Ce que Web Bot Auth implique lorsque vous bloquez déjà les crawlers IA

En résumé : Web Bot Auth applique la RFC 9421 (HTTP Message Signatures) au trafic des crawlers. Les bots signent leurs requêtes avec une clé privée, publient les clés publiques dans un répertoire .well-known, et vous laissez le serveur vérifier la signature au lieu de faire confiance à l’en-tête User-Agent. Google publie déjà ses clés sous agent.bot.goog pour son agent de navigation IA ; Googlebot, lui, n’est pas encore signé. Le travail d’ici 2026 consiste à ajouter une voie de vérification par signature sans supprimer la résolution DNS inversée, car la majorité du trafic se réclamant de Google reste non signé et le restera au moins un an.

Un opérateur avec qui je travaille avait rédigé une règle WAF Cloudflare en 2024 : bloquer tout User-Agent contenant GPTBot, ClaudeBot ou PerplexityBot, et autoriser tout UA contenant Googlebot. La règle a tenu deux ans. Puis, au printemps 2026, un nouvel UA est apparu dans les logs : Google-Agent, accompagné de trois en-têtes inconnus : Signature-Agent, Signature-Input et Signature. La règle de 2024 n’a aucune opinion sur ces en-têtes ; elle ne lit que l’UA. Cet écart entre des règles écrites pour l’ancien modèle de vérification et un trafic arrivant sous le nouveau est précisément le sujet de cet article. Pas « qu’est-ce que robots.txt », ni « faut-il bloquer les crawlers IA ». Ici, on parle d’intégration pour les opérateurs qui maintiennent déjà un jeu de règles anti-bot et veulent comprendre ce que Web Bot Auth change.

Ce qu’est réellement Web Bot Auth

Web Bot Auth est un profil orienté bot de la RFC 9421 sur les signatures de messages HTTP. Le bot signe chaque requête sortante avec une clé privée. Le site récupère la clé publique du bot à l’URL .well-known/http-message-signatures-directory sur un domaine contrôlé par le bot. Le site vérifie ensuite que la signature de la requête entrante provient bien de la clé privée correspondante. Si c’est le cas, l’origine de la requête est attestée cryptographiquement ; sinon, la requête est falsifiée.

Trois nouveaux en-têtes réalisent le travail. Signature-Agent pointe vers le répertoire de clés du bot. Signature-Input liste les éléments signés ainsi que les métadonnées : keyid, dates created et expires, algorithme et la chaîne littérale tag="web-bot-auth" qui marque qu’il s’agit d’une signature de bot (et non d’un autre usage de la RFC 9421). Signature transporte les octets cryptographiques.

« Ce document décrit un mécanisme pour créer, encoder et vérifier des signatures numériques ou des codes d’authentification de message sur des composants d’un message HTTP. » — A. Backman, J. Richer, M. Sporny, RFC 9421 (HTTP Message Signatures, abstract)

Le profil bot ajouté au-dessus de la RFC fait toute la différence : sans lui, on ne parle que de signatures HTTP. Le draft IETF draft-meunier-web-bot-auth-architecture précise les conventions côté bot : la présence du tag="web-bot-auth", la forme de l’URL .well-known, les composants couverts recommandés (au minimum @authority et signature-agent) et l’exigence de mettre le répertoire en cache selon son propre Cache-Control. Rien de cela n’est dans la RFC 9421 elle-même ; la RFC fournit l’algèbre, Web Bot Auth fournit le cas d’usage.

Pourquoi la vérification UA + IP ne suffit plus

La pile de vérification comporte trois niveaux, chacun avec son point de rupture : User-Agent est du texte, n’importe qui peut le définir. Le DNS inversé fonctionne pour Googlebot mais reste bancal pour les agents récents routés via une infrastructure générique. Les listes d’IP autorisées sont fragiles : les plages d’egress cloud changent sans préavis.

Johannes Ullrich, du SANS Internet Storm Center, résume brutalement le problème de spoof UA :

« Les utilisateurs ont compris depuis longtemps que définir son user agent sur “Googlebot” permet de contourner certains paywalls. » — Johannes Ullrich, SANS Internet Storm Center, septembre 2025

