Trafic des agents IA : crawl et attribution

Publiée le 4 août 2026 . Rattachée à la lisibilité du catalogue par les agents.

« On a mis GPTBot dans le robots.txt, le sujet est traité. » C’est la phrase qu’on entend le plus souvent, et c’est celle qui coûte le plus cher. Elle repose sur une confusion de catégorie : tout ce qui arrive d’un fournisseur d’IA n’est pas un crawler, et robots.txt ne gouverne pas la même chose selon le cas.

Cette note sépare les trois familles de trafic, et dit pour chacune ce qui est réellement pilotable.

Trois familles, pas une

Les crawlers d’entraînement parcourent le web pour constituer des corpus. Ils sont récurrents, larges, indifférents à un utilisateur particulier. GPTBot entre dans cette catégorie : OpenAI le documente comme son crawler d’entraînement, avec une chaîne du type compatible; GPTBot/1.4; +https://openai.com/gptbot.

Les indexeurs de réponse alimentent une surface de recherche générative. OAI-SearchBot est documenté par OpenAI pour l’indexation de recherche. Les bloquer ne protège rien, cela retire simplement le site des réponses. C’est une décision commerciale déguisée en décision technique.

Les récupérations déclenchées par un humain sont d’une autre nature. ChatGPT-User correspond aux requêtes initiées par un utilisateur, et la documentation d’OpenAI précise que les règles de robots.txt peuvent ne pas s’y appliquer, précisément parce que l’action vient d’une personne. Un utilisateur qui demande à son assistant d’ouvrir une page n’est pas un robot, et le traiter comme tel dégrade une visite réelle.

OpenAI documente également OAI-AdsBot, dédié à la validation publicitaire, ni entraînement ni recherche. Quatre jetons, quatre intentions distinctes : les regrouper sous une même règle revient à décider sans savoir ce qu’on décide.

Le cas Google-Extended, qui n’est pas un crawler

Google documente une distinction que beaucoup de configurations ignorent. Googlebot, Google-CloudVertexBot et GoogleOther sont des crawlers actifs, avec des chaînes user-agent HTTP réelles. Google-Extended, lui, ne l’est pas. La documentation est explicite : « Google-Extended doesn’t have a separate HTTP request user agent string. Crawling is done with existing Google user agent strings; the robots.txt user-agent token is used in a control capacity. »

Autrement dit, Google-Extended est un jeton de contrôle, pas un visiteur. Il n’apparaîtra jamais dans les logs d’accès. Deux conséquences concrètes :

• chercher Google-Extended dans les logs pour mesurer un volume est une impasse, il n’y a rien à trouver ;
• le bloquer au niveau du serveur, par filtrage user-agent, n’a aucun effet, puisque la requête arrive sous une autre identité. Seule la directive robots.txt agit, et son effet porte sur l’usage du contenu pour l’entraînement de Gemini, pas sur la présence du site dans Google Search.

C’est le contre-exemple qui suffit à disqualifier le raisonnement « je bloque au pare-feu, c’est plus sûr que robots.txt ». Selon le jeton, l’un des deux leviers n’existe simplement pas.

Ce que robots.txt ne gouverne pas

robots.txt est une convention déclarative. Elle repose sur la bonne foi du client et sur l’honnêteté de la chaîne user-agent, qui est trivialement falsifiable. Trois angles morts subsistent, quelle que soit la qualité du fichier :

• les agents qui ignorent la convention, par choix ou par conception ;
• les agents exécutés localement dans un navigateur, côté utilisateur, qui ressemblent à du trafic humain parce que c’en est presque ;
• les fournisseurs qui ne publient aucun jeton stable.

La conclusion opérationnelle n’est pas d’abandonner robots.txt, qui reste le seul signal standard et le seul respecté par les grands fournisseurs. Elle est de ne pas lui prêter une fonction de contrôle d’accès qu’il n’a jamais eue. Un contrôle d’accès se fait au niveau de la couche réseau ou applicative, avec les compromis que cela implique.

Une position par défaut défendable

Pour un marchand qui veut être trouvé et acheté par des agents, la position par défaut n’est pas symétrique :

Famille	Position par défaut	Raison
Indexeurs de réponse	autoriser	les bloquer retire le site des réponses
Agents déclenchés par un humain	autoriser	c’est une visite réelle
Crawlers d’entraînement	décision de marque	aucun effet sur la découvrabilité commerciale
Jetons de contrôle	décision de marque	agit sur l’usage, pas sur l’accès

C’est la configuration retenue par ce site : le fichier robots.txt autorise explicitement les principaux jetons documentés plutôt que de s’en remettre à une règle générique.

Ce qui manque encore

L’écosystème n’a pas de mécanisme largement déployé permettant à un marchand de vérifier cryptographiquement qu’un agent est bien celui qu’il prétend être. Tant que cette brique manque, toute politique fondée sur le nom du user-agent reste une politique fondée sur la déclaration de l’autre partie. C’est aussi ce qui rend la mesure difficile, sujet abordé sur la page commerce agentique.

Pour la préparation du catalogue lui-même, voir la lisibilité par les agents et llms.txt.

Sources

• OpenAI, Bots and crawlers
• Google, Common crawlers

---

Revenir à la lisibilité du catalogue par les agents · Toutes les notes · Read in English