10 min de lecture - Préférences communes d’entraînement de l’IA : décidez avant de modifier robots.txt

Les responsables de sites pourront peut-être bientôt déclarer une préférence unique pour l’entraînement de l’IA, au lieu d’entretenir une règle par fournisseur participant. Le 30 octobre 2026, OpenAI, Google et Microsoft ont chacun annoncé leur soutien à un signal commun dans robots.txt. Ce mécanisme repose sur un jeton de politique nommé __usage_ai-training.

La modification semble mineure. Elle traduit pourtant un choix de politique éditoriale qui produit des effets techniques. L’entraînement, l’exploration, l’indexation dans un moteur de recherche et l’ancrage d’une réponse générée correspondent à des usages différents ; le signal proposé n’en couvre qu’un. Il provient aussi d’un Internet-Draft précoce, tandis que les trois fournisseurs annoncent des calendriers et des règles propres à leurs produits.

Pour une startup ou une PME, le travail commence avant que l’équipe technique n’ajoute la moindre ligne : décidez quels contenus peuvent servir à quels usages, qui peut trancher et comment vérifier que la politique publiée reflète toujours cette décision.

Ce qui a été annoncé, et ce qui n’est pas encore actif

Dans son annonce du 30 octobre, OpenAI s’engage à respecter le signal commun pour l’entraînement des modèles de fondation d’IA générative. L’entreprise vise une mise en œuvre dans les prochains mois ; ses contrôles actuels dédiés aux robots resteront applicables. Cette annonce décrit donc une évolution prévue, pas la preuve que le jeton commun gouverne déjà les systèmes d’OpenAI.

L’annonce de Google Search Central vise 2027. Google prévoit d’interpréter un refus exprimé par le jeton commun comme un refus pour Google-Extended, à condition que le site ne précise pas Google-Extended séparément. Une règle Google propre peut rester aux côtés de la préférence générale.

Microsoft publie des dates plus précises dans son guide Bing destiné aux éditeurs. L’entreprise prévoit de respecter les nouvelles préférences au fil de l’exploration à partir du 1er février 2027. Les sites qui utilisent aujourd’hui NoArchive ou NoCache pour les choix d’entraînement ou d’ancrage chez Microsoft disposent d’une transition qui se termine le 1er mars 2027. Microsoft ajoute par ailleurs des réglages d’ancrage distincts au niveau de la page ; ils ne font pas partie du jeton commun consacré à l’entraînement.

Ces trois sources primaires établissent des engagements. Elles ne fixent ni date d’activation commune ni périmètre identique. Une modification déployée maintenant doit cohabiter avec les contrôles actuels jusqu’à ce que chaque fournisseur confirme son implémentation.

Le projet exprime une préférence, pas un blocage réseau

Le mécanisme figure dans le registre de l’IETF sous le titre Machine-Readable Training Preference Signal, daté du 30 octobre 2026. Le registre le qualifie d’Internet-Draft individuel, sans statut formel dans le processus de normalisation de l’IETF. Il peut changer, être remplacé ou expirer ; la version actuelle arrive à échéance le 3 mai 2027. Son auteur, Kevin Kelley (Anthropic), l’a présenté sur la liste de diffusion du groupe de travail AI Preferences de l’IETF comme une contribution aux travaux du groupe sur le rattachement des préférences. Il y indique qu’Anthropic a commencé à mettre en œuvre cette prise en charge, en complément des contrôles de robots qu’Anthropic propose déjà.

Son exemple tient en quelques lignes :

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

Selon le projet, ce bloc exprime un refus de l’entraînement de l’IA générative pour l’ensemble du site et une préférence favorable sous /press-kit/. La syntaxe connue Allow et Disallow est réutilisée, mais le jeton désigne une finalité, pas un robot. Un groupe générique User-Agent: * ne lui correspond pas. En l’absence de groupe contenant le jeton, le site n’exprime aucune préférence.

