Connexion
Abonnez-vous

Les crawlers des IA deviennent un sérieux problème pour le web, même pour Wikimédia

DDoS généré pour IA

Les crawlers des IA deviennent un sérieux problème pour le web, même pour Wikimédia

Pour entrainer et tenir à jour leurs intelligences artificielles, les crawlers des entreprises d'IA parcourent le web en permanence et sont suspectés de ne pas respecter les fameux robots.txt censés permettre leur blocage. Leur activité va jusqu'à mettre en péril des sites web de projets de logiciels libres ou toucher fortement les activités de Wikimédia.

Le 03 avril à 17h06

Les entreprises qui ont mis en place des IA génératives comme OpenAI, Meta, Anthropic, Mistral ou encore Amazon, Google et Microsoft ont besoin d'indexer des contenus sur le web en permanence pour entrainer leurs grands modèles de langage (LLM), récupérer les nouvelles informations afin que leurs outils soient capables de répondre aux demandes de leurs utilisateurs.

Un trafic difficile à gérer, même pour la fondation Wikimédia

Mais en venant en permanence sur les sites web, ils ajoutent du trafic important à leur bande passante, au point de saturer certains. La fondation Wikimédia a publié un billet pour expliquer à quel point ces robots ont un impact sur ses projets : « Notre infrastructure est conçue pour supporter des pics soudains de trafic d'origine humaine lors d'événements très intéressants, mais le volume de trafic généré par les robots scrapeurs est sans précédent et présente des risques et des coûts croissants ».

En effet, ces entreprises récupèrent ces contenus à l'aide de « crawlers », des robots d'indexation, ou plutôt ici de récupération de données. OpenAI a officiellement donné le nom de son robot, GPTBot, en aout 2023, suscitant immédiatement la réaction de RSF qui a rapidement invité « tous les médias à configurer leurs sites pour éviter qu’OpenAI ne récupère leur contenu gratuitement ». C'est ce qu'ont fait beaucoup de sites web.

Un blocage pas si efficace

Pour cela, il « suffit » de lister dans le fichier robots.txt de son site les robots dont on ne veut pas. Mais, comme l'ont démontré récemment des chercheuses, certains robots récupèrent des informations de sites qui, pourtant, les ont ajoutés dans leurs listes. De plus, l'outil d'IA générative de Microsoft, Copilot, utilise BingBot, le robot d'indexation du moteur de recherche de l'entreprise. Un site qui voudrait bloquer l'IA de Microsoft ne serait plus indexé dans le moteur de recherche Bing.

Et, comme on l'a vu récemment, certains sites peuvent être visités 2 millions de fois par un bot en un trimestre. Il est déjà difficile pour des infrastructures comme celles de la Fondation Wikimédia de faire face à cet afflux « artificiel » pour gérer sa bande passante, mais ça l'est encore plus pour des projets qui ont moins de moyens.

Certains expriment leur ras-le-bol

Plusieurs responsables de projets de logiciels libres se sont plaints du problème, expliquait récemment ArsTechnica. Le développeur Xe Iaso a, par exemple, exprimé son ras-le-bol en janvier face au crawler d'Amazon : « À la personne qui gère AmazonBot, veuillez ajouter git.xeserv.us à votre liste de domaines bloqués. Si vous connaissez quelqu'un chez Amazon, merci de lui transmettre ce message et de lui demander de le transmettre à l'équipe d'AmazonBot » alors qu'il avait radicalement bloqué tous les robots dans son fichier robots.txt.

TheLibre.News a aussi recensé plusieurs infrastructures de logiciels libres touchés par ce problème. Le GitLab des développeurs de KDE a, par exemple, été touché par des crawlers ayant des IP détenues par Alibaba, ce qui l'a rendu temporairement inaccessible. L'un des administrateurs systèmes du projet Pagure de Fedora a, lui aussi, constaté un afflux massif de robots de récupération de données venant du Brésil. Il explique avoir décidé de bloquer temporairement toutes les IP brésiliennes pour en venir à bout tout en sachant bien que ce n'était pas une solution de long terme.

