Retour au blog
robots.txt : un signal commun pour l’entraînement des IA, et les décisions qu’il impose aux marchands
3 novembre 2026SEO

robots.txt : un signal commun pour l’entraînement des IA, et les décisions qu’il impose aux marchands



Le 30 octobre 2026, trois annonces sont tombées le même jour. Sur son blog Search Central, Google a indiqué qu’il prendra en charge un contrôle commun de l’entraînement des IA dans robots.txt ; OpenAI a publié un billet dans le même sens ; Microsoft a détaillé son calendrier pour Bing. Le point commun : un même jeton, défini dans un brouillon de l’IETF rédigé chez Anthropic et publié ce jour-là, que chaque fournisseur participant s’engage à lire de la même manière.


Ce qui change concrètement


Jusqu’ici, un marchand qui voulait tenir ses contenus à l’écart de l’entraînement des modèles devait entretenir une liste de jetons propriétaires : Google-Extended chez Google depuis 2023, GPTBot chez OpenAI, les balises NoArchive et NoCache chez Microsoft, et une ligne de plus à chaque nouvel acteur. Le brouillon de l’IETF propose à la place un jeton de politique unique, __usage_ai-training, qui s’écrit comme un groupe robots.txt ordinaire :


  • User-Agent: __usage_ai-training
  • Disallow: /
  • Allow: /presse/

Lu par un fournisseur participant, ce groupe exprime une préférence contre l’entraînement sur tout le site, sauf le dossier presse. La grammaire est celle du RFC 9309 : mêmes règles de chemin, même priorité à la correspondance la plus longue, aucune directive nouvelle à apprendre.


Trois précisions comptent pour un architecte.


  • Ce n’est pas une règle de crawl. Le jeton n’apparaît jamais dans l’en-tête d’un robot ; il décrit un usage, pas un accès. Pour limiter l’exploration, les groupes Googlebot, Bingbot ou GPTBot restent la bonne couche.
  • Le groupe générique ne compte pas. Un robots.txt qui interdit seulement le panier et le compte client sous l’étoile n’exprime aucune préférence d’entraînement. Il faut nommer le jeton.
  • Sans le jeton, aucune préférence n’est exprimée. Les fournisseurs appliquent alors leurs règles habituelles, et un jeton propriétaire garde son sens propre.

Entraînement n’est pas visibilité


C’est le piège principal pour un e-commerçant. Le jeton couvre une seule chose : l’entraînement, défini par l’IETF comme l’utilisation d’un contenu pour modifier les paramètres appris d’un modèle génératif. Il ne dit rien de la recherche classique, des réponses générées à partir du web (ce que les fournisseurs appellent le grounding) ni des agents d’achat qui lisent votre catalogue en direct.


Les fournisseurs relient pourtant les deux, chacun à sa façon. Google précise qu’un site qui refuse l’entraînement via le jeton commun sans mentionner Google-Extended sera traité comme s’il avait interdit Google-Extended ; or seuls les sites qui autorisent explicitement Google-Extended restent éligibles aux réponses et aux clics issus du grounding dans les applications Gemini. Refuser l’entraînement chez Google peut donc coûter de la présence dans Gemini. Microsoft sépare au contraire les deux usages : l’entraînement se règle dans robots.txt ou page par page, le grounding uniquement page par page, avec une option intermédiaire, DisallowExtended, qui réserve vos contenus aux expériences Microsoft (Copilot, AI Mode, Microsoft 365) et les retire des services tiers. Microsoft prévient qu’un refus du grounding réduira la visibilité de la marque dans ses expériences IA, sans toucher aux résultats classiques de Bing.


Pour un marchand, la question n’est donc pas « bloquer ou non les IA », mais : quels contenus ont une valeur d’entraînement que vous ne voulez pas céder (guides d’achat, comparatifs, photos, avis), et quelle présence dans les assistants vous ne voulez pas perdre (fiches produit, stock, prix) ?


Le calendrier


  • Google vise une prise en charge en 2027, aux côtés des autres fournisseurs ; Google-Extended continue de fonctionner en parallèle.
  • OpenAI annonce un déploiement dans les prochains mois et confirme que ses contrôles existants restent respectés.
  • Microsoft applique les nouvelles préférences à partir du 1er février 2027. Au 1er mars 2027, NoArchive et NoCache ne seront plus lus comme préférences d’entraînement ou de grounding : les sites qui s’en servaient doivent publier des préférences page par page avant cette date, et un réglage transitoire pour le grounding ouvrira dans Bing Webmaster Tools le 15 décembre 2026. Les deux préférences valent Autoriser par défaut.
  • Côté normes, le texte reste un brouillon qui expire le 3 mai 2027, et les discussions sur le reste du vocabulaire de l’IETF continuent. Google souligne que l’approche est cohérente avec le code de bonnes pratiques européen pour les modèles d’IA à usage général, qui reconnaît robots.txt comme moyen privilégié d’exprimer ces préférences.

Que faire sur une boutique Magento ou Adobe Commerce


  1. Inventorier l’existant. Sur Magento 2 et Adobe Commerce, robots.txt se modifie dans l’administration, à l’échelle du site web, dans la configuration du design ; en multi-sites, chaque domaine a le sien. Relevez aussi les balises meta robots et les en-têtes X-Robots-Tag posés par le thème, les modules SEO et le CDN : ils se contredisent souvent.
  2. Décider par zone, pas par site. Catalogue, contenu éditorial, espace B2B, médias : chaque zone mérite sa propre réponse, écrite avec le marketing et le juridique, puis versionnée avec le code.
  3. Ne rien retirer avant 2027. Les lignes Google-Extended, GPTBot et consorts restent valables ; le jeton commun s’ajoute, il ne remplace rien, et un fournisseur peut traiter son propre jeton comme plus spécifique.
  4. Traiter les vitrines découplées. Sur un front headless, Edge Delivery ou Next.js, robots.txt n’est plus servi par Magento : le fichier et les en-têtes relèvent de l’équipe front et du CDN. Il faut un propriétaire unique.
  5. Mesurer. Journalisez les passages des robots IA avant et après, et suivez les visites venues des assistants ; c’est la seule façon d’estimer le coût réel d’un refus.

Le jeton commun simplifie l’écriture de la préférence ; il ne décide pas à votre place. L’arbitrage entre protection des contenus et présence dans les assistants est une décision d’architecture et de direction, à prendre maintenant, pendant que les fournisseurs laissent le temps de la préparer.


Je peux vous aider.

Discutons de votre projet.