x402 et les paiements entre machines en 2026 : facturer les agents IA à la requête, et ce qu'il y a de réel là-dedans

HTTP dispose d'un code d'état pour cela depuis les débuts du web. La RFC 9110 le dit encore sans détour : « Le code d'état 402 (Payment Required) est réservé pour un usage futur. » En 2026, deux protocoles tentent de faire arriver ce futur. x402, lancé par Coinbase et désormais piloté par un projet de la Linux Foundation, répond à une requête par un prix et accepte, à la nouvelle tentative, un paiement signé en stablecoin. Le Machine Payments Protocol (MPP), de Stripe et de Tempo, fait de même par les en-têtes d'authentification de HTTP et prend en charge les cartes comme les stablecoins. AWS et Cloudflare vendent désormais ces deux idées à la périphérie du réseau (edge), si bien qu'un éditeur peut faire payer les robots d'indexation d'IA sans toucher à son serveur d'origine.

L'argument séduit quiconque vend des données, une API ou du contenu que lisent des agents IA : facturer à l'appel, régler en quelques secondes, sans comptes ni factures. Les chiffres qui sous-tendent l'argument sont une autre affaire. Une mesure indépendante de x402 sur Base a constaté que la plupart des règlements enregistrés sont des paiements à soi-même ou des fonds qui circulent à l'intérieur d'un même groupe de portefeuilles, et une société d'analyse de la blockchain évalue à environ USD 5 000 à 11 000 par mois, en 2026, le volume qui ressemble à des agents en train d'acheter.

Cet article s'adresse aux propriétaires et aux développeurs d'API, de services de données et de sites de contenu qui se demandent s'il faut facturer les agents dès maintenant. Il explique le fonctionnement des protocoles, ce que propose chaque fournisseur au 22 octobre 2026, ce que vous auriez à construire, ce que montrent réellement les volumes et les questions réglementaires qui accompagnent la détention de stablecoins.

Comment fonctionne x402

La spécification en est à la version 2, datée du 9 décembre 2025, dans un dépôt passé de Coinbase à la x402 Foundation. Elle définit trois rôles : un serveur de ressources qui veut être payé, un client (souvent un agent) qui paie, et un facilitateur qui « assure la vérification des paiements et leur règlement sur la blockchain ».

Une requête payante se déroule ainsi :

1. Le client demande la ressource et reçoit 402 Payment Required. Un en-tête PAYMENT-REQUIRED porte un objet encodé en Base64 qui liste un ou plusieurs moyens de paiement acceptables, chacun avec un scheme, un network au format CAIP-2 (eip155:8453 est Base), un amount dans les plus petites unités du token, un asset, une adresse payTo et un maxTimeoutSeconds.
2. Le client signe un paiement et répète la requête avec un en-tête PAYMENT-SIGNATURE. Sur les chaînes EVM, il s'agit d'une signature EIP-712 portant sur une autorisation de transfert EIP-3009, avec une fenêtre de validité et un nonce de 32 octets contre le rejeu.
3. Le serveur fait vérifier la signature par le facilitateur (POST /verify, qui « NE DOIT PAS enregistrer d'état de paiement »), exécute son gestionnaire, puis fait régler par le facilitateur (POST /settle).
4. Le serveur répond avec la ressource et un en-tête PAYMENT-RESPONSE contenant le hash de la transaction.

C'est le flux « authorization » par défaut : « le paiement est vérifié avant l'exécution de la ressource et réglé ensuite ». Deux autres flux sont définis : l'un qui règle d'abord, l'autre qui prend un dépôt et règle le montant final après coup. Si un règlement a été diffusé sans être confirmé, le facilitateur peut renvoyer settlement_pending avec le hash, et le serveur doit faire le rapprochement avant que quiconque ne réessaie.

Deux détails piègent les gens. La version 1, que montrent la plupart des anciens tutoriels, utilisait X-PAYMENT et X-PAYMENT-RESPONSE ainsi que des noms de réseau comme base-sepolia ; la version 2 a renommé les en-têtes et adopté CAIP-2. Et les mêmes messages sont définis au-dessus de MCP et du protocole Agent-to-Agent (A2A) : avec MCP, un outil payant renvoie un résultat avec isError: true et le paiement transite dans _meta["x402/payment"].

Les quatre schémas de paiement

Sur les chaînes EVM, n'importe quel token ERC-20 fonctionne en principe, via EIP-3009 (la méthode de l'USDC) ou Permit2. En pratique, les SDK de référence fixent les prix en dollars et font correspondre "$0.01" à un stablecoin en USD propre à chaque réseau : l'USDC sur Base et sur la plupart des chaînes EVM, plusieurs stablecoins sur Solana, l'USDT sur TON. Le client de référence n'accepte que les actifs qu'il reconnaît et plafonne chaque paiement à USD 1 par défaut. Il n'y a pas de valeur par défaut en euros.