Gergely Orosz, qui publie la newsletter The Pragmatic Engineer, explique sur LinkedIn que le site d'un de ses projets personnels qui déclinait a reçu récemment un trafic important « lorsque le crawler AI de Meta et d'autres bots comme Imagesiftbot ont commencé à crawler le site sans réfléchir : ça a poussé le trafic à plus de 700Go par mois » alors qu'il était aux alentours de 100Go par mois un peu avant.

« Le site est hébergé sur Render où 500Go/mois sont inclus, au-delà c'est 30 $ pour 100Go. Ce mois-ci, je paie donc 90 $ pour l'entrainement de ces LLM », commente-t-il. Et lui aussi pointe que « l'ironie est que les robots - y compris Meta !- ignorent manifestement le fichier robots.txt du site qui leur dit de "s'il vous plait, restez à l'écart" ».

Drew DeVault, le fondateur de la plateforme d'outils open source Source Hut, a publié un billet de blog le 17 mars dernier demandant aux entreprises d'IA génératives d' « arrêter d'externaliser [leur] coûts directement sur [lui] ». « Au lieu de travailler sur nos priorités à SourceHut, j'ai passé entre 20 et 100 % de mon temps à atténuer les crawlers LLM hyper-agressifs », s'y lamente-t-il. Il explique que Source Hut subit des « dizaines de brèves pannes par semaine » et qu'il doit chercher tous les jours de nouvelles solutions pour ne pas voir la situation empirer. Le même jour, son entreprise expliquait que des crawlers de LLM continuaient à provoquer un DDoS sur SourceHut.

Des solutions pour piéger les crawlers d'IA

Elle expliquait avoir décidé de déployer Anubis pour essayer de bloquer les bots des entreprises d'IA. « Ce logiciel présente à certains utilisateurs un défi de preuve de travail qui est résolu par le navigateur de l'utilisateur à l'aide de JavaScript », explique SourceHut. C'est en fait une solution qu'a développée Xe Iaso après avoir publié son ras-le-bol.

D'autres solutions commencent à être développées, notamment en essayant de piéger les IA dans un labyrinthe de liens. Nepenthes, par exemple. Sa documentation explique que le logiciel « fonctionne en générant des séquences infinies de pages, chacune contenant des dizaines de liens, qui retournent simplement dans un piège ». Nepenthes ajoute des petits détails comme un délai ou une fausse apparence de fichiers statiques pour tromper le crawler.

De son côté, Cloudflare a aussi pensé à une solution de labyrinthe, explique-t-elle dans un billet de blog. Celle-ci « utilise du contenu généré par l'IA pour ralentir, embrouiller et gaspiller les ressources des AI Crawlers et d'autres robots qui ne respectent pas les directives "no crawl" ». L'entreprise, connue pour vendre des solutions pour augmenter la sécurité et les performances des sites internet, propose pour le moment à tous ses utilisateurs la possibilité d'activer gratuitement cette fonctionnalité.

Commentaires (50)

votre avatar
Cloudflare ne propose pas aux bots IA de résoudre un casse tête comme parfois il le fait aux humains ?
votre avatar
Il y aurait certainement une solution en jouant sur les conditions d’utilisation des sites :
* Comme ils en ont généralement le droit, les propriétaires modifient ces conditions d’utilisation pour préciser que les robots servant à l’IA génératives voient les vues facturées à 1€ la page
* Les conditions sont réputées acceptées par une simple visite
* Au bout d’un mois, on envoie la facture de quelques millions d’euros à OpenAI et leurs petits copains parasites
* Profits !!!
votre avatar
Je pensais que les données de wiki(p)(m)édia étaient téléchargeables sous la forme d'une grosse archive.
Ca a changé ?
votre avatar
Ça a l'air de toujours exister.
En plus, c'est du torrent, donc ça doit les soulager côté bande passante.
votre avatar
Le bot OpenAI est peut être le plus respectueux au niveau des ressources parmi ces "nouveaux" Crawler.
Celui de Bytedance le plus merdique, bloqué au niveau des FW chez moi.

