Oui, un nouveau signal commun dans robots.txt doit permettre aux propriétaires de sites de refuser l’utilisation de leurs contenus pour l’entraînement de modèles génératifs sans bloquer automatiquement les moteurs de recherche traditionnels. Mais il ne faut pas l’installer comme une formule magique : le texte est encore un Internet-Draft, les calendriers diffèrent selon OpenAI, Google et Microsoft, et le grounding des réponses IA reste un usage distinct dont le traitement varie selon le fournisseur.
Le 30 octobre 2026, un projet technique a défini le jeton __usage_ai-training. Placé dans un groupe robots.txt, il permet d’exprimer une préférence à l’échelle d’un site ou de certains chemins. OpenAI annonce vouloir l’appliquer dans les prochains mois, Google en 2027 et Microsoft à partir du 1er février 2027.
Cette convergence est utile aux créateurs, médias, formateurs et indépendants qui publient des contenus originaux. Elle réduit la nécessité d’écrire une règle différente pour chaque entreprise. Elle ne règle toutefois ni les usages passés, ni les robots qui refusent de coopérer, ni la protection des contenus confidentiels. Surtout, elle ne signifie pas partout la même chose pour les réponses IA alimentées par le Web.
Informations vérifiées le 31 octobre 2026. Le statut du projet et les dates de mise en œuvre peuvent encore évoluer.
Ce qui a réellement été annoncé le 30 octobre 2026
La source technique principale est l’Internet-Draft Machine-Readable Training Preference Signal. Il propose d’utiliser la syntaxe déjà connue de robots.txt avec un jeton de politique commun :
User-Agent: __usage_ai-training Disallow: / Allow: /press-kit/Dans cet exemple, le site exprime une préférence contre l’entraînement génératif pour l’ensemble de ses contenus, sauf ceux situés sous /press-kit/. Le mécanisme ne crée pas une nouvelle directive : il réutilise User-Agent, Disallow, Allow et les règles de priorité de robots.txt.
Le projet définit l’entraînement IA comme l’utilisation d’un contenu pour modifier les paramètres appris d’un modèle génératif. Il exclut les systèmes utilisés exclusivement pour la classification, le classement ou la notation. Si aucun groupe __usage_ai-training n’existe, aucune préférence n’est exprimée au titre de ce mécanisme. Le groupe générique User-Agent: * ne doit pas être interprété comme couvrant automatiquement ce jeton.
Il faut également présenter son statut avec précision. La fiche IETF indique qu’il s’agit d’un Internet-Draft individuel, non approuvé par l’IETF et sans statut formel de norme. Cette première version date du 30 octobre 2026 et expire le 3 mai 2027 si elle n’est pas mise à jour, remplacée ou prolongée. Elle constitue donc un travail en cours, même si de grands fournisseurs annoncent déjà vouloir l’adopter.
OpenAI prévoit de respecter le signal dans les prochains mois et de publier les détails de son implémentation ultérieurement. Ses contrôles actuels restent valables. Google annonce un support en 2027, tandis que sa documentation sur les robots communs évoque le début de 2027. Microsoft Bing donne une date plus précise : le 1er février 2027, avec une transition à terminer avant le 1er mars pour les éditeurs utilisant encore NoArchive ou NoCache.
Entraînement, recherche et grounding : trois usages à ne pas confondre
Le point essentiel est la finalité. L’entraînement modifie durablement les paramètres d’un futur modèle. La recherche explore et indexe des pages pour les faire apparaître dans des résultats. Le grounding, ou ancrage, utilise un contenu au moment d’une demande pour aider une IA à produire une réponse plus actuelle et éventuellement citer sa source.
Le nouveau jeton vise l’entraînement génératif. Le projet précise qu’il ne s’agit pas d’une directive de crawl : les règles adressées aux robots d’exploration continuent de s’appliquer séparément. Il ne faut donc pas déduire qu’un Disallow pour __usage_ai-training interdit automatiquement l’indexation classique.
Chez OpenAI, la séparation est déjà lisible dans la documentation des robots. GPTBot concerne les contenus susceptibles d’être utilisés pour l’entraînement, tandis que OAI-SearchBot sert à faire apparaître des sites dans les fonctions de recherche de ChatGPT. Un éditeur peut actuellement bloquer le premier et autoriser le second. Le signal commun doit simplifier la préférence d’entraînement, sans remplacer immédiatement ces contrôles propres à OpenAI.
Microsoft annonce une séparation explicite. La préférence d’entraînement pourra être exprimée dans robots.txt ou au niveau d’une page. Le grounding disposera de réglages de page distincts : Allow, DisallowExtended pour limiter l’usage aux expériences exploitées par Microsoft, ou Disallow. Microsoft précise que ces choix ne modifient pas l’éligibilité aux résultats Bing traditionnels, mais qu’un refus du grounding réduit fortement la visibilité dans les réponses générées.
Le cas Google demande davantage de prudence. Google indique que, si le signal commun refuse l’entraînement et qu’aucune règle Google-Extended n’est explicitement définie, il prévoit de l’interpréter comme un refus de Google-Extended. Or, selon la documentation Google, Google-Extended couvre l’entraînement de futures générations de Gemini mais aussi certains usages de grounding. Le signal commun reste présenté comme une préférence d’entraînement ; sa traduction opérationnelle chez Google peut néanmoins influer sur l’éligibilité au grounding Gemini. Avant toute modification, il faut donc comparer les deux groupes et vérifier la documentation à jour.
Cette distinction prolonge le guide VIFLY consacré à la visibilité dans ChatGPT et les agents IA. Être cité par une réponse, apparaître dans une recherche et contribuer à un entraînement futur ne sont pas trois façons de dire la même chose. Ce sont trois décisions éditoriales différentes.
Deux exemples concrets pour les professionnels VIFLY
Une formatrice protège ses supports premium tout en laissant son expertise visible
Une formatrice publie des articles gratuits, une page de présentation et des extraits de cours. Elle héberge aussi quelques ressources publiques très détaillées sous /formations/. Son objectif est de rester découvrable dans Google, Bing et les moteurs IA, mais de refuser que les supports de cours accessibles publiquement servent à l’entraînement génératif.
Elle commence par cartographier ses chemins. Les articles de découverte peuvent rester sans préférence commune ou recevoir un Allow explicite si elle le souhaite. Le répertoire de supports peut recevoir un Disallow. Elle maintient en parallèle les contrôles propres aux fournisseurs tant que le signal commun n’est pas effectivement appliqué. Pour les contenus réservés aux clients, elle n’utilise pas robots.txt comme protection : elle conserve une authentification et de vraies permissions d’accès.
Ce choix lui permet de raisonner par valeur et par finalité. Ses pages destinées à la découverte restent ouvertes aux parcours qu’elle juge utiles ; ses ressources de travail reçoivent une préférence plus stricte. Elle documente la décision afin de pouvoir la réviser lorsque les implémentations seront stabilisées.
Un photographe veut être cité sans céder automatiquement ses images à l’entraînement
Un photographe indépendant souhaite que ses reportages apparaissent dans les résultats de recherche et puissent être cités lorsqu’un utilisateur cherche un professionnel local. En revanche, il ne veut pas exprimer un accord pour l’entraînement de modèles génératifs à partir de ses portfolios.
Il ne bloque pas aveuglément tous les robots IA. Il distingue les robots de recherche, les robots d’entraînement et les accès déclenchés par un utilisateur. Il vérifie aussi le poids réel des images originales : une miniature publique n’a pas le même rôle qu’un fichier haute définition livré à un client. Les originaux restent derrière un accès contrôlé et ne sont jamais protégés uniquement par une ligne publique de robots.txt.
Cette approche rejoint l’analyse VIFLY sur les liens et profils dans Google AI Mode : la visibilité utile dépend de contenus publics, attribuables et reliés à une source durable. Le refus d’un usage d’entraînement n’oblige pas à abandonner toute stratégie de découverte.
Le point de vue VIFLY : contrôlez les usages, pas la visibilité par peur
Pour un créateur ou un indépendant, publier remplit plusieurs fonctions. Une page peut établir une expertise, attirer une recherche, rassurer un prospect, vendre une ressource ou servir un client. Traiter toutes ces pages avec une seule règle globale revient souvent à confondre des actifs différents.
Le nouveau signal rend visible une question qui existait déjà : quelle contrepartie attendez-vous de chaque contenu public ? Un article de référence peut gagner à rester découvrable et citable. Un modèle payant, un cours complet, une base photographique ou un document client ne devrait pas être rendu public simplement pour faciliter le référencement. La première mesure de protection reste alors l’architecture d’accès, pas le fichier des robots.
Le signal commun peut devenir une brique de gouvernance utile parce qu’il raisonne par usage plutôt que par marque de robot. Mais la simplicité de la syntaxe ne doit pas masquer la complexité de la décision. Google, Microsoft et OpenAI n’alignent pas encore toutes les conséquences sur le grounding, les réponses IA ou les contrôles historiques.
L’article VIFLY sur les conditions Meta et le crawl des sites rappelait déjà qu’une règle robots.txt est un signal adressé à des clients automatisés, pas une barrière de sécurité ni une réponse juridique universelle. Le nouveau jeton améliore l’expression d’une préférence ; il ne transforme pas un protocole volontaire en coffre-fort.
Nuances, limites et points de vigilance
Le texte n’est pas encore une norme IETF adoptée. Il peut être modifié, remplacé ou abandonné. Les implémentations annoncées peuvent aussi ajuster leur calendrier ou leur interprétation.
Le signal n’est pas encore appliqué partout. OpenAI parle des prochains mois, Google de 2027 et Microsoft du 1er février 2027. Publier la règle aujourd’hui exprime une intention, mais ne prouve pas qu’un fournisseur l’a déjà détectée ou respectée.
Le périmètre est mondial, mais sans garantie uniforme par pays. Il ne s’agit pas d’une fonctionnalité réservée aux États-Unis : un site français ou réunionnais peut publier la syntaxe. En revanche, les conséquences dépendent de chaque entreprise, de ses produits et de sa date d’activation. Aucune liste distincte pour la France ou La Réunion n’est annoncée.
La règle agit pour les collectes futures. Elle n’efface pas les contenus déjà collectés, n’impose pas le retrait d’un modèle existant et ne remplace pas une demande juridique ou contractuelle adaptée.
Les robots non coopératifs peuvent l’ignorer. Le protocole repose sur l’interprétation et le respect du signal par le consommateur. Il ne bloque pas techniquement un téléchargement.
Le grounding reste distinct. Microsoft fournit des réglages séparés. OpenAI conserve des robots différenciés. Google prévoit une interaction particulière avec Google-Extended. Il faut vérifier le fournisseur avant d’annoncer qu’un refus d’entraînement préservera toujours chaque forme de visibilité IA.
robots.txt n’est pas une sécurité. Le RFC 9309 précise que les chemins inscrits deviennent publics et découvrables. Un espace client, une ressource payante ou un fichier confidentiel doit utiliser une authentification et des contrôles d’accès.
Le contexte européen ne crée pas une réponse automatique. Le Code de bonnes pratiques pour les modèles d’IA à usage général reconnaît les réserves de droits lisibles par machine et cite robots.txt. Cela renforce l’intérêt pratique du signal, mais la qualification des droits, l’application du droit d’auteur et les recours éventuels demandent une analyse propre à chaque situation. Le dossier VIFLY IA aide à distinguer loi, règles de plateforme et bonnes pratiques sans les confondre.
Que faire maintenant ? Un plan d’action en huit étapes
- Inventoriez vos contenus publics. Séparez pages de découverte, articles, portfolios, ressources gratuites, extraits, contenus premium et espaces clients.
- Décidez par finalité. Pour chaque groupe, indiquez si vous acceptez la recherche classique, l’apparition dans les réponses IA, le grounding et l’entraînement futur.
- Auditez le robots.txt actuel. Repérez GPTBot, OAI-SearchBot, Google-Extended, ClaudeBot, Bingbot et les règles génériques. Une nouvelle règle peut entrer en tension avec un choix plus ancien.
- Conservez les contrôles propres aux fournisseurs. Le signal commun n’est pas encore partout actif. Ne supprimez pas une règle existante uniquement parce que le projet a été publié.
- Testez le périmètre par chemin. Commencez sur un environnement contrôlé ou un groupe de pages clairement identifié. Vérifiez les priorités Allow et Disallow avant de viser tout le domaine.
- Protégez réellement ce qui doit rester privé. Utilisez connexion, permissions, URLs temporaires et stockage adapté pour les fichiers payants, clients ou confidentiels.
- Documentez la décision. Notez la date, l’objectif, les chemins concernés et les contrôles complémentaires. Cette trace évite qu’une modification technique future annule involontairement votre choix.
- Revenez sur le réglage en 2027. Vérifiez l’implémentation finale d’OpenAI, le support Google et la transition Microsoft. Contrôlez aussi les journaux serveur, l’indexation et la visibilité réelle.
La priorité n’est donc pas de copier une ligne immédiatement. Elle est de construire une politique compréhensible : quels contenus doivent être trouvés, lesquels peuvent alimenter une réponse, lesquels ne doivent pas entraîner un modèle et lesquels ne devraient tout simplement pas être publics.
Questions fréquentes et sources
Quel code permet de refuser l’entraînement IA pour tout un site ?
Le projet propose un groupe User-Agent: __usage_ai-training suivi de Disallow: /. Il s’agit encore d’un Internet-Draft et son respect dépend des fournisseurs participants.
Ce signal bloque-t-il Google Search ou Bing ?
Non, pas en tant que tel. Le projet sépare la préférence d’usage pour l’entraînement des règles de crawl adressées aux moteurs. Google et Microsoft déclarent que la préférence n’affecte pas l’éligibilité à la recherche traditionnelle, sous réserve des règles normales d’exploration et d’indexation.
Peut-on refuser l’entraînement tout en restant visible dans les réponses IA ?
Parfois, mais le réglage dépend du fournisseur. Microsoft sépare entraînement et grounding. OpenAI distingue ses robots de recherche et d’entraînement. Google prévoit une interaction avec Google-Extended qui demande une vérification spécifique.
Le signal est-il déjà respecté par OpenAI, Google et Microsoft ?
Pas encore de manière générale au 31 octobre 2026. OpenAI vise les prochains mois, Google 2027 et Microsoft le 1er février 2027. Les contrôles existants doivent rester en place pendant la transition.
La règle protège-t-elle les fichiers confidentiels ?
Non. robots.txt est public et n’est pas un contrôle d’accès. Les fichiers sensibles ou payants doivent être protégés par authentification et autorisation.
Le signal s’applique-t-il en France et à La Réunion ?
La syntaxe peut être publiée par n’importe quel site. Aucune restriction géographique n’est indiquée dans le projet. Son effet réel dépend toutefois du calendrier et de l’implémentation de chaque fournisseur.
Sources
- IETF Datatracker — Machine-Readable Training Preference Signal, 30 octobre 2026.
- OpenAI — Making it easier for websites to express AI training preferences, 30 octobre 2026.
- Google Search Central — Supporting a shared AI training control for websites, 30 octobre 2026.
- Google — Common crawlers and Google-Extended, consulté le 31 octobre 2026.
- Microsoft Bing — Your content, your choice, 30 octobre 2026.
- OpenAI — Overview of OpenAI Crawlers, consulté le 31 octobre 2026.
- RFC 9309 — Robots Exclusion Protocol.
- EU AI Act — General-Purpose AI Code of Practice, mesure 1.3.