Le côté liste d’IP pose un problème différent mais lié. Thibault Meunier et Mari Galicer de Cloudflare, parrains du projet Web Bot Auth à l’IETF, l’ont formulé ainsi en mai 2025 : « les connexions du service de crawl peuvent être partagées par plusieurs utilisateurs, comme avec les proxys de confidentialité ou les VPN ; ces plages, souvent gérées par des fournisseurs cloud, évoluent dans le temps. » Une liste valide le lundi peut être caduque le vendredi.

L’arrivée du trafic agent aggrave l’ancienne pile. Lorsqu’un crawler agit au nom d’un utilisateur dans une session de chat, le profil source se fragmente. Cloudflare l’a dit sans détour : « Les bots ne sont plus uniquement dirigés par leurs propriétaires, mais aussi par des utilisateurs finaux qui agissent en leur nom. »

La vérification cryptographique est la seule voie qui résiste aux trois failles héritées : elle se moque de l’IP source, ne fait pas confiance à l’UA et n’a pas besoin de lookup DNS inversé. Elle ne regarde que la clé.

À quoi ressemble réellement une requête Googlebot signée

Une requête signée de l’agent Google suit la forme décrite dans la documentation Cloudflare et le guide développeur de Google. Format approximatif, keyid abrégé :

GET /article/example HTTP/1.1
Host: yoursite.com
User-Agent: Mozilla/5.0 (compatible; Google-Agent/1.0; ...)
Signature-Agent: g="https://agent.bot.goog"
Signature-Input: sig=("@authority" "signature-agent")
 ;created=1735689600;keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U"
 ;alg="ed25519";expires=1735693200;tag="web-bot-auth"
Signature: sig=:MEQCIBmw...truncated...:

Lisez de gauche à droite. Signature-Agent indique où récupérer la clé publique ; le littéral g="https://agent.bot.goog" mène à https://agent.bot.goog/.well-known/http-message-signatures-directory. Signature-Input décrit ce qui est attesté : ici @authority (le host) et l’en-tête signature-agent, signé à created et valable jusqu’à expires. keyid est l’empreinte JWK qui choisit une clé précise dans le répertoire. Signature porte les octets de signature ed25519.

Sémantique de chaque paramètre, sous forme de tableau, car c’est là que les opérateurs se trompent au premier coup d’œil :

Une mise en garde que Google donne clairement : « Tous les user agents Google n’utilisent pas Web Bot Auth. » En mai 2026, l’UA qui signe systématiquement est Google-Agent, l’agent IA de navigation. Googlebot, le crawler d’indexation qui génère l’essentiel de votre trafic organique, n’est toujours pas signé. Ajustez vos règles en conséquence.

Le flux de vérification, de bout en bout

Le chemin de vérification comporte quatre étapes, toutes peu coûteuses. Les pièces mobiles sont le cache de répertoire et la bibliothèque crypto, pas le calcul.

Étape 1 : la requête arrive. Cherchez un en-tête Signature-Agent. S’il manque, la requête est non signée ; on retombe alors sur la pile héritée (DNS inversé, UA, IP). La plupart des requêtes en 2026 sont encore dans ce cas.

Étape 2 : analysez Signature-Input. Extrayez keyid, created, expires, alg et tag. Rejetez si tag n’est pas littéralement web-bot-auth ou si l’horloge dépasse expires. Tout cela avant même de toucher à la clé publique.

Étape 3 : récupérez le répertoire de clés publiques à l’URL donnée par Signature-Agent. Respectez son en-tête Cache-Control ; Google en fixe un. Mettez le répertoire en cache (mémoire ou Redis), rafraîchissez à expiration, supprimez les clés disparues (rotation). Sortez la clé dont l’empreinte JWK correspond à keyid.

Étape 4 : vérifiez la signature sur les composants listés dans Signature-Input. Si ça passe, la requête est attestée ; sinon, traitez-la comme falsifiée.

Le cache de répertoire est souvent mal géré. Prenez Cache-Control au sérieux. Trop long : risque d’accepter une clé révoquée. Trop court : latence et surcharge sur le répertoire. En cas d’échec de fetch alors que le cache est expiré, retombez sur la voie non signée ; ne bloquez pas sur un raté transitoire.

Ce qui change pour vos règles de blocage des bots IA

La question clé pour l’opérateur : vos règles existent, le protocole change. Que faire ?

Bonne nouvelle : les règles qui bloquent « UA contient GPTBot/ClaudeBot/PerplexityBot » restent valides. La requête arrive toujours avec un UA identifiable, et un GPTBot spoofé prétendait déjà être le bot que vous vouliez bloquer.

