Aller au contenu
Universal Commerce Protocol Hub de marque / fr

Comparatif

UCP vs MCP : ce ne sont pas des concurrents.

On les oppose souvent parce qu'ils portent tous deux le mot « protocole ». En réalité, le Model Context Protocol (Anthropic) et le Universal Commerce Protocol (Google, Shopify) travaillent à deux étages différents : l'un connecte l'agent à ses outils, l'autre porte l'achat. Voici comment ils s'articulent, avec un schéma, un scénario concret et un quiz.

L'essentiel en 30 secondes

  • MCP (Anthropic, nov. 2024) : comment un agent se connecte aux outils et aux données. Une couche de contexte, sans commerce ni paiement.
  • UCP (Google/Shopify, janv. 2026) : comment un agent découvre et achète chez un marchand. Une couche transactionnelle.
  • Ils ne se concurrencent pas : couches différentes. UCP peut même être exposé au travers d'un transport MCP.
  • Pour un marchand : MCP ne remplace pas UCP. C'est UCP (ou ACP) qui porte la transaction ; MCP est un moyen d'y accéder.

Où se situent MCP et UCP dans la pile agentique

Le plus simple est de les regarder comme des étages. Un agent se connecte d'abord aux outils (transport), puis découvre et déclenche un achat (commerce), puis règle (paiement). MCP est un standard de l'étage du bas ; UCP, de l'étage du milieu. Établi

La pile du commerce agentique Trois couches empilées : paiement et autorisation en haut, commerce au milieu, transport et connexion en bas. UCP se situe dans la couche commerce, MCP dans la couche transport. Agent PAIEMENT & AUTORISATION AP2 Visa Intelligent Commerce Mastercard Agent Pay x402 COMMERCE UCP ACP découverte, catalogue, commande — le marchand reste vendeur de record TRANSPORT & CONNEXION MCP A2A REST comment l'agent accède aux outils, données et capacités

MCP et UCP ne sont pas sur la même ligne : l'un transporte, l'autre décrit le commerce.

Le comparatif dimension par dimension

Dimension UCP (commerce) MCP (contexte / outils)
Nature Protocole de commerce agentique : découverte et achat chez un marchand Protocole de connexion agent-outils : accès aux outils, données et systèmes
Créateur Google et Shopify, avec Etsy, Wayfair, Target, Walmart et 20+ partenaires Anthropic, en open source (protocole ensuite donné à une fondation)
Apparition Janvier 2026 (NRF) Novembre 2024
Question résolue « Comment un agent découvre-t-il et achète-t-il chez un marchand ? » « Comment un agent accède-t-il aux outils et aux données dont il a besoin ? »
Périmètre Vertical : la transaction commerciale Horizontal : n'importe quel outil ou source de données
Découverte Manifeste marchand standardisé /.well-known/ucp Serveur MCP exposant des ressources, des outils et des invites à un client
Paiement Gestionnaires de paiement modulaires (Google Pay, Shop Pay...) Hors périmètre : MCP ne traite pas les paiements
Vendeur de record Le marchand Sans objet (MCP ne transige pas)
Relation à l'autre Peut être exposé via un transport MCP Peut servir de transport à un catalogue ou une capacité UCP
Code Open source : spec, SDK Python, exemples sur GitHub Open source : spec ouverte et SDK multiples (Python, TypeScript...)

La confusion vient d'un mot : « protocole »

MCP et UCP sont tous deux des standards ouverts, portés par des acteurs majeurs, arrivés à quelques mois d'intervalle. D'où la tentation de les mettre en concurrence. Mais ils ne décrivent pas la même chose. Établi

MCP est une couche de contexte. Il répond à une question d'accès : comment un agent branche-t-il ses outils, ses fichiers, ses bases de données, ses API ? Publié par Anthropic en novembre 2024, il définit une architecture client-serveur où l'agent (le client) découvre et invoque des ressources exposées par des serveurs. En 2026, c'est devenu la manière standard de connecter un agent au monde extérieur.

UCP est une couche transactionnelle. Il répond à une question de commerce : comment un agent découvre-t-il un marchand, lit-il son catalogue à jour, et déclenche-t-il un achat dont le marchand reste vendeur de record ? C'est un standard vertical, spécialisé, là où MCP est horizontal et générique.

Un scénario concret, de bout en bout

Imaginons un agent chargé d'acheter une paire de chaussures de running en taille 43, budget 120 €.

  1. Connexion (MCP). L'agent se connecte au serveur MCP du marchand et découvre les outils exposés : rechercher un produit, lire une fiche, vérifier le stock.
  2. Découverte commerce (UCP). À travers ces outils, il lit le manifeste et le catalogue UCP du marchand : modèles disponibles, tailles, prix à jour, politique de retour.
  3. Décision. L'agent sélectionne un modèle en 43 à 110 €, conforme aux contraintes.
  4. Transaction (UCP). Il déclenche la commande selon UCP. Le marchand reste vendeur de record : facturation, SAV et responsabilité juridique restent chez lui.
  5. Paiement (AP2 / gestionnaire). Le règlement passe par un gestionnaire de paiement ou une autorisation par mandat (AP2), dans les limites fixées par l'utilisateur. MCP n'intervient pas ici.