Les facilitateurs : qui déplace l'argent

Le facilitateur est « facultatif mais recommandé ». Il vérifie les signatures et soumet le transfert on-chain, et la documentation dit qu'il « ne détient pas de fonds et n'agit pas comme dépositaire » : l'argent arrive dans votre portefeuille payTo.

• Le facilitateur public x402.org est réservé aux réseaux de test. Le guide de démarrage pour les vendeurs est explicite : « Ne réutilisez pas https://x402.org/facilitator pour des routes sur le mainnet. »
• Le facilitateur CDP hébergé de Coinbase ne facture rien pour les 1 000 premières transactions on-chain du mois, puis USD 0,001 chacune, la vérification restant toujours gratuite. Il applique à chaque paiement des contrôles OFAC et Know Your Transaction, exige une clé d'API CDP et prend en charge Base, Polygon, Arbitrum, Monad, World et Solana. Il ne liste pas auth-capture. Le règlement par lots répartit les frais : « une seule transaction on-chain peut traiter des milliers de paiements ».
• La fondation liste d'autres facilitateurs en production, dont Fireblocks, Polygon, PayAI, Corbits, Stellar et Celo, et précise que la liste n'est « pas un catalogue exhaustif ».
• Vous pouvez être votre propre facilitateur, en payant le gas et, sur Solana, en construisant la détection des doubles règlements qu'un facilitateur fournirait sinon.

La x402 Foundation est devenue opérationnelle le 14 juillet 2026 avec 40 membres. Ses membres premier niveau comprennent Adyen, AWS, American Express, Cloudflare, Coinbase, Google, Mastercard, Shopify, Stripe et Visa ; son comité de pilotage technique compte des membres de Coinbase, de Cloudflare et de Stripe. Être membre, c'est soutenir la gouvernance, pas déployer. Le communiqué de lancement mentionne la « prise en charge de types de paiement allant des cartes traditionnelles aux stablecoins », mais la spécification ne comporte aujourd'hui aucune liaison avec les cartes.

Le Machine Payments Protocol de Stripe et Tempo

Stripe et Tempo ont lancé MPP le 18 mars 2026, jour de la mise en service du mainnet de Tempo. Il s'appuie sur le cadre d'authentification de HTTP : un 402 avec un défi WWW-Authenticate: Payment, un justificatif dans Authorization: Payment et un en-tête Payment-Receipt en cas de succès. Ses intentions sont charge (un paiement), session (paiement en flux sur un canal) et subscription, et ses moyens de paiement en production sont les stablecoins de Tempo et les moyens de paiement par carte de Stripe. Visa a publié le même jour une spécification pour les cartes et un SDK pour MPP. Le document de l'IETF qui le sous-tend est un Internet-Draft individuel qui « n'a aucun statut formel dans le processus de normalisation de l'IETF ».

Sur Stripe, MPP accepte les cartes (via les Shared Payment Tokens) et les stablecoins, et Stripe accepte aussi les paiements x402 en stablecoin sur Base, réglés par le facilitateur de Coinbase vers une adresse de dépôt Stripe. Dans les deux cas, le résultat arrive dans votre solde Stripe sous forme de PaymentIntent, et les stablecoins envoyés à une adresse de dépôt sont convertis : « Stripe convertit automatiquement ces paiements en monnaie courante (offramp) et les règle dans votre solde Stripe. » Les conditions :

