Coinbase pousse x402 vers le neutre, tandis que Stripe continue de miser sur les deux côtés en dehors du MPP

Auteur : Charlie, responsable d'OSL Americas, partenaire de venture @ Generative Ventures. Ancien vice-président de la licorne de cryptomonnaies Strike (impliqué dans la loi sur le btc-42">Bitcoin d'El Salvador et responsable du réseau Bitcoin Lightning et des activités de paiement de stablecoin en Amérique latine), analyste macro et monétaire chez Franklin Templeton, un fonds de plusieurs milliards de dollars, et membre fondateur d'Adyen, un géant mondial des paiements.

L'article reflète les opinions personnelles de l'auteur et ne représente pas les positions des sociétés concernées.

Récemment, de plus en plus d'amis ont commencé à prêter attention au commerce agentic, mais les différents protocoles et acteurs sont devenus de plus en plus confus.

En particulier la semaine dernière, alors que tout le monde était occupé à comprendre le MPP de Stripe/Tempo, Stripe a rejoint de manière inattendue la fondation x402 du concurrent Coinbase.

De plus, Cloudflare prend désormais en charge les deux systèmes. Google est également impliqué, mais il a son propre AP2 et UCP.

Visa et Mastercard ont également rejoint le groupe, mais ils ne sont clairement pas là pour soutenir les stablecoins.

La Fondation Linux définit publiquement x402 comme un « camp de base » neutre, co-géré par l'industrie, tandis que Cloudflare a explicitement inclus à la fois x402 et MPP dans son propre Agents SDK, et Stripe a également déclaré publiquement qu'il prend en charge à la fois MPP et x402.

Qui est en concurrence avec qui, et qui se chevauche avec qui ?

Cependant, plus j'y réfléchis ces derniers temps, plus j'ai l'impression que ce « chaos » ne vient pas du fait que le marché manque de direction, mais parce que le marché est déjà très clair. Comme je l'ai mentionné précédemment dans x402, nous aurions peut-être mal compris son intention originale : dès le premier jour, cette question ne serait pas unifiée par un seul protocole en une seule fois.

Cela ressemble à une situation courante dans l'infrastructure Internet : différentes couches se développent simultanément, différentes entreprises misent sur différentes couches, et finalement, l'interopérabilité fera fonctionner le tout.

La véritable histoire stratégique concerne qui définira la couche de contrôle par défaut pour l'accès machine payant sur le web agentic ; et les acteurs clés sont clairement en multi-homed, car tout le monde mise encore sur l'endroit où le véritable goulot d'étranglement se produira : l'autorisation, la distribution ou le règlement.

1. Pourquoi Coinbase a-t-elle cédé la Fondation x402 à Linux ?

Si x402 n'était qu'un protocole de Coinbase, il serait difficile de devenir l'option par défaut de l'industrie.

Ce n'est pas une déclaration politiquement correcte, mais plutôt une logique de standardisation réaliste.

La déclaration de la Fondation Linux est cette fois très claire : elle met l’accent sur la neutralité des fournisseurs de services, la gouvernance communautaire et l’infrastructure partagée, plutôt que sur « une certaine entreprise a lancé une nouvelle fonctionnalité de produit ».

Plus crucialement, la page de la Fondation x402 indique actuellement que le projet est en phase de mise en place, et que le mécanisme de gouvernance et le conseil d’administration sont encore en cours de construction.

En d’autres termes, cette action n’annonce pas principalement « le produit est mature », mais plutôt « nous voulons donner à ce protocole un foyer neutre ».

L’implication sous-jacente est assez simple.

Si x402 continue de porter le visage d’une fonctionnalité de produit Coinbase (comme Base actuel), alors les fournisseurs de services cloud, les sociétés de paiement, les organisations de cartes et les acteurs de plateformes, même s’ils sont techniquement prêts à l’adopter, hésiteront politiquement.

Personne ne veut céder la future couche d'accès payante à une seule plateforme. La placer sous la Fondation Linux n'est pas parce que Coinbase ne veut pas la contrôler ; c'est précisément parce qu'elle veut que x402 soit largement adopté qu'elle doit d'abord supprimer le fardeau de « c'est le protocole de Coinbase ».

Ce point est en fait très important car beaucoup de gens considèrent des actions comme celles de la fondation comme de simples gestes de relations publiques ou open-source.

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

