HTTP 402 : le guide complet du paiement entre machines

Un logiciel qui veut acheter quelque chose n'a ni carte bancaire, ni compte client, ni historique avec le vendeur. Il a une adresse et des dollars. Le web n'a jamais su servir ce client-là, alors qu'il transporte depuis vingt-neuf ans le code de statut prévu exactement pour lui.

Ce guide couvre les quatre questions dans l'ordre où elles se posent : ce qu'est x402, comment il fonctionne jusqu'au champ près, ce que le réseau traite réellement aujourd'hui, et la marche à suivre pour le mettre en place des deux côtés.

Un code réservé depuis 1997, et la convention qui manquait

La première spécification de HTTP/1.1, publiée en janvier 1997, réserve un code de statut nommé « Payment Required » et le laisse vide. Sa définition tient en une phrase : ce code est réservé pour un usage futur. Vingt-cinq ans plus tard, la spécification qui l'a remplacée, le RFC 9110 de juin 2022, reprend la même formule sans y ajouter un mot.

Le web savait donc dire « il faut payer » depuis l'origine. Ce qui manquait, c'était la convention sur la suite : quoi répondre avec ce code, dans quel format, et comment le client prouve qu'il a payé. x402 est cette convention.

Ce qu'il n'est pas mérite d'être dit aussi clairement, parce que c'est là que se logent les malentendus les plus coûteux. Ce n'est pas une blockchain, on ne choisit pas x402 contre Ethereum ou Solana, on l'utilise par-dessus. Ce n'est pas un jeton, il n'y a rien à acheter pour s'en servir. Ce n'est pas un smart contract, il n'y a rien à déployer ni à auditer. Un serveur x402 est un serveur HTTP ordinaire qui sait répondre 402 avec le bon message.

C'est le point qui décide de la faisabilité d'un projet : le risque technique d'intégration est proche de zéro, parce qu'il n'y a pas de code à soi sur la chaîne.

Reste la question de savoir qui porte tout ça, et elle compte autant que la technique quand il s'agit de miser sur un standard. Le protocole a été lancé par Coinbase en mai 2025, puis branché par AWS en juin 2026 et par Cloudflare deux semaines plus tard. Son créateur en a depuis transféré la gouvernance à une fondation neutre sous l'égide de la Linux Foundation, dont Visa, Mastercard, American Express et Stripe ont rejoint le conseil en juillet 2026. Autrement dit : un standard ouvert, gouverné par un consortium plutôt que par une entreprise, et dont les réseaux de cartes ont choisi d'être membres plutôt que spectateurs.

Comment un logiciel paie, étape par étape

L'échange tient en cinq temps et dans une seule boucle de requête.

Le client appelle une adresse, sans compte ni clé. Le serveur répond 402 en joignant ses conditions de paiement au format JSON. Le client construit la transaction correspondante, la signe, et rejoue exactement le même appel en y attachant sa preuve de paiement. Le serveur fait vérifier, fait régler, et répond 200 avec la ressource.

Le cœur de l'affaire est dans le message que renvoie le serveur. Il ne dit pas seulement « payez », il dit combien, à qui, en quoi, sur quel réseau, et qui acquittera les frais.

Deux champs méritent une attention particulière. Le montant s'exprime en unités atomiques, pas en dollars : un stablecoin à six décimales rend une erreur d'échelle silencieuse et coûteuse. Et le champ extra.feePayer porte l'adresse de celui qui paiera les frais de réseau, ce qui nous amène au mécanisme central.

Le détail qui fait tout tenir : l'acheteur n'a pas besoin de gas

Quand le client construit sa transaction, il ne la signe pas entièrement. La spécification du schéma exact décrit une transaction partiellement signée, à laquelle il manque encore la signature de celui qui va payer les frais de réseau. Cette signature, c'est le facilitateur qui l'apposera, en qualité de payeur de frais, avant de soumettre l'ensemble à la chaîne.

Sur les chaînes compatibles Ethereum, la formulation est identique : le facilitateur paie le gaz, le client garde le contrôle du montant et du destinataire par sa seule signature, et le facilitateur ne peut modifier ni l'un ni l'autre. Il paie le timbre, il ne touche pas à la lettre.

Sans ce mécanisme, chaque agent devrait tenir deux soldes dans deux actifs sur chaque réseau : des dollars pour payer, et le jeton natif pour avoir le droit de payer. Il faudrait les approvisionner, les surveiller, les rééquilibrer. Avec, il suffit d'avoir des dollars. C'est ce qui fait passer l'idée d'une machine cliente du théorique au praticable, et c'est la première chose à comprendre avant toute décision d'architecture.

Une réserve à porter : cette dispense vaut dans le flux avec facilitateur. En implémentation autonome, sans facilitateur, le client redevient payeur de frais et doit détenir le jeton du réseau.

Qui garantit quoi, et pourquoi il n'y a aucun smart contract

