Pendant vingt ans, l'identité d'un crawler a été une affirmation. On écrit User-Agent: Googlebot dans un en-tête et le serveur décide s'il y croit. Comme n'importe qui peut y écrire n'importe quoi, les opérateurs ont appris à vérifier l'affirmation par des indices : une résolution DNS inverse sur l'IP qui se connecte tombe-t-elle dans le bon domaine, ce domaine se résout-il à nouveau vers la même adresse, l'IP est-elle dans une plage publiée.
Cette vérification porte toute l'économie de qui a le droit de crawler. C'est aussi la raison pour laquelle la détection de bots est devenue du fingerprinting, du scoring comportemental et des pages de challenge, car un indice ne vaut que la volonté d'un attaquant de louer la bonne adresse.
En 2026, tout cela est remplacé. Non par un meilleur fingerprinting, mais par de la cryptographie asymétrique : un crawler signe ses requêtes avec une clé privée, publie la moitié publique à une URL well-known, et le serveur vérifie une signature au lieu de peser un indice. L'affirmation devient une preuve.
Ce qui est intéressant n'est pas la cryptographie, qui est ordinaire. C'est ce qui s'est passé le jour de sa mise en production.
- Web Bot Auth signe les requêtes en Ed25519 et publie les clés de vérification dans un annuaire JWKS well-known, de sorte que l'identité est vérifiée plutôt que déduite.
- Cloudflare l'a intégré à son programme Verified Bots le 1er juillet 2025, le jour même où il a commencé à bloquer les crawlers d'IA par défaut et ouvert une bêta de pay-per-crawl.
- L'identité est devenue prouvable et l'autorisation est devenue vendable le même jour. Ce n'est pas une coïncidence, c'est le point.
- Au 18 août 2026 le protocole reste un Internet-Draft individuel, non adopté par un groupe de travail, pendant que les gardiens le vérifient en production.
- L'accès se scinde en une voie signée et une voie non signée, et aucun travail de fingerprinting ne procure une clé.
Ce qu'est réellement le mécanisme
Web Bot Auth est une fine couche au-dessus de RFC 9421, la norme HTTP Message Signatures. Le bot détient une paire de clés Ed25519. Chaque requête porte trois en-têtes : Signature-Input décrit ce qui a été couvert, Signature porte les octets, et Signature-Agent pointe vers l'emplacement HTTPS où vivent les clés publiques.
La signature couvre des composants de la requête plutôt que le corps entier. Le draft impose au signataire d'inclure soit @authority soit @target-uri, si bien qu'une signature capturée ne peut être rejouée contre un autre hôte ou un autre chemin.
GET /article/12345 HTTP/1.1 Host: example.com Signature-Agent: "https://crawler.example/.well-known/http-message-signatures-directory" Signature-Input: sig=("@authority" "signature-agent"); created=1740000000; expires=1740086400; keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U"; tag="web-bot-auth" Signature: sig=:TUAfxGCoruBcOaEBRTdd6DcH0GJPd1v/1Vg1nCLmYFI=:
Quatre détails de ce bloc portent toute la conception.
Le keyid n'est pas un nom, c'est une empreinte. C'est l'empreinte SHA-256 de la JSON Web Key, encodée en base64url. On ne peut pas revendiquer l'identifiant d'un autre, parce que l'identifiant dérive de la clé dont il faut prouver la possession.
Le tag vaut web-bot-auth. Les signatures sont cantonnées à un usage : une signature émise pour un protocole ne peut pas être réutilisée pour satisfaire un autre vérificateur.
L'expiration est courte. Le draft recommande au plus 24 heures, ce qui borne la durée pendant laquelle une signature capturée vaut quelque chose.
L'annuaire est découvrable. Les clés sont publiées en JWKS à /.well-known/http-message-signatures-directory, de sorte qu'un vérificateur les récupère et les met en cache sans aucune relation préalable avec le crawler.
Le jour où l'identité et l'autorisation sont arrivées ensemble
Le 1er juillet 2025, Cloudflare a ajouté les message signatures à son programme Verified Bots, publié des bibliothèques en Rust et TypeScript, et indiqué aux opérateurs que les demandes accompagnées de signatures bien formées seraient approuvées plus vite.
Le même jour, il a commencé à bloquer les crawlers d'IA par défaut pour les nouveaux domaines, et a ouvert une bêta privée de pay-per-crawl, où un éditeur fixe un prix et où un crawler le paie ou n'obtient pas la page. Cloudflare se tient devant environ un cinquième du web : un défaut y équivaut presque à une règle.
Lisez ces deux annonces comme une seule et la forme saute aux yeux. Facturer l'accès suppose de savoir qui demande, et savoir qui demande suppose une identité infalsifiable. Le pay-per-crawl est impossible au-dessus de User-Agent. Il devient possible à l'instant où l'identité est une signature.
Mis en production avant d'être normalisé
Voici la partie sur laquelle il vaut la peine de s'arrêter. Le draft de protocole, draft-meunier-webbotauth-httpsig-protocol-02, est daté du 18 août 2026 et reste un Internet-Draft individuel . Il n'est pas adopté par un groupe de travail, et il porte la mention habituelle qu'un draft est un travail en cours.
La documentation de Cloudflare est franche à ce sujet : elle dit que l'implémentation s'appuie sur des drafts IETF et nomme les versions précises qu'elle suit. Pendant ce temps la vérification tourne en production, et le même mécanisme est contrôlé par d'autres grands opérateurs.
Cet ordre n'a rien d'inhabituel sur le web, et ce n'est pas un scandale. Il a néanmoins des conséquences à anticiper. Une spécification implémentée pendant qu'elle bouge signifie que les détails bougent aussi : la forme des en-têtes, les chemins d'annuaire et les valeurs de tag ont déjà changé d'une révision à l'autre. Bâtir dessus, c'est suivre une cible mobile entretenue surtout par les parties qui profitent le plus du résultat.
Ce que cela change si vous crawlez
La course aux armements gagne une seconde voie, pas un remplacement
Les agents signés ne suppriment rien du fingerprinting. La machinerie décrite dans notre analyse anti-bot ne disparaît pas : empreintes TLS, ordre des en-têtes et scoring comportemental continuent de tourner et décident toujours du sort du trafic non signé. Ce qui change, c'est qu'un agent signé et enregistré peut sauter l'essentiel, parce que la question coûteuse "est-ce bien celui qu'il prétend être" a déjà reçu une réponse bon marché.
La population se scinde donc. Les agents signés obtiennent une voie rapide. Tous les autres rencontrent le même mur croissant qu'avant, avec moins d'attention de l'opérateur consacrée à les distinguer les uns des autres.
L'identité n'est pas une autorisation
Une signature vérifiée prouve qui demande. Elle ne dit rien sur le droit d'obtenir la page. Ce sont deux décisions distinctes, et les confondre est le contresens le plus courant sur cette technologie. Un éditeur peut vérifier parfaitement votre identité et néanmoins vous refuser, vous facturer ou vous servir une version réduite. Web Bot Auth rend le refus précis plutôt que probabiliste.
Une clé est une entrée d'allowlist, et les allowlists ont des propriétaires
En pratique, être vérifié signifie être reconnu par un gardien, et les opérateurs qui tiennent ces programmes sont ceux-là mêmes qui décident déjà de ce qui atteint une origine. Le parcours d'enregistrement passe par le programme de l'opérateur, et l'approbation lui appartient. Cela déplace sensiblement le pouvoir de décider quel trafic automatisé est légitime, en l'éloignant de l'éditeur dont le contenu est en jeu et en le rapprochant de l'infrastructure placée devant lui.
Elle ne prouve ni l'intention, ni le respect d'une licence, ni la bonne conduite. Elle ne rend pas un crawler poli et n'établit aucun droit d'accès. Elle prouve que le détenteur d'une clé privée précise a émis une requête précise avant une échéance. Toutes les autres questions qui agitent le secteur se règlent encore dans les politiques, les contrats et les tribunaux, et une signature clarifie seulement avec qui l'on discute.
La position pratique pour les prochaines années
Si vous exploitez un grand crawler nommé dont l'identité publique compte, se faire signer est simple et vaut le coup : générer une clé, publier un annuaire, s'enregistrer auprès des programmes qui comptent pour vos cibles.
Si vous collectez des données publiques à une échelle ordinaire sans être un nom connu, la lecture honnête est que la voie signée ne vous est pas ouverte en pratique, et que la voie non signée se rétrécit. Entre ces deux faits, le coût d'obtenir une page de façon fiable s'éloigne du travail astucieux côté client et se rapproche d'une infrastructure qui résout déjà l'accès.
L'accès comme problème résolu plutôt que comme projet de recherche : IP résidentielles rotatives, rendu par navigateur réel et gestion des challenges à l'intérieur du fetch, avec une réponse propre en retour. Les requêtes en échec ne sont pas facturées, une cible qui se durcit vous coûte donc de la latence et non de la facture. Démarrez gratuitement avec 1 000 requêtes, sans carte.
Conclusion
Le web se dote d'une couche d'identité pour le trafic automatisé, et elle est arrivée de la manière ordinaire : un draft, l'implémentation d'un fournisseur, et un modèle économique qui en avait besoin. La cryptographie est banale. La conséquence ne l'est pas.
Pendant deux décennies, la question posée à l'edge était "est-ce que ça ressemble à un bot ?". Elle devient "ce bot est-il celui qu'il prétend être, et avons-nous un accord ?". C'est une meilleure question, posée honnêtement. C'est aussi une question qui n'a de bonne réponse que si vous êtes déjà quelqu'un, et c'est précisément ce dont le secteur n'a pas fini de débattre.
Surveillez le draft plutôt que la couverture médiatique. Quand un groupe de travail l'adoptera, quand un second vérificateur indépendant l'implémentera, et quand le premier éditeur fixera un prix qu'un crawler paiera vraiment, la forme des prochaines années se lira dans ces trois événements.
Foire aux questions
Web Bot Auth est-il une norme internet approuvée ?
Pas encore. Au 18 août 2026 le document de protocole est draft-meunier-webbotauth-httpsig-protocol-02, un Internet-Draft individuel et non adopté par un groupe de travail, et les Internet-Drafts sont explicitement des travaux en cours. Le format de signature sous-jacent, RFC 9421, est une norme publiée. La couche au-dessus, qui dit ce que les bots doivent signer et comment les vérificateurs découvrent les clés, bouge encore.
En quoi est-ce différent d'une vérification DNS inverse ?
La vérification DNS inverse demande si l'adresse qui se connecte appartient à l'organisation que le crawler revendique. C'est une inférence à partir de la propriété du réseau : elle casse dès que les adresses sont louées, déléguées ou réattribuées, et elle ne voyage pas d'un réseau à l'autre. Une signature est une preuve sur la requête elle-même : seul le détenteur de la clé privée a pu la produire, depuis n'importe quelle adresse.
Une signature permet-elle à un crawler de contourner les systèmes anti-bot ?
Seulement au sens où elle répond à une question que ces systèmes existent pour deviner. Un agent vérifié fait toujours face à la politique de l'opérateur, qui peut autoriser, limiter, facturer ou refuser. Signer lève l'ambiguïté sur l'identité, pas le droit de l'opérateur à dire non.
Une signature peut-elle être rejouée ?
Pas utilement, si elle est construite correctement. Le signataire doit couvrir @authority ou @target-uri, si bien qu'une signature capturée ne se transfère pas vers un autre hôte, et le draft recommande une expiration d'au plus 24 heures, ce qui borne la fenêtre où un rejeu vaudrait la peine.
Qu'arrive-t-il aux crawlers non signés ?
La même chose qu'aujourd'hui, avec moins de patience. Le trafic non signé continue de rencontrer fingerprinting, scoring comportemental et challenges, et à mesure que le trafic automatisé légitime rejoint la voie signée, la population non signée paraît plus uniformément suspecte aux systèmes qui la jugent.
Faut-il l'implémenter dès maintenant ?
Si vous exploitez un crawler nommé dont l'identité fait partie du produit, oui : la mécanique tient dans une paire de clés et un document JSON, et être en avance coûte peu. Si vous consommez des données publiques à une échelle ordinaire, implémenter le côté client n'apporte rien en soi, car la valeur est d'être reconnu par un programme, pas de produire une signature valide. Suivez le draft et regardez quels vérificateurs se lancent.
Crawlez n'importe quel site à grande échelle, sans combattre l'infrastructure.
Crawlbase gère les proxies, les empreintes et les CAPTCHA afin que votre équipe livre des pipelines de données au lieu de maintenir la plomberie de crawl. 1 000 requêtes gratuites, sans carte requise.