Aller au contenu principalSkip to content

ChatGPT-User vs GPTBot vs OAI-SearchBot : quelle surface OpenAI contrôle quoi

L’une des erreurs les plus faciles à commettre aujourd’hui en gouvernance d’accès machine consiste à traiter tout le trafic OpenAI comme une seule chose.

Ce n’est pas le cas.

Un modèle OpenAI vraiment utile doit maintenant distinguer au moins 4 surfaces :

  • OAI-SearchBot
  • GPTBot
  • ChatGPT-User
  • ChatGPT agent

Quand on les rabat dans le même panier mental, on pose de mauvaises questions.

On dit « Faut-il bloquer OpenAI ? » alors que les vraies questions sont beaucoup plus précises :

  • veut-on de la visibilité dans ChatGPT Search ?
  • veut-on refuser l’entraînement ?
  • veut-on gouverner les visites déclenchées par l’utilisateur ?
  • faut-il gérer un accès vérifié ou allowlisté à l’edge ?

C’est exactement pour cela que Pourquoi robots.txt ne suffit plus pour les agents IA déclenchés par l’utilisateur est un article pilier, pas un cas marginal.

La version courte

Voici la séparation la plus utile des surfaces OpenAI.

SurfaceÀ quoi elle sertQuestion principale
OAI-SearchBotVisibilité dans les fonctions Search de ChatGPTVeut-on que le site soit surfacé dans les réponses Search de ChatGPT ?
GPTBotCollecte pour entraînementAutorise-t-on l’usage du contenu pour l’entraînement des modèles fondamentaux génératifs ?
ChatGPT-UserVisites déclenchées par l’utilisateur depuis ChatGPT ou un Custom GPTVeut-on autoriser cette récupération à la demande, sachant qu’il ne s’agit pas d’un crawl automatique classique ?
ChatGPT agentTrafic agentique signé et allowlistableEst-on face à un problème d’identité, d’edge, et de permissions runtime plutôt qu’à un simple problème de crawl policy ?

Cette distinction résume tout l’article.

Ce que contrôle réellement OAI-SearchBot

OAI-SearchBot est la surface OpenAI qui compte pour la visibilité Search.

Son rôle n’est pas l’entraînement. Son rôle est de surfacer des sites dans les fonctions Search de ChatGPT.

C’est donc la bonne surface quand l’objectif business principal est :

  • apparaitre dans les réponses Search de ChatGPT ;
  • être surfacé, cité, et lié dans les fonctions Search de ChatGPT ;
  • conserver une découvrabilité orientée recherche.

C’est aussi ici que beaucoup d’équipes se blessent elles-mêmes.

Si vous bloquez OAI-SearchBot, il ne faut pas s’attendre à une inclusion normale dans les réponses Search de ChatGPT. OpenAI précise aussi qu’un site peut encore apparaitre comme lien navigationnel, ce qui est un résultat bien plus étroit qu’une vraie présence dans les réponses Search.

La première règle est donc simple :

si le sujet est la découvrabilité dans ChatGPT Search, la surface pertinente est OAI-SearchBot, pas GPTBot.

Ce que contrôle réellement GPTBot

GPTBot est la surface OpenAI liée à la collecte pour entraînement.

Son rôle est de crawler du contenu susceptible d’être utilisé pour entraîner les modèles fondamentaux génératifs d’OpenAI.

C’est donc la bonne surface lorsque la vraie question est :

  • ce contenu peut-il servir à l’entraînement ?
  • veut-on refuser un usage pour de futurs entraînements ?
  • veut-on séparer la visibilité Search de la réutilisation pour l’entraînement ?

La nuance centrale est celle-ci :

bloquer GPTBot correspond à une posture d’entraînement.
Ce n’est pas la même chose que sortir de ChatGPT Search.

Un site peut autoriser OAI-SearchBot tout en refusant GPTBot. OpenAI documente explicitement ce cas comme un choix normal.

C’est un très bon exemple du fait qu’une logique plate du type « autoriser OpenAI / bloquer OpenAI » est trop grossière pour être utile.

Ce que change ChatGPT-User

ChatGPT-User introduit une autre classe de requête.

Cet agent est utilisé pour certaines actions utilisateur dans ChatGPT et les Custom GPTs. Quand un utilisateur pose une question à ChatGPT, le système peut visiter une page web avec un agent ChatGPT-User. OpenAI précise aussi que les utilisateurs peuvent interagir avec des applications externes via GPT Actions.

Ce point compte énormément parce que ChatGPT-User n’est pas décrit comme un crawl automatique du web.

