Agents.txt n’est pas un contrôle d’accès

DreamHost indique désormais que ses offres Web Hosting incluent automatiquement des fichiers robots.txt et agents.txt par défaut lorsqu’un site n’a pas fourni ses propres versions.¹

Ce petit détail d’hébergement signale un changement plus large. Les sites web s’adressent maintenant à au moins trois publics à la fois : les robots d’exploration de recherche, les robots d’exploration IA et les assistants au moment de l’inférence qui cherchent un contexte propre. Les noms de fichiers donnent à cette évolution une apparence ordonnée. robots.txt indique ce que les clients automatisés peuvent explorer. llms.txt donne aux LLM une carte éditorialisée. agents.txt esquisse une politique destinée aux agents. Aucun de ces fichiers ne devrait donner à un opérateur le sentiment d’être protégé.

Agents.txt n’est pas un contrôle d’accès. Traitez les fichiers destinés aux robots d’exploration comme des indications publiques de politique et des aides à la découverte. Le vrai contrôle vient toujours de l’autorisation côté serveur, de la vérification de l’identité des bots, des limites de débit, des journaux, du comportement du cache et des preuves montrant que les robots qui vous importent ont bien vu les fichiers actuels.

TL;DR

La norme Robots Exclusion Protocol précise que les règles destinées aux robots d’exploration ne sont « pas une forme d’autorisation d’accès ».² Google prévient aussi qu’une URL interdite dans robots.txt peut tout de même apparaître dans Search si d’autres pages créent un lien vers elle.³ L’article de DreamHost sur le contrôle des bots explique lui aussi que les fichiers robots agissent comme des suggestions pour les moteurs de recherche conformes, et que les mauvais bots peuvent ignorer le fichier ou utiliser des user agents trompeurs.¹

Les robots d’exploration IA ajoutent d’autres dimensions de politique. OpenAI distingue OAI-SearchBot, utilisé pour la recherche ChatGPT, de GPTBot, lié à l’exploration destinée à l’entraînement, et indique que ChatGPT-User représente des actions déclenchées par l’utilisateur, auxquelles robots.txt peut ne pas s’appliquer.⁴ Google explique que Google-Extended n’a pas de chaîne user-agent HTTP distincte et fonctionne comme un jeton produit dans robots.txt pour les préférences d’entraînement et d’ancrage, pas pour l’inclusion dans Google Search.⁵ Le fichier de contrôle des robots doit désormais exprimer une politique par finalité, pas un simple interrupteur autoriser/bloquer.

Utilisez agents.txt si votre hébergeur, votre plateforme ou votre écosystème d’agents l’attend. Utilisez llms.txt si vous voulez que les outils au moment de l’inférence comprennent vos meilleures pages. Gardez robots.txt exact, car les grands robots d’exploration s’en servent toujours. Ensuite, vérifiez les requêtes au niveau du serveur et lisez les journaux. Un fichier texte peut exprimer une intention. Il ne peut pas arrêter un client non fiable.

Points clés

Pour les propriétaires de site : - Publiez robots.txt pour la politique d’exploration, llms.txt pour le contexte lisible par l’IA, et agents.txt uniquement comme indication destinée aux agents. - Ne placez jamais de routes privées, de noms de fichiers secrets, de prompts internes ni de chemins sensibles dans un fichier public destiné aux robots. - Vérifiez les journaux après chaque changement. Un fichier de politique ne compte que si le bon robot le récupère et change de comportement.

Pour les équipes SEO et AIO : - Séparez la visibilité dans la recherche, les permissions d’entraînement et les récupérations déclenchées par l’utilisateur. - Rendez explicite la liste d’autorisation pour les bots que vous voulez accueillir, comme les robots de recherche et les interfaces de réponses IA. - Associez les fichiers destinés aux robots à la vérification du sitemap, des balises canoniques, du schema et de llms.txt.

Pour les équipes sécurité : - Traitez les chaînes user-agent comme des déclarations, pas comme une identité. - Vérifiez les robots d’exploration avec le DNS inverse ou les plages d’IP publiées lorsque l’opérateur les fournit. - Protégez l’accès aux ressources sensibles avec l’authentification, des règles WAF, une politique applicative et des limites de débit, pas avec l’étiquette des robots.

Qu’est-ce qui a changé avec Agents.txt ?

robots.txt existe depuis des décennies. Le RFC définit un fichier robots.txt que les propriétaires de service mettent à disposition pour que les robots d’exploration puissent décider à quelles URI ils peuvent accéder.² La forme de base du fichier est familière :

User-agent: *
Disallow: /private-draft/
Sitemap: https://example.com/sitemap.xml

