E-commerce
26 août 2026
Choisir entre MCP et API pour piloter vos agents e-commerce, ce n’est pas une question de stack à la mode. C’est une décision d’architecture : laissez-vous le système raisonner tout seul, ou préférez-vous dicter chaque étape ? Anthropic a lancé le Model Context Protocol fin 2024, et depuis, le débat fait rage. D’un côté, ceux qui y voient une révolution. De l’autre, ceux qui n’y voient qu’une surcouche inutile. La vérité se situe entre les deux, et pour un marchand Shopify, se tromper de camp se paie cash : paniers abandonnés, parcours clients cassés, conversion en berne. Les API classiques restent imbattables pour ce qui est prévisible et rapide. MCP brille quand l’environnement bouge sans arrêt et que l’intention client est floue. On vous aide à voir clair.
Sommaire
API classiques : des serveurs qui obéissent au doigt et à l’œil
Les API REST et GraphQL fonctionnent comme des serveurs au restaurant. Vous passez commande, ils vous apportent exactement ce que vous avez demandé. GET /products/12345 renvoie le produit 12345. Ni plus, ni moins. Pas d’interprétation, pas de suggestion, pas d’adaptation si le menu change en cours de route. Pendant vingt ans, cela a très bien marché. L’e-commerce tournait sur des cycles requête-réponse déterministes, et personne ne s’en plaignait.
Le problème, c’est que vos catalogues bougent tous les jours. Les promos apparaissent et disparaissent. L’intention client est rarement linéaire et ne se map pas proprement sur un seul endpoint. Pour gérer cette complexité croissante, vous empilez les intégrations custom, vous codez des orchestrations sur mesure, et vous priez pour que tout tienne en production. Les API classiques restent ultra-performantes pour ce qui est figé, mais elles montrent leurs limites dès que l’environnement devient imprévisible.
200+ ecommerçants accompagnés
MCP : un protocole qui laisse l’agent découvrir ses outils
Le Model Context Protocol introduit une logique différente. Pensez USB-C pour les modèles de langage : une interface standardisée qui permet à l’IA de découvrir dynamiquement les outils et les schémas de données disponibles, sans qu’un développeur ait besoin de tout coder à la main. Le modèle demande ce qui est disponible, inspecte le schéma, puis décide comment s’en servir. Pas de script pré-écrit obligatoire.
Imaginez un entrepôt. Les API classiques, ce sont les convoyeurs : trajectoires fixes, vitesses constantes, débit prévisible. Parfait pour les flux connus. MCP, c’est le robot de picking intelligent qui lit le plan des étagères, s’adapte quand le stock bouge, et calcule le meilleur chemin tout seul. Le convoyeur gagne sur une route unique et bien comprise. Le robot gagne quand l’environnement ne cesse de changer. En e-commerce, l’environnement ne cesse jamais de changer.
Les trois primitives qui changent la donne
MCP expose trois types de briques : les tools (fonctions exécutables), les resources (données en lecture seule), et les prompt templates. Pour un marchand, cette séparation compte plus qu’il n’y paraît. Les tools permettent la sélection dynamique : un agent peut découvrir à la volée quels outils sont disponibles et les enchaîner selon l’intention réelle du client. Prenez un agent support qui doit vérifier le stock, appliquer une réduction, puis mettre à jour le panier. Avec une API classique, vous codez chaque point d’intégration. Avec MCP, l’agent découvre check_inventory, apply_promotion et update_cart depuis le schéma du serveur, puis les chaîne tout seul.
Les flux de travail deviennent autonomes. Ajoutez un endpoint programme de fidélité au trimestre suivant, et vous n’écrivez pas une ligne de code. L’agent le trouve et l’utilise. Les prompt templates, eux, alignent la voix de marque au niveau du protocole. Votre agent ne se contente pas de récupérer des données produit, il les présente dans le ton qui colle à votre identité. Sur mobile, chaque mot compte.
Quand MCP prend l’avantage : découverte et orchestration
MCP brille quand l’environnement est en mouvement permanent et que les parcours clients ne suivent pas de script unique. Un agent connecté via MCP peut enchaîner recherche catalogue, vérification inventaire, recommandations personnalisées et mise à jour panier dans une seule boucle de raisonnement. Zéro code de glue entre les étapes. Tout repose sur la capacité du modèle à comprendre l’intention et à chaîner les outils disponibles.
Testez cet exemple : un agent qui analyse les 25 dernières pull requests d’un projet, passe les données dans un outil analytics, puis formate un résumé par email. Une seule chaîne, plusieurs outils, aucune orchestration manuelle. Transposez en e-commerce : consultation catalogue, vérification stock, upsell personnalisé, ajout au panier. Un seul agent, plusieurs sources, aucune API custom à maintenir. C’est ce type de fluidité que MCP rend possible, et que les architectures API rigides peinent à reproduire sans explosion de complexité.
Quand les API classiques restent imbattables
Tout ne devrait pas être agentique, et il faut le dire franchement. Certaines tâches doivent rester ennuyeusement prévisibles. Les API REST brillent quand le processus est bien défini et répétitif : synchronisation des stocks entre entrepôts, mise à jour massive des prix pendant le Black Friday, envoi des données commande vers les partenaires logistiques. REST utilise des méthodes HTTP standard (GET, POST, PUT, DELETE) avec des payloads JSON. Prévisible, débogable, rapide.
Le traitement des paiements est le cas le plus évident. Quand vous débitez 49,99 € sur la carte d’un client, vous avez besoin d’appels API versionnés, auditables, contrôlés au millimètre. Pas d’interprétation IA. Pas de découverte dynamique. Un endpoint conforme PCI-DSS qui fait exactement une chose et renvoie exactement une réponse. Même logique pour le calcul de taxe, le traitement des remboursements, la réconciliation comptable. Ces chemins exigent des contrats rigides, et c’est là que l’approche déterministe des API classiques reste irremplaçable.
Comparaison tête-à-tête : performance, autonomie, complexité
Côté latence, les API REST gagnent haut la main. Appels HTTP directs, overhead minimal. MCP ajoute du JSON-RPC 2.0 plus la négociation de schéma, ce qui se traduit par quelques millisecondes supplémentaires à chaque appel. Pour une action unique et fréquente, c’est du gaspillage. Pour une découverte agentique sur des dizaines d’outils, c’est acceptable.
Sur l’autonomie, les positions s’inversent. REST impose que le développeur définisse chaque chemin d’appel. MCP laisse l’agent découvrir et chaîner les outils tout seul. En termes de complexité initiale, REST reste plus simple à démarrer : documentation OpenAPI, clients HTTP standards. MCP demande une couche serveur dédiée et un modèle capable de raisonner sur les schémas. Mais une fois en place, MCP réduit drastiquement la maintenance : ajoutez un outil, l’agent le trouve. Avec REST, vous réécrivez l’orchestration à chaque fois. Le choix dépend donc de la nature de vos processus et de votre capacité à absorber la complexité initiale.
Architecture hybride : le meilleur des deux mondes
La vraie question n’est pas MCP ou API, mais quand utiliser l’un ou l’autre. Une architecture hybride combine la rapidité déterministe de REST pour les chemins critiques (paiement, stock temps réel, envoi de confirmations) et la souplesse agentique de MCP pour les parcours exploratoires (recherche produit, recommandations, support conversationnel). Vous gardez le contrôle là où il est vital, vous gagnez en flexibilité là où l’intention client reste floue.
Concrètement, exposez vos endpoints critiques en REST direct, encapsulez vos outils métier dans des serveurs MCP, et laissez l’agent orchestrer les deux selon le contexte. Vous n’avez pas à choisir un camp. Vous choisissez l’outil le mieux adapté à chaque problème, et vous construisez une architecture qui évolue sans vous obliger à tout refondre tous les six mois. C’est exactement l’approche que les order management systems modernes adoptent pour gérer la complexité croissante du commerce omnicanal.
Cas pratiques : où placer le curseur sur votre shop
Prenons trois scénarios concrets. Pour la recherche produit et les recommandations, MCP l’emporte : l’agent peut interroger le catalogue, croiser avec l’historique client, suggérer des alternatives, puis affiner selon les retours en temps réel. Trop de variabilité pour qu’un arbre de décision figé fonctionne bien. Pour les mises à jour de stock haute fréquence, REST reste roi : un webhook Shopify déclenche un POST vers votre entrepôt, latence minimale, pas d’interprétation nécessaire.
Pour le support client conversationnel, l’hybride brille : l’agent MCP comprend l’intention, découvre les outils disponibles (suivi colis, politique retour, statut commande), puis appelle les endpoints REST sous-jacents pour récupérer les données exactes. Vous combinez fluidité conversationnelle et fiabilité opérationnelle. C’est cette combinaison qui permet de garder l’humain là où il apporte vraiment de la valeur, tout en automatisant le reste intelligemment.
Implications pour la stack Shopify
Shopify expose déjà une API REST solide et une API GraphQL Admin flexible. Vous n’avez pas besoin de remplacer quoi que ce soit. L’ajout de MCP se fait en couche supérieure : vous encapsulez vos appels Shopify (produits, collections, clients, commandes) dans un serveur MCP, et vous laissez un agent orchestrer ces briques selon l’intention utilisateur. Shopify reste votre source de vérité, MCP devient le chef d’orchestre.
Pour les boutiques Shopify les plus performantes, cette approche permet d’innover sur l’expérience client sans toucher au socle technique. Vous testez de nouveaux parcours conversationnels, vous ajoutez des recommandations contextuelles, vous personnalisez le tone of voice par segment, tout en gardant la stabilité et la sécurité des API Shopify natives. C’est une évolution, pas une révolution, et c’est justement ce qui la rend applicable dès maintenant.
Risques et pièges à éviter
Le premier piège, c’est de vouloir tout passer en MCP. Résultat : latence en hausse, debugging cauchemardesque, et overhead protocol partout. Ne rendez agentique que ce qui bénéficie réellement de l’autonomie. Gardez REST pour le reste. Deuxième piège : sous-estimer la complexité de la couche serveur MCP. Exposer des tools cohérents, maintenir des schémas à jour, gérer les versions, tout cela demande de la rigueur. Ce n’est pas plug-and-play.
Troisième piège : ignorer la sécurité. Un agent qui découvre des outils dynamiquement peut découvrir des outils qu’il ne devrait pas toucher. Vous devez implémenter des contrôles d’accès stricts au niveau du serveur MCP, exactement comme vous le feriez pour vos API. Enfin, ne négligez pas le monitoring. Un agent qui chaîne cinq outils en une seule requête, c’est cinq points de défaillance potentiels. Instrumentez, loggez, alertez. L’autonomie, c’est puissant, mais cela ne vous dispense pas de surveiller ce qui se passe sous le capot.
Qstomy : un agent IA qui orchestre tout sans vous forcer à choisir
Qstomy est un agent IA conçu pour Shopify qui guide vos clients vers l’achat : recommandations produits, upsell et cross-sell, assistance panier, suivi de colis, SAV. Plus de 100 marchands l’utilisent déjà. Sous le capot, Qstomy combine API REST pour la rapidité (stock, commandes, paiements) et logique agentique pour la fluidité (compréhension d’intention, orchestration multi-étapes, personnalisation dynamique). Vous n’avez pas à gérer la complexité d’une architecture hybride vous-même.
Là où un agent MCP pur ajouterait de la latence sur chaque interaction critique, et où une approche 100 % API rigidifierait l’expérience client, Qstomy choisit la bonne brique au bon moment. Résultat : vos clients obtiennent des réponses rapides et pertinentes, votre taux de conversion monte, et vous ne passez pas vos nuits à maintenir des couches d’orchestration custom. Qstomy intègre nativement suivi de colis, gestion de compte, politique retours, et transforme les questions SAV en opportunités de rebond commercial, exactement ce qu’une approche hybride bien pensée doit accomplir.
En bref : choisir selon vos vrais besoins
MCP et API ne sont pas concurrents, ils répondent à des besoins différents. Voici comment trancher :
MCP : pour les processus exploratoires, l’orchestration multi-outils, les parcours clients imprévisibles, la personnalisation dynamique.
API REST/GraphQL : pour les chemins critiques (paiement, stock, comptabilité), les appels haute fréquence, tout ce qui exige prévisibilité et audit strict.
Hybride : pour combiner rapidité déterministe et fluidité agentique sans sacrifier ni performance ni expérience client.
En bref : ne choisissez pas un camp par idéologie. Choisissez l’outil adapté à chaque problème, et construisez une architecture qui évolue avec vous. Les recommandations produit par IA et l’optimisation du panier moyen bénéficient clairement d’une approche agentique. Le traitement des paiements, jamais. La clé, c’est de savoir où placer la frontière, et de la déplacer au fur et à mesure que votre shop grandit.
FAQ
MCP remplace-t-il les API Shopify ?
Non. MCP orchestre vos API existantes, il ne les remplace pas. Shopify reste votre source de vérité.
Dois-je migrer toute mon architecture vers MCP ?
Absolument pas. Gardez REST pour ce qui est rapide et prévisible, ajoutez MCP uniquement là où l’autonomie apporte une vraie valeur.
Qstomy utilise-t-il MCP en interne ?
Qstomy combine logique agentique et appels API directs selon le contexte, sans vous imposer de choix technique. Vous profitez du meilleur des deux mondes, clé en main.
Pour aller plus loin : Comment construire une stratégie Facebook Ads e-commerce ? - Qstomy, Marketing e-commerce et publicité : quelles différences ? - Qstomy.
Enzo
26 août 2026