Moins bonne nouvelle : les règles qui autorisent « UA contient Googlebot » sont désormais insuffisantes. Un spoofer avec UA Googlebot passe encore. Le correctif n’est pas de tout réécrire (la part signée est trop faible), mais d’ajouter une voie parallèle : vérifier la signature sur le trafic Google signé, et continuer à traiter le non signé via DNS inversé. L’équipe verified-bots de Cloudflare résume l’écart :

« Les méthodes actuelles reposent sur la combinaison plage IP (partagée ou mouvante) + user agent (facilement falsifiable). Elles ont des limites. » — Équipe verified-bots Cloudflare, juillet 2025

La bonne image mentale : deux piles. Une pour le trafic signé (vérifie la signature, contrôle keyid, expires, etc.), l’autre pour le non signé (DNS inversé + UA + IP comme aujourd’hui). Ne supprimez pas les règles héritées ; à mi-2026, la majorité du trafic Google réel passe encore par elles.

Vérifier les signatures à l’origine (hors Cloudflare)

Derrière Cloudflare, c’est simple : le CDN valide les signatures et expose le résultat via cf.verified_bot_category dans le WAF. Votre règle devient « si cf.verified_bot_category correspond, alors… », et la crypto est déléguée.

Sans CDN vérifiant, vous faites le boulot à l’origine. Une petite couche middleware interceptant les requêtes avec Signature-Agent, récupérant le répertoire .well-known (mise en cache), vérifiant selon la RFC 9421, puis plaçant un en-tête interne X-Verified-Bot que vos règles lisent.

L’équipe recherche Cloudflare a open-sourcé ces briques : cloudflareresearch/web-bot-auth. Le crate Rust et le package npm TypeScript (web-bot-auth) contiennent la logique ; le dépôt fournit aussi un plugin Caddy et des Workers Cloudflare. Rien n’est audité, mais la surface est petite — mieux que réimplémenter la RFC vous-même.

Conseil pragmatique : sur Cloudflare, utilisez la voie edge. Hors Cloudflare, installez le middleware, pointez-le vers les agents pertinents (Google aujourd’hui, d’autres demain) et lisez son en-tête de confiance. Dans tous les cas, ne mettez pas la vérification de signature dans votre code métier ; gardez-la en frontal, auditable et remplaçable.

Le fallback DNS inversé ne disparaît pas

Si j’insiste sur « ne supprimez pas les règles héritées », c’est que la part signée reste faible. En mai 2026, le crawler d’indexation Googlebot n’est pas signé ; seul l’agent IA Google-Agent l’est. Pour la plupart des sites, l’IA-navigateur représente un chiffre modeste du trafic Google. L’indexation, qui conditionne votre SEO, est non signée aujourd’hui et probablement jusqu’en 2027.

Google le dit explicitement. La doc qui présente Web Bot Auth recommande toujours de « continuer à s’appuyer sur les adresses IP, le DNS inversé et les User-Agents ». Ce n’est pas une précaution oratoire, c’est le modèle d’exploitation. Web Bot Auth est une voie ; la pile héritée en est une autre. Elles coexistent, et en 2026 la pile héritée porte encore plus de charge.

Cadence d’audit : chaque trimestre, échantillonnez le trafic se réclamant de Google, séparez signé/non signé, calculez la part signée. À 30-40 %, la vérif par signature devient significative. À 70 %, la règle « UA Googlebot autorisé » mérite un vrai durcissement ; les spoofers seront visibles dans ce reliquat. Avant ces seuils, gardez les deux voies et considérez la crypto comme additive.

Anti-pattern à éviter : ne bloquez pas aujourd’hui le trafic Googlebot non signé. Vous vous désindexeriez en un cycle de crawl.

Ce qu’il faut vraiment faire ce trimestre

Checklist en quatre points, sans dépendre d’un fournisseur.

Premièrement, inventoriez vos règles bot actuelles. Étiquetez-les : UA, DNS inversé, IP, signature. La plupart des audits révèlent doublons ou règles périmées. Nettoyez avant d’ajouter.

Deuxièmement, ajoutez une voie de vérification par signature. Sur Cloudflare, activez la validation edge verified-bots et créez une règle sur cf.verified_bot_category. À l’origine, installez le middleware WBA, pointez-le vers agent.bot.goog (et autres répertoires utiles), exposez un en-tête de confiance lisible par vos règles.

