La responsabilité continue de Cloudflare pour les bots vérifiés transforme l’identité en évaluation permanente

Cloudflare a introduit le 16 octobre une responsabilité continue pour les bots vérifiés, ajoutant une évaluation permanente du comportement à un programme auparavant centré sur l’identité. Cette évolution répond à un conflit fondamental : un crawler peut prouver qui l’exploite tout en ignorant les règles d’un site web.

Le nouveau système observe si l’automatisation vérifiée respecte les préférences publiées et réagit lorsqu’un site lui demande de ralentir. Cloudflare convertit ensuite ces observations en une plage de confiance explicable, plutôt que de considérer la vérification comme un sceau d’approbation permanent.

Cette distinction compte depuis que Cloudflare a retiré Perplexity de sa liste de bots vérifiés en 2025. Cloudflare a allégué que Perplexity avait accédé à du contenu restreint et modifié ses tactiques d’exploration lorsqu’il était bloqué. Perplexity a contesté cette caractérisation. L’épisode a révélé la faiblesse que Cloudflare cherche désormais à corriger : l’authentification peut identifier un bot, mais l’identité seule ne peut garantir un bon comportement.

La responsabilité continue des bots vérifiés ajoute une couche comportementale

Cloudflare transforme la vérification, auparavant une décision ponctuelle sur l’identité, en une évaluation continue du comportement.

Le programme Verified Bots de Cloudflare a historiquement aidé les sites web à distinguer l’automatisation reconnue du trafic inconnu ou potentiellement malveillant. Les crawlers de recherche, services de supervision, outils d’accessibilité et agents pilotés par les utilisateurs peuvent tous demander le statut vérifié.

Un bot doit s’identifier au moyen d’une méthode acceptée. Ces méthodes comprennent les signatures cryptographiques, les plages d’adresses IP publiées associées à des agents utilisateurs stables, ainsi que les vérifications DNS inversées.

La politique relative aux bots vérifiés de Cloudflare exige également un comportement non abusif. Les services vérifiés doivent respecter les instructions de robots.txt, maintenir des taux de requêtes raisonnables et éviter de contourner les préférences des sites web.

Le problème est temporel. Un opérateur peut satisfaire à ces conditions lors de son inscription, puis déployer une mise à jour qui modifie le comportement de son crawler. Une erreur de configuration peut aussi générer un trafic nuisible sans intention malveillante.

Le nouveau système de Cloudflare surveille cet écart. Il mesure la régularité avec laquelle un crawler suit les préférences d’un site au fil du temps et enregistre le comportement à l’origine de son évaluation.

Le résultat est une plage de confiance explicable. Cloudflare la décrit comme une fourchette reflétant un comportement durable, et non comme un jugement permanent sur une entreprise ou un opérateur.

Cette approche sépare le risque de la confiance. Le risque concerne le préjudice potentiel associé à une requête ou à un instant donné. La confiance reflète un schéma répété sur de nombreuses interactions.

Un crawler vérifié peut produire une violation accidentelle de politique sans devenir catégoriquement indigne de confiance. À l’inverse, un bot qui ignore à plusieurs reprises les restrictions ne devrait pas conserver un traitement privilégié simplement parce qu’il a passé un contrôle d’identité antérieur.

Cloudflare indique que ses premiers signaux d’évaluation posent deux questions. Le bot a-t-il respecté les instructions publiées, et a-t-il réagi aux retours directs du site web ?

Ces signaux se concentrent sur le comportement réseau observable. Ils n’obligent pas Cloudflare à déduire les intentions privées de l’opérateur d’un crawler.

Cette approche offre aussi aux opérateurs une voie de rétablissement. Une plage de confiance peut s’améliorer lorsqu’un bot modifie systématiquement son comportement après avoir reçu des instructions ou des réponses de limitation de débit.

Cloudflare utilise déjà le système en interne. L’entreprise prévoit de rendre l’évaluation accessible à ses clients après avoir constitué un historique comportemental suffisant et affiné ses recommandations.

Les clients pourront à terme choisir un seuil de confiance pour traiter le trafic des Verified Bots. Cloudflare n’a pas annoncé de date de disponibilité générale ni communiqué la formule exacte de calcul.

Ces omissions sont importantes. L’annonce définit le principe directeur et les signaux initiaux, mais elle ne fournit pas encore une spécification complète du produit.

