55 opérateurs de robots sur 150 signent déjà, les serveurs apprennent à lire

Depuis vingt ans, un site qui veut trier son trafic automatisé s'appuie sur deux indices : le user-agent, qu'un script copie en une ligne, et l'adresse IP, que les VPN, les proxies de confidentialité et les plages cloud partagées rendent de moins en moins fiable. Le 1er septembre 2026, le groupe de travail webbotauth de l'IETF (Internet Engineering Task Force) a publié la version -00 de son profil de signatures HTTP pour robots. Le crawler signe sa requête, le serveur vérifie la signature.

Le mécanisme repose sur la RFC 9421 (HTTP Message Signatures). L'agent signe chaque requête avec une clé privée et publie la clé publique dans un annuaire accessible à une adresse fixe, /.well-known/http-message-signatures-directory. Un en-tête Signature-Agent désigne cet annuaire, et la signature couvre cet en-tête lui aussi. Le serveur récupère les clés publiques, vérifie, et sait quelle clé le robot détient.

Une signature, pas un laissez-passer

Cloudflare, qui pousse le sujet, rappelle dans son billet de 2025 que le user-agent est falsifiable par conception et que les plages IP changent et se partagent entre plusieurs clients. Avec une signature, le serveur n'a plus à croire une déclaration : il contrôle la détention d'une clé.

Une confusion revient vite : une signature n'est pas un droit d'accès. Elle atteste une identité technique, rien de plus. Un agent parfaitement signé peut aspirer un catalogue entier en dix minutes, et le profil ne dit rien de ce qu'un site doit lui accorder.

Un calendrier serré, des implémentations déjà là

Le groupe a été créé en juin 2025 et sa charte approuvée le 23 octobre 2025. Les jalons « standards track » étaient fixés à avril 2026, le document opérationnel attendu pour août 2026. La version -00 du profil est sortie le 1er septembre 2026, et en octobre le groupe a envoyé ses notifications pour l'IETF 127.

Côté implémentations, Cloudflare documente la vérification et un en-tête Signature-Agent conforme. AWS WAF (Web Application Firewall) Bot Control authentifie ce type de trafic. Un vérificateur pour nginx a été ajouté à mod_pagespeed, avec une réserve de taille : il est expérimental et réglé par défaut sur l'observation.

55 annuaires pour 150 opérateurs

Un relevé publié le 19 octobre 2026 a interrogé 150 opérateurs de crawlers IA, tirés de deux listes publiques : ai.robots.txt et les catégories « AI crawler », « AI assistant » et « AI search » de Cloudflare Radar. 55 d'entre eux servent un annuaire de clés. Toutes les clés observées étaient en Ed25519, à une exception près.

Ce 55 sur 150 donne un ordre de grandeur. La liste Radar, qui documente un champ « Signature Agent », compte mécaniquement plus de signataires (50 sur 89) que la liste communautaire (15 sur 94). La répartition renseigne davantage que le total : ce sont surtout les agents qui agissent pour un utilisateur, comme ChatGPT agent ou Google-Agent, qui publient des clés. Les gros robots d'entraînement et de recherche en publient souvent aucune.

Ce que les sites peuvent faire dès maintenant

Premier réflexe : regarder dans les journaux du serveur quels en-têtes Signature-Agent arrivent déjà. Quatre points ensuite.

• Les données manquent côté CMS et hébergeurs indépendants : aucune des sources consultées ne recense de prise en charge native dans WordPress ou Drupal, ni chez un hébergeur comme OVHcloud ou o2switch. Le contrôle passe pour l'instant par un grand réseau (Cloudflare, AWS) ou par un reverse proxy.
• Derrière Cloudflare, le site reçoit souvent un verdict plutôt que la signature. Une règle par agent, du genre « laisser passer ChatGPT agent sur les fiches produit, refuser un crawler d'entraînement », devient alors difficile à écrire.
• En auto-hébergement, le vérificateur nginx de mod_pagespeed ne fonctionne qu'en observation : on journalise d'abord, on bloque ensuite.
• Un en-tête Signature-Agent non vérifié ne doit porter aucune politique, et le brouillon interdit de suivre automatiquement les redirections vers l'annuaire. Ces deux règles piègent les implémentations pressées.

Reste un scénario commercial à surveiller : un grand réseau vérifie la signature à la place du site, puis arbitre l'accès, y compris en le facturant à l'éditeur ou à l'agent. C'est le seul péage envisageable ici, et rien dans le standard ne l'impose. Un site qui ne lit pas ces en-têtes ne peut ni exclure un agent précis ni autoriser le bon : il bloque tout ou laisse tout passer.

Ce qui peut gripper la dynamique

Les profils se multiplient, jusqu'aux paiements agentiques, et divergent déjà sur la syntaxe d'un même en-tête ou sur la durée de validité d'une signature. La rotation des clés et la révocation restent ouvertes, tout comme la protection contre le rejeu. Il y a aussi un angle mort politique : identifier un agent revient souvent à identifier la personne derrière lui.

Si seuls deux ou trois grands réseaux savent vérifier, Web Bot Auth fonctionnera comme un standard sous contrôle privé. Si les hébergeurs indépendants, les CMS et les frameworks transmettent l'identité vérifiée à l'origine, le site pourra de nouveau choisir lui-même. Prochaines échéances vérifiables : l'IETF 127, pour laquelle le groupe a envoyé ses notifications en octobre, et la révision de draft-ietf-webbotauth-httpsig-protocol qui fera suite à la version -00 du 1er septembre 2026.