Un jeton partagé dans le robots.txt pour refuser l'entraînement des IA

Google a annoncé le 30 octobre 2026 son intention de prendre en charge un jeton de préférence partagé dans le robots.txt, construit sur un brouillon du groupe de travail AIPREF à l'Internet Engineering Task Force (IETF), pour que les sites expriment leurs préférences d'entraînement des IA auprès de plusieurs fournisseurs en une seule étape.¹ Microsoft a publié le même jour ses propres contrôles autour de ce jeton commun, et OpenAI a annoncé son adhésion au signal partagé ; Anthropic, qui a déposé le brouillon à l'IETF, participe aussi aux discussions, selon PPC Land.² Cet article reprend ce que fait ce jeton, ce qu'il laisse de côté, le calendrier annoncé par chaque éditeur et le réglage à envisager pour une PME qui veut rester citée par les IA.

01Comment fonctionne le jeton partagé

Le nouveau mécanisme repose sur un jeton de politique (policy token), inscrit dans une ligne User-Agent du robots.txt comme n'importe quel autre robot, mais qui n'exprime pas une règle d'exploration : il exprime une préférence d'usage sur le contenu déjà récupéré.³

La syntaxe : un seul jeton, plusieurs fournisseurs

Le brouillon de l'IETF définit le jeton __usage_ai-training, à écrire dans un groupe robots.txt ordinaire. L'exemple donné par le brouillon refuse l'entraînement sur tout le site, sauf sous un chemin choisi :³

Avant ce jeton, un site qui voulait refuser l'entraînement chez plusieurs fournisseurs devait répéter la règle pour chaque robot : Google-Extended, GPTBot, ClaudeBot, et d'autres encore, chacun avec son propre nom et sa propre documentation.² Le jeton partagé remplace ces lignes répétées par une seule, que plusieurs fournisseurs s'engagent à lire de la même façon.

Le filet de sécurité pour Google-Extended

Google a précisé un détail pour les sites qui ont déjà configuré Google-Extended : si un site utilise le nouveau jeton pour refuser l'entraînement sans mentionner explicitement Google-Extended, Google prévoit de traiter cela comme si le site avait refusé Google-Extended.¹ Les contrôles propres à chaque fournisseur continuent de fonctionner à côté du nouveau jeton commun : un site peut garder un réglage général avec le jeton partagé, tout en ajustant son choix pour un fournisseur précis via son propre contrôle, comme les réglages robot par robot décrits dans le guide de la Generative Engine Optimization.¹

02Ce que le jeton laisse de côté

Le brouillon de l'IETF et les contrôles existants de Google et Microsoft tracent une frontière nette entre trois usages : l'exploration du site, l'entraînement des modèles et l'apparition dans une réponse générée. Le nouveau jeton ne couvre que le second.³

L'exploration et l'indexation ne changent pas

Le brouillon de l'IETF précise que ce jeton de politique n'est pas une directive pour le comportement d'exploration, et qu'il reste indépendant des règles d'exploration propres à chaque robot : un robot continue d'appliquer les règles écrites pour son propre nom d'agent, exactement comme avant.³ Côté Google, sa documentation des robots précise que Google-Extended, le contrôle qu'il opère depuis 2023 pour l'entraînement des modèles Gemini, n'a aucun effet sur l'inclusion d'un site dans la Recherche Google ni sur son classement.⁴ Le jeton partagé, pensé pour fonctionner comme Google-Extended, hérite de cette même limite : il ne touche pas à Googlebot ni à l'indexation.

Chez Google, l'ancrage dans Gemini reste un réglage à part

La documentation de Google précise que Google-Extended couvre à la fois l'entraînement des futurs modèles Gemini et l'ancrage (grounding), c'est-à-dire la fourniture de contenu de l'index de Recherche au modèle au moment de la requête, pour les réponses de Gemini Apps et de Vertex AI.⁴ Les sites qui autorisent explicitement Google-Extended restent éligibles à apparaître dans les réponses ancrées de Gemini Apps et à y recevoir des clics.¹ Un site qui veut rester cité dans les réponses ancrées de Gemini tout en refusant l'entraînement doit donc continuer à régler Google-Extended spécifiquement, le jeton partagé seul ne suffisant pas à distinguer les deux usages chez Google.

Chez Microsoft, l'entraînement et l'ancrage se règlent séparément

Microsoft va plus loin en séparant explicitement les deux usages. Sa documentation distingue une préférence d'entraînement (AI Training), réglée dans le robots.txt avec le jeton partagé ou à la page, d'une préférence d'ancrage (AI Grounding), réglée uniquement à la page par une balise meta ou un en-tête X-Robots-Tag, sans équivalent au niveau du site entier dans le robots.txt.⁵ Un site peut ainsi refuser l'entraînement tout en laissant Copilot citer ses pages, ou l'inverse ; aucun des deux choix ne change son éligibilité aux résultats de recherche Bing classiques.⁵

03Calendrier et réglage pour une PME

Les quatre éditeurs n'avancent pas au même rythme, et seul Microsoft a fixé une échéance ferme assortie d'une date limite pour les sites qui utilisent encore ses anciennes balises.⁵

Le calendrier annoncé

Le brouillon reste un texte individuel à l'IETF, sans statut formel dans le processus de normalisation : sa formulation, sa portée et sa syntaxe peuvent encore changer avant qu'il ne devienne un standard.³²

L'échéance ferme : les sites sous NoArchive ou NoCache chez Microsoft

Microsoft fixe un calendrier précis pour les sites qui utilisent encore ses anciennes balises NoArchive et NoCache, en place depuis 2023 pour contrôler l'entraînement et l'ancrage. Des préférences de transition temporaires s'ouvrent dans Bing Webmaster Tools le 15 décembre 2026, pour les sites concernés uniquement. Les nouvelles préférences prennent effet au fil des explorations à partir du 1^er février 2027. Les sites qui veulent conserver leurs restrictions doivent publier leurs nouvelles préférences et, pour l'ancrage, enregistrer une préférence de transition dans Bing Webmaster Tools, avant le 1^er mars 2027 : après cette date, NoArchive et NoCache ne sont plus lus comme une préférence d'entraînement ou d'ancrage. Les préférences de transition elles-mêmes expirent le 30 septembre 2027.⁵

Le réglage à envisager pour une PME

Pour une PME qui n'a pas encore de contrôle spécifique à l'IA dans son robots.txt, rien n'oblige à agir avant la mise en service annoncée par chaque éditeur : les contrôles actuels, propres à chaque fournisseur, restent valables en attendant.¹ Pour préparer le terrain, le test d'accès des robots IA montre robot par robot ce que le fichier actuel autorise, et le générateur de robots.txt écrit les lignes du jeton partagé une fois le choix arrêté. Pour un site qui veut rester cité par Gemini ou par Copilot, le choix se pose moins en bloc qu'éditeur par éditeur : refuser l'entraînement avec le jeton partagé n'empêche pas, chez Google comme chez Microsoft, de garder un réglage distinct pour apparaître dans les réponses ancrées.

04Questions fréquentes