Coinbase pousse x402 vers la neutralité Stripe parie des deux côtés en dehors du MPP

Auteur : Charlie Liu, associé chez Generative Ventures

Ces derniers temps, je vois de plus en plus de personnes s’intéresser à l’agentic commerce, mais toutes les différentes protocoles et tous les différents acteurs donnent de plus en plus de mal à tout le monde pour s’y retrouver.

Surtout la semaine dernière : tout le monde était encore en train de se familiariser avec le MPP de Stripe / Tempo, et en un clin d’œil Stripe a finalement rejoint le x402 Foundation, le projet de son concurrent Coinbase.

Et en plus, Cloudflare prend désormais en charge les deux. Google est aussi dans la partie, mais il a aussi ses propres AP2 et UCP.

Visa, Mastercard aussi sont arrivés, mais clairement pas pour servir de vitrine aux stablecoins.

Linux Foundation a publiquement défini x402 comme un « QG » neutre, gouverné par l’ensemble de l’industrie. De son côté, Cloudflare a explicitement intégré à la fois x402 et MPP dans son Agents SDK. Stripe, elle aussi, a écrit publiquement qu’elle prend en charge à la fois MPP et x402.

Au final, qui est en concurrence avec qui, et qui s’additionne avec qui ?

Mais plus je regarde ces jours-ci, plus je me dis que ce “désordre” ne vient pas du fait que le marché n’ait pas de direction. C’est plutôt parce que le marché est déjà très clair. Et comme je l’ai mentionné plus tôt : dès le premier jour, cette affaire ne sera pas unifiée en une seule fois par un protocole.

C’est davantage comme un cas très courant dans les infrastructures d’internet : différentes couches évoluent en parallèle, différentes entreprises parient sur des couches différentes, et finalement tout est lancé d’abord grâce à l’interopérabilité.

La véritable histoire stratégique, c’est : qui définit la couche de contrôle par défaut de paid machine access dans l’agentic web ? Et les acteurs clés misent clairement sur le multi-home, parce que tout le monde parie encore sur le fait que le véritable goulot d’étranglement futur se trouvera sur l’autorisation, la distribution ou le règlement.

I. Pourquoi Coinbase a laissé x402 Foundation à Linux ?

Si x402 n’était que le protocole de Coinbase, il lui serait difficile de devenir un choix par défaut de l’industrie.

Ce n’est pas une phrase politiquement correcte : c’est une logique de standardisation très concrète.

Le communiqué de Linux Foundation est très clair : il met l’accent sur la neutralité des fournisseurs de services, la gouvernance communautaire, et la mutualisation de l’infrastructure, plutôt que sur le fait qu’« une entreprise a publié une nouvelle fonctionnalité ».

Et surtout, la page de x402 Foundation indique encore aujourd’hui que le projet est en phase de construction : les mécanismes de gouvernance et le conseil d’administration sont encore en train d’être mis en place.

Autrement dit, cette action n’annonce pas d’abord « le produit est mûr », mais plutôt « nous allons donner à ce protocole une maison neutre ».

Derrière ce message implicite, c’est assez simple.

Si x402 continue de grandir avec une face de “fonctionnalités produit Coinbase” (par exemple, Base pour l’instant), alors les fournisseurs cloud, les sociétés de paiement, les organisations de cartes et les acteurs “plateforme” hésiteront politiquement même s’ils seraient techniquement disposés à s’y connecter.

Personne ne veut confier la couche future de paid access à une seule plateforme. Mettre x402 sous Linux Foundation n’est pas parce que Coinbase ne veut pas contrôler ; au contraire, c’est parce que Coinbase veut au maximum une adoption large de x402, et doit donc d’abord retirer la charge : « c’est le protocole de Coinbase ».

Ce point est important, parce que beaucoup de gens voient des actions de type fondation comme un PR ou une posture open source.

Mais dans une guerre de protocoles, la gouvernance fait partie du produit.

Surtout quand une norme est encore à ses débuts, et qu’elle n’a pas encore d’effets de réseau absolument dominants : la soi-disant “confiance neutre” n’est pas moins importante que la finesse technique.

Inversement, si x402 devait vraiment devenir un certain baseline paid access natif HTTP à l’avenir, ce ne serait probablement pas parce que son code est le plus beau, mais parce que** cela a abaissé le coût politique plus tôt que les autres solutions.**

