# Google prévient : robots.txt ne contrôle pas l’entraînement IA > Google rappelle que robots.txt contrôle l’accès des robots, mais pas l’usage ultérieur des contenus, notamment pour l’entraînement des modèles. Type : Actualité IA · Catégorie : Outils · Publié le 2026-10-25 · Signal IA - Order & Chaos Source : https://www.orderchaos.eu/signal-ia/actu/google-alerte-robotstxt-ne-bloque-pas-lusage-par-lia Tags : robots.txt, référencement, ia générative, google, gemini, benchmark --- ## En résumé - Gary Illyes affirme que robots.txt contrôle les URL qu’un robot peut demander. - Google-Extended permet de gérer certains usages des contenus dans les produits Gemini. - Un projet de l’IETF propose une règle Content-Usage dédiée aux préférences d’utilisation. **Le signal :** Gary Illyes distingue clairement le contrôle des URL par robots.txt et l’usage ultérieur des contenus par les systèmes d’IA. **Google clarifie** le rôle de robots.txt dans l’usage des contenus par l’intelligence artificielle. Gary Illyes, de Google Search Relations, a expliqué cette limite dans une vidéo publiée mercredi. Selon lui, la norme RFC 9309 encadre les URL qu’un robot peut demander. Elle ne définit pas ce qu’un système fait avec les données après leur exploration. La question portait sur un scénario précis. Un site pourrait-il autoriser l’exploration par l’IA, tout en interdisant l’entraînement de modèles génératifs avec ces informations ? Illyes répond que robots.txt est un protocole de préférence d’accès. Il ne constitue donc pas, à lui seul, une règle générale d’utilisation des contenus déjà explorés. [Lire l’analyse de Google](https://www.searchenginejournal.com/google-illyes-robots-txt-crawling-ai-training/593957/) **Le fichier cible** les robots grâce à leur identifiant User-Agent. Pour bloquer complètement un robot d’IA précis, Illyes recommande de viser explicitement ses jetons User-Agent dans robots.txt. Cette méthode peut empêcher l’accès à certaines pages ou à l’ensemble d’un site. Elle ne distingue toutefois pas automatiquement l’exploration et l’entraînement lorsque le même robot a déjà obtenu les données. La page de spécifications de Google reconnaît quatre éléments pris en charge. Il s’agit de User-Agent, Allow, Disallow et Sitemap. Les lignes invalides sont ignorées par l’analyseur de Google. La norme RFC 9309 laisse aussi aux robots le choix de traiter des éléments situés hors du protocole. Une règle inventée comme « No-AI-Chicken-Training » serait donc ignorée par un analyseur compatible. ## Google distingue accès et usage **Google-Extended contrôle** certains usages propres aux produits Google. Ce jeton robots.txt ne possède pas son propre User-Agent. Google explore avec ses identifiants habituels, tandis que Google-Extended agit comme mécanisme de contrôle. La documentation de Google indique qu’il gère l’utilisation des contenus explorés pour entraîner de futurs modèles Gemini. Il concerne aussi l’ancrage dans Gemini Apps et dans Grounding with Google Search sur Vertex AI. Google-Extended ne modifie pas l’inclusion d’un site dans Google Search. Il ne constitue pas non plus un signal de classement. Sa portée vient de la documentation des produits Google. Elle ne provient pas directement de la norme RFC 9309. La vidéo renvoie à cette documentation sans détailler Google-Extended pendant l’épisode. **Un projet IETF** propose une séparation plus précise entre l’accès et l’utilisation. Gary Illyes a coécrit ce projet avec Martin Thomson, de Mozilla. La version datée du 19 août ajouterait une règle Content-Usage à RFC 9309. Elle prévoirait aussi un en-tête HTTP correspondant. Allow et Disallow continueraient de définir les URL explorables. Content-Usage préciserait ensuite les préférences applicables aux contenus déjà récupérés. Ces préférences concerneraient uniquement les chemins dont l’exploration est autorisée. L’exemple du projet contient la valeur « train-ai=n ». Le document reste un projet de groupe de travail. Son entrée IETF indique que le groupe ne l’a pas encore soumis au comité directeur de l’IETF. [Consulter le document de travail](https://datatracker.ietf.org/doc/draft-ietf-aipref-attach/) **Le calendrier évolue** autour de ce projet de règle. La date prévue pour une transmission au comité directeur était août 2026. Le document Content-Usage doit actuellement expirer le 20 février 2027, sauf remplacement anticipé par une nouvelle version. Le libellé « train-ai » apparaît aussi dans un projet de vocabulaire daté du 14 septembre. Ce document précise qu’il ne représente aucun consensus du groupe de travail. Ces éléments décrivent donc une proposition en cours, et non une règle déjà intégrée à RFC 9309. La vidéo concernée est le deuxième épisode de The Non-Canonical Cabinet. Gary Illyes et Cherry Prommawin y répondent à des questions atypiques de la communauté. Le prochain épisode doit traiter du code d’état 404. [Voir la vidéo Google](https://www.youtube.com/watch?v=-jHONLQgE-s) **Les chemins encodés** réduisent les risques d’interprétation différente entre robots. Cherry Prommawin recommande d’utiliser la forme encodée en pourcentage pour les chemins contenant des caractères non anglais ou des emojis. L’analyseur de Google traite les caractères bruts et encodés de la même manière. D’autres robots, notamment plus anciens, pourraient toutefois interpréter les caractères bruts différemment. RFC 9309 autorise les caractères UTF-8 dans les chemins. Google illustre néanmoins l’encodage en pourcentage comme la méthode standard la plus sûre. Pour limiter un usage d’IA tout en conservant la visibilité dans Google Search, la règle dépend donc du robot ou du produit concerné. Disallow vise l’accès, Google-Extended vise certains usages Google, et Content-Usage reste à l’état de projet. Pour aller plus loin, consultez notre guide sur [déployer un chatbot IA pour le service client](/signal-ia/guides/chatbot-ia-service-client-pme-2026).