Bloquer les crawlers IA : la décision ne se joue plus seulement dans robots.txt

Le sujet paraît technique. Il devient vite une question de gouvernance. Dans beaucoup d’entreprises, le fichier robots.txt est détenu par l’équipe web, tandis que Cloudflare relève de l’hébergeur, du prestataire de sécurité ou d’un ancien administrateur. À compter du 15 septembre, ce partage des accès peut déterminer qui collecte le contenu, et pour quel usage. Avant même Cloudflare, la question se pose au niveau du registre : qui est propriétaire du nom de domaine, de l’hébergement et du DNS décide de qui peut trancher.

La nouvelle configuration ne transforme pas Cloudflare en juge de la visibilité. Elle oblige plutôt chaque site à reprendre les décisions de référencement qui doivent rester chez le client. C’est le propriétaire du site qui doit définir la règle, en connaître les conséquences et vérifier que la personne ayant accès au tableau de bord l’a appliquée.

Le piège serait de résumer l’annonce à « Cloudflare bloque les IA ». La réalité est plus précise. Les catégories de robots sont distinctes, le blocage par défaut vise les pages avec publicité et les réglages peuvent être modifiés. C’est justement cette précision qui rend un audit utile : une décision floue donne rarement un résultat maîtrisé.

Ce qui bascule le 15 septembre, et sur quels sites

Cloudflare annonce de nouveaux réglages pour les nouveaux domaines à partir du 15 septembre 2026. Les robots classés Training, pour l’entraînement ou l’ajustement de modèles, et Agent, qui agissent en temps réel pour un utilisateur, seront bloqués sur les pages détectées comme affichant de la publicité. Les robots classés Search resteront autorisés dans ce réglage par défaut.

Le périmètre mérite une lecture attentive. Il ne s’agit ni d’un refus général de tout trafic automatisé, ni d’une fermeture de chaque page d’un site. Cloudflare prévoit trois choix pour chaque comportement : bloquer partout, bloquer sur les pages avec publicité, ou autoriser. Les robots à usage mixte, Search et Training, sont eux aussi inclus dans les configurations qui bloquent l’entraînement.

Avant cette date, les clients peuvent renoncer à ces nouveaux réglages. Après cette date, la première vérification consiste donc à ouvrir Security Settings, puis Configure AI bot policies, et à relever les choix réellement actifs pour le domaine. Une capture datée et le nom du responsable évitent qu’un réglage important disparaisse dans une conversation orale.

Pourquoi robots.txt ne suffit plus

robots.txt reste utile. Il annonce les préférences du propriétaire du site aux robots qui choisissent de les respecter. Mais ce fichier ne constitue pas une barrière technique. Cloudflare le rappelle dans sa propre documentation : la conformité est volontaire et un opérateur peut ignorer une directive Disallow.

Le changement est là : une directive déclarative peut être complétée par une règle appliquée à la périphérie du site, avant que la requête n’atteigne le serveur. C’est aussi la raison pour laquelle il faut comprendre la façon dont les robots d’IA lisent réellement une page. Le contenu visible, la réponse HTTP et la règle de filtrage ne se situent pas au même endroit.

Cloudflare propose d’ailleurs de combiner les deux couches : robots.txt pour exprimer une préférence, AI Crawl Control pour l’appliquer. Cette distinction aide aussi à remettre ce que vaut réellement un fichier llms.txt à sa place : un signal documentaire, pas un verrou à lui seul.

Les trois niveaux de décision et qui tient chacun

Un même site peut porter trois décisions différentes. Elles doivent être cohérentes, sans être confondues. Le fichier robots.txt communique une consigne. Le tableau de bord Cloudflare applique une politique par catégorie de bot. Une règle WAF ou une configuration plus fine traite enfin les exceptions, par chemin, par robot ou selon le contexte de la requête.

Le tableau ne dit pas qui doit trancher. Il montre qui peut agir. Dans une PME, la même personne peut piloter les trois niveaux. Dans une organisation externalisée, les responsabilités sont souvent distribuées entre le marketing, le prestataire web, l’hébergeur et la sécurité. Sans mandat explicite, chacun suppose que l’autre a choisi.

Le cas le plus fréquent : personne n’a tranché

