Le fichier robots.txt ne bloque qu’une chose : l’exploration de vos pages par un robot. Il ne contrôle ni ce qu’une intelligence artificielle fait ensuite du contenu qu’elle a lu, ni son entraînement, ni sa réutilisation dans une réponse générée. C’est exactement le malentendu que l’équipe Search Relations de Google a pris le temps de corriger le 21 octobre 2026, dans une clarification relayée dès le lendemain par Search Engine Journal : beaucoup de propriétaires de site croient encore pouvoir écrire une consigne en langage courant dans leur robots.txt pour tenir une IA à distance.
L’exemple donné par Gary Illyes, analyste chez Google, est volontairement caricatural : une ligne du type « ne pas explorer cette page secrète ». Un artisan ou une boutique en ligne qui ajouterait à son fichier robots.txt une phrase comme « merci de ne pas utiliser mon contenu pour entraîner une IA » croit poser une règle. Le fichier, lui, ne lit rien de tout cela.
Table des matières
Un parseur qui ne reconnaît que quatre mots-clés
Le format robots.txt n’accepte que quatre champs : user-agent, allow, disallow et sitemap. Les trois premiers viennent du standard RFC 9309, qui encadre le protocole depuis 2022 ; le quatrième est une extension non normative mais largement supportée, documentée par Google. Seules les lignes commençant par un dièse échappent à la règle : ce sont des commentaires, pas des instructions.
Toute ligne qui sort de ce format est silencieusement ignorée. Aucune alerte ne signale l’anomalie : la page continue d’être explorable comme si la ligne n’existait pas. Le RFC est d’ailleurs explicite sur la nature du mécanisme : il précise que ces règles ne constituent pas une forme d’autorisation d’accès, seulement une préférence que le robot est libre de respecter ou non. Un robot GPTBot ou Google-Extended qui applique correctement le standard lira donc votre phrase bien intentionnée exactement comme il lirait une ligne vide.
Ce que l’autorisation de crawl ne couvre pas
Le deuxième point, plus structurant, tient en une phrase d’Illyes citée mot pour mot par Search Engine Journal : robots.txt « doesn’t dictate what a system does with the data after it has already crawled it », autrement dit le fichier ne dit rien de ce qu’un système fait du contenu une fois qu’il l’a récupéré. RFC 9309 fixe quelles URL un robot a le droit de demander. Il ne fixe rien sur l’entraînement d’un modèle, la génération d’une réponse, ou tout autre usage fait du texte une fois aspiré.
Ne pas confondre avec la question du choix de la méthode pour bloquer un crawler IA, robots.txt ou blocage au niveau serveur : cette question porte sur comment empêcher l’exploration. Celle d’aujourd’hui porte sur ce qui se passe une fois que l’exploration a été autorisée, et c’est là que la confusion commence.
Google illustre lui-même cette séparation avec Google-Extended, le seul jeton documenté qui matérialise concrètement la distinction. Ce jeton contrôle si le contenu exploré par Google peut servir à entraîner les futurs modèles Gemini et à alimenter le grounding dans les Gemini Apps, sans toucher à l’inclusion dans Google Search ni au classement. Un site peut donc rester parfaitement indexé et visible sur Google tout en refusant que ses pages nourrissent l’entraînement de Gemini : les deux leviers sont indépendants, même chez l’opérateur qui écrit le standard.
Il n’existe pas de directive générique « IA » dans un robots.txt. Bloquer un crawler précis suppose de cibler explicitement son propre jeton user-agent, GPTBot, Google-Extended, ou un autre : chacun de ces jetons est décidé unilatéralement par l’opérateur qui le fait respecter, sans garantie qu’un nouvel entrant en lance un et s’y tienne. Un robots.txt qui ne liste que Google-Extended n’a jamais empêché un autre fournisseur de passer.
Un brouillon à l’IETF, rien de plus pour l’instant
À l’IETF, l’organisme qui rédige les standards techniques du web, le groupe de travail aipref propose d’ajouter une règle Content-Usage au format robots.txt, distincte des règles allow et disallow : celles-ci continueraient de décider ce qui est explorable, tandis que Content-Usage porterait la préférence d’usage, entraînement IA compris, sur les chemins déjà autorisés au crawl. Le document n’en est qu’à sa cinquième révision, encore classé comme brouillon de groupe de travail, sans date d’adoption connue. C’est une piste en discussion, pas un standard qu’on peut implémenter aujourd’hui.
Ce qu’un responsable de site peut vérifier dès maintenant
Trois réflexes concrets suffisent pour un site de PME. D’abord, ouvrir son propre robots.txt et repérer toute ligne qui ressemble à une phrase plutôt qu’à l’un des quatre champs reconnus : une consigne en français ou en anglais glissée là par précaution ne sert à rien, et la retirer n’enlève aucune protection puisqu’elle n’en apportait pas.
Ensuite, comprendre qu’empêcher le crawl n’empêche pas forcément l’entraînement : un site qui bloque Googlebot via disallow bloque l’exploration Google tout court, y compris l’indexation, alors qu’un site qui veut seulement écarter l’entraînement Gemini sans perdre sa visibilité doit cibler Google-Extended spécifiquement. Ce sont deux décisions distinctes, chacune à régler séparément dans le fichier.
Enfin, accepter que la granularité réelle, aujourd’hui, passe par lister explicitement chaque user-agent qu’on veut restreindre, pas par une phrase d’intention. La seule façon fiable de refuser un crawler IA reste de connaître son nom exact et de l’écrire noir sur blanc, comme le détaille la page sur le réglage Cloudflare qui refuse l’entraînement IA sans perdre Google. Un fichier robots.txt bien tenu reste un outil utile : il n’a simplement jamais été conçu pour porter une intention, seulement une liste.
Crédits photo : Pixabay, Pixabay/blickpixel.