agents.txt arrive dans un autre contexte. Le web ne reçoit plus seulement des robots de moteurs de recherche. Il reçoit des robots d’entraînement, des robots de moteurs de réponse, des robots de sécurité publicitaire, des récupérations par assistants de navigateur, des récupérations LLM déclenchées par l’utilisateur, des robots d’archivage, des outils SEO et des bots de spam qui empruntent les noms de robots légitimes.

La documentation de DreamHost compte parce qu’elle fait passer agents.txt d’une idée de niche à un comportement d’hébergement par défaut chez au moins un hébergeur grand public. L’article indique que DreamHost inclut automatiquement des fichiers robots.txt et agents.txt par défaut pour les offres Web Hosting, et permet aux propriétaires de site de remplacer l’un ou l’autre en plaçant un fichier personnalisé à la racine du site.¹ Cela ne transforme pas agents.txt en norme dotée de sémantique d’application. Cela rend simplement le nom de fichier plus susceptible d’apparaître sur le web.

La lecture prudente est étroite :

Les noms de fichiers ne doivent pas se concurrencer. Ils doivent former un paquet de politique : ce que les robots peuvent demander, ce que les systèmes IA devraient lire, ce que les agents devraient savoir, et ce que le serveur a réellement observé.

Robots.txt reste utile, mais il ne protège pas

Les fichiers destinés aux robots échouent quand les équipes les utilisent comme frontières de sécurité.

Le RFC rend cette limite explicite. Le protocole demande aux clients automatisés d’honorer des règles lorsqu’ils accèdent à des URI ; il n’autorise pas l’accès.² Google le dit aussi de manière opérationnelle : si une autre page crée un lien vers une URL interdite, Google peut tout de même trouver et indexer l’adresse de l’URL ainsi que d’autres informations de lien publiques, même sans explorer le contenu de la page bloquée.³ DreamHost avertit que les règles robots fonctionnent comme des suggestions pour les moteurs de recherche conformes, et que les mauvais bots peuvent ignorer le fichier ou utiliser de faux user agents.¹

Ces faits mènent à une règle simple : ne mettez jamais dans robots.txt, agents.txt ou llms.txt quoi que ce soit qui vous nuirait si c’était copié dans un résultat de recherche, aspiré dans un jeu de données ou affiché par un LLM.

Les mauvais fichiers destinés aux robots exposent plus qu’ils ne protègent :

User-agent: *
Disallow: /internal-product-roadmap/
Disallow: /legal-private/
Disallow: /prompt-drafts/
Disallow: /customers/acme-renewal-risk/

Le fichier ci-dessus indique à chaque visiteur où du contenu sensible pourrait se trouver. Un robot conforme peut éviter ces chemins. Un attaquant reçoit une carte des dossiers.

Un fichier plus sûr énonce une politique d’exploration publique sans nommer l’inventaire sensible :

