Protocoles de commerce pour agents IA : UCP, ACP, AP2 et MCP — Comment la pile s'articule

Points clés

• UCP compte 11 co-développeurs dont Google, Shopify, Amazon, Meta et Stripe — il s'étend du shopping vers l'hébergement et la restauration, ce qui en fait la coalition de protocoles de commerce la plus large à août 2026.
• ACP est gouverné par OpenAI et Stripe (désormais rejoints par Meta), en bêta, et en direct dans ChatGPT depuis septembre 2025 — il couvre le paiement piloté par agent mais pas le workflow d'achat B2B.
• AP2 sécurise les paiements pilotés par agent sur plus de 60 organisations, avec Coinbase x402 comme extension stablecoin — x402 a traité 100 millions de paiements agentiques sur Coinbase Base à date de 2026.
• MCP est la couche d'intelligence sous-jacente à la fois à UCP et à ACP — chaque boutique Shopify UCP expose un endpoint MCP actif, et l'architecture à trois couches d'ACP place MCP au milieu.
• Aucun des quatre protocoles ne couvre la couche sémantique B2B — la tarification par palier client, les devis RFQ en volume, les réservations de stock contre un ERP et l'attribution des commandes entre canaux nécessitent tous un module MCP personnalisé en plus.

Deux standards ouverts ont été lancés à quelques mois d'intervalle en 2025–2026 pour résoudre le même problème sous des angles différents : comment un agent IA découvre-t-il un produit, négocie-t-il un prix, finalise-t-il un paiement et paie-t-il — sans qu'un humain doive câbler une intégration sur mesure pour chaque boutique ? Le Universal Commerce Protocol (UCP) a été co-développé par Google et Shopify avec 11 co-développeurs dont Amazon, Meta, Microsoft, Salesforce et Stripe. Le Agentic Commerce Protocol (ACP) est maintenu par OpenAI et Stripe et est en direct dans ChatGPT depuis septembre 2025. Un troisième protocole, le Agent Payments Protocol (AP2), sécurise la couche de mandat de paiement avec plus de 60 organisations participantes. Les trois s'appuient sur le Model Context Protocol (MCP), qui fournit la connexion de couche d'intelligence entre un agent et les données d'une boutique.

Cet article cartographie où chaque protocole s'inscrit, comment ils se recoupent, et où se situe l'écart pour le commerce B2B — car les quatre protocoles ont été conçus pour la découverte et le paiement grand public, pas pour les workflows de devis, de tarification par palier et de réservation de stock dont un distributeur de taille moyenne exploitant NetSuite ou BigCommerce a réellement besoin.

La pile à quatre couches

Le paysage des protocoles de commerce n'est pas un standard unique. C'est une pile de quatre protocoles complémentaires, chacun résolvant une couche différente de la transaction de l'agent :