En d’autres termes : ici, la gouvernance n’est pas un rôle secondaire. La gouvernance elle-même est le moteur de croissance.

II. À quoi sert vraiment la “cohabitation” des efforts de Stripe ?

L’acteur à surveiller en priorité, c’est absolument Stripe, parce que ses actions sont celles qui prêtent le plus à confusion.

D’un côté, elle a lancé de façon très médiatisée le MPP le 18 mars, en le présentant comme une norme ouverte pour les paiements de machines.

De l’autre côté, elle est un founding contributor de x402 Foundation, et sa documentation prend elle aussi en charge les x402 machine payments.

La documentation de Cloudflare est plus directe encore : elle écrit explicitement que le cœur des processus de paiement de MPP pour x402 est rétrocompatible, et que le client MPP peut consommer directement les services x402 existants.

Si on regarde uniquement ce cadre “de concurrence entre protocoles”, Stripe donne l’impression de mener des efforts dans deux directions à la fois.

Mais si tu élargis encore un peu la perspective, cette approche a au contraire une logique commerciale très claire.

Car ce que Stripe veut vraiment protéger n’est peut-être pas uniquement le handshake 402 lui-même.

Ce qu’elle veut vraiment protéger, ce sont les couches au-dessus du handshake : credentials, compliance, risk, reporting, tax, refunds, merchant integration.

Stripe ne ressemble pas à une croyante d’un protocole unique. Elle ressemble plutôt à quelqu’un qui s’assure que, quel que soit le standard de handshake qui finit par l’emporter, Stripe reste la couche d’abstraction par défaut pour les agent payments.

Prendre en charge x402, c’est pour ne pas être absent de l’écosystème ouvert ; pousser MPP, c’est pour participer à la définition des sémantiques de base ; et pousser ensuite ACP et Shared Payment Tokens, c’est pour préserver cette couche de valeur plus épaisse : les workflows et les preuves de paiement.

Donc le côté “le plus bizarre” de Stripe, c’est en réalité le plus honnête.

Elle ne fait pas semblant que l’avenir se résumera vite à un seul protocole. Elle te montre par ses actions un message simple : à ce stade, personne ne devrait parier uniquement d’un côté.

III. En réalité, c’est une histoire d’infrastructure B2B

J’ai de plus en plus l’impression que beaucoup de médias déplacent le centre de gravité de cette affaire.

Dès qu’on parle d’agent payments, on pense le plus souvent au retail : l’IA achète des billets d’avion, réserve des hôtels, passe des commandes, gère le checkout.

Mais si tu regardes les scénarios qui sont réellement déjà publiquement déployés et qui commencent vraiment à sentir l’infrastructure, ce n’est d’abord pas le checkout retail qui démarre, c’est un paid access B2B plus ennuyeux, mais plus réel : API payantes, données payantes, outils payants, sessions de navigateur payantes, workflows d’agents payants.

Cloudflare prend désormais publiquement en charge la facturation de contenu HTTP, d’API et de MCP tools avec x402 et MPP.

Le chemin d’adoption le plus fort pour x402 se situe sur les paid APIs et tools developer-to-developer, parce que le “no account + pay-per-request” n’est pas un gadget ici : c’est une implémentation concrète.

Les changements qui se cachent derrière tout ça sont en réalité très importants.

Avant, pour monétiser une API, on devait généralement passer par tout un ensemble de processus “conviviaux pour les humains” : créer un compte, lier la facturation, émettre une API key, définir des limites, rapprocher les comptes, puis gérer les permissions de paiement.

Pour les humains, c’est déjà assez pénible ; pour les agents, c’est encore plus inconfortable.

Le point le plus attirant de x402 n’est pas qu’il soit plus crypto, ni qu’il soit plus AI. C’est qu’il essaie de remettre “l’accès payant” directement dans le HTTP lui-même, afin que le contrôle d’accès et la négociation de paiement se produisent comme pour une requête-response ordinaire.

Le serveur renvoie un 402, te dit combien vaut cette requête ; le client paye ensuite, puis réessaie la même requête en utilisant les preuves de paiement.

Si tu regardes ce modèle sous l’angle des logiciels B2B et de l’accès machine-to-machine, il est bien plus naturel que sous l’angle du retail.

