# Paramètres par défaut de Cloudflare pour les robots d'indexation IA au 15 septembre : ce qui a changé pour les agents et les équipes chargées des données

Le 15 septembre 2026, Cloudflare a modifié la signification du terme « bloqué » pour le trafic lié à l’IA. Les nouveaux domaines générant des revenus publicitaires voient désormais les robots d’apprentissage de l’IA refusés et les agents IA bloqués sur les pages contenant des publicités, tandis que la recherche reste autorisée. Cloudflare indique que plus de 20 % du Web est hébergé derrière son réseau ([Blog Cloudflare](https://blog.cloudflare.com/agentic-internet-bot-report/), 2026) ; ce paramètre par défaut s’applique donc à près d’un cinquième du Web. Deux semaines après la mise en place, voici ce qui a réellement changé, qui est concerné et ce que les équipes exploitant des agents IA ou des pipelines de données doivent faire à ce sujet.

> **Points clés à retenir**
>
> - Depuis le 15 septembre 2026, Cloudflare classe le trafic IA en trois catégories (Recherche, Entraînement, Agent), et les nouveaux domaines monétisés par la publicité voient, dès leur création, l’entraînement IA désactivé et le trafic Agent bloqué sur les pages contenant des publicités ([Blog Cloudflare](https://blog.cloudflare.com/accountable-mixed-use-ai-crawlers/), 2026).
> - En juin 2026, 52 % des requêtes de robots d’indexation observées par Cloudflare concernaient l’entraînement de l’IA, contre 22 % au printemps 2025 ([Blog Cloudflare](https://blog.cloudflare.com/agentic-internet-bot-report/), 2026).
> - Si votre agent récupère des pages pour le compte d’un utilisateur, vous êtes désormais classé dans la catégorie « Agent ». Prévoyez des règles variables par page, et non par site.

## Qu’est-ce qui a exactement changé le 15 septembre ?

Le 15 septembre 2026, Cloudflare a modifié la manière dont ses contrôles anti-bots gèrent le trafic lié à l’IA ([Blog Cloudflare, « Have it both ways »](https://blog.cloudflare.com/accountable-mixed-use-ai-crawlers/), 2026). Ses paramètres « Bloquer » et « Bloquer sur les pages contenant des publicités » s’appliquent désormais également aux robots d’exploration à usage mixte, c’est-à-dire aux robots qui collectent des pages à la fois pour la recherche et pour l’IA. Le bouton unique « Bloquer les robots IA » est supprimé, et un nouveau paramètre « Interdire l’entraînement de l’IA » permet à un site de rester dans les résultats de recherche tout en refusant l’entraînement. Le fichier robots.txt géré devient également « Bot Preference Sync ». Le changement concret réside dans la segmentation. Auparavant, Cloudflare traitait les « bots d’IA » comme une seule catégorie. Désormais, le trafic lié à l’IA est réparti en trois catégories : « Recherche », « Apprentissage » et « Agent », chacune disposant de son propre commutateur. Les nouveaux domaines se voient proposer l’un des deux préréglages suivants, selon que le site génère ou non des revenus publicitaires :

| Catégorie | Ce qu’elle couvre | Nouveau domaine monétisé par la publicité | Nouveau domaine sans publicité |
|--------|----------------|-------------------------|-------------------|
| Recherche | Indexation pour les résultats de recherche | Autorisé | Autorisé |
| Entraînement | Collecte de contenu pour entraîner des modèles | Interdire l’entraînement IA | Autorisé |
| Agent | Récupération de pages en réponse à la requête en temps réel d’un utilisateur | Bloqué sur les pages contenant des publicités | Autorisé |

*Préréglages tels qu’énumérés dans l’article de Cloudflare du 15 septembre 2026, [Le meilleur des deux mondes](https://blog.cloudflare.com/accountable-mixed-use-ai-crawlers/).*

Le Web n’a donc pas basculé du jour au lendemain. Selon Cloudflare, les paramètres des clients existants sont migrés automatiquement, et les nouveaux préréglages ne s’appliquent que lorsqu’un client intègre un nouveau domaine. Ce qui a changé, c’est le point de départ de chaque nouveau site à partir de maintenant, et sur un réseau de cette envergure, les points de départ s’accumulent rapidement.

## Pourquoi Cloudflare distingue-t-il les robots d’indexation en trois catégories : « Recherche », « Entraînement » et « Agent » ?

Cloudflare a divisé ses contrôles d’IA car le trafic d’entraînement a dépassé le trafic de recherche. En juin 2026, 52 % des requêtes de robots d’exploration observées par Cloudflare concernaient l’entraînement de l’IA, contre 22 % au printemps 2025, et les robots d’exploration à usage mixte représentaient plus de 36 % de l’activité ([Cloudflare, « Content Independence Day, one year on »](https://blog.cloudflare.com/agentic-internet-bot-report/), 2026). L’exploration purement dédiée à la recherche ne représente désormais qu’une part modeste et en baisse. Pour un propriétaire de site, cela signifie que la plupart des robots d’IA qui accèdent à ses pages collectent du contenu pour des modèles plutôt que de rediriger des lecteurs via les résultats de recherche, et qu’un simple commutateur « robots d’IA » ne permettait pas de faire la distinction entre les deux.

Les éditeurs considèrent cela comme un échange déséquilibré. TollBit, qui aide les éditeurs à concéder des licences de contenu aux entreprises spécialisées dans l’IA, suit cette évolution dans son [rapport « State of the Bots »](https://tollbit.com/state-of-the-bots/). L’édition du premier et du deuxième trimestre 2026, portant sur les robots IA de 40 fournisseurs chez 3 906 éditeurs, a montré que le rapport entre le scraping et les références était passé de 150:1 au premier trimestre à 227:1 au deuxième trimestre (TollBit, 2026, tel que rapporté par [Digiday](https://digiday.com/media/european-publishers-are-getting-hit-harder-by-ai-bot-scraping-report-finds/) en août 2026). Cela représente des centaines de visites de bots pour chaque visiteur humain qui clique sur un lien.

Alors pourquoi ne pas tout bloquer, tout simplement ? Parce que moins de 1 % des sites Cloudflare bloquent les robots de recherche, selon ce même article de septembre, tandis que 17 % activent un moyen de bloquer l’apprentissage ([Blog Cloudflare](https://blog.cloudflare.com/accountable-mixed-use-ai-crawlers/), 2026). Les sites veulent le trafic de Google. Ils ne veulent simplement pas fournir gratuitement des données d’entraînement. La répartition en trois catégories leur permet d’accepter l’un et de refuser l’autre.

<!-- [POINT DE VUE UNIQUE] -->
Pour toute personne développant des produits d’IA qui naviguent pour le compte d’un utilisateur, la catégorie « Agent » est celle qui importe. Les robots d’apprentissage étaient voués à se retrouver sous pression. Les agents sont plus récents, et ils disposent désormais de leur propre commutateur et de leur propre paramètre par défaut, au lieu de partager un seul commutateur « robots IA » avec les robots d’apprentissage.

## Qu’est-ce qu’un robot d’indexation « responsable » à usage mixte ?

Cloudflare définit un robot d’indexation responsable à usage mixte comme un robot dont l’opérateur offre aux propriétaires de sites un moyen de se désinscrire de l’entraînement de l’IA (via le fichier robots.txt ou une norme similaire), des contrôles de désinscription pour les résumés générés par l’IA, une visibilité au niveau des URL sur l’utilisation à des fins d’entraînement, ainsi que l’assurance que ce refus n’aura pas d’incidence négative sur le classement dans les résultats de recherche ([Blog Cloudflare](https://blog.cloudflare.com/accountable-mixed-use-ai-crawlers/), 2026). Cloudflare cite Applebot, Bingbot et Googlebot comme des robots d’indexation à usage mixte « responsables ». Elle répertorie Amazon, Anthropic, Meta et OpenAI comme des opérateurs « responsables et distincts », car ils exploitent des robots d’indexation distincts pour la recherche et pour l’apprentissage. Les robots d’indexation à double usage responsables restent autorisés pour la recherche sur les sites qui sélectionnent l’option « Interdire l’apprentissage de l’IA ». Tous les autres robots d’indexation destinés à l’apprentissage sont bloqués sur ces sites.

Cela crée une incitation claire. Si vous exploitez un robot d’indexation, le moyen de rester le bienvenu consiste à séparer vos objectifs ou à donner aux sites un contrôle réel sur chacun d’entre eux. Un robot unique qui fait tout est désormais la chose la plus facile à bloquer.

## Le modèle « Pay Per Crawl » devient « Pay Per Use »

Dans le cadre du modèle « Pay Per Crawl », l’ancien modèle de Cloudflare, les sites pouvaient facturer aux robots d’IA des frais pour chaque requête de page. En juillet 2026, Cloudflare a annoncé qu’elle rémunérerait les éditeurs lorsque leur contenu contribuerait à former une réponse générée par l’IA, et non plus uniquement lorsqu’une page était consultée. Les entreprises de recherche IA Ceramic.ai et You.com ont été désignées comme premiers partenaires ([The Next Web](https://thenextweb.com/news/cloudflare-block-ai-crawlers-pay-publishers), 2026). Il s’agit là d’un véritable changement dans ce qui fait l’objet d’une tarification. Un « crawl » correspond à une simple requête, tandis qu’une « utilisation » désigne le moment où le contenu se retrouve dans une réponse lue par un utilisateur. Pour les éditeurs, cela lie davantage la rémunération à la valeur. Pour les entreprises spécialisées dans l’IA, cela signifie que le coût du contenu pourrait désormais être calculé en fonction de l’utilisation plutôt que du volume, ce qui modifie la logique permettant de déterminer s’il est opportun ou non de récupérer une page.

Nous avons abordé la version antérieure de ce modèle, ainsi que les raisons pour lesquelles le Web ouvert a commencé à se fermer aux robots, dans [« Le Web qui se referme : blocage des robots d’IA, paiement à l’exploration et ses implications pour les agents »](https://www.joinmassive.com/blog/the-closing-web-ai-crawler-blocking-pay-per-crawl-and-what-it-means-for-agents).

## Que doivent faire désormais les équipes qui exploitent des agents d’IA ?

Commencez par accepter le fait que l’accès varie désormais d’une page à l’autre. Dans le cadre du nouveau paramètre de monétisation publicitaire, un agent peut accéder à la page de tarification d’un site, puis se voir bloquer l’accès à l’article financé par la publicité qui se trouve juste à côté.

Une liste de contrôle pratique :

1. **Identifiez la catégorie à laquelle vous appartenez.** Récupérer une page parce qu’un utilisateur a posé une question relève du trafic « Agent ». Collecter des pages pour affiner un modèle relève de l’« Entraînement ». Étiquetez-les séparément dans vos propres journaux, car le Web les traite désormais différemment.
2. **Attendez-vous à des réponses au cas par cas.** « Blocage sur les pages comportant des publicités » signifie qu’un même domaine peut répondre à la fois par l’affirmative et par la négative. Mettez en place des tentatives de réessai et des solutions de repli par URL, et non par domaine.
3. **Considérez les blocages comme des signaux.** Un blocage dans le cadre de ces préréglages correspond à la préférence exprimée par l’éditeur. Enregistrez-le dans vos journaux et contournez-le en utilisant une source sous licence ou structurée, le cas échéant.
4. **Surveillez les modèles de paiement à l’utilisation.** Si une source dont vous dépendez adhère à un programme payant, il peut s’avérer plus économique de payer que de mettre en place une solution technique pour contourner le blocage.
5. **Séparez vos charges de travail et identifiez-les.** Si vous gérez à la fois du trafic d’entraînement et du trafic d’agents, attribuez-leur des identités distinctes afin qu’aucune ne provoque le blocage de l’autre. Cloudflare propose également un programme d’« agents signés » : les agents dirigés par un utilisateur final peuvent signer leurs requêtes HTTP à l’aide de Web Bot Auth, une norme cryptographique de signature de messages, afin que Cloudflare puisse vérifier leur identité ([Documentation Cloudflare, Agents signés](https://developers.cloudflare.com/bots/concepts/bot/signed-agents/)). Si vous exploitez un agent, quelle que soit son échelle, cela vaut la peine de lire cette documentation.

<!-- [UNIQUE INSIGHT] -->
Il convient de signaler un piège. Pour les pipelines d’agents, les échecs les plus préjudiciables ne sont généralement pas les blocages purs et simples, qui sont faciles à repérer. Les pages de vérification (Challenge Pages) de Cloudflare constituent le cas le plus simple : chacune comporte un en-tête `cf-mitigated: challenge`, et son type de contenu est toujours `text/html`, quelle que soit la ressource que vous avez demandée ([Documentation Cloudflare, Détecter une réponse de page de défi](https://developers.cloudflare.com/cloudflare-challenges/challenge-types/challenge-pages/detect-response/)). Vérifiez la présence de cet en-tête avant de procéder à toute analyse. Le cas le plus délicat est celui d’une page partielle silencieuse : une requête renvoie un statut 200, mais le corps correspond à une page de remplacement (une page interstitielle), un shell JavaScript ou une version allégée de l’article. Vérifiez ce qui a été renvoyé, et pas seulement le code d’état. Une longueur minimale de contenu, ou la vérification de la présence d’un élément DOM que vous vous attendez à trouver sur la page réelle, permet de détecter la plupart de ces cas.

## Comment Massive s’adapte aux nouveaux paramètres par défaut de Cloudflare

Massive fournit un réseau d’accès aux appareils et une pile de rendu qui délivrent du code HTML ou Markdown épuré à partir de pages publiques, dans plus de 195 pays. Les clients gèrent leurs propres opérations par-dessus. Les préférences des éditeurs en matière d’IA constituent des signaux publics, et les équipes avec lesquelles nous travaillons les considèrent comme des données d’entrée pour leur propre politique, et non comme des obstacles à contourner.

La fonctionnalité [Web Render API](https://docs.joinmassive.com/web-render/overview) renvoie les pages rendues au format Markdown pour les pipelines LLM et permet aux clients de cibler géographiquement les requêtes par pays, région ou ville. En ce qui concerne les proxys résidentiels, chaque compte dispose également de sa propre [liste noire de domaines](https://docs.joinmassive.com/residential/domain-blocking), ce qui permet à une équipe de bloquer les requêtes vers tout site auquel elle a décidé de ne pas accéder. Cette liste peut contenir jusqu’à 1 000 domaines, et toute requête vers un domaine bloqué est refusée avec une erreur 452 (Contenu interdit) avant même d’atteindre le site. Si votre pile d’agents se heurte aux nouvelles valeurs par défaut, consultez [les raisons pour lesquelles les agents IA sont bloqués sur les adresses IP des centres de données et comment y remédier](https://www.joinmassive.com/blog/why-ai-agents-get-blocked-on-datacenter-ips-and-how-to-fix-it), ou revenez au guide complet sur [comment donner aux agents IA un accès au Web en temps réel](https://www.joinmassive.com/blog/how-to-give-ai-agents-live-web-access). En ce qui concerne les aspects juridiques liés aux données d’entraînement, consultez [les poursuites judiciaires relatives aux données d’entraînement de l’IA que toute équipe chargée des données Web devrait connaître](https://www.joinmassive.com/blog/ai-training-data-lawsuits-web-scrapers).

## Foire aux questions

### Cloudflare a-t-il bloqué tous les robots d’exploration IA le 15 septembre 2026 ?

Non. Les nouveaux paramètres par défaut s’appliquent aux nouveaux domaines intégrés à Cloudflare, et les paramètres existants ont été migrés automatiquement. La recherche reste autorisée par défaut partout. Le trafic lié à l’entraînement et aux agents n’est restreint par défaut que sur les nouveaux domaines monétisés par la publicité, selon l’article publié par Cloudflare le 15 septembre 2026.

### Le Googlebot est-il bloqué par les nouveaux paramètres de Cloudflare ?

Pas sur les sites qui utilisent l’option « Disallow AI Training ». Cloudflare classe le Googlebot, le Bingbot et l’Applebot parmi les robots d’indexation à usage mixte responsables, qui restent autorisés pour la recherche. En revanche, les sites qui optent pour un paramètre « Block » (Bloquer) complet bloquent désormais également les robots d’indexation à usage mixte, ce qui peut affecter la visibilité dans les résultats de recherche.

### Quelle est la différence entre « Pay Per Crawl » et « Pay Per Use » ?

Le modèle « Pay Per Crawl » facturait les robots d’IA à chaque requête. Le modèle « Pay Per Use », annoncé en juillet 2026, rémunère les éditeurs lorsque leur contenu alimente une réponse générée par l’IA. Ceramic.ai et You.com ont été cités comme premiers partenaires, selon un article de The Next Web.

### Quelle part du trafic des robots est désormais consacrée à l’entraînement de l’IA ?

En juin 2026, Cloudflare a indiqué que 52 % des requêtes de robots d’indexation sur son réseau concernaient l’entraînement de l’IA, contre 22 % au printemps 2025. Les robots d’indexation à usage mixte représentaient plus de 36 % de l’activité.

## En résumé

- Cloudflare traite désormais le trafic de recherche, d’entraînement et d’agents comme trois décisions distinctes, chacune disposant de son propre commutateur et de sa propre valeur par défaut pour les nouveaux domaines.
- Pour les nouveaux domaines monétisés par la publicité, l’entraînement est initialement désactivé et les agents sont bloqués sur les pages publicitaires.
- Le modèle « Pay Per Use » rémunère les éditeurs pour les réponses fournies, et non pour les requêtes effectuées.
- Les développeurs d’agents doivent prévoir un accès par page, vérifier la présence de l’en-tête `cf-mitigated: challenge` dans chaque réponse et consigner chaque blocage comme une préférence exprimée par l’éditeur.
- À suivre : quelles entreprises d’IA rejoindront le modèle « Pay Per Use » et combien d’agents s’enregistreront en tant qu’[agents signataires](https://developers.cloudflare.com/bots/concepts/bot/signed-agents/).

Vous souhaitez voir à quoi ressemblent concrètement les requêtes rendues et géociblées ? Commencez par consulter la [Web Render API présentation générale](https://docs.joinmassive.com/web-render/overview).

## Sources

- Cloudflare, [« Le meilleur des deux mondes : rester visible dans les résultats de recherche tout en interdisant l’entraînement des IA »](https://blog.cloudflare.com/accountable-mixed-use-ai-crawlers/), consulté le 25/09/2026
- Cloudflare, [« Content Independence Day, un an après »](https://blog.cloudflare.com/agentic-internet-bot-report/), consulté le 25 septembre 2026
- The Next Web, [« Cloudflare fixe la date limite de septembre aux robots d'indexation IA »](https://thenextweb.com/news/cloudflare-block-ai-crawlers-pay-publishers), consulté le 25 septembre 2026
- Cloudflare Docs, [Agents signés](https://developers.cloudflare.com/bots/concepts/bot/signed-agents/)
- Cloudflare Docs, [« Détecter une réponse de page de défi »](https://developers.cloudflare.com/cloudflare-challenges/challenge-types/challenge-pages/detect-response/), consulté le 28 septembre 2026
- TollBit, [État des lieux des bots (1er et 2e trimestres 2026)](https://tollbit.com/state-of-the-bots/)
- Digiday, [« Les éditeurs européens sont de plus en plus touchés par le scraping des bots IA, selon un rapport »](https://digiday.com/media/european-publishers-are-getting-hit-harder-by-ai-bot-scraping-report-finds/) (données « State of the Bots » de TollBit)