User-agent: *
Allow: /
Disallow: /*.md$
Sitemap: https://example.com/sitemap.xml

Cette version exprime une vraie préférence sans révéler la structure privée. Si /prompt-drafts/ existe, le serveur devrait la protéger avec une authentification et, lorsque c’est pertinent, des en-têtes noindex. Le fichier destiné aux robots ne devrait pas porter ce poids.

Les robots d’exploration IA exigent une politique par finalité

La politique des robots de recherche semblait autrefois binaire : autoriser Googlebot, bloquer les outils SEO bruyants, garder les pages privées privées avec des contrôles serveur.

La politique des robots IA ajoute la finalité. Un propriétaire de site peut vouloir qu’une page apparaisse dans les résultats de recherche ChatGPT tout en excluant cette même page de l’entraînement des modèles. La documentation des robots d’OpenAI rend cette distinction explicite. Elle indique qu’OAI-SearchBot prend en charge les fonctionnalités de recherche ChatGPT, tandis que GPTBot explore du contenu pouvant être utilisé pour entraîner les modèles de fondation d’IA générative d’OpenAI.⁴ OpenAI précise aussi que ces paramètres sont indépendants : un webmaster peut autoriser OAI-SearchBot tout en interdisant GPTBot.⁴

Google trace une limite similaire autrement. La documentation des robots de Google indique que Google-Extended n’a pas de chaîne user-agent HTTP distincte ; les user agents Google existants effectuent l’exploration, et Google-Extended agit comme un jeton produit dans robots.txt.⁵ Google explique que ce jeton contrôle si le contenu exploré d’un site peut soutenir les futurs entraînements et ancrages de modèles Gemini, et qu’il n’affecte pas l’inclusion ni le classement dans Google Search.⁵

Ces deux exemples montrent pourquoi une liste de blocage plate manque l’essentiel. La vraie matrice de politique demande :

Le fichier de politique doit correspondre à la finalité. N’interdisez pas tous les user agents IA pour ensuite vous demander pourquoi les interfaces de recherche IA ignorent le site. N’autorisez pas tous les robots IA pour ensuite vous plaindre que des robots d’entraînement consomment des pages que vous destiniez seulement à la recherche côté utilisateur. Séparez les finalités, énoncez la préférence, puis vérifiez le comportement.

Llms.txt résout un autre problème

llms.txt ne remplace pas robots.txt. La proposition de Jeremy Howard décrit /llms.txt comme un moyen de fournir des informations qui aident les LLM à utiliser un site web au moment de l’inférence.⁶ La même proposition indique que llms.txt peut coexister avec les standards actuels du web : les sitemaps listent les pages pour les moteurs de recherche, tandis que llms.txt offre une vue d’ensemble éditorialisée aux LLM et peut compléter robots.txt avec du contexte pour le contenu autorisé.⁶

Cette distinction compte pour le travail AIO.

robots.txt répond : « Ce robot peut-il demander ce chemin ? »

llms.txt répond : « Si un assistant lit mon site, que devrait-il comprendre en premier ? »

agents.txt peut répondre : « Que devraient savoir les clients agentiques sur le comportement souhaité ? »

Ces questions sont proches, mais elles ne se fondent pas en un seul fichier. Un site sérieux devrait traiter la découverte IA comme une surface de publication :

1. Publier des pages canoniques avec des titres et descriptions clairs.
2. Ajouter des données structurées qui correspondent à la page visible.
3. Maintenir le sitemap et le flux RSS à jour.
4. Publier llms.txt et llms-full.txt pour un contexte IA éditorialisé.
5. Publier robots.txt avec une politique explicite pour les robots.
6. Ajouter agents.txt seulement si la plateforme ou l’écosystème d’agents donne au fichier un lecteur concret.
7. Vérifier les journaux pour confirmer que les robots demandent les fichiers modifiés.

Sauter la dernière étape transforme l’AIO en rituel d’espoir. Le fichier destiné aux robots existe. La route renvoie 200. Aucune preuve ne montre que les clients visés l’ont vu.

La vérification se fait au niveau du serveur

Les chaînes user-agent ne prouvent pas l’identité. Un script quelconque peut envoyer User-Agent: Googlebot. Un scraper peut envoyer User-Agent: GPTBot. Une politique qui fait confiance au seul en-tête accorde le traitement le plus généreux à ce qui est le plus facile à usurper.

Google documente deux méthodes de vérification pour les requêtes qui prétendent venir de Google : DNS inverse puis DNS direct pour les vérifications ponctuelles, et correspondance avec des plages d’IP publiées pour les systèmes plus importants.⁷ OpenAI publie des fichiers JSON d’adresses IP pour OAI-SearchBot, GPTBot et ChatGPT-User dans sa documentation sur les robots.⁴ Ces mécanismes ne couvrent pas tous les robots. Ils établissent néanmoins la bonne forme : l’identité exige une preuve au-delà d’une chaîne.

La politique minimale au niveau du serveur devrait enregistrer :

Ce paquet de journaux transforme la politique des robots d’opinion en preuve. Si GPTBot continue de demander des chemins interdits, vous pouvez le prouver. Si un faux Googlebot martèle des URL qui ressemblent à des chemins privés depuis un proxy résidentiel, vous pouvez le bloquer sans pénaliser le vrai Googlebot. Si OAI-SearchBot ne demande jamais l’article modifié, vous savez pourquoi la page n’est pas apparue dans la recherche ChatGPT.

Un paquet pratique de politique pour les robots IA

Ne commencez pas par le fichier. Commencez par le résultat recherché.

Ce paquet donne à chaque couche le bon rôle. robots.txt communique une préférence. llms.txt communique du contexte. agents.txt communique une intention destinée aux agents lorsqu’un lecteur existe. Le serveur applique. Les journaux prouvent.

Sur mon propre site, le travail lié aux robots suit cette séparation. Le fichier de politique public accueille les robots légitimes et bloque les chemins Markdown bruts que des robots avaient déduits d’exemples dans des blocs de code. Les fichiers de contexte IA offrent aux assistants une entrée éditorialisée vers les contenus publics. Le recensement nocturne des explorations me dit si des robots ont vu des erreurs, un cache périmé, des routes manquantes ou d’anciennes URL qui devraient désormais renvoyer 410. Le fichier de politique donne l’intention. Les journaux décident si l’intention a fonctionné.

Que mettre dans Agents.txt

Tant que l’écosystème n’est pas stabilisé, gardez agents.txt ennuyeux et public.

Bons candidats :

• Contact du site et URL de politique.
• Pointeurs vers robots.txt, le sitemap, llms.txt et le RSS.
• Déclaration sur l’usage préféré du contenu public.
• Avertissement indiquant que les routes privées ou authentifiées exigent une autorisation.
• Adresse de support pour les problèmes d’exploration.

Mauvais candidats :

• Chemins secrets.
• Règles de prompts internes.
• Routes API non publiques.
• Noms de clients.
• Exceptions de sécurité.
• Instructions qui nuiraient au site si elles étaient copiées par un client hostile.

Le bon critère pour agents.txt n’est pas « Un bon agent apprécierait-il cela ? ». Le bon critère est : « Serais-je à l’aise si un mauvais agent, un résultat de recherche et un utilisateur quelconque lisaient tous ce fichier ? »

Le meilleur modèle mental

Les fichiers destinés aux robots sont des panneaux sur une route publique.

Un panneau peut dire « entrée livraisons », « sens interdit » ou « commencez ici ». Les conducteurs respectueux suivent le panneau. Les conducteurs imprudents l’ignorent. Le panneau reste utile parce que la plupart du trafic légitime veut des instructions claires. Il échoue quand vous le traitez comme une porte verrouillée.

Les robots d’exploration IA rendent ces panneaux à la fois plus importants et moins suffisants. Plus importants, parce que les systèmes IA ont besoin d’un contexte public clair, d’une politique par finalité et de cartes de routes. Moins suffisants, parce que les user agents se multiplient, l’entraînement et la recherche se séparent, et les mauvais clients peuvent imiter les bons.

La réponse n’est pas d’abandonner les fichiers destinés aux robots. La réponse est de ramener leur autorité au bon niveau. Publiez une politique publique claire. Vérifiez qui demande les fichiers. Observez ce qu’ils récupèrent. Faites appliquer les frontières privées par le serveur. Traitez toute affirmation sur la « visibilité IA » comme non prouvée tant que les journaux et les routes en direct ne l’appuient pas.

Voilà la différence entre le théâtre AIO et de vraies opérations d’exploration.

FAQ

Qu’est-ce qu’agents.txt ?

agents.txt est un fichier texte émergent, destiné aux agents, que certains hébergeurs ou outils peuvent servir à la racine du site. DreamHost documente des fichiers agents.txt par défaut pour les offres Web Hosting, mais cette documentation ne fait pas du fichier une norme de contrôle d’accès. Traitez-le comme une indication publique jusqu’à ce qu’une plateforme d’agents précise exactement comment elle lit et applique le fichier.¹

Robots.txt bloque-t-il les robots d’exploration IA ?

Les robots conformes peuvent respecter robots.txt, et les grands opérateurs documentent des jetons spécifiques pour leurs robots. OpenAI documente les contrôles OAI-SearchBot et GPTBot, tandis que Google documente Google-Extended comme jeton produit pour les préférences d’entraînement et d’ancrage.⁴⁵ robots.txt n’authentifie toujours pas le client, ne cache pas le contenu et n’arrête pas un bot qui choisit d’ignorer le fichier.²³

Dois-je publier llms.txt ?

Publiez llms.txt si vous voulez que les assistants IA trouvent une carte éditorialisée de votre contenu public. La proposition présente llms.txt comme du contexte au moment de l’inférence, pas comme un remplacement du sitemap ou de robots.txt.⁶ Un fichier utile pointe vers les pages que vous voulez réellement faire comprendre aux agents.

Une URL interdite peut-elle quand même apparaître dans la recherche ?

Oui. Google indique qu’une URL bloquée par robots.txt peut tout de même apparaître si d’autres pages créent un lien vers elle, même si Google n’explore ni n’indexe le contenu de la page bloquée.³ Utilisez l’authentification, noindex lorsque l’accès par exploration est autorisé, et une politique côté serveur pour les pages qui doivent rester hors des résultats publics.

Comment distinguer un vrai robot d’un faux ?

Ne vous contentez pas de la chaîne user-agent. Google documente les vérifications par DNS inverse puis DNS direct, ainsi que la correspondance avec des plages d’IP publiées.⁷ OpenAI publie des fichiers JSON d’adresses IP pour ses bots documentés.⁴ Lorsqu’un opérateur de robot ne publie pas de données de vérification, classez la requête comme une déclaration et appliquez des limites de débit ou un challenge selon son comportement.

Quelle est la configuration de fichiers robots la plus sûre pour un site public ?

Utilisez robots.txt pour la politique des robots, le sitemap pour la découverte des URL, llms.txt pour le contexte IA éditorialisé et agents.txt uniquement pour des indications publiques destinées aux agents. Gardez les chemins sensibles hors de tous les fichiers publics. Ensuite, vérifiez les routes en direct, l’état du cache, les récupérations par les robots et les journaux serveur avant d’affirmer que la configuration fonctionne.

Références