Le projet précise aussi que ce jeton ne donne aucune instruction sur le comportement d’exploration. Selon notre lecture, un fournisseur pourrait donc continuer à récupérer une page pour la recherche tout en respectant le refus de l’utiliser pour modifier les paramètres appris d’un modèle génératif. Si le site veut aussi restreindre l’accès d’un robot nommé, il lui faut une règle dédiée à ce robot.

Dans la version actuelle, des accords privés peuvent primer sur la préférence. Il faut donc examiner contrats, licences et conditions de plateforme au lieu de considérer qu’un fichier public règle toutes les relations.

Séparez quatre décisions avant la mise en production

Une case intitulée « Refuser l’IA » fusionnerait des questions qui exigent des responsables et des preuves différents.

Le marketing peut vouloir préserver la visibilité, alors que l’équipe juridique peut constater des droits incomplets. L’équipe web connaît les chemins publics ; les responsables produit connaissent les contenus de clients ou de partenaires. Ces points de vue doivent être réunis.

Avant de choisir la syntaxe, créez une carte simple des droits. Pour chaque classe de contenu, consignez son propriétaire, sa source, les conditions applicables, les chemins publics, le traitement voulu dans les moteurs de recherche ainsi que les préférences d’entraînement et d’ancrage. Incluez traductions, documents téléversés, contenus produits par les utilisateurs, apports de partenaires et archives. Une traduction française ne crée pas de nouveaux droits ; une URL publique n’autorise pas tous les usages ultérieurs.

Notre guide consacré à l’actif d’évaluation avant l’entraînement d’un modèle applique la même discipline aux données d’entrée : accès, droits et finalité permise doivent rester distincts.

Décidez par classe de contenu, pas par nom de fournisseur

Les fournisseurs changeront. Commencez par les catégories de contenu que l’organisation peut défendre.

Un manuel public peut viser la découverte et les citations, alors que son propriétaire refuse l’entraînement. Un portail client doit dépendre d’une authentification, pas de préférences volontaires dans robots.txt. Un forum peut mêler la prose de l’entreprise et des contributions régies par d’autres conditions.

Ces différences peuvent conduire à refuser l’entraînement par défaut tout en autorisant un espace presse approuvé. L’organisation doit décider après avoir vérifié propriété, objectifs commerciaux et accords existants.

Bloquer tous les robots peut supprimer un accès légitime sans démontrer la suppression des contenus déjà collectés. Tout autoriser au nom du trafic peut envoyer un signal plus large que prévu. Le jeton isole un usage, mais seuls les acteurs qui l’adoptent sont censés l’interpréter.

Gérez robots.txt comme une configuration de production

De nombreux sites produisent robots.txt depuis le code de l’application, une extension SEO, une règle de CDN ou un modèle de déploiement. Une modification manuelle dans une console peut disparaître à la livraison suivante. La politique a donc besoin d’une source de vérité et d’un test.

Appliquez un processus de modification limité :

1. Recensez chaque système capable d’émettre ou de réécrire robots.txt, les balises meta et les en-têtes X-Robots-Tag.
2. Faites approuver une matrice chemin-finalité par des responsables nommés pour le contenu, la technique et les droits.
3. Conservez les règles propres à chaque fournisseur tant que le support commun annoncé reste en attente, sauf décision contraire du responsable compétent.
4. Vérifiez automatiquement le fichier déployé et un échantillon d’en-têtes de pages ; testez l’hôte de production ainsi que le fichier du dépôt.
5. Planifiez des revues aux jalons de mise en œuvre des fournisseurs et lors de chaque évolution du projet IETF.

Le test doit repérer les absences et les conflits. Analysez le fichier selon la règle de correspondance la plus longue de la RFC 9309, que le projet conserve, vérifiez les chemins sensibles et signalez les groupes générés qui se contredisent. Confirmez aussi que les pages importantes pour la recherche gardent les règles d’exploration voulues. Chez Microsoft, les sites qui s’appuient sur l’ancien traitement NoArchive ou NoCache doivent contrôler la transition séparément avant mars 2027.