Troisièmement, conservez la voie DNS inversé pour la grande majorité de trafic Google non signé. Ne la durcissez pas, ne la remplacez pas. Faites-la tourner en parallèle.

Quatrièmement, planifiez l’audit trimestriel : part signée du trafic Google, part signée du trafic agents IA, pourcentage de spoofers captés par la signature mais manqués par les règles héritées. Les chiffres bougent lentement en 2026, plus vite en 2027. Vos règles doivent évoluer au même rythme.

Si votre équipe gère aussi la politique plus large des crawlers IA, le playbook des crawlers IA et l’article sur la désactivation du blocage Cloudflare IA complètent la partie autorisation. Celui-ci traite de l’identité.

Ce que cela NE résout PAS

Web Bot Auth concerne l’identité, pas l’autorisation. La signature atteste que la requête vient d’un bot spécifique. Elle ne dit rien sur son droit de lire l’URL. Un Google-Agent vérifié peut toujours aspirer votre contenu payant si vos règles le laissent passer. La signature apporte la confiance sur l’origine ; la politique reste la vôtre.

Elle ne se prononce pas non plus sur robots.txt. Un bot signé qui l’ignore reste hors-la-loi ; signer n’offre aucun accès supplémentaire. Si vous voulez que l’agent IA saute votre section payante, indiquez-le via robots et faites-le respecter dans vos règles.

Et elle ne décide pas du routage entre recherche IA et recherche traditionnelle. Web Bot Auth dit « c’est vraiment Google-Agent ». Décider si Google-Agent reçoit le même contenu que Googlebot ou non relève de votre stratégie. L’article sur l’optimisation pour Perplexity, ChatGPT Search et Google AI Mode traite de ce routage.

Bilan honnête : c’est un rail dans une pile à trois rails. Signature pour l’identité, DNS inversé pour l’héritage, robots pour l’autorisation. Le nouveau rail renforce le premier. Les opérateurs qui réussissent en 2026 traitent les trois comme essentiels.

La cadence d’audit à mesure que l’adoption progresse

L’indicateur clé pour 2026-2027 : la part signée du trafic se réclamant de Google. Aujourd’hui, c’est un chiffre à un seul digit. À 30-40 %, la vérif par signature pèse dans vos décisions ; à 70 %, la règle UA non signé mérite revue.

Refaites l’inventaire tous les six mois et relisez la doc crawler de Google ; elle évolue. La forme du répertoire et la liste des composants couverts sont les points les plus susceptibles de changer. Deux fois par an suffit pour rester à jour.

Pour le contexte Googlebot de base, notre explainer sur Googlebot est le bon départ. Pour le trafic agent, comment bâtir un site agent-friendly détaille l’intégration.

FAQ

Googlebot signe-t-il déjà ses requêtes ? Pas à mi-2026. Le déploiement Web Bot Auth actuel concerne Google-Agent. Googlebot, le crawler d’indexation, s’authentifie toujours via DNS inversé et plages IP documentées. Traitez-les séparément.

Web Bot Auth remplace-t-il robots.txt ? Non. Web Bot Auth atteste « cette requête vient bien de Google ». Robots.txt déclare « cette URL est ou non accessible ». Les deux restent valides, et un bot signé qui ignore robots reste en faute.

Quel algorithme de signature est utilisé ? La RFC 9421 en prévoit plusieurs. Les exemples Cloudflare et le répertoire Google utilisent ed25519 (EdDSA/Curve25519). Votre vérif doit donc supporter ed25519 ; c’est un appel de lib dans la plupart des langages (Go, Rust, Node, Python…).

Que se passe-t-il si le répertoire de clés Google est injoignable ? Vous le mettez en cache selon Cache-Control. Si le cache est frais, la vérif continue. Si le cache est expiré et que le fetch échoue, retombez sur la voie non signée (DNS, UA, IP). Ne bloquez pas sur un raté transitoire, sinon vous risquez la désindexation.

Dois-je abandonner la vérif DNS inversé pour Googlebot ? Pas encore, probablement pas en 2026. La part signée est trop faible. Le DNS inversé reste votre vraie défense contre les spoofers se réclamant de Googlebot, puisque Googlebot n’est pas signé. Réévaluez trimestriellement. Le bon moment pour durcir la voie non signée, c’est quand elle sera minoritaire dans votre trafic réel, pas avant.