La réponse courte
Cloudflare a dissocié « apparaître en recherche » de « nourrir l'entraînement IA », et a fait du blocage le réglage par défaut pour les robots qui refusent de distinguer les deux. Depuis le 15 septembre 2026, un nouveau réglage « Interdire l'entraînement IA » permet aux propriétaires de sites de rester indexés par les moteurs de recherche tout en empêchant les robots à usage mixte d'utiliser leur contenu pour entraîner des modèles. Sur les nouveaux domaines, nouveaux sites et comptes de l'offre gratuite, l'entraînement et la récupération par agents sont désormais bloqués par défaut sur les pages financées par la publicité, et les robots à usage mixte qui ne déclarent pas leur finalité y sont bloqués purement et simplement.
Lecture pratique : le web passe de « un robot, une décision » à l'exploration à finalité déclarée, où l'accès recherche, agents et entraînement se négocie séparément. Bonne nouvelle si vous publiez du contenu, mauvaise si votre produit dépend silencieusement du scraping d'éditeurs financés par la publicité. Les équipes qui construisent des agents IA et des pipelines RAG devraient supposer que la couverture du web en direct continuera de se resserrer, et concevoir en conséquence dès maintenant, pas une fois qu'un index de récupération se sera silencieusement périmé.
Ce que Cloudflare a changé
Jusqu'ici, un propriétaire de site sur Cloudflare avait un choix brutal : autoriser un robot ou le bloquer. Cela fonctionnait quand un robot faisait un seul travail. Cela s'est brisé lorsque le même robot en a fait plusieurs — indexer une page pour la recherche classique, la récupérer en direct pour répondre à la question d'un agent IA, et l'ingérer pour entraîner un modèle. Bloquer un tel robot « à usage mixte » pour arrêter l'entraînement, c'était aussi disparaître de la recherche ; l'autoriser pour rester en recherche, c'était consentir à l'entraînement. Les éditeurs n'avaient aucun moyen de dire oui à l'un et non à l'autre.
La mise à jour du 15 septembre ajoute ce chaînon manquant. Une nouvelle option « Interdire l'entraînement IA » publie une préférence lisible par machine — en somme, « indexe-moi, ne t'entraîne pas sur moi » — que les robots participants s'engagent à respecter. Choisissez-la, et les robots à usage mixte des opérateurs qui honorent le signal continuent d'explorer pour la recherche, tandis que les robots d'entraînement seul des entreprises qui gardent ces fonctions séparées sont bloqués sans toucher à votre classement. Cloudflare nomme explicitement les robots d'entraînement d'Amazon, Anthropic, Meta et OpenAI comme ceux qu'il peut bloquer proprement, parce que ces opérateurs exploitent des robots de recherche et d'entraînement distincts.
Cloudflare a aussi durci les réglages par défaut. Les contrôles existants « Bloquer » et « Bloquer sur les pages avec publicité » s'appliquent désormais aux robots à usage mixte — dont Applebot, Bingbot et Googlebot —, ce qui n'était pas le cas avant. Pour les nouveaux clients Cloudflare, les sites nouvellement ajoutés et chaque site de l'offre gratuite qui n'a pas modifié son tableau de bord, les robots d'entraînement et d'agents sont bloqués par défaut sur les pages financées par la publicité, tandis que les robots de recherche restent autorisés. Les clients payants existants conservent leur configuration actuelle et peuvent l'activer quand ils le souhaitent. Les pages publicitaires sont au centre pour une raison simple : c'est là que vivent l'actualité, les tests, les prix et les analyses produit — exactement le contenu que les agents IA convoitent le plus.
Le pacte « Accountable »
Le mécanisme qui rend viable « rester en recherche, sauter l'entraînement » est une nouvelle désignation que Cloudflare appelle « Accountable ». Un opérateur la mérite en tenant quatre engagements : laisser les propriétaires de sites refuser l'entraînement IA via robots.txt ou une norme similaire ; leur permettre de refuser les résumés IA, directement ou via Cloudflare, avec un objectif début 2027 ; fournir une visibilité au niveau des URL sur les pages utilisées pour l'entraînement, aux côtés des métriques de recherche ; et garantir que refuser l'entraînement ne nuira pas au classement d'un site en recherche. Apple, Google et Microsoft se sont engagés sur ces principes, si bien qu'Applebot, Bingbot et Googlebot comptent comme Accountable et conservent leur accès recherche sous le nouveau réglage.
Ce dernier engagement est le nœud. Si les éditeurs ont toléré si longtemps l'exploration à usage mixte, c'était par crainte : refusez l'entraînement et vous pourriez perdre discrètement du trafic de recherche de la même entreprise. Dissocier les deux — et y adosser une promesse nommée — supprime la prise d'otage. Cela pousse aussi chaque opérateur de robots vers une norme : déclarer la finalité de chaque requête et honorer la préférence qui y est attachée. Les opérateurs qui refusent de séparer leurs fonctions sont les plus exposés aux nouveaux blocages par défaut.
En parallèle des contrôles d'exploration, Cloudflare change la façon dont l'argent circule. Son ancien « Pay Per Crawl » facturait les entreprises d'IA à chaque récupération de page par un robot. Le remplaçant, « Pay Per Use », déployé avec des partenaires dont Ceramic.ai et You.com, paie les éditeurs quand leur contenu est réellement utilisé dans une réponse ou un résultat d'IA plutôt que simplement récupéré. Cloudflare affirme que plus de la moitié du trafic des robots d'IA récupère à nouveau des pages inchangées, brûlant la bande passante des éditeurs pour rien ; lier le paiement à l'usage plutôt qu'à la récupération est censé y remédier. Le PDG Matthew Prince a résumé l'urgence sans détour : « Maintenant que la majorité du trafic sur Internet n'est pas humaine, nous devons aller plus loin et agir plus vite pour qu'un écosystème durable puisse émerger. »
Ce que ça signifie pour les équipes logicielles en France
Si vous construisez des produits qui lisent le web en direct, le titre est que le scraping gratuit, silencieux et généralisé du contenu financé par la publicité prend fin. Cloudflare se trouve devant une grande part du web, et ses réglages par défaut font norme. Un système RAG ou un agent qui tire discrètement de sites d'actualité, de places de marché et de pages d'avis verra sa couverture s'éroder à mesure que davantage de domaines héritent des réglages plus stricts. Le design durable, c'est la récupération à finalité déclarée : exploiter des robots séparés et identifiables pour la recherche, les agents et l'entraînement ; lire et honorer robots.txt et les nouvelles préférences ; et bâtir des solutions de repli vers des flux sous licence, des données de première partie et des API partenaires pour les sources qui refusent. C'est précisément cette résilience que nous intégrons dans nos développements web et plateformes, plutôt que de la découvrir quand un index se périme.
Si vous exploitez un site riche en contenu ou un SaaS derrière Cloudflare, la nouvelle est surtout un levier — à condition de l'utiliser. Vous pouvez désormais rester visible dans Google, Bing et la recherche Apple tout en disant non aux robots d'entraînement, et facturer l'usage IA de votre contenu au lieu de l'offrir. Le hic : les nouveaux sites et propriétés de l'offre gratuite héritent maintenant de réglages plus stricts ; une équipe qui monte un domaine neuf devrait vérifier que les robots de recherche voulus restent autorisés et qu'aucun accès IA réellement nécessaire n'a été coupé par défaut. Une revue de réglages de cinq minutes vaut mieux qu'une chute de trafic surprise.
Il y a aussi une couche de gouvernance, et en France elle est particulièrement concrète. Pouvoir déclarer et faire respecter la manière dont des tiers utilisent votre contenu s'articule avec les attentes de consentement, de transparence et de traçabilité des données qui traversent le RGPD et le règlement européen sur l'IA (AI Act). Les lignes directrices de la CNIL sur la création de bases de données d'entraînement par moissonnage web, et l'avis 28/2024 du Comité européen de la protection des données (CEPD) sur les modèles d'IA, font d'une politique d'exploration documentée une position défendable, non un simple bonus. S'y ajoute le droit voisin des éditeurs de presse — la France a été la première à le transposer et l'Autorité de la concurrence l'a fait appliquer face aux grandes plateformes — qui encadre déjà l'usage commercial des contenus éditoriaux. « Nous savons quels robots touchent notre contenu et à quelles conditions » devient la réponse standard que vous devriez pouvoir donner.
Que faire maintenant
- Revoyez vos réglages de bots et de robots d'IA Cloudflare. Décidez délibérément entre accès recherche, agents et entraînement. N'héritez pas du réglage par défaut par accident — et si vous exploitez de nouveaux domaines ou des sites de l'offre gratuite, confirmez que les réglages plus stricts correspondent à votre intention.
- Séparez et identifiez vos propres robots. Si votre produit récupère le web, exploitez des robots de recherche, d'agents et d'entraînement distincts avec des user-agents clairs, pour que les éditeurs — et Cloudflare — puissent autoriser les usages auxquels vous avez droit et que vous ne soyez pas assimilé à un robot à usage mixte non responsable.
- Auditez votre chaîne d'approvisionnement en données. Cartographiez les sources dont dépendent votre index RAG et vos agents, repérez les éditeurs financés par la publicité les plus susceptibles de restreindre l'accès, et prévoyez des flux sous licence, des API partenaires ou des données de première partie comme solutions de repli avant que la couverture ne chute.
- Honorez les préférences déclarées dans le code. Lisez robots.txt et les nouveaux signaux d'entraînement/résumé dans vos fetchers, mettez-les en cache, et échouez en mode fermé (fail closed) quand une source refuse. Traitez la conformité comme une fonctionnalité, pas comme une arrière-pensée.
- Consignez votre politique d'exploration. Documentez comment votre produit explore et comment vos propriétés autorisent l'exploration. C'est l'artefact que réclameront auditeurs, régulateurs et acheteurs grands comptes — et celui qui transforme ce virage d'un risque en signal de confiance.
Questions fréquentes
Qu'est-ce qui a changé chez Cloudflare le 15 septembre 2026 ?
Cloudflare a modifié le comportement par défaut de ses contrôles de robots d'IA. Un nouveau réglage « Interdire l'entraînement IA » permet à un site de rester indexé pour la recherche tout en empêchant les robots à usage mixte d'utiliser son contenu pour entraîner des modèles. Les options existantes « Bloquer » et « Bloquer sur les pages avec publicité » s'appliquent désormais aussi aux robots à usage mixte comme Applebot, Bingbot et Googlebot, ce qui n'était pas le cas avant. Les nouveaux réglages par défaut concernent les nouveaux clients, les nouveaux sites et tous les sites de l'offre gratuite qui n'ont pas changé leurs paramètres ; les clients payants existants conservent leur configuration.
Qu'est-ce que la désignation « Accountable » de Cloudflare ?
C'est un label pour les opérateurs de robots remplissant quatre conditions : laisser les propriétaires de sites refuser l'entraînement IA via robots.txt ou une norme similaire ; leur laisser refuser les résumés IA (directement ou via Cloudflare, visé pour début 2027) ; fournir une visibilité au niveau des URL sur les pages utilisées pour l'entraînement, plus des métriques de recherche ; et garantir que refuser l'entraînement n'affectera pas le classement en recherche. Apple, Google et Microsoft y répondent, de sorte qu'Applebot, Bingbot et Googlebot conservent l'accès recherche même quand un site choisit « Interdire l'entraînement IA ».
Quel impact sur les agents IA et les systèmes RAG qui récupèrent des pages web ?
Les robots d'agents et d'entraînement sont les plus susceptibles d'être limités. Sur les nouveaux domaines et les sites de l'offre gratuite, l'entraînement et la récupération par agents sont bloqués par défaut sur les pages financées par la publicité, et les robots à usage mixte qui ne déclarent pas leur finalité y sont entièrement bloqués. Si votre produit construit un index RAG ou fait tourner des agents qui tirent du contenu web en direct, attendez-vous à une couverture en baisse des éditeurs financés par la publicité, séparez vos robots de recherche, d'agents et d'entraînement pour que chacun soit identifiable, respectez les préférences de robots.txt et prévoyez des données sous licence ou de première partie là où l'exploration en direct est bloquée.
Qu'est-ce que le Pay Per Use et en quoi diffère-t-il du Pay Per Crawl ?
Le Pay Per Crawl facturait les entreprises d'IA à chaque récupération de page par un robot. Le Pay Per Use, déployé avec des partenaires dont Ceramic.ai et You.com, paie plutôt les éditeurs lorsque leur contenu est réellement utilisé dans une réponse ou un résultat d'IA, et non simplement récupéré. Ce virage reflète les données de Cloudflare selon lesquelles plus de la moitié du trafic des robots d'IA récupère à nouveau des pages inchangées, gaspillant la bande passante des éditeurs, et lie le paiement au moment où le contenu crée de la valeur pour le produit d'IA.
Dois-je modifier mes réglages Cloudflare dès maintenant ?
Si vous êtes un client payant existant, vos réglages restent inchangés et rien ne casse automatiquement, mais vous devriez tout de même revoir vos contrôles de bots et de robots d'IA et choisir délibérément entre accès recherche, agents et entraînement. Les nouveaux domaines, nouveaux sites et sites de l'offre gratuite héritent des réglages par défaut plus stricts ; vérifiez donc que les robots de recherche voulus restent autorisés et qu'aucun accès IA dont vous dépendez n'a été bloqué. Les équipes des deux côtés de la relation d'exploration devraient auditer lesquels de leurs propres robots sont identifiables et lesquels des éditeurs dont elles dépendent ont commencé à restreindre l'accès.
Sources
Cloudflare Blog — Have it both ways: stay discoverable in search while disallowing AI training (15 septembre 2026)
TechCrunch — Cloudflare’s new policy pushes AI companies to pay for publishers’ content
Help Net Security — Cloudflare changes AI crawler access rules