Auteur : Charlie Liu, associé chez Generative Ventures
La semaine dernière, OpenClaw et Tempo sont presque devenus des mots de passe dans la communauté crypto.
Beaucoup ont vu la tendance, savent que Stripe est sorti du jeu, et que Visa et Lightspark ont rejoint le mouvement.
Ce qui n’a pas encore été pleinement compris, ce n’est pas l’actualité elle-même, mais le déplacement des points de contrôle de paiement.
Ces derniers mois, le marché a été plein d’imagination autour des Agent Payments.
Coinbase a lancé x402 en mai 2025, transformant le HTTP 402 en un langage de paiement ; Cloudflare l’a rapidement intégré dans la documentation sur les paiements agentiques, créant une expérience de paiement programmatique sans compte, sans session, sans clés API, un point de départ très internet, très natif pour les développeurs.
Circle a suivi cette voie, en reliant USDC, Wallets, paiements autonomes et x402, puis a lancé Nanopayments, avançant vers des paiements à haute fréquence, faibles montants, et plus proches du paiement machine.
Ainsi, ces derniers mois, beaucoup ont en tête un schéma : l’agent doit payer, le protocole est x402, l’argent est USDC, la compensation se fait sur la blockchain, et l’entrée pour les développeurs se trouve sur Coinbase Developer Platform et dans l’écosystème associé.
Ce schéma reste valable aujourd’hui, mais il ne décrit que la première étape.
Stripe et Tempo ont lancé la semaine dernière le MPP. Ce qui change vraiment, ce n’est pas « un protocole supplémentaire supportant les paiements AI agentiques », mais la redéfinition du problème : passer de « comment un agent effectue un paiement en stablecoin » à « comment des machines peuvent disposer d’une interface de paiement indépendante du moyen de paiement ».
L’objectif officiel de Stripe est : le MPP est une norme ouverte, native à Internet, permettant aux agents de payer ; Cloudflare va plus loin, en le décomposant en un protocole unifié supportant Tempo stablecoins, cartes et wallets Stripe, Lightning, et des méthodes de paiement personnalisées.
Le champ de bataille a changé.
x402 a d’abord gagné une manche
Si je ne rends pas hommage à x402, toutes mes analyses sur le MPP seront vides.
J’ai déjà écrit que l’Internet a une faute originelle : contenu, puissance de calcul, données, API deviennent de plus en plus granulaires, mais le paiement reste figé dans l’ancien monde des comptes, abonnements, prépaiements, checkout manuel.
Ce qui rend x402 puissant, c’est qu’il ne tente pas de tout résoudre en une fois, mais choisit une approche très ciblée : faire en sorte que la requête HTTP elle-même porte la capacité de paiement.
Le serveur renvoie un 402 Payment Required, le client effectue le paiement de façon programmatique, puis réessaie avec la preuve de paiement.
Pas de système de comptes, pas de session, pas de gestion de clés API. Pour un agent, cette conception est naturellement pratique.
C’est aussi pour cela que Circle a d’abord bénéficié de cette opportunité.
Il veut permettre aux AI agents de payer via Circle Wallets, USDC et l’API x402 ; et, il y a quelques jours, avec Nanopayments, Circle a directement présenté x402 comme le protocole standard pour le paiement web des agents.
En combinant cela avec la croissance récente de USDC, dont la circulation a augmenté de 72 % pour atteindre 75,3 milliards de dollars, le marché voit naturellement dans « infrastructure de stablecoin » et « infrastructure de paiements agentiques » une seule et même narration, ce qui a fait exploser le cours de Circle.
En résumé, x402 n’a pas gagné la « fin de la technologie », mais a simplement permis que « ça se passe d’abord ».
C’est crucial dans un nouveau marché.
Dans la première phase, ce n’est souvent pas la solution la plus complète qui a le plus de valeur, mais celle que les développeurs adoptent en premier.
Le vrai changement apporté par le MPP, ce n’est pas la voie de paiement, mais le checkout sans tête
Le point le plus souvent mal compris du MPP, c’est que beaucoup le voient comme « x402 Pro supportant plus de moyens de paiement », une version étendue de x402.
Mais ce qu’il veut vraiment toucher, c’est la couche checkout.
Dans l’interview du podcast Tokenized cette semaine, Cuy Sheffield, responsable crypto chez Visa, a dit une phrase clé : si l’on veut vraiment faire croître le commerce agentique, il ne faut plus renvoyer l’agent dans le « monde humain » pour chercher une page web, cliquer sur un bouton, faire un checkout ; ce qu’il faut, c’est un checkout sans tête, où l’agent négocie directement avec le commerçant ce qu’il veut acheter, à quel prix, avec quel moyen, puis effectue la transaction proprement.
Plus important encore, lui et Simon Taylor, responsable GTM de Tempo, ont insisté dans cette discussion non pas sur « supporter une chaîne supplémentaire », mais sur « payment-method-agnostic, payment-network-agnostic, PSP-agnostic, vault-provider-agnostic ».
Ce n’est plus une idée d’ingénieur crypto, mais une redéfinition de l’interface par la plateforme de paiement.
Le blog officiel de Stripe dit aussi la même chose, mais avec plus de retenue.
Le MPP n’est pas simplement une spécification, mais une intégration directe dans le système existant de Stripe, avec Payment Intents et autres backends.
Les commerçants pourront accepter un paiement MPP en quelques lignes de code ; ces paiements entreront dans le flux normal de Stripe : balance, payout, taxes, fraude, reporting, remboursements.
Pour les développeurs, cela signifie qu’ils n’ont pas besoin d’apprendre un nouveau protocole de paiement sur la blockchain, mais peuvent commencer à intégrer des machines dans leur stack de paiement familier.
C’est très Stripe : dans ses moments les plus risqués, ce n’est pas en inventant quelque chose de nouveau, mais en transformant une tâche complexe, réservée à quelques experts, en une interface par défaut pour tous les développeurs.
C’est pourquoi je pense que le vrai enjeu du MPP n’est pas la voie de paiement, mais le checkout sans tête dans l’ère du machine commerce. La première détermine comment l’argent circule, la seconde qui réalise la transaction. Historiquement, ce qui a de la valeur, c’est souvent la seconde.
Session, la vraie avancée
La différence profonde entre x402 et le MPP ne réside pas dans « un protocole plus ouvert, ou plus orienté entreprise », mais dans la notion de session.
Le MPP définit deux types d’intentions de paiement : le « charge » pour un paiement immédiat et ponctuel, adapté à la facturation par demande ; la « session » pour un paiement en flux continu basé sur un canal, adapté au paiement à l’usage ou par token, avec pour objectif des coûts infimes et une latence inférieure à la milliseconde.
Plus important encore, la documentation de Cloudflare indique que le MPP est rétrocompatible avec x402, et que le flux exact de x402 peut être mappé dans le « charge » du MPP.
Autrement dit, le MPP ne rejette pas x402, mais construit sur cette base pour faire du paiement continu une primitive du protocole.
Tempo explique cette primitive plus simplement : une session, c’est comme OAuth pour l’argent, une fois autorisée, puis des paiements programmatiques dans la limite d’un quota, regroupant des milliers de micro-interactions en une seule liquidation finale.
Dans le podcast Tokenized, Liam Horne, responsable produit chez Tempo, a dit que cela correspond à des « payment channels » dans la vieille terminologie blockchain, sauf que la nouvelle application n’est pas un réseau de paiement idéal pour les maximalistes BTC, mais plutôt pour la facturation par token, par API, ou par workflow agentique.
Par exemple, déposer 5 dollars, puis déduire un peu à chaque token généré, puis fermer la session. Dès que cette image apparaît, on comprend que le MPP vise non pas la démo, mais le modèle économique.
Mon expérience chez Strike, dans Lightning Network, m’a rendu très sensible à cette idée.
La session MPP et le concept de payment channel ont beaucoup en commun avec Lightning Network, c’est pourquoi le MPP supporte aussi Lightning dès le départ.
Et le choix de Lightspark comme partenaire Lightning, par Tempo, a une signification profonde — que je ne vais pas développer ici.
Dès qu’on voit « verrouiller la valeur, la déduire en continu dans la session, puis faire une liquidation finale », on comprend que Tempo ne cherche pas à ajouter une chaîne, mais à intégrer une logique de paiement à long terme, souvent réservée à une élite, dans une vision plus large du machine commerce.
Ce qui rend Tempo vraiment redoutable, ce n’est pas seulement le protocole, mais sa volonté de prendre en main tout le système de paiement
Beaucoup comparent actuellement x402 et le MPP, mais cette comparaison perd de sa pertinence, car ils n’évoluent pas dans le même espace.
x402 est essentiellement un langage de paiement. Élégant, précis, ciblé.
Mais Tempo ne se limite pas à un langage : il propose un système complet, conçu pour les paiements réels.
Lors de son lancement, Tempo a mis en avant des points concrets : règlement instantané, faibles frais prévisibles, haute capacité, disponibilité mondiale ; tout en intégrant des paiements par voie, stablecoins gas, et des charges de travail pour les paiements d’entreprise.
TIP-20 illustre bien cette approche : ce n’est pas une simple norme de token, mais une intégration de besoins complexes comme les mémos de transfert, la conformité, la distribution de récompenses, directement dans la primitive.
Tempo, en seulement sept mois entre la première ligne de code et le mainnet, s’appuie sur une infrastructure éprouvée, accumulée au fil des années.
Ce qui rend Tempo digne d’attention, ce n’est pas la vitesse, mais le fait qu’il ne cache pas ses bases techniques derrière un récit entrepreneurial, mais explique clairement que ce n’est pas un projet « sans fondations ».
Comparé à la plateforme Coinbase Developer Platform, qui privilégie la mise en place de standards pour faire venir les développeurs et bâtir une écosystème, Tempo vise une étape suivante : l’intégration progressive de l’abstraction protocolaire, du runtime de paiement, des outils pour développeurs et des primitives de paiement d’entreprise.
Ce n’est pas une question d’intelligence, mais d’adaptation à chaque étape de développement.
Circle doit surtout faire attention à ne pas se laisser distraire par le volume actuel de USDB
Cela signifie-t-il que USDB va défier USDC ?
USDC est très fort aujourd’hui : Circle n’est pas seulement un émetteur d’actifs, mais aussi très lié à x402, aux paiements autonomes, et à Nanopayments, avec une forte imagination du marché.
Le problème, c’est que la position dominante de Circle repose essentiellement sur la couche monétaire : la dollar que les agents AI préfèrent dépenser est très probablement USDC.
Mais ce que Stripe et Bridge font, ce n’est pas cela.
Stripe supporte à la fois USDC et USDB, avec une vision claire : USDB est une stablecoin d’infrastructure / à boucle fermée, pas un concurrent direct d’USDC en marché ouvert.
C’est aussi là que je vois un danger : la boucle fermée n’a jamais été une faiblesse, mais souvent un point de départ pour une plateforme de paiement.
Si Tempo, avec le MPP, pousse Stripe vers une interface de machine commerce, la stratégie de Bridge/USDB pourrait changer radicalement.
Aujourd’hui, USDB est une stablecoin pour le traitement en backend ; demain, elle pourrait devenir le règlement par défaut dans un grand réseau de paiement, la couche de récompense, ou la couche de trésorerie par défaut.
Bridge insiste sur le fait que USDB, contrairement aux stablecoins traditionnels, peut répartir plus flexiblement ses réserves entre l’émetteur, les développeurs et les utilisateurs finaux.
Pour Stripe, qui excelle dans la distribution de l’économie de plateforme, ce n’est pas une simple feature produit, mais un avantage structurel.
Lightspark n’est pas un simple acteur secondaire, il donne une dimension historique à cette évolution
Lightspark ne doit pas seulement être vu comme « un nouveau rail Bitcoin ». Son rôle dépasse cela.
Bien que le protocole supporte aujourd’hui Tempo, il reste rail-agnostic.
Visa l’a étendu aux paiements par carte, Stripe à ses cartes, wallets et autres moyens, Lightspark à Lightning Network.
Ce mélange est intéressant : il transforme le MPP d’un simple protocole de stablecoin en une couche de coordination des paiements.
Comme mentionné plus haut, la couche session et Lightning channel se ressemblent beaucoup : selon Lightspark, Lightning est basé sur des payment channels, où chaque transaction n’a pas besoin d’être broadcastée sur la blockchain, mais les deux parties mettent à jour leur solde dans le canal, puis le résultat est inscrit sur la chaîne.
La session Tempo n’est pas une simple copie de Lightning, ses techniques et cas d’usage diffèrent, mais leur intuition commerciale est très proche : les paiements à haute fréquence, faibles, et continus, ne doivent pas être recalculés à chaque fois.
En regardant plus loin, cette ligne de pensée devient encore plus intrigante. David Marcus, ancien responsable chez Facebook Libra, a toujours voulu réécrire un système de paiement inefficace, pas simplement lancer une nouvelle monnaie.
Après avoir quitté Facebook pour créer Lightspark, il a récemment écrit que « Restarting Libra » n’était pas la bonne voie. En reliant ces personnes et ces événements, on perçoit une forte résonance historique : Libra voulait réécrire la monnaie, aujourd’hui ces acteurs cherchent à réécrire l’interface de paiement d’une autre manière.
En évoquant Libra, on pense à Meta, et à la stratégie récente de revenir à la stabilité.
Le système MPP relie maintenant David Marcus, Lightspark, et Stripe, comme un puzzle d’un grand consortium : Stripe fournit l’interface, Bridge la stablecoin à boucle fermée, Tempo la blockchain sous-jacente, Meta la distribution. Mark Zuckerberg, David Marcus, Patrick Collison forment la façade.
Le marché va probablement réévaluer tout cela.
