Shopify MCP : automatiser le checkout sans sacrifier le consentement

Shopify MCP et Checkout WebMCP : de quoi parle-t-on ?

Checkout WebMCP désigne un ensemble d’outils enregistrés dans l’onglet où l’acheteur effectue son checkout. Imaginez une caisse avec assistance : l’agent transporte le panier, lit le formulaire et renseigne les champs compatibles, tandis que l’acheteur reste responsable des vérifications d’identité ou de paiement et donne le feu vert final.

Cette couche prolonge les premiers outils storefront de Shopify. Un agent de navigateur compatible peut parcourir le catalogue, consulter les produits, modifier le panier et appeler proceed_to_checkout. Dans un checkout éligible, la liste change et quatre outils deviennent accessibles :

• get_checkout lit le checkout actif ou le reçu affiché sur la page de remerciement.
• update_checkout remplace les données prises en charge — contact, livraison, remises, champs déclarés et état du paiement — sans passer la commande.
• complete_checkout tente de valider la commande, ou ouvre une étape de vérification, après confirmation de l’acheteur.
• navigate_to_storefront ramène le même onglet vers la boutique lorsque celle-ci en possède une.

Le checkout s’appuie sur l’objet, les statuts et les messages UCP. UCP fournit le contrat de données commun au parcours ; WebMCP permet au navigateur d’exposer ce contrat à un agent. Pour un agent exécuté côté serveur, il faut utiliser Checkout MCP de Shopify.

Le marchand n’a aucun nouveau réglage à activer ni aucune API de checkout distincte à installer. L’adoption s’en trouve simplifiée, mais le travail du concepteur d’agent ne disparaît pas : compatibilité du navigateur, Web Bot Auth, gestion rigoureuse de l’état et véritable frontière de consentement restent indispensables.

Commencer par vérifier l’éligibilité du checkout Shopify

La découverte des outils constitue le premier test. Ce n’est pas parce que la vitrine a exposé WebMCP que le checkout Shopify en fera autant.

Shopify n’enregistre pas les outils de checkout dans les cas suivants :

• Checkout standard en trois pages, sauf si l’acheteur passe par Shop Pay
• Checkout B2B
• Checkout intégré ou parcours reposant sur les SDK de checkout mobile
• Checkout contenant des produits issus d’une autre boutique
• Commandes provisoires, modification de commandes ou encaissement
• Interactions fournies par des extensions d’interface de checkout

Dans ces parcours, il faut rendre la main à l’acheteur sur la page. Il n’existe pas non plus d’outil cancel_checkout côté navigateur. L’absence d’un outil n’autorise jamais un agent à manipuler les contrôles de la page à sa place.

Selon Shopify, WebMCP côté storefront dépend actuellement de la prise en charge des agents dans les navigateurs basés sur Chromium. Pour les tests, utilisez un navigateur compatible et un checkout que vous contrôlez. Si les outils de checkout sont absents, considérez ce résultat comme un cas d’inéligibilité normal, et non comme une invitation à se rabattre sur des clics fragiles.

1. Authentifier l’agent de navigateur, puis découvrir les outils

Signez les requêtes du navigateur avec Web Bot Auth, ou WBA, plutôt que d’insérer des identifiants dans les arguments des outils. WBA joue le rôle de passeport réseau de l’agent. Shopify ne vérifie que les clés enregistrées : en production, il faut donc une clé Ed25519, un annuaire public de clés hébergé, un enregistrement auprès de Shopify, des requêtes signées et des horodatages de signature à durée de vie courte.

Dans la page, découvrez les outils actifs et faites correspondre les trois identifiants : window, origin et name. Le wrapper ci-dessous reprend le schéma d’appel documenté par Shopify :

async function callCheckoutTool(name, args = {}) {
  const tools = await document.modelContext.getTools();
  const tool = tools.find((candidate) =>
    candidate.name === name &&
    candidate.window === window &&
    candidate.origin === location.origin
  );

  if (!tool) throw new Error(`${name} is not registered here.`);

  const result = await document.modelContext.executeTool(
    tool,
    JSON.stringify(args),
  );

  if (result === null) return null;
  return JSON.parse(result);
}