La direction reste néanmoins claire. Le statut vérifié signifiera de plus en plus qu’un bot demeure identifiable et continue de se comporter dans les limites acceptées.

Pourquoi l’identité ne pouvait plus assumer seule toute la décision de confiance

Une identité cryptographique répond à la question de savoir qui a envoyé une requête, mais pas à celle de savoir si cette requête doit être accueillie.

Cloudflare consacre plusieurs années à renforcer l’identification des bots. Les signaux traditionnels, comme les chaînes d’agent utilisateur et les adresses IP, présentent de sérieuses limites.

Un agent utilisateur n’est qu’une étiquette envoyée avec une requête HTTP. Un autre programme peut le copier. Les plages IP peuvent changer, desservir plusieurs systèmes ou être compromises.

Web Bot Auth améliore cette couche d’identité. Il permet à un bot de signer ses requêtes au moyen de HTTP Message Signatures, qui fournissent une preuve cryptographique qu’un opérateur autorisé a créé la requête.

Cloudflare valide la signature et associe le trafic à une entrée dans BotBase, son annuaire public de bots et d’agents. Cela réduit la dépendance à des identifiants faciles à usurper.

Le format de signature sous-jacent n’est pas une invention exclusive de Cloudflare. HTTP Message Signatures a été normalisé dans le cadre de la RFC 9421, tandis que les spécifications de Web Bot Auth continuent d’être élaborées ouvertement.

La validation d’une signature ne résout encore que l’authentification. Une signature valide peut établir qu’une requête provient d’un opérateur connu. Elle ne peut pas établir que cet opérateur a respecté les restrictions d’un éditeur.

Prenons un bot de supervision qui signe correctement chaque requête, mais commence à demander des pages des centaines de fois plus vite après un déploiement défectueux. Son identité reste valide alors même que son comportement génère des coûts opérationnels.

Le même problème s’applique aux crawlers d’IA. Un crawler peut s’identifier correctement tout en demandant du contenu que le site a signalé comme indisponible pour son usage.

Cet écart devient plus important à mesure que l’automatisation assume davantage de rôles. Cloudflare classe désormais les systèmes vérifiés dans les catégories de recherche, d’entraînement de modèles, d’agents pilotés par les utilisateurs, de transactions, de tests de sécurité, de collecte de données et d’autres activités.

Certains bots agissent également comme intermédiaires. Leur infrastructure appartient à une entreprise, mais de nombreux utilisateurs peuvent initier des actions par son intermédiaire.

Cela crée ce que Cloudflare appelle une confiance transitive. Un site peut faire confiance à l’opérateur de la plateforme sans faire confiance à tous les utilisateurs qui dirigent l’agent de cette plateforme.

La responsabilité continue des bots vérifiés ne résout pas entièrement ce problème de délégation. Elle donne toutefois à Cloudflare un moyen d’évaluer le trafic qui en résulte, plutôt que de s’appuyer entièrement sur l’identité de l’opérateur.

Ce changement incite aussi les opérateurs de bots à intégrer la conformité dans les systèmes de production. Le bon comportement ne peut plus rester une promesse consignée lors de l’inscription.

Les opérateurs ont besoin d’une récupération fiable de robots.txt, d’une sélection d’URL tenant compte des politiques, d’identités propres à chaque finalité et d’un contrôle adaptatif du débit. Ils ont aussi besoin d’une supervision capable de détecter les régressions avant qu’un CDN n’enregistre un schéma préjudiciable.

Cela relève le niveau d’exigence technique pour l’automatisation vérifiée. L’authentification devient la condition d’entrée, tandis que la conformité observable détermine si la confiance qui en résulte perdure.

Robots.txt et HTTP 429 deviennent des preuves, et non des suggestions

Le mécanisme de Cloudflare transforme deux signaux web familiers en éléments de preuve du niveau de confiance continu d’un crawler.

Le premier signal est robots.txt, un fichier texte situé au chemin de premier niveau d’un site web. Il publie des instructions d’accès à destination des crawlers automatisés.

Le protocole organise les règles par agent utilisateur et utilise les directives Allow ou Disallow pour identifier les chemins accessibles. Selon la RFC 9309, un crawler qui télécharge avec succès le fichier doit suivre ses règles interprétables.

