Votre site, vos règles : nouvelles options de gestion du trafic lié à l'IA pour tous les clients

Il y a un an, nous déclarions la première Journée de l'indépendance du contenu et donnions aux propriétaires de sites web les moyens de reprendre le contrôle de leur contenu. L'accord tacite qui avait tenu 30 ans entre les bots d'exploration et les propriétaires de sites web (nous vous indexons et vous recevez du trafic référent) n'était plus vrai. En s'emparant de tous les contenus, tout en ne renvoyant rien, l'IA représentait une menace existentielle pour les propriétaires de sites web. C'est pourquoi nous avons lancé l'option « Bloquer les bots IA » d'un simple clic, ainsi qu'un marché du paiement à l'exploration.

La situation a beaucoup évolué en un an. En juillet dernier, les discussions autour des « bots IA » se concentraient sur le blocage de l'entraînement des IA sans compensation et pointaient vers une situation perdant-gagnant où le contenu était utilisé pour l'entraînement des modèles sans retour de valeur pour le propriétaire du site web. Un désir pour davantage de nuance a toutefois émergé : les propriétaires de contenu souhaitent toujours pouvoir protéger leur contenu et devraient être rémunérés pour le contenu original sur lequel ils travaillent dur, que ce soit pour le créer, l'organiser ou le partager. Nous savons également que le verrouillage du contenu ne constitue pas une solution universelle. Les propriétaires de sites web souhaitent en effet disposer de davantage d'options que de simplement « bloquer tout le trafic automatisé, à chaque fois ».

Si vous gérez un petit site, le problème ne réside pas uniquement dans le fait que quelqu'un pourrait entraîner ses modèles sur votre contenu, c'est que personne ne peut vous trouver en premier lieu. Vous devez donc conclure un pacte faustien : soit apparaître dans les recherches et laisser l'IA s'entraîner sur votre contenu, soit risquer de perdre en visibilité. Cette situation avantage injustement les fournisseurs de recherche en place s'ils utilisent les mêmes bots pour la recherche et l'entraînement. Cet avantage injuste incite ainsi les nouveaux acteurs à se montrer évasifs lorsqu'ils tentent de réduire leur écart concurrentiel.

L'IA peut être présente dans n'importe quel type de ressource aujourd'hui. La recherche Google est passée de l'utilisation d'un outil de tri des réponses assisté par IA à celui du déploiement d'un moteur de réponse complet qui répond directement à votre question sur la page des résultats. Or, le cas Google n'est pas unique : c'est dans cette direction que s'oriente l'avenir de l'activité de « recherche ».

Nous pourrions débattre du seuil permettant de déterminer ce qui qualifie un bot comme « lié à l'IA » aujourd'hui, pour finalement découvrir que la norme aura changé demain. Ainsi, plutôt que de définir un bot principalement comme « lié à l'IA » ou non, notre approche actualisée de la classification posera des questions plus profondes sur le comportement des bots ou des agents : quelles actions effectuent-ils sur mon site ? Que stockent-ils ? Et comment vont-ils repartager mon contenu ?

Nous avons besoin d'une vision plus nuancée pour répondre à ces questions : une taxonomie pragmatique qui s'aligne avec les scénarios d'utilisation de l'IA qui intéressent nos clients. Nous élargissons donc la discussion au-delà de l'entraînement de l'IA pour nous concentrer sur trois scénarios d'utilisation de l'IA que nous souhaitons permettre à tous nos clients de traiter :

• Recherche : tout comportement qui collecte ou indexe votre contenu afin de pouvoir répondre ultérieurement à des questions le concernant. L'essentiel à saisir ici est que l'activité de recherche construit une base de données de votre site de manière proactive afin de pouvoir ensuite répondre aux requêtes. Les propriétaires de sites doivent s'attendre à recevoir du trafic référent ou à bénéficier d'une autre compensation équitable en conséquence.

