Agents personnels Cloudflare : autoriser, limiter ou bloquer les assistants IA sur votre site

Les nouveaux contrôles de bots de Cloudflare visent à sortir les propriétaires de sites d'un piège bien précis. Comme l'explique Cloudflare dans son article sur la Trusted Agent Delegation, lorsqu'un utilisateur détourne un agent partagé pour du credential stuffing, du scraping ou du test de cartes bancaires, le site peut détecter l'abus mais ne peut que bloquer l'agent, ce qui bloque aussi tous ses utilisateurs légitimes. Alors que de plus en plus de clients envoient des assistants IA naviguer, comparer et acheter à leur place, c'est un choix coûteux auquel on ne devrait pas être contraint.

Les nouveaux contrôles permettent de choisir une politique différente pour chaque agent personnel pris en charge, au lieu de se contenter d'un blocage du tout ou rien. Je présente ci-dessous leur fonctionnement, un modèle de déploiement réutilisable et les points sur lesquels les preuves restent minces.

Pourquoi les agents personnels méritent leur propre politique

Crawlers et agents peuvent se ressembler dans vos logs, mais ils soulèvent des questions différentes. Un crawler d'entraînement collecte du contenu pour construire un modèle. Un crawler de recherche indexe des pages pour les faire remonter plus tard.

Avec les crawlers, vous vous demandez si vous voulez que votre contenu soit utilisé. Avec les agents personnels, vous vous demandez si vous voulez servir un client qui a choisi d'envoyer un logiciel à sa place. Le volet crawlers implique ses propres décisions, traitées dans notre carte de migration des crawlers Cloudflare pour les équipes SEO.

Prenez l'argument du volume avec prudence. Cloudflare affirme que le trafic agentique croît rapidement et pourrait éclipser la navigation humaine traditionnelle dans un avenir proche. En septembre, Matthew Prince, PDG de Cloudflare, a prédit que le trafic des bots atteindrait 1,000 fois le trafic humain d'ici cinq ans. Ce sont des prévisions émanant d'une entreprise qui vend des outils de gestion de ce trafic. Ce ne sont pas des mesures.

