Robots.txt et IA : ce que le nouveau jeton change (ou non) pour les DSI

Le 30 octobre 2026, Kevin Kelley, ingénieur chez Anthropic, a déposé à l’IETF un brouillon de norme baptisé « Machine-Readable Training Preference Signal ». Google, Microsoft et OpenAI ont annoncé dans la foulée qu’ils respecteraient ce signal, aux côtés d’Anthropic. L’objectif affiché : remplacer la liste de robots à bloquer un par un (GPTBot chez OpenAI, Google-Extended chez Google, ClaudeBot chez Anthropic) par une préférence unique, valable pour tous les fournisseurs engagés. Pour les directions des systèmes d’information françaises, qui gèrent déjà des dizaines de sites et de sous-domaines, la promesse de simplification est réelle. Mais elle ne doit pas masquer la nature exacte de l’outil : un signal volontaire, sans aucune force contraignante, qui ne couvre ni les obligations de protection des données ni la sécurité des contenus déjà collectés.

Un jeton unique pour remplacer une liste de robots à bloquer un par un

Techniquement, le dispositif ajoute un nouveau jeton, __usage_ai-training, que l’éditeur place dans la ligne User-Agent de son fichier robots.txt, comme on le fait déjà avec le nom d’un robot. Un Disallow sous ce jeton exprime un refus de l’entraînement, un Allow exprime un accord, et les deux se combinent chemin par chemin. Un site peut ainsi refuser l’entraînement sur l’ensemble de ses pages tout en l’autorisant pour un espace presse, selon l’exemple donné par le texte lui-même :

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

Le texte reprend la définition de l’entraînement retenue par le groupe de travail AI Preferences (AIPREF) de l’IETF, centrée sur les modèles d’IA générative. Le brouillon doit expirer le 3 mai 2027 si aucune nouvelle version n’est publiée d’ici là, signe qu’il s’agit à ce stade d’une proposition individuelle, pas encore d’un standard adopté.

Un déploiement étalé jusqu’en 2027, sans harmonisation réelle des calendriers

Les quatre entreprises n’appliquent pas le signal selon le même rythme, ce qui complique d’emblée toute lecture simple du dispositif pour un service juridique ou une direction conformité.

Apple, Amazon et Meta ne se sont pas engagés à respecter ce jeton. Rien n’oblige non plus les robots qui ignorent déjà le robots.txt à commencer à le lire.

Trois usages distincts, trois réglages distincts

Le signal ne règle qu’un seul aspect de l’exploitation d’un site par une IA : l’entraînement des modèles. Il ne concerne ni l’indexation dans les résultats de recherche classiques, ni le « grounding », c’est-à-dire l’usage d’une page en direct pour nourrir une réponse générée. Microsoft précise ainsi que les sites restent éligibles aux résultats de Bing quel que soit leur choix sur l’entraînement, et gère le grounding via une balise ou un en-tête HTTP distincts, page par page. Pour un éditeur qui souhaiterait un blocage global, cette segmentation impose de multiplier les réglages plutôt que de se reposer sur une seule ligne.

Les limites que le texte lui-même reconnaît

Le brouillon IETF énonce ses propres limites sans ambiguïté. D’une part, le jeton ne bloque pas l’exploration : il est décrit comme indépendant des règles visant les robots, qui continuent de s’appliquer comme avant. D’autre part, il ne concerne que les contenus récupérés après son ajout : il ne retire rien des modèles déjà entraînés, et n’est donc pas rétroactif. Surtout, l’engagement repose sur la seule parole des fournisseurs. OpenAI le présente lui-même comme une démarche volontaire, et aucun mécanisme de contrôle ni de sanction n’est prévu. Un éditeur n’a aucun moyen de vérifier qu’un contenu refusé n’a pas servi à entraîner un modèle. Pour un site qui veut un blocage réellement effectif, la gestion fine des robots et les pare-feu applicatifs restent les seuls moyens techniques disponibles, en complément du robots.txt.

Ce que le RGPD exige, et que ce signal ne peut pas apporter