À aucun moment MCP et UCP ne se sont « affrontés » : MCP a ouvert la porte, UCP a décrit la vente, une couche paiement a réglé. Émergent

Trois idées reçues

« MCP va remplacer UCP »

Non : ils ne couvrent pas le même besoin. MCP standardise l'accès aux outils et aux données ; il ne décrit ni un catalogue marchand, ni une commande, ni un règlement. Un marchand qui n'expose que MCP n'est pas « vendable » par un agent tant qu'une couche commerce (UCP ou ACP) ne décrit pas la transaction.

« Il faut choisir MCP ou UCP »

Faux dilemme. Un éditeur d'outils n'a souvent besoin que de MCP ; un marchand, souvent que de UCP ; une plateforme, des deux. Et quand les deux sont présents, ils s'empilent : MCP transporte, UCP décrit le commerce.

« MCP sert à payer »

Non. Le paiement agentique relève de standards dédiés : les gestionnaires de paiement de UCP, l'Instant Checkout / Visa côté ACP, ou l'autorisation par mandats cryptographiques d'AP2. MCP reste en amont, sur l'accès aux capacités.

Ce qu'ils partagent

  • L'open source comme stratégie d'adoption : spécifications publiques des deux côtés, pour devenir des standards de fait plutôt que des produits fermés.
  • La même hypothèse de fond : l'agent devient une surface d'usage à part entière, et il faut des standards pour qu'il agisse sans intégration bilatérale à chaque fois.
  • Le même prérequis côté marchand : des données exactes et des capacités explicites. Qu'on les expose via MCP ou via UCP, un catalogue pauvre reste pauvre.

Pour préparer ce socle, la méthodologie d'audit de readiness évalue votre état couche par couche, et le guide d'implémentation UCP détaille la marche à suivre côté commerce. La note UCP, Catalog MCP et WebMCP sur Shopify montre comment ces couches se traduisent dans une implémentation actuelle.

Comprendre MCP en vidéo

Anthropic revient sur les raisons d'être de MCP et sur son passage en gouvernance ouverte.

Source : chaîne officielle Anthropic (YouTube, mode sans cookie).

Testez votre compréhension

  1. 1. Qui a publié MCP ?

  2. 2. Le paiement d'un achat agentique est porté par…

  3. 3. UCP et MCP sont…

  4. 4. Dans UCP, un marchand se rend découvrable via…

  5. 5. Un serveur MCP peut-il exposer un catalogue UCP ?

Questions fréquentes

01

UCP et MCP sont-ils concurrents ?

Non. Ils opèrent à deux couches différentes de la pile agentique. MCP répond à « comment un agent accède-t-il aux outils et aux données ? » ; UCP répond à « comment un agent découvre-t-il et achète-t-il chez un marchand ? ». On peut utiliser les deux en même temps : ils ne se remplacent pas, ils s'empilent.

02

MCP sert-il à payer un achat ?

Non. MCP est un protocole de contexte et d'outils : il standardise la connexion entre un agent et des ressources externes, pas le règlement d'une transaction. Le paiement agentique relève d'autres standards : UCP (via ses gestionnaires de paiement), ACP côté OpenAI, ou l'autorisation par mandats d'AP2.

03

Un serveur MCP peut-il exposer un catalogue UCP ?

Oui, et c'est là que les deux se rejoignent. La spécification UCP prévoit quatre transports (REST, MCP, A2A et embedded). Un marchand peut donc exposer ses capacités UCP au travers d'un serveur MCP : l'agent se connecte via MCP, découvre les outils du marchand, puis invoque la transaction selon UCP. MCP est le tuyau, UCP est ce qui circule côté commerce.

04

Faut-il choisir entre implémenter MCP ou UCP ?

La question ne se pose pas dans ces termes : ils répondent à deux besoins distincts. MCP intéresse surtout ceux qui exposent des outils et des données à des agents (SaaS, bases internes, API). UCP intéresse les marchands qui veulent être découvrables et transigeables par des agents. Un marchand peut n'avoir besoin que de UCP ; un éditeur d'outils, que de MCP ; une plateforme, des deux.

05

Qu'est-ce que MCP, concrètement ?

Le Model Context Protocol est un standard ouvert publié par Anthropic en novembre 2024. Il définit une architecture client-serveur par laquelle une application d'IA (le client) se connecte à des serveurs qui exposent des ressources, des outils et des invites. Son ambition est d'être un connecteur universel entre les modèles et le monde extérieur, souvent décrit comme un « port universel » pour l'IA. En 2026, il s'est imposé comme la façon standard de brancher un agent sur des outils.

06

Où se situe le paiement dans tout ça ?

Au-dessus du commerce. Une fois la transaction décrite par UCP (ou ACP), le règlement passe par une couche d'autorisation et de paiement : gestionnaires de UCP, Visa Intelligent Commerce et Mastercard Agent Pay côté réseaux, AP2 pour l'autorisation par mandats cryptographiques, ou x402 pour le règlement en stablecoins. MCP n'intervient à aucun de ces étages.

Aller plus loin

Le comparatif des standards de commerce, la référence UCP et le contexte du paiement agentique.