Et plus on se rapproche du B2B, plus les avantages de x402 deviennent évidents, et ses limites deviennent moins cruciales.

Parce que, dans le consumer commerce, les refunds, les refus de paiement, le merchant-of-record, la protection des consommateurs, l’attribution de la responsabilité… tout ce sont des problèmes difficiles. Mais dans les appels d’API et d’outils B2B, ces problèmes perdent nettement en importance.

À l’inverse, le vrai besoin est : “pas de compte, facturation à l’appel, et une fois le résultat obtenu, on s’en va”.

Le retail est plus grand et plus animé, et attire aussi plus facilement l’attention ; mais définir à quoi ressemble réellement un protocole, ce sont souvent les scénarios qui révèlent les vrais besoins tôt, pas forcément les plus bruyants.

Pour cette vague d’agent payments d’aujourd’hui, ce scénario ne sera probablement pas un panier, mais plutôt le paid access entre un nombre croissant de logiciels, entre des agents, et entre des workflows.

IV. Le développement du secteur valide mon jugement précédent sur l’interopérabilité

Le point le plus central de mon article précédent, c’était l’interoperability.

À l’époque, ce jugement avait encore un peu le goût de “devrait être comme ça sur le plan de l’architecture”.

Aujourd’hui, je le vois de plus en plus comme une contrainte réelle, parce que le marché public est déjà en train de voter avec ses pieds.

Cloudflare n’a pas choisi un camp : il prend en charge x402 et MPP simultanément, et a aussi fait des mappings de compatibilité explicitement.

Google, d’un côté, participe à x402, et de l’autre continue de pousser AP2 et UCP.

Visa et Mastercard n’ont pas non plus exprimé leur stratégie avec une posture de “all in one winner”. Elles font : d’un côté elles rejoignent x402, de l’autre elles renforcent agent token, l’authentification, la validation d’instructions et les signaux de dispute.

Les paris multilatéraux des géants sont des décisions rationnelles, pas de l’hypocrisie commerciale.

Pourquoi est-ce que ça arrive ? Parce que ces protocoles ne sont tout simplement pas de la même couche.

Au moins pour l’instant, x402 et MPP se rapprochent davantage de la couche de paid HTTP handshake : ils traitent “comment faire remonter une capacité de paiement dans la requête”.

AP2 se rapproche davantage de l’autorisation et des intentions dignes de confiance : il traite “est-ce que cet agent a vraiment la capacité autorisée à dépenser cet argent”.

UCP et ACP ressemblent plutôt à une couche de workflow : elles gèrent des problèmes plus haut niveau comme la discovery, le checkout, les relations marchands, et le partage de preuves.

Beaucoup d’entreprises prennent en charge x402, MPP, AP2, UCP non pas parce qu’elles ne savent pas ce qu’elles font, mais parce que** gagner à la fin implique probablement une architecture qui traverse plusieurs couches, voire qui nécessite plusieurs protocoles ensemble pour se compléter.**

Donc si l’on résume en une phrase mon jugement précédent, je suis encore plus convaincu qu’en l’absence d’interopérabilité, cet écosystème ne se mettrait tout simplement pas en place.

Et à présent, on voit que le marché valide activement ce jugement.

Plus loin : ce jugement est aussi important pour B2B vs retail.

Dans le monde retail, peut-être qu’à la fin, quelques grandes plateformes et quelques gros workflows vont vraiment tout aspirer ; mais le monde B2B n’est pas comme ça.

Les entreprises vivent de toute façon dans la réalité : multi-cloud, multi-modes de paiement, multi-systèmes de workflows, multi-systèmes d’identités et d’autorisations.

Celui qui essaie de tout reconstruire en remplaçant l’ensemble du stack de l’entreprise par un seul nouveau protocole risque fort de mourir en premier.

En B2B, ce que les clients sont réellement prêts à payer n’est pas “un protocole unique correct”, mais plutôt “la capacité à faire fonctionner les systèmes existants dans un environnement multi-protocoles”.

Et cette logique rend l’interopérabilité plus “dure” en contexte entreprise que dans le contexte consumer.

V. Ce n’est pas juste une concurrence de protocoles : c’est une concurrence de stack une fois les couches séparées

Dès que tu comprends cette affaire comme un stack en couches, beaucoup de phénomènes qui semblaient confus s’alignent instantanément.

