La prolifération des robots d'IA avides de données et leurs pratiques d'exploration agressives soulèvent des défis majeurs pour les projets open source, déjà fragilisés par des ressources limitées. Les mesures défensives traditionnelles, comme le fichier robots.txt, s'avèrent inefficaces face à des robots d'indexations qui usurpent les agents utilisateurs, ignorent les restrictions ou exploitent des proxys résidentiels. Des solutions alternatives émergent, comme les systèmes de preuve de travail ou les pièges à contenu trompeur, mais elles présentent des inconvénients, notamment pour l'accessibilité ou l'expérience utilisateur.Pourtant, les discussions autour de ces enjeux révèlent des tensions plus profondes. D'un côté, les entreprises d'IA, accusées de prédation, semblent privilégier la collecte massive de données au détriment de la viabilité des infrastructures qu'elles exploitent. De l'autre, la communauté open source, en manque de leviers juridiques ou techniques, se retrouve contrainte à des mesures radicales (blocages géographiques, challenges computationnels). Certains suggèrent même d'empoisonner volontairement les données des crawlers, une approche certes créative mais potentiellement problématique sur le plan éthique et légal.
Ces stratégies reflètent une course aux armements inégale, où l'asymétrie des ressources entre les géants de l'IA et les mainteneurs open source aggrave les risques pour l'écosystème numérique. Si des initiatives collaboratives comme ai.robots.txt tentent d'apporter des réponses structurelles, l'absence d'engagement clair des acteurs industriels et de régulation adaptée laisse présager une escalade destructrice. L'enjeu dépasse la simple bande passante : il questionne la pérennité d'un internet ouvert, où le respect mutuel entre humains et machines semble se dissoudre dans l'urgence de l'innovation.
Le fichier robots.txt : régulateur des bots sur le web
Un fichier robots.txt constitue un ensemble d'instructions destinées aux bots, intégré aux sources de la majorité des sites web. Ces fichiers servent principalement à encadrer l'activité des bots bienveillants, notamment les robots d'indexation, les bots malveillants ayant tendance à ignorer ces directives.
Cette mécanique peut s'apparenter à un panneau "Règlement intérieur" dans un espace public : bien qu'incapable d'imposer physiquement son respect, il sera suivi par les usagers de bonne foi tandis que les autres s'exposeront à des sanctions. Techniquement, un bot représente un programme automatisé interagissant avec les sites web. On distingue deux catégories :
- Les bots bénéfiques, comme les robots d'indexation qui parcourent le web pour référencer le contenu dans les moteurs de recherche
- Les bots malveillants, conçus pour des activités nuisibles
Le fichier robots.txt permet notamment de :
- réguler l'activité des robots d'indexation ;
- prévenir la surcharge des serveurs web ;
- restreindre l'indexation des pages non destinées au public
Cette solution technique, bien que perfectible, reste essentielle pour maintenir un équilibre entre visibilité et contrôle dans l'écosystème web.
IA contre open source : la course aux armements qui menace l'internet libre
Le développeur Xe Iaso a été confronté à une crise majeure lorsque les robots d'indexation d'Amazon ont submergé son dépôt Git, provoquant des interruptions répétées de service. Malgré l'implémentation des protections standards comme la modification du fichier robots.txt, le blocage des agents utilisateurs connus et le filtrage des adresses IP suspectes, les crawlers d'IA ont continué à contourner ces mesures en utilisant des proxys résidentiels et en falsifiant leurs identifiants. Face à cette situation, Iaso a finalement opté pour une solution drastique en déployant son serveur derrière un VPN et en développant « Anubis », un système imposant aux visiteurs de résoudre un problème de calcul avant d'accéder au contenu. Dans un billet de blog intitulé « Un appel à l'aide désespéré », il a souligné l'inutilité des méthodes traditionnelles de blocage face à des robots qui masquent constamment leur origine et modifient leur comportement.
Ce cas illustre une problématique plus large affectant la communauté open source, où certains projets voient jusqu'à 97 % de leur trafic provenir de robots d'entreprises d'IA, selon un rapport de LibreNews. Cette situation équivaut à une attaque DDoS persistante, entraînant des surcoûts importants en bande passante, une instabilité des services et une pression accrue sur des mainteneurs déjà sursollicités. Plusieurs projets ont adopté des mesures extrêmes : Fedora Pagure a bloqué tout le trafic en provenance du Brésil, GNOME GitLab a implémenté le système Anubis avec des résultats montrant que 96,8% des requêtes étaient automatisées, et KDE a subi des interruptions de service causées par des crawleurs associés à Alibaba.
Envoyé par Kevin Fenzi
Le problème des collecteurs de données IA (je suppose qu'il s'agit bien d'eux) n'a fait que s'aggraver ces derniers temps. La semaine dernière, pagure.io en a particulièrement souffert. Nous avons bloqué plusieurs sous-réseaux, mais il est extrêmement difficile de tout filtrer sans affecter les vrais utilisateurs - et effectivement, nous avons involontairement bloqué quelques utilisateurs légitimes. Ces cas ont été rapidement résolus, mais restent préoccupants.
Après analyse, j'ai constaté que la majorité des requêtes problématiques provenaient du Brésil. En dernier recours, j'ai donc instauré un blocage complet de cette zone géographique, ce qui a permis de rétablir des performances normales. Je sais pertinemment que ce n'est qu'une solution temporaire - je compte lever cette restriction dès que le trafic anormal diminuera (ce qui devrait se produire une fois que les collecteurs réaliseront l'inutilité de leurs tentatives).
À plus long terme, nous devons absolument trouver une meilleure approche. J'aimerais pouvoir consacrer du temps à configurer mod_qos pour garantir un accès prioritaire aux réseaux essentiels tout en limitant les autres. En attendant, j'ai augmenté la capacité CPU de la machine virtuelle hébergeant pagure.io, ce qui a apporté une légère amélioration.
Après analyse, j'ai constaté que la majorité des requêtes problématiques provenaient du Brésil. En dernier recours, j'ai donc instauré un blocage complet de cette zone géographique, ce qui a permis de rétablir des performances normales. Je sais pertinemment que ce n'est qu'une solution temporaire - je compte lever cette restriction dès que le trafic anormal diminuera (ce qui devrait se produire une fois que les collecteurs réaliseront l'inutilité de leurs tentatives).
À plus long terme, nous devons absolument trouver une meilleure approche. J'aimerais pouvoir consacrer du temps à configurer mod_qos pour garantir un accès prioritaire aux réseaux essentiels tout en limitant les autres. En attendant, j'ai augmenté la capacité CPU de la machine virtuelle hébergeant pagure.io, ce qui a apporté une légère amélioration.
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.