Robots.txt présente des limites pratiques. Il communique des préférences, mais ne les applique pas comme le ferait une passerelle d’authentification ou une règle de pare-feu.

Il indique également peu de choses sur les raisons pour lesquelles un crawler souhaite accéder à un contenu précis. Un opérateur peut utiliser des bots distincts pour la recherche, l’entraînement de modèles et la récupération demandée par les utilisateurs. Un autre peut regrouper ces finalités.

Cloudflare évalue si le trafic observé demeure conforme aux règles publiées par le site. Le système met l’accent sur les schémas répétés plutôt que de considérer chaque divergence isolée comme décisive.

Cette distinction réduit le risque qu’une erreur temporaire détruise automatiquement la réputation d’un bot. Elle rend aussi plus difficile de présenter un mépris persistant comme une anomalie.

Cloudflare avertit que robots.txt représente une limite minimale, et non une autorisation générale pour tout ce qu’il n’interdit pas. Un site web peut indiquer que la poursuite de l’accès n’est pas souhaitée par d’autres réponses.

HTTP 429 est le deuxième signal initial. Un serveur utilise ce code d’état pour indiquer qu’un client a envoyé trop de requêtes au cours d’une période donnée.

La réponse peut inclure un en-tête Retry-After, qui indique au client combien de temps attendre. Toutefois, cette indication est facultative.

La norme HTTP concernée laisse aux serveurs une marge de manœuvre sur la façon dont ils identifient le trafic excessif et comptabilisent les requêtes. Les serveurs peuvent appliquer des limites par ressource, identifiants ou autres critères.

Cloudflare observe ensuite ce que fait le bot. Un bot qui ralentit ou s’interrompt après avoir reçu des réponses 429 répétées démontre sa capacité d’adaptation. Celui qui continue au même rythme perd de la confiance.

La gestion des limitations de débit devient ainsi partie intégrante de la responsabilité des bots vérifiés. Elle comble aussi une faille importante, car un crawler peut rester entièrement dans les chemins autorisés tout en submergeant le serveur d’origine.

Le mécanisme combiné crée une boucle de rétroaction comportementale. Un éditeur exprime ses préférences d’accès, le serveur d’origine fournit un retour en temps réel, et Cloudflare observe la réponse du crawler.

Bot Preference Sync prend en charge le volet publication de cette boucle. Il traduit les préférences configurées par un client concernant le trafic d’IA en entrées robots.txt correspondantes.

Les outils Bot Management de Cloudflare assurent le volet application. Les clients peuvent utiliser des catégories reconnues et d’autres signaux pour autoriser, bloquer, soumettre à une vérification ou limiter le trafic.

L’évaluation continue se situe entre ces composants. Elle détermine si un bot connu se comporte réellement comme prévu après avoir rencontré les politiques publiées et appliquées.

Le système mesure donc la conformité sur deux échelles temporelles différentes. Robots.txt reflète une politique de site relativement durable, tandis que HTTP 429 communique une pression immédiate.

Un crawler digne de confiance doit gérer les deux. Il doit planifier ses requêtes en tenant compte des restrictions permanentes et adapter son comportement lorsque les conditions actuelles changent.

Perplexity montre pourquoi la responsabilité des bots vérifiés est controversée

Le différend avec Perplexity montre à la fois la valeur des preuves comportementales et le danger de laisser un fournisseur d’infrastructure définir la confiance.

Cloudflare a déclaré avoir commencé son enquête après que des clients ont signalé que Perplexity continuait d’accéder à des sites dont les opérateurs avaient tenté de bloquer les crawlers d’IA.

L’entreprise a créé des domaines de test nouveaux, non indexés et protégés par des restrictions robots.txt. Cloudflare a ensuite soumis à Perplexity des requêtes nécessitant des informations issues de ces domaines.

Selon Cloudflare, Perplexity a récupéré des informations détaillées malgré ces restrictions. Cloudflare a également allégué que l’exploration avait basculé vers une infrastructure non déclarée et des identités de navigateur génériques lorsque les agents déclarés rencontraient des blocages.

Cloudflare a comparé ce comportement à des tests impliquant OpenAI. L’entreprise a déclaré que ChatGPT s’était arrêté lorsque robots.txt interdisait l’accès et qu’il s’était également arrêté lorsqu’il rencontrait un blocage réseau.