Un transfert de stablecoin sur Solana est un appel au programme de jetons du réseau, déployé par Solana et en production depuis des années. On n'écrit rien, on appelle une bibliothèque système. Aucun code propre ne vit sur la chaîne, donc rien à auditer, rien qui puisse contenir un bug à soi.

Reste la question de confiance : qui dit que le paiement a eu lieu. Ce n'est pas le facilitateur, c'est la chaîne. La réponse de règlement contient une signature de transaction vérifiable sur n'importe quel explorateur public. Un facilitateur peut refuser de régler ; il ne peut pas prétendre avoir réglé. Cette asymétrie est ce qui rend acceptable de s'appuyer sur un facilitateur hébergé par un tiers sans avoir à lui faire confiance.

Il ne détient d'ailleurs jamais les fonds. Les dollars vont directement du portefeuille de l'acheteur à celui du vendeur ; le facilitateur ne fait que vérifier, avancer les frais de réseau et diffuser.

Où en est réellement le marché

Le 14 juillet 2026, Visa et Artemis ont publié la première mesure ajustée de cette activité, c'est-à-dire débarrassée des transactions de test et des boucles d'auto-échange. Sur des données arrêtées au 21 avril 2026 : 15 millions de dollars de volume pour 109,6 millions de transactions depuis mai 2025. Le panier moyen ressort autour de 0,14 dollar.

L'apport du document n'est pas ce chiffre, c'est l'instrument. La catégorie se mesurait jusque-là en transactions brutes, une unité que ses promoteurs contrôlent. Elle dispose maintenant d'une base opposable.

La forme de la courbe dit le reste. Les relevés publics du cumul mensuel montrent que 111 des 159 millions de transactions du protocole sont tombées sur les trois derniers mois de 2025, et que le rythme est stable autour de 5 millions par mois depuis février 2026. Notre analyse du 2 juillet relevait déjà, sur les données d'Artemis de mars, près de la moitié de transactions artificielles autour d'un memecoin pendant cette période de pic.

Le verrou n'est pourtant pas technique. Aujourd'hui, la majorité des paiements d'agents passe encore par une validation humaine dans un portefeuille. Un chiffrage repris par la presse spécialisée évalue le coût de cette confirmation entre 0,03 et 0,10 dollar l'unité. Sur un panier de 0,14 dollar, approuver coûte du même ordre de grandeur que payer. Une économie de machines qui réclame un humain à chaque achat n'en est pas une, et c'est ce chaînon, l'autorisation déléguée par mandat signé, qui se construit actuellement ailleurs que dans le protocole.

Notre estimation à horizon 2031, hypothèses affichées dans le visuel ci-dessus, tient entre 0,5 et 2 milliards de dollars par an en scénario médian. C'est une projection, pas une donnée. Elle a le mérite de fixer l'ordre de grandeur : le chemin vers un vrai marché passe par la taille du ticket, pas par le nombre de transactions.

Mettre en place le côté vendeur

Quatre gestes, et aucun ne demande de compétence blockchain.

Premier geste, répondre 402. Sur la route à protéger, renvoyer le code 402 accompagné du manifeste décrit plus haut. C'est de la logique applicative ordinaire, dans le langage du serveur existant.

Deuxième geste, choisir un facilitateur. C'est la seule vraie décision d'architecture. Un facilitateur est un serveur tiers qui expose trois routes : /supported pour annoncer ce qu'il sait faire, /verify pour valider un paiement présenté, /settle pour le soumettre à la chaîne et avancer les frais.

Le relevé ci-dessus a été fait en interrogeant directement les endpoints publics le 28 juillet 2026, et pas en recopiant une documentation. Deux enseignements. Le premier : x402.org/facilitator/supported annonce huit familles de chaînes, Algorand, Aptos, Base, EVM, Hedera, Solana, Stellar et XRPL. x402 a cessé d'être une affaire Ethereum plus Solana, et le choix du réseau se fait donc plus tard qu'on ne le croit. Le second : facilitator.payai.network couvre Solana en réseau principal comme en réseau de test, sans clé d'API, avec 46 combinaisons de version, schéma et réseau annoncées. Pour prototyper, il n'y a rien à demander à personne.

Troisième geste, brancher la vérification. À réception d'un paiement, appeler /verify, servir la ressource si la réponse est positive, puis appeler /settle. L'ordre importe : on sert après vérification, on encaisse après.

Quatrième geste, disposer d'une adresse de réception valide. Sur Solana, le compte de réception dédié au couple portefeuille et jeton doit exister avant le premier paiement. C'est le piège le plus fréquent, détaillé plus bas.

Compter une journée de travail pour la boucle complète en réseau de test. Ce qui prend du temps n'est pas le protocole.

Mettre en place le côté acheteur

Le client fait le chemin inverse, et son travail est plus technique parce que la forme de la transaction est imposée.

