Pendant toute l'histoire du web, la personne à l'autre bout d'une requête était une personne. Cette hypothèse est désormais fausse plus souvent qu'elle n'est vraie.
Les mesures de Cloudflare en 2026 situent les requêtes automatisées à environ 57,5% du trafic web HTML, contre 42,5% pour les humains — le premier croisement jamais enregistré par l'entreprise. Son PDG Matthew Prince a souligné que ce cap avait été franchi avec près de dix-huit mois d'avance sur leurs propres projections. Le moteur n'est pas la vieille histoire des scrapers et des spam bots. C'est l'IA agentique : des programmes autonomes qui naviguent pour le compte d'assistants, où une seule question d'utilisateur peut se traduire par des centaines de récupérations de pages.
La plupart des équipes techniques n'ont pas ajusté leur architecture. Leurs analytics supposent encore un tunnel humain, leurs limites de débit supposent encore un rythme humain, et leur politique bot reste un simple « autoriser ou bloquer » fondé sur des chaînes user-agent que n'importe qui peut falsifier. Cet article traite de ce qui change réellement au niveau de l'infrastructure.
Tout ce trafic n'est pas équivalent
La première erreur consiste à traiter le « trafic bot » comme une catégorie unique. La ventilation Cloudflare de mai 2026 sur les requêtes de crawlers IA est éclairante :
- 51,8% servent à l'entraînement des modèles — collecte massive de corpus, peu de valeur pour vous, coût de bande passante élevé
- 9,3% servent à l'indexation de recherche — la relation classique crawl-et-classement
- Le reste correspond à une activité d'agent déclenchée par un utilisateur — quelqu'un a posé une question à un assistant, et celui-ci récupère votre page à l'instant même pour y répondre
Ces trois catégories méritent des traitements totalement différents. Les crawls d'entraînement sont un pur centre de coût, sauf accord de licence. Les crawls de recherche relèvent du vieux pacte : vous donnez du contenu, vous recevez du trafic. Les récupérations déclenchées par un utilisateur sont les plus intéressantes — c'est une intention client vivante qui arrive par un nouveau canal, et la bloquer équivaut à bloquer un navigateur.
Si votre politique bot ne sait pas distinguer ces trois cas, ce n'est pas une politique. C'est un tirage à pile ou face.
Identité : pourquoi les user-agents sont finis
La méthode historique d'identification d'un crawler reposait sur l'en-tête user-agent complété d'une vérification DNS inverse contre des plages d'IP publiées. Les deux mécanismes s'effondrent. Les chaînes user-agent se falsifient sans effort — un scraper qui se déclare GPTBot ne coûte rien. Les listes d'IP autorisées ne survivent pas à une époque où les agents s'exécutent depuis des proxys résidentiels, des fonctions edge et des appareils utilisateurs.
Le remplacement est cryptographique, et il se standardise rapidement.
Web Bot Auth est une proposition IETF portée par Cloudflare qui s'appuie sur la RFC 9421 (HTTP Message Signatures), un Proposed Standard ratifié en février 2024. Le principe est simple : un opérateur d'agent génère une paire de clés Ed25519, publie la clé publique dans un annuaire découvrable, et signe chaque requête sortante avec la clé privée. Votre origine vérifie la signature. L'usurpation devient cryptographiquement impossible plutôt que simplement découragée.
Une requête signée transporte trois en-têtes :
Signature-Input: sig=("@authority" "signature-agent");
created=1700000000;
expires=1700011111;
keyid="ba3e64==";
tag="web-bot-auth"
Signature: sig=abc==
Signature-Agent: signer.example.comSignature-Agent indique où récupérer les clés publiques. Signature-Input déclare les composants signés — ici l'autorité cible et l'en-tête Signature-Agent lui-même — plus une fenêtre de validité et l'empreinte de clé (RFC 7638). Signature porte la valeur.
Le soutien industriel est sérieux : Cloudflare, Amazon, Akamai et OpenAI, avec un groupe de travail IETF constitué en 2026. Les grands opérateurs publient leurs annuaires à des chemins tels que https://anthropic.com/.well-known/http-message-signatures-directory.
Cloudflare a ouvert sa pile de vérification sous cloudflare/web-bot-auth. Elle livre :
web-bot-auth— package npm et crate Rust implémentant le protocole drafthttp-message-sig— signature et vérification RFC 9421jsonwebkey-thumbprint— empreintes de clés RFC 7638- Des implémentations de référence sous forme de Cloudflare Worker et de plugin Caddy
Un point de test en direct existe également sur http-message-signatures-example.research.cloudflare.com pour valider votre implémentation contre la clé de test Ed25519 de la RFC 9421 avant mise en production.
Pour la plupart des équipes, l'action pratique n'est pas d'écrire un vérificateur de zéro. C'est d'activer la vérification de signature sur votre edge existant — Cloudflare a intégré les Message Signatures à son programme Verified Bots — puis de prendre une décision délibérée par opérateur vérifié.
À quoi ressemble une vraie politique d'agents
Une fois les agents signés distingués du trafic anonyme, la hiérarchisation devient possible :
| Classe de trafic | Traitement |
|---|---|
| Agents vérifiés déclenchés par un utilisateur | Servir intégralement, limite généreuse, suivre comme un canal |
| Crawlers de recherche vérifiés | Servir, budget de crawl standard |
| Crawlers d'entraînement vérifiés | Décision business — autoriser, facturer, ou exiger une licence |
| Bots non signés et auto-déclarés | Limite agressive, application stricte du robots.txt |
| Non signés usurpant un UA connu | Bloquer |
Le levier utile ici est rarement « tout bloquer ». Bloquer le trafic agentique déclenché par un utilisateur en 2026 produit le même effet que bloquer les navigateurs mobiles en 2010 : vous disparaissez d'un canal émergent que vos concurrents, eux, servent. Le levier, c'est la sélectivité — précisément ce que l'identité cryptographique vous achète.
Servir des pages réellement exploitables par un agent
La vérification règle la question du « qui ». L'autre moitié concerne l'exploitabilité de la réponse.
Les agents interagissent avec les pages à peu près comme un lecteur d'écran : via le DOM, pas via les pixels. Les implications sont concrètes :
Rendez le contenu côté serveur. Un agent qui reçoit une coquille vide et un bundle JavaScript peut ou non l'exécuter. Beaucoup ne le feront pas, et ceux qui le font y consomment du budget. Si votre contenu n'existe qu'après hydratation, considérez-le comme invisible.
Utilisez la sémantique native des formulaires. Un vrai élément form avec des champs étiquetés et un bouton de soumission est navigable. Un div avec un gestionnaire de clic ne l'est pas. C'est la même discipline qui fait passer un audit d'accessibilité Lighthouse — les deux objectifs convergent presque parfaitement.
Publiez des données structurées. JSON-LD et le balisage schema.org donnent à l'agent des faits sans ambiguïté plutôt que des déductions tirées de la mise en page. Pour tout ce qui porte un prix, une disponibilité, une adresse ou une date, c'est la différence entre être cité correctement et être cité de travers.
Envisagez la négociation de contenu. Servir du markdown plutôt que du HTML aux crawlers identifiés réduit fortement la taille des réponses, ce qui allège votre facture de sortie et augmente les chances d'être correctement analysé. Dès lors que vous pouvez identifier cryptographiquement le demandeur, cette optimisation devient sûre.
Retirez les frictions qui n'existent que pour les humains. CAPTCHAs, défilement infini sans pagination, boutons non étiquetés et interstitiels modaux sont autant d'arrêts nets pour un agent. Si vous voulez ce trafic, dégagez le chemin.
Une partie de ces points recoupe notre guide sur l'optimisation pour la recherche IA et l'AEO — mais cet article-là traite du fait d'être trouvé. Celui-ci traite du fait d'être correctement servi une fois l'agent arrivé.
Au-delà de la lecture : laisser les agents transiger
Lire une page, c'est le petit bain. Le vrai changement, ce sont les agents qui doivent faire quelque chose : réserver, acheter, soumettre, interroger.
Trois approches convergent :
- Exposer des API transactionnelles plutôt que d'imposer une simulation d'interface. Un agent qui pilote votre tunnel de commande à coups de clics DOM est fragile pour vous deux.
- Adopter un protocole de commerce émergent — l'Agentic Commerce Protocol pour les achats via ChatGPT, ou l'Universal Commerce Protocol pour une voie neutre.
- Exposer des fonctions directement aux agents in-page via WebMCP, qui permet à un site de déclarer des outils appelables à un agent résident du navigateur au lieu d'espérer qu'il les déduise du balisage.
Les trois exigent un modèle d'autorisation. OAuth 2.1 avec des credentials à portée limitée, complété d'un contrôle d'accès au niveau ressource, est le motif qui s'est imposé : un agent agissant pour un utilisateur obtient un jeton étroit, révocable et auditable — pas le cookie de session de l'utilisateur. Plus permissif que cela, et vous avez construit un amplificateur d'injection de prompt avec votre base de données derrière.
Instrumenter avant de décider
L'étape que presque tout le monde saute : mesurez d'abord votre propre répartition.
Ajoutez la classification des agents à vos analytics avant de modifier la moindre politique. Segmentez par statut de vérification de signature, par opérateur déclaré et par finalité de requête. La plupart des équipes qui le font découvrent deux choses à la fois — que leur part de trafic bot est bien supérieure à ce qu'elles imaginaient, et qu'une tranche significative correspond à une intention utilisateur réelle qu'elles bridaient silencieusement.
On ne décide pas raisonnablement d'un trafic qu'on n'a jamais séparé. Les 57,5% de Cloudflare sont une moyenne à l'échelle d'Internet, pas votre chiffre. Trouvez le vôtre.
En résumé
Le web n'est plus un média exclusivement humain, et l'outillage pour traiter ce fait honnêtement existe désormais. La RFC 9421 est ratifiée. Web Bot Auth dispose d'un groupe de travail IETF et d'implémentations en TypeScript comme en Rust. Les données structurées et le balisage accessible — ce que les bons ingénieurs font déjà — se révèlent être exactement ce dont les agents ont besoin.
Les équipes qui traitent le trafic agentique comme une surface d'ingénierie plutôt que comme un problème d'abus passeront les deux prochaines années à rester joignables par un canal que leurs concurrents bloquent par défaut.
Vous construisez pour le web agentique ? Noqta accompagne les équipes en Tunisie et en Arabie saoudite dans la conception d'infrastructures prêtes pour les agents — de l'identité bot et la politique edge à l'intégration MCP et au contenu structuré. Parlons-en.