Cloudflare a ensuite retiré le bot de Perplexity de sa liste des bots vérifiés. L’entreprise a également ajouté des règles de détection gérées visant à bloquer l’exploration furtive alléguée.

Perplexity a rejeté l’accusation. L’entreprise aurait qualifié le récit de Cloudflare d’argument commercial et soutenu que le trafic identifié par Cloudflare ne provenait pas de Perplexity.

Ce désaccord n’a pas disparu simplement parce que Cloudflare propose désormais une bande de confiance. Toute évaluation comportementale dépend encore de l’attribution, de la conception des mesures et de l’interprétation des règles.

L’attribution est particulièrement difficile lorsqu’un service d’IA utilise plusieurs couches de récupération. Une réponse peut s’appuyer sur un crawler déclaré, un index tiers, un navigateur piloté par l’utilisateur ou une infrastructure exploitée par un autre fournisseur.

Un CDN peut observer les modèles de requêtes sur de nombreux sites web, mais il ne peut pas toujours voir la relation commerciale ou l’intention de l’utilisateur derrière chaque requête.

De même, un opérateur peut considérer différemment une récupération déclenchée par l’utilisateur et une exploration autonome à grande échelle. Un éditeur peut rejeter cette distinction lorsque les deux actions copient la même page restreinte.

La bande de confiance proposée par Cloudflare est mieux adaptée à de tels différends qu’une étiquette binaire. Elle peut représenter des tendances et identifier les comportements ayant influencé l’évaluation.

Toutefois, l’explicabilité doit aller au-delà d’une courte étiquette. Les opérateurs ont besoin de suffisamment de détails pour identifier les requêtes, politiques, périodes et mesures correctives à l’origine d’une note plus basse.

Un processus d’appel sera également important. Une fausse attribution pourrait nuire à un bot légitime en incitant les clients à le bloquer sur de nombreux sites protégés par Cloudflare.

La concentration de l’autorité soulève une autre inquiétude. Cloudflare fournit les outils de préférence, observe le trafic, calcule l’évaluation de confiance et propose le produit d’application des règles.

Cette intégration rend la boucle de responsabilité concrète. Elle donne aussi à Cloudflare une influence considérable sur les services automatisés pouvant accéder à une large part du web.

L’entreprise devrait donc expliquer comment elle traite les cas ambigus, les agents aux usages mixtes, les infrastructures partagées et les interruptions temporaires. Un score dépourvu de garanties procédurales pourrait devenir un système de réputation opaque.

La responsabilité des bots vérifiés exige aussi une transparence symétrique de la part des opérateurs. Les entreprises devraient documenter leurs agents utilisateurs, leurs objectifs, leurs plages IP, leurs clés de signature et leurs réactions aux restrictions des sites.

Des identités distinctes pour la recherche, l’entraînement et la récupération pilotée par l’utilisateur peuvent réduire l’ambiguïté. Elles permettent aux éditeurs d’autoriser une découverte utile sans accorder le même accès à tous les usages automatisés.

Le cas Perplexity reste un avertissement plutôt qu’un verdict universel. Cloudflare a présenté des observations techniques, tandis que Perplexity a contesté la propriété et l’interprétation du trafic.

Ce conflit non résolu explique précisément pourquoi le nouveau système nécessite des preuves transparentes. La mesure continue n’est utile que lorsque les parties concernées peuvent examiner et contester ses conclusions.

La bande de confiance laisse encore des questions cruciales sans réponse

Cloudflare a décrit ce qu’il souhaite mesurer, mais pas suffisamment le fonctionnement des jugements qui en résulteront.

L’entreprise n’a pas publié les règles de pondération relatives aux violations de robots.txt, aux réponses 429 ignorées ou à d’autres signaux futurs. Elle n’a pas non plus défini les limites entre ses bandes de confiance.

Sans ces détails, les clients ne peuvent pas prévoir de manière indépendante comment le comportement d’un crawler se traduira en évaluation. Les opérateurs de bots ne disposent pas non plus d’un objectif technique complet pour se conformer aux exigences.

Cloudflare affirme qu’il évaluera des tendances durables plutôt que des incidents isolés. C’est une protection raisonnable, mais le terme « durable » nécessite une période mesurable.

Un crawler envoyant des millions de requêtes peut générer de nombreuses violations accidentelles à un taux infime. Un crawler plus modeste peut causer un préjudice sérieux avec beaucoup moins de requêtes contre une même origine.

