- Pour permettre aux agents IA d’effectuer de manière autonome des achats, des paiements et des règlements, plusieurs protocoles de paiement émergent en parallèle
- ACP, UCP, AP2, x402, etc. traitent tous du paiement, mais visent des domaines de problèmes différents, comme le commerce, le B2B ou les paiements entre agents
- L’internet a été conçu à l’origine pour le transport de l’information et ne comportait donc aucune couche de paiement ; le code d’état HTTP 402 a bien été défini en 1997, mais n’a jamais réellement été mis en œuvre
- Dans les transactions entre agents, une couche de confiance devient une condition préalable au paiement, rôle assuré par des protocoles comme ERC-8004 et Visa TAP
- Dans le commerce, ACP d’OpenAI et Stripe, ainsi que UCP de Google et Shopify, constituent les deux axes majeurs, déjà utilisés respectivement dans les environnements ChatGPT et Gemini
- Les paiements entre agents ouvrent la voie à des micropaiements massifs pour l’usage du calcul, des données et des API, et annoncent une structure d’échange autonome de ressources
- À terme, l’économie des agents pourrait évoluer non pas vers un standard unique, mais vers une architecture en pile combinant des protocoles aux rôles différents
Le contexte derrière la prolifération des protocoles de paiement agentiques
- ACP, UCP, A2P, AXTP, x402 et d’autres sigles se multiplient, ce qui rend l’espace des paiements agentiques assez confus
- S’il y a autant de protocoles, c’est qu’ils ne résolvent pas tous le même problème
- Le commerce, les paiements B2B et les paiements entre agents ont des exigences et des contraintes différentes
- Les traiter comme un seul et même problème complique au contraire la compréhension de l’ensemble
La structure des protocoles internet et l’absence de couche de paiement
- L’internet repose sur plusieurs protocoles comme TCP/IP, DNS et HTTP/S, qui fonctionnent ensemble pour créer une expérience utilisateur fluide
- TCP/IP : assure l’adressage, le routage et la transmission fiable des données
- DNS : convertit les noms de domaine lisibles par l’humain en adresses IP
- HTTP/S : gère les requêtes et le transfert des pages web et des médias, HTTPS renforçant la sécurité grâce au chiffrement
- De nouveaux protocoles comme gRPC ou WebSocket continuent d’être ajoutés, ce qui fait de l’internet un système évolutif plutôt qu’une structure figée
- Le code d’état HTTP 402 (Payment Required) a été défini en 1997, mais n’a jamais été utilisé en pratique
- L’internet a été conçu dès le départ pour le transport d’information, et le paiement n’y a été raccordé qu’ensuite via des systèmes financiers séparés
- Une requête initiée dans le navigateur est transmise successivement au marchand, à la passerelle de paiement, puis à des réseaux financiers comme Visa ou ACH
- Il n’existe pas de protocole de paiement unique couvrant de bout en bout tout le processus, de l’ajout au panier au règlement final
Les agents ont mis en lumière le vide de la couche de paiement
- L’infrastructure existante, conçue autour du clavier et de l’écran, n’est pas adaptée à des agents logiciels capables de raisonner et d’agir à la vitesse machine
- Quand un agent effectue un achat à la place d’un humain, de nouveaux problèmes apparaissent
- Nouveau type de client : l’agent doit décider seul quel magasin et quel produit choisir, et les vendeurs doivent désormais s’optimiser pour des agents plutôt que pour des humains
→ émergence du concept d’Agent Engine Optimization (AEO)
- Nouveau canal de paiement : l’interface conversationnelle devient elle-même le point de paiement, ce qui affaiblit l’importance des funnels de conversion, des tests A/B ou des e-mails d’abandon de panier
- Nouveaux risques de fraude : il faut vérifier immédiatement si l’agent utilise bien un utilisateur autorisé et des moyens de paiement légitimes, ou s’il exploite automatiquement des identifiants volés
La couche de confiance : vérifier la contrepartie
- MCP et A2A gèrent la communication entre agents, mais la spécification ERC-8004 indique explicitement qu’ils ne traitent pas fondamentalement la découverte des agents ni la confiance
- Avant toute transaction entre agents, il faut d’abord vérifier leur légitimité ; un marchand doit pouvoir n’autoriser que des agents fiables, et non des bots indistincts
- Deux approches ont émergé pour répondre à ce besoin
- ERC-8004 (Trustless Agents) : registre on-chain d’identité, de réputation et de vérification, au stade Draft EIP, auquel participent MetaMask, Google, Coinbase et l’Ethereum Foundation
- Les informations d’enregistrement d’un agent peuvent inclure un endpoint MCP, une carte d’agent A2A, un nom ENS, un DID, etc.
- La structure ne remplace pas les protocoles de communication existants entre agents ; elle vient les compléter avec des données de confiance et d’identité
- Visa Trusted Agent Protocol (TAP) : protocole en cours de développement chez Visa, fournissant des signatures vérifiables pour permettre aux marchands de distinguer les agents fiables des bots ordinaires
- Il prouve qu’il s’agit d’un agent de confiance Visa destiné au commerce
- Il confirme qu’il agit pour le compte d’un consommateur donné via, par exemple, un compte de fidélité ou un identifiant d’appareil
- Il permet aussi au marchand de vérifier des identifiants de paiement valides
- Point clé : la confiance est le point de départ du paiement ; avant même de se demander « comment payer ? », il faut résoudre la question « peut-on faire confiance à cet agent ? »
Les protocoles de commerce : le domaine qui s’étend le plus vite
- Le commerce agentique consiste à déléguer à un agent l’ensemble du moment d’achat : découverte du produit, sélection et paiement
- Deux protocoles clés émergent pour standardiser cet usage
- Agentic Commerce Protocol (ACP) : protocole co-développé par OpenAI et Stripe, définissant la manière de constituer un panier et de générer un token de paiement à transmettre à un PSP
- Déjà déployé en production avec Walmart, Etsy et Instacart dans l’environnement ChatGPT
- Un standard centré sur la transaction qui précise clairement la structure du panier, la génération du token de paiement et la procédure de finalisation du checkout
- Universal Commerce Protocol (UCP) : protocole piloté par Google et Shopify, dans lequel le marchand configure directement le serveur exposé aux agents
- Déploiement prévu progressivement dans Google Search et Gemini
- Un framework d’orchestration où le marchand publie un capability manifest, que l’agent découvre puis négocie
- Dans le commerce, il joue un rôle comparable à celui du DNS
- Différence structurelle : UCP impose une charge d’implémentation initiale plus élevée, mais offre davantage de flexibilité sur l’ensemble du parcours ; ACP est relativement plus simple à intégrer avec les systèmes de paiement existants
- Pour être visible à la fois dans ChatGPT et Gemini, il faut en pratique prendre en charge ACP et UCP ensemble
Les protocoles au niveau des réseaux de paiement
- Visa Intelligent Commerce (VIC) : protocole développé par Visa pour permettre à un agent d’effectuer des paiements sur le réseau Visa à l’aide de tokens de sécurité analogues à une carte
- Actuellement en phase de test, avec un lancement prévu au second semestre 2026
- Mastercard Agent Pay (MAP) : protocole développé par Mastercard pour générer des tokens de sécurité utilisables sur le réseau Mastercard
- Également en phase de test, avec un lancement prévu au second semestre 2026
- Ces deux standards ont une structure et un objectif presque identiques ; la différence essentielle est qu’ils ne fonctionnent chacun que sur leur propre réseau de paiement
- Les tokens émis au niveau du réseau permettent de conserver la protection du consommateur, la gestion des chargebacks et la lutte contre la fraude selon le même modèle que les paiements par carte existants
Les exigences spécifiques des flux de paiement B2B
- Le commerce grand public attire l’attention, mais en volume réel de transactions, les paiements B2B sont bien plus importants
- Paiement de factures, règlements fournisseurs, versement de salaires : la majorité des règlements se situe entre entreprises
- Les flux de paiement B2B ont des caractéristiques propres
- Les montants sont élevés et difficiles à annuler une fois exécutés
- Ils nécessitent des contrôles internes, comme le rapprochement de factures, les processus d’approbation et les pistes d’audit
- Ils s’appuient sur des rails comme l’ACH ou le virement bancaire, plus lents mais structurellement plus flexibles
- Dans ce domaine, les agents communiquent souvent directement avec les rails de paiement au lieu de passer par une couche intermédiaire
- Les rails utilisés incluent
- Stablecoins (USDC, USDT) : le paiement s’effectue directement on-chain, avec la possibilité d’intégrer des règles et de la logique dans la transaction elle-même
- Déjà utilisés en pratique par des entreprises comme Catena Labs ou Payman
- Rails traditionnels (ACH, Wire) : l’agent prépare les informations de paiement puis les transmet via les rails financiers existants
- Les stablecoins offrent des garanties de réussite proches de celles des paiements par carte, avec une programmabilité supérieure, mais aucun standard clair ne s’est encore imposé à l’échelle du secteur
Les paiements entre agents : le plus grand potentiel
- La plupart des ressources de valeur sur internet sont enfermées derrière des clés API et des modèles d’abonnement
- Le modèle actuel exige de créer un compte, de précharger un solde et d’obtenir une clé avant de pouvoir utiliser un service
- Dans un environnement où des milliards d’agents écrivent du code, échangent entre eux et utilisent des ressources à la demande, ce modèle ne passe pas à l’échelle
- Deux principaux points de friction apparaissent aujourd’hui
- Épuisement des tokens : si un agent atteint sa limite en cours de tâche, un humain doit intervenir pour recharger afin de poursuivre le travail
- Problème des clés API : chaque fois qu’un agent a besoin d’un nouveau service, l’utilisateur doit s’inscrire lui-même, créer les identifiants et les transmettre
- À cause de ces contraintes, les agents restent loin de l’autonomie complète et occupent une position comparable à celle d’un développeur junior à qui l’on ne peut pas confier la carte de l’entreprise ni les identifiants critiques
Protocoles natifs pour les agents
- Google Agent to Pay (AP2) : composant du framework A2A, qui définit une structure de mandate permettant à un humain de déléguer à un agent le pouvoir de payer
- Conçu comme une couche d’abstraction fonctionnant avec x402 et UCP ; il ne s’agit donc pas de protocoles mutuellement exclusifs
- Sur la base d’identifiants vérifiables, il distingue les mandates suivants
- cart mandate : le périmètre des achats que l’agent peut effectuer
- intent mandate : l’objectif réellement voulu par l’humain
- payment mandate : les identifiants de paiement enregistrés
- HTTP x402 : approche développée par Coinbase et Cloudflare, qui retourne un HTTP 402 lorsqu’une ressource à accès restreint est demandée et incite à payer en stablecoins
- Des tests sont en cours sur le réseau Base et dans l’environnement Cloudflare
- Agent Transaction Protocol (AXTP) : protocole en développement chez Circuit et Chisel, conçu pour permettre à un agent de payer l’usage d’un serveur MCP ou d’en tirer des revenus
- Encore à un stade précoce
- Cela ouvre la voie à des micropaiements massifs, instantanés et fractionnés à l’unité de calcul, de donnée ou d’appel API, avec la possibilité de créer un volume considérable de nouvelles transactions dans des domaines jusque-là mal monétisés
Structure d’ensemble des protocoles et perspectives
- À ce stade, l’écosystème des paiements agentiques reste hétérogène et peu structuré
- Formation d’une pile centrée sur Google : une structure A2A → AP2 → UCP est en train d’émerger, couvrant à la fois les paiements commerciaux et non commerciaux
- Chaque protocole joue un rôle à un niveau d’abstraction différent
- Couche de communication entre agents : standardiser la manière dont les agents échangent des messages (MCP, A2A)
- Couche de confiance : évaluer l’identité et la fiabilité des agents, gérer identité et réputation (ERC-8004, Visa TAP)
- Couche de délégation : vérifier les autorisations de paiement et la possession des identifiants nécessaires (mandates AP2, tokens VIC/MAP)
- Couche de flux transactionnel : gérer la découverte, la négociation et le checkout autour de quoi acheter et comment payer (ACP, UCP)
- Couche d’authentification : valider la légitimité de la transaction, maintenir la sécurité, prévenir la fraude et traiter les annulations
- Couche des rails de paiement : exécuter le paiement réel via carte, ACH ou stablecoins
Principaux enseignements
- Les standards actuels sont encore en phase de formation, imparfaits et peu adoptés
- Certains pourraient disparaître à terme, comme WAP ou Betamax
- Mais cela supposerait la disparition des agents IA eux-mêmes, une hypothèse peu probable
- Les points à surveiller pour les marchands, les prestataires de paiement et les institutions financières
- L’influence de Google : l’entreprise a déjà façonné des standards internet par le passé, et la pile A2A·AP2 ainsi que les couches associées pourraient s’inscrire dans la durée
- La stratégie commerce d’abord : prendre en charge ACP et UCP permet d’être visible dans les deux grands environnements LLM grand public, ChatGPT et Gemini
- L’importance de l’infrastructure de confiance : à mesure que le trafic agentique augmente, les questions d’identité et de réputation deviennent plus complexes, ce que visent ERC-8004 et Visa TAP
- L’opportunité B2B : un domaine à fort volume où les standards restent flous ; l’adoption des stablecoins progresse, mais sans cadre clair
- Le potentiel des paiements natifs pour agents : des stablecoins rapides, peu coûteux, disponibles en continu et programmables apparaissent comme la solution la plus crédible ; x402 constitue un point de départ, mais reste encore immature
- La prochaine étape de l’environnement des paiements agentiques passera probablement par des combinaisons entre protocoles et un héritage fonctionnel entre couches
- Le basculement vers des logiciels capables de découvrir eux-mêmes des ressources, d’en négocier les conditions et d’en payer l’usage est déjà en cours, quel que soit le standard qui survivra
Aucun commentaire pour le moment.