Facebook aussi abuse de manière hallucinante parfois.
votre avatar
Avec Cloudflare si vous avez une licence entreprise vous avez accès au botscore
Vous le passer à plus de 80 et les ia n'entrent plus...
votre avatar
Je ne comprends pas quelque chose. Comment Anubis peut être une contre-mesure ? S'il repose sur une preuve de travail (si j'ai bien compris le code c'est du calcul récursif de SHA) en quoi ça limite les crawlers ?

De ma compréhension, le crawlers pourrait bien effectuer cette opération mais à part ralentir la pression sur le site je ne vois pas trop ce que ça peut changer, pusique in fine les données se feront quand même aspirer. Si il y a peu de crawlers ok ça peut aider mais si le nombres devient conséquent ça ne va pas forcément changer grand-chose, non ?
votre avatar
Le truc, c'est que les Crawlers peuvent être sacrément irrespectueux (du genre consulter toutes les pages d'un site, toutes les 6h, sans aucune limite dans le rate et donc balancer 50req/s par exemple). Sur un site comme une forge logicielle, où il y a énormément de lien et où certaines pages peuvent mobiliser un certains nombres de ressources pour être afficher, c'est la cata.

La preuve de travail nécessite un calcul, prend du temps et nécessite javascript. Beaucoup de crawler n'ont pas javascript. Pour ceux qui l'ont, ils ne pourront plus envoyer 30000req/s, car le CPU va mouliner pour résoudre la preuve de travail.

Donc le but de la preuve de travail n'est pas d'empêcher, mais d'éviter un afflux de requêtes abusives, avec un impact mineur pour les utilisateurs "humains".
votre avatar
J'ai des crawlers qui ont littéralement DDOS mon serveur 2 fois par jour, j'ai bloqué des plages IP énormes.
Ça m'a demandé pas mal de boulot de trouver des solutions pour mon petit serveur :
Apache High CPU
J'ai fait ce script pour pouvoir identifier les IP qui posaient problème et éviter que le serveur ne tombe quand je suis dessus.
Aujourd'hui, j'aimerais bien bloquer tout Amazon Crawler qui représente plus de 80% de mon trafique. Mais il y a beaucoup trop d'IP...
votre avatar
Il n'y a pas trop d'IP. Juste met les dans un set Ipset et surtout pas directement dans Iptable. Au delà de 2 ou 3000 règles les perf Netfilter deviennent désastreuses. J'ai des centaines de milliers d'IP bloquées.
votre avatar
J'ai essayé avec Ipset, mais il me dit qu'il y a trop d'IP. Ou alors il y a un truc que j'ai pas compris.
votre avatar
Si ce sont des IPs individuelles :
ipset create NOM_DU_SET hash:ip
Pour les rzo :
ipset create NOM_DU_SET hash:net
Si tu veux mettre un temps de ban en plus :
ipset create NOM_DU_SET hash:ip timeout 3600
Les commandes ci-dessus permettent de mettre 65536 lignes (IPs). Au delà tu as 2 solutions :
1 - créer d'autre set (ce que je fait)
2 - Définir le nombre max d'éléments avec l'option "maxelem"
ipset create NOM_DU_SET hash:ip maxelem 500000
Ipset utilise la RAM mais si tu en as un peu cela devrait pas être un pb.
votre avatar
Je me demandais déjà si en fait les LLM était donc transformés en moteurs de recherches scrapeur du web plutot que tournant localement sur une infra dédiée. En gros on est sur des "simples" requêteurs de recherche à chaque prompt et le robot scrapeur va gentillement chercher l'info en ligne plutot que de la générer à partir de ce qu'il a à sa disposition.
Imaginez les coup en datacenter et en bande passante si on reste dans ce mode de fonctionnement... c'est juste fou de laisser perdurer ce mécanisme.
Alors oui pour le end-user c'est top d'avoir un "google 2.0" mais derrière pour la consommation pour savoir combien d'oeuf mettre pour sa pâte à crêpes...
votre avatar
Bin a priori aucun humain ne cherchera à accéder au fichier robots.txt donc pourquoi les sites qui n'en veulent pas ne vont pas directement bloquer toute IP qui voudrait y accéder ?
Ça me semble si simple, il y a peut-être un truc auquel je n'ai pas tout compris ? :keskidit:
votre avatar
quel intérêt pour les crawlers qui ignorent le robot.txt d'aller voir ce que contient le robot.txt ?
votre avatar
Et bien pourtant c'est la cas de quelques un (Facebook par exemple).
D'autre comme Bytespider (Bytedance) ne prennent même pas le peine de regarder robots.txt
votre avatar
Sur le site d'une asso à laquelle j'appartiens, on s'est soudainement mis à recevoir plein de messages de notre hébergeur pour nous dire qu'on dépassait les limites raisonnables du service et qu'on était mis en quarantaine.