Les nombres bruts déformeraient ces situations. Les pourcentages peuvent également masquer de fortes pointes qui submergent temporairement un site vulnérable.

Un modèle de notation crédible nécessite du contexte. Cela comprend le volume de requêtes, la capacité de l’origine, l’actualité des politiques, les instructions Retry-After, la cohérence des réponses et la preuve que le crawler a reçu le signal.

Robots.txt introduit une autre source d’ambiguïté. Les fichiers peuvent être indisponibles, mal configurés, contradictoires, modifiés pendant une exploration ou altérés par un intermédiaire.

Bot Preference Sync de Cloudflare réduit certaines dérives de configuration en alignant les paramètres du tableau de bord sur les préférences publiées. Il ne peut pas éliminer tous les conflits avec des règles personnalisées ou le comportement de l’origine.

HTTP 429 est tout aussi imparfait. Certains sites web génèrent cette réponse en raison de paramètres de sécurité généraux, d’infrastructures partagées ou d’un trafic mal identifié.

La spécification HTTP n’exige pas que les serveurs utilisent le code 429 en cas de forte charge. Un site peut interrompre les connexions ou employer d’autres contrôles, laissant au crawler des retours moins explicites.

Cloudflare doit donc prévoir des garanties pour éviter de considérer chaque 429 comme une preuve de mauvaise conduite. L’élément déterminant est l’échec répété à s’adapter lorsque le signal est attribuable et compréhensible.

Les seuils choisis par les clients ajoutent une complexité supplémentaire. Deux sites web pourraient traiter différemment la même bande de confiance, ce qui favorise le contrôle local mais complique les attentes des opérateurs.

Cette conception est probablement préférable à une décision universelle d’autorisation ou de blocage. Les éditeurs ont des modèles économiques, des limites d’infrastructure et des attitudes différentes face à la découverte par l’IA.

Un détaillant peut accueillir favorablement les visites fréquentes d’agents soutenant les recommandations de produits. Un éditeur financé par la publicité peut restreindre les crawlers d’entraînement tout en autorisant les systèmes de recherche qui apportent des référencements mesurables.

Cloudflare devrait préserver ces distinctions plutôt que de condenser tous les comportements dans un classement moral mondial unique. Une confiance spécifique à chaque usage offrirait un contrôle plus utile qu’un score composite unique.

L’entreprise doit aussi expliquer le rétablissement. Un opérateur de bot devrait savoir à quelle vitesse un comportement corrigé améliore son évaluation et si les incidents passés s’estompent avec le temps.

Sinon, la responsabilité continue peut devenir une sanction permanente sous un autre nom. Cela contredirait la description de Cloudflare selon laquelle la confiance se construit par des comportements répétés.

Le reporting public sera le test décisif. Cloudflare affirme prévoir de partager les scores via Radar, mais l’annonce ne précise ni leur présentation ni les preuves qui y seront disponibles.

Un système public crédible devrait distinguer les observations des conclusions. Il devrait présenter les périodes pertinentes, les niveaux de confiance, les signaux mesurés et les changements matériels de comportement.

Il devrait aussi signaler les attributions contestées. La visibilité de Cloudflare est étendue, mais elle ne supprime pas l’incertitude.

Ce que les propriétaires de sites web et les opérateurs de bots doivent surveiller ensuite

Le prochain test consistera à voir si Cloudflare transforme son principe de responsabilité en un système d’exploitation transparent et contestable.

Le premier signal à surveiller est la publication publique dans Radar. Cloudflare indique qu’il prévoit de publier des informations de confiance, rendant le score visible au-delà de ses systèmes internes.

La question utile n’est pas de savoir si Radar ajoute un badge supplémentaire. Les lecteurs devraient examiner si chaque bande de confiance inclut des comportements précis, des périodes et suffisamment de preuves pour expliquer les changements.

Un reporting détaillé renforcerait l’affirmation centrale de Cloudflare. Une simple étiquette l’affaiblirait en demandant au marché de faire confiance à l’évaluateur sans voir la logique de notation.

Le deuxième signal est la disponibilité pour les clients. Cloudflare prévoit de permettre aux clients de choisir le seuil déterminant le traitement du trafic des Verified Bots.