Ce cas est banal. Le site a été ajouté à Cloudflare lors d’une migration, les accès sont conservés par une agence, et le responsable SEO ne consulte que le CMS. Quand une politique par défaut évolue, personne ne sait si elle a été acceptée, contournée ou remplacée. La difficulté n’est pas de cocher une case. Elle est de disposer du bon accès et d’un propriétaire de décision.

Autoriser ou bloquer : ce que la décision engage

Bloquer l’entraînement peut répondre à une logique de maîtrise des contenus, de coût d’infrastructure ou de protection d’un catalogue à forte valeur. Autoriser peut soutenir une stratégie de découverte, de citation ou d’exposition de la marque, sans garantir pour autant une présence dans les réponses génératives. Les bénéfices et les renoncements ne sont donc pas symétriques.

La bonne question n’est pas « faut-il laisser passer les IA ? », mais « quels usages de notre contenu acceptons-nous, sur quelles pages et avec quel objectif ? ». Cette réflexion rejoint ce qui rend une marque visible dans les réponses génératives. La visibilité dépend aussi de la qualité éditoriale, des preuves externes et de la capacité des systèmes à accéder légalement au contenu.

Une entreprise peut décider d’autoriser les robots de recherche, de refuser l’entraînement sur son contenu éditorial et de réserver certaines ressources à ses clients. Elle peut aussi vouloir des exceptions pour une base documentaire ou un espace presse. Ce choix doit être formulé par usage et par zone, pas à partir d’une formule générale sur l’IA.

La question à poser à votre hébergeur cette semaine

La demande utile est courte : « Qui détient l’accès administrateur au domaine Cloudflare, quelles politiques IA sont actives, et qui est autorisé à les modifier ? » Ajoutez une seconde question : « Le site contient-il des pages détectées comme affichant de la publicité ? » Cette information conditionne le réglage par défaut annoncé par Cloudflare. Elle fait partie du périmètre réel d’une prestation de site et d’hébergement que le client doit pouvoir vérifier.

Demandez ensuite un relevé simple : capture des politiques, date de contrôle, liste des domaines concernés, règles particulières et contact responsable. Si l’hébergeur ou l’agence agit au nom du client, le contrat doit indiquer qu’il applique une instruction, pas une préférence implicite. Pour les sites les plus exposés, testez aussi un échantillon de pages et les journaux de trafic après le changement.

Il ne s’agit pas de lancer un chantier de sécurité disproportionné. Il s’agit de transformer un réglage hérité en décision explicite, comme pour les Core Web Vitals, dont l’agence et l’hébergeur se renvoient la responsabilité. En trente minutes, une entreprise peut recenser ses accès, documenter sa position et planifier une revue. Elle évite ainsi de découvrir plusieurs mois plus tard que son contenu était filtré, ou laissé ouvert, sans validation métier.

Cette revue gagne à distinguer les domaines de production, de préproduction et les sous-domaines documentaires. Un réglage homogène est parfois pertinent, mais il ne doit pas masquer les différences de contenus, d’audiences ou de modèles économiques. Le registre de décision doit signaler les exceptions et leur date de réexamen.

Le réglage invisible doit devenir une décision de gouvernance

Le 15 septembre 2026 marque surtout un changement de méthode. Cloudflare ne bloque pas indistinctement tous les crawlers IA : il propose une politique par catégorie et par type de page, que le propriétaire peut ajuster. La responsabilité de l’entreprise est de savoir où la règle s’applique, qui y a accès et quel usage de ses contenus elle veut accepter.

Commencez par la liste des domaines et des administrateurs Cloudflare. Faites valider une position par le marketing, le juridique et la sécurité lorsque le contenu est sensible. Puis conservez une preuve du réglage choisi. Une consigne lisible, un accès maîtrisé et un contrôle daté valent mieux qu’un robots.txt oublié au fond d’un dépôt.

Sources et références

Cet article s’appuie sur la documentation Cloudflare sur les politiques de blocage des bots IA, sur la documentation Cloudflare consacrée au réglage robots.txt, sur le guide Cloudflare de gestion des crawlers IA, sur l’annonce Cloudflare des nouvelles options de trafic IA, sur la présentation d’AI Crawl Control par Cloudflare et sur la documentation Google relative aux robots d’exploration.