Conservez un instantané rendu et la trace de l’approbation avec chaque livraison afin de pouvoir auditer la politique plus tard.

Mesurez ce qui change après l’activation

Le signal ne promet ni suppression, ni paiement, ni trafic, ni présence dans une réponse d’IA. Microsoft précise qu’autoriser l’ancrage rend un contenu éligible à ses réponses d’IA, mais qu’aucun des deux choix, entraînement ou ancrage, ne garantit présence, trafic ou paiement. La documentation de Google sur ses robots indique que Google-Extended n’a aucun effet sur l’inclusion ni sur le classement dans Google Search. OpenAI n’a pas encore publié les détails de son implémentation.

Mesurez ce qui est observable : politique déployée, requêtes dans les journaux, indexation, trafic de référence et rapports de citations lorsqu’ils existent. Une baisse des requêtes ne prouve pas l’arrêt de l’entraînement ; le projet sépare récupération et usage.

Consignez les inconnues : support documenté, contrôles actifs, exceptions par chemin et résultats impossibles à vérifier. Notre guide de gouvernance IA portable applique cette logique : nommez le contrôle, son responsable, sa preuve et sa date de révision, au lieu de formuler une promesse générale de conformité.

Une décision réaliste pour ce trimestre

Les équipes peuvent recenser les droits, séparer les quatre décisions et préparer une configuration testée. Ne publiez le jeton que si les responsables approuvent son sens, si les contrôles existants restent cohérents et si l’équipe accepte un support encore progressif. Sinon, préparez une pull request et attendez le support documenté. Conservez les règles actuelles jusqu’à la vérification de leurs remplaçantes en production.

Un jeton commun réduit la répétition de configuration. La propriété des contenus, l’examen des contrats, la stratégie de recherche et les tests de déploiement restent des chantiers distincts ; la politique chemin-finalité derrière le fichier servira de nouveau lorsque les fournisseurs changeront leurs règles.

Découvrez les services IA et d’ingénierie d’Exceev si votre équipe doit cartographier les usages, transformer la décision en configuration web testée ou bâtir un dossier de preuves pour les prochaines évolutions des fournisseurs.

Sources et limites

Nous avons ouvert et vérifié toutes les sources ci-dessous le 2 novembre 2026. Le message de la liste de l’IETF et la documentation de Google sur ses robots ont été ajoutés le 4 novembre 2026.

• L’annonce d’OpenAI établit son soutien prévu, son calendrier actuel et le maintien de ses contrôles propres aux robots.
• L’annonce de Google Search Central établit son objectif pour 2027 et l’articulation prévue entre le signal commun et Google-Extended.
• Le guide Bing de Microsoft établit ses dates, les réglages au niveau de la page, la distinction de l’ancrage et la transition depuis NoArchive et NoCache.
• Le registre et l’Internet-Draft de l’IETF définissent le jeton proposé, les règles de correspondance et leurs limites. Ce texte reste un travail en cours, pas une norme approuvée par l’IETF.
• Le message de Kevin Kelley sur la liste de l’IETF présente le projet et indique qu’Anthropic a commencé à mettre en œuvre sa prise en charge.
• La documentation de Google sur ses robots indique que Google-Extended n’a aucun effet sur l’inclusion ni sur le classement dans Google Search.

Nous n’avons testé aucune implémentation non publiée, inspecté aucun système d’entraînement ni vérifié les contrats et les droits d’un site. Les engagements des fournisseurs, la syntaxe du projet et les dates peuvent changer. La matrice, le processus de modification et le plan de mesure relèvent de l’analyse d’Exceev, pas des exigences des organisations citées. Cet article fournit des repères techniques et opérationnels ; il ne constitue pas un avis juridique et ne prouve pas qu’une préférence publiée crée un droit opposable dans une juridiction donnée.