Le niveau d'absurdité et de gaspillage induit par les crawlers IA c'est quand même impressionnant.
En 33 jours, mon serveur web s'est mangé 2,21 milliards de requêtes HTTP. Si je me trompe pas ça fait une moyenne de 775 requêtes par seconde. 54 millions viennent de Google 132 millions de Facebook 187 millions d'OpenAI 554 millions de Claude/Anthroopic 893 millions de bots déguisés en particuliers depuis des IP résidentielles Et le reste c'est du "autre"
Ce traffic a consommé 5,40 terabytes de bande passante.
Le site qui a reçu le plus de traffic (787 millions) c'est le wordpress d'une asso ultra locale qui doit avoir quelques centaines de visiteurs humains par mois, grand max.
Edit : vu que ce fil a circulé bien plus que je m'y attendais, je vous invite à lire la suite publiée ce matin pour avoir plus de contexte sur ces chiffres
Sur un VPS OVH à 5 balles/mois qui héberge des tout petits sites/services avec un traffic normalement riquiqui.
je sais pas si vous vous rendez-compte de la dinguerie.
Toutes proportions gardées c'est comme si dans ma boite aux lettres ou je reçois deux courriers par jour depuis 10 ans, j'en recevais soudainement cinquante mille par jour, tous les jours.
Et ça c'est ce qui se passe sur le web actuellement, partout.
Okay ce fil a été repartagé bien plus que ce que j'imaginais, donc je pense qu'il est nécessaire de contextualiser un peu plus ces données.
Déjà, le serveur qui héberge ces sites est un VPS OVH classique sur lequel j'héberge une quinzaine de domaines. Trois d'entre eux sont des sites WordPress, le reste sont des services divers et variés (Miniflux, Seafile, Bitwarden, une gallerie photo, des sites statiques…).
Un mot sur Iocaine
J'en ai déjà parlé ici à plusieurs reprises mais j'ai oublié de le mentionner au début du fil. En mars 2025, j'ai déployé sur ce serveur un outil appelé Iocaine, qui permet de piéger les robots d'indexation IA. À l'époque, j'avais expliqué l'essentiel dans [cet article de blog](<https://agate.blue/2025/03/27/Pi%C3%A9ger-les-robots-d'indexation-gr%C3%A2ce-%C3%A0-nginx-et-iocaine.html>).
Même si les exemples de codes sont obsolètes, l'outil fonctionnent toujours de la même manière : lorsqu'un visiteur indésirable est détecté, plutôt que de refuser de servir la page demandée, on va lui servir une fausse page. Cette page est bourrée de lien vers d'autres fausses pages, elles mêmes bourrées de liens vers d'autres fausses pages. À l'infini.
En pratique, ça envoie ce traffic dans un labyrinthe automatiquement créé. Si vous voulez voir à quoi ça ressemble, voici un lien qui vous envoie dans le labyrinthe. Cliquez sur n'importe quel lien de cette page, et vous arrivez sur une autre page similaire, mais avec une URL différente (c'est important).
Puisque Iocaine arrive a détecter les crawlers, pourquoi ne pas directement leur interdire l'accès (par exemple en renvoyant un code HTTP 403) ? Pourquoi s'embêter à répondre une fausse page et créer un labyrinthe qui va les faire revenir ?
Parce que les robots évoluent au fil du temps, et si un site bloque leur traffic de manière évidente, ils vont simplement trouver une solution de contournement et revenir plus tard, de manière plus discrète. Ça augmente la difficulté à les gérer, pour tout le monde.
Bloquer fonctionne dans l'immédiat mais pas à moyen ni long terme (en tout cas c'est mon avis)
Empoisonner la liste d'URLs des crawlers permet d'arriver au même objectif, mais différemment : vu que le crawler va visiter des pages dont on sait qu'elles n'existent pas pour de vrai, on peut désormais identifier le crawler avec certitude : qu'il change d'adresse IP, de comportement, de version, de User-Agent… peu importe puisque c'est sa demande elle-même, l'URL d'une page qui n'existe pas, qui le trahit.
Servir de fausses pages avec de fausses URLs permet ainsi de mieux détecter ces crawlers.
Est-ce que ce n'est pas un énorme gâchis de ressources ?
Honnêtement, je ne pense pas.
Je crois plutôt que ça fait économiser à tout le monde (sauf aux crawlers évidemment). Je rappelle : le trafic des crawlers est une fonction directe du nombre d'URLs dans leur liste à visiter. Et ils en ont des trillions, de base, car le web est gigantesque.
Que l'on soit un robot ou un humain, on consomme au moins ces ressources en visitant une page web : De la bande passante montante, pour envoyer notre requête jusqu'au serveur. C'est normalement notre fournisseur d'accès à internet qui assume ce coût. De l'électricité, pour générer et envoyer la page correspondante. C'est l'hébergeur du site qui assume ce coût. De la bande passante descendante, pour transmettre le contenu de la page du serveur jusqu'à nous. C'est l'hébergeur du site qui assume ce coût. De l'électricité, pour traiter la page reçue. C'est nous qui assumons ce coût.
Pour l'hébergeur d'un site, recevoir et surtout répondre à ces requêtes est une énorme charge. Imaginez que la page demandée soit une page très longue, qui prenne deux secondes à générer, implique de solliciter une base de données… Ça peut tirer très fort sur le processeur, la mémoire et le disque du serveur. Les sites WordPress sont typiquement dans ce genre de cas. La taille du HTML renvoyé va être aussi très conséquente.
En comparaison, une page générée par Iocaine ne nécessite que quelques millisecondes maximum de temps CPU à générer, ne sollicite pas le disque, ne pèse quasiment rien. Ce n'est vraiment pas simple à comparer, mais si je devais le faire au doigt mouillé, je dirai qu'une page servie par Iocaine consomme 100 à 1 000 fois moins qu'une page d'un de mes sites WordPress.
Au moment où j'écris, Iocaine traite paisiblement 250 requêtes par seconde, et 75% du CPU est inutilisé (sachant que le serveur est aussi utilisé pour de vraies choses). Si le site WordPress devait servir ne serait-ce qu'un pourcent de ce traffic, je pense que le serveur serait déjà en train de tirer la langue.
Okay mais ce trafic n'existerait pas sans le labyrinthe, si ?
Peut-être que non. Peut-être que si.
Peut-être que demain, une personne gérant l'un des WordPress que j'héberge installe un plugin qui rajoute des milliers d'URLs, que les crawlers s'empresseront d'explorer (en mettant au passage mon serveur à genoux).
Peut-être que la semaine prochaine, un bot mal codé se vautre sur une page et invente des URLs absurde que personne n'irait visiter en combinant des filtres de recherche.
Peut-être que cet été j'ai besoin de mettre en ligne des photos de vacances, ou de déployer un service sans avoir à me poser toutes ces questions.
La trafic existait avant le labyrinthe. Il y avait moins de requêtes par seconde mais elles existaient et elles bouffaient des ressources. Ma charge serveur a largement diminué depuis que j'utilise iocaine, tout est plus stable. L'hébergeur paye le coût de la bande passante qui augmente, mais si j'avais moins de trafic et désactivai Iocaine, il payerait le coût de l'électricité. Dans tous les cas, la charge de ces robots d'indexation existe, on peut juste choisir de la répartir différemment.
Peut-on résoudre individuellement un problème collectif ?
Si je les bloquais directement, ils iraient voir ailleurs, chez des gens avec moins ou aucune possibilité de se défendre.
Les piéger dans un labyrinthe me permet, dans une certaine mesure de compliquer leur tâche et leur impact collectif. S'ils sont en train de crawler des milliards de pages chez moi pour un coût ridicule de mon côté, ils ne sont pas en train de faire la même chose sur le forum bien plus gourdmand en ressources de Bidule, le wiki de Machine ou la forge logicielle de Trucmuche.
C'est aussi pour ça que j'ai du mal avec les approches de type Anubis, qui consistent à bloquer le trafic, même si j'entends parfaitement qu'elles sont nécessaires ou les seules possibles dans plein de cas : c'est basiquement la même chose que barricader sa maison en sachant que les zombies vont aller attaquer ensuite la cabane mal protégée des voisins.
Plutôt que de barricader, est-ce qu'on creuserait pas des douves autour de chez nous, comme ça les zombies tombent dedans et ils font plus chier personne dans le village ?
Bloquer en bout de chaine ce trafic le déporte sur d'autres sites plus vulnérables, tout en augmentant progressivement la difficulté pour tout le monde de détecter les crawlers. C'est le même principe que les Captcha, qui deviennent de plus en plus faciles à contourner à mesure que les robots sont ajustés, donc de plus en plus chiantes à résoudre. C'est une approche individualiste. Et je dis ça sans jugement aucun : si votre serveur est sous l'eau évidemment que vous allez faire au plus vite et bloquer le trafic en question, c'est normal ! Mais ensuite ? C'est quoi le projet à long terme ?
À mon avis, piéger incite beaucoup moins les crawlers à se déguiser (ils ont l'impression d'avoir ce qu'ils veulent), tout en répartissant la charge de les gérer entre des acteurs qui peuvent le faire. C'est une manière de collectiviser le problème. C'est bien plus efficace à moyen et long terme, et socialement utile, si on a les ressources qui le permettent.
Et en bonus, pour peu que certaines de ces pages aboutissent dans des données d'entrainement, ça participe potentiellement à la déliquescence accélérée des modèles d'IA générative :D
