Un petit retour en arrière
Guillaume Pitel : Julien, on s’est connus il y a presque 10 ans, à l’époque j’étais chez Exensa et on démarrait sérieusement dans le crawling. On avait développé un algorithme d’apprentissage pour la sémantique et on voulait prouver qu’il passait à l’échelle du Web. On a commencé avec Common Crawl, mais insatisfaits de la qualité, j’ai voulu crawler moi-même.
Je t’avais contacté parce que j’avais vu ton activité autour de StormCrawler et DigitalPebble. Finalement, ça ne s’est pas fait à cause de la complexité de monter un financement avec le UK, même avant le Brexit. J’ai collaboré avec l’université de Twente aux Pays-Bas, ce qui a mené à la création de Babbar. Aujourd’hui, on crawle beaucoup, notamment pour Ibou, notre moteur de recherche Web en cours de développement. Mais parlons de toi : quel est ton parcours ?
Julien Nioche : Je suis basé en Grande-Bretagne depuis plus de 20 ans, à Bristol depuis 16 ans. J’ai un parcours atypique avec un syndrome de l’imposteur bien ancré : je n’ai jamais étudié l’informatique à l’université. J’ai appris à coder pendant mon service militaire, pendant mes heures de garde à l’école militaire.
J’ai étudié le russe et les langues jusqu’à la maîtrise. Je me destinais à la traduction littéraire, mais il faut ne pas avoir besoin d’argent et être incroyablement doué. Ce n’était pas mon cas. La traduction technique ne m’intéressait pas car les traducteurs utilisaient déjà des systèmes d’assistance. C’est en discutant avec mes profs que j’ai réalisé que je pouvais concilier linguistique et programmation via le traitement automatique des langues (TAL).
J’ai travaillé pour une start-up en France, puis je suis parti à l’université de Sheffield comme chercheur. On faisait de l’extraction d’entités nommées : extraire automatiquement dans un texte des noms de personnes, produits, lieux et leurs relations. À l’époque, tout était fait par règles, ce qui nécessitait des compétences linguistiques. C’était ingérable au bout d’un moment.
L’open source et Lucene
Julien : La start-up en France faisait des moteurs de recherche « sémantiques » avec des dictionnaires et ressources lexicales. J’avais trouvé un petit projet open source peu connu que j’ai commencé à utiliser intensivement : Lucene. À l’époque, ce n’était pas encore à la Fondation Apache. J’ai fait quelques contributions modestes, mais j’étais parmi les premiers utilisateurs.
Ce projet a été super important pour moi. C’est là que j’ai vu comment on écrivait du bon code en Java, la dynamique d’un projet open source, comment combiner des influences différentes du monde entier. Je suis devenu un meilleur développeur Java juste en regardant le code de Lucene.
À Sheffield, je faisais de l’extraction d’information. Au bout de quelques années, le côté universitaire m’a fatigué. Les énormes projets européens produisaient peu par rapport à l’argent investi. C’était génial pour le tourisme avec des réunions bizarrement toujours en Espagne, Italie, Grèce l’été, mais la sortie était d’une pauvreté affligeante. Je venais de l’industrie et je voulais faire des choses qui marchaient, qui avaient un impact.
Le passage au crawling
Julien : C’est là que j’ai commencé DigitalPebble. C’était un saut dans le vide car je n’avais aucune expérience de consulting. J’arrivais avec mon bagage sur Lucene, je voulais faire des moteurs de recherche. C’était au tout début d’Elasticsearch. J’avais d’ailleurs rencontré Shay Banon quand il était encore seul, je crois à Amsterdam.
Mes clients me disaient : « C’est super, tu peux faire de l’indexation, de la recherche, de la classification. Mais il nous faut des documents. Est-ce que tu peux nous aider à avoir des pages web ? »
Guillaume : Ah, le fameux problème d’acquisition de données !
Julien : Exactement. J’avais déjà joué avec le web comme corpus de données. À l’époque, j’avais travaillé avec Gregory Grefenstette…
Guillaume : Sérieux ? J’ai fait mon post-doc avec lui !
Julien : Incroyable ! J’avais fait un stage au centre de recherche Xerox à Grenoble avec lui. On avait travaillé sur l’utilisation de corpus web pour des tâches linguistiques, notamment l’identification de langues. Mais là, on me demandait de crawler plusieurs millions de pages. Il me fallait des outils d’un autre calibre.
Découverte de Nutch et Apache
Julien : En fouillant, je suis tombé sur Apache Nutch. Nutch permet de crawler le Web à très grande échelle et est surtout connu pour avoir donné naissance à Hadoop, la première grande plateforme open source Map/Reduce. Doug Cutting, qui a créé Nutch, était aussi l’auteur de Lucene. Au risque de passer pour un fan boy, c’est quelqu’un que j’admire beaucoup : il a fait Lucene, Hadoop, Nutch, Avro. Et c’est quelqu’un d’absolument adorable que j’ai eu la chance de rencontrer à une des conférences Apache.
J’ai commencé à utiliser Nutch vers 2008-2009 pour des clients qui voulaient crawler un milliard de pages. Sur des clusters assez gros, j’ai trouvé plein de bugs et d’améliorations possibles. J’ai commencé à contribuer des patches, patch sur patch. Et on m’a demandé de devenir committer sur le projet.
Guillaume : C’est une belle reconnaissance.
Julien : Les succès commerciaux donnent de la joie, mais le fait d’avoir été invité à être committer sur Nutch, c’est une des choses qui m’a donné le plus de joie professionnellement. Je me suis senti plus valorisé que d’avoir un gros contrat. C’était avoir la reconnaissance de gens que j’admirais. Ça m’a donné un méga boost.
On m’a demandé après d’être PMC chair, le lien entre le comité directeur du projet et la Fondation Apache. J’ai utilisé Nutch pour pas mal de clients. Au fur et à mesure, je faisais de plus en plus de crawl, de moins en moins de TAL, et très peu de recherche. Entre temps, Solr et Elasticsearch s’étaient bien établis.
Les limitations de Nutch
Julien : J’ai commencé à voir les limites de Nutch. Même si c’était très robuste et fiable, le fait que Nutch repose sur Hadoop faisait que le crawl se faisait par batch, par vagues. Plus le crawl grandissait, plus certaines opérations batch prenaient du temps entre les phases.
Pour illustrer, la séquence est : génération d’URLs à chercher, fetch de ces URLs, parsing pour extraire liens et contenu, indexation, puis mise à jour de la base de données. Avec ce modèle, plus ça va, plus les premières et dernières phases prennent du temps car la base de données croît rapidement. La partie fetch, qui devrait être l’essence du crawl, représente une part qui diminue.
C’était aussi inefficace car on n’utilisait pas les ressources en même temps. Quand on fetch, on utilise le réseau, peu de CPU, peu de disques. Quand on parse, c’est du CPU, pas de réseau. Quand on fait génération et update, c’est du CPU et beaucoup de disques, pas de réseau. Bref, on a toujours des ressources inutilisées.
La naissance de StormCrawler
Julien : Il y a 12-13 ans, il y avait l’émergence du stream processing, le traitement de flux. Plusieurs projets émergeaient, dont Apache Storm. J’ai commencé à regarder Storm et je trouvais ça séduisant. Les concepts étaient simples mais permettaient des choses expressives.
Je me suis dit : je vais voir si je peux écrire un petit crawler en Storm. Je l’ai appelé StormCrawler, ce qui en dit long sur mon imagination ! J’ai investi du temps par intérêt, pour voir où ça me mène. Assez rapidement, j’ai vu que ça intéressait des utilisateurs potentiels. Je me suis retrouvé à San Francisco avec un client pour les aider à l’utiliser.
Guillaume : Et la communauté s’est développée ?
Julien : Oui, et c’est une joie égale à celle d’avoir été fait committer sur Nutch. Quand on crée un projet open source, juste une idée qu’on code dans son bureau, et que quelqu’un s’y intéresse, envoie une contribution, même un commentaire, ou l’utilise… C’est un sentiment génial : « Wow, j’ai fait un truc suffisamment bon pour que les gens investissent leur temps et attention. »
C’est le meilleur antidote au syndrome de l’imposteur. StormCrawler a grandi progressivement. J’ai voulu régler les problèmes de Nutch : maintenant on est tout le temps en train de tout faire. On récupère des URLs, on met à jour la base, on fetch, on parse — tout en même temps. Toutes les ressources sont utilisées simultanément.
C’est logique : si on se soucie de politesse dans le crawl, on ne va pas taper un serveur avec beaucoup de requêtes dans un temps restreint. On respecte le robots.txt et ses directives. Avoir plus de temps pour fetcher permet de fetcher de manière plus polie.
Plus modulaire aussi. Nutch, il faut récupérer tout le code base et le modifier. Avec StormCrawler, tout est modulaire, basé sur des dépendances Maven. J’ai vu des utilisateurs crawler un milliard de pages avec un code minimal — juste quelques fichiers de configuration. L’idée était de faire quelque chose d’élégant, léger et surtout facile à customiser.
Je pense que StormCrawler a réussi à être à la fois facile à modifier et réusable. Des utilisateurs l’ont utilisé pour des choses très différentes, ayant juste besoin d’écrire leur petite partie spécifique et de s’appuyer sur une base commune.
Vers Apache et la transmission
Julien : Au fil du temps, j’ai essayé de faire levier avec les efforts des autres. L’idée n’était pas de lâcher prise, mais d’inciter les autres contributeurs à participer et de leur laisser les clés du camion, pour que le projet devienne le leur autant que le mien.
Il y a un an et demi, j’ai fait don de StormCrawler à la Fondation Apache. On est passé par une phase d’incubation assez rapide car parmi les committers, quatre étaient déjà membres de la Fondation Apache. Maintenant, StormCrawler est un Top-Level Project. Ma participation est limitée, l’essentiel du travail est fait par d’autres committers. Quel que soit mon implication, le projet continuera.
Guillaume : C’est un peu comme voir grandir ses enfants et accepter qu’ils deviennent indépendants ?
Julien : Exactement. J’étais allé jusque là, je serai toujours là, mais le projet doit faire sa vie.
Le tournant vers le Green IT
Guillaume : Et depuis cette transmission, tu as évolué vers quoi ?
Julien : Les questions environnementales ont toujours été d’une grande importance pour moi. J’ai toujours eu conscience qu’on ne traitait pas la planète comme on le devrait. Pendant longtemps, il y avait une dichotomie entre mes convictions personnelles et mes activités professionnelles.
Il y a deux-trois ans, j’ai commencé à regarder ce qui se faisait autour du Green Software. J’ai trouvé que les compétences que je connaissais, mon expertise professionnelle, pouvaient être utilisables pour faire des choses dans lesquelles je croyais profondément. Je suis tombé dans le Green Software — cette idée qu’on peut mesurer et réduire les impacts environnementaux de ce qu’on fait avec du logiciel.
Guillaume : Avant qu’on rentre dans le détail, parlons rapidement des moteurs de recherche et de l’IA. Nous, on lance Ibou, un moteur de recherche autonome. Avec l’émergence de l’IA générative qui utilise massivement le search, quel est ton avis sur l’impact environnemental ?
L’IA et l’impact environnemental
Julien : L’IA, c’est sur toutes les lèvres, et les impacts environnementaux aussi. C’est une source de problèmes, surtout aux États-Unis : utilisation d’eau dans des régions arides, usage d’électricité que les grilles nationales ne peuvent pas toujours fournir. On se retrouve avec des acteurs qui font tourner des turbines à gaz. C’est une catastrophe environnementale. Il y a aussi le bruit.
Je parlais avec quelqu’un de l’industrie qui vit aux États-Unis et me disait : « Pour aller faire mes courses, je passe devant 20 data centers. Quand ils font tourner leur générateur diesel, la qualité de l’air est abominable selon le vent. » Ça nous ramène au 18e siècle en France où les banlieues étaient déterminées par le vent et les usines. On revient à ça avec les data centers.
Il ne se passe pas une journée sans article essayant d’apporter un éclairage. En Grande-Bretagne, c’est la course à la construction des data centers. Bizarrement, au lieu de les construire en Écosse où on a tellement d’énergies renouvelables qu’on doit les couper du réseau et où l’accès à l’eau n’est pas un problème, on les met dans le sud-est de l’Angleterre où il y a déjà des problèmes d’eau et d’accès à l’électricité.
Guillaume : Pour la latence peut-être ?
Julien : Je ne sais pas. Ou ils ont peur que les Écossais deviennent vraiment indépendants 🙂 ! Il y a un progrès : Google a publié le mois dernier un papier éclairant sur leurs impacts. Mais ça reste dans l’ensemble très opaque. Quand un modèle tourne en production, c’est difficile à évaluer.
Pour le web search, tu rappelais que le machine learning n’est pas nouveau dans la recherche. C’étaient surtout des approches vectorielles classiques avec des distances cosinus, plutôt légères en computation. Ce n’est pas comme les LLM.
Le problème, c’est l’opacité. Pour l’essentiel de l’IA et du SaaS, quand tu demandes : « Quelle quantité d’énergie a été utilisée pour mes pipelines et dans quelle région ? », ils disent : « C’est intéressant, mais on ne peut pas vous dire. » Tout est opaque. Il est difficile d’avoir une estimation et d’être capable de prendre en compte les impacts dissimulés.
Les moteurs de recherche et l’environnement
Guillaume : Tu parlais de moteurs de recherche qui se positionnent sur l’environnemental en plantant des arbres. Un avis là-dessus ?
Julien : Eh bien je contribue à une organisation caritative près de Bristol qui plante des arbres. Il m’arrive de passer mes week-ends à planter des arbres, c’est un sujet qui me tient à cœur.
C’est une bonne chose, mais ce qui serait encore mieux, c’est qu’ils publient des indications : « Par requête utilisateur, nous estimons que cela génère telle quantité d’électricité et, comme nos serveurs tournent à tel endroit, ça se traduit par telle quantité d’émissions. » Mettre les choses en perspective avec des données ouvertes, dans la mesure du possible.
Guillaume : A propos de transparence et d’impact, depuis le 11-12 septembre, Google a bloqué les requêtes avec 100 résultats, très utilisées dans le SEO pour le tracking de position. On soupçonne que ce n’est pas à cause des gens qui font du SEO, mais plutôt des acteurs de l’IA générative comme OpenAI, Perplexity, Anthropic qui requêtent massivement de manière non conforme.
Bing aussi, cet été, a arrêté son API de search pur. Maintenant, il faut utiliser Azure avec leur service qui intègre le résumé automatique. Pas mal de resserrement de l’espace concurrentiel sur le search. Et la transparence n’est pas leur priorité.
Julien : Google publie quand même des choses. Je crois qu’ils étaient à 7 grammes par recherche en 2023. Difficile de savoir si un moteur ultra-optimisé pourrait faire mieux ou si leur échelle les rend efficaces. Google, parmi les principaux acteurs cloud, est le plus transparent. Ce n’est pas parfait, mais ils publient chaque année un rapport environnemental détaillé avec une méthodologie claire. Le problème, c’est que quand on regarde le tableau, les émissions sont en hausse, la consommation électrique en hausse, tout à cause de l’IA. Mais ils mettent une tick verte à côté ! Ils s’éloignent à grande vitesse de leurs objectifs.
Eux sont encore assez transparents et mettent à disposition de leurs utilisateurs les outils les plus pratiques. Au-delà de l’environnemental, il y a les questions de vie privée et de souveraineté : est-ce acceptable d’avoir délégué entièrement les fondations de l’industrie numérique à un acteur privé d’un pays étranger sous influence de leur gouvernement ?
Le web crawling et l’efficacité
Guillaume : Chez Babbar, on est très attentifs aux coûts, financiers et aussi environnementaux. On a 60 machines pour la base qui gère 700 milliards d’URLs, 16 pour le crawl. On est sur des serveurs dédiés en région parisienne chez OVH et Scaleway. Le moins possible de cloud AWS ou GCP.
On est attentifs aux coûts CPU, RAM, disque. Mon principal problème : on crawle le web, donc on déclenche des opérations partout dans le monde. Je n’ai pas trouvé d’indicateur permettant de dire : l’intensité carbone de demander une information à tel serveur. Ça permettrait d’orienter mon crawl et d’avoir une idée de mon impact indirect.
Julien : Pas à ma connaissance. Le réseau, c’est un peu spécifique. Il y avait une présentation passionnante au GreenIO de Paris en décembre dernier. GreenIO, c’est une des grandes conférences sur le Green Software. Il y a aussi un podcast du même nom par Gaël Duez.
La présentation parlait de l’impact environnemental du network. C’est dur d’avoir des estimations. Ce qui se passe, c’est que le network est provisionné pour les pics de demande. La plupart du temps, il se passe très peu par rapport à la capacité, mais la quantité d’énergie nécessaire est la même. Ça devient un peu une constante. Les switches ont des options non activées par défaut qui permettraient de réduire quand il y a peu de trafic.
Il pourrait y avoir du routage intelligent qui prendrait en compte l’intensité carbone d’un nœud dans le réseau et dirait : « C’est un peu crado à cet endroit, on va passer de l’autre côté, c’est plus propre. » Mais actuellement, c’est une constante.
Dans ton cas, tu disais que c’est surtout les ressources physiques, l’embodied carbon. C’est dû au fait que tu tournes en France où l’énergie est relativement propre. Si tes serveurs étaient en Pologne avec l’énergie au charbon, ça changerait le rapport.
Le crawl intelligent et la qualité
Guillaume : L’intelligence du crawl est déterminante. Quand on crawle naïvement, on se retrouve vite à ne crawler que du déchet. Il y a énormément de déchets sur Internet. Des sites créent une infinité de pages pour tricher sur les métriques type PageRank, et par définition, ces sites infinis finissent par occuper tout ton index.
Julien : Je reconnais tout à fait ce que tu décris. Avec des crawls qu’on faisait, si on ne prend pas les mesures adéquates, on se retrouve rapidement avec 80% des URLs qui sont des redirections infinies vers des contenus adultes sans valeur.
Pour Common Crawl, je pense que ça s’est amélioré. Je connais bien Common Crawl car j’ai travaillé plusieurs fois avec eux. Il y a très longtemps, quand leur ingénieur était parti, j’ai fait tourner le crawl. J’avais réussi à les convaincre de revenir vers du Nutch plus standard. Plus tard, j’ai fait don d’une configuration StormCrawler pour crawler des sites de news, qui fait maintenant partie de leurs ressources.
Plus récemment, j’ai passé quelques mois avec eux. Sebastian Nagel, leur ingénieur principal qui est aussi committer de Nutch et StormCrawler, a fait énormément de travail. La qualité s’est améliorée. Common Crawl a été une des sources principales d’entraînement pour les LLM. Des organisations qu’on connaît tous ont largement utilisé Common Crawl.
Guillaume : Moi c’était vers 2015-2016. On a commencé avec Bubing, puis développé notre propre version. On a beaucoup contribué à Bubing car il y avait énormément de bugs, mais il était impressionnant en efficacité par rapport à Nutch ou Heritrix.
Julien : En parlant de Bubing, j’étais rentré en contact avec eux. J’ai fait il y a quelques années un projet appelé URLFrontier, où l’idée était de séparer la logique de sélection et stockage des URLs dans un service séparé, pour ne pas réinventer la roue. Chaque crawler réinvente son propre code pour ça.
Les auteurs de Bubing étaient des universitaires pas très intéressés à long terme. Ça illustre que l’open source, ce n’est pas que le code soit accessible. Le plus important, c’est quelle communauté on construit. C’est le succès d’un projet : la communauté derrière. C’est dans l’ADN des projets Apache.
Guillaume : On a contribué des fixes à Bubing, puis on a dû forker car on devenait trop dépendants. Zéro communauté ne s’intéressait à contribuer. C’est difficile parfois de contribuer à l’open source en tant que société. On a essayé de contribuer à RocksDB, jamais au-delà de tentatives répétées car on sent qu’il n’y a pas de volonté du maintainer.
Prix, énergie et localisation
Guillaume : Ma règle intuitive pour l’impact environnemental, c’est surtout le prix. Si tu dépenses de l’argent, ça doit avoir un impact. Je me doute que c’est trop simplifié mais ça doit avoir quand même un bon lien.
Julien : Pourtant, le prix est un assez mauvais proxy pour l’impact. Tu as raison, si c’est cher, c’est probablement lourd. Mais laisse-moi te donner des exemples sur AWS.
Tu peux prendre des mesures qui vont réduire tes coûts en t’engageant sur une période ou en réservant des instances. Ça n’aura aucun impact environnemental sur les mêmes services. Pour l’impact, tout dépend essentiellement d’où les services tournent.
Exemple concret : je travaillais récemment avec une organisation à Bristol, Camera Forensics, des gens fantastiques qui utilisent StormCrawler. La plupart de leurs process tournent sur AWS aux États-Unis, simplement parce que c’est le défaut — us-east-1. Beaucoup de services n’étaient disponibles qu’à cet endroit au départ.
En réalité tout est question d’intensité carbone de la grille électrique. Aux États-Unis, beaucoup de charbon et gaz, peu de renouvelables. En France, vous êtes essentiellement sur du nucléaire — pas forcément une bonne nouvelle environnementalement, mais au moins c’est bas carbone. L’intensité carbone en France est aux alentours de 30-40 grammes d’équivalent CO2 par kilowattheure.
Ici en Grande-Bretagne, c’est différent car la transition énergétique des 10-15 dernières années a été efficace. Beaucoup de vent, des éoliennes, et malgré ce qu’en pensent les Français, du soleil aussi ! On a donc beaucoup plus de variations dans l’intensité carbone électrique.
En Suède, ils sont tout le temps à environ 20g car ils ont énormément de renouvelables. Le même process selon qu’il tourne aux États-Unis ou en Suède va nécessiter la même quantité d’énergie. Mais dans un cas, ça va générer 400g de CO2 par kilowatt, dans l’autre cas 20g. Ça n’a aucun rapport avec le prix. Tu as payé la même chose, mais dans un cas l’impact environnemental est 20 fois moindre.
C’est ce qu’on appelle le carbon-aware, la base du Green Software. On a accompagné cette organisation à Bristol. Ils migrent vers la Suède et passent sur des instances Graviton plus récentes, moins chères et plus efficaces. Ils font d’une pierre deux coups.
L’autre stratégie, c’est le time shifting : prendre en compte les fluctuations dans les émissions de carbone à l’intérieur d’une journée. Si on a un batch à faire, le faire quand la grille est relativement propre pour minimiser l’impact.
Question pour toi : où tournent tes serveurs géographiquement ?
Guillaume : En région parisienne, et chez OVH et Scaleway en France. En bon Français nucléarisé, utilisateur de resources locales, l’impact carbone de l’électricité n’est pas le plus déterminant pour moi dans mes réflexions. Quand je fais des rapports, le plus déterminant c’est les ressources physiques, les serveurs. Notre usage énergétique est relativement de faible impact.
Mon principal problème : on crawle le web, donc on déclenche des opérations partout. Je n’ai pas trouvé d’indicateur d’intensité carbone par Autonomous System ou par IP par exemple. Ça permettrait d’orienter mon crawl. Les estimations des coûts réseau vont de très peu à énorme selon qui tu interroges.
Le réseau et les impacts cachés
Julien : Le réseau est un problème difficile. Il y avait cette présentation au GreenIO qui expliquait qu’avec le network, c’est provisionné pour les pics de demande. La plupart du temps, il se passe absolument rien, mais la quantité d’énergie nécessaire est la même. Ça devient une constante.
Il pourrait y avoir du routage intelligent basé sur l’intensité carbone, mais actuellement c’est une constante évaluée. Dans ton cas, le fait que tes ressources physiques soient plus importantes est dû au fait que tu tournes en France où l’énergie est propre. Si tu étais en Pologne, ça changerait le rapport.
Dans les hyperscalers, l’équipement est tellement utilisé sur 5-6 ans que le ratio est trois quarts usage, un quart hardware. Pour un laptop ou téléphone, c’est l’inverse : 80% de l’impact est dans la fabrication, 20% dans l’utilisation. La meilleure chose à faire : le garder le plus longtemps possible.
Pour les serveurs cloud, c’est différent. Parfois il est plus efficace d’avoir des serveurs avec une durée de vie moindre mais plus efficaces, surtout si la grille est vraiment sale. Les économies feront qu’au bout de quelques temps, ça aura un impact positif.
Ce que tu décrivais avec le crawl, c’est un peu le crawl tournesol qui privilégierait certaines régions selon le soleil, le vent. Ça permettrait d’optimiser, mais c’est difficile à mesurer puisque ce n’est pas de ton côté.
Guillaume : Compliqué. Il faudrait un dialogue entre le crawler et le crawlé. Et puis potentiellement, il y a un arbitrage aussi avec la politesse: vaut-il mieux crawler quand le serveur n’est pas occupé pour éviter de gêner ? Mais quand il n’est pas occupé, c’est probablement la nuit, donc pas idéal pour le solaire.
Aussi, nous en tant que crawler, on n’est intéressé que par le texte pour l’indexation. Avoir une intelligence au niveau des serveurs web qui dirait : « Si c’est un crawler, je ne vais pas activer les cookies, la personnalisation, le JavaScript, je vais renvoyer une payload minimale avec du HTML sémantique bien ficelé. »
LLMs et l’avenir du web
Julien : On voit ça justement par rapport aux crawlers utilisés par les LLM. Ça s’appelle « LLMs.txt » . L’idée est de pointer vers une version des pages en Markdown, une version minimale du contenu textuel avec juste les liens. Servir ça aux robots.
Je me suis amusé à regarder. J’ai pris 1 million de sites web, lancé un petit crawl avec StormCrawler pour voir la proportion qui avaient une page comme ça. J’ai laissé tourner plusieurs heures et quand le total était toujours à zéro, j’ai tué le crawl. Pour l’instant, je n’ai pas l’impression que ça prend de l’envol. Mais qui sait, ce serait plutôt une bonne chose.
Le problème, c’est que ça nécessite que les acteurs de l’IA veuillent jouer selon les règles. Quand on voit le robots.txt — cette directive qui permet au webmaster de dire au crawler quelle page ne pas visiter ou quelle fréquence utiliser — c’est le b.a.-ba. Un crawler bien élevé devrait respecter ça. StormCrawler le fait par défaut.
Mais les acteurs de l’IA ne le font pas. Ils bombardent allègrement les sites web. Je ne pense pas qu’on puisse s’attendre à ce qu’ils respectent quelque chose de différent, sauf si ça a de la valeur ajoutée pour eux, comme ne pas avoir à parser des pages complexes.
Guillaume : Mais ça voudrait dire qu’ils mettent de la valeur sur l’argent, et justement je relève qu’ils en ont un peu trop et qu’ils préfère sacrifier l’argent pour gagner du temps. En janvier, un acteur de l’open source a sorti Anubis, un captcha JavaScript qui bloque les crawlers qui se font passer pour des browsers, car les sites se font pilonner par des crawlers sans aucun respect.
Des solutions comme Cloudflare existaient déjà, mais là c’est quelqu’un qui l’a fait en open source parce qu’il s’était fait bombarder son site. C’était une espèce de GitHub avec des liens vers l’historique des commits qui demandaient des accès database. Il s’est fait écrouler par ces malotrus du web qui respectent rien parce qu’ils mettent de l’argent, achètent des proxies, des crawlers, et balancent la sauce sans se soucier des conséquences.
C’est le malheur de ces industries surcapitalisées sans limites, dans une course effrénée au premier qui arrive.
Julien : Je suis content que tu aies utilisé le mot « malotru », je ne l’ai pas entendu depuis très longtemps vu que je suis en Grande-Bretagne. Le langage avec une distance prend une dimension poétique. Il m’arrive d’entendre des mots rares pour moi qui ont une saveur particulière.
Spruce : un projet Green IT
Guillaume : Parle-nous de tes projets dans le Green IT maintenant.
Julien : Avec mon ADN open source, j’ai commencé il y a quelques mois un nouveau projet : Spruce. Ce que fait Spruce, c’est qu’il permet d’estimer l’énergie et les émissions de l’usage d’un utilisateur sur AWS — les différents services : stockage, réseau, compute. Il va donner une estimation de l’énergie nécessaire et des émissions de CO2.
Maintenant, l’activité de DigitalPebble c’est essentiellement ça : du Green Software, du GreenOps. Je fais encore du crawl si on me demande avec beaucoup de ferveur, mais je suis essentiellement dans le Green Software.
Guillaume : Le GreenOps, c’est quoi exactement ?
Julien : Tout le monde est familier avec le FinOps, l’activité qui consiste à regarder et réduire les coûts financiers de l’usage du cloud. Le GreenOps regarde non pas les coûts, mais les impacts environnementaux.
Spruce est un outil de GreenOps. Il prend des usage reports, des rapports d’utilisation générés par AWS — d’énormes fichiers Parquet comme un CSV géant avec un million de lignes et des centaines de colonnes. Spruce lit les Parquets, fait tourner différentes données et modèles pour arriver à ces estimations. À partir de là, ça permet de faire du reporting, d’avoir des chiffres sur l’impact sur le cloud AWS. Mais aussi d’essayer de réduire leurs impacts, de voir quels projets, environnements, services ont un impact et surtout qu’est-ce qu’on peut faire pour réduire.
Moi avec DigitalPebble, je fournis le projet open source mais aussi du conseil qui aide les organisations à transcrire cette information en action pour réduire leur impact environnemental.
Spruce utilise des librairies open source. On ne crée pas nos propres modèles, on reprend des librairies existantes. Il y a un module qui permet de récupérer les estimations de l’API Boavizta.
Une des motivations pour le projet : il y avait Cloud Carbon Footprint qui était pendant longtemps la référence. C’était un bon outil multiplateforme : Google, Alibaba, AWS. Mais il était soutenu par une boîte aux US qui fait du consulting, et ils ont arrêté de soutenir le projet. Le projet est mort. Plus personne n’y contribue.
C’était le cas avec Cloud Carbon Footprint : pas de diversité des contributeurs. Tous bossaient pour la même boîte. Le jour où cette boîte en a marre, le projet est mort. Spruce, l’idée c’est d’avoir quelque chose qui ne fonctionnera pas comme ça. C’est pour l’instant un projet sous le label de DigitalPebble, ma boite de consulting, mais il se peut que je le mette aussi à la Fondation Apache au bout d’un moment. On va voir, ça dépendra de la dynamique, s’il y a de l’attraction.
Il existe aussi des solutions commerciales pour le GreenOps. En France, Sopht et OxygenIT, en Grande-Bretagne GreenPixie et Tailpipe. Plein d’offres sur le marché avec leurs atouts. Je connais toutes ces boîtes car j’ai récemment travaillé pendant un an pour le ministère de la Justice britannique. J’ai été fonctionnaire où je m’occupais du Green Software au ministère de la Justice. Ce n’était pas un rôle qui existait, c’est un rôle que j’ai créé.
C’est un environnement énorme avec des milliers de développeurs. J’ai vu qu’il y avait un vide côté GreenOps, donc j’ai cherché à le combler. Au bout d’un moment, je me suis rendu compte que j’aurais sans doute plus d’impact en retournant faire ça de mon côté avec DigitalPebble. Dans ce cadre, j’avais bossé avec certains de ces providers de solutions commerciales.
L’idée avec Spruce n’est pas de rentrer en compétition avec eux, mais de fournir un premier outil qui va permettre à un développeur, à une organisation, de montrer quelque chose rapidement sans que ça coûte beaucoup d’argent et d’avoir cette première démarche de conviction à l’intérieur de son entreprise.
Le problème humain du GreenOps
Julien : Le problème du GreenOps et du FinOps, ce ne sont pas des problèmes techniques. Ce n’est pas « on est capable d’avoir les données » — surtout pour le FinOps, ces données on les a, Amazon les donne avec beaucoup de détails. Le problème, ce n’est pas de coder les dashboards, ça c’est assez trivial. Le problème, c’est un problème humain de convaincre les gens, mais aussi de mettre l’information visible.
Qu’une équipe de développeurs qui bosse sur un produit puisse facilement avoir, de la même manière qu’ils ont leurs métriques de déploiement, les coûts et les impacts aussi.
Ce qui se passe souvent : le développeur, dans une boîte, le coût, il s’en moque un peu. Sauf s’il est dans une start-up et que sa survie immédiate dépend de la survie financière de l’entreprise. Mais à partir du moment où l’organisation dépasse une certaine taille, plus elle est grande, plus son implication dans le coût financier de ce qu’il fait va être moindre.
J’ai vu ça dans les grandes organisations : la quantité de services sur le cloud qui sont inutilisés, c’est incroyable. C’est dû en partie à la manière dont ces organisations fonctionnent. Souvent une équipe va créer un nouveau service, le transmettre à une autre équipe qui assure la maintenance. Cette équipe se dit : « Pourquoi on a cinq environnements ? » Et dans le doute, ils laissent les choses parce qu’ils n’ont pas une connaissance profonde de l’outil.
On se retrouve avec des ressources inutilisées. Des buckets avec des données qu’on laisse parce qu’on n’est pas bien sûr, avec de la réplication sur trois continents. Tout ça mène à des quantités de ressources énormes qui coûtent beaucoup d’argent et ont un impact environnemental.
Ces développeurs ne vont pas forcément être très sensibles à l’aspect financier. Je l’ai vu : « Oui, ça coûte tant par mois et on n’utilise pas. » Mais par contre, si je dis : « Oui, c’est tant par mois, mais ça génère aussi 30 kilos de CO2 par mois sans aucune raison. » 30 kilos de CO2, c’est 300 kilomètres en voiture, l’équivalent qu’on peut tout à fait éliminer.
Ça peut faire que le développeur qui, sinon, dit : « J’ai pas le temps de regarder », va prendre le temps de le faire. En anglais on dit « It’s not my wallet », ce n’est pas mon portefeuille, mais c’est ma planète. C’est ça le GreenOps : ça permet d’avoir une organisation qui va plus loin sur le FinOps, plus loin sur le financier.
L’argument : si vous mettez en avant les critères environnementaux, ça va déclencher aussi des actions côté financier.
Conclusion et perspectives
Guillaume : Pour conclure, tu travailles désormais essentiellement sur le Green IT ?
Julien : Oui, l’activité de DigitalPebble c’est essentiellement du Green Software et du GreenOps. Je fais encore un peu de crawl ou de recherche si on me demande avec beaucoup de ferveur, mais je suis essentiellement dans le Green Software.
Pouvoir aligner mes convictions environnementales avec mon expertise professionnelle, c’est une grande satisfaction. Pendant longtemps il y avait une dichotomie entre mes convictions personnelles et mes activités professionnelles. Maintenant c’est aligné, et c’est quelque chose dans lequel je crois profondément.
Le Green Software, c’est mesurer et réduire les impacts environnementaux de ce qu’on fait. Le vrai problème du GreenOps n’est pas technique, c’est humain : convaincre les gens et rendre l’information visible. Quand un développeur voit l’impact environnemental de son code, même s’il ne se soucie pas des coûts financiers, il peut agir parce que c’est sa planète.
Guillaume : Merci Julien pour tous ces éclairages, de ton parcours à StormCrawler jusqu’au Green IT. C’est passionnant de voir comment ton expertise technique sert maintenant une cause qui te tient à cœur.
Julien : Merci à toi Guillaume. Et bon courage avec Ibou, c’est un beau projet. L’idée d’avoir un moteur de recherche qui respecte les éditeurs web et qui essaie d’être sobre, c’est exactement le genre d’initiative dont on a besoin.