Il s’agit d’un accès déclenché par l’utilisateur.

C’est pour cela qu’OpenAI indique que les règles robots.txt peuvent ne pas s’appliquer à ces requêtes.

C’est aussi pourquoi ChatGPT-User ne doit pas être traité comme une surface Search. OpenAI dit explicitement qu’il n’est pas utilisé pour déterminer si un contenu peut apparaitre dans Search. Cette décision relève de OAI-SearchBot.

Donc, si ton équipe se demande :

  • pourquoi ChatGPT visite cette page à la demande ;
  • pourquoi une partie de la récupération continue malgré un refus de l’entraînement ;
  • pourquoi la visibilité Search reste distincte des visites déclenchées par l’utilisateur ;

la réponse est généralement qu’elle regarde ChatGPT-User, pas un crawler classique.

Où se place ChatGPT agent

Il existe une autre surface OpenAI qu’on rate facilement si l’on reste enfermé dans le cadre robots.txt.

OpenAI documente aussi ChatGPT agent comme un agent signé et allowlistable dans des écosystèmes edge majeurs comme Akamai, Cloudflare, et HUMAN.

Cela veut dire qu’une partie du trafic lié à OpenAI ne doit plus être modélisée d’abord comme une simple règle publique de crawl.

Il faut la modéliser comme un problème d’identité vérifiée et de politique d’infrastructure.

Cette couche vit dans des endroits comme :

  • l’allowlisting côté CDN ;
  • les règles WAF ;
  • les répertoires d’agents de confiance ;
  • les permissions runtime et les politiques de session.

C’est précisément pour cela que Robots.txt vs allowlisting d’agents signés appartient au même cluster que la décomposition des robots OpenAI.

Quelle surface OpenAI faut-il utiliser ?

Voici le bon parcours de décision.

Objectif : apparaitre dans les fonctions Search de ChatGPT

Gardez OAI-SearchBot autorisé.

Si cette surface est bloquée, il ne faut pas s’attendre à une présence normale dans les réponses Search de ChatGPT.

Bloquez GPTBot, mais ne bloquez pas OAI-SearchBot sauf si vous acceptez aussi de perdre la présence Search normale.

Objectif : raisonner correctement sur les visites déclenchées par l’utilisateur

Traitez ChatGPT-User comme une classe distincte de la recherche et de l’entraînement.

Ne supposez pas qu’un refus d’entraînement règle automatiquement la question de la récupération à la demande.

Objectif : laisser passer un agent de confiance dans une infrastructure contrôlée

Ce n’est pas principalement un problème robots.txt.

Il faut le traiter comme un sujet de vérification à l’edge et d’allowlisting.

Trois erreurs fréquentes

1. Bloquer GPTBot en pensant que la visibilité Search disparaît

Ce n’est pas la surface Search.

Si le vrai sujet est la présence dans ChatGPT Search, la surface pertinente est OAI-SearchBot.

2. Bloquer OAI-SearchBot puis s’étonner d’une baisse de visibilité citationnelle

C’est le résultat attendu.

La présence Search et la posture d’entraînement ne sont pas la même chose.

3. Traiter ChatGPT-User et ChatGPT agent comme une seule classe opérationnelle

Ce n’est pas le cas.

ChatGPT-User relève de visites déclenchées par l’utilisateur. ChatGPT agent relève d’un modèle d’agent signé ou allowlistable côté edge.

Où Better Robots.txt se place

Better Robots.txt aide sur la couche de publication et de gouvernance du problème.

Il aide à :

  • séparer OAI-SearchBot et GPTBot ;
  • éviter de mélanger découvrabilité et entraînement ;
  • coordonner robots.txt avec les signaux d’usage IA et llms.txt ;
  • garder une politique plus claire sur plusieurs surfaces lisibles par machine.

Ce qu’il ne fait pas, c’est transformer l’accès d’un agent signé en simple case à cocher.

Dès que la vraie question devient identité vérifiée, allowlisting, permissions runtime, ou enforcement côté edge, on sort du rôle central du plugin pour entrer dans l’infrastructure.

Le bon modèle mental

Le modèle mental le plus sûr côté OpenAI est maintenant celui-ci :

  • OAI-SearchBot = visibilité Search
  • GPTBot = collecte pour entraînement
  • ChatGPT-User = récupération déclenchée par l’utilisateur
  • ChatGPT agent = trafic agentique signé ou allowlistable

Plus cette séparation est claire dans la politique publiée, moins le risque de bloquer la mauvaise chose pour la mauvaise raison est élevé.

À lire aussi