Il lit le manifeste, retient l'offre qui correspond à ce qu'il accepte de payer, puis construit une transaction dont l'ordre des instructions est contraint : deux instructions de budget de calcul, puis le transfert vérifié vers le compte de réception du vendeur, puis éventuellement une note servant d'identifiant unique. Le facilitateur refuse toute transaction qui s'écarte de cette forme.

Il signe ensuite à sa position en laissant vide la case du payeur de frais, sérialise, encode en base64, et rejoue sa requête initiale en attachant ce paquet. Un seul champ, la transaction elle-même. C'est tout ce que le protocole transporte.

Ce que l'agent doit détenir se résume donc à deux choses : des dollars numériques, et une clé capable de signer. Ce qu'il n'a pas à détenir, et c'est ce qui change tout à l'échelle d'une flotte : le jeton natif de chaque réseau qu'il touche.

Les cinq pièges que les tutoriels ne mentionnent pas

Ils viennent tous d'une vérification sur les spécifications et le code de référence, pas d'une documentation d'introduction.

Les décimales. Le montant est exprimé en unités atomiques. Un stablecoin à six décimales transforme une erreur d'échelle en vente à un millionième du prix, sans aucun message d'erreur.

Le compte de réception qui n'existe pas. Sur Solana, chaque couple propriétaire et jeton a un compte dédié à une adresse déterministe. Ni le client de référence ni les implémentations courantes n'ajoutent d'instruction pour le créer. Si le vendeur n'a jamais reçu ce stablecoin, le paiement échoue et le message ne le dit pas clairement.

Le règlement dupliqué. La même transaction soumise deux fois avant confirmation peut renvoyer un succès les deux fois, parce que le réseau la déduplique en silence. La spécification recommande un cache en mémoire indexé sur la charge utile, qui rejette la seconde présentation.

L'expiration du blockhash. Une transaction construite trop tôt devient invalide avant d'être soumise. C'est marginal pour un achat déclenché par un humain, structurel pour un agent qui tourne sur une tâche planifiée : il faut reconstruire et réessayer, ou passer par un mécanisme de validité prolongée.

Le payeur de frais codé en dur. L'adresse du facilitateur se lit sur son /supported au moment de construire le manifeste. La figer dans le code revient à parier qu'elle ne changera jamais.

Ce que le protocole ne résout pas

x402 règle la mécanique du paiement et rien d'autre. Il ne dit pas si un agent a le droit de dépenser, ni combien, ni chez qui. Cette couche d'autorisation, plafonds, listes blanches de destinataires, budget de session, porte d'approbation au-delà d'un seuil, reste entièrement à la charge de celui qui déploie l'agent. C'est aujourd'hui le vrai sujet, et c'est aussi le vrai risque : une clé qui signe sans plafond ni liste blanche est un incident qui attend son heure.

Il ne résout pas davantage la question de ce qui est acheté. Un rail de paiement parfait ne dit rien de la valeur de ce qui circule dessus.

FAQ

x402, c'est quoi exactement ?
Une convention ouverte qui donne enfin un usage au code HTTP 402 « Payment Required », réservé sans emploi depuis 1997. Elle définit ce qu'un serveur répond quand il exige un paiement, et comment le client prouve qu'il a payé. Ce n'est ni une blockchain, ni un jeton, ni un contrat.

Faut-il déployer un smart contract pour l'utiliser ?
Non. Un serveur x402 est un serveur web ordinaire qui sait répondre 402 avec le bon message. Le paiement appelle le programme de jetons du réseau, déjà déployé. L'intégrateur n'écrit aucun code on-chain, donc n'a rien à auditer.

L'acheteur doit-il détenir des cryptos pour payer ?
Des dollars numériques oui, le jeton natif de la chaîne non. Dans le flux avec facilitateur, c'est le facilitateur qui signe comme payeur de frais et acquitte les frais de réseau. En implémentation autonome, le client redevient payeur et doit détenir le jeton du réseau.

Sur quelles blockchains x402 fonctionne-t-il ?
Bien plus largement que sur Solana et les chaînes compatibles Ethereum. Au 28 juillet 2026, le facilitateur de référence annonce huit familles : Algorand, Aptos, Base, EVM, Hedera, Solana, Stellar et XRPL.

Combien de temps faut-il pour mettre en place le côté vendeur ?
La boucle 402 elle-même représente une journée de travail en réseau de test. Ce qui prend du temps, ce sont les cinq pièges détaillés plus haut, dont aucun n'apparaît dans les tutoriels d'introduction.

Le facilitateur peut-il détourner le paiement ?
Non. La spécification est explicite : il ne peut modifier ni le montant ni le destinataire, il ne détient jamais les fonds, et il ne peut pas prétendre avoir réglé puisque la preuve est une signature vérifiable publiquement. Il peut en revanche refuser de régler, ce qui en fait une dépendance de disponibilité à déclarer dans son architecture.

Ce guide est à visée informative, sans conseil en investissement. Crypto Deep Research distingue le fait, l'annonce et la projection, et cite ses sources primaires. Méthode et charte d'indépendance accessibles librement sur le site.