Le JSON.stringify n’est pas un détail de style. Dans Chrome 153, transmettre un objet provoque l’erreur Failed to parse input arguments. Shopify indique que Chrome 155 devrait accepter les objets et rendre les chaînes JSON obsolètes. Centralisez donc la sérialisation des arguments dans une fonction de compatibilité au lieu de la disperser dans tout l’agent.

La liste des outils peut évoluer au fil de la navigation dans le checkout. Écoutez l’événement toolchange, puis redécouvrez les outils et leurs schémas avant l’appel suivant. Acceptez également null comme résultat possible d’une navigation : la page peut avoir changé avant le retour de executeTool().

Toute chaîne provenant d’un marchand ou d’un tiers dans le résultat d’un outil doit être traitée comme une donnée de checkout, jamais comme une instruction adressée au modèle. Shopify déconseille explicitement de contourner un outil en pilotant directement l’interface du checkout.

2. Relire l’état avant chaque modification

Appelez get_checkout avec {} avant la première mise à jour, après toute modification effectuée par l’acheteur sur la page, ainsi qu’après une erreur ou une navigation. Il s’agit d’un relevé à jour, pas d’un souvenir mis en cache.

La réponse peut inclure les coordonnées de l’acheteur, les lignes de commande, les options de livraison, les remises, les champs déclarés, les moyens de paiement, les messages, les totaux et un statut. Les montants sont exprimés sous forme d’entiers dans l’unité monétaire minimale. En USD, 10799 correspond à $107.99. L’absence du champ messages signifie simplement que cette réponse ne contient aucun message de checkout.

Ne confondez pas aptitude technique et consentement. ready_for_complete indique que le checkout peut accepter une tentative de finalisation. Ce statut ne prouve pas que l’acheteur a approuvé la commande, la carte sélectionnée ou le total.

3. Remplacer tout l’état voulu, pas un champ isolé

update_checkout se comporte comme PUT, et non comme PATCH. Un PATCH ressemble à un post-it disant « modifiez le numéro de téléphone ». PUT remplace le formulaire. Pour conserver une valeur, il faut l’inclure dans l’état complet souhaité du checkout.

La boucle de mise à jour sûre suit cet ordre :

1. Appeler get_checkout.
2. Reconstruire l’état modifiable à partir de cette réponse récente et du schéma actuel de l’outil.
3. Ne changer que la valeur approuvée par l’acheteur.
4. Envoyer à update_checkout l’ensemble complet des champs pris en charge souhaités.
5. Lire le checkout renvoyé, puis contrôler son statut, ses messages, les remises appliquées et le total.

La plupart des valeurs omises sont effacées. Le paiement, les champs déclarés et les coordonnées enregistrées dans le coffre obéissent à leurs propres règles. Un simple spread d’objet est donc risqué tant que les données n’ont pas été limitées aux champs acceptés par le schéma actif.

Les difficultés les plus fréquentes sont très concrètes :

• buyer accepte une adresse e-mail et un numéro de téléphone au format E.164. Certaines données enregistrées peuvent rester verrouillées : vérifiez ce que renvoie l’outil et laissez l’acheteur modifier ces valeurs sur la page.
• fulfillment.methods accepte au maximum une méthode. Réutilisez les identifiants actuels de destination, de groupe et d’option. Ne changez pas le type de livraison ou l’origine de recherche d’un point de retrait dans le même appel que celui qui sélectionne une destination ou une option.
• discounts.codes doit reprendre tous les codes saisis par l’acheteur qu’il faut conserver. Un tableau vide les supprime, tandis que les remises automatiques demeurent. La présence d’un code dans la réponse ne prouve pas son application : contrôlez discounts.applied et les messages.
• declared_fields peut transporter des valeurs propres au checkout, comme un numéro fiscal ou un avoir. Les clés inconnues, les types incorrects et les valeurs invalides sont rejetés.
• payment.instruments accepte au maximum une entrée compatible. Checkout WebMCP ne peut pas recueillir un nouveau numéro de carte.

