Architecture du commerce agentique : une couche de capacités MCP, quatre canaux d'IA

Points clés

• Quatre canaux d'accès IA (un portail propriétaire, l'ACP d'OpenAI, Meta Muse et des agents A2A externes) peuvent partager une seule couche de capacités MCP, au lieu de quatre réimplémentations distinctes de la même logique commerciale.
• La règle de décision tient en une ligne : n'ajoutez un adaptateur de protocole que lorsque le protocole externe diffère de MCP. L'Agentic Commerce Protocol d'OpenAI exige un adaptateur ACP→MCP ; un connecteur qui parle déjà MCP n'en demande aucun.
• Magento / Adobe Commerce reste le système de référence faisant autorité : ACP, MCP et A2A ne reproduisent jamais sa logique de prix, de stock, de taxes ou de commandes ; ils l'appellent.
• Les outils d'écriture sont contrôlés selon leur impact, à la frontière de l'outil : les lectures comme catalog.search_products circulent librement, tandis que les écritures sensibles comme order.submit et payment.authorize exigent une approbation humaine et l'idempotence.

Connectez votre catalogue e-commerce à ChatGPT, à Meta Muse et aux agents d'entreprises partenaires, et la conception naïve réimplémente votre logique de prix, de stock et de paiement quatre fois, une par plateforme. Chaque surface d'IA parle un protocole différent : OpenAI a lancé l'Agentic Commerce Protocol (ACP, co-développé avec Stripe), les agents dialoguent avec les outils via le Model Context Protocol (MCP), et les agents se délèguent des tâches via A2A. Le réflexe consiste à bâtir une pile d'intégration par plateforme. Ce réflexe est l'erreur coûteuse.

Cet article décrit une architecture neutre vis-à-vis des fournisseurs pour le commerce agentique : une couche de capacités MCP d'entreprise côté sud, de multiples canaux d'accès IA côté nord. Il prend Magento / Adobe Commerce comme exemple concret de système de référence commercial, mais le schéma s'applique à tout ERP, OMS ou catalogue. Le résultat central est une règle de décision unique, n'ajouter un adaptateur que lorsque le protocole de la plateforme externe doit être traduit en MCP, qui indique précisément où le code d'intégration a sa place et, plus utilement, où il n'en a pas.

Le piège : quatre plateformes, quatre réimplémentations

Chaque surface de commerce IA réclame les mêmes opérations de fond : rechercher dans le catalogue, vérifier le stock, obtenir un prix, constituer un panier, soumettre une commande. L'architecture naïve relie chaque surface directement à la plateforme commerciale avec sa propre logique :

• le site propriétaire → appels Magento sur mesure
• OpenAI / ChatGPT → d'autres appels Magento
• Meta Muse → encore d'autres appels Magento
• agents partenaires → encore un autre jeu

Dès lors, une modification de règle tarifaire, une nouvelle juridiction fiscale ou une correction de réservation de stock doit être effectuée, et testée, à quatre endroits. La logique métier a été copiée, et les copies divergent. C'est le même foisonnement de connecteurs qui renchérit l'intégration point à point à toute échelle, appliqué à des canaux d'IA plutôt qu'à des points d'accès SaaS.

La solution consiste à fusionner les quatre implémentations côté sud en une seule. Chaque canal atteint la même couche de capacités d'entreprise, exposée via MCP, adossée à des services commerciaux canoniques et, en dernier ressort, à Magento comme source unique de vérité pour les produits, les prix, les stocks, les paniers, les taxes et les commandes. Magento continue de porter la logique commerciale ; les canaux d'IA ne font que l'appeler.

La règle de décision : un adaptateur seulement en cas d'écart de protocole

Les canaux ne diffèrent que sur un point qui compte pour l'architecture : le protocole qu'ils parlent. Ce seul fait détermine si un canal a besoin d'un adaptateur de traduction ou peut se brancher directement sur MCP. Les trois protocoles ne sont pas concurrents : ils répondent à des questions différentes.

Technologie	De quoi s'agit-il	À quelle question répond-elle
HTTP / REST / JSON	Transport, style d'API, format de données	Comment les octets circulent
ACP	Interopérabilité du commerce IA (OpenAI + Stripe)	Comment une plateforme de commerce IA et un marchand effectuent une transaction
MCP	Interopérabilité entre agent/application et outil	Quels outils un agent ou une application peut appeler
A2A	Interopérabilité entre agents	Comment un agent délègue du travail à un autre

ACP et MCP résolvent des problèmes différents ; un adaptateur ACP est donc réellement nécessaire : il traduit la sémantique commerciale d'ACP (sessions de paiement, état des commandes, formats de flux) en appels d'outils MCP. A2A est lui aussi distinct : un agent externe délègue une tâche via A2A, qu'une passerelle achemine vers votre Agent Core, lequel appelle ensuite MCP. En revanche, une plateforme dont le modèle de connecteur consomme déjà MCP n'a besoin d'aucun adaptateur : elle atteint directement la couche de capacités.

C'est là le point à contre-courant. L'instinct dit : « une nouvelle plateforme d'IA, c'est un nouvel adaptateur ». La règle dit l'inverse : ne construisez un adaptateur que lorsque le protocole de la plateforme n'est pas MCP. Les quatre canaux se résolvent alors en quatre chemins d'accès, et non en quatre intégrations :

• Portail propriétaire → Agent Core → MCP
• OpenAI / ChatGPT → ACP → adaptateur ACP → MCP
• Meta Muse → connecteur Muse → MCP (aucun adaptateur : le connecteur parle MCP)
• Agent externe → A2A → passerelle A2A → Agent Core → MCP

Tout converge vers MCP. Cette convergence est toute la conception :