L'idée la plus utile est ce que Cloudflare appelle l'Intermediation Principle (principe d'intermédiation) : la relation commerciale entre les utilisateurs et les sites, ainsi que les responsabilités de sécurité de chaque participant, doivent être maintenues quelle que soit l'intermédiation. Votre client reste votre client lorsqu'un assistant clique à sa place. Une grande partie de cette nouveauté vise à rendre ce principe applicable.

L'échelle est la raison d'y prêter attention, même si vous n'utilisez pas Cloudflare. L'entreprise indique que plus de 20% des domaines web se trouvent derrière son réseau : les valeurs par défaut et les catégories qu'elle définit influencent donc la manière dont une large part du web traite les agents.

Ce qui a changé dans les politiques d'accès

La configuration se trouve dans Security Settings. Comme l'explique l'annonce de Cloudflare sur les agents personnels, vous définissez une politique Agents globale, puis choisissez une politique différente pour chaque agent personnel pris en charge. Chaque agent reçoit l'une de ces actions :

• Allow (do not block) : le trafic correspondant passe. Je l'appellerai simplement Allow dans la suite.
• Block on pages with ads : l'agent est arrêté sur les pages qui affichent des publicités, mais peut toujours accéder au reste du site.
• Block : le trafic correspondant est bloqué sur l'ensemble du site.

Pour le contexte, le tableau de bord Account Abuse Protection sur lequel tout cela repose a été lancé le 2 octobre 2026.

Comment fonctionne l'héritage

C'est ici que les équipes se font piéger. Selon la documentation de Cloudflare sur les politiques d'accès, les agents personnels héritent par défaut de la politique Agents, et modifier la politique Agents met à jour chaque agent personnel. Vous pouvez ensuite redéfinir des actions individuelles, mais vos surcharges par agent ne survivront pas à une modification de la politique parente.

Cloudflare recommande Allow pour les agents personnels. Pour la plupart des entreprises, c'est la bonne valeur par défaut, pour les raisons qu'explique la matrice de décision ci-dessous.

Lire la catégorie Personal Assistants

Dans Security Analytics, le graphique Bot Analysis affiche désormais Personal Assistants comme nouvelle catégorie, à côté de Verified Bot, Likely Human, Likely Automated et Automated. Ouvrez cette vue avant de toucher à la moindre politique. Vérifiez le volume de trafic d'assistants reconnus que vous recevez et s'il est stable ou s'il connaît des pics autour d'événements particuliers. Surtout, vérifiez quels chemins il atteint.

Ce sont les chemins qui déterminent la politique. Un assistant qui lit des articles financés par la publicité pose une question de revenus. Un assistant qui sollicite la connexion et le paiement pose une question de fraude et de conversion. Le même volume peut justifier des réglages très différents selon l'endroit où il arrive.

Une limite s'applique dès le premier jour. La documentation de Cloudflare précise que les requêtes provenant d'assistants qu'elle ne reconnaît pas apparaissent comme du trafic ordinaire. Considérez cette catégorie comme un plancher, pas comme un décompte complet.

Contrôle au niveau du compte avec le Hashed User ID

C'est la partie de la nouveauté qui s'attaque directement au piège de l'agent partagé. S'il semble qu'un attaquant utilise un agent sur un compte, les analystes fraude peuvent neutraliser ce compte grâce à une règle WAF portant sur son Hashed User ID, sans bloquer l'agent pour tous les autres utilisateurs qui en dépendent. La couverture indépendante d'Unite.AI décrit le même mécanisme : la règle cible le Hashed User ID du compte plutôt que l'agent dans son ensemble.

Il existe deux actions. Managed Challenge ajoute de la friction, tandis que Block arrête purement et simplement les requêtes du compte. La documentation Account Abuse Protection de Cloudflare indique que seul le compte ciblé est concerné, y compris lorsqu'il utilise un assistant IA sur lequel s'appuient d'autres utilisateurs.

Le tableau de bord fait aussi remonter des signaux sur les identifiants. Dans l'exemple de tableau de bord fourni par Cloudflare, environ 2.4K événements ont produit un résultat de nom d'utilisateur ou de mot de passe divulgué, contre 11.7K événements où les identifiants ont été classés comme sains. Cela vous montre à quoi ressemble la vue. Ce n'est pas une référence pour votre propre trafic.

Prévoyez deux contraintes. D'abord, Account Abuse Protection est en Early Access pour les clients Bot Management Enterprise, sans coût supplémentaire pendant une période limitée, jusqu'à sa disponibilité générale. Établissez votre budget en partant du principe que la tarification changera. Ensuite, la documentation de Cloudflare limite la visibilité sur les assistants IA aux événements de connexion et d'inscription : un abus commis ailleurs dans une session ne sera donc pas attribué à un assistant par cette fonctionnalité.

Matrice de décision par modèle économique

Le bon réglage dépend de la façon dont votre site gagne de l'argent. Considérez les positions ci-dessous comme des données d'entrée pour l'étape Surcharge de la méthode présentée plus bas. Ce sont des points de départ. Si votre propre référence indique autre chose, suivez vos données.

Éditeurs financés par la publicité

Lorsqu'un assistant lit votre article et le résume pour son utilisateur, cette visite peut ne générer aucun revenu publicitaire. Cloudflare a lui-même penché dans ce sens. Son annonce de juillet 2026 indiquait que, pour tous les nouveaux domaines rejoignant Cloudflare, les catégories Training et Agent seraient bloquées par défaut sur les pages affichant des publicités, tandis que Search resterait autorisée. La documentation actuelle décrit des valeurs par défaut différentes, sur lesquelles je reviens plus bas : vérifiez donc vos propres zones.

SaaS

Pour un produit SaaS, un agent qui se connecte est très probablement un client payant qui automatise son propre travail. Bloquer les agents en bloc risque de casser des workflows et de déclencher une vague de tickets de support. Le réglage Allow recommandé convient à ce modèle. Lorsqu'un abus apparaît, agissez sur le Hashed User ID plutôt que sur l'agent entier.

E-commerce

Les agents atteignent déjà le paiement. Les données de Microsoft Clarity montraient que le paiement apparaissait dans 25% des sessions d'agents IA, contre 15% pour les humains. Bloquez un agent et vous risquez de bloquer des acheteurs.

Les blocages généralisés existent bel et bien. Début octobre, Muse de Meta représentait 72% des requêtes d'agents IA dans les données de HUMAN, et Amazon a empêché Muse de faire des achats sur son site. Nous suggérons de considérer tout blocage généralisé comme la décision d'une entreprise donnée, et non comme un modèle pour la vôtre.

L'exposition à la fraude est elle aussi réelle. Arkose Labs a indiqué que 65.2% de ses clients avaient vu des agents IA atteindre les parcours de connexion, d'inscription et de paiement. Il s'agit d'une part des clients d'Arkose, pas des sessions. Nous suggérons d'y voir une tendance plutôt qu'une référence pour votre propre site. Ce chiffre plaide tout de même pour associer Allow à une surveillance active des comptes, au lieu de traiter la décision comme un choix binaire entre ouvert et fermé.

Contenu et commerce combinés

De nombreux sites proposent des articles financés par la publicité aux côtés d'un parcours de paiement, d'un espace membres ou d'un produit accessible après connexion. Une action unique à l'échelle du site leur convient rarement. Un point de départ raisonnable consiste à maintenir la politique Agents globale sur Allow, afin que les agents puissent atteindre les pages de connexion, de compte et de paiement, et à appliquer Block on pages with ads uniquement aux agents dont la référence montre une lecture intensive des pages publicitaires. Cette action suit les publicités, pas la section du site. Vérifiez que vos pages commerciales et vos pages accessibles après connexion n'affichent aucune publicité, sinon le blocage les atteindra également. Répartissez les responsabilités selon la même ligne : l'équipe contenu ou revenus gère les surcharges sur les pages publicitaires, et l'équipe fraude gère les réponses au niveau des comptes.

Tableau récapitulatif

Méthode : la boucle Référence-Héritage-Surcharge-Confinement-Revue

Nous suggérons de mener cette démarche comme une boucle en cinq étapes. Chaque étape produit un livrable concret, ce qui vous permet de savoir quand elle est terminée et où reprendre lors de la revue suivante.

Étape 1 : Référence

Examinez le trafic Personal Assistants dans Bot Analysis sur une période suffisamment longue pour couvrir les cycles hebdomadaires normaux et d'éventuelles promotions. Regroupez les pages consultées par les assistants en pages publicitaires, connexion et inscription, pages produits et paiement. Livrable : une vue Bot Analysis enregistrée et les principaux chemins par agent.

Étape 2 : Héritage

Définissez d'abord la politique Agents globale, puisque chaque agent personnel en hérite. Consignez-la comme première ligne d'un journal des surcharges, avec la date et la personne qui l'a approuvée. Traitez toute modification ultérieure comme une demande de changement, et relevez les réglages actuels par agent avant que quiconque n'y touche, car la modification les réinitialise. Livrable : une politique parente consignée et un accord selon lequel elle ne change qu'après revue.

Étape 3 : Surcharge

Démarrez chaque agent sur Allow. Ne passez un agent sur Block on pages with ads ou Block que lorsqu'une entrée du journal le justifie. Voici un modèle à titre d'illustration, et non un véritable dossier client :

Livrable : une entrée par surcharge. Tout ce qui n'a pas d'entrée revient à la politique parente lors de la revue suivante.

Étape 4 : Confinement

Si vous disposez de Bot Management Enterprise, activez Account Abuse Protection et préparez des règles WAF ciblant un Hashed User ID. Commencez par Managed Challenge et ne passez à Block que lorsque les preuves le justifient. Rédigez la procédure d'escalade comme un runbook de kill switch pour agents IA, avec des déclencheurs et des responsables clairs, afin que l'analyste d'astreinte n'ait pas à improviser. Consignez chaque règle de compte comme vous consignez une surcharge : référence du compte, action, déclencheur, responsable et date d'expiration. Livrable : un chemin d'escalade écrit et un journal des règles.

Étape 5 : Revue

Faites une revue mensuelle ou trimestrielle, selon le trafic. Vérifiez les valeurs par défaut des domaines nouvellement ajoutés, réappliquez les surcharges consignées après tout changement de la politique parente, faites expirer les règles de compte dont vous n'avez plus besoin et réexaminez les réglages après les lancements d'agents majeurs. Revenez ensuite à l'étape 1 avec une nouvelle référence.

C'est la répartition des responsabilités qui garantit la rigueur de la boucle. Les équipes marketing ou revenus devraient prendre en charge les décisions sur les pages publicitaires, car elles peuvent mettre en balance les visites et les revenus. Les équipes sécurité ou fraude devraient prendre en charge les actions au niveau des comptes, car ce sont elles qui détiennent les preuves.

Erreurs fréquentes

Confondre Allow et identité. Comme le souligne Forkast, une politique d'agent détermine si le trafic correspondant est autorisé, mais elle n'établit pas à elle seule l'identité du compte utilisateur ni qui a autorisé l'action concernée. Votre authentification habituelle continue de s'appliquer, qu'il s'agisse de mots de passe avec MFA ou d'un déploiement de passkeys avec une récupération solide.

Supposer que les signatures vérifient l'humain. Une signature Web Bot Auth authentifie l'identité de l'agent ou du bot. Elle ne vous dit rien de la personne qui se trouve derrière.

Bloquer un agent partagé pour arrêter un seul fraudeur. Cela coupe l'accès à tous les utilisateurs légitimes de l'agent. Utilisez la neutralisation au niveau du compte lorsque c'est possible.

Oublier l'héritage. Modifiez la politique Agents parente et chaque choix par agent devra être réappliqué.

Interpréter un faible chiffre Personal Assistants comme un faible trafic d'agents. Les assistants non reconnus apparaissent comme du trafic ordinaire : une catégorie modeste peut donc masquer une réalité plus large.

Mises en garde et limites

L'angle mort de la visibilité. Seuls les assistants que Cloudflare reconnaît sont étiquetés et bénéficient d'un contrôle par agent. Votre politique couvre les agents que Cloudflare sait identifier, pas tous les assistants automatisés.

Des sources contradictoires sur les valeurs par défaut. L'article de blog de juillet 2026 indiquait que les nouveaux domaines bloqueraient par défaut Training et Agent sur les pages publicitaires. La documentation actuelle indique que, pour les nouveaux domaines, Search, Agents et Training utilisent Allow par défaut. Lorsque les deux divergent, fiez-vous à votre tableau de bord.

Les limites de la détection. Lors du propre test de Resemble AI, les outils anti-bots ont détecté entre 3.1% et 14.8% des agents IA déguisés. C'est un chiffre de fournisseur, sans taille d'échantillon publiée, mais la tendance est claire : les agents conçus pour ressembler à des humains sont difficiles à repérer.

L'angle mort de l'identité. Arkose Labs a constaté que 97.7% des sessions légitimes d'agents IA ne portaient aucun identifiant vérifié entre le 1er juillet et le 30 septembre. Nous suggérons de partir du principe que le trafic légitime des agents peut vous parvenir sans aucune identité vérifiée.

Des standards encore jeunes. L'article sur la Trusted Agent Delegation évoque une coalition travaillant sur la délégation d'agents, mais ne cite aucun de ses membres, et le site web de la coalition non plus. Ce site indique que les standards ouverts sont en cours d'élaboration à l'IETF et au W3C. Attendez-vous à ce que les mécanismes évoluent à mesure que ces travaux avancent.

Des chiffres sans lien. Plusieurs chiffres et citations de tiers dans cet article sont attribués, mais sans lien vers leur publication d'origine. Vérifiez la méthodologie et les dates à la source avant de les réutiliser. Les prévisions de trafic proviennent par ailleurs de Cloudflare lui-même : utilisez-les pour dégager une tendance, pas pour planifier vos capacités.