Les robots IA respectent-ils vraiment le robots.txt ?
Chaque grande entreprise IA opérant un robot web déclare publiquement que son robot respecte le robots.txt. OpenAI affirme que GPTBot suit les règles Disallow. Anthropic dit la même chose de ClaudeBot. Common Crawl, Google, Meta et les autres font des engagements similaires.
Mais énoncer une politique et l'appliquer de manière consistante sont deux choses distinctes. La question n'est pas de savoir si les entreprises IA ont l'intention de respecter le robots.txt — c'est de savoir si, en pratique, le protocole robots.txt est suffisant pour gouverner la façon dont les systèmes IA interagissent avec le contenu.
Ce pour quoi le robots.txt a été conçu
Le standard robots.txt a été créé en 1994 comme convention volontaire pour les robots web. Le mot clé est volontaire. Rien dans la spécification technique n'impose la conformité. Un robot lit le fichier robots.txt, analyse les règles, puis décide s'il les suit. Il n'y a pas d'authentification, pas de vérification et aucun mécanisme de pénalité intégré au protocole.
Pendant deux décennies, ça a fonctionné raisonnablement bien parce que l'écosystème des robots était restreint et que les opérateurs avaient de fortes incitations à se conformer. Google, Bing et Yahoo avaient besoin de la confiance des propriétaires de sites pour construire des index de recherche utiles. Un moteur qui ignorait le robots.txt s'exposait à des répercussions, des défis juridiques et une perte de coopération des éditeurs.
Le paysage de la conformité en 2026
Avec les robots IA, la structure d'incitation est différente. Les entreprises IA ont besoin de données d'entrainement à grande échelle. Le web est la source la plus vaste et la plus accessible de ces données. La valeur de la conformité est réputationnelle, pas opérationnelle — un modèle IA entrainé sur des données collectées en violation du robots.txt fonctionne aussi bien qu'un modèle entrainé sur des données autorisées.
Cela dit, les principaux robots IA des entreprises connues respectent généralement le robots.txt quand les règles sont correctement configurées. Des tests indépendants menés par des chercheurs SEO et des opérateurs de sites ont confirmé que GPTBot, ClaudeBot et Google-Extended cessent de crawler les chemins explicitement interdits.
Les lacunes de conformité tendent à apparaitre de façons moins visibles :
La collecte indirecte. Même si on bloque GPTBot, le contenu peut déjà exister dans les archives de Common Crawl, des jeux de données académiques ou des services de scraping tiers que les entreprises IA achètent sous licence. Le blocage robots.txt empêche le crawl direct mais ne retire pas rétroactivement les données des ensembles d'entrainement existants.
Les agents non déclarés. Toutes les requêtes liées à l'IA ne s'identifient pas honnêtement. Certains robots utilisent des chaines d'agent génériques ou trompeuses, rendant impossible l'application de règles ciblées. Si un robot ne s'annonce pas comme robot IA, les règles robots.txt pour les agents IA spécifiques n'ont aucun effet.
Le rendu vs la récupération. Certains systèmes IA récupèrent le contenu des pages sans exécuter le JavaScript, ce qui signifie que le contenu dynamique et les directives injectées côté client (comme les balises meta robots générées par JavaScript) peuvent ne jamais être vus. Le robots.txt, qui est récupéré comme fichier texte statique, reste le signal de gouvernance le plus fiablement lu précisément parce qu'il ne dépend pas du rendu.
Ce que l'observation empirique montre
Les données d'observation provenant de sites WordPress en production utilisant des outils de surveillance de gouvernance dessinent un portrait révélateur. Sur les sites qui déploient des piles complètes de fichiers de gouvernance — robots.txt, ai.txt, ai-manifest.json et artéfacts connexes — la majorité des robots IA déclarés suivent les règles Disallow du robots.txt pour les requêtes directes de pages.
Toutefois, le taux de conformité global aux protocoles de découverte de gouvernance est significativement plus faible. Les fichiers au-delà du robots.txt (comme ai.txt ou les fichiers de politique lisibles par machine) affichent des taux de lecture beaucoup plus bas. Cela suggère que si les robots IA vérifient le robots.txt comme base de référence, la plupart ne cherchent pas ou ne traitent pas actuellement les signaux de gouvernance supplémentaires.
L'implication pratique : le robots.txt est le plancher de la gouvernance IA, pas le plafond. C'est le seul fichier dont on peut compter qu'il sera lu par la plupart des robots IA. Tout ce qui va au-delà — politiques d'utilisation, signaux d'exclusion d'entrainement, artéfacts de gouvernance structurés — fournit de la documentation supplémentaire sur l'intention du propriétaire mais dépend de l'adoption future de l'écosystème pour devenir réellement efficace.
Le déficit d'application
Le défi central du robots.txt face aux robots IA est ce qu'on pourrait appeler le déficit d'application. Les propriétaires de sites peuvent déclarer leurs préférences, mais ils ne peuvent pas vérifier la conformité de manière indépendante. Les journaux du serveur montrent quand un robot connu fait une requête, mais ils ne peuvent pas montrer :
- Si le contenu a été utilisé pour l'entrainement.
- Si le contenu a été récupéré par un tiers qui l'avait déjà scrapé.
- Si le robot opère sous une chaine d'agent qu'on ne reconnait pas.
Ce n'est pas un défaut du robots.txt en particulier. C'est une limitation structurelle de tout mécanisme de gouvernance volontaire et unilatéral. Le propriétaire du site publie des règles ; l'opérateur du robot décide s'il les suit. Il n'y a pas de tiers neutre qui vérifie la conformité.
Ce que ça signifie pour les propriétaires de sites
La conclusion pragmatique est : le robots.txt est nécessaire mais pas suffisant.
Il est nécessaire parce que c'est le fichier de gouvernance le plus largement lu et le plus consistamment respecté du web. Le configurer correctement pour les robots IA est l'action la plus impactante qu'on puisse entreprendre.
Il n'est pas suffisant parce qu'il ne peut pas empêcher toutes les formes d'extraction de contenu, ne peut pas retirer rétroactivement du contenu des ensembles d'entrainement, et ne peut pas gouverner les robots qui ne s'identifient pas honnêtement.
Pour les propriétaires de sites WordPress, l'approche pratique est en couches :
- Configurer le robots.txt précisément. Utiliser des blocs User-agent spécifiques pour chaque robot IA qu'on veut autoriser ou refuser. Ne pas se fier à une règle générale
User-agent: *. - Surveiller les journaux du serveur. Savoir quels robots visitent réellement le site et à quelle fréquence. Les agents inattendus méritent investigation.
- Ajouter des signaux de gouvernance supplémentaires. Des fichiers comme ai.txt et des documents de politique structurés ne sont peut-être pas largement lus aujourd'hui, mais ils établissent l'intention documentée — ce qui compte pour les arguments juridiques et éthiques.
- Accepter la limitation. Aucun fichier unique ne peut imposer une conformité parfaite à l'ensemble de l'écosystème IA. L'objectif est de rendre sa position claire, vérifiable et défendable — pas d'atteindre un contrôle absolu.
Better Robots.txt adresse les deux premières couches directement et fournit la fondation pour la troisième à travers son module de gouvernance et ses paramètres de politique d'utilisation IA.