Pourquoi robots.txt ne suffit plus pour les agents IA déclenchés par l’utilisateur
Le web moderne n’est plus visité uniquement par des crawlers classiques qui découvrent des pages pour la recherche.
Certaines machines construisent des index de recherche. D’autres collectent des données pour l’entraînement futur de modèles. D’autres récupèrent des pages pour soutenir la génération de réponses ou le grounding au moment de la requête. D’autres encore n’agissent que lorsqu’un humain leur demande. Et certaines sont vérifiées ou allowlistées au niveau du CDN ou du WAF.
Cela change la question de fond.
La question n’est plus seulement quels bots dois-je bloquer dans robots.txt ? La meilleure question devient quelle surface de contrôle correspond à quel type d’accès machine ?
Cette distinction compte parce que robots.txt reste fondamental, mais il a été conçu pour l’accès au crawl. Il n’a pas été conçu pour couvrir à lui seul tout le web agentique moderne.
robots.txt a été conçu pour le crawl, pas pour tous les usages machine
robots.txt reste la couche de base de la gouvernance publique du crawl.
C’est encore le premier fichier que la plupart des crawlers automatisés consultent. C’est encore la façon la plus portable d’autoriser ou d’interdire le crawl par chemin et par agent. C’est encore l’endroit le plus sûr pour exprimer une intention de crawl par catégorie.
Mais robots.txt ne répond qu’à une question précise :
Ce crawler peut-il récupérer cette URL ?
Il ne répond pas, à lui seul, à toutes les autres questions qui comptent désormais :
- comment les snippets ou aperçus de recherche doivent se comporter ;
- si le contenu peut être réutilisé pour l’entraînement ;
- si le contenu peut être injecté dans une réponse au moment de la requête ;
- si une récupération déclenchée par l’utilisateur doit être traitée comme un crawl automatique ;
- si un agent signé doit être autorisé via des contrôles d’infrastructure en temps réel.
Le problème en 2026 n’est donc pas que robots.txt est devenu inutile.
Le problème est qu’on lui demande souvent de résoudre des cas qui appartiennent à d’autres couches.
Les 4 familles d’accès machine qu’il faut séparer
Un modèle de gouvernance utile commence maintenant par la séparation d’au moins 4 familles d’accès machine.
1. Les crawlers de recherche
Ces crawlers servent la découverte, le re-crawl, l’indexation et le rafraîchissement pour des produits de recherche.
On y retrouve par exemple des bots de recherche classiques comme Googlebot et Applebot, ainsi que des bots orientés recherche comme OAI-SearchBot.
La question business principale est généralement la visibilité.
Voulez-vous que le site reste découvrable dans des produits de recherche capables de renvoyer du trafic ?
2. Les crawlers d’entraînement
Ces crawlers, ou parfois ces product tokens, concernent le développement futur de modèles, pas la découvrabilité en recherche.
On peut citer GPTBot, ClaudeBot, Google-Extended et Applebot-Extended.
La question principale n’est pas l’indexation. C’est l’usage aval du contenu.
Voulez-vous que votre contenu serve à entraîner ou améliorer de futurs systèmes génératifs ?
3. Les systèmes de réponse ou de récupération
Ces systèmes existent pour soutenir les réponses, le grounding, l’optimisation de recherche, ou la récupération quasi temps réel.
Ils peuvent fonctionner comme des crawlers, comme des bots de récupération, ou comme des systèmes hybrides mêlant indexation et récupération à la demande.
La vraie question n’est plus seulement la visibilité. C’est la manière dont votre contenu est consommé dans les réponses.
Voulez-vous une présence sous forme de lien et d’extrait, une injection dans le contexte du modèle, ou ni l’un ni l’autre ?
4. Les agents déclenchés par l’utilisateur ou les agents signés
C’est là que l’ancien modèle mental casse le plus souvent.
Certaines requêtes sont initiées par des utilisateurs. Certaines sont authentifiées ou vérifiées cryptographiquement par des fournisseurs d’infrastructure. Certaines sont conçues pour naviguer sur le web et effectuer des actions, pas seulement pour récupérer des pages en vue d’une indexation.
Dans ces cas, robots.txt cesse souvent d’être le levier principal.
Même fournisseur, plusieurs surfaces de contrôle
L’une des erreurs les plus coûteuses en gouvernance consiste à penser qu’un fournisseur équivaut à un seul crawler et à un seul point de contrôle.
Ce n’est plus vrai.
| Fournisseur | Surface | Rôle principal | Question de contrôle principale |
|---|---|---|---|
Googlebot | Crawl de recherche et accès Search | Est-ce que je veux le crawl et l’indexation Google Search ? | |
Google-Extended | Entraînement et certains usages de grounding hors Search | Est-ce que j’autorise cette réutilisation dans ces systèmes ? | |
Google-Agent | Trafic agentique déclenché par l’utilisateur | Est-ce un sujet de simple crawl policy, ou faut-il de l’infrastructure ? | |
| OpenAI | OAI-SearchBot | Visibilité dans les fonctions de recherche ChatGPT | Est-ce que je veux apparaitre dans cette recherche ? |
| OpenAI | GPTBot | Collecte pour entraînement | Est-ce que j’autorise l’entraînement ? |
| OpenAI | ChatGPT-User | Visites déclenchées par l’utilisateur | Est-ce que j’autorise cette récupération à la demande ? |
| OpenAI | ChatGPT agent | Trafic signé et allowlistable | Ai-je besoin d’allowlisting et de vérification côté edge ? |
| Anthropic | ClaudeBot | Collecte pour entraînement | Est-ce que j’autorise cette collecte ? |
| Anthropic | Claude-SearchBot | Optimisation de recherche | Est-ce que je veux cette indexation pour la recherche Claude ? |
| Anthropic | Claude-User | Récupération dirigée par l’utilisateur | Est-ce que j’autorise ce fetch à la demande ? |
| Apple | Applebot | Crawl de recherche pour les surfaces Apple | Est-ce que je veux la visibilité Apple Search ? |
| Apple | Applebot-Extended | Contrôle d’usage des données seulement | Est-ce que j’autorise l’usage du contenu pour l’entraînement Apple ? |
| Bing / Microsoft | bingbot plus contrôles meta | Crawl de recherche plus contrôles Bing Chat / Copilot | Ai-je besoin de règles de crawl, de preview, ou des deux ? |
La leçon clé est simple :
un nom de fournisseur n’est pas une stratégie de gouvernance.
Il faut une stratégie par surface.
Utiliser la bonne surface de contrôle pour le bon problème
Une fois la famille d’accès clarifiée, la bonne couche de contrôle devient beaucoup plus évidente.
Utiliser robots.txt pour l’accès au crawl
Utilisez robots.txt lorsque la vraie question est de savoir si un crawler doit pouvoir récupérer certaines URL.
C’est la bonne surface pour :
- l’accès au crawl de recherche ;
- beaucoup d’opt-out de crawlers d’entraînement ;
- les règles par agent et par chemin ;
- la réduction des chemins de faible valeur ;
- l’hygiène de crawl par catégorie.
C’est toujours la couche de base la plus importante.
Utiliser meta robots ou X-Robots-Tag pour le comportement d’indexation et d’aperçu
Quand la question n’est plus l’accès au crawl, mais ce qui peut apparaitre dans la recherche ou dans les aperçus, les contrôles à la page ou à la ressource deviennent essentiels.
C’est là que meta robots et X-Robots-Tag interviennent.
Ils sont la bonne couche pour des questions comme :
- cette page doit-elle être indexée ;
- faut-il autoriser les snippets ;
- faut-il réduire les previews ;
- une ressource doit-elle rester crawlable mais non indexable ?
C’est particulièrement important quand un écosystème dit explicitement que le comportement Search continue d’être gouverné par son crawler de recherche, et non par un token distinct d’entraînement.
Utiliser les signaux d’usage IA quand la question porte sur l’usage aval
Si la question n’est plus « peut-il récupérer ? » mais « quels types d’usage est-ce que j’autorise ? », alors vous êtes dans la couche d’usage.
C’est là que les signaux d’usage IA et les distinctions de type Content-Signal deviennent utiles.
On retrouve notamment des distinctions comme :
searchai-inputai-train
Ce ne sont pas des mécanismes d’enforcement universels. Mais ils expriment une posture d’usage plus précise que le simple accès binaire au crawl.
Utiliser llms.txt et les fichiers de gouvernance associés pour l’attention et l’interprétation
llms.txt ne remplace pas robots.txt. Il remplit une autre fonction.
Il aide les modèles et les lecteurs machine à comprendre ce qui compte sur le site, ce qui doit être priorisé, et quel parcours de lecture est le plus sûr.
La même logique vaut pour des surfaces de gouvernance complémentaires comme :
Ces surfaces réduisent la mauvaise interprétation. Elles n’agissent pas comme un firewall.
Utiliser des contrôles edge ou d’infrastructure pour les agents signés et vérifiés
Dès qu’on entre dans le monde des agents signés, de l’allowlisting, de la vérification, ou des permissions d’exécution, on n’est plus seulement dans la couche de politique de crawl.
On est dans l’infrastructure.
Cela peut inclure :
- l’allowlisting côté CDN ou WAF ;
- la vérification de bots au niveau edge ;
- la validation de requêtes ;
- le contrôle du débit en temps réel ;
- les frontières de session et de permissions.
C’est précisément là qu’il ne faut pas surpromettre le plugin.
Ce que Better Robots.txt fait réellement
Better Robots.txt aide sur la partie qui relève bien de la couche de publication et de gouvernance.
Il aide les propriétaires de sites à :
- publier une politique
robots.txtstructurée ; - séparer les catégories de crawlers avant génération de la politique ;
- publier des signaux d’usage IA et des surfaces de gouvernance associées ;
- publier
llms.txtet des supports lisibles par machine ; - garder la politique publiée plus cohérente entre les différentes sorties.
Autrement dit, il aide à choisir et publier une politique plus claire.
Il ne transforme pas un fichier de politique en enforcement runtime.
Ce qui relève de l’infrastructure, pas du plugin
Certaines couches de contrôle appartiennent clairement à l’extérieur du cœur du plugin.
Cela inclut :
- l’allowlisting d’agents signés ;
- la vérification cryptographique ;
- les règles CDN et WAF ;
- la limitation de débit et les contrôles anti-abus ;
- l’authentification et les permissions de session ;
- l’enforcement runtime des décisions d’accès.
C’est pourquoi Better Robots.txt doit être décrit comme une couche de gouvernance et de publication, pas comme un produit de sécurité, ni comme une couche d’enforcement garantie.
Réponses rapides
Google-Agent, est-ce la même chose que Google-Extended ?
Non.
Google-Extended est un product token lié à l’usage aval du contenu crawlé par Google pour de futurs entraînements Gemini et certains usages de grounding. Google-Agent correspond à du trafic agentique déclenché par l’utilisateur et hébergé sur l’infrastructure Google. Ce sont des surfaces différentes et donc des problèmes de contrôle différents.
Bloquer l’entraînement, est-ce que cela bloque automatiquement la découvrabilité ?
Non.
Dans plusieurs écosystèmes, il est possible de rester visible en recherche tout en refusant certains usages liés à l’entraînement. C’est précisément l’intérêt de séparer les crawlers de recherche des crawlers ou tokens d’entraînement.
llms.txt remplace-t-il robots.txt ?
Non.
robots.txt reste la couche d’accès au crawl. llms.txt est une couche de guidage et d’attention. Ils ne résolvent pas le même problème.
Quand faut-il sortir du plugin pour passer à l’edge ?
Quand le problème exige une identité vérifiée, du trafic signé, de l’allowlisting, des permissions runtime, une logique WAF, ou du contrôle anti-abus. À ce moment-là, la couche de publication reste utile, mais elle n’est plus suffisante seule.
À lire aussi
- Google-Extended vs Googlebot
- ChatGPT-User vs GPTBot vs OAI-SearchBot
- Claude-User vs ClaudeBot vs Claude-SearchBot
- Applebot vs Applebot-Extended
- Bing, noarchive, nocache, et Copilot
- Robots.txt vs allowlisting d’agents signés
- Search vs ai-input vs ai-train
- Le paysage des crawlers IA en 2026
- La pile de gouvernance machine
- Taxonomie des bots
- Paramètres AI & LLM governance
- Paramètres llms.txt