La couche la plus basse, c’est paid access handshake.

Cette couche se préoccupe de : comment une requête HTTP exprime “ici, il faut payer”, et comment le client ramène les preuves de paiement une fois le paiement effectué.

x402 et MPP se disputent principalement ici. MPP essaie d’englober 402 dans des sémantiques d’authentification HTTP plus formelles ; x402 ressemble davantage à une “plateformisation” de 402 : via des headers personnalisés, un facilitator, une abstraction du règlement on-chain et une intégration d’écosystème, pour lui permettre de démarrer.

Une trajectoire plutôt sémantique et standardisée, et une autre plutôt orientée distribution de plateforme.

La couche suivante, c’est authority to spend, autrement dit : qui a autorisé cette dépense.

C’est là que beaucoup de gens ne réalisent pas encore pleinement l’importance.

Oui, les machines peuvent payer : ce n’est pas si difficile. Mais réussir à autoriser de manière fiable une machine à payer, c’est ça qui est vraiment dur.

AP2 est important justement parce qu’il ne traite pas seulement “comment payer”, mais résout aussi mandates, verifiable credentials, authenticity, accountability.

Les agent tokens, instruction validation, passkeys et dispute signals renforcés récemment par Visa et Mastercard, au fond, traitent aussi de ce point.

La couche au-dessus suivante, c’est workflow et distribution.

C’est discovery, checkout, relation marchand, partage de credentials, intégration de l’AI à la surface… des sujets plus proches de “qui contrôle le flux et l’orchestration des transactions”.

UCP et ACP se disputent cette couche.

Pour le B2B, à court terme, elle n’est peut-être pas aussi excitante ; mais à long terme, sa valeur peut être très élevée.

Parce que si, à l’avenir, un nombre croissant de logiciels d’entreprise sont coordonnés, appelés, achetés et payés par des agents, alors celui qui maîtrise le workflow language ne fait pas qu’orchestrer un paiement : il orchestre tout le workflow.

Une fois ces trois couches séparées, tu découvres un fait très simple : il n’y a aucune raison de s’attendre à ce qu’un protocole englobe tous les problèmes.

Le chemin le plus réaliste, c’est : ces trois couches grandissent chacune de leur côté au début, puis elles s’emboîtent progressivement grâce à l’interopérabilité.

Et c’est exactement pour ça que les paris multiples ne sont pas un signe d’hésitation : c’est rationnel.

VI. Le risque réel de x402 n’est peut-être pas la régulation : c’est l’économie en cas de concurrence

Si on s’arrête seulement à la compréhension de “des protocoles coexistent”, ce n’est pas encore assez profond.

Le plus grand risque de x402 n’est peut-être pas d’abord la régulation. C’est possiblement l’économie “verify–settle” en deux étapes, donc l’économie du time-of-check/time-of-use.

Dit simplement : si la vérification du paiement et le règlement final ne sont pas la même chose, alors dans des environnements internet réels comme le haut parallélisme, les retries, la couche agents, la couche cache, il existe une fenêtre “pay once, access multiple times”.

L’écosystème x402 essaie aujourd’hui aussi de colmater des trous : settlement cache, idempotency extension, payment identifier… mais le fait même qu’on doive “colmater” montre que ce n’est pas un problème théorique.

Pourquoi ce point mérite particulièrement l’attention des lecteurs B2B ?

Parce que dans le B2B, ce que le monde craint le plus n’a jamais été “de jolis demos qu’on n’arrive pas à faire”. C’est plutôt “trop d’edge cases”, puis ça commence à fuir dès qu’on passe en production.

Avec la monétisation d’API, en surface, on dirait que c’est juste quelques centimes à chaque requête : c’est léger. Mais si votre produit est facturé par appel, par résultat, ou par workflow, alors “payer une fois pour obtenir une fois” versus “payer une fois pour obtenir plusieurs fois”, ce n’est plus un détail produit : c’est une ligne de vie.

Donc si x402 devait vraiment émerger en B2B à l’avenir, un prérequis important ne serait pas le narrative, mais le fait que ces mécanismes par défaut “sûrs” doivent être implémentés de manière suffisamment automatique, sans prise de tête. Sinon, les entreprises ne mettront pas volontiers leur trafic réel dans le système.