Couche	Protocole	Gouverné par	Ce qu'il fait	Statut de production
Découverte et commerce	UCP	Google, Shopify, 11 co-développeurs	L'agent découvre des produits, constitue des paniers, transfère au marchand pour le paiement, suit les commandes	En direct (Shopify Spring '26 Edition) ; s'étend à l'hébergement et à la restauration
Interaction de paiement	ACP	OpenAI, Stripe, Meta	Modèle d'interaction d'achat piloté par agent ; architecture à trois couches (Interaction → Intelligence → Commerce)	Bêta ; en direct dans ChatGPT depuis sept. 2025
Mandat de paiement	AP2	Google, 60+ organisations, FIDO Alliance	Identifiants vérifiables, mandats de paiement, piste d'audit cryptographique pour les paiements pilotés par agent	v0.2 ; standardisation en cours au sein de la FIDO Alliance
Intelligence et outils	MCP	Anthropic (à l'origine)	Connexion agent-outil : lecture des données produit, interrogation des stocks, appel des API de la boutique	Spec finale 2026-07-28 ; ~20K serveurs enregistrés

MCP n'est pas un protocole de commerce — c'est la couche d'intelligence dont dépendent à la fois UCP et ACP. La spécification d'UCP indique explicitement « support MCP intégré ». L'architecture à trois couches d'ACP place MCP au milieu : la couche Interaction (agent-acheteur) se trouve au-dessus, la couche Intelligence (MCP) connecte l'agent aux données de la boutique, et la couche Commerce gère l'exécution. Chaque boutique Shopify qui implémente UCP expose un endpoint MCP actif permettant aux agents d'interroger les catalogues de produits, de gérer les paniers et de récupérer l'état des commandes.

UCP — le standard de la découverte au paiement

UCP est la coalition la plus large. Le site ucp.dev répertorie 11 co-développeurs répartis sur trois secteurs : le shopping (Google, Shopify, Etsy, Wayfair, Target, Walmart, Amazon, Microsoft, Meta, Salesforce, Stripe), l'hébergement (Amadeus, Booking.com, Expedia, Hilton, Marriott, Trip.com) et la restauration (DoorDash, Square, Toast, Uber Eats). La liste des partenaires approuvés inclut Visa, Mastercard, Coinbase, PayPal, Adyen, Klarna et Worldpay.

UCP prend en charge les transports REST et JSON-RPC, avec un support intégré pour AP2, A2A et MCP. La documentation développeur de Shopify confirme que les outils MCP de Shopify implémentent UCP à chaque étape du parcours acheteur : négocier et authentifier (niveaux de confiance basés sur le profil), découvrir des produits (recherche parmi des centaines de millions d'annonces), paniers et paiement (constituer des paniers, les convertir en paiements, transférer au marchand pour le règlement) et surveiller les commandes (webhooks de commande et état de commande à la demande via l'outil MCP get_order).

L'Universal Cart API permet à un agent IA de rassembler des articles de n'importe quel marchand — sur ou hors Shopify — dans un seul panier unifié via UCP. Le programme de certification de Shopify (Shopify + OpenAI + Google, bêta fermée, accès élargi au T3 2026) crée ce qui équivaut à une nouvelle couche de découverte pour les agents : des données structurées propres déterminent si un agent peut trouver une boutique et transiger avec elle.

ACP — le modèle d'interaction de paiement

ACP adopte une approche architecturale différente. Plutôt qu'une large coalition multi-sectorielle, il est gouverné par OpenAI et Stripe (la documentation de Stripe liste désormais Meta comme co-créateur) en tant que Founding Maintainers, avec une voie vers une gouvernance communautaire plus large. La spécification est en bêta sous licence Apache 2.0.

ACP définit des blocs de construction composables pour le commerce piloté par agent. L'Agentic Commerce Suite de Stripe fournit l'implémentation de référence : les agents découvrent des produits, les ajoutent à des paniers et finalisent des achats en utilisant l'infrastructure de paiement de Stripe. BigCommerce a adopté la voie ACP via son partenariat avec Stripe plutôt que de construire un serveur MCP first-party pour les données de boutique — l'article sur le connecteur BigCommerce traite ce sujet en profondeur.

L'architecture ACP à trois couches — Interaction → Intelligence (MCP) → Commerce — signifie que MCP est le tissu conjonctif. Un agent ne contourne pas MCP pour utiliser ACP ; il utilise MCP pour dialoguer avec la boutique et ACP pour structurer l'interaction d'achat.

AP2 — la couche de mandat de paiement

AP2 se situe sous UCP et ACP en tant que protocole de confiance de paiement. Google a annoncé AP2 en septembre 2025 avec plus de 60 organisations partenaires. Il est désormais en cours de standardisation au sein de la FIDO Alliance. AP2 étend A2A (communication agent-à-agent) avec des mandats de paiement structurés — Intent Mandates, Cart Mandates et Payment Mandates — qui fournissent une preuve vérifiable et non répudiable qu'un utilisateur a autorisé un agent à effectuer un achat spécifique.

Coinbase x402 est l'extension stablecoin d'AP2, nommée d'après le code de statut HTTP 402 (« Payment Required »). x402 permet aux agents de payer des appels d'API, des services et des micro-transactions directement en stablecoins via HTTP. Chainalysis a rapporté que x402 a dépassé les 100 millions de paiements agentiques sur Coinbase Base, démontrant que le rail stablecoin fonctionne à l'échelle de la production.

Trois réseaux de paiement concurrents se sont formés autour du commerce agentique : Visa Trusted Agent, Mastercard Agent Pay (30+ partenaires sectoriels, Agentic Tokens via MDES) et Coinbase x402. Stripe provisionne des tokens de réseau agentiques à la fois de Mastercard et de Visa, se positionnant comme le pont entre les rails de carte traditionnels et la couche de paiement des agents.

La pile de protocoles de commerce à quatre couches, avec l'écart de la couche sémantique B2B qui nécessite un module MCP personnalisé :

Où la pile converge — et où elle ne converge pas

Les quatre protocoles convergent vers une architecture partagée : UCP ou ACP pour l'interaction de commerce, AP2 pour le mandat de paiement, MCP pour la couche d'intelligence, et A2A pour la délégation agent-à-agent. La spécification UCP référence explicitement AP2, A2A et MCP comme intégrations natives. La documentation AP2 référence explicitement A2A et UCP. La pile est conçue pour interopérer.

Mais la convergence est façonnée pour le grand public. Les protocoles résolvent un problème spécifique : un agent découvre un produit, négocie un prix, finalise un paiement et paie. C'est le parcours du consommateur. Un distributeur B2B de taille moyenne traitant 200 RFQ par semaine n'a pas de problème de paiement — il a un problème de palier tarifaire, un problème de réservation de stock et un problème de réécriture vers l'ERP.

L'écart est la couche sémantique B2B :

• Tarification par palier client. UCP et ACP exposent les prix publiés d'une boutique. Les prix d'un distributeur B2B sont par client, par contrat, par palier de volume — stockés dans des groupes de clients NetSuite ou BigCommerce, pas dans un catalogue public. Aucun protocole de commerce ne négocie la tarification par palier.
• Devis RFQ en volume. Les protocoles grand public gèrent les achats d'un seul article. Les achats B2B fonctionnent avec des RFQ : un acheteur envoie une demande pour 500 unités avec une fenêtre de livraison, le fournisseur répond avec un devis, l'acheteur négocie. L'article sur l'architecture du moteur RFQ traite ce workflow en profondeur.
• Réservations de stock contre un ERP. Un paiement grand public réserve le stock au moment de l'achat. Un devis B2B nécessite une réservation de disponibilité — une réservation à durée limitée contre le stock NetSuite ou Brightpearl qui expire si le devis n'est pas accepté. Aucun outil UCP ou ACP ne fournit cela.
• Attribution des commandes entre canaux. Une commande B2B passée par un agent doit être attribuée au bon compte client, au bon commercial et au bon contrat dans l'ERP. Les protocoles grand public supposent une identité acheteur unique.

Un module MCP personnalisé comble cet écart. Le MCP Module Code Standard définit le pattern structurel : définitions d'outils typées, traductions de couche sémantique entre l'agent et l'ERP, gouvernance des limites de débit et une piste d'audit. Le module se situe au-dessus des protocoles de commerce — il ne remplace pas UCP ni ACP, il les étend vers les workflows B2B que les protocoles grand public n'ont pas été conçus pour couvrir.

Lectures connexes

• "Connecter un agent IA à BigCommerce avec MCP : ce que le partenariat Stripe ne résout pas" — l'analyse par connecteur de la voie ACP de BigCommerce et de l'écart de la couche sémantique B2B
• "Quand un agent IA vend en votre nom : connecter Shopify à la pile B2B" — comment les serveurs MCP de Shopify conformes à UCP couvrent la moitié grand public et où un module personnalisé s'étend vers le B2B
• "MCP + A2A : les deux protocoles derrière chaque système d'IA agentique en production" — la vue d'ensemble de la pile de protocoles que cet article étend vers la couche commerce

Build représentatif

Un distributeur industriel de taille moyenne exploitant BigCommerce pour son catalogue en ligne et NetSuite comme ERP reçoit 150 RFQ par semaine par email. Chaque RFQ nécessite une consultation de prix par palier client, une réservation de disponibilité de stock et un devis référençant les termes du contrat du client. Les protocoles de commerce grand public — UCP pour la découverte de produits, ACP pour le paiement, AP2 pour le règlement — ne touchent aucune de ces étapes. Un module MCP personnalisé comble l'écart : il expose des outils typés pour la consultation de tarification par palier, la création de réservations de disponibilité et l'assemblage de devis qu'un agent appelle après avoir découvert des produits via le protocole de commerce standard. L'agent gère le RFQ de bout en bout — découverte, tarification, réservation, devis, approbation humaine — tandis que le module MCP gouverne la réécriture vers l'ERP et la piste d'audit. Premier agent en direct en 5 à 8 semaines.

Demandez un build cadré. Discovery d'une semaine. Vous obtenez un inventaire des systèmes, une cartographie des flux et un périmètre fixe — que vous construisiez avec nous ou non.