L'architecture en une vue :

Le serveur MCP Commerce est la frontière réutilisable

La couche de capacités est un serveur MCP qui expose un jeu restreint et stable d'outils commerciaux : catalog.search_products, pricing.get_price, inventory.check, cart.create, cart.add_item, order.submit, order.get_status. Tous les canaux utilisent les mêmes outils. L'Agent Core du portail propriétaire, l'adaptateur ACP, le connecteur Muse et les agents externes arrivant via A2A appellent tous catalog.search_products ; aucun n'implémente sa propre recherche de produits.

Point essentiel : MCP est l'interface de capacités, pas le modèle de données métier. Derrière les outils se trouvent des services commerciaux canoniques, un modèle indépendant du protocole (Product, Variant, Price, Inventory, Cart, Order), et un adaptateur Magento qui fait correspondre ce modèle canonique aux API d'Adobe Commerce. Lorsque le format de flux produits d'OpenAI ou le schéma de paiement d'ACP change, seul l'adaptateur ACP change. Lorsque l'API de Magento change, seul l'adaptateur Magento change. Les outils au milieu restent stables. C'est la même discipline structurelle qu'un module MCP gouverné : des outils typés, un contrat stable et les particularités du fournisseur isolées en périphérie.

Les outils sont classés par impact, et c'est dans cette classification que se loge la gouvernance. Les lectures (catalog.search, pricing.get, inventory.check) présentent peu de risque et circulent librement. Les écritures (cart.add_item) modifient l'état mais sont réversibles. Les écritures sensibles (order.submit, payment.authorize, refund.create) déplacent de l'argent ou créent des obligations : elles exigent une approbation humaine, des clés d'idempotence pour éviter les commandes en double et une journalisation d'audit, appliquées à la frontière de l'outil quel que soit le canal appelant. La couche de gouvernance propre à un connecteur (authentification, permissions des utilisateurs, points d'approbation humaine) se place en amont du serveur MCP, et non à sa place.

Pourquoi Meta Muse n'a pas besoin d'adaptateur, et ACP si

La meilleure illustration de la règle de décision est le contraste entre les deux plateformes d'IA externes. L'ACP d'OpenAI et MCP sont des protocoles différents ; le chemin ACP comporte donc un adaptateur qui traduit la sémantique commerciale d'ACP en appels d'outils MCP. À l'inverse, un modèle de connecteur qui soumet son intégration sous la forme d'un point d'accès MCP consomme directement la couche de capacités : la frontière de gouvernance est le processus de revue et le modèle de permissions du connecteur, mais il n'y a aucune seconde couche de traduction à construire ou à maintenir. En ajouter une « parce que Muse est une autre plateforme » reviendrait à créer une dette d'intégration sans aucune fonction.

Le même test vaut pour toute future surface d'IA. Une seule question : cette plateforme peut-elle consommer MCP directement ? Si oui, elle se branche sur le serveur existant et réutilise tous les outils. Sinon, vous ajoutez exactement un adaptateur de protocole, et rien d'autre. C'est ainsi que quatre canaux (puis un cinquième, puis un sixième) restent peu coûteux.

Au-delà du commerce : la même couche devient une plateforme d'agents d'entreprise

Le commerce n'est qu'un domaine MCP parmi d'autres. Le même Agent Core peut appeler un serveur MCP Commerce, un serveur MCP CRM et un serveur MCP ERP, et composer une demande comme « trouver les produits compatibles avec les achats précédents de ce client, à moins de 500 $, en stock, et préparer une recommandation » sur Commerce et CRM dans un seul plan. Pour la délégation externe, A2A, qui a dépassé 150 organisations dès sa première année, permet à l'agent d'achats d'une entreprise partenaire de déléguer à votre agent commercial, qui appelle votre couche MCP, sans accorder au partenaire d'accès direct aux systèmes internes. L'architecture commerciale et la pile d'entreprise MCP + A2A plus large constituent une seule et même architecture à des échelles différentes.

Un exemple de réalisation

Un marchand de taille intermédiaire sur Adobe Commerce voulait vendre dans ChatGPT et Meta Muse sans équipe plateforme dédiée. Nous avons d'abord construit les services commerciaux canoniques et l'adaptateur Magento, exposé six outils commerciaux MCP, puis appuyé l'Agent Core du portail propriétaire sur ces outils. OpenAI est venu ensuite : un adaptateur ACP et le transformateur de flux produits, en réutilisant exactement les mêmes outils en dessous. Meta Muse a été le canal le moins coûteux : le serveur MCP Commerce existant a été documenté (point d'accès, authentification, outils, classification lecture/écriture, approbations des écritures sensibles) et soumis à la revue du connecteur, sans écrire d'adaptateur propriétaire. Une seule couche de capacités ; chaque nouveau canal était un chemin d'accès, et non une refonte.

Lectures connexes

• Commerce Protocols for AI Agents: UCP, ACP, AP2, and MCP — How the Stack Fits Together — le paysage des protocoles sur lequel repose cette architecture, et quel protocole couvre quelle partie d'une transaction
• A2A vs MCP: Choosing the Right Protocol for Agent Communication — la distinction entre agent-à-agent et agent-à-outil qui situe la passerelle A2A et la couche MCP
• MCP Module Code Standard — le schéma structurel des outils MCP typés et gouvernés qui rendent la couche de capacités réutilisable

Construire une couche de commerce agentique sur votre propre pile (Adobe Commerce, un ERP, un CRM) commence par nommer une seule fois les capacités canoniques, et non une fois par plateforme.

Demandez une construction ciblée. Une semaine de cadrage. Vous recevez un inventaire des systèmes, une cartographie des flux de travail et un périmètre fixe, que vous construisiez ou non avec nous.