VII. Les protocoles peuvent être gratuits, mais les postes de péage ne disparaîtront pas

Il y a encore un autre point qui, je pense, mérite d’être clarifié dans cet article.

Beaucoup de protocoles ouverts finissent par arriver à un endroit très familier : le protocole lui-même devient de plus en plus cheap, voire gratuit, mais les vrais postes de péage apparaissent à côté.

x402 n’y échappe pas.

Le standard met bien sûr l’accent sur l’ouverture, la neutralité, et l’absence de 0 fees built into the standard, mais ça ne signifie pas que value capture va disparaître.

Si x402 réussit, la valeur ne restera pas principalement dans le protocole ; elle migrera vers des couches adjacentes : facilitator, wallets et key management, discovery, policy engine, trust wrapper.

C’est particulièrement important pour le B2B.

Parce que les clients d’entreprise ne vont pas payer pour qu’on leur transforme massivement l’ensemble de leur stack juste pour un nouveau protocole. Ce qu’ils sont vraiment prêts à payer, c’est celui qui peut les aider à régler, dans un environnement multi-protocoles, toutes ces tâches pénibles : orchestration, policy, risk, compliance, audit, settlement, frontières d’autorisations.

Autrement dit : le protocole ressemblera de plus en plus à un langage de bas niveau, mais la couche qui traduit ces langages en capacité “sûre pour déployer en entreprise” a au contraire plus de chances de devenir une nouvelle plateforme, et un nouveau poste de péage.

C’est aussi pour ça que je me dis que, quand on regarde x402 aujourd’hui, il ne faut pas seulement se focaliser sur qui ressemble le plus au “protagoniste” : Coinbase, Cloudflare ou Stripe.

Ce qui mérite d’être surveillé, ce sont ceux qui ont le plus de chances de se placer sur ces couches adjacentes.

Cloudflare a une position sur la périphérie et sur la distribution de trafic ; Stripe a une position sur l’infrastructure de paiements et sur les relations marchands ; Visa et Mastercard ont une position sur les credentials, les network tokens et la confiance des consumers ; Google a une position sur le workflow et la surface de discovery.

La véritable capture de valeur ne se produira pas forcément au moment où “qui définit 402”. Elle se produira plus probablement au moment où “qui intègre 402 dans un système d’entreprise plus large”.

VIII. Conclusion

Le sujet x402 Foundation n’est pas une annonce selon laquelle x402 aurait déjà vaincu tous les protocoles d’agentic commerce.

C’est une reconnaissance publique : dès le premier jour, cette génération d’agent payments ne sera pas un monde à protocole unique.

Le fait que Coinbase confie x402 à Linux Foundation, c’est pour qu’il ressemble davantage à une couche publique neutre, plutôt qu’à un produit exclusif.

Stripe pousse MPP tout en rejoignant x402 : ce n’est pas une hésitation, mais parce qu’elle sait qu’à l’heure actuelle, il ne faut pas parier seulement d’un côté.

Cloudflare supporte les deux : parce qu’elle est la plus proche du trafic réel.

Les actions de Google, Visa, Mastercard, Adyen, etc., montrent aussi toutes la même chose : d’abord rendre le système interopérable, puis discuter qui occupera finalement quelle couche.

Et si on déplace la perspective en dehors du retail, ce jugement devient encore plus fluide.

Parce qu’en premier, les protocoles ne seront peut-être pas nécessaires par un panier. Ils seront nécessaires par de plus en plus de logiciels et services B2B facturés à l’appel, à la tâche, et au résultat.

Le retail est bien plus grand, mais en B2B, ce sont souvent des besoins réels qui se révèlent plus tôt, et qui définissent aussi plus tôt à quoi ressemblera la dernière infrastructure.

Dans mon article précédent, j’ai placé l’interoperability au centre. Et je pense que, maintenant, la réponse donnée par le marché est très claire : oui, et même plus tôt que je ne le pensais à l’époque.

En ce sens, x402 Foundation n’est pas la fin de cette histoire.

C’est juste quelque chose qui nous fait voir plus tôt que le vrai thème n’a jamais été “qui va gagner”, mais plutôt “ce monde est destiné à être interconnecté d’abord, et qui pourra occuper la couche la plus précieuse une fois l’interopérabilité acquise”.