Cloudflare veut mesurer la fiabilité des robots au fil de leur navigation

Une identité connue ne suffit plus

Cloudflare présente un système chargé d’évaluer les robots déjà reconnus par son programme Verified Bots. Un robot est ici un logiciel qui visite automatiquement des pages et envoie des requêtes aux sites. L’entreprise veut désormais vérifier son comportement après l’identification initiale. Elle observe notamment s’il respecte les choix publiés par les propriétaires et s’il adapte son rythme lorsque l’accès devient indésirable.

L’enjeu précède les détails techniques. Un robot parfaitement identifié peut encore parcourir des zones refusées, surcharger le serveur d’origine ou contourner des contrôles. Le serveur d’origine est l’infrastructure qui héberge réellement le contenu derrière Cloudflare. Selon l’entreprise, ces écarts ne révèlent pas toujours une intention malveillante. Une erreur de configuration ou un défaut logiciel peuvent aussi expliquer le comportement observé.

Pour les propriétaires de sites, cette différence conditionne le trafic qu’ils acceptent. Une identité reconnue apporte de la responsabilité, mais elle ne garantit pas que les consignes seront suivies. Pour les opérateurs de robots, le suivi doit offrir un moyen de démontrer une conduite fiable dans le temps. Cloudflare cherche ainsi à rattacher la confiance à des comportements observables, plutôt qu’au seul nom déclaré.

De la vérification à la confiance

Pour intégrer la liste Verified Bots, un opérateur doit annoncer correctement son identité, accomplir seulement l’activité déclarée et éviter les pratiques abusives. Web Bot Auth permet au robot de signer ses requêtes, donc de prouver leur provenance. BotBase catalogue ensuite ces identités dans un format ouvert. Ce mécanisme répond à la question de l’auteur d’une requête, mais pas à celle de sa conduite future.

Cloudflare sépare ainsi le risque et la confiance. Le risque décrit la possibilité qu’une requête précise provoque un dommage à un instant donné. La confiance résulte, elle, d’un comportement cohérent observé pendant une certaine durée. L’entreprise cite le robot de Perplexity, retiré de sa liste en 2025. Il aurait visé des ressources dont les sites refusaient l’extraction, puis tenté de contourner les blocages rencontrés.

Une méthode centrée sur les consignes publiées

La première partie de la méthode compare le trafic observé aux préférences inscrites dans robots.txt. Ce fichier texte indique aux robots quelles parties d’un site ils peuvent parcourir. Son fonctionnement est décrit par la RFC 9309, un document technique qui formalise ce protocole. Cloudflare cherche des violations répétées, car un incident isolé ne suffit pas nécessairement à caractériser une conduite durable.

Les observations portent aussi sur la réponse donnée aux retours directs des sites. Cloudflare précise que robots.txt fixe seulement les interdictions minimales. L’absence d’une règle ne vaut donc pas autorisation générale selon son interprétation. Un site peut transmettre autrement que la poursuite de l’accès n’est plus souhaitée. Le système vérifie alors si le robot tient compte de ce signal complémentaire.

À ce stade, Cloudflare retient deux questions principales. Le robot respecte-t-il les instructions publiées, et réagit-il aux demandes directement formulées par le site ? L’évaluation porte sur des tendances durables, pas sur un écart unique. Cette méthode vise à distinguer une anomalie ponctuelle d’une pratique qui se répète malgré les préférences exprimées.

Le ralentissement devient un signal mesurable

Un robot peut respecter toutes les zones autorisées tout en envoyant trop de demandes. Le site peut répondre avec le code HTTP 429, nommé « Trop de requêtes ». HTTP désigne le protocole utilisé pour échanger des données sur le Web. Cette réponse demande au visiteur de réduire son débit et peut lui indiquer combien de temps attendre avant un nouvel essai.

La méthode observe la réaction qui suit. Un ralentissement ou une pause répétés renforcent la confiance, tandis que l’ignorance régulière du signal la réduit. Ces résultats doivent former une plage de confiance explicable. Cette plage indiquera la régularité avec laquelle le robot respecte les préférences et les comportements ayant pesé dans l’évaluation. Elle ne doit pas constituer un verdict permanent sur le robot ou son opérateur.

Un déploiement progressif, avec des limites ouvertes

Cloudflare utilise déjà le système en interne afin d’accumuler un historique et d’affiner la transformation des observations en indications utiles. L’entreprise prévoit ensuite de l’ouvrir à tous ses clients. Ceux-ci pourraient choisir le seuil de confiance appliqué au traitement du trafic des robots vérifiés. Les scores doivent aussi devenir publics sur Radar, le service de Cloudflare consacré aux tendances du trafic Internet.

Dans l’interprétation proposée par Cloudflare, trois outils formeraient une boucle de responsabilité. Bot Preference Sync aide un propriétaire à publier ses préférences. Le nouveau suivi mesure leur respect dans le temps, puis Bot Management permet de décider comment traiter le trafic automatisé. Cette articulation reste toutefois décrite par son concepteur, qui fournit ici sa méthode et ses objectifs, sans résultats chiffrés ni évaluation indépendante.

Plusieurs limites empêchent donc d’estimer encore l’efficacité réelle du dispositif. Cloudflare ne précise ni la formule du score, ni les seuils envisagés, ni la durée nécessaire pour établir une tendance. La source ne détaille pas davantage le traitement des erreurs d’identification ou des incidents techniques. Enfin, la publication sur Radar et l’accès général aux clients sont des projets annoncés, sans calendrier indiqué.