L’échec le plus courant est discret. Vous suivez un guide, collez un bloc JSON dans la configuration du client, redémarrez, et cela fonctionne : la liste des outils apparaît, la connexion est verte. Puis vous demandez à quoi ressemblaient les commandes d’hier et n’obtenez rien d’utile, sans raison évidente.
La raison est que Shopify fournit deux serveurs MCP différents, et le plus simple ne peut pas voir votre boutique.
Les deux serveurs
Shopify a publié son AI Toolkit en open source en avril 2026, regroupant sa pile de serveurs MCP officiels, ses Skills d’Agents et un plugin Claude Code dans un même espace de noms. Cet espace contient deux éléments que l’on confond régulièrement.
Dev MCP s’exécute en local, ne nécessite aucune connexion et fournit à l’assistant la documentation développeur de Shopify et les schémas API. Il est conçu pour les personnes qui développent des applications Shopify, et remplit très bien ce rôle. Il ne lira pas les commandes d’hier et ne modifiera pas de produit, car il ne touche par conception jamais à une boutique en production.
Admin MCP est celui qui travaille sur les données réelles de la boutique, et il lui faut un jeton Admin API. Ce jeton fait toute la différence, et représente aussi tout le coût de configuration.
Si vous développez sur Shopify, installez Dev MCP et arrêtez la lecture. Il est gratuit, officiel, et cet article ne cherche pas à le remplacer. Si vous exploitez une boutique et voulez lui poser des questions, il vous faut l’autre.
Ce que la voie Admin exige réellement
Vous créez une application personnalisée dans l’administration de votre boutique, lui accordez les portées d’accès Admin API nécessaires et conservez le jeton obtenu. Cela fait trois décisions souvent mal prises.
La première concerne l’étendue des autorisations. Accordez-en trop peu et l’échec arrivera plus tard, au moment de l’appel, sous forme d’erreur d’autorisation noyée dans une réponse de chat peu lisible. Accordez tout et vous créez un jeton capable de réécrire votre catalogue, stocké dans un fichier de configuration sur un ordinateur portable.
La deuxième concerne l’emplacement du jeton. La plupart des guides montrent par défaut un jeton en clair dans une configuration JSON, car c’est l’instruction la plus courte à écrire. Ce n’est pas le choix que vous feriez pour un identifiant capable de publier des produits.
La troisième est le renouvellement. Les jetons survivent à la raison de leur création. Rien dans la configuration ne vous le rappelle.
Lire et écrire n’exposent pas au même risque
Demander quels SKU ont été en rupture la semaine dernière est une lecture. Elle est peu coûteuse, réversible et, si la réponse est fausse, vous le constatez et passez à la suite.
Changer un prix, modifier une description produit, publier sur un canal de vente : toutes ces actions s’exécutent sur une boutique en production où des clients achètent en ce moment. Le protocole ne fait pas cette distinction. MCP décrit un outil et ses arguments ; il ne porte pas la notion « cette action est irréversible ».
Le contrôle doit donc se trouver dans le client. Si votre client exécute les appels d’outils dès que le modèle les émet, la seule chose entre une consigne mal comprise et un catalogue aux prix modifiés est un modèle dans un bon jour. Personne ne choisit volontairement ce profil de risque ; on l’hérite d’un guide d’installation.
La même structure sur toutes les autres plateformes
eBay, Etsy et WooCommerce disposent désormais tous de serveurs MCP communautaires, et le scénario se répète presque à l’identique : un jeton ou une paire de clés à générer vous-même, un choix d’autorisations, un processus local à maintenir et un client auquel confier les écritures. Un vendeur présent sur quatre plateformes se retrouve à exploiter quatre petits services et à détenir quatre identifiants : un vrai travail que personne n’avait prévu.
La place d’Orkas dans tout cela
Orkas est un client MCP : tous les serveurs décrits ci-dessus fonctionnent donc avec lui comme avec d’autres clients. Il fournit aussi son propre connecteur Shopify Admin, fondé sur une application Dev Dashboard appartenant au marchand, dont deux détails constituent l’intérêt.
Les portées d’accès sont validées lors de la connexion, pas lorsqu’un appel échoue. Orkas vérifie chaque portée requise : produits, commandes, clients, stocks, emplacements, commandes provisoires, retours, remises, publications et portées applicables aux ordres de traitement. Il indique celle qui manque avant que vous ne passiez une conversation à le découvrir. Les identifiants sont chiffrés sur votre appareil au lieu de rester dans un fichier de configuration.
Et le contrôle d’écriture se trouve dans le client, pas dans la consigne. Tout ce qui écrit, supprime, dépense ou touche une boutique en production passe par une demande d’autorisation, les actions irréversibles étant contrôlées séparément des actions courantes. Le même catalogue couvre eBay, Etsy, Walmart Marketplace, WooCommerce et Amazon Seller Central, ainsi que les plateformes chinoises : le problème des quatre services ne se reproduit donc pas pour chaque boutique.
Ce que cela ne couvre pas
Cela ne fait pas d’Orkas un système de gestion de boutique. Il ne gère pas les stocks, n’achemine pas les commandes et ne réévalue pas les prix à votre place ; si c’est votre besoin, gardez votre ERP. Il remplace l’empilement de petites intégrations que vous assembleriez pour interroger votre boutique et agir sur les réponses. Pour la partie action, il remplace aussi l’idée qu’un modèle dans un bon jour constitue une protection suffisante.