Un même signal pour un web fragmenté
Le titre résume bien l’enjeu: quatre géants unifient les refus d’entraînement IA. Le 30 octobre 2026, Google, Microsoft et OpenAI ont annoncé leur soutien à un signal commun dans robots.txt permettant aux éditeurs de sites d’exprimer leurs préférences sur l’utilisation de leurs contenus pour l’entraînement de l’IA générative, tandis que les développements publiés au même moment identifient Anthropic comme le quatrième acteur via Kevin Kelley, auteur chez Anthropic du projet technique sous-jacent .
Il ne s’agit pas d’un bouton universel dans les paramètres de chaque application grand public. Le mécanisme vise d’abord les opérateurs de sites web: médias, créateurs, marques, plateformes, bibliothèques numériques ou services hébergeant des contenus. Jusqu’ici, refuser l’entraînement IA obligeait souvent à gérer une liste de robots différents, avec des règles propres à chaque fournisseur. Cette fragmentation rendait le consentement difficile à exprimer et coûteux à maintenir.
Le changement proposé est donc simple dans son principe: au lieu d’écrire une règle pour GPTBot, une autre pour Google-Extended, une autre pour ClaudeBot et d’autres encore pour les services Microsoft, un site pourrait publier une préférence commune que les fournisseurs participants s’engagent à lire. Cette promesse ne règle pas tout, mais elle transforme un problème de bricolage permanent en début d’interface standardisée.
Le jeton __usage_ai-training
Le cœur du dispositif est un jeton de politique nommé __usage_ai-training, défini dans l’Internet-Draft intitulé “Machine-Readable Training Preference Signal,” mis à jour le 30 octobre 2026 . Un site peut utiliser ce jeton dans un groupe ordinaire de son fichier robots.txt, puis employer les directives habituelles Allow et Disallow pour exprimer une préférence par chemin ou pour l’ensemble du site . En clair, User-Agent: __usage_ai-training suivi de Disallow: / signifie que l’opérateur ne souhaite pas que le site soit utilisé pour l’usage d’entraînement couvert par le jeton.
Le détail technique est important: le projet ne crée pas une nouvelle grammaire. Il s’appuie sur la structure existante de robots.txt, notamment la correspondance des chemins et les règles de priorité, tout en ajoutant une étiquette fondée sur l’usage dans la ligne User-Agent . Le texte précise aussi qu’un groupe générique comme User-Agent: * ne doit pas être interprété comme correspondant au nouveau jeton, et que l’absence du jeton signifie qu’aucune préférence commune d’entraînement n’a été exprimée .
Autre point essentiel: le signal concerne l’usage, pas nécessairement l’accès. Le projet indique que ce jeton n’est pas une directive de crawl et que les règles propres aux robots continuent de fonctionner indépendamment . Un éditeur peut donc vouloir rester accessible aux moteurs de recherche ou aux systèmes de réponse qui citent les sources, tout en refusant que le contenu serve à modifier les paramètres d’un modèle futur. C’est précisément cette distinction que le nouveau signal cherche à rendre lisible par machine.
Une convergence, mais pas une mise en œuvre identique
L’accord entre les quatre entreprises est réel, mais les calendriers et les effets diffèrent. Google explique que lorsqu’un site utilise le signal commun pour refuser l’entraînement et ne précise pas explicitement Google-Extended, l’entreprise prévoit de l’interpréter comme si l’éditeur avait interdit Google-Extended . Google indique aussi que les contrôles spécifiques existants continueront de fonctionner et vise une prise en charge en 2027 . Les informations actuelles rapportent que la documentation de Google parle plus précisément du début 2027 .
Microsoft va plus loin dans la granularité. L’entreprise dit s’appuyer sur la préférence commune d’AI Training, mais ajoute une préférence séparée d’AI Grounding, afin que les éditeurs puissent distinguer l’entraînement de modèles futurs de l’utilisation d’un contenu pour informer une réponse générée dans Bing, Copilot ou Microsoft 365 . Microsoft prévoit de commencer à honorer les nouvelles préférences lors du crawl à partir du 1er février 2027 et demande aux sites utilisant NoArchive ou NoCache de migrer avant le 1er mars 2027 s’ils veulent maintenir leurs restrictions . Microsoft introduit aussi un réglage au niveau de la page qui peut remplacer la règle publiée au niveau du site dans robots.txt .
OpenAI adopte une position plus concise. L’entreprise dit qu’elle honorera le signal commun dans robots.txt, qualifie l’effort de volontaire et prévoit une mise en œuvre “dans les prochains mois” . OpenAI ajoute que ses contrôles de crawl existants continueront de s’appliquer et d’être respectés . Pour les éditeurs, cela signifie qu’il ne faut pas considérer le nouveau jeton comme immédiatement universel: tant que chaque fournisseur ne l’a pas déployé, les règles spécifiques à chaque service restent nécessaires.
Anthropic occupe une place particulière. L’Internet-Draft est signé par Kevin Kelley et mentionne Anthropic dans le bloc auteur . Les informations publiées sur l’annonce indiquent qu’Anthropic a commencé à mettre en œuvre le support du signal, sans donner de date publique de finalisation . Anthropic apparaît donc à la fois comme l’origine du projet technique et comme l’un des fournisseurs participants, même si le document reste un Internet-Draft individuel, et non une norme IETF adoptée .
Pourquoi c’est important
Pour les éditeurs, l’intérêt principal est la simplicité opérationnelle. Un signal commun réduit le coût de l’expression d’un refus d’entraînement auprès des fournisseurs qui le prennent en charge. Ce gain peut être important pour un grand groupe média avec des milliers de pages, mais aussi pour un petit créateur qui n’a ni équipe juridique ni spécialiste SEO permanent.
Pour les entreprises d’IA, le signal offre aussi une meilleure architecture de conformité. Google affirme que le projet répond aux demandes d’éditeurs, d’organisations de la société civile, de régulateurs et d’autres parties prenantes qui réclamaient des contrôles d’entraînement à l’échelle de l’industrie . Google rattache également cette proposition au Code de bonnes pratiques pour les modèles d’IA à usage général dans le cadre de l’AI Act européen, qui reconnaît robots.txt comme une méthode importante d’expression de préférences lisibles par machine .
Pour les utilisateurs et les créateurs, l’effet est indirect. Le mécanisme ne permet pas à une personne de retirer partout ses œuvres déjà copiées, republiées ou hébergées sur des plateformes tierces. Il permet d’abord à l’opérateur d’un domaine d’exprimer une préférence pour ce domaine. Mais à l’échelle du web, cette capacité peut réduire l’écart entre un droit théorique et une instruction effectivement lisible par les systèmes automatisés.
Les limites: volontariat, délais et données déjà absorbées
La première limite est juridique et institutionnelle. La page de l’IETF indique clairement que le document est un Internet-Draft, qu’un tel projet peut être soumis par n’importe qui, et qu’il n’a pas de statut formel dans le processus de normalisation de l’IETF . Le texte expire le 3 mai 2027 s’il n’est pas révisé ou remplacé . On parle donc d’une proposition crédible et soutenue par de grands acteurs, pas encore d’une norme mondiale finalisée.
La deuxième limite est l’application. Un signal dans robots.txt ne vaut que si les systèmes qui le lisent choisissent de le respecter. Le projet définit comment exprimer une préférence, mais ne crée pas de mécanisme d’audit, de sanction ou de rémunération . Microsoft précise de son côté que ses choix ne garantissent ni inclusion, ni trafic, ni paiement, et que restreindre le grounding peut réduire la visibilité dans les expériences d’IA .
La troisième limite est le calendrier. Google vise 2027, Microsoft commence le 1er février 2027, OpenAI parle des prochains mois et Anthropic a commencé sans date finale publique . Ajouter le jeton aujourd’hui peut donc servir de déclaration anticipée, mais pas encore de bouton immédiatement effectif chez tous les fournisseurs.
La quatrième limite concerne les données déjà ingérées. Les annonces officielles actuelles ne disent pas clairement que le signal supprimera les contenus déjà collectés ou inversera un entraînement déjà réalisé . L’interprétation prudente est donc que le jeton vise surtout les usages futurs, selon les calendriers techniques de chaque entreprise.
Ce que les sites devraient faire maintenant
La priorité n’est pas de supprimer les règles existantes. Google, Microsoft et OpenAI présentent le nouveau signal comme compatible avec les contrôles actuels, et Microsoft est le seul à fournir un calendrier détaillé de remplacement pour certains anciens réglages . Les opérateurs qui veulent refuser l’entraînement devraient ajouter le jeton commun, mais conserver les règles spécifiques par fournisseur tant que chaque mise en œuvre n’est pas effective et documentée.
Ils doivent aussi clarifier leur objectif: refuser l’entraînement, limiter le grounding, bloquer le crawl, ou combiner ces trois choix. Microsoft sépare désormais l’entraînement du grounding, alors que Google relie son interprétation du signal à Google-Extended, qui a aussi des effets sur l’éligibilité aux usages de grounding dans Gemini . Le même objectif éditorial peut donc demander des réglages différents selon le fournisseur.
L’importance de cette annonce dépasse la ligne ajoutée dans robots.txt. Elle montre que les refus d’entraînement IA commencent à devenir une couche d’infrastructure du web, plutôt qu’une négociation dispersée fournisseur par fournisseur. Le signal __usage_ai-training ne résout ni l’application, ni la rétroactivité, ni la rémunération. Mais s’il est largement adopté, il pourrait enfin donner aux préférences de confidentialité et de propriété intellectuelle une interface commune au lieu d’un labyrinthe de réglages incompatibles.
Commentaires
Sois le premier à commenter.