Cloudflare ajoute l’analyse du trafic des agents personnels et des politiques d’accès par agent, mais les vues par compte sont en accès anticipé et l’article ne liste pas les agents pris en charge
Le 4 novembre 2026, Cloudflare a ajouté une analyse et des politiques d’accès pour les agents personnels : Security Analytics gagne une catégorie et un widget « Personal Assistants » montrant chemins, codes d’état et réseaux de chaque agent, et les paramètres de sécurité permettent de choisir Allow, Block on pages with ads ou Block pour chaque agent pris en charge. Les vues par compte relèvent d’Account Abuse Protection, encore en accès anticipé ; contexte utilisateur, réputation et responsabilité ne sont que des objectifs suivants. L’article ne liste ni agents pris en charge, ni précision d’identification, ni offres concernées.
Le 4 novembre 2026, le blog de Cloudflare a présenté deux séries de nouveautés pour aider les propriétaires de sites à voir et à contrôler les « agents personnels ». Un agent personnel est un logiciel qui transforme les instructions d’une personne en requêtes et en actions sur des sites, par exemple comparer des produits, trouver des articles d’assistance ou finaliser un achat. Pour un site, tout cela ressemble à du trafic automatisé. L’article soutient que bloquer entièrement les agents peut faire perdre des clients, alors que ne pas savoir quel agent fait quoi empêche de dire si le trafic aide ou crée un risque. C’est un article de produit de Cloudflare, sans données de résultats.
La première série concerne l’analyse. Dans Security Analytics, le graphique Bot Analysis affiche une nouvelle catégorie « Personal Assistants » à côté de Verified Bot, Likely Human, Likely Automated et Automated, ce qui permet de voir ce trafic seul dans le temps. Dans Top statistics, un nouveau widget Personal Assistants liste les agents qui visitent le site et le nombre de requêtes de chacun. En filtrant sur un agent, tous les autres widgets n’affichent plus que son trafic : chemins demandés, codes d’état reçus et réseaux d’origine. On voit ainsi si un agent se connecte, lit des fiches produits, atteint le paiement ou rencontre des erreurs sur des pages inutilisables. L’article dit que Cloudflare tient le plus grand annuaire de robots vérifiés au monde et l’intègre aux détails du trafic, mais ne donne aucun chiffre de précision pour l’identification et ne liste pas les agents pris en charge.
Pour les sites qui protègent des comptes d’utilisateurs, l’article décrit aussi des vues dans Account Abuse Protection et précise que ce produit est actuellement en accès anticipé. Une vue d’ensemble de la population montre quels agents personnels sont actifs parmi les utilisateurs et combien de comptes les emploient. Chaque connexion et chaque inscription indique si un agent personnel a fait la requête et lequel, et les équipes antifraude peuvent filtrer les comptes par événements d’assistant IA ou par nombre d’assistants IA. L’aperçu d’un compte liste les agents qui agissent pour lui. Si un analyste juge qu’un attaquant utilise un agent sur un compte, il peut écrire une règle WAF sur l’identifiant utilisateur haché de ce compte, sans bloquer l’agent pour tous ceux qui s’en servent. Ces vues n’intéressent que les clients disposant de ce produit en accès anticipé.
La seconde série concerne les politiques d’accès. Cloudflare a introduit cet été des politiques pour les robots d’IA, qui permettent de régler séparément les comportements de recherche, d’entraînement et d’agent. L’article d’appui du 1er juillet indique qu’à partir du 15 septembre 2026, les nouveaux domaines ajoutés à Cloudflare bloquent par défaut les robots d’entraînement et d’agent sur les pages qui affichent des publicités, la recherche restant autorisée. Désormais, la politique Agents existante gagne des options fines pour les agents personnels pris en charge, et la section est renommée AI Crawler and Agent access policies. Dans les paramètres de sécurité, on définit une politique générale pour les agents, puis on choisit pour chaque agent personnel pris en charge entre « Allow (do not block) », « Block on pages with ads » et « Block ». Par exemple, la politique générale peut être « Block on pages with ads » et un agent que le site veut accueillir peut être réglé sur « Allow ». Les politiques de recherche et d’entraînement existantes ne changent pas. Les mêmes choix sont proposés à l’ajout d’une nouvelle zone, où Cloudflare demande si le site monétise ses pages par la publicité et adapte sa recommandation.
L’article d’appui du 1er juillet ajoute deux points qui touchent ces politiques. D’abord, à partir du 15 septembre, les robots à usages multiples qui combinent recherche et entraînement sont autorisés ou bloqués selon l’ensemble de leurs comportements, avec la règle applicable la plus restrictive : des robots comme Googlebot, Applebot et BingBot sont donc bloqués par les clients qui bloquent l’entraînement. Ensuite, le même article a présenté BotBase, une base consultable de tous les robots connus, y compris les robots vérifiés et les agents, pour les clients Enterprise Bot Management ; elle n’offrait alors que de la visibilité, les contrôles étant promis plus tard dans l’année. L’article du 4 novembre ne dit pas si les nouvelles vues d’agents personnels s’appuient sur BotBase ni comment les agents pris en charge se rattachent à cet annuaire, et il ne faut pas le supposer.
L’article termine en disant que l’identité de l’agent n’est qu’une partie du sujet. Un site peut reconnaître l’agent sans connaître ce qu’il saurait normalement de l’utilisateur : est-il client, qu’a-t-il autorisé l’agent à faire, a-t-il un abonnement, quelles protections appliquer. Le prochain objectif de Cloudflare est de transporter le contexte de l’utilisateur à travers un agent dans le respect de la vie privée, d’aider à évaluer la réputation et d’établir la responsabilité en cas de problème. Ce sont des projets, sans calendrier dans l’article.
Il faut distinguer ce qui est livré de ce qui est prévu. Sont livrés la nouvelle catégorie d’analyse, le widget et la politique à trois niveaux pour chaque agent pris en charge. Les vues par compte sont en accès anticipé. Le contexte utilisateur, la réputation et la responsabilité sont des projets. L’article ne nomme pas les agents pris en charge ni les offres qui incluent ces fonctions : vérifiez dans votre propre tableau de bord Cloudflare avant de vous y fier.
Sources
FAQ
Cette mise à jour permet-elle de fixer des règles d’accès différentes par agent personnel ?
Oui, mais seulement pour les agents personnels pris en charge. Dans les paramètres de sécurité, on définit une politique générale pour les agents, puis on choisit pour chaque agent pris en charge Allow (do not block), Block on pages with ads ou Block. L’article ne liste pas ces agents : vérifiez dans votre propre tableau de bord.
Les vues d’agents par compte sont-elles ouvertes à tous les clients Cloudflare ?
Les vues reliant les agents aux connexions, inscriptions et comptes relèvent d’Account Abuse Protection, actuellement en accès anticipé. Le billet décrit séparément la catégorie analytique Personal Assistants, son widget et les politiques par agent, sans préciser les forfaits ou comptes éligibles. Sans Account Abuse Protection, il faut vérifier la disponibilité selon son compte et son forfait.
Cette sortie dit-elle à un site ce que l’utilisateur derrière l’agent a autorisé ?
Non. L’article précise que reconnaître l’agent n’est qu’une partie du sujet. Transporter le contexte de l’utilisateur, évaluer la réputation et établir la responsabilité sont des objectifs suivants : un site saurait alors si l’utilisateur est client et ce qu’il a autorisé. Ce sont des projets sans calendrier, on ne peut pas encore s’y fier.