Les fichiers robots.txt de Cloudflare peuvent désormais dire trois choses différentes à la fois. Depuis le 24 septembre 2025, l'entreprise permet aux propriétaires de sites de définir des valeurs distinctes pour l'indexation dans les moteurs de recherche, la récupération IA au moment de la requête, et l'entraînement des modèles d'IA, dans une seule ligne, plutôt que l'ancienne règle disallow tout-ou-rien. Plus de 3,8 millions de domaines utilisent déjà le robots.txt géré par Cloudflare pour exprimer une version de cette préférence. La plupart d'entre eux appliquent pourtant encore une seule règle globale aux trois, ce qui signifie qu'une marque cherchant à bloquer l'entraînement de l'IA finit souvent par bloquer les citations mêmes qu'elle recherche auprès de ChatGPT ou Perplexity.
Les trois autorisations qu'une seule règle de crawl contrôlait auparavant
Une ligne disallow dans un robots.txt traditionnel n'a jamais voulu dire qu'une seule chose : rester entièrement à l'écart. La syntaxe Content-Signal de Cloudflare divise cette autorisation unique en trois : la possibilité pour un crawler d'indexer une page pour la recherche, de l'utiliser pour ancrer une réponse en temps réel, et d'entraîner un modèle dessus, chacune définie indépendamment dans le même fichier.
La syntaxe ressemble à ceci : Content-Signal: search=yes, ai-input=yes, ai-train=no, placée sous un bloc user-agent de la même manière qu'une ligne Allow ou Disallow. La valeur du milieu, ai-input, est celle qui compte réellement pour les citations : elle détermine si un crawler peut intégrer une page dans un système de génération augmentée par récupération et l'utiliser pour ancrer la réponse qu'un utilisateur lit maintenant dans ChatGPT, Perplexity ou Gemini. La valeur ai-train régit quelque chose de différent : si ce même passage alimente un entraînement susceptible de remodeler les poids du modèle des mois plus tard. Une marque peut définir ai-train=no et ai-input=yes sur la même page, refusant de devenir une donnée d'entraînement tout en autorisant que le contenu soit cité aujourd'hui. Avant l'existence de Content-Signal, robots.txt n'avait aucun moyen d'exprimer cette différence. Une ligne disallow bloquait tout ce qu'un crawler donné pouvait faire avec une page, si bien qu'un éditeur voulant arrêter l'entraînement bloquait, par construction, également la récupération.
L'accès IA et l'entraînement de l'IA ne constituent pas la même autorisation. Une page peut ancrer une réponse en temps réel dans ChatGPT ou Perplexity aujourd'hui tout en refusant d'alimenter le prochain entraînement d'un modèle, mais seulement si le signal utilisé maintient réellement ces deux autorisations séparées.
Où robots.txt reste encore insuffisant
Robots.txt ne touche que les crawlers qui récupèrent le fichier, l'analysent correctement, et choisissent de le respecter, et même une règle pleinement respectée s'applique à un user-agent entier plutôt qu'à une seule page. Savoir quels robots IA tiennent réellement cette promesse est une question à part entière ; ce sont les lacunes restantes qui ont poussé les éditeurs vers des signaux au niveau de la page et de l'en-tête à la place.
La documentation d'OpenAI sur ses propres crawlers est étonnamment directe sur ce point. Désactiver GPTBot, y est-il précisé, indique que le contenu d'un site ne doit pas être utilisé pour entraîner des modèles de fondation d'IA générative, et OpenAI affirme respecter cette règle. Mais cette même documentation prévoit une exception pour ChatGPT-User, le crawler qui récupère une page pour le compte d'une personne au sein d'une conversation en direct : parce que ces actions sont initiées par un utilisateur, les règles de robots.txt peuvent ne pas s'appliquer. Une page qu'un site a désactivée pour l'entraînement peut donc quand même être récupérée et affichée à cet utilisateur quelques secondes plus tard. Robots.txt ne peut pas non plus distinguer une page rédigée pour des extraits de recherche d'une page rédigée pour répondre à une question précise, puisque la règle s'applique à tout le site ou à tout le user-agent, jamais à l'intention d'une seule URL.
Les balises meta et les en-têtes HTTP atteignent des pages individuelles
Une balise meta robots dans l'en-tête d'une page, ou l'équivalent X-Robots-Tag dans sa réponse HTTP, contrôle l'indexation et l'affichage pour cette seule URL plutôt que pour un site entier, selon la documentation de Google elle-même. C'est cette portée au niveau de la page qui explique pourquoi les éditeurs superposent balises meta et en-têtes au robots.txt plutôt que de le remplacer.
L'exemple le plus connu est la paire de directives noai et noimageai, introduites par DeviantArt en novembre 2022 pour empêcher les générateurs d'images IA de s'entraîner sur les créations téléversées par les artistes. Leur adoption a largement dépassé cet usage initial : le suivi continu d'Originality.AI a recensé plus de 88 000 domaines portant l'une des deux balises en juin 2026, répartis entre 77 645 utilisant la balise meta et 23 604 utilisant l'en-tête, soit un bond de 26,5 % de l'adoption de la balise meta en un seul mois. Rien dans cette adoption ne s'accompagne d'une garantie. Une balise noai est une demande, pas un verrou, note Originality.AI, puisqu'aucun grand laboratoire d'IA n'a publié de politique s'engageant à la respecter. La balise meta robots de Google elle-même comporte un effet secondaire pertinent pour l'IA, facile à manquer : la directive nosnippet, conçue des années avant l'existence des réponses génératives, empêche désormais aussi une page d'être utilisée comme donnée d'entrée directe pour les AI Overviews et l'AI Mode.
TDMRep ajoute un levier juridique que les autres n'ont pas
Le Text and Data Mining Reservation Protocol, ou TDMRep, est une norme du W3C Community Group, finalisée le 10 mai 2024, pour déclarer des droits d'exploration de données de façon lisible par machine. Les éditeurs le configurent via un en-tête HTTP, une balise meta HTML, ou un seul fichier tdmrep.json valable pour tout le site, et il peut pointer vers une politique de licence plutôt qu'un simple oui ou non.
Cette structure distingue TDMRep de robots.txt et de la balise noai, tous deux purement facultatifs partout où ils sont lus. Un éditeur réserve ses droits d'exploration avec un en-tête aussi simple que tdm-reservation: 1, ou le fixe à 0 pour signaler une exploration sans restriction, et peut y joindre un en-tête tdm-policy pointant vers une page de licence pour quiconque souhaiterait malgré tout négocier un accès. Les règles de droit d'auteur de l'Union européenne accordent aux titulaires de droits un opt-out explicite pour l'exploration de textes et de données lorsqu'il est exprimé de façon lisible par machine, et TDMRep a été conçu pour être exactement cette expression. Hors de l'UE, le protocole dépend entièrement du choix d'un opérateur de crawler de le vérifier et de s'y conformer, la même limite que partage chaque signal évoqué dans cet article.
Aucun de ces signaux n'est réellement contraignant
Aucun de ces mécanismes, de robots.txt à Content-Signal en passant par TDMRep, ne s'accompagne d'une garantie technique. Chacun dépend du choix volontaire de l'opérateur du crawler de lire le fichier et de le respecter, ce pourquoi les recommandations 2025 de l'International Press Telecommunications Council conseillent aux éditeurs de superposer plusieurs signaux plutôt que de faire confiance à un seul.
Robots.txt est, selon les mots de l'IPTC, en apparence la méthode la plus simple mais en réalité l'une des plus difficiles à bien appliquer, puisque le user-agent de chaque crawler IA doit être nommé et bloqué séparément, et que la liste ne cesse de s'allonger. OpenAI publie bien une politique claire pour l'un de ses quatre crawlers, indiquant qu'un disallow sur GPTBot exclut ce contenu des données d'entraînement de ses modèles de fondation, et affirme respecter cette règle. Aucun engagement public équivalent n'existe encore de la part d'OpenAI, d'Anthropic ou de Google spécifiquement pour les couches Content-Signal ou noai, ce qui explique exactement pourquoi les recommandations de l'IPTC traitent robots.txt, les balises meta, les en-têtes HTTP et tdmrep.json comme complémentaires plutôt que comme des substituts les uns aux autres.
Que configurer si l'objectif est d'obtenir des citations, pas le silence
Une marque qui veut apparaître dans les réponses de ChatGPT et de Perplexity sans alimenter un futur entraînement dispose d'un choix clair : définir ai-input=yes et ai-train=no dans la ligne Content-Signal de Cloudflare, et l'associer à une autorisation explicite de crawler dans robots.txt, plutôt qu'une balise noai globale que la plupart des systèmes interprètent comme laissez tout cela complètement tranquille.
Configurer correctement le signal n'est que la moitié du travail, puisque rien de ce qui est décrit ici n'est imposé par autre chose que le choix propre de l'opérateur du crawler. Les journaux serveur restent le seul moyen de confirmer si GPTBot, PerplexityBot ou Claude-SearchBot récupèrent réellement les pages qu'un site entendait laisser ouvertes, et une analyse plus poussée de ce trafic montre comment distinguer un vrai crawl d'un user-agent usurpé. Les paramètres par défaut de gestion des robots de Cloudflare lui-même se sont par ailleurs révélés capables de bloquer des crawlers IA légitimes même quand la ligne Content-Signal d'un site indique le contraire, ce qui mérite d'être vérifié directement plutôt que de supposer que les deux réglages concordent.
Questions fréquemment posées
Robots.txt bloque-t-il réellement l'entraînement de l'IA ?
Cela peut être le cas, mais seulement pour les crawlers qui choisissent de le respecter. La documentation d'OpenAI indique que désactiver GPTBot dans robots.txt signifie que le contenu d'un site ne doit pas servir à entraîner ses modèles de fondation, et l'entreprise affirme respecter cette règle. Robots.txt n'a toutefois aucun moyen d'autoriser séparément ce même contenu pour la récupération ou la citation, ce que la syntaxe Content-Signal de Cloudflare a justement été conçue pour corriger.
Qu'est-ce que la balise meta noai, et ChatGPT la respecte-t-il ?
Noai et noimageai sont des balises meta introduites par DeviantArt en novembre 2022 pour décourager l'entraînement de l'IA sur les créations téléversées. Plus de 88 000 domaines utilisent aujourd'hui l'une des deux balises, selon Originality.AI, mais aucune grande entreprise d'IA, y compris OpenAI, n'a publié de politique s'engageant à les respecter. Elles fonctionnent comme une demande publique, pas comme un blocage technique.
Qu'est-ce que la Content Signals Policy de Cloudflare ?
C'est une extension de robots.txt que Cloudflare a lancée le 24 septembre 2025 et qui permet à un site de définir trois valeurs distinctes, search, ai-input et ai-train, plutôt qu'une seule règle globale d'autorisation ou d'interdiction. Plus de 3,8 millions de domaines utilisent déjà le robots.txt géré par Cloudflare pour exprimer une version de cette préférence.
En quoi TDMRep diffère-t-il de robots.txt ?
TDMRep est une norme du W3C, finalisée en mai 2024, que les éditeurs configurent via un en-tête HTTP, une balise meta, ou un fichier tdmrep.json valable pour tout le site afin de déclarer leurs droits d'exploration de textes et de données. Contrairement à robots.txt, il peut avoir une portée juridique en vertu des règles de droit d'auteur de l'UE, bien qu'en dehors de l'UE il dépende encore du choix du crawler de le vérifier.
Une marque peut-elle bloquer l'entraînement de l'IA tout en étant citée par ChatGPT ou Perplexity ?
Oui, en principe. Définir ai-input=yes et ai-train=no dans la ligne Content-Signal de Cloudflare sépare les deux autorisations, permettant à un crawler d'ancrer une réponse en temps réel sans alimenter un entraînement. Une balise noai globale ne fait pas cette distinction, donc les marques qui recherchent des citations devraient l'éviter et confirmer que cette séparation fonctionne via une analyse des journaux serveur.