Surtout lorsqu'un standard en est encore à ses débuts et manque d'effets de réseau absolus, le soi-disant « neutre et digne de confiance » n'est pas moins important que l'élégance technique.

À l'inverse, si x402 peut effectivement devenir une sorte de référence d'accès payant natif HTTP à l'avenir, c'est probablement parce qu'il a réduit les coûts politiques plus tôt que d'autres solutions, et non parce que son code est le plus beau.

En d'autres termes, la gouvernance n'est pas un rôle de soutien ici ; la gouvernance est elle-même un moteur de croissance.

2. Que fait vraiment la stratégie double de Stripe ?

Le protagoniste à surveiller cette fois est certainement Stripe, car ses actions sont les plus déroutantes.

D'une part, il a lancé MPP avec grande pompe le 18 mars, en le présentant comme un standard ouvert pour les paiements automatiques.

D'autre part, elle est un contributeur fondateur de la Fondation x402 et sa propre documentation prend également en charge les paiements automatiques x402.

La documentation de Cloudflare est encore plus directe, indiquant explicitement que MPP est rétrocompatible avec le processus de paiement principal de x402, et que les clients MPP peuvent consommer directement les services x402 existants.

Si l'on se contente de voir cela à travers le prisme de la « concurrence des protocoles », Stripe semble s'engager dans une stratégie double.

Mais si vous élevez un peu votre perspective, cette approche a en réalité le plus de sens commercial.

Parce que ce que Stripe veut vraiment protéger, ce n'est pas juste la poignée de main 402 elle-même.

Ce qu'il souhaite véritablement protéger, ce sont les couches au-dessus de la poignée de main : les identifiants, la conformité, le risque, la déclaration, la fiscalité, les remboursements, l'intégration des commerçants.

Stripe ne semble pas être un véritable croyant en un seul protocole ; il semble plutôt veiller à ce que, quel que soit le standard de poignée de main qui finira par prévaloir, Stripe reste la couche d'abstraction par défaut pour les paiements des agents.

Soutenir x402, c'est s'assurer de participer à l'écosystème ouvert ; pousser MPP, c'est aider à définir la sémantique sous-jacente ; et promouvoir davantage ACP et les jetons de paiement partagés, c'est protéger la couche de valeur plus épaisse des flux de travail et des identifiants de paiement.

Ainsi, l'aspect le plus « étrange » de Stripe cette fois est en fait son aspect le plus honnête.

Il ne prétend pas que l'avenir se réduira rapidement à un seul protocole. C'est une action qui vous dit : au moins à ce stade, personne ne devrait miser sur un seul côté.

3. C'est en fait une histoire d'infrastructure B2B.

J'ai de plus en plus l'impression que de nombreux médias ont mal ciblé les projecteurs sur cette question.

En ce qui concerne les paiements d'agents, la chose la plus facile à penser est le commerce de détail : L'IA vous aide à réserver des vols, à réserver des hôtels, à passer des commandes et à effectuer le paiement.

Mais si l'on examine les scénarios qui ont réellement été mis en œuvre publiquement et qui ont vraiment un aspect infrastructurel, le premier à décoller n'est pas la caisse enregistreuse, mais plutôt l'accès payant B2B plus banal et réel : API payantes, données payantes, outils payants, sessions de navigateur payantes, flux de travail d'agent payants.

Cloudflare prend désormais ouvertement en charge la facturation du contenu HTTP, des API et des outils MCP en utilisant x402 et MPP.

Le chemin d'adoption le plus solide pour x402 réside dans les API et les outils payants de développeur à développeur, car « compte non existant + paiement à la demande » n'est pas juste un gadget, mais une réalité véritablement opérationnelle.

Les changements qui se cachent derrière sont assez importants.

Dans le passé, la facturation d'une API nécessitait généralement de passer par un ensemble complet de processus « conviviaux » : ouverture d'un compte, liaison de la facturation, émission de clés API, définition de limites, réconciliation, puis gestion des autorisations de paiement.

Pour les humains, cela est déjà assez agaçant ; pour les agents, c'est encore plus gênant.

L'aspect le plus attrayant de x402 n'est pas qu'il soit plus crypto ou plus IA, mais qu'il tente de réinsérer l'« accès payant » dans HTTP lui-même, permettant le contrôle d'accès et la négociation de paiement comme une demande-réponse normale.

Le serveur renvoie un 402, vous indiquant combien coûte cette demande ; le client paie, puis relance la même demande avec la preuve de paiement.

