OpenAI introduit un signal partagé dans robots.txt pour les préférences de formation IA

OpenAI a annoncé le 30 octobre 2026 qu’il allait reconnaître un nouveau signal dans le fichier robots.txt. Ce signal, appelé __usage_ai‑trainingTrainingProcessus durant lequel un modèle ajuste ses paramètres à partir de données afin d'améliorer ses performances., permet aux éditeurs de sites web d’indiquer une préférence unique – par exemple « ne pas utiliser mon contenu pour entraîner des modèles génératifs » – à plusieurs fournisseurs 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. simultanément. L’objectif est de simplifier la gestion des règles, qui devait jusqu’à présent être définie séparément pour chaque crawler.

Pourquoi un signal partagé ?

Jusqu’à présent, chaque acteur – Google, Microsoft, Anthropic, etc. – possède son propre user‑agent (GPTBot, ClaudeBot, etc.) et les webmestres doivent maintenir une liste de directives distinctes dans le robots.txt. Cette multiplication de règles complique la tâche, surtout pour les sites qui publient de nombreux répertoires. Le signal partagé repose sur un Internet‑Draft (draft‑kelley‑aipref‑training‑preference‑signal‑00) qui introduit un tokenTokenUnité de contenu traitée par un modèle de langage, pouvant représenter un mot, une partie de mot ou un caractère. de politique utilisable dans la ligne User‑Agent du fichier. Le token __usage_ai‑training n’ajoute aucune nouvelle syntaxe au standard RFC 9309, ce qui signifie que les analyseurs existants continueront d’interpréter les directives habituelles et ignoreront simplement les groupes qu’ils ne reconnaissent pas.

Fonctionnement technique

Le draft propose d’associer le token à des chemins précis, par exemple :

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

Cette configuration indique que le contenu du site ne doit pas servir à l’entraînement IA, à l’exception du répertoire /press‑kit/. Les groupes génériques (*User‑Agent: ***) ne sont pas considérés comme correspondant au token, évitant ainsi toute ambiguïté. Si le token n’apparaît pas dans le fichier, aucune préférence n’est exprimée.

Le signal ne dicte pas le comportement de crawl – il ne bloque pas l’accès – mais il exprime une préférence d’usage. Les accords privés entre éditeur et fournisseur peuvent toutefois primer, comme le souligne le draft.

Le contexte IETF et les vocabulaires

Le token s’appuie sur le vocabulaire élaboré par le groupe de travail IETF AI Preferences (draft‑ietf‑aipref‑vocab‑08). Ce vocabulaire définit trois catégories d’usage : AI Training (utilisation pour ajuster les paramètres d’un modèle génératif), AI Use (entrée dans un modèle génératif) et Search (recherche d’actifs). Chaque catégorie reçoit une valeur : allowed, disallowed ou unknown. En cas de conflit, la préférence la plus restrictive prévaut.

Il faut préciser que le vocabulaire ne garantit pas le respect des préférences ; il laisse le choix de les appliquer à chaque participant. Le draft indique également qu’une conformité complète impliquerait de transmettre les préférences associées aux actifs d’entraînement lorsqu’un modèle est redistribué, un point encore en discussion.

Ce que cela change pour les webmestres

• Simplification : une seule ligne User‑Agent suffit pour couvrir tous les fournisseurs qui adoptent le signal.
• Granularité : il reste possible de préciser des exceptions par chemin, comme le montre l’exemple Allow.
• Compatibilité : les analyseurs qui ne comprennent pas le token continuent d’appliquer les règles classiques, donc aucune régression attendue.

OpenAI maintient cependant ses contrôles existants via les directives User‑Agent classiques (GPTBot, OAI‑SearchBot, etc.). Les webmestres peuvent ainsi désactiver spécifiquement le crawl de formation tout en laissant le site visible dans les recherches ChatGPT, par exemple. Les changements de configuration prennent généralement 24 heures à se propager.

Limitations et perspectives

Le mécanisme reste volontaire : chaque fournisseur doit décider de le reconnaître. OpenAI encourage les autres acteurs à suivre l’exemple, mais aucune contrainte juridique ne l’impose. De plus, le draft expirera le 3 mai 2027, ce qui implique qu’une version finalisée devra être adoptée pour garantir la pérennité du signal.

En pratique, le signal ne résout pas les cas où un tiers récupère du contenu en dehors du cadre du crawl officiel (par exemple, via des archives publiques). Il constitue surtout un outil de communication entre éditeur et fournisseurs d’IA, visant à rendre le web plus prévisible quant à l’usage de ses données.

Pour les sites qui souhaitent tester cette approche, il suffit d’ajouter le groupe correspondant dans le robots.txt et de surveiller les rapports de trafic pour vérifier que les crawlers concernés respectent la préférence. OpenAI promet de publier les détails d’implémentation dans les mois à venir, ce qui devrait aider les administrateurs à automatiser la mise à jour.

En résumé, le signal partagé représente une avancée vers une gouvernance plus claire du contenu web face à l’apprentissage automatiqueMachine LearningBranche de l'intelligence artificielle permettant à des systèmes d'apprendre des relations à partir de données plutôt que de suivre uniquement des règles programmées., tout en restant compatible avec les pratiques actuelles du protocole robots.txt.