C’est là que l’angle technique rejoint une question de droit que les communications des quatre entreprises passent sous silence. Google présente d’ailleurs ce dispositif comme cohérent avec le code de bonnes pratiques de l’AI Act européen, qui reconnaît le robots.txt comme un moyen d’exprimer ses préférences. Cette référence mérite d’être lue avec précision : un code de bonnes pratiques rattaché à l’AI Act n’est pas le RGPD, et l’expression d’une préférence sur l’usage d’un contenu pour l’entraînement d’un modèle n’a rien à voir avec une base légale de traitement de données personnelles.

Or un site web contient fréquemment des données personnelles : noms de contacts, témoignages clients, commentaires, formulaires archivés. Si un robot d’entraînement collecte ces pages, la question de la licéité du traitement au sens de l’article 6 du RGPD se pose indépendamment de ce que dit le robots.txt. Un refus exprimé via le jeton __usage_ai-training n’est ni une mesure de sécurité au sens de l’article 32, ni l’exercice d’un droit d’opposition au sens de l’article 21 : c’est une préférence déclarative, sans effet juridique opposable à une entreprise qui ne s’y engage pas, et sans garantie de respect même pour celles qui s’y engagent. Un délégué à la protection des données ne peut donc pas s’appuyer sur ce signal pour documenter une mesure de conformité, ni pour répondre à une demande d’un responsable du traitement sur le sort des données déjà collectées avant son ajout.

Cette distinction compte d’autant plus que les éditeurs qui adoptent le signal sont invités à conserver en parallèle leurs règles spécifiques (GPTBot, Google-Extended, ClaudeBot) : le nouveau jeton s’ajoute à l’existant, il ne le remplace pas, et ne constitue en rien une protection unique et suffisante.

Quelles mesures compléter côté DSI

Pour une direction informatique française, trois réflexes restent nécessaires indépendamment de ce signal. D’abord, documenter les flux réels de données vers des modèles tiers, au-delà de la simple préférence d’entraînement : un contenu autorisé pour l’entraînement peut rester soumis au grounding, et inversement. Ensuite, s’appuyer sur des contrôles techniques opposables, comme un pare-feu applicatif ou une gestion fine des robots au niveau du serveur, puisque le robots.txt n’a, par nature, aucune valeur contraignante. Enfin, traiter séparément la question de la protection des données personnelles transmises à des modèles tiers lors de l’usage courant de l’IA en entreprise, qui ne relève pas du tout du même sujet que l’entraînement des modèles par des robots d’exploration. Sur ce dernier point, certains éditeurs français proposent des mécanismes de pseudonymisation avant l’envoi de requêtes à des modèles tiers : c’est le cas de Moon Blur, sur la plateforme Moon AI, qui remplace les données personnelles par des jetons avant transmission puis les rétablit au retour. Ce procédé étant réversible, il s’agit d’une pseudonymisation au sens de l’article 4, point 5, du RGPD, et non d’une anonymisation, ni d’une garantie de conformité en soi : il répond à un besoin différent de celui que cherche à couvrir le signal robots.txt, celui du traitement des requêtes envoyées en production, pas celui de l’entraînement des modèles sur des contenus publiés.

Questions fréquentes

Le jeton __usage_ai-training suffit-il à empêcher qu’un site soit utilisé pour entraîner une IA ?

Non. Il exprime une préférence lue uniquement par les entreprises qui s’y engagent, sans mécanisme de contrôle ni de sanction. Apple, Amazon et Meta ne s’y sont pas engagés, et les robots qui ignorent déjà le robots.txt continueront de l’ignorer.

Ce signal s’applique-t-il aux contenus déjà collectés avant son ajout ?

Non. Le brouillon précise que le jeton ne concerne que les contenus récupérés après son ajout. Il ne retire rien des modèles déjà entraînés sur des données antérieures.

Ajouter ce jeton suffit-il pour répondre à une obligation RGPD sur un site contenant des données personnelles ?

Non. Le signal porte sur l’usage d’un contenu pour l’entraînement d’un modèle, pas sur la licéité du traitement de données personnelles. Il ne constitue ni une base légale, ni une mesure de sécurité au sens de l’article 32 du RGPD, ni l’exercice d’un droit d’opposition.

Faut-il conserver les anciens réglages (GPTBot, Google-Extended) après avoir ajouté le nouveau jeton ?

Oui. Le nouveau signal s’ajoute aux contrôles existants et ne les remplace pas. Les éditeurs sont invités à maintenir leurs règles spécifiques par fournisseur en complément du jeton commun.