Au début je comprenais pas du tout pourquoi, ensuite j'ai vu qu'il y avait un nombre hallucinant de requêtes (plus d'un million par jour) provenant du robot d'Anthropic. Vu les logs, il s'est justement perdu dans un labyrinthe de liens dont il n'arrivait pas à se sortir...
votre avatar
Il est beau le coût écologique des IA, difficile d'entendre qu'il faudrait être raisonnable sur son forfait data mobile avec ça...
votre avatar
Sur un petit serveur où j'ai installé la majorité de mes sites, Claude a été tellement BOURRIN qu'il m'a DDOS, obligé de l'interdire (ainsi que d'autres) via des règles NGinX 😅
votre avatar
Je serais intéressé par les ranges à bloquer. C'est documenté quelque part ?
votre avatar
Ce ne sont pas des ranges IP mais des user-agent. Étonnamment, ça fonctionne plutôt bien !

Je me suis aidé de https://darkvisitors.com/agents et ce que j'ai fais :

- Dans chaque fichier de conf nginx pour mes sites (/etc/nginx/sites-available/), j'ai ajouté

include /etc/nginx/baduseragents.conf;

- Dans le fichier /etc/nginx/baduseragents.conf j'ai mis

if ($http_user_agent ~ (AI2Bot|Applebot-Extended|Bytespider|CCBot|ClaudeBot|cohere-training-data-crawler|Diffbot|FacebookBot|Google-Extended|GPTBot|Meta-ExternalAgent|omgili|PanguBot|Timpibot|anthropic-ai|Claude-Web|cohere-ai)) {
return 418;
}*

Et ça semble fonctionner. En plus avec l'erreur 418 je peux voir les essais des bots :)
votre avatar
Répondre 418 n'est pas approprié.

Plus sérieusement, pourquoi ne pas répondre par un code d'erreur :
429 Too Many Requests
410 Gone
402 Payment Required

Le premier me semble le plus adapté et devrait faire comprendre aux humains qui le liront le problème.
Le second pour espérer qu'on arrête de demander cette ressource.
Le dernier pour rester dans la blague mais en conformité avec le protocole HTTP.
votre avatar
Merci !
votre avatar
Naivement, j'aurai fait pareil en testant le user agent ou l'IP, ou tout autre information sur le "visiteur". Et en mode plus méchant, si jamais il regardait aussi le contenu des fichiers (dont zip), je l'aurai fait pointer vers un zip bomb réservé aux Crawler qui ne respectent rien.
votre avatar
Je suis certes naif, mais le DDOS est puni par la loi. Pourquoi personne ne les attaques ? (Bon la peine financière est dérisoire)
En France, l'attaque par déni de service est punie pénalement à l'article 323-2 du Code Pénal : « Le fait d'entraver ou de fausser le fonctionnement d'un système de traitement automatisé de données est puni de cinq ans d'emprisonnement et de 75 000 euros d'amende »
votre avatar
Déjà, il faudrait que la loi française puisse s'appliquer, donc que l'une des deux conditions au moins soient remplies :
- que le service perturbé soit français
- que le service à l'origine de la perturbation soit français

Ensuite, la difficulté réside que si dans les faits, cela peut effectivement perturber des services, ce ne sont pas des attaques DDOS à proprement parlé, dans le sens où ce n'est pas l'intention première et que ce n'est pas une volonté propre (c'est même contre leur intérêt puisque si le service coule, les crawlers ne peuvent plus récupérer d'info !)

Je pense que le gros soucis derrière tout ça, c'est que les crawlers sont mal foutus. C'est difficile d'en faire un "respectueux" et de ne pas tomber dans une suite infinie de liens, à cause de différents pièges comme les query parameter. Et des sites comme les forges logicielles regorgent de ce genre de piège.

Les crawlers des moteurs de recherche ont tout intérêt à faire attention et à éviter ces pièges, pour éviter de référencer des données non pertinente (comme les diff entre 2 commits d'il y a 10 ans).

Pas certains que les crawlers d'entrainement d'IA fasse tout cela. Ils se contentent très certainement de crawler le web, de naviguer de lien en lien, de mettre le contenu pertinent lorsqu'il y en a un de trouver, et de continuer ainsi. Je ne serais pas étonné que la plupart des crawlers d'IA soient écrit par des spécialistes en IA (plus à même de juger de la "pertinence" des contenus), donc des personnes souvent peut sensibles à la mécanique des pièges des liens...
votre avatar
Je pense que le gros soucis derrière tout ça, c'est que les crawlers sont mal foutus. C'est difficile d'en faire un "respectueux" et de ne pas tomber dans une suite infinie de liens,
Moi ça me semble simple de ne pas balancer 30 req/s sur des ressources dynamique. C'est de la mauvaise fois évidentes de leur part.
Ils sont dans une course aux données pour leur entraînement et on laissé tomber toutes les règles de respects autrefois appliquées (encore heureux, ils n'usurpent pas encore leurs user agent)
votre avatar
Limiter le nombre de requêtes par seconde, c'est la part "facile" pour UNE instance d'un crawler. Mais sur quel critère tu décides que c'est pertinent de le faire ? On applique le même taux pour Wikipédia ? Github ? etc.

Déjà que pour un site comme Wikipédia (60 millions d'articles), à ce rythme là, il faut un bon mois pour crawler une fois chaque article (juste les articles, sans prendre les différentes versions, les discussions, etc.).

C'est facile de se dire que limiter un site en particulier, c'est faisable. Mais appliquer la même règle sur tous les sites ne marchera pas.

De même, comment identifier les ressources qui sont dynamiques de celles qui ne le sont pas ? A part utiliser la recommandation de la durée du cache renvoyé par un serveur, ça me parait compliqué.

Mais là encore, il faut tenir une base à jour, et une base commune (= partagée par tous les crawlers d'une même entité).

Je ne dis pas que ce n'est pas faisable techniquement (ça l'est). Je dis que c'est juste loin d'être trivial et qu'il est beaucoup plus facile aujourd'hui de faire un crawler simple, et de le lancer x fois sur 42000 machines que de faire un crawler "respectueux".

Et personnellement, je ne suis guère étonné de la situation actuelle, car je pense que la plupart de ceux qui ont fait les crawlers pour entrainer leur IA sont les spécialistes IA, qui ne pensent pas du tout à ce genre de considérations, simplement parce qu'ils ne sont pas "au courant". Cela ne veut pas dire que j'approuve ce comportement (loin de là même, qu'on soit bien d'accord). J'essaie juste de comprendre comment on en est arrivé là.

Pour terminer, ça me parait juste difficile de comparer le crawler d'une IA à celui d'un crawler d'un moteur de recherche, où là, c'est leur coeur de métier depuis des années, avec la détection de contenu dupliqué, traduit, etc.
votre avatar
Bah Gogole et MSN savent très bien le faire.
Évidement si le site à 250K pages le crawl va être plus rapide.
Sur un site donné qui disons une centaines de pages les bot de moteurs de recherche font le travail correctement. Certains bots AI font un travail dégueulasse (genre je requête 10 fois la même page dans l'heure voir la minute).
De même, comment identifier les ressources qui sont dynamiques de celles qui ne le sont pas ?
Bah... Déjà qu'il commence avec les extensions (c'est simple ça). Servir un .jpg ça n'a rien à voir
avec une page qui peut faire des centaines de requêtes en BDD + le travail de PHP.

J'ai une liste de 15K IP utilisé par Bytedance, pour moi c'est une technique d’évasion.

Quand tu passes une bonne parti de ton temps à voir pourquoi les ressources sont saturé c'est épuisant.
votre avatar
Bah Gogole et MSN savent très bien le faire.
Oui, mais c'est le fruit d'années d'expérience et d'améliorations. C'est ce qu'il essaie de t'expliquer.
votre avatar
Merci ! Au moins une personne qui aura compris le sens de mon propos :)
votre avatar
Les gars j'ai bien compris (notez que je suis agacé par ces bots, pas par vous :) ).

Ce n'est peut être pas une tâche si facile que ça pour une petite boite...
Mais ces groupes on tous d'énormes ressources humaines et techniques et je reste persuadé que c'est volontaire -> course à celui qui aura le plus de données d’entraînement.
votre avatar
Pas vraiment, non. Aussi loin que je me souvienne (ça remonte à Altavista), le trafic des bots des moteurs de recherche n'a jamais posé problème. D'ailleurs, à quoi ça sert de visiter le même site toutes les 6h ?
votre avatar
D'ailleurs, à quoi ça sert de visiter le même site toutes les 6h ?
À indexer au plus vite les articles de next.ink (et des autres sites d'actualité) ?

Plus sérieusement, si tu penses que le Web n'a pas très fortement évolué entre l'époque d'Altavista et maintenant et qu'il n'a pas fallu adapter très fortement la technique des bots d'indexation sur un web de plus en plus dynamique, tu as raté quelque chose à l'évolution du Web.
votre avatar
Pour un moteur de recherche, je vois l'intérêt d'être réactif, mais quand tu es un ChatGPT qui connaît le monde jusqu'en décembre 2023, à quoi ça sert ? Ils ne refont pas l'apprentissage toutes les 6h que je sache.

Ça semble d'autant plus stupide qu'être une IA bienveillante dans son crawl, ça permet d'être moins bloqué, donc d'amasser plus de connaissance, d'avoir une meilleure réputation, et in fine de faire plus de pognon.
votre avatar
Pour un moteur de recherche, je vois l'intérêt d'être réactif, mais quand tu es un ChatGPT qui connaît le monde jusqu'en décembre 2023, à quoi ça sert ? Ils ne refont pas l'apprentissage toutes les 6h que je sache.
Outre la création de dataset, les bots en question sont aussi ceux de SearchGPT (par exemple) et la recherche assistée par IA. Dans la mesure où elle fait du RAG, je pense qu'ils vont avoir tendance à crawl à tout va pour indexer et mettre les données dans des bases vectorielles afin d'aider le modèle à produire des réponses moins datées.
votre avatar
tu as l'air de dire que c'est un souci technique. Je suis persuadé que c'est faux, qu'ils veulent juste etre les premiers et piller avant que les parades surgissent. Je pense qu'il n'y a absolument aucune morale, juste une course de dératé pour avoir un hypothétique avantage a cas où.
Toutes les barrières éthiques, déjà bien fragiles, semblent céder depuis que l'idiocratie est au pouvoir (mais là, je disgresse un peu :D)
votre avatar
Non. Je dis que les choses n'ont pas forcément été faite de manière malveillante. Faire "techniquement" un crawler "responsable", c'est compliqué (bien plus qu'on ne pourrait le croire).

Et si cela n'a pas été fait, je penche plus pour un manque initial de compétence qu'une réelle volonté de nuire ou d'être les premiers.

Par contre, le problème est maintenant quand même bien connu depuis des mois. Le fait que cela ne change pas, ça, c'est inexcusable.
votre avatar
Non. Je dis que les choses n'ont pas forcément été faite de manière malveillante. Faire "techniquement" un crawler "responsable", c'est compliqué (bien plus qu'on ne pourrait le croire).
Quand tu lèves pls dizaines de milliards par mois, tu peux peut être te payer quelques scientifiques pour passer une ou deux semaines à faire une revue de l'état de l'art sur le sujet et appliquer le dit état de l'art à leurs crawlers. OpenAI, c'est pas 2 gars dans un garage.

C'est pas fait de manière malveillante, c'est fait par des fumistes qui ne se sont jamais préoccupés et ne se préoccuperont jamais des conséquences de leurs actes sur les autres (services et personnes). Ça correspond plus ou moins à la définition de a..hole.
votre avatar
Les géants de l'IA font de la merde, épisode n°gros beaucoup.
votre avatar
ce que je trouve fou, c'est qu'il n'existe toujours pas de liste AI sur iblocklist...
en alternative, il y a ça ou ça, mais c'est tout...
votre avatar
Oh, pas mal, merci pour le partage.

Après, le user-agent reste falsifiable, hélas. On est pas à l'abri de requêtes se faisant passer pour des navigateurs web classiques.
votre avatar
Merci pour le partage, je ne connaissais pas le scénario de Crowdsec.

Je ne pourrais certainement pas l'utiliser car depuis quelques semaines du trafic légitime provient des IA générative (ChatGPT).

Si ces outils viennent à remplacer les moteurs de recherche je ne peux pas me permettre d'avoir des pertes de chance pour les sites que j'héberge.
De plus le bot OpenAI ne crée pas de nuisance de ce que j'en constate.
votre avatar
@gg40 avec le blocage côté FW et @cthoumieux avec le test cloudflare, ont donné des exemples qui ont l'air, à mes yeux de novice du web, de fonctionner.
Et pourtant ça n'est pas cité dans l'article par les acteurs du web inpactés .

Est-ce par qu'il y a autant de solution que de crawler IA , et que ce serait trop long?
Est-ce parce que ce sont des techniques avec des effets moins importants que ceux de l'article ?

Ou autre chose?
Parce qu'une black-list des crawler IA à ajouter sur le FW, et hop, c'est plié, non?

Merci de vos avis.

La technique de @Muzikals a l'air bien aussi.
votre avatar
Je lutte avec mes moyens.
Je ne peux pas forcer mes clients à gérer leur DNS par Cloudflare avec une formules payante (et passer par un proxy américain en plus).
J'utilise le FW car cela permet de ne pas charger les serveurs. Les requêtes n'arrive même pas sur le service web (Apache dans mon cas)

J'ai des scripts bash qui tournent toutes les heures et maintiennent des listes d'IPs à bloquer.
votre avatar
A quand un crwaler doté d'une IA pour crawler comme un humain?
Au lieu d'aspirer Wikipedia comme des mal propres, il y a certains moyens de négocier des dumps. Bien plus efficace pour les 2 parties :(
votre avatar
oui, mais pourquoi s'emmerder à négocier alors qu'on peut tenter de le piller :D :( ?
votre avatar
Wikimedia serait joueur, en repérant des bot d'IA, ils pourraient ajouter des "ne pas" dans leurs articles :p
votre avatar
Et le LLMs.txt vous n’en parlez pas ? :D
votre avatar
Ça peut être intéressant d'en parler, mais c'est plus destiné aux outils IA qui cherchent de l'information à la demande d'un utilisateur qu'à la phase d'apprentissage des IA :
llms.txt information will often be used on demand when a user explicitly requests information about a topic, such as when including a coding library’s documentation in a project, or when asking a chat bot with search functionality for information. Our expectation is that llms.txt will mainly be useful for inference, i.e. at the time a user is seeking assistance, as opposed to for training. However, perhaps if llms.txt usage becomes widespread, future training runs could take advantage of the information in llms.txt files too.
Ce n'est pas conçu pour interdire l'utilisation d'un site par les IA. J'ai fait parcouru rapidement cette page, mais ça serait effectivement intéressant que Next approfondisse le sujet.

Les crawlers des IA deviennent un sérieux problème pour le web, même pour Wikimédia

  • Un trafic difficile à gérer, même pour la fondation Wikimédia

  • Un blocage pas si efficace

  • Certains expriment leur ras-le-bol

  • Des solutions pour piéger les crawlers d'IA

Fermer