Cette publication montrera si la confiance agit comme un champ informatif, une donnée de création de règles ou un mécanisme d’application automatique. Ces options présentent des risques opérationnels différents.

Un champ visible favorise la vérification humaine, mais ajoute du travail. L’application automatisée passe mieux à l’échelle, même si des erreurs pourraient bloquer l’indexation par les moteurs de recherche, la surveillance, les services d’accessibilité ou les agents pilotés par l’utilisateur.

Les clients devraient également observer l’interaction du système avec les listes d’autorisation existantes. Les bots vérifiés ont historiquement bénéficié d’un traitement favorable parce que Cloudflare les reconnaissait déjà.

Un seuil de confiance dynamique peut restreindre ce privilège lorsque le comportement évolue. Il peut aussi compliquer la gestion des politiques si les administrateurs supposent que « vérifié » signifie toujours universellement sûr.

Le troisième signal est la réponse des opérateurs. Les principaux fournisseurs de crawlers peuvent valider le modèle de Cloudflare en adoptant des identités signées, en séparant les usages et en publiant des pratiques de conformité plus claires.

Ils peuvent également contester le modèle avec des preuves techniques. Les différends concernant l’attribution des requêtes, l’interprétation de robots.txt et la gestion des limites de débit révéleront les faiblesses de la méthodologie.

Surveillez la documentation décrivant le comportement de ralentissement après les réponses 429. Surveillez également les identifiants distincts couvrant la recherche, l’entraînement et la récupération pilotée par l’utilisateur.

Ces pratiques renforceraient l’idée qu’une automatisation responsable peut fonctionner au travers de normes web partagées. Une ambiguïté persistante renforcerait les arguments en faveur d’une application réseau plus stricte.

Pour les propriétaires de sites web, la responsabilité continue des bots vérifiés offre un modèle de confiance plus réaliste qu’une vérification permanente. Elle reconnaît que les logiciels évoluent et que des erreurs opérationnelles surviennent après l’approbation.

Elle ne devrait pas remplacer les contrôles directs. Les éditeurs ont toujours besoin de préférences claires, de limites de débit adaptées, de journaux de trafic et de règles d’application alignées sur leurs objectifs commerciaux.

Pour les développeurs de bots, le message est tout aussi direct. L’identité cryptographique peut apporter une reconnaissance, mais le comportement continu détermine si cette reconnaissance reste utile.

Les équipes développant des agents devraient traiter les politiques d’accès au web comme des exigences de production. Elles devraient tester l’analyse de robots.txt, respecter les restrictions d’accès, mettre en œuvre un ralentissement adaptatif et surveiller les changements entre les déploiements.

Les développeurs ont également besoin d’archives durables expliquant pourquoi un agent a accédé à une ressource. Cela devient essentiel lorsque les plateformes, les éditeurs et les intermédiaires ne s’accordent pas sur l’objectif d’une requête.

Les travailleurs du savoir font face à une question connexe. Les réponses générées par les agents dépendent de plus en plus de systèmes de récupération opérant hors de la vue de l’utilisateur.

Une meilleure couche de responsabilité peut aider les utilisateurs à comprendre si ces systèmes accèdent aux sources de manière transparente. Elle peut aussi révéler lorsque la commodité repose sur des comportements que les éditeurs ont explicitement rejetés.

Le web a désormais besoin de davantage que l’identification des bots. Il lui faut un moyen de relier l’identité, l’objectif déclaré, le comportement observé et des conséquences proportionnées.

Cloudflare a proposé un tel système, mais sa légitimité dépendra des preuves et du respect d’une procédure régulière. L’entreprise doit démontrer que les bandes de confiance sont exactes, compréhensibles et ouvertes à la correction.

Au cours des prochains mois, surveillez les scores publics, les contrôles destinés aux clients et les réponses des opérateurs de crawlers. Ensemble, ils montreront si la responsabilité continue devient une norme partagée ou une nouvelle couche privée de contrôle d’accès.

Les propriétaires de sites web devraient comparer les futures évaluations de Cloudflare avec leurs propres journaux avant d’automatiser l’application des règles. Les opérateurs de bots devraient dès maintenant auditer leur réponse à robots.txt comme à HTTP 429.

La question centrale n’est plus de savoir si un bot peut prouver son identité. Elle est de savoir si cette identité reste responsable après des milliers de requêtes, des politiques changeantes et d’inévitables mises à jour logicielles.