Cloudflare a mis en service le 4 novembre un ensemble de fonctions d'analyse et de contrôle pour le trafic des agents personnels. Les webmasters peuvent désormais voir à part, dans leur interface, les agents qui comparent des prix, font des recherches ou passent des commandes pour le compte des utilisateurs, et définir une politique d'accès pour chacun.
Ce trafic était jusqu'ici difficile à traiter. Derrière chaque agent se trouve un vrai utilisateur : tout bloquer peut faire perdre des clients, tout laisser passer empêche de voir ce que les agents font. L'idée de Cloudflare cette fois est de les distinguer d'abord du trafic automatisé, puis de laisser les règles d'accès au webmaster.
« Better visibility into agent activity allows you to decide what access makes sense for your site. »
(Mieux voir l'activité des agents permet de décider quels accès ont du sens pour votre site.)
Ce qui change dans l'interface
Analyse. Le graphique Bot Analysis de Security Analytics gagne une catégorie Personal Assistants, aux côtés de Verified Bot, Likely Human, Likely Automated et Automated. Les Top statistics comptent aussi un nouveau composant qui liste les agents visitant le site et leur nombre de requêtes ; lorsqu'on filtre sur un agent, les autres composants affichent les chemins demandés, les codes d'état reçus et les réseaux d'origine.
Niveau du compte. Les sites ayant activé Account Abuse Protection peuvent en outre voir pour quel utilisateur l'agent agit. Les événements de connexion et d'inscription indiquent s'ils ont été lancés par un agent personnel et lequel, et les équipes antifraude peuvent filtrer les comptes selon les événements ou le volume par agent. Si un attaquant s'est servi d'un agent pour pénétrer dans un compte, il est possible d'écrire une règle WAF fondée sur le Hashed User ID qui ne traite que ce compte, sans toucher aux autres utilisateurs du même agent. Cette capacité reste en accès anticipé.
Politiques. Les anciennes politiques AI bots se répartissaient en Search, Training et Agents ; Agents s'étend désormais aux agents personnels pris en charge, et le réglage s'intitule AI Crawler and Agent access policies. Chaque agent dispose de trois options :
- Allow : ne pas bloquer ;
- Block on pages with ads : bloquer uniquement sur les pages avec publicité ;
- Block : bloquer directement.
Les politiques Search et Training ne changent pas. Lors de l'intégration d'un nouveau site, l'assistant de configuration demande s'il se finance par la publicité, puis recommande une politique en conséquence.
La deuxième option est celle qui révèle le mieux l'intention de cette fonction. Quand un agent lit des pages à la place d'une personne, personne ne regarde les publicités, et les sites qui en vivent perdent des revenus d'affichage ; en revanche, le même agent qui se rend sur une page produit pour passer une commande est une bonne chose pour le site. Bloquer selon le type de page répond mieux aux besoins réels des webmasters qu'une coupe franche fondée sur l'identité.
Ce que le blog ne dit pas
L'article ne fournit pas la liste des agents pris en charge et indique seulement que les options précises sont à consulter dans l'interface ; il ne précise pas non plus à quelles offres ces fonctions correspondent, ni dans quelle catégorie tombent les agents non reconnus. Sur le critère d'identification, il mentionne seulement que Cloudflare tient le plus grand répertoire de bots vérifiés, sans expliquer ce qu'un agent doit faire pour y figurer.
Ces points influent directement sur l'efficacité. Un agent qui ne s'annonce pas et reste mêlé au trafic ordinaire échappe aux trois niveaux de politique. Lorsqu'Amazon a bloqué en septembre le Muse de Meta, l'une des raisons était précisément que cet agent ne déclinait pas son identité en naviguant.
Cloudflare indique que les prochaines étapes sont au nombre de trois : transmettre le contexte utilisateur de façon à préserver la vie privée, aider à évaluer la réputation et établir clairement les responsabilités en cas de problème. Les solutions concrètes et le calendrier n'ont pas encore été communiqués.
Le regard des sites installés en Chine
Les sites en Chine qui utilisent Cloudflare peuvent dès maintenant consulter ce réglage dans Security Settings. Il vaut mieux observer les données quelque temps avant d'agir : les sites de contenu peuvent commencer par « bloquer uniquement sur les pages avec publicité » ; pour le commerce en ligne et les sites d'outils, si les agents apportent des inscriptions et des commandes, les laisser passer est plus rentable.
Du côté du mobile, la Chine suit une voie similaire. Quand ByteDance a lancé en septembre la version grand public de l'assistant mobile Doubao, elle a publié en même temps le protocole SAEP, qui permet aux applications tierces de déclarer si elles autorisent l'assistant à automatiser des actions à l'écran. Les deux mécanismes agissent à des niveaux différents, l'un à l'entrée du réseau, l'autre à l'écran du système, mais l'idée est la même : la partie sollicitée dispose désormais d'un interrupteur explicite.
Avec ces interrupteurs côté webmaster, les éditeurs d'agents font face à une situation nouvelle : un même assistant pourra faire des choses de plus en plus différentes selon le site. Contre qui les utilisateurs se retourneront lorsqu'une tâche échouera, personne ne le sait pour l'instant.
Sources : blog officiel de Cloudflare, CocoLoop ; l'étendue des fonctions suit l'annonce de Cloudflare, le contexte sur Doubao et Amazon provient de reportages publics.