Note de la rédaction : Sur la question du paiement par les Agents, x402 et MPP proposent deux approches presque opposées.
x402 opte pour la minimalisme protocolaire : intégrer le paiement directement dans la requête HTTP, réalisant le paiement à la requête de la manière la plus simple. Pas de comptes, pas d'intermédiaires, un design plus proche de l'ouverture et du sans-permission de l'Internet早期, adapté aux développeurs de la longue traîne et aux scénarios décentralisés.
MPP, quant à lui, est la maximalisation systémique : il résout les problèmes de transactions haute fréquence, de gestion des risques et d'intégration des monnaies fiduciaires grâce aux sessions, aux paiements en flux (streaming payments) et à un système de conformité. Il ne recherche pas la pureté, mais priorise la satisfaction des besoins commerciaux réels, plus adapté aux applications d'entreprise et à grande échelle.
Leur différence est essentiellement deux solutions à un même problème : faut-il faire du paiement une partie du protocole, ou une couche du système ?
C'est aussi pourquoi ils ne sont pas vraiment en concurrence, mais plutôt répartis sur différents segments : x402 couvre les besoins de la longue traîne des réseaux ouverts, MPP prend en charge le trafic commercialisé et à haute fréquence. Dans une économie des Agents encore naissante, cette différenciation est peut-être inévitable.
Voici l'article original :
Le code d'état HTTP 402, défini dans la spécification HTTP/1.1 à la fin des années 1990, attendait simplement un cas d'utilisation. Sa signification est "Paiement Requis". L'idée initiale était d'intégrer la capacité de paiement dans la couche protocolaire du Web, permettant aux machines d'acheter des ressources comme elles demandent une page web.
Mais cette vision est largement restée lettre morte. Au fil des ans, ce code d'état n'est apparu que dans quelques scénarios marginaux, comme les réponses de limitation de débit (rate limiting) de Shopify, les erreurs de facturation d'Apple Mobile Me, mais personne n'a jamais vraiment construit le futur des micro-paiements qu'il sous-entendait. À la place, nous avons eu les cartes de crédit, les paywalls par abonnement, et les mécanismes de clés API, systèmes conçus essentiellement pour des humains qui interagissent manuellement.
Aujourd'hui, deux voies de mise en œuvre concurrentes de ce futur sont apparues, et publiées le même jour. Je vais tenter d'expliquer ce qu'elles sont, leurs différences, et pourquoi Stripe parie sur les deux voies simultanément.
x402 : Une solution plus simple
Coinbase a officiellement lancé x402 en mai 2025. Son idée centrale est presque radicalement minimaliste. Un client demande une ressource ; le serveur renvoie un HTTP 402, en informant le client : combien payer, quelle crypto-monnaie utiliser, sur quelle blockchain effectuer le paiement. Le client effectue le paiement sur la blockchain, puis relance sa requête en y joignant la preuve de paiement, le serveur délivre alors la ressource.
C'est aussi simple que cela. Pas de système de comptes, pas de clé API, pas de mécanisme d'abonnement. Juste un aller-retour de requête HTTP, avec un paiement inséré au milieu.
Aujourd'hui, Stripe prend en charge nativement x402 dans son système de paiement, permettant aux marchands de recevoir directement ce type de paiement via leur backoffice existant. Cependant, fondamentalement, x402 reste un protocole mené par Coinbase, dont la gouvernance est assurée par la x402 Foundation, co-fondée par Coinbase et Cloudflare en septembre 2025. Le protocole est entièrement open source (licence Apache 2.0) et fournit des SDK en TypeScript, Go, Python et autres langages.
En termes de support, la documentation officielle de Coinbase indique qu'il supporte actuellement les paiements ERC-20 sur Base, Polygon et Solana. Parallèlement, l'écosystème explore son extension à d'autres blockchains comme Avalanche, Sui et Near, mais avec des niveaux de maturité variables.
En ce qui concerne l'adoption, les données sont un peu plus complexes. Coinbase indique que x402 a traité plus de 50 millions de transactions via son infrastructure Agentic Wallet. Cela semble impressionnant, mais selon CoinDesk le 11 mars, citant les données d'analyse on-chain d'Artemis : le volume quotidien est d'environ 131 000 transactions, pour un montant total d'environ 28 000 dollars, le paiement moyen étant d'environ 0,20 dollar, dont environ la moitié semble être des tests ou des comportements gamifiés plutôt que de réelles transactions commerciales.
Mais ce n'est pas forcément une mauvaise chose. Car ce protocole est précisément conçu pour un marché qui n'existe pas encore vraiment : un monde où les agents IA effectuent des micro-paiements (même inférieurs à 1 centime) pour des appels API et des requêtes de données. Et les marchands desservant ce marché commencent tout juste à émerger.
Par exemple, le Agentic Payments Protocol (AP2, faisant partie du framework A2A) de Google a intégré x402 ; Lowe's Innovation Labs a présenté un démo : un agent IA pouvant dans un seul flux découvrir un produit, faire des recherches et passer commande. Aussi, World (lancé par Sam Altman) a publié cette semaine AgentKit, ajoutant des capacités de preuve d'identité humaine au portefeuille x402.
L'hypothèse centrale est : rendez le paiement aussi léger qu'une requête HTTP, et les cas d'usage émergeront naturellement. Reste à voir si cela se vérifiera.
MPP : La solution full-stack
Stripe et Tempo ont choisi un chemin différent. Le Machine Payments Protocol (MPP) a été publié aujourd'hui, coïncidant avec le lancement du mainnet de Tempo. Contrairement à x402, qui est une couche légère construite sur des blockchains existantes, MPP est conçu spécifiquement pour le scénario des agents intelligents à transactions haute fréquence.
Son mécanisme central est les sessions. Au lieu de lancer une transaction on-chain à chaque demande de ressource, un agent peut d'abord autoriser une fois pour toutes un plafond de dépense, puis effectuer des micro-paiements continus dans cette limite. Si vous êtes une IA qui doit interroger des milliers de sources de données par heure, vous ne voulez pas signer et diffuser une transaction on-chain à chaque fois, et les sessions résolvent précisément ce problème.
La blockchain Tempo est également construite autour de ce besoin. Elle supporte des dizaines de milliers de transactions par seconde, avec des temps de confirmation inférieurs à la seconde, et n'a pas de jeton gas natif. Les utilisateurs peuvent payer les frais directement avec des stablecoins, évitant ainsi l'étape fastidieuse d'acheter un jeton aléatoire juste pour effectuer un transfert.
Un autre composant à comprendre : le Agentic Commerce Suite de Stripe inclut les Shared Payment Tokens (SPTs). Ce n'est pas une partie intrinsèque de MPP, mais un mécanisme d'extension de Stripe qui peut fonctionner avec lui. Les SPT permettent à un agent de transmettre de manière sécurisée les identifiants de carte bancaire ou de portefeuille de l'utilisateur au marchand sans exposer les données réelles. Ces identifiants sont limités à une transaction unique et ont une durée de vie limitée, on peut les considérer comme des autorisations programmables et auto-destructrices. En pratique, cela signifie qu'un agent payant via MPP peut utiliser soit l'USDC sur Tempo, soit la carte Visa liée à l'utilisateur, voire une combinaison des deux.
Selon le blog annonçant le lancement du mainnet de Tempo, ses partenaires incluent Anthropic, DoorDash, Mastercard, Nubank, OpenAI, Ramp, Revolut, Shopify, la Standard Chartered et Visa. The Block rapporte quant à lui que le répertoire de paiement MPP comptait déjà plus de 100 services au lancement, incluant Alchemy, Dune Analytics, Merit Systems et Parallel Web Systems. Matt Huang, co-fondateur de Tempo et de Paradigm, a déclaré dans un entretien avec Fortune que ce domaine en est encore à ses débuts, et que la conception du MPP vise à pouvoir à l'avenir s'étendre au-delà de Tempo vers davantage d'environnements blockchain.
Pourquoi Stripe supporte les deux
Si vous êtes déjà intégré à Stripe, la réponse la plus pratique est : vous n'avez pas à choisir.
Stripe prend en charge x402 et MPP via deux voies d'intégration distinctes, plutôt que de les abstraire en une interface unifiée. Pour x402, sa documentation couvre principalement la génération d'adresses de recharge, la surveillance on-chain et le processus de règlement des fonds vers le compte Stripe – vous vous chargez de renvoyer la réponse 402, l'infrastructure de paiement crypto sous-jacente est gérée par Stripe. Support actuel pour l'USDC sur Base, extension future prévue. Pour MPP, les marchands peuvent utiliser la même API PaymentIntents pour recevoir des paiements en flux basés sur des sessions.
Le Agentic Commerce Suite de Stripe, publié en décembre 2025, est construit au-dessus de ces deux rails de paiement. Le marchand upload simplement son catalogue produits, choisit les agents IA qu'il souhaite intégrer, et Stripe s'occupe de la découverte des produits, du processus de checkout, de la antifraude et du traitement fiscal. Actuellement, URBN, Etsy, Coach, Kate Spade et Ashley Furniture l'utilisent déjà, et des plateformes comme Wix, WooCommerce, BigCommerce, Squarespace et commercetools sont déjà intégrées.
Sa stratégie est en réalité très claire : contrôler la couche d'abstraction, et laisser les protocoles sous-jacents concourir librement.
Comparaison
Macroscopiquement, ces deux protocoles font la même chose : permettre aux machines de payer des ressources via HTTP. Mais la vraie différence réside dans les détails.
x402 (mené par Coinbase) vs MPP (Stripe + Tempo)
Standardisation
x402 : Entièrement open source (Apache 2.0), promu par la x402 Foundation pour une participation multipartite (Coinbase, Cloudflare, Visa, Google).
MPP : Standard ouvert, défini conjointement par Stripe et Tempo, fait partie du Stripe Agentic Commerce Suite.
Mécanisme HTTP
x402 : Ressuscite HTTP 402, initie la demande via l'en-tête PAYMENT-REQUIRED, utilise PAYMENT-SIGNATURE pour la nouvelle tentative.
MPP : Utilise également un mécanisme challenge-response, mais avec le Payment HTTP Authentication Scheme (brouillon IETF), liant l'ID du challenge via HMAC.
Infrastructure de paiement (Rails)
x402 : Conçu pour être indépendant de la blockchain, support actuel sur Base, Polygon, Solana, exploration sur d'autres blockchains en cours.
MPP : Basé sur la blockchain Tempo – un L1 optimisé pour les paiements, supportant 10k+ TPS, confirmation en moins d'une seconde, pas de jeton gas natif ; objectif à long terme : compatibilité cross-chain.
Méthodes de paiement
x402 : Uniquement stablecoins, entièrement on-chain.
MPP : Supporte l'USDC sur Tempo + SPT (mécanisme Stripe), permettant un hybride crypto/monnaie fiduciaire (cartes bancaires, portefeuilles, BNPL).
Mode de règlement
x402 : Règlement on-chain (environ 200ms à quelques secondes), validation et règlement assurés par des facilitateurs comme Coinbase.
MPP : Confirmation en moins d'une seconde sur Tempo, comptabilisation automatique et traitement de la conformité par Stripe.
Intégration marchand
x402 : Middleware open source (Express, Hono, Next.js, etc.), possibilité de construire soi-même ou d'utiliser un facilitateur.
MPP : Intégration directe à l'API PaymentIntents de Stripe, gestion des risques, taxes, remboursements, reporting tout inclus.
Innovation clé
x402 : Simplicité extrême, sans lien avec un fournisseur, philosophie proche d'Unix pour les paiements.
MPP : Haut débit + fusion fiduciaire, paiements en flux et agrégation de micro-paiements via les sessions, et contrôle des dépenses programmable basé sur les SPT.
Partenaires clés
x402 : Coinbase, Cloudflare, Google (A2A/AP2), Visa, World, Anthropic (MCP).
MPP : Stripe, Visa, Lightspark, Anthropic, DoorDash, Mastercard, OpenAI, Shopify, Revolut, Standard Chartered.
x402 ressemble plus au choix privilégié lorsque vous construisez un système ouvert : API pour développeurs indépendants, marché de données décentralisé, ou tout service ne souhaitant pas dépendre d'un processeur de paiement. Sa spécification tient dans un livre blanc, l'intégration ne nécessite qu'un middleware et une adresse de portefeuille. Cette pureté est attractive – bien que la limitation au pur crypto signifie aussi que son public est plus restreint.
MPP est un paradigme totalement différent. Si votre agent doit effectuer des centaines, voire des milliers de transactions en une seule session, sans vouloir passer sur la chaîne à chaque fois, alors c'est le choix le plus raisonnable. Le mécanisme de session garde la plupart des interactions hors chaîne jusqu'au règlement final ; le système de conformité de Stripe s'occupe de la gestion des risques et des taxes ; et le mode hybride SPT permet à l'agent de ne pas se limiter aux stablecoins, mais d'utiliser directement les modes de paiement de l'utilisateur comme Visa. Il est moins élégant, mais plus proche de la réalité.
Il est intéressant de noter qu'ils ne sont pas vraiment en concurrence. x402 couvre les scénarios ouverts de longue traîne, MPP couvre le trafic d'entreprise à haute fréquence. La stratégie de Stripe est également très claire : ne pas parier sur un seul protocole, mais s'assurer que, quelle que soit la voie qui l'emporte, les fonds finissent dans le système de comptes de Stripe.
La réalité : Où en est-on vraiment ?
Pour être honnête, il n'y a pratiquement pas encore de transactions à grande échelle.
Selon les informations de lancement de x402 par Coinbase, les premiers partenaires incluent Hyperbolic (paiement pour l'inférence GPU) et Anthropic (intégration du protocole MCP). Le blog de Stripe mentionne des scénarios d'agents payants par appel API (par exemple CoinGecko). Le répertoire de Tempo comptait 100+ services au lancement. Le SDK Agents de Cloudflare supporte nativement x402, et quelques petits projets sur Base L2 essaient d'utiliser x402 comme passerelle de paiement.
Mais globalement : le volume de transactions est faible, le nombre de marchands est limité, la plupart des activités en sont encore au stade expérimental.
Ce n'est pas vraiment surprenant. Toute nouvelle infrastructure de paiement est ainsi au début. Les listes de partenaires peuvent parfois masquer un écart entre la signature d'une lettre d'intention et une mise en production effective, et ces annonces ne font généralement pas la distinction.
Il est plus pertinent de regarder les acteurs poids lourds derrière l'infrastructure. Stripe a traité 1,9 billion de dollars de paiements en 2025, avec une croissance totale de 34%. Parallèlement, Coinbase, Cloudflare, Visa, Google, ainsi que tout le réseau de partenaires de Tempo sont entrés dans la danse.
En d'autres termes, les rails sont posés. Il ne reste qu'une question : en 2026, les agents IA auront-ils vraiment besoin d'effectuer des transactions massives sur ces rails ? Ou est-ce plus comme poser de la fibre optique en 1998 – le besoin n'est pas encore là, mais l'infrastructure est prête.
Alors, lequel choisir ?
Si vous construisez un système ouvert, sans permission – x402 est le choix le plus naturel. Pas d'inscription sur une plateforme, pas d'intégration avec un processeur, importez un middleware, liez une adresse de portefeuille et recevez des paiements. Le prix à payer : la conformité, la gestion des risques, le règlement en monnaie fiduciaire sont à votre charge.
Si vous êtes déjà dans l'écosystème Stripe et souhaitez capter le trafic des agents – MPP est plus adapté. Les sessions, les paiements en flux, l'hybride fiduciaire+crypto, et le système complet de conformité, c'est essentiellement une mise à niveau de configuration, pas une refonte du système.
Si vous ne vous souciez que d'une chose : peu importe le protocole utilisé par l'agent, je veux pouvoir être payé. Alors la réponse est simplement : utilisez Stripe. Il supporte les deux.
Le HTTP 402 est enfin utile. Il aura simplement attendu environ 27 ans.
