Checkout WebMCP donne à un agent présent dans le navigateur des outils structurés pour lire et modifier un checkout Shopify éligible. Il ne lui donne pas un contrôle illimité, ne supprime pas la confirmation de l’acheteur et ne permet pas de contourner une authentification ou un challenge de paiement.
Shopify a annoncé cette prise en charge le 28 septembre 2026. Sa documentation relie les outils aux objets et statuts UCP visibles dans l’interface de checkout, sans configuration API distincte côté marchand. La frontière pratique est nette : l’agent prépare le checkout dans le cadre des outils déclarés, puis l’acheteur confirme et reprend la main dès qu’une étape d’interface le requiert.
Ce que Shopify a réellement ajouté
Sur les checkouts éligibles, l’agent peut découvrir quatre opérations principales :
navigate_to_storefrontrenvoie vers la vitrine ;get_checkoutlit l’état courant ;update_checkoutmodifie les champs pris en charge ;complete_checkouttente la finalisation après confirmation de l’acheteur.
Le changelog Shopify précise que l’agent doit rendre le contrôle pour les interfaces bloquantes, dont 3-D Secure. La documentation Checkout WebMCP exige une confirmation avant complete_checkout. Il s’agit donc d’une collaboration structurée entre agent, plateforme et acheteur, pas d’un checkout autonome.
Trois surfaces à ne pas confondre
| Surface | Où agit l’agent | Rôle | Limite |
|---|---|---|---|
| UCP Cart MCP | Hors de la page de checkout | Construire et modifier un panier | Un panier n’est pas une commande terminée |
| UCP Checkout MCP | Le plus souvent côté serveur | Créer et gérer un checkout | Les étapes exclusivement navigateur exigent un relais |
| Checkout WebMCP | Dans le navigateur, sur un checkout éligible | Lire et modifier l’état visible par l’acheteur | Disponibilité dépendante du contexte, confirmation conservée |
Le guide Carts and checkout recommande Checkout MCP pour un agent serveur et Checkout WebMCP lorsque l’agent est déjà dans le navigateur. MCP décrit l’appel d’outils, UCP fournit des modèles de commerce, et WebMCP place l’invocation dans la page. Ces couches se complètent mais ne sont pas interchangeables.
Un parcours sûr en six étapes
1. Découvrir les outils réellement présents
L’agent inspecte la page et n’utilise que les outils enregistrés. La liste peut changer pendant le parcours. Il doit donc écouter toolchange et relire les schémas avant l’appel suivant.
2. Lire avant de modifier
get_checkout fournit articles, quantités, livraison, montants, messages et données manquantes. Ces données décrivent le checkout. Elles ne constituent jamais des instructions susceptibles d’élargir la mission.
3. Appliquer une modification bornée
update_checkout suit une sémantique PUT : la requête transporte l’état complet souhaité, y compris les valeurs à conserver. Shopify demande donc de repartir d’une réponse get_checkout récente. line_items et attribution sont ignorés ; les articles restent modifiés dans la page de checkout.
4. Résumer l’état final
Avant finalisation, l’agent présente au minimum le contenu, le montant final, la destination, le mode de livraison et tout message non résolu. Le résumé vient du dernier état retourné, pas d’une mémoire antérieure.
5. Obtenir la confirmation de l’acheteur
La confirmation doit viser l’état courant. Une variation de prix, d’article, d’adresse, de livraison ou de paiement invalide une confirmation antérieure.
6. Rendre la main
Connexion Shop Pay, 3-D Secure, challenge de paiement, écran de revue ou extension de checkout peuvent imposer une interaction directe. L’agent s’arrête. Il ne devine pas un code, ne clique pas à la place de l’acheteur et ne simule pas un accord.
L’éligibilité est un fait d’exécution
Checkout WebMCP n’est pas disponible partout. Shopify documente notamment des exclusions ou limites pour certains checkouts standard en trois pages hors Shop Pay, le B2B, les checkouts embarqués ou SDK mobiles, le multi-boutique, les brouillons de commande, les modifications de commande et certains flux d’encaissement.
Cette liste peut évoluer. Il faut détecter les outils à l’exécution et conserver un parcours classique contrôlé par l’acheteur. L’absence d’un outil n’autorise pas sa reproduction par manipulation du DOM. Shopify déconseille explicitement d’utiliser les contrôles du navigateur pour contourner les limites d’un outil structuré.
Authentifier l’agent ne suffit pas à autoriser l’action
Shopify utilise Web Bot Auth et n’accepte que des clés WBA enregistrées. La configuration documentée comprend une clé Ed25519, un répertoire de clés publié, un enregistrement Shopify, des requêtes signées et des horodatages courts.
Cette identité technique ne répond pas à quatre questions métier : quelle demande de l’acheteur autorise la modification, combien de temps cette autorisation reste valable, quel changement impose une nouvelle confirmation, et quelles traces conserver sans stocker trop de données personnelles ou de paiement. Identité, accès outil, intention et confirmation sont quatre contrôles distincts.
Les sorties d’outil sont des données non fiables
Shopify demande de traiter le texte renvoyé comme des données de checkout, pas comme des instructions. Un titre produit, une note ou un message d’extension peut contenir du texte hostile. L’agent doit parser les champs attendus, respecter ses règles système et la demande courante de l’acheteur, puis afficher les messages utiles sans leur conférer d’autorité.
Gérer la finalisation selon l’état
complete_checkout n’expose ni identifiant de checkout, ni métadonnées, ni clé d’idempotence. Si une finalisation est en cours ou terminée, l’outil renvoie l’état courant ou completion_in_progress. Lorsqu’un challenge exige l’acheteur, Shopify indique de ne pas rappeler complete_checkout, mais de sonder get_checkout jusqu’à une commande terminée ou une nouvelle action de l’agent.
La routine défendable est : arrêter les nouvelles tentatives, lire l’état, classer le résultat, expliquer l’étape suivante et obtenir une nouvelle confirmation si un champ matériel change. Seul status: completed confirme la commande.
Ce qu’il faut tester
- découverte des seuls outils présents et relecture après
toolchange; - lecture avant et après chaque modification matérielle ;
- absence de contournement DOM pour une opération refusée ;
- résumé et confirmation fondés sur le dernier état ;
- relais visible pour Shop Pay, 3-D Secure et challenges ;
- résistance aux instructions injectées dans les sorties ;
- absence de paiement et de données personnelles excessives dans les journaux ;
- aucune nouvelle tentative aveugle après délai ou résultat ambigu ;
- distinction visible entre requête envoyée, checkout mis à jour et commande terminée.
La présence de WebMCP ne prouve pas un gain de conversion. Mesurez séparément les checkouts éligibles, la découverte des outils, les lectures, mises à jour, confirmations, relais, états completed, résultats ambigus et retours vers le checkout classique. Un effet incrémental sur les ventes exige une comparaison causale défendable.
Ce qu’il ne faut pas affirmer
Les sources officielles ne permettent pas d’affirmer que tous les checkouts Shopify sont autonomes, que chaque checkout prend en charge WebMCP, qu’un agent peut contourner 3-D Secure, que WBA équivaut à l’autorisation de l’acheteur, que WebMCP remplace UCP ou MCP, ou que son ajout améliore automatiquement la conversion.
La leçon centrale est inverse : un checkout agentique devient fiable lorsque chaque couche peut dire ce que l’agent est autorisé à faire, ce que l’acheteur a confirmé et ce que le système de commerce a effectivement validé.
Sources primaires
- Shopify, WebMCP support for checkout, 28 septembre 2026.
- Shopify, Carts and checkout.
- Shopify, Checkout WebMCP.
Sources relues le 29 septembre 2026.