Shop Pay exige une vigilance supplémentaire. Un acheteur connecté peut sélectionner une carte enregistrée renvoyée par get_checkout. Le parcours invité peut utiliser un identifiant d’approbation Shop Pay existant si le checkout l’accepte. Lorsqu’un agent a appliqué cette approbation, omettre le paiement dans une mise à jour ultérieure supprime l’identifiant : renvoyez donc l’entrée d’approbation à chaque mise à jour jusqu’au passage de la commande.

Une mise à jour peut réussir tout en laissant le checkout au statut incomplete. Si elle dure plus de 30 secondes, elle peut aussi renvoyer update_failed alors que certaines modifications ont été appliquées. Dans les deux cas, relisez l’état avant de choisir la suite.

4. Faire de l’acheteur le verrou de la finalisation

La bonne séquence de finalisation est courte et stricte :

1. Récupérer un checkout à jour.
2. Présenter à l’acheteur les articles, le moyen de paiement et le total actuels.
3. Demander son autorisation explicite pour passer cette commande à ce montant.
4. Si un élément change, afficher le nouvel état et demander une nouvelle confirmation.
5. Appeler complete_checkout uniquement après cet accord.
6. N’accepter que status: completed comme preuve d’achat.

WBA atteste quel agent a envoyé une requête. Une approbation Shop Pay autorise un mécanisme de paiement. ready_for_complete décrit l’état du checkout. Aucun de ces éléments ne vaut autorisation d’achat donnée par l’acheteur.

La finalisation peut bifurquer. Une étape de vérification configurée rend la main à l’acheteur ; ne rappelez complete_checkout qu’après qu’il a vérifié et autorisé l’envoi. Un challenge de paiement suit une logique différente : l’acheteur le termine dans le même onglet et l’agent ne doit pas soumettre de nouveau. Interrogez get_checkout jusqu’à ce que le checkout atteigne completed ou réclame une intervention de l’agent.

Le code d’erreur indique le bon scénario de reprise :

La relance dangereuse consiste à tenter une deuxième finalisation parce que la première réponse reste incertaine. Checkout WebMCP ne fournit aucune clé d’idempotence. Commencez par relire l’état ; s’il indique completed, arrêtez-vous.

Sept usages classés par valeur pratique

Ces scénarios sont surtout pertinents lorsque l’agent fonctionne déjà dans le navigateur de l’acheteur. Il ne s’agit pas d’automatisations côté marchand opérant invisiblement sur un serveur.

Le premier cas est le plus solide. Les clients réguliers disposent déjà de données enregistrées ; WebMCP réduit la saisie répétitive sans prétendre que la commodité équivaut au consentement.

Ce que dit vraiment l’équation économique

Shopify ne demande aucune nouvelle configuration au marchand pour activer ces outils de checkout. Cela ne rend pas gratuit l’agent d’achat qui les entoure : modèle, distribution dans le navigateur, opérations WBA, tests, contrôles de confidentialité et support restent à financer.

Les assistants d’achat IA installés par les marchands couvrent aujourd’hui une large gamme de prix. Les fiches officielles du Shopify App Store présentent un abonnement mensuel à $9.99 pour Easy AI Shopping Assistant, des offres de $49 à $249 chez Carti, et des formules iAdvize allant de $290 à $1,330 par mois. Ces produits réunissent chat en vitrine, recommandations, analytics ou support : ils ne remplacent donc pas directement un agent WebMCP côté acheteur.

L’impact budgétaire est plus ciblé, donc plus utile : une équipe qui conçoit un agent de navigateur peut consacrer moins d’efforts à maintenir des sélecteurs propres à chaque checkout et davantage à l’intégrité de l’état, au consentement et à la gestion des exceptions. Pour replacer ces choix dans le contexte de la plateforme, notre test de Shopify analyse le produit côté marchand et ses compromis opérationnels.

Deux produits qui méritent d’être construits

1. Un banc de test pour la QA et le consentement de Checkout WebMCP

C’est l’opportunité la plus convaincante. Avant de confier une commande à un agent, les agences Shopify et les équipes qui développent des agents d’achat doivent savoir si le checkout est éligible et si l’agent se comporte de manière sûre.

