Google, Microsoft et OpenAI s’accordent sur un signal commun dans robots.txt pour encadrer l’entraînement des IA

Le 30 octobre 2026, Google a annoncé qu’il allait prendre en charge un nouveau mécanisme de contrôle partagé pour l’entraînementTrainingProcessus durant lequel un modèle ajuste ses paramètres à partir de données afin d'améliorer ses performances. des intelligences artificielles, à intégrer directement dans le fichier robots.txt. L’idée est simple : offrir aux éditeurs de sites web une façon unique d’exprimer leurs préférences vis‑à‑vis de l’utilisation de leurs contenus pour entraîner les modèles d’IAIntelligence artificielleEnsemble de techniques permettant à des machines d'accomplir des tâches nécessitant habituellement certaines capacités humaines, comme la reconnaissance, la prédiction ou la prise de décision., quel que soit le fournisseur. Le même jour, Microsoft et OpenAI ont confirmé qu’ils allaient respecter ce signal.

Un mécanisme issu de l’IETF

Le contrôle repose sur le travail du groupe « AI Preferences » de l’Internet Engineering Task Force (IETF) et s’appuie sur le draft Machine-Readable Training Preference Signal (Kevin Kelley, Anthropic, 30 oct 2026). Le draft introduit un policy‑tokenTokenUnité de contenu traitée par un modèle de langage, pouvant représenter un mot, une partie de mot ou un caractère. nommé __usage_ai-training à placer dans la ligne User-Agent d’une section du robots.txt. Aucun nouveau mot‑clé n’est ajouté au standard RFC 9309 : les parseurs existants ignorent simplement les groupes qu’ils ne reconnaissent pas. Ainsi, un éditeur peut déclarer, par exemple :

User-Agent: *
Disallow: /

User-Agent: __usage_ai-training
Disallow: /
Allow: /press-kit/

Ce snippet indique que le site refuse toute utilisation de son contenu pour l’entraînement d’IA, à l’exception du répertoire /press‑kit/.

Ce que cela change pour les éditeurs

Actuellement, chaque acteur du secteur propose ses propres balises : Google utilise depuis 2023 le préfixe Google‑Extended, Microsoft avait introduit les tags NoArchive et NoCache, et OpenAI possède déjà ses propres contrôles de crawler. Le nouveau signal partagé permet de centraliser la plupart de ces déclarations. Un éditeur qui ajoute le token __usage_ai‑training avec la valeur Disallow indique, sans ambiguïté, qu’il ne souhaite pas que son site soit exploité pour entraîner les modèles des fournisseurs qui respectent le standard (Google, Microsoft, OpenAI et potentiellement d’autres à l’avenir).

Les contrôles spécifiques restent actifs. Un site peut donc continuer à affiner ses instructions : garder le token partagé pour une règle globale tout en ajoutant un groupe Google‑Extended pour préciser un traitement particulier avec le moteur de recherche Google. Cette double couche offre à la fois la simplicité d’un signal unique et la granularité nécessaire pour les accords particuliers.

Adoption progressive et dates clés

• Google prévoit de rendre le signal effectif en 2027, après une phase d’expérimentation et de mise à jour de ses crawlers. L’entreprise a souligné que ce dispositif s’inscrit dans le cadre du EU Code of Practice lié à l’AI ActAI ActRèglement de l'Union européenne établissant un cadre juridique pour les systèmes d'intelligence artificielle, notamment selon leurs usages et leurs niveaux de risque., qui reconnaît déjà robots.txt comme moyen principal d’expression des préférences des éditeurs.
• Microsoft a annoncé que le signal sera déployé à partir du 1er février 2027. En parallèle, la firme introduira des préférences de « groundingGroundingApproche consistant à relier les réponses d'une IA à des informations de référence pour améliorer leur pertinence et leur vérifiabilité. » au niveau des métadonnées et des en‑têtes HTTP, avec une option DisallowExtended qui limite l’usage du contenu aux expériences internes comme Copilot ou Microsoft 365.
• OpenAI s’engage à respecter le token dans les mois qui suivent, tout en maintenant ses contrôles de crawler actuels.

Ces calendriers laissent aux éditeurs un délai d’au moins six mois pour adapter leurs robots.txt avant que les nouveaux signaux ne deviennent opérationnels.

Implications concrètes

1. Transparence accrue – Les éditeurs n’ont plus besoin de suivre plusieurs documentations pour chaque fournisseur. Un seul fichier robots.txt suffit pour couvrir la majorité des grands acteurs IA.
2. Réduction de l’incertitude juridique – En s’appuyant sur un standard reconnu par l’UE, les sites peuvent plus facilement démontrer leur conformité aux exigences du AI Act.
3. Impact sur le référencement – Google indique que les sites qui autorisent le token Google‑Extended peuvent apparaître dans les réponses enrichies par les « Gemini Apps ». À l’inverse, un refus généralisé pourrait limiter la visibilité dans les services d’IA qui utilisent le grounding.
4. Limites – Le token ne contrôle pas le crawling en soi, seulement la préférence d’utilisation à des fins d’entraînement. Les moteurs restent libres de choisir de crawler ou non le site, sous réserve des directives classiques de robots.txt.

En résumé, la convergence autour d’un signal commun représente une étape importante vers une gouvernance plus cohérente du web face à l’essor des modèles génératifs. Les éditeurs qui souhaitent protéger leurs contenus – que ce soit pour des raisons de propriété intellectuelle, de monétisation ou de conformité – disposent désormais d’un outil plus simple et plus universel. Le véritable test sera la rapidité avec laquelle les autres fournisseurs d’IA adopteront le même protocole, mais l’engagement simultané de Google, Microsoft et OpenAI donne déjà le ton pour l’avenir du contrôle des données d’entraînement.