Si vous considérez ce modèle du point de vue des logiciels B2B et de l'accès machine à machine, il fonctionne beaucoup plus en douceur que du point de vue de la vente au détail.

De plus, plus vous vous rapprochez du B2B, plus les avantages de x402 deviennent évidents, et ses lacunes sont moins fatales.

Parce que dans le commerce de détail, les remboursements, les rejets de paiement, le marchand enregistreur, la protection du consommateur et l'attribution de la responsabilité sont tous des problèmes difficiles ; mais dans les appels d'API et d'outils B2B, l'importance de ces problèmes diminue considérablement.

À l'inverse, "pas de compte, paiement à l'appel, obtenez des résultats et partez" est une demande réelle.

Le commerce de détail est certainement plus important, plus dynamique et plus facile à attirer l'attention ; mais les scénarios qui définissent vraiment l'aspect du protocole ne sont souvent pas les plus dynamiques, mais ceux qui exposent d'abord les besoins réels.

Pour l'actuelle vague de paiements d'agents, ce scénario n'est probablement pas le panier d'achat, mais le nombre croissant d'accès payants entre les logiciels, les agents et les flux de travail.

4. Le développement de l'industrie valide mon jugement précédent sur l'interopérabilité

Le jugement central de mon dernier article était l'interopérabilité.

À l'époque, ce jugement ressemblait un peu à « il faudrait le structurer de cette manière ».

Maintenant, cela ressemble de plus en plus à une contrainte de réalité, car le marché ouvert vote déjà avec ses pieds.

Cloudflare n'a pas choisi son camp, mais prend directement en charge à la fois x402 et MPP tout en établissant clairement des correspondances de compatibilité.

Google participe à x402 tout en continuant à faire avancer AP2 et UCP.

Visa et Mastercard n'ont pas non plus exprimé leurs stratégies de manière « gagnant unique » ; au contraire, elles rejoignent toutes les deux x402 tout en continuant à miser sur les jetons d'agent, la vérification d'identité, la validation des instructions et les signaux de litige.

Les paris multilatéraux des géants sont des décisions rationnelles, et non une hypocrisie commerciale.

Pourquoi est-ce le cas ? Parce que ces protocoles ne se trouvent même pas sur la même couche.

Au moins pour l'instant, x402 et MPP sont plus proches de la couche de poignée de main HTTP payante, abordant la question de « comment s'assurer que les demandes reviennent avec la capacité de paiement ».

AP2 est plus proche de l'autorisation et de l'intention digne de confiance, abordant la question de « cet agent a-t-il le droit de dépenser cet argent ? »

UCP et ACP ressemblent davantage à la couche de flux de travail, traitant de la découverte, de la vérification, des relations avec les commerçants et de la transmission des identifiants, des problèmes qui sont plus proches de « qui contrôle l'orchestration du trafic et des transactions ».

De nombreuses entreprises qui prennent en charge x402, MPP, AP2 et UCP simultanément ne le font pas parce qu'elles ne sont pas claires elles-mêmes, mais parce que l'architecture qui l'emporte à la fin est susceptible de s'étendre sur plusieurs couches et peut même nécessiter plusieurs protocoles pour se former ensemble.

Donc, si je devais réfléchir à mon jugement précédent en une phrase, je crois maintenant encore plus fortement que sans interopérabilité, cette vague d'écologie n'aurait pas émergé du tout.

En y regardant de plus près, le marché valide activement ce jugement.

De plus, ce jugement est également important pour le B2B par rapport au commerce de détail.

Car dans le monde du commerce de détail, il peut en effet finir par être absorbé par quelques grandes plateformes et quelques flux de travail majeurs ; mais le monde du B2B n’est pas comme cela.

Les entreprises existent inhéremment dans une réalité où coexistent le multi-cloud, plusieurs méthodes de paiement, plusieurs systèmes de flux de travail et plusieurs systèmes de permission d’identité.

Quiconque tente d’utiliser un nouveau protocole pour réviser complètement l’ensemble de la pile d’entreprise risque d’échouer en premier.

Ce pour quoi les clients B2B sont vraiment prêts à payer n’est souvent pas « le bon protocole », mais la capacité de faire fonctionner les systèmes existants dans un environnement multi-protocole.

Cette logique explique précisément pourquoi l'interopérabilité est plus critique dans les scénarios d'entreprise que dans les scénarios grand public.

