L'économie agentique débloquera-t-elle une pile de paiements à deux couches pour les transactions natives de l'IA ?

À mesure que les transactions natives de l’IA passent du concept à la mise en œuvre, le commerce agentique oblige à repenser fondamentalement la manière dont fonctionnent les paiements numériques et l’infrastructure de compensation.

Des paiements centrés sur l’humain aux rails natifs pour l’IA

Entre septembre 2025 et mars 2026, chaque acteur majeur des paiements mondiaux s’est orienté vers un commerce porté par l’IA. OpenAI et Stripe ont lancé le Agentic Commerce Protocol, tandis que Google a dévoilé le Universal Commerce Protocol à plus de 30 partenaires de la vente au détail et de la fintech.

Sur la même période, Visa et Mastercard ont publié des cadres de paiement axés agents. Coinbase a fait avancer sa norme x402, compensant plus de 15 millions de transactions sur Base. En outre, Stripe et Tempo ont co-rédigé le Machine Payments Protocol et l’ont soumis à la standardisation de l’IETF.

Le calendrier n’est pas fortuit. L’infrastructure de paiement des trois dernières décennies a été conçue pour des humains utilisant des navigateurs, remplissant des formulaires et passant une vérification par étapes. Les agents d’IA, eux, ont besoin d’interfaces programmatiques, d’une autorisation quasi instantanée et d’une compensation capables de traiter des transactions à des fractions d’un cent.

La pile existante n’a jamais été conçue pour cet environnement, et l’industrie reconnaît l’inadéquation. Ce qui émerge plutôt, c’est une architecture en deux couches : une couche supérieure d’orchestration pour la découverte et l’initiation, et une couche inférieure de compensation pour le transfert de valeur. Elles évolueront sur des pistes distinctes, portées par des incitations différentes.

Orchestration commerciale : comment les transactions d’agents se rassemblent

La couche d’orchestration définit la manière dont un agent trouve un service, gère une session et transmet le paiement. Deux catégories distinctes de cas d’usage sont apparues, et les confondre fait courir le risque de mal comprendre la structure du marché.

1.1 Agents agissant pour le compte des consommateurs

Pour les agents qui achètent pour le compte d’humains, le principal problème aujourd’hui n’est pas la mécanique de paiement, mais l’accès. La plupart des plateformes de e-commerce sont optimisées pour la navigation humaine. Cependant, un agent ne devrait pas faire défiler des pages produits, interpréter des bannières, ni cliquer sur un bouton « add to cart ».

Les marchands ont plutôt besoin d’extrémités structurées et lisibles par machine. Elles restent encore rares, ce qui limite les interactions natives d’agents. La première vague de protocoles dans ce segment vient d’OpenAI, Stripe et Google, chacun avec une approche différente en matière de contrôle et d’ouverture.

OpenAI et Stripe ont lancé le Agentic Commerce Protocol (ACP) en septembre 2025. Le protocole s’articule autour de la délégation de paiement sécurisée au moment du checkout : la méthode de paiement d’un utilisateur est stockée dans ChatGPT, et au moment de la confirmation d’achat, Stripe émet un Shared Payment Token (SPT), un identifiant à usage unique limité au marchand et au total du panier.

Ce jeton est remis au marchand via API, qui conserve le statut complet de Merchant of Record et traite le paiement via l’infrastructure Stripe existante. Le SPT de Stripe est, au moment où nous écrivons ces lignes, la première mise en œuvre en production de cette architecture de délégation, et il est compatible avec la Delegated Payment Spec d’OpenAI. D’autres PSP peuvent implémenter la spécification, ce qui rend l’ACP ouvert au niveau du paiement.

ChatGPT Instant Checkout a été lancé en septembre 2025 pour les utilisateurs américains, mais a été fermé en mars 2026 après une conversion proche de zéro. OpenAI s’est depuis déplacé vers la découverte : ChatGPT met désormais en avant des produits et redirige les utilisateurs vers les sites ou applications des marchands pour le checkout. L’ACP survit dans un rôle plus restreint, en alimentant des applications dédiées au sein de ChatGPT pour un petit ensemble de grands détaillants.

