OpenAI prépare un signal robots.txt commun : protéger ses contenus sans disparaître de ChatGPT Search

OpenAI a annoncé le 30 octobre 2026 son intention de respecter un signal commun placé dans le fichier robots.txt. Ce signal doit permettre à un éditeur de site d’exprimer, avec une règle unique, sa préférence sur l’utilisation de ses contenus pour l’entraînement de modèles génératifs auprès de plusieurs fournisseurs participants.

Aujourd’hui, un responsable de site doit généralement connaître les robots propres à chaque acteur et maintenir des règles séparées. OpenAI présente le nouveau mécanisme comme un moyen de réduire ce travail. L’entreprise précise toutefois deux limites importantes : la mise en œuvre est prévue dans les prochains mois et les contrôles existants continueront à s’appliquer.

Le mécanisme proposé utilise le jeton de politique __usage_ai-training. Une entreprise pourrait, par exemple, refuser l’entraînement sur l’ensemble du site tout en l’autorisant sur un dossier précis :

``text User-Agent: __usage_ai-training Disallow: / Allow: /presse/ ``

Cette syntaxe figure dans un Internet-Draft daté du 30 octobre 2026. Le document est rédigé par Kevin Kelley, d’Anthropic, dans le cadre des travaux du groupe AI Preferences de l’IETF. Il s’agit d’un document de travail individuel : le registre de l’IETF indique explicitement qu’il n’est pas approuvé par l’IETF et qu’il n’a pas de statut formel dans le processus de normalisation.

La nouvelle utile pour une PME n’est donc pas qu’une norme définitive vient d’entrer en vigueur. C’est qu’un langage commun commence à émerger et qu’OpenAI s’engage publiquement à le prendre en charge.

La principale erreur serait de traiter robots.txt comme un interrupteur unique pour « l’IA ». OpenAI distingue déjà plusieurs usages.

Les paramètres sont indépendants. OpenAI donne lui-même l’exemple d’un site qui autorise OAI-SearchBot afin d’apparaître dans les résultats de recherche, tout en bloquant GPTBot pour indiquer que ses contenus ne doivent pas servir à l’entraînement.

Le futur signal commun ne change pas cette séparation. Le projet technique précise que la préférence d’usage et les règles de circulation des robots sont deux choses distinctes. Le jeton __usage_ai-training n’est pas, à lui seul, une directive destinée à empêcher l’exploration d’un site.

Le sujet concerne d’abord les entreprises qui publient un actif éditorial ou informationnel substantiel :

• médias, éditeurs et organismes de formation ;

• cabinets de conseil qui diffusent méthodes, études ou bases documentaires ;

• éditeurs SaaS avec une documentation technique détaillée ;

• places de marché et sites e-commerce avec des catalogues enrichis ;

• entreprises industrielles qui publient notices, données techniques ou centres de ressources.

Pour une PME dont le site présente seulement ses offres et quelques articles, la première question n’est pas forcément « comment tout bloquer ? ». Elle est : quels contenus doivent être trouvés par de futurs clients, lesquels peuvent être utilisés pour l’entraînement et lesquels ne devraient jamais être publics sans authentification ?

Une règle globale appliquée dans l’urgence peut produire un mauvais compromis. Elle peut protéger un contenu que l’entreprise cherche justement à rendre visible, ou laisser accessible un document sensible qui aurait dû être placé derrière un contrôle d’accès.

1. Cartographier les chemins du site

Classez les principales zones du site selon leur fonction : pages commerciales, blog, documentation, centre d’aide, espace presse, fichiers téléchargeables et contenus réservés.

Pour chaque zone, posez trois questions distinctes :

1. voulons-nous qu’elle apparaisse dans ChatGPT Search ?

1. acceptons-nous qu’elle soit utilisée pour l’entraînement de modèles génératifs ?

1. devrait-elle être accessible publiquement à n’importe quel visiteur ?

La troisième question ne se traite pas avec robots.txt. Un fichier public reste public. Une préférence adressée à des robots n’est ni une authentification, ni un chiffrement, ni une protection contre la copie.

2. Auditer les règles existantes avant de les modifier

Relevez les directives actuelles pour GPTBot, OAI-SearchBot, ChatGPT-User et le groupe générique User-agent: *. Vérifiez aussi les règles du pare-feu ou du CDN : autoriser un robot dans robots.txt ne suffit pas si ses adresses sont bloquées ailleurs.

Cette photographie initiale évite de perdre une règle utile lors de l’ajout futur du signal commun.

3. Conserver les contrôles actuels

OpenAI n’a pas annoncé une activation immédiate. L’entreprise prévoit une mise en œuvre dans les prochains mois et promet une nouvelle communication sur les détails.

Il serait donc prématuré de supprimer les règles propres à GPTBot au profit du seul __usage_ai-training. La démarche prudente consiste à conserver les contrôles actuels, préparer la politique souhaitée et attendre la documentation de déploiement avant d’activer la nouvelle règle.

4. Définir une politique par type de contenu

Une politique uniforme est rarement nécessaire. Une entreprise peut vouloir :

• rendre ses pages d’offres visibles dans les moteurs et assistants ;

• conserver son blog accessible à la recherche tout en refusant l’entraînement ;

• autoriser plus largement l’usage d’un dossier presse ;

• protéger réellement les documents clients, méthodes propriétaires et données sensibles par authentification.

Le projet de signal commun prévoit des règles par chemin. Cette granularité est utile à condition que l’entreprise ait d’abord classé ses contenus.

5. Nommer un responsable et conserver une preuve de décision

Le fichier robots.txt est souvent modifié comme un détail technique. Il devient pourtant un point de traduction entre une politique éditoriale, une stratégie de visibilité et une préférence d’usage des contenus.

La décision doit donc être détenue conjointement par le marketing ou l’éditorial, la DSI et, lorsque les contenus ont une valeur particulière, le juridique. Conservez la version du fichier, la date de modification, le périmètre retenu et le motif de chaque règle.

Le nouveau signal reste volontaire. Il exprime une préférence à destination des fournisseurs qui choisissent de l’honorer. Ce n’est pas une mesure de sécurité et ce n’est pas, à lui seul, un contrat de licence.

Le texte technique peut encore évoluer. Il est daté du 30 octobre 2026, expire le 3 mai 2027 dans sa version actuelle et n’a pas de statut normatif. OpenAI n’a pas encore publié les détails de son implémentation.

Enfin, refuser l’entraînement ne signifie pas disparaître automatiquement des fonctions de recherche. Chez OpenAI, GPTBot et OAI-SearchBot répondent déjà à des finalités distinctes. C’est précisément cette séparation que les entreprises doivent préserver.

Ne demandez pas à votre équipe de « bloquer l’IA » ou d’« ouvrir le site à l’IA ». Ces formulations mélangent des usages différents.

Demandez plutôt une matrice simple, par zone du site : visibilité souhaitée, entraînement accepté ou refusé, accès public ou réservé, responsable de la décision et contrôle technique correspondant.

L’annonce d’OpenAI ne crée pas une urgence de modification. Elle crée une échéance de préparation. Les entreprises qui auront classé leurs contenus pourront adopter le signal commun lorsqu’il sera effectivement pris en charge, sans sacrifier leur visibilité ni confondre préférence d’usage et protection des données.

• Shadow AI : l’IA invisible est déjà un système d’information parallèle

• Contrats IA : la réversibilité vaut plus que le meilleur benchmark

• Studio IA Atalas