5. Il ne s'agit pas simplement d'une compétition de protocoles, mais d'une compétition de pile stratifiée.

Une fois que vous comprenez cette question comme une pile stratifiée, de nombreux phénomènes qui semblaient à l'origine chaotiques prendront immédiatement du sens.

La couche la plus basse est la poignée de main d'accès payant.

Cette couche concerne la manière dont les requêtes HTTP expriment « le paiement est requis ici » et comment le client renvoie les justificatifs de paiement après avoir payé.

x402 et MPP sont principalement en concurrence ici. MPP tente de formaliser 402 dans des sémantiques d'authentification HTTP plus officielles ; tandis que x402 vise davantage à standardiser 402, en utilisant des en-têtes personnalisés, des facilitateurs, des abstractions de règlement en chaîne et une intégration de l'écosystème pour le faire fonctionner en premier.

L'un ressemble davantage à une route sémantique standardisée, tandis que l'autre ressemble à une route de distribution de plateforme.

La couche suivante est l'autorité de dépenser, qui est « qui a autorisé cet argent ».

Cette couche est la clé que beaucoup de gens n'ont pas encore pleinement réalisée.

Les machines qui paient de l'argent ne sont pas si difficiles à mettre en place ; le véritable défi est de garantir que l'on peut faire confiance aux machines pour qu'elles soient autorisées à dépenser de l'argent.

L'AP2 est important précisément parce qu'il ne se contente pas de traiter la question de « comment payer », mais impose également des mandats, des justificatifs vérifiables, l'authenticité et la responsabilité.

Les jetons d'agent, la validation des instructions, les mots de passe et les signaux de litige que Visa et Mastercard ont récemment renforcés relèvent essentiellement de ce niveau.

Le niveau suivant est le flux de travail et la distribution.

Cela inclut la découverte, le paiement, les relations avec les commerçants, le partage de justificatifs et l'intégration de la surface d'IA ; des problèmes qui sont plus proches de « qui contrôle l'orchestration du trafic et des transactions ».

UCP et ACP sont plus en concurrence pour cette couche.

Pour le B2B, cette couche peut ne pas être aussi dynamique à court terme, mais sa valeur à long terme pourrait être très élevée.

Car si de plus en plus de logiciels d'entreprise sont coordonnés, appelés, achetés et payés par des agents à l'avenir, alors celui qui maîtrise le langage du flux de travail ne gère pas juste un seul paiement, mais l'ensemble du flux de travail.

Une fois que vous séparez ces trois couches, vous découvrirez un fait très simple : il n'est pas nécessaire d'attendre qu'un seul protocole couvre tous les problèmes.

Un chemin plus réaliste est que ces trois couches se développent séparément et puis opèrent progressivement de manière interopérable.

Pour cette raison, les paris à têtes multiples ne sont pas une indécision, mais une rationalité.

6. Le véritable risque de x402 ne réside peut-être pas dans la réglementation, mais dans l'économie de la concurrence.

Si nous ne reconnaissons que « la coexistence de plusieurs protocoles », cela ne suffit pas encore.

Le plus grand risque pour x402 ne réside peut-être pas principalement dans la réglementation, mais plutôt dans l'économie du temps de vérification/temps d'utilisation engendrée par le processus de règlement de vérification en deux étapes.

En termes simples, si la vérification du paiement et le règlement final ne sont pas la même chose, alors dans les véritables environnements Internet caractérisés par une forte concurrence, des réévaluations, des couches de proxy et des couches de mise en cache, il y aura une fenêtre pour « payer une fois, accéder plusieurs fois ».

L'écosystème x402 colmate actuellement des trous, tels que la mise en cache des règlements, l'extension d'indépence et l'identifiant de paiement, mais cela indique précisément que le problème n'est pas simplement théorique.

Pourquoi cela vaut-il particulièrement la peine d'être noté pour les lecteurs B2B ?

Parce que ce que le monde B2B craint le plus, ce n'est pas l'incapacité de produire une belle démonstration, mais plutôt qu'il existe trop de cas limites, et une fois qu'il est mis en production, il commence à fuir.

La monétisation des API peut sembler superficiellement comme payer quelques centimes par demande, ce qui est assez léger ; mais une fois que votre produit facture par appel, par résultat ou par flux de travail, alors que « payer une fois, obtenir un » ou « payer une fois, obtenir beaucoup » n'est pas juste un détail de produit mais une question de vie ou de mort.

