Aller au contenu
BrèvesBrève

robots.txt pour IA : un signal partagé pour l’entraînement

Un signal commun dans robots.txt permet d’exprimer une préférence d’entraînement IA à plusieurs fournisseurs à la fois.

Rudy Molinillo5 min de lecture
robots.txt pour IA : un signal partagé pour l’entraînement

OpenAI, Google, Microsoft et Anthropic convergent vers un même signal dans robots.txt pour les préférences d’entraînement IA. L’objectif est simple : permettre à un site d’indiquer en une seule règle si ses contenus peuvent être utilisés pour entraîner des modèles génératifs.

Ce mécanisme repose sur un brouillon de l’IETF publié le 30 octobre 2026. Il ne remplace pas tous les contrôles existants, mais il ajoute une couche commune, plus facile à maintenir pour les éditeurs, les marques et les équipes web.

Ce qui change concrètement

Jusqu’ici, un site devait souvent gérer des règles séparées selon les fournisseurs. Par exemple, OpenAI documente déjà GPTBot pour l’entraînement de modèles génératifs, tandis que Google utilise Google-Extended depuis 2023 pour le contrôle lié à l’entraînement de ses modèles. Cette logique reste possible, mais elle devient vite lourde quand plusieurs acteurs doivent être couverts.

Le nouveau mécanisme propose un signal partagé dans le fichier robots.txt. Selon OpenAI, il permet de communiquer la même préférence à plusieurs fournisseurs participants, sans maintenir une règle propre à chacun. The Verge rapporte qu’OpenAI, Google, Microsoft et Anthropic ont déclaré qu’ils restreindraient leurs crawlers d’entraînement lorsqu’ils rencontrent ce signal partagé.

Techniquement, le brouillon IETF draft-kelley-aipref-training-preference-signal-00 définit un policy token : __usage_ai-training. Il s’écrit dans une ligne User-Agent, mais il ne désigne pas un robot précis. Il sert à attacher une préférence d’usage à des chemins du site.

Point important : le brouillon IETF n’ajoute ni nouvelle directive, ni nouvelle grammaire. Les règles restent celles de robots.txt : groupes ordinaires, chemins, priorité au plus long chemin correspondant. Pour une équipe technique, cela limite la complexité. On ne découvre pas un nouveau langage : on réutilise le format déjà présent sur la plupart des sites.

Comment l'essayer

Le signal se place dans le fichier robots.txt, à la racine du site. Engadget donne l’exemple suivant : User-Agent: __usage_ai-training, puis Disallow: /, avec éventuellement Allow: /press-kit/ pour autoriser un répertoire précis. En pratique, cela permettrait de dire : pas d’entraînement IA sur l’ensemble du site, sauf sur un kit presse ou une zone volontairement ouverte.

OpenAI indique viser une implémentation dans les mois à venir. Google a annoncé son intention de prendre en charge ce contrôle partagé dans robots.txt sur la base des travaux de l’IETF. Selon Google, si un site utilise ce policy token pour refuser l’entraînement et ne mentionne pas explicitement Google-Extended, Google prévoit de l’interpréter comme un refus pour Google-Extended.

La disponibilité est donc progressive. The Verge indique qu’Anthropic a déjà adopté le signal, qu’OpenAI prévoit de l’implémenter dans les mois à venir, et que Google et Microsoft prévoient de le prendre en charge l’an prochain. Aucun prix n’est communiqué, car il s’agit d’un contrôle dans robots.txt, pas d’un produit commercial annoncé. Pour un site français, l’usage consiste simplement à publier ou modifier son fichier robots.txt, tout en tenant compte du calendrier d’adoption des fournisseurs.

Attention à ne pas confondre ce signal avec l’indexation classique. Engadget précise que ce nouveau champ n’empêche pas l’indexation Google Search. Il vise l’usage pour l’entraînement IA, notamment via Google-Extended pour Google, et non la présence d’une page dans les résultats de recherche.

Pour qui, et pour quoi faire

Le premier public concerné est celui des éditeurs de contenus : médias, blogs d’expertise, bases documentaires, organismes de formation, sites de marques, cabinets de conseil ou plateformes SaaS avec beaucoup de ressources publiques. Dès qu’un site publie des contenus originaux, la question de leur usage dans l’entraînement de modèles se pose.

Cas d’usage concret : une entreprise B2B publie des guides techniques, des études de cas et des livres blancs. Elle veut rester visible dans Google Search, mais ne souhaite pas que l’ensemble de son corpus serve à l’entraînement de modèles génératifs. Avec le signal partagé, son équipe web peut définir une règle globale de refus pour l’entraînement, puis autoriser certaines sections destinées à la diffusion large, comme un dossier de presse ou des pages institutionnelles.

Ce contrôle peut aussi aider les directions marketing et juridiques à clarifier leur politique. Au lieu d’une consigne vague, elles peuvent formaliser une préférence lisible par plusieurs fournisseurs. Cela ne remplace pas une stratégie de droit d’auteur, de licences ou de diffusion, mais cela donne un point d’application technique simple.

Limites et points de vigilance

Le premier point de vigilance est le statut du mécanisme. Le document IETF publié le 30 octobre 2026 est un brouillon, avec le statut Standards Track, et il expire le 3 mai 2027. Il s’agit donc d’un travail de standardisation en cours, pas d’une garantie que tous les acteurs du web appliqueront immédiatement la même interprétation.

Deuxième limite : seuls les fournisseurs participants sont concernés. Le signal est utile si les crawlers le respectent. Il ne bloque pas techniquement un robot malveillant ou un acteur qui ne l’honore pas. Les contrôles existants par crawler restent donc importants, en particulier pour les acteurs qui ne prennent pas encore en charge le policy token.

Troisième point : il faut éviter les conflits de règles. Google explique que le nouveau signal peut être interprété comme un refus de Google-Extended si aucune règle Google-Extended explicite n’est donnée. Les équipes SEO et techniques devront donc relire leurs fichiers robots.txt existants avant d’ajouter le token partagé.

Enfin, robots.txt est un signal public. Il exprime une préférence et guide les crawlers coopératifs. Pour des contenus sensibles, le bon réflexe reste de ne pas les exposer publiquement, ou de les protéger par authentification.

L'avis NXUS

Ce signal va dans le bon sens pour les professionnels : il simplifie une gestion qui devenait fragmentée entre fournisseurs. Mais il doit être traité comme un réglage de gouvernance web, pas comme une protection absolue.

Avant de l’ajouter, fais l’inventaire des zones de ton site : contenus ouverts, contenus commerciaux, ressources premium, presse, documentation. Puis définis une politique claire avec les équipes SEO, juridique et marketing.

Le plus utile à court terme est de préparer un robots.txt propre, documenté et cohérent avec les règles déjà en place pour GPTBot, Google-Extended ou d’autres crawlers. Si ton organisation veut structurer plus largement ses usages et ses règles autour de l’IA, une montée en compétence via les formations IA NXUS peut aider à poser les bons réflexes.

Sources

Source : OpenAI

robots.txtIA générativeIETFSEO

Rudy Molinillo

Articles similaires