Les marchands doivent demander à participer, et OpenAI contrôle quels éléments apparaissent et selon quel classement. Cela dit, ce modèle curaté offre à OpenAI un contrôle de bout en bout sur l’expérience au sein de l’assistant, tout en déléguant la compensation à des processeurs tiers comme Stripe.

Le Universal Commerce Protocol (UCP) de Google représente une stratégie contrastée. Annoncé par Sundar Pichai lors de la conférence NRF du 11 janvier 2026, l’UCP a été co-développé avec Shopify, Etsy, Wayfair, Target et Walmart, et approuvé par plus de 20 partenaires, dont Adyen, American Express, Best Buy, Mastercard, Visa, Stripe et The Home Depot.

L’UCP est explicitement aligné avec le propre protocole de paiements par agents de Google (AP2), la norme Agent2Agent (A2A), et le Model Context Protocol (MCP. Cette poussée d’interopérabilité est une tentative délibérée de prendre l’avantage sur l’indexation et l’accès. Google Pay sert de méthode de paiement par défaut, avec PayPal annoncé comme option à venir.

Techniquement, l’UCP fonctionne via un manifeste de capacité connu sous le nom de profil UCP. Les marchands publient un document JSON structuré à /.well-known/ucp sous leur domaine, spécifiant les méthodes de transport, les capacités de checkout et les gestionnaires de paiement pris en charge. Les agents lisent directement ces manifestes, sans intermédiaires.

L’architecture reflète les priorités stratégiques de Google. Google n’a que peu d’intérêt à jouer l’intermédiaire des transactions, ce qui ferait naître une pression sur les marges, une exposition en matière de responsabilité et un examen réglementaire plus strict. Il veut plutôt une visibilité complète sur le web du commerce. L’UCP positionne Gemini comme couche principale de découverte pour les achats d’agents tout en restant pour l’essentiel invisible au moment de la compensation.

Le contraste avec l’ACP est net. L’ACP est un environnement curaté où OpenAI agit comme gardien, les marchands doivent demander à participer, et le flux est optimisé au sein de ChatGPT. L’UCP agit comme un catalogue ouvert : les marchands se publient eux-mêmes, n’importe quel agent compatible peut consommer les profils, et Google contrôle la surface de découverte mais pas le paiement lui-même.

Le manque de friction au démarrage est plus faible et la portée potentielle est plus large avec l’UCP, mais les marchands reçoivent moins d’accompagnement direct. En pratique, l’ACP échange l’ouverture contre le contrôle, tandis que l’UCP échange le contrôle contre la largeur de l’index et la standardisation au niveau du protocole.

1.2 Agents qui effectuent des transactions avec d’autres agents

La deuxième grande catégorie est structurellement différente : les deux parties à la transaction sont des agents autonomes, et aucun marchand humain n’intervient. Dans cet environnement, les ancres de confiance traditionnelles disparaissent, laissant peu de protections familières.

Il n’existe aucune loi de protection des consommateurs ni de droits de chargeback de carte sur lesquels s’appuyer. De plus, les parties n’ont peut-être jamais interagi auparavant, et pourtant elles doivent échanger de la valeur en toute sécurité. C’est le problème que de nouvelles normes Ethereum cherchent à résoudre.

Proposé le 10 mars 2026 par l’équipe dAI de la Ethereum Foundation, avec Virtuals Protocol, ERC-8183 structure chaque transaction comme un travail à trois parties. Un Client commande le travail, un Provider le fournit, et un Evaluator certifie l’achèvement.

Les fonds sont détenus en escrow via smart-contract et libérés uniquement lorsque l’Evaluator donne son feu vert. Ni le Client ni le Provider n’ont besoin d’évaluer la fiabilité de l’autre ; le contrat impose le résultat de façon mécanique. En parallèle, ERC-8004 définit la couche d’identité qui sous-tend ce mécanisme.

Sous ERC-8004, les agents s’enregistrent on-chain et construisent un score de réputation à partir de l’historique des transactions. Cela crée un signal de crédibilité portable qui persiste au-delà des interactions. La conception est robuste en théorie ; cependant, le démarrage de l’adoption à grande échelle reste le goulot d’étranglement pratique.

Aujourd’hui, la majeure partie de l’usage réel est concentrée au sein de la plateforme Virtuals Protocol. Un agent orchestrateur appelé Butler décompose des tâches complexes en sous-tâches et les achemine vers des agents spécialistes. La communauté plus large des développeurs n’a pas encore été mobilisée à une échelle comparable. ERC-8183 est essentiellement une tentative de rendre ce pattern ouvert et sans permission.

Un point structurel suit directement. Le e-commerce de détail peut fonctionner confortablement sur des rails de cartes, parce que les acheteurs humains restent dans la boucle. En revanche, le pur commerce agent-à-agent nécessitera probablement une compensation en stablecoin, car les frais de carte deviennent non économiques pour des montants de ticket très faibles et des fréquences élevées.

Protocoles de compensation : qui fait réellement circuler l’argent

Si l’orchestration décide quoi et où transiger, la couche de compensation détermine si la valeur se déplace réellement. Cinq protocoles majeurs sont désormais en concurrence ici, chacun adapté à différents cas d’usage et contraintes économiques.

2.1 Delegated Payment Spec et SPT (Stripe)

La Delegated Payment Spec de Stripe étend l’infrastructure par carte plutôt que de la remplacer. Lorsqu’un client autorise un agent, Stripe provisionne un SPT que l’agent stocke. Au moment de la transaction, l’agent présente ce jeton limité dans le temps et plafonné en montant au marchand.

La compensation s’effectue ensuite via la pile de cartes existante de Stripe. En coulisse, Stripe se connecte à Visa Intelligent Commerce et Mastercard Agent Pay, qui émettent des tokens de réseau agentique. Les marchands voient une seule surface d’intégration, quel que soit le réseau de cartes situé en dessous.

Ce modèle convient bien aux achats de détail standards et à de nombreux paiements de valeur élevée agent-à-agent, où les chargebacks et autres protections des consommateurs restent souhaitables. En revanche, il correspond mal à des schémas à haute fréquence et micro-valeur, comme les paiements en streaming machine-à-machine.

Dans ces scénarios, les montants des transactions sont souvent des fractions d’un cent, et les volumes peuvent atteindre des milliers d’opérations par minute. L’économie des frais de carte et la surcharge d’autorisation deviennent rapidement non soutenables, même si c’est techniquement faisable.

2.2 Visa Intelligent Commerce et Mastercard tokens agentiques

Visa et Mastercard ont toutes deux refactoré leurs couches de tokenisation pour gérer les paiements initiés par des agents. De vrais numéros de carte sont remplacés par des tokens chiffrés dynamiques qui intègrent des métadonnées sur l’agent autorisant, de l’identité aux limites de dépense et aux fenêtres de validité.

Les marchands autorisés sont aussi précisés dans les métadonnées du token, permettant des contrôles fins sur les endroits où les agents peuvent payer. La compensation elle-même reste sur des rails de cartes hérités, ce qui conserve des parcours d’intégration familiers et évite une infrastructure entièrement nouvelle.

Les deux réseaux sont allés bien au-delà de la preuve de concept. Mastercard a traité la première transaction d’agent entièrement identifiée en septembre 2025, en collaboration avec Commonwealth Bank en Australie. Visa a terminé des déploiements initiaux sur les marchés européens via son programme Agentic Ready.

L’infrastructure semble capable, mais le plancher de frais constitue une limitation structurelle. Aucun des deux réseaux ne peut supporter efficacement des paiements sous le dollar à la densité que le commerce agent à venir pourrait exiger. En outre, les couches réglementaires et de conformité contraignent davantage l’expérimentation à l’extrémité des très petits tickets.

2.3 x402 (Coinbase)

x402, à l’inverse, démarre avec HTTP plutôt qu’avec les cartes. Il s’appuie sur le code d’état 402 “Payment Required”, présent dans la spécification HTTP depuis 1997 mais à peine utilisé. Lorsqu’un agent demande une ressource payante, le serveur répond avec un 402 contenant des paramètres de paiement.

L’agent signe une autorisation, et un Facilitator exécute une compensation atomique on-chain en USDC ou autres tokens pris en charge, généralement en environ deux secondes. Il n’y a pas de configuration de compte, pas de distribution de clé API et pas d’application de KYC au niveau du protocole. La gouvernance réside dans la x402 Foundation, créée par Coinbase et Cloudflare.

D’ici la fin de 2025, x402 avait traité plus de 100 millions de transactions sur Base, Solana et Polygon. Cependant, des analystes d’Artemis, écrivant en février 2026, ont estimé que l’essentiel de ce volume reflète des opérations de type self-dealing et des tests d’infrastructure plutôt qu’un véritable commerce.

Le volume annuel de paiements du protocole se situe autour de 600 millions de dollars, mais la concentration et les problèmes de qualité du volume sont importants. Cela dit, x402 ne fait face à aucun plancher structurel de frais ; il a été explicitement conçu pour les micropaiements. Le manque clé est la profondeur de l’adoption et la densité du commerce réel dans le monde, pas la conception technique.

2.4 Nanopayments (Circle)

Le protocole Nanopayments de Circle est intentionnellement compatible avec x402, en utilisant HTTP 402 comme déclencheur tout en ajoutant une couche de compensation groupée. Plutôt que de régler chaque paiement on-chain individuellement, les acheteurs pré-alimentent un compte Circle Gateway et signent des messages EIP-3009 hors chaîne pour chaque transaction.

La compensation périodique groupée vers la blockchain répartit le coût du gaz sur de nombreux paiements, rendant économiquement viables des transferts aussi petits que 0,000001 $. Le gaz est effectivement payé une seule fois au dépôt plutôt que par paiement, une optimisation cruciale pour les cas d’usage à ultra-haute fréquence.

Le compromis est que les deux contreparties doivent déposer dans Circle Gateway, créant ainsi un réseau semi-clos dans l’architecture actuelle. Nanopayments a été lancé sur testnet en mars 2026 sur 12 chaînes prises en charge. De plus, le modèle de frais est convaincant pour des flux intensifs de micro-paiements si Circle peut réduire la friction d’onboarding.

2.5 MPP Machine Payments Protocol (Tempo et Stripe)

MPP, co-écrit par Tempo et Stripe, est le plus ambitieux des cinq designs de compensation. Il utilise HTTP 402 comme déclencheur et permet aux marchands et aux agents de choisir parmi plusieurs rails de compensation dans un cadre unifié.

Les développeurs n’ont plus besoin de “hard-wire” à l’avance, au moment de la construction, soit l’infrastructure en stablecoin soit celle en fiat. À la place, l’agent peut décider à l’exécution quel rail utiliser selon les besoins de la transaction. Les options disponibles incluent la compensation en stablecoin Tempo, les paiements par SPT de Stripe, les tokens de réseau de cartes, et les paiements Bitcoin Lightning alimentés par Lightspark.

Point crucial : MPP introduit une primitive de “session” similaire à OAuth. Un agent autorise une seule fois et préfinance un compte, puis bénéficie d’une compensation automatisée en temps réel pour les interactions suivantes, sans transaction on-chain par paiement.

La spécification principale a été soumise à l’IETF en tant que mise en œuvre de référence de HTTP 402. Au lancement le 18 mars 2026, le Payment Directory du mainnet avait déjà intégré plus de 100 services. Toutefois, les schémas d’adoption restent à un stade précoce.

Le rôle double de Stripe est stratégiquement important. Il a co-écrit le protocole et apparaît aussi comme une des options de paiement à l’intérieur de celui-ci, capturant de la valeur que les développeurs choisissent MPP principalement pour la flexibilité ou spécifiquement pour les capacités liées aux cartes.

Réalité du marché : des protocoles en avance sur le déploiement

3.1 Où en est le marché

Malgré le lancement rapide de protocoles au cours des six derniers mois, l’adhésion commerciale reste limitée. Côté compensation, x402 mène en nombre de transactions, mais le volume de commerce quotidien réel avoisine les 28 000 dollars. Côté orchestration, Instant Checkout d’ACP a été stoppé après des conversions négligeables.

De nouvelles normes comme ERC-8183 et MPP montrent un schéma similaire : le récit dépasse le déploiement réel. L’industrie a atteint un point d’inflexion où une grande partie de l’architecture des protocoles existe déjà, mais où l’application commerciale à grande échelle n’a pas encore commencé.

Le goulot d’étranglement central est la fragmentation au niveau de l’orchestration. Les marchands font face à plusieurs standards indépendants, chacun avec ses propres SDK, flux d’authentification et règles de conformité. Cependant, cela augmente les coûts d’intégration et décourage l’expérimentation.

Historiquement, une telle fragmentation est résolue par une couche d’agrégation qui unifie l’accès entre standards concurrents. Ce cycle pourrait être différent. Les plateformes qui ont un trafic d’agents significatif, y compris OpenAI, Google et Microsoft, sont incitées à maintenir des surfaces fermées plutôt que de laisser passer les utilisateurs ailleurs.

Cette même logique se déroule aussi à l’échelle régionale. La Chine, l’Asie du Sud-Est, la Corée et le Japon développent chacun des écosystèmes en boucle fermée ancrés par des super-applis ou des plateformes dominantes. L’issue la plus probable est donc un ensemble de systèmes fermés parallèles régionaux plutôt qu’un seul standard global ouvert.

La couche d’agrégation que les marchands veulent proviendrait donc plus probablement de fournisseurs d’infrastructure tiers qui servent directement les marchands, plutôt que des plateformes qui se disputent la propriété du trafic d’agents. Les incitations à l’ouverture et à la portée multi-plateformes ne s’alignent simplement pas au niveau de la plateforme.

3.2 Où se trouvent les opportunités à court terme

Deux ensembles d’opportunités se dégagent de ce paysage : l’infrastructure de compensation et les services agent-à-agent au niveau de l’application. Le premier semble être l’activité la plus certaine à court terme, tandis que le second est le moins développé mais potentiellement le plus transformateur.

Pour la compensation, la fragmentation au niveau de l’orchestration contraste fortement avec la pression de consolidation au niveau du paiement. Chaque agent, quelle que soit la plateforme, fait finalement face au même problème : comment payer efficacement les contreparties via différents rails.

Les développeurs ne peuvent pas raisonnablement maintenir des intégrations de paiement distinctes pour chaque surface où leurs agents pourraient opérer. À mesure que les plateformes se multiplient, la pression économique s’intensifie en faveur d’une intégration de paiement unique et unifiée qui abstrait la complexité des rails sous-jacents.

Cela définit une exigence produit concrète : un wallet multi-rails pour les agents. Les rails cartes tels que SPT, les tokens agentiques Visa et les tokens agentiques Mastercard continueront de prendre en charge le commerce marchand traditionnel. Les rails en stablecoin, comme les paiements de session x402 et MPP, serviront d’ancrage pour des API on-chain et des transferts agent-à-agent.

Ces deux catégories sont déjà en ligne et ne convergeront pas vers un seul rail à court terme. La charge de flexibilité repose du côté de l’agent, pas du côté du marchand. Les marchands choisissent les rails qu’ils prennent en charge : une décision relativement stable et contrôlable.

Les entreprises provisionnent ensuite leurs agents avec des stablecoins et des cartes déléguées. L’agent paie en utilisant le rail que la contrepartie accepte. Un wallet qui gère de façon transparente les deux, au sein d’une seule intégration, devient la couche d’habilitation pour des agents généralistes opérant à travers des écosystèmes variés.

La valeur d’intégration s’accumule à chaque transaction et avec chaque nouvelle plateforme, créant une profondeur d’infrastructure difficile à déplacer une fois établie. De plus, elle positionne le fournisseur de wallet comme une couche neutre de compensation entre des environnements d’orchestration fragmentés.

Commerce agent-à-agent : l’opportunité sous-développée

La deuxième opportunité se situe au niveau de l’application du commerce agent-à-agent. Aujourd’hui, la majeure partie de l’activité A2A reste confinée à des workflows natifs de la crypto : des agents interrogeant des données on-chain, interagissant avec des protocoles DeFi et exécutant des transactions blockchain.

Le marché ne s’est pas encore étendu à des services réels et généralistes. Pourtant, du point de vue des protocoles, les agents pourraient déjà commander des tâches comme l’analyse de données, la génération de contenu, la recherche juridique ou la revue de code, en payant à la demande.

La pièce manquante est l’écosystème développeur. Les créateurs de services n’emballent pas encore leurs offres sous forme d’APIs payables par agents avec une tarification fine basée sur l’usage. C’est le vrai manque, et actuellement c’est l’une des zones les moins disputées de la pile.

Cet espace est limité par un problème de “cold-start”. Les systèmes d’identité comme ERC-8004 exigent une densité de transactions importante pour générer des scores de confiance crédibles. Les agents sans historique manquent de poids de réputation, ce qui limite les contreparties prêtes à transiger avec eux.

Microsoft a projeté environ 1,3 milliard d’agents IA actifs d’ici 2028. La base installée d’aujourd’hui est d’un ordre de grandeur bien plus faible. L’écart ne se comble pas automatiquement ; c’est précisément ce qui maintient la concurrence à court terme basse et rend intéressant de prendre une position tôt.

Les implications dépassent les paiements et touchent aussi les modèles économiques. Les modèles dominants de l’internet, la publicité et les abonnements, supposent des acheteurs humains. Les agents ne sont pas persuadables via des publicités, ni en besoin de bundles mensuels d’accès ; ils paient pour le résultat d’appels spécifiques.

Dans ce contexte, les paiements http 402 créent une primitive économique différente. Les fournisseurs vendent des résultats plutôt que l’accès, facturent fortement les gros utilisateurs proportionnellement à la consommation réelle, et cessent de subventionner les utilisateurs légers ou de sur-provisionner pour des pics rares.

Que l’économie A2A s’étende au-delà de la crypto, et si HTTP 402 devient une couche de tarification générale pour les logiciels, revient effectivement à la même question. Les deux dépendent du fait que les agents deviennent des acteurs économiques routiniers, transigeant à grande échelle contre des annuaires de services riches, facturés à l’appel.

Conclusion : une pile en deux couches et les primitives manquantes

En regardant vers l’avenir, le commerce agentique continuera de se développer sur deux pistes distinctes. Les agents orientés consommateurs qui achètent des biens pour des humains s’appuieront pour l’essentiel sur des rails de cartes, en avançant au rythme des frameworks d’autorisation en entreprise et de la confiance des utilisateurs envers de nouvelles surfaces de paiement.

En parallèle, la pile de protocoles de commerce agentique pour des paiements logiciel-à-logiciel est déjà techniquement viable sur des rails en stablecoin. Il lui manque maintenant le déploiement d’agents et de services qui nécessitent une compensation programmatique à haute fréquence et à grande échelle.

L’état final probable est une pile en deux couches évoluant en parallèle : l’orchestration qui régit la découverte et l’initiation, et la compensation qui régit le transfert de valeur. Pour les concepteurs, la priorité stratégique est la largeur d’intégration sur les deux couches.

L’infrastructure capable d’acheminer n’importe quelle transaction d’agent via n’importe quel protocole requis par la contrepartie, tout en cachant cette complexité aux applications, occupera une position structurellement forte à mesure que le marché se développe. Cette couche sera invisible pour les utilisateurs finaux, mais gagnera en importance de manière cumulative.

Le déclencheur de l’échelle commerciale n’est pas de meilleurs protocoles. C’est le moment où les entreprises délèguent l’autorité de dépense aux agents avec des traces auditables, des contrôles de budget et une responsabilité claire en cas d’achats mal dirigés. Une fois ce seuil franchi, deux positions d’infrastructure deviennent critiques.

D’abord, un wallet multi-rails pour agents qui supporte à la fois les paiements en stablecoin et par carte dans une seule intégration. Ensuite, un répertoire de services accessible à l’appel, qui permet aux développeurs sans bagage crypto d’exposer des API à des acheteurs agents. Les deux sont des opportunités ouvertes aujourd’hui, et les deux deviennent essentielles une fois que les agents de dépense fonctionnent à grande échelle.