Donc, si x402 peut effectivement décoller dans le B2B, une condition préalable importante n'est pas le récit, mais que ces mécanismes par défaut doivent être rendus suffisamment simples d'utilisation ; sinon, les entreprises ne se sentiront pas en sécurité pour faire entrer du trafic réel.

7. Les protocoles peuvent être gratuits, mais les péages ne disparaîtront pas

Il y a un autre point que je pense qu'il vaut la peine d'élaborer dans cet article.

De nombreux protocoles ouverts aboutissent finalement à un endroit très familier : le protocole lui-même devient de plus en plus bon marché, voire gratuit, mais de véritables péages vont se développer à ses côtés.

x402 n'est pas différent.

La norme elle-même met certainement l'accent sur l'ouverture, la neutralité et l'absence de frais intégrés dans la norme, mais cela ne signifie pas que la capture de valeur disparaîtra.

Si x402 a du succès, la valeur ne restera pas principalement dans le protocole, mais migrera vers les facilitateurs, les portefeuilles, la gestion des clés, la découverte, les moteurs de stratégie et les enveloppes de confiance, ces couches adjacentes.

Cela est particulièrement important pour le B2B.

Car les clients d'entreprise ne vont pas massivement revoir l'ensemble de leurs systèmes pour un nouveau protocole ; ce pour quoi ils sont vraiment prêts à payer, c'est qui peut les aider à organiser l'orchestration, la politique, le risque, la conformité, l'audit, le règlement et les limites de permission dans un environnement multi-protocole.

En d'autres termes, les protocoles ressembleront de plus en plus à des langages sous-jacents, mais la capacité de traduire ces langages en capacités « prêtes pour l'entreprise » deviendra plus facilement de nouvelles plateformes et de nouveaux péages.

C'est également pourquoi je pense que, lorsque nous examinons x402 aujourd'hui, nous ne devrions pas nous concentrer uniquement sur qui parmi Coinbase, Cloudflare ou Stripe est le plus proche du « protagoniste ».

Ce qui vaut vraiment la peine d'être observé, c'est qui a la meilleure opportunité de se positionner sur ces couches adjacentes.

Cloudflare occupe une position dans le domaine du trafic et de la distribution, Stripe dans l'infrastructure de paiement et les relations avec les commerçants, Visa et Mastercard dans les identifiants, les jetons réseau et la confiance des consommateurs, et Google dans les flux de travail et les surfaces de découverte.

La véritable valeur ajoutée ne réside peut-être pas dans « qui a défini 402 », mais plutôt dans « qui a intégré 402 dans des systèmes d'entreprise plus vastes ».

8. Conclusion

La Fondation x402 n'annonce pas que x402 a déjà gagné dans tous les protocoles de commerce agentic.

Elle reconnaît publiquement que cette génération de paiements d'agents ne sera pas un monde de protocole unique dès le premier jour.

Coinbase remet x402 à la Fondation Linux pour en faire une couche publique neutre plutôt qu'un produit exclusif.

Stripe qui fait la promotion de MPP tout en rejoignant x402 n'est pas indécis. C'est parce qu'il sait qu'il ne faut pas miser sur un seul côté en ce moment.

Cloudflare prend en charge les deux systèmes simultanément car il est le plus proche du trafic réel.

Les actions de sociétés comme Google, Visa, Mastercard et Adyen indiquent également la même chose : d'abord, laissez les systèmes interopérer, puis discutez de qui occupe finalement quelle couche.

Et si nous changeons de perspective par rapport au commerce de détail, ce jugement devient encore plus clair.

Car les premiers à avoir besoin de ces protocoles ne sont peut-être pas le panier d'achat, mais plutôt le nombre croissant de logiciels et de services B2B qui facturent par appel, tâche ou résultat.

Le commerce de détail est certainement plus important, mais le B2B expose souvent les besoins réels plus tôt et définit plus rapidement à quoi ressemble finalement l'infrastructure.

Dans mon dernier article, j'ai placé l'interopérabilité au centre, et je crois que la réponse du marché est maintenant assez claire : oui, et même plus tôt que je ne le pensais à l'époque.

En ce sens, la Fondation x402 n'est pas la fin de cette histoire.

Elle nous permet simplement de voir plus tôt que le véritable thème n'a jamais été « qui va gagner », mais plutôt « ce monde est destiné à interopérer en premier, et qui peut occuper la couche la plus précieuse après l'interopérabilité ».