• Agent : un comportement automatisé qui agit (généralement en temps réel) pour le compte d'une personne afin d'immédiatement réaliser une tâche. Cette catégorie inclut les bots de récupération de chat (p. ex., ChatGPT-User) et les agents d'utilisation de navigateur (p. ex., Gemini ou Claude sur Chrome). L'élément clé ici est que l'agent visite votre application web pour accomplir une tâche et qu'un utilisateur humain attend souvent à l'autre bout.

• Entraînement : un bot d'exploration qui utilise votre contenu pour entraîner ou affiner un modèle. L'idée clé ici est que vos données sont absorbées de manière permanente au sein de l'architecture sous-jacente de l'IA afin d'améliorer ses capacités.

De nombreux bots d'exploration populaires sur le web appartiennent à l'une des classes ci-dessus. Certains entrent même dans plusieurs catégories. Nous classifions de nombreux autres comportements au-delà des trois mentionnés ci-dessus, notamment la vérification des publicités, la récupération de flux et les transactions agentiques (nous reviendrons sur ce cas plus bas). Or, nous considérons qu'il devrait être simple pour tous les propriétaires de sites web de gérer l'accès à leur contenu pour ces trois scénarios d'utilisation axés sur l'IA. Nous pensons que les exploitants de bots devraient distinguer leurs bots d'exploration, car cette opération permet de générer davantage de transparence pour les propriétaires de sites web. Ces derniers peuvent ensuite mieux comprendre pour quelles raisons un bot donné se rend sur son site et dès lors mieux gérer l'accès qu'ils accordent à ce bot d'exploration. Nous encourageons fortement les entreprises à diviser leur processus d'automatisation en trois bots d'exploration distincts si ce dernier a pour tâche de construire des index de recherche, d'agir comme un agent et de collecter des données pour entraîner les modèles.

Nous souhaitons mettre en place un système de classification évolutif et représentatif de l'univers du trafic automatisé vers lequel il tend. Suivre les objectifs d'un bot n'est pas nouveau, mais notre nouvelle taxonomie inclut quelques mises à jour qui représentent mieux l'état actuel du trafic des bots. Nous souhaitons plus particulièrement reconnaître que les bots qui présentent plusieurs finalités doivent être suivis pour l'ensemble de ces dernières, et non pour une seule.

Nous souhaitons offrir davantage d'options de gestion des différents types de trafic IA à tous les propriétaires de sites web sur le réseau Cloudflare.

Le préréglage géré pour « Bloquer les bots IA » que nous avons annoncé par le passé incluait les bots à but unique qui exploraient les données à des fins d'entraînement des modèles, comme indiqué ci-dessous : 