• L'acceptation des stablecoins est « disponible pour les entreprises de tous les États américains, à l'exception de New York ». Ailleurs, vous écrivez à Stripe pour demander l'accès, qui est examiné ; l'Union européenne, Hong Kong, le Mexique et la Suisse sont en préversion privée.
• Les minimums sont de USD 0,50 pour un paiement par carte et de 0,01 USDC pour un paiement en stablecoin. Les sessions MPP peuvent facturer par paliers « aussi petits que 0,000001 USDC » mais règlent en cents entiers, et un reste inférieur au cent est perdu.
• Les paiements en stablecoin sur Stripe n'ont pas de prise en charge des litiges, les remboursements repartent en stablecoins vers le portefeuille d'origine, et une transaction unique est plafonnée à USD 10 000.
• Les API sont des versions en préversion (2026-07-29.preview pour MPP, 2026-05-27.preview pour l'adresse de dépôt x402).

Visa Intelligent Commerce Connect, annoncé le 8 avril 2026 en phase pilote, liste MPP parmi les protocoles d'agent que les marchands peuvent accepter par son intermédiaire. Il ne liste pas x402.

Facturer à la périphérie du réseau : AWS et Cloudflare

Si votre contenu ou votre API se trouve déjà derrière un CDN, la périphérie du réseau peut se charger de la facturation.

AWS WAF AI traffic monetization (annoncé le 15 juin 2026) renvoie aux bots et aux agents « une réponse HTTP 402 Payment Required lisible par une machine, selon le protocole ouvert x402 », et règle via le facilitateur de Coinbase vers un portefeuille USDC que vous fournissez, sur Base ou Solana. La fonctionnalité n'entraîne aucun frais supplémentaire, mais les frais habituels de WAF et de Bot Control s'appliquent, et elle ne fonctionne qu'avec CloudFront. Vous pouvez tarifer différemment les robots d'indexation de moteurs de recherche vérifiés, les agents non vérifiés et les robots d'entraînement, et tester avant la mise en ligne. Elle ne règle que si votre serveur d'origine renvoie un 2xx, et ne facture pas les 4xx ni les 5xx. La documentation est franche sur les coûts : un minimum de USD 0,001 par requête, « plusieurs secondes de latence supplémentaire » sur les requêtes payantes, une détection des bots qui est « probabiliste », et un avertissement : une règle Monetize qui ne se limite pas aux bots « bloquera de fait l'accès aux clients non automatisés ». « AWS n'est pas partie au flux de fonds ni n'y intervient », et vous acceptez les conditions de Coinbase. Le règlement via Stripe et la prise en charge de MPP étaient « bientôt disponibles » lors de l'annonce.

Cloudflare pay per crawl relève d'un autre modèle. Il est en bêta fermée, votre domaine doit être chez Cloudflare, vous fixez un prix unique pour tous les robots que vous facturez, et Cloudflare « agit comme marchand officiel (merchant of record) ». Les robots s'identifient avec Web Bot Auth et paient par facture Stripe, pas depuis un portefeuille. Vous ne touchez jamais aux stablecoins.

Cloudflare Workers peuvent placer un proxy x402 ou MPP devant n'importe quel backend HTTP, avec un prix par motif de route, et ne facturer que les requêtes dont le score de bot est bas, afin que les personnes naviguent gratuitement. L'Agents SDK propose paidTool, qui transforme un outil MCP en outil payant. Notez que les exemples de Cloudflare utilisent le facilitateur x402.org, orienté testnet, et les noms de réseau de la version 1 ; pour la production, remplacez-le par un facilitateur de production et des identifiants CAIP-2.

Ce qu'il y a de réel là-dedans

Les chiffres mis en avant sont élevés et ne concordent pas entre eux. La page d'accueil de x402.org affiche 75,41 millions de transactions et USD 24,24 millions sur les 30 derniers jours, sans date, source ni méthode sur la page. Coinbase dit que son facilitateur a traité « plus de 100 millions de transactions et 28 millions de dollars de volume de paiements sur Base et Solana seulement », sans période. Ce sont des décomptes de règlements, et c'est là que le bât blesse.

Une étude de mesure de chercheurs de la City University of Hong Kong, de The Chinese University of Hong Kong et de la Zhejiang University (un preprint, publié le 14 juillet 2026) a examiné 280 jours de x402 sur Base, du 17 septembre 2025 au 23 juin 2026 : 136 708 672 règlements, pour USD 44,1 millions. Parmi eux, « 21,20 % sont fictifs et 63,78 % relèvent d'un règlement interne au sein d'un groupe lié ». La valeur qui « parvient de façon démontrable à un service identifiable » était de USD 187 861,35. Sur 624 destinataires ayant jamais été payés, 249 ont gagné au moins USD 10, le revenu médian sur toute la durée était de USD 3,96, et seuls 474 des 910 hôtes annoncés renvoyaient encore un défi de paiement actif. La conclusion des auteurs : « Le nombre de règlements mesure la fabricabilité, pas l'adoption. »

TRM Labs, qui vend de la surveillance de blockchain, a compté USD 52,7 millions répartis sur 198,9 millions de règlements sur Base, Solana et Polygon depuis mai 2025. Environ la moitié a disparu une fois retirés les paiements à soi-même, les flux en masse et les vendeurs aux acheteurs trop rares. Sur les USD 25,62 millions restants, elle a estimé qu'entre 0,6 % et 7,5 % « semblent agentiques », et que le volume déplacé par des agents est resté d'environ USD 5 000 à 11 000 par mois tout au long de 2026. Sa lecture pour les vendeurs est utile : « attirer le trafic des agents demande une conception différente. Il faut qu'elle soit lisible par les machines et qu'elle ait une tarification à l'appel sur un endpoint qu'un acheteur peut découvrir sans qu'un humain voie jamais la page. »

Rien de cela ne dit que l'idée est mauvaise. Cela dit qu'en octobre 2026, un endpoint qui facture les agents à l'appel doit s'attendre à des revenus de l'ordre de l'expérience, et qu'il ne faut pas bâtir de plan sur les chiffres mis en avant.

Qui détient l'argent, et quelles règles s'appliquent

Avec x402, le paiement va directement dans votre portefeuille. Cela signifie que votre entreprise détient les clés, porte de l'USDC dans ses comptes et le convertit dans sa propre monnaie, à moins qu'un prestataire comme Stripe ne le convertisse pour vous. Le filtrage du facilitateur (les contrôles OFAC et KYT de Coinbase) est une prestation du facilitateur ; la spécification x402 n'en définit aucun. Les remboursements, c'est à vous de les organiser : exact « ne définit aucun remboursement », et les paiements en stablecoin de Stripe n'ont pas de litiges.

Deux régimes concernent quiconque se trouve dans le flux de fonds.

• États-Unis : le GENIUS Act. La Public Law 119-27, approuvée le 18 juillet 2025, entre en vigueur 18 mois après sa promulgation ou 120 jours après les règlements définitifs, selon la première de ces échéances. La proposition de règle du Trésor du 18 août 2026 indique que la date d'entrée en vigueur « devrait être le 18 janvier 2027 ». À partir de cette date, un prestataire de services d'actifs numériques ne peut pas proposer aux États-Unis le stablecoin d'un émetteur étranger, sauf si l'émetteur peut se conformer aux ordres légaux. À partir du 18 juillet 2028, un prestataire de services d'actifs numériques ne peut ni offrir ni vendre un stablecoin de paiement à une personne aux États-Unis, sauf si un émetteur autorisé l'a émis. La loi définit un prestataire de services d'actifs numériques par des activités telles qu'échanger, transférer ou détenir des actifs numériques pour autrui, exercées « contre rémunération ou en vue d'un profit ».
• Union européenne : MiCA. La période transitoire des prestataires de services sur crypto-actifs a pris fin le 1er juillet 2026. Déclaration de l'ESMA : « toute entité fournissant des services sur crypto-actifs à des clients de l'UE sans agrément MiCA enfreindra le droit de l'UE et devra cesser de proposer ces services », et les sociétés hors UE ne peuvent pas servir des clients de l'UE, « y compris […] dans un contexte interentreprises ». Les stablecoins en USD sont des jetons de monnaie électronique au sens de MiCA. Le conseil de l'ESMA aux utilisateurs est de vérifier qu'un prestataire figure sur son registre provisoire.

Ce qu'aucune de ces sources ne tranche, c'est la situation d'une entreprise qui reçoit seulement des stablecoins en paiement de sa propre API ou de son propre contenu. Les restrictions du GENIUS Act sont écrites pour les prestataires de services d'actifs numériques, et celles de MiCA pour les prestataires de services sur crypto-actifs ; savoir si votre montage fait de vous l'un ou l'autre, ou vous fait dépendre de prestataires qui doivent l'être, est une question pour un juriste dans chaque juridiction où vous exercez. Nous sommes des ingénieurs, pas des juristes, et nous construisons selon la réponse de votre conseil. En pratique, demandez à chaque prestataire de votre chaîne s'il est agréé là où se trouvent vos clients.

Quatre façons de le construire

Du moins de code au plus :

1. Laisser le CDN facturer. AWS WAF sur CloudFront : une configuration de monétisation avec votre portefeuille et vos prix, des règles Monetize limitées à des étiquettes de bots, le mode test d'abord, aucune modification du serveur d'origine. Cloudflare pay per crawl : si vous êtes dans la bêta, un prix et des paramètres de versement, avec Cloudflare comme marchand officiel.
2. Laisser un prestataire de paiement facturer. Stripe MPP : un profil Stripe, la bibliothèque mppx, un appel charge dans votre gestionnaire et une adresse de dépôt Tempo. Carte et stablecoin, réglés en monnaie courante dans votre solde Stripe. Ou x402 sur Stripe avec un compte CDP et une adresse de dépôt sur Base, stablecoin uniquement.
3. Faire tourner x402 dans votre propre serveur avec le middleware du SDK pour votre framework (Express, Hono, Next.js, Fastify ; il existe des SDK Python et Go), un facilitateur hébergé et une configuration de route composée du schéma, du prix, du réseau, de payTo et d'une description.
4. Être votre propre facilitateur, si vous avez besoin d'un contrôle complet ou d'un réseau que personne ne dessert.

Quelle que soit la voie choisie, certaines décisions restent les vôtres : quel schéma convient au travail (exact pour des prix fixes, upto pour un travail mesuré, le règlement par lots lorsque les appels valent moins que le gas), qui voit le mur de paiement (un 402 affiché à un utilisateur dans un navigateur est une impasse), comment vous rapprochez settlement_pending, des nouvelles tentatives idempotentes si les clients envoient un identifiant de paiement, les remboursements, la garde du portefeuille de réception et la façon dont vous comptabilisez les encaissements en USDC. Les agents doivent aussi pouvoir payer : un client x402 a besoin d'un portefeuille contenant le bon stablecoin sur le bon réseau, un client MPP d'un portefeuille Link ou Tempo, un robot pay per crawl d'une identité Web Bot Auth et d'une relation de facturation avec Stripe. Vous ne pouvez pas supposer qu'un agent donné dispose de l'un d'eux.

Faut-il facturer les agents dès maintenant ?

• Vous vendez une API ou des données que des agents appellent déjà : une expérience coûte peu. Placez un ou deux endpoints derrière MPP ou x402, à côté de vos clés et de vos forfaits existants, fixez un prix supérieur aux planchers (USD 0,001 chez AWS, 0,01 USDC chez Stripe) et mesurez qui paie. Conservez vos forfaits payants actuels : le canal du paiement par les agents restera petit pour l'instant.
• Vous publiez du contenu que des robots d'indexation d'IA lisent déjà : les options à la périphérie du réseau existent pour cela. AWS WAF si vous êtes sur CloudFront et à l'aise avec la détention d'USDC ; Cloudflare pay per crawl si vous êtes chez Cloudflare, voulez un règlement par carte et pouvez entrer dans la bêta. Ni l'un ni l'autre n'est encore un plan de revenus ; les deux vous donnent un prix et un journal de ceux qui ont refusé de le payer.
• Vous voulez que des agents achètent des biens dans votre boutique : ce n'est pas ce problème. Les réseaux de cartes, les Shared Payment Tokens de Stripe et les protocoles de paiement de Google et d'OpenAI couvrent les agents qui achètent auprès de marchands, et nous les traitons dans notre article sur les paiements agentiques.

Ce qui pourrait changer

• L'entrée en vigueur du GENIUS Act le 18 janvier 2027 (plus tôt si les règlements définitifs arrivent d'abord), et la restriction de 2028 qui suit.
• L'ajout par AWS du règlement via Stripe et de MPP, annoncé comme bientôt disponible.
• La maturation de auth-capture, qui donnerait à x402 des remboursements en dehors des drafts.
• L'Internet-Draft de MPP qui avancerait, ou non, vers un groupe de travail de l'IETF.
• Visa Intelligent Commerce Connect qui s'élargirait au-delà de ses partenaires pilotes, ce qui apporterait à davantage de marchands, via MPP, les paiements d'agents financés par carte.

Où trouver de l'aide

Nous construisons le côté serveur de l'accès payant des machines : mesure de la consommation et tarification par endpoint, défis x402 ou MPP devant des API et des outils MCP existants, rapprochement des règlements dans les systèmes que votre équipe financière utilise déjà, et l'identification des bots qui décide qui voit un prix. Notre service de développement d'agents IA et d'intégration de serveurs MCP est le point de départ de ce travail.

Si vous hésitez à facturer les agents pour votre API ou votre contenu, et par quel prestataire, écrivez à office@c9group.dev.