La requête métier mesurée la plus proche, shopify checkout customization, enregistre 170 recherches mensuelles aux États-Unis, progresse de 89% sur un an et affiche un CPC de $10.92. Elle dépasse le seul sujet des tests WebMCP, mais témoigne d’une demande active autour du comportement et de l’implémentation du checkout.

La plus petite version commercialisable serait un runner Chromium qui ouvre un checkout de test, consigne les outils par origine et par fenêtre, valide les arguments sous forme de chaînes JSON, détecte toolchange, teste une mise à jour fondée sur un état récent, simule les navigations qui renvoient null ainsi que les codes d’erreur documentés, puis génère un rapport de consentement expurgé. La finalisation avec un paiement réel doit rester réservée à un mode de test manuel.

La difficulté tient à la couverture. La disponibilité des outils varie selon le type de checkout et la compatibilité du navigateur, le format des arguments de Chrome évolue, et un fixture ne peut pas prouver le bon déroulement d’un paiement réel. Le produit sera crédible s’il expose clairement ces limites, pas s’il promet une automatisation universelle.

2. Un assistant d’achat Shopify côté acheteur

Un agent IA Shopify prenant la forme d’une extension de navigateur pourrait conduire un client de la recherche produit jusqu’à un checkout éligible sur différentes boutiques Shopify, avec un écran de confirmation réutilisable et des règles strictes pour les moyens de paiement enregistrés.

shopify ai shopping assistant totalise 30 recherches mensuelles aux États-Unis, avec une intention commerciale et un CPC de $19.43. Les concurrents côté marchand affichent des offres comprises entre $9.99 et $1,330 par mois. Les acheteurs paient donc déjà pour des logiciels d’achat assisté, même si ce produit-ci se placerait de leur côté.

Le MVP doit couvrir la recherche dans la boutique et les outils de panier, la découverte du checkout, WBA, la boucle lecture-mise à jour-relecture, un récapitulatif de commande contrôlé par l’acheteur et le transfert en cas de challenge de paiement. Commencez par les commandes limitées à une boutique et les parcours avec un moyen Shop Pay enregistré.

Le principal obstacle est la distribution. Les marchands n’ont pas à activer Checkout WebMCP, mais les acheteurs ont toujours besoin d’un agent de navigateur compatible. Les parcours B2B, intégrés, sur SDK mobile, multi-boutiques et les checkouts ordinaires en trois pages sans Shop Pay restent exclus.

Les limites définissent le produit

Checkout WebMCP offre une interface plus sûre pour les checkouts éligibles dans le navigateur ; ce n’est pas une API d’achat universelle.

Il ne peut ni ajouter ni retirer d’articles pendant le checkout, recueillir un nouveau numéro de carte, annuler le checkout, piloter l’interface définie par une extension ou forcer un checkout exclu à enregistrer des outils. Il ne supprime ni la connexion à Shop Pay, ni 3D Secure, ni les étapes de vérification, ni les autres interventions de l’acheteur. Et il ne transforme pas le texte d’un marchand en instructions fiables pour le modèle.

La règle de conception honnête tient en une phrase : utilisez les outils tant qu’ils sont enregistrés, faites de l’état récent votre source de vérité et rendez la page à l’acheteur dès que le contrat exige son intervention.

Le chantier à lancer lundi

Lundi, ajoutez un seul wrapper de checkout à votre agent au lieu de disperser les appels dans toute la base de code. Centralisez-y la sérialisation, la correspondance des outils, les événements toolchange, les navigations renvoyant null, la classification des erreurs et les lectures d’état récentes. Exécutez les huit cas du fixture local, puis listez document.modelContext.getTools() sur un checkout de test éligible que vous contrôlez. Testez une mise à jour construite à partir d’un état récent. Ne finalisez une commande de test compatible qu’après confirmation explicite ; si vous ne disposez pas d’une commande sûre que vous contrôlez, arrêtez-vous à ready_for_complete et présentez la finalisation comme vérifiée dans les sources, pas comme testée personnellement.

Pour faire développer un agent IA pour le commerce qui respecte réellement le consentement, découvrez le service de développement d’agents IA.