Le standard x402, qui s’appuie sur le code d’erreur HTTP 402 (Payment Required), permet désormais aux services de demander un paiement pour une ressource. Selon developers.cloudflare.com, ce mécanisme autorise les clients à payer de manière programmatique sans avoir besoin de comptes, de sessions ou de clés API. Quand un client demande une ressource via une requête GET /resource, le serveur répond par un 402, incluant les détails de paiement encodés en Base64 dans l’en-tête PAYMENT-REQUIRED.

Ce système s’adresse à toute entité sollicitant une ressource payante : une application gérée par un humain, un agent IA ou un service automatisé. Le client n’a besoin que d’un portefeuille de cryptomonnaie pour gérer la transaction. Le processus se déroule ainsi : le client construit une charge utile de paiement signée et renvoie la requête avec l’en-tête PAYMENT-SIGNATURE. Le serveur vérifie ce paiement, soit directement, soit via un facilitateur tiers, avant de finaliser la transaction sur la blockchain et de livrer la ressource en retour d’un en-tête PAYMENT-RESPONSE.

La gestion des transactions et les schémas de paiement

Le facilitateur est un service tiers optionnel, mais recommandé, qui simplifie l’interaction avec la blockchain. Au lieu que le serveur se connecte directement à un nœud, il délègue deux opérations : POST /verify pour confirmer la validité du paiement, et POST /settle pour soumettre la transaction. Ce facilitateur ne détient pas les fonds ; il valide et diffuse la transaction pré-signée au nom du serveur.

Le standard définit plusieurs schémas de paiement. Le schéma exact permet de transférer un montant fixe, comme un token ERC-20 USDC sur les réseaux EVM, vers l’adresse du marchand. Pour les réseaux EVM, le schéma upto autorise un montant maximal, le coût réel étant déterminé au moment du règlement en fonction de la consommation de la ressource.

Les réseaux pris en charge incluent Base, Ethereum, Polygon, Optimism, Arbitrum, Avalanche, Solana, Aptos, Stellar, Sui et Algorand. Pour les tests, developers.cloudflare.com recommande d’utiliser base-sepolia avec des USDC de test obtenus via le Circle Faucet.

Agents et nécessité de l’identité vérifiée

Ce déploiement de paiement automatisé intervient dans un contexte où la nature des acteurs en ligne change. Cloudflare note que les agents IA agissent pour des millions de personnes sur le web, devenant de plus en plus des intermédiaires. Historiquement, un site pouvait bloquer ce trafic intermédiaire, mais cette stratégie devient inopérante lorsque le trafic agentique risque de dépasser celui des utilisateurs humains.

L’enjeu, comme le souligne Cloudflare, est de maintenir la relation entre le site et l’utilisateur final, même si un agent s’interpose. Cette problématique est accentuée par le fait que les agents ne connaissent pas de fatigue et peuvent opérer en parallèle à une échelle quasi illimitée. En entreprise, par exemple, l’on constate que les systèmes de confiance accordés aux comptes humains sont étendus aux agents, sans examen approfondi de l’identité réelle derrière la session, ce qui expose à des risques de détournement d’instructions.

Le x402 apporte une granularité au paiement, permettant aux sites de monétiser les actions des agents de façon décentralisée. D’ailleurs, Cloudflare propose déjà des outils pour authentifier ces agents via le protocole Web Bot Auth, qui utilise des signatures cryptographiques Ed25519 pour vérifier l’origine des requêtes automatiques avant même que la question du paiement ne se pose.

Sources

• x402 · Cloudflare Agents docs, developers.cloudflare.com
• Web Bot Auth · Cloudflare bot solutions docs, developers.cloudflare.com
• Agents aren’t humans (but they kinda are), Cloudflare, 5 novembre 2026
• The Agent Smith Dilemma: Governing Agentic Identities, SecurityWeek, 5 novembre 2026