
Commerce agentique
Qu'est-ce que le MCP et à quoi sert-il pour l'e-commerce ?
Mis à jour le
Le MCP — le Protocole de Contexte de Modèle, publié par Anthropic — est une spécification ouverte décrivant comment un agent IA découvre les outils qu'il peut appeler et les appelle ensuite avec des arguments typés. Dans l'e-commerce, c'est le mécanisme par lequel un assistant apprend que votre boutique expose des opérations comme "rechercher dans le catalogue", "créer une commande brouillon" ou "émettre un remboursement", et les invoque directement au lieu de simuler un humain cliquant dans une interface utilisateur d'administration. Le protocole ne comporte pas de modèle de permission propre, donc la définition des portées et l'audit relèvent de la responsabilité de la plateforme marchande.
Ce qu'est le MCP, précisément
Le MCP standardise la poignée de main entre un agent et un fournisseur d'outils. Un serveur annonce un ensemble d'outils, chacun avec un nom, une description et un schéma typé pour ses arguments. Un agent se connecte, lit cette liste et appelle ce dont il a besoin. C'est véritablement toute l'idée, et sa valeur réside dans le fait d'être ennuyeux et universel plutôt qu'ingénieux.
Ce n'est pas un protocole de commerce. Il ne dit rien sur les paniers, les prix, les flux ou l'autorisation de paiement. C'est la couche sous-jacente : comment l'agent découvre qu'une capacité de commerce existe tout court. La révision d'avril 2026 de l'ACP s'appuie exactement sur cela, incluant un crochet pour que les agents compatibles ACP puissent annoncer la capacité de paiement via la découverte d'outils MCP.
Ce qu'un serveur MCP de commerce devrait exposer
La conception tentante est de refléter votre API REST un-à-un. Cela produit un serveur avec des centaines d'outils, et les agents choisissent mal parmi de longues listes d'options quasi identiques.
La meilleure conception est d'exposer les opérations à l'altitude où un opérateur humain les décrirait, la plateforme se chargeant de l'orchestration sous-jacente. "Lancer une campagne avec ce budget auprès de cette audience" est un seul outil. Les six appels API dans lesquels il se décompose ne sont pas six outils.
- Opérations de lecture — recherche de catalogue, recherche de commande, niveaux de stock, historique client, requêtes d'analyse. Sûres, de grande valeur, et là où la plupart des utilisations d'agents se produisent réellement.
- Opérations de brouillon — créer une commande brouillon, préparer une réduction, composer une campagne. Produire un artefact révisable plutôt qu'un changement validé.
- Opérations de validation — publier, facturer, rembourser, expédier. Ce sont celles qui nécessitent une porte de validation.
- Introspection — permettre à l'agent de demander ce qu'il est autorisé à faire. Un agent qui peut lire ses propres portées cesse de tenter des appels qui lui seront refusés.
La partie que le protocole ne vous donne pas
Le MCP définit la découverte et l'invocation. Il ne définit pas qui est autorisé à appeler quoi, ce qui se passe lorsque le même appel arrive deux fois, ou comment vous reconstituez après coup ce qu'un agent a fait et pourquoi. Ce sont ces propriétés qui décident si un agent interagissant avec une boutique en direct est un atout ou un incident, et chacune d'elles relève de la responsabilité de la plateforme.
Quatre contrôles sont non négociables avant qu'un agent n'obtienne une clé qui peut dépenser : des portées par clé afin qu'une clé puisse être accordée en lecture seule ou pour une tranche étroite d'écriture ; l'idempotence afin qu'un appel réessayé ne puisse pas facturer deux fois ; un enregistrement d'audit durable liant chaque action à la clé appelante et à la requête initiale ; et une porte d'approbation qui arrête le mouvement d'argent en attendant l'approbation humaine.
PlatformDTC implémente ces quatre contrôles dans l'Agent Gateway et expose les mêmes opérations via le MCP, ainsi le modèle de sécurité ne dépend pas du transport utilisé par l'agent pour l'atteindre.
Questions fréquentes
- Le MCP est-il un concurrent de l'ACP ou de l'UCP ?
- Non — il se situe en dessous des deux. Le MCP gère la découverte et l'invocation d'outils de manière générale ; l'ACP et l'UCP spécifient la sémantique commerciale comme les flux, les paniers et les sessions de paiement. L'ACP s'intègre explicitement au MCP afin que les agents puissent découvrir la capacité de paiement via la liste d'outils MCP.
- Puis-je exposer mon administration Shopify ou d'une autre plateforme via le MCP ?
- Vous pouvez placer un serveur MCP devant n'importe quelle API que vous contrôlez. La difficulté ne réside pas dans la liaison du protocole, mais dans tout ce que la plateforme sous-jacente ne vous offre pas : des identifiants à portée plus étroite qu'un jeton d'administrateur complet, l'idempotence sur les écritures, et une piste d'audit attribuant les actions à un agent plutôt qu'à l'application propriétaire du jeton.
- Qu'est-ce qui empêche un agent de faire quelque chose de destructeur ?
- Rien dans le MCP lui-même — c'est le point à intérioriser. Les contrôles doivent résider dans le serveur : des portées qui rendent l'appel destructeur indisponible pour cette clé, une porte d'approbation sur les actions irréversibles, et l'idempotence afin qu'une tempête de réessais ne puisse pas multiplier un effet. Traitez une clé d'agent comme vous traiteriez une clé d'intégration tierce, et non comme un appelant interne de confiance.
Sources
- Spécification du Protocole de Contexte de Modèle — Anthropic
- Normes de commerce agentique : UCP vs ACP vs AP2 — Digital Applied