^{Capture d'écran du paramètre existant de gestion du trafic lié aux bots IA le 1er juillet 2025.}

L'IA n'est toutefois pas toujours utilisée de la même manière et nous souhaitons que nos clients disposent des mesures de contrôle dont ils ont besoin. Nous lançons donc la possibilité de gérer le trafic IA en fonction de trois scénarios d'utilisation majeurs : la recherche (Search), les agents (Agents) et l'entraînement (Training). Grâce à ces nouvelles options, nos clients peuvent affiner la gestion du trafic lié aux bots, notamment les utilisateurs de notre offre gratuite.

^{Capture d'écran des nouvelles options de gestion du trafic lié aux bots IA le 1er juillet 2026.}

Le 15 septembre 2026, nous définirons de nouveaux paramètres par défaut pour chacune de ces trois classifications. Pour tous les nouveaux domaines qui intègrent le réseau Cloudflare, les catégories Entraînement et Agent seront bloquées par défaut sur les pages qui affichent des publicités, tandis que la classe Recherche restera autorisée par défaut. 

Une publicité est un signal qu'un propriétaire de site web a mis en place dans l'intention qu'un utilisateur accède à une page et voie la publicité, c'est-à-dire un élément monétisable conçu pour soutenir l'entreprise. Nous considérons donc l'attention humaine comme la finalité ultime sur ces pages et écartons les bots qui pourraient empêcher l'établissement de cette attention (c'est-à-dire les bots d'entraînement et les bots agents). D'autre part, la recherche constitue le comportement qui attire le plus naturellement les visiteurs et nous pensons qu'il va dans l'intérêt de la plupart des propriétaires de sites d'autoriser ce type d'activité.

Autre changement qui s'appliquera le 15 septembre : les bots d'exploration polyvalents (notamment ceux qui combinent recherche et entraînement) seront autorisés/bloqués en vertu de l'ensemble de leurs comportements, conformément à notre appel à davantage de transparence pour les propriétaires de sites web. Comme l'application des paramètres par défaut s'effectuera en fonction des règles les plus restrictives, les bots polyvalents (p. ex. Googlebot, Applebot et BingBot) seront bloqués par les clients qui ont choisi de bloquer l'activité d'entraînement (soit par l'intermédiaire des nouvelles options de gestion du trafic lié à IA, soit par le biais du service existant de blocage des bots IA).

Bien entendu, le choix du client demeure primordial : si un propriétaire de site web souhaite se désinscrire de ces nouvelles configurations par défaut, il peut facilement le mentionner dans ses paramètres de sécurité à tout moment avant le 15 septembre. Il confirmera dès lors qu'il ne souhaite aucun changement s'appliquer aux bots d'entraînement qui explorent également le contenu à des fins de recherche. Nous continuerons également à informer les clients de la modification à venir des paramètres par défaut à l'approche du 15 septembre afin de nous assurer que les clients qui souhaitent choisir des paramètres différents de ceux par défaut puissent le faire.

Nous nous réjouissons également de lancer une mise à jour majeure de la visibilité sous forme d'une nouvelle fonctionnalité de niveau Enterprise pour la gestion des bots. Plus le répertoire de bots suivis par Cloudflare s'est élargi, plus le désir de gérer ces bots en fonction de groupes logiques et de comprendre plus en détail un bot particulier a également augmenté. 

Nous vous présentons dès lors BotBase,notre nouvelle base de données qui répertorie l'ensemble des bots connus, y compris les bots et les agents vérifiés. Cette base de données assure une vue d'ensemble complète et consultable sur l'intégralité de notre répertoire de bots, directement sur le tableau de bord Cloudflare. Nous nous attaquons à la visibilité en premier lieu, mais nous étendrons BotBase plus tard cette année afin de vous proposer un centre de contrôle direct du contenu automatisé connu sur votre site web.

Grâce à cette nouvelle vue, les clients de niveau Enterprise de notre solution Bot Management peuvent consulter le catalogue complet de tous les bots/agents vérifiés et leur classification dans cette taxonomie mise à jour. Ils bénéficient dès lors d'une visibilité que nous n'avons jamais affichée de manière dynamique sur le tableau de bord Cloudflare auparavant. Les clients qui souhaitent cibler un bot spécifique avec précision peuvent aussi facilement filtrer l'ensemble du trafic issu de ce bot, et copier l'ID de détection à utiliser dans les règles de sécurité. Toutes ces fonctions sont désormais disponibles sur une page dédiée, elle-même accessible par l'intermédiaire de la carte de configuration de la solution Bot Management. 

En développant BotBase, nous souhaitions prendre en compte toutes les informations permettant de produire des informations puissantes et évolutives d'un bot à l'autre. L'un de ces éléments constitue une pierre angulaire de notre taxonomie mise à jour, basée sur ce qu'un bot peut faire sur votre site, c'est-à-dire son comportement. Nous distinguons ces différentes classes comme indiqué ci-dessous et chaque bot est classé selon un ou plusieurs de ces comportements.

^{Les lignes en gras et en italique indiquent les nouvelles options configurables disponibles pour l'ensemble de nos clients.}

Un autre élément d'information dont nous avons entendu dire par nos clients qu'il était important pour eux est l'utilisation du contenu par un bot, c'est-à-dire ce qu'un bot peut conserver et repartager après avoir exploré votre contenu. Pour aborder cette question, nous développons des capacités conçues pour que les clients de notre service Bot Management puissent sélectionner et bloquer ce qu'ils souhaitent en fonction de « l'utilisation du contenu ». Ce paramètre peut être défini selon trois niveaux, du moins permissif au plus permissif :

• immediate (immédiate) : interaction, mais sans stockage ni réutilisation

• reference (référence, par défaut) : indexation, créations d'extraits et de liens retour

• full (complète) : synthèse et reproduction

Ces valeurs peuvent être combinées aux classes de bots pour exprimer des règles plus nuancées, comme « autoriser tous les bots utilisés à des fins de recherche, de SEO et de vérification des publicités, mais uniquement jusqu'au niveau d'utilisation référence. » Cette possibilité permet aux propriétaires de sites web de prendre des décisions par groupes homogènes plutôt que de gérer les règles bot par bot.

Pour aller plus loin dans ce sens, nous testons un nouveau signal (use) à partir d'aujourd'hui. Ce dernier étend les signaux de contenu (Content Signals) et réside dans votre fichier robots.txt. Cet ajout étend les trois champs de la première version des signaux de contenu par un quatrième champ facultatif qui exprime la même préférence que ci-dessus :

• use=immediate

• use=reference

• use=full

Comme pour tous les autres éléments listés dans le fichier robots.txt, les valeurs de contenu signalent la préférence du propriétaire du site web plutôt que de procéder directement au blocage. Nous ajoutons aujourd'hui la prise en charge de cette extension : tous les clients qui ont déjà activé le fichier géré robots.txt (qui précise ci-dessous que l'exploration est autorisée pour la recherche, mais pas pour l'entraînement) verront désormais la préférence supplémentaire use=reference ajoutée à leur fichier robots.txt.

# Cloudflare Managed content with original Content Signals

User-agent: *
Content-Signal: search=yes,ai-train=no
Allow: /

^{Le contenu du fichier robots.txt géré par Cloudflare, avec les valeurs originales des signaux de contenu.}

# Cloudflare Managed content with the new content-use signal

User-agent: *
Content-Signal: search=yes,ai-train=no,use=reference
Allow: /

^{Le contenu du fichier robots.txt géré par Cloudflare avec le paramètre ajouté.}

Nous commençons aussi à suivre l'utilisation du contenu pour chaque bot dans BotBase. Le bot perdra le statut « Vérifié » lorsque nous découvrons qu'il abuse de ces signaux, ce qui entraînera son interdiction. Les bots qui reproduisent intégralement le contenu ne peuvent pas avoir le statut Vérifié à l'heure actuelle.

En ce qui concerne le statut « Vérifié », la définition de la vérification est mise à jour pour refléter les prochains changements comparés aux critères par défaut Autoriser et Bloquer. Auparavant, tous les bots vérifiés étaient autorisés par défaut. Cette situation était reflétée dans notre offre de base Bot Fight Mode afin de bloquer le trafic automatisé indésirable et dans nos modèles de règles pour les clients Enterprise du service Bot Management. 

À compter d'aujourd'hui, nous ajustons ce mode de fonctionnement afin d'ajouter de la nuance : les bots non vérifiés demeurent par défaut bloqués, mais nous ne considérons plus les bots vérifiés comme « autorisés par défaut ». L'étiquette « Vérifié » permet désormais à un bot d'être autorisé en fonction de sa catégorie pertinente, c'est-à-dire que la catégorie autorisée (p. ex., autoriser l'activité Recherche) déterminera quels bots sont autorisés à accéder à un site web.

Pour équilibrer ce changement, nous ouvrons le processus visant à permettre à un bot d'obtenir le statut Vérifié et le rendons également plus transparent. Pour « vérifier » un bot, l'entité qui exploite ce dernier doit démontrer deux choses : que le bot se présente de manière honnête et qu'il n'abuse pas de l'accès que cette honnêteté lui confère. Enfin, nous développons actuellement des outils de gestion pour faciliter la tâche aux exploitants de bots et leur permettre d'assurer une représentation précise au sein du système de classification Cloudflare (à annoncer prochainement). 

^{Une capture d'écran de la plateforme à venir, conçue directement pour les exploitants de bots qui font partie ou souhaitent faire partie de BotBase, la nouvelle génération de l'annuaire des bots Cloudflare.}

Autre élément de l'équation : le bot (ou l'agent) à votre porte n'est de plus en plus souvent pas géré par l'entreprise qui l'a développé. Une plateforme comme la Cloudflare Developer Platform exécute des automatisations pour des milliers d'exploitants différents en même temps, qui vont des entreprises aux développeurs dont vous n'avez jamais entendu parler. Vous pouvez faire confiance à Stripe, mais vous n'avez pas nécessairement à faire confiance à tous les utilisateurs qui ont intégré les outils Stripe à un projet personnel (weekend project).

Nous considérons le scénario « propriétaire de site → entreprise détentrice du bot → utilisateur final » comme une question de confiance transitive et proposons d'utiliser l'en-tête Forwarded (Transféré) existant, tel que défini dans la RFC 7239. Cet en-tête accompagne la requête et permet aux « composants proxy de divulguer des informations perdues dans le processus de mise en proxy ». 

Il se révèle similaire à ce qu'effectue l'en-tête X-Forwarded-For pour les adresses IP ou l'en-tête X-Forwarded-Host pour préserver l'en-tête Host original. Ainsi, lorsque le propriétaire d'un site web déclare « Autoriser cet exploitant », la préférence restera en place, que l'entité exploitante vienne directement à vous ou par l'intermédiaire de trois couches d'intermédiaires de confiance. Vous trouverez davantage de détails dans notre documentation, avec un bref exemple de présentation du format ci-dessous.

Forwarded: for="openai"

En ajoutant l'extension comportant le paramètre « content-use » dont nous avons discuté ci-dessus, l'ajout de l'en-tête précisant la manière dont l'entité exploitante indique qu'elle utilisera le contenu auquel elle accède ressemblerait à ce qui suit :

Forwarded: for="openai";use="reference"

Cette approche aligne également le modèle incitatif que nous souhaitons encourager. Le fait de perdre le statut « de confiance » sur plus de 20 % des domaines web situés derrière Cloudflare constitue un puissant moyen de dissuasion. La confiance devient une qualité qui peut vous accompagner et que vous pouvez perdre.

Toutefois, à l'heure où le trafic lié aux bots se mêle au trafic d'origine humaine, il est possible que ce système de confiance transitive ne s'étende pas au-delà des utilisateurs qui peuvent se permettre d'être identifiables. Les mesures que nous proposons aujourd'hui aident à instaurer cette confiance, mais elles ne conviendront pas toujours à l'ensemble du web. Les petites sources de trafic ont besoin de confidentialité, et les entreprises qui souhaitent préserver leurs engagements en matière de respect de la vie privée doivent avoir la possibilité d'explorer des éléments constitutifs équitables pour l'avenir d'un Internet agentique, comme le contrôle du volume des requêtes.

Il s'agit là de petits changements qui vont dans la même direction : permettre aux propriétaires de sites d'obtenir davantage de contrôle sur qui utilise leur contenu et de quelle manière. Nous pensons que les nouveaux paramètres par défaut dont nous avons discuté aujourd'hui et que nous allons bientôt mettre en œuvre encouragent la transparence et reflètent davantage la direction que prend le monde.

Bien entendu, les fluctuations d'Internet continueront de survenir sous nos yeux et nous devrons nous adapter constamment. Mais la direction générale ne changera pas, car il s'agit toujours de celle avec laquelle Cloudflare a commencé : un écosystème web bâti autour de la confiance. Un écosystème au sein duquel les créateurs peuvent décider de la manière dont leurs créations sont utilisées et dans lequel faire preuve d'honnêteté sur ses intentions permet de disposer de davantage d'accès, pas d'un accès réduit.

Ces nouvelles options de gestion du trafic lié à l'IA sont désormais disponibles et peuvent être configurées par tous les clients existants dans leurs paramètres de zone. Votre site n'est pas encore sur Cloudflare ? Souscrivez à notre offre gratuite et définissez les mesures de contrôle du trafic que vous souhaitez dès aujourd'hui.

Bonne Journée de l'indépendance du contenu.