WebMCP checkout concerne les agents dans le navigateur de l’acheteur. La revue proposée vérifie l’éligibilité, la version de l’adaptateur, le total approuvé et la confirmation finale. Les cas simulés couvrent aussi la navigation et les réponses incertaines, sans annoncer de gain SEO ou commercial.
Dans cet article
Shopify a annoncé le 28 septembre 2026 l’arrivée de WebMCP dans le checkout. Les outils s’exécutent dans la session du navigateur de l’acheteur ; la validation humaine reste nécessaire pour passer commande. La première tâche d’une équipe ecommerce consiste à vérifier ce contrat sur son parcours réel, avec des données de test, plutôt qu’à annoncer une hausse de visibilité IA. Annonce Shopify
Distinguer découverte, panier et commande
Une fiche produit comprise par un moteur, un panier composé par un assistant et une commande enregistrée sont trois résultats différents. Le test proposé ici commence lorsqu’un agent utilise déjà le navigateur de l’acheteur. Il ne démontre pas qu’un assistant découvre spontanément la marque, qu’un produit sera cité ou qu’un visiteur achètera davantage.
Définissez le problème à résoudre : éviter que l’assistant annonce une commande avant sa confirmation, conserve un ancien total ou perde le contexte après une navigation. Ces erreurs peuvent devenir particulièrement coûteuses pendant Q4, lorsque remises, disponibilités et frais évoluent. Le succès attendu est une interaction correcte et compréhensible, sans raccourci dans l’accord de l’acheteur.
Conservez un périmètre réduit : une boutique de développement autorisée, un produit fictif et un moyen de paiement de test approprié. L’équipe doit savoir quelles actions peuvent modifier le checkout. Aucun scénario de cet article ne représente une commande réellement passée.
Vérifier l’éligibilité du checkout
WebMCP concerne le navigateur ; Checkout MCP est l’autre interface, côté serveur. Les exclusions documentées comprennent le B2B, l’embedded/mobile SDK, les commandes provisoires ou modifiées et le checkout standard sur trois pages sans Shop Pay. Périmètre officiel
Construisez une matrice avec le type de checkout, le contexte de paiement, les extensions présentes et les outils effectivement découverts. Une absence d’outil ne justifie pas une tentative de contournement. Le parcours utilisateur ordinaire reste la solution de repli.
Pour les marchés US et UK, répétez le contrôle avec le contexte commercial voulu : devise, adresse de test, livraison et conditions proposées par la boutique. La documentation citée ne fournit pas une garantie universelle de disponibilité par pays. Ne transformez donc pas deux scénarios locaux en annonce de déploiement mondial. Notez la date, la configuration et le résultat observable de chaque vérification.
L’absence de configuration supplémentaire côté marchand ne supprime pas l’authentification de l’agent. Shopify demande Web Bot Auth : l’agent génère une clé Ed25519, publie son répertoire de clés publiques, le fait enregistrer auprès de Shopify et signe les requêtes du navigateur avec des signatures de courte durée. Sans WBA, la détection des bots peut réduire la priorité des requêtes ou les bloquer. Les signatures passent dans les en-têtes du navigateur, jamais comme secrets dans les arguments des outils. Cette identité vérifiée ne vaut toujours pas accord de l’acheteur. Authentification de l’agent
Versionner l’adaptateur du navigateur
L’API navigateur possède un cycle de découverte et des changements de liste d’outils. Il faut actualiser cette liste sur toolchange et suivre l’origine de l’outil. Référence Chrome
Placez cette gestion dans un adaptateur distinct du raisonnement de l’assistant. Son entrée est un outil identifié ; sa sortie est un résultat interprété ou un état inconnu. Enregistrez la version du navigateur dans le rapport de test pour pouvoir reproduire un échec.
Ne copiez pas une signature d’appel sans cette vérification : Shopify décrit des arguments sérialisés en JSON pour Chrome 153, tandis que la référence Chrome présente également une interface avec objet. Ces exemples ne constituent pas un contrat identique pour toutes les versions. Instructions Shopify
Le test d’acceptation de l’adaptateur doit employer des outils simulés avant tout outil marchand : liste vide, changement d’origine, schéma modifié et navigation pendant un appel. Il doit échouer clairement lorsqu’il ne sait pas interpréter la réponse, sans inventer une réussite à partir d’un message partiel.
Mettre l’accord de l’acheteur au bon endroit
Les statuts ready_for_complete et completed ne sont pas équivalents. Les montants sont exprimés en unités monétaires mineures. L’acheteur doit confirmer la commande et son total courant ; la préparation technique ne remplace pas cet accord. Contrat de checkout
Voici un exemple synthétique, qui ne reproduit aucune transaction : article à 80 USD, livraison à 5 USD et taxes fictives à 6 USD, total 91 USD. Dans une représentation en cents, le total vaut 9100. Un second cas UK utilise indépendamment 80 GBP et 5 GBP de livraison, soit 85 GBP ; ce n’est pas une conversion de devises ni un calcul fiscal britannique.
Votre écran de confirmation doit nommer le marchand, les articles, les quantités, la devise et le total. Dans le scénario, si le total américain passe à 94 USD après changement de livraison, l’accord précédent sur 91 USD est invalidé par votre règle d’acceptation. Une nouvelle présentation et une nouvelle confirmation sont nécessaires.
Cette règle doit être testable dans l’application : conserver uniquement le fait qu’un accord existe ne suffit pas. L’accord doit correspondre à la proposition présentée. Un changement d’article ou de quantité déclenche aussi une nouvelle revue.
Prévoir l’incertitude et le retour humain
Après un délai ou une réponse illisible, la règle proposée consiste à suspendre toute nouvelle soumission et à relire l’état disponible. L’objectif est d’éviter une deuxième tentative lorsque le résultat de la première reste inconnu. Donnez au lecteur humain un message précis : « confirmation en cours de vérification », plutôt qu’une promesse de commande ou un échec supposé.
Les challenges de paiement et interactions bloquantes peuvent rendre la main à l’acheteur. Annonce du fonctionnement Préparez cette transition comme une partie normale du parcours : montrer ce qui reste à faire et ce que l’assistant sait effectivement.
Le texte marchand ou tiers reçu par l’assistant doit rester une donnée. Les recommandations OWASP traitent notamment les injections indirectes et l’observation des actions d’outils. Guide OWASP Pour ce test, utilisez une consigne contradictoire inoffensive dans une description fictive et des outils simulés ; vérifiez qu’elle ne déclenche aucune modification non autorisée. Aucun service tiers ne doit servir de cible.
Écrire des critères d’acceptation observables
La grille suivante est un protocole proposé, pas un bilan d’expériences déjà exécutées.
| Cas de test | Résultat attendu dans notre protocole |
|---|---|
| Aucun outil reconnu | Repli humain, aucune commande annoncée |
| Total changé après l’accord | Nouvelle revue avant toute soumission |
| Accord absent | Aucune tentative de finalisation |
| Navigation pendant un appel | Résultat traité comme inconnu |
| Intervention de l’acheteur | Attente puis nouvelle lecture du contexte |
| Confirmation finale observée | Rapprochement avec l’identifiant de commande |
Pour chaque cas, conserver entrée fictive, état précédent, événement déclencheur, action réellement tentée et état final. Les journaux doivent éviter données personnelles, coordonnées bancaires et secrets. Un message rassurant dans la conversation ne prouve pas qu’aucune action incorrecte n’a eu lieu : le contrôle porte aussi sur les appels.
Mesurer l’intégration sans inventer son rendement
Séparez disponibilité des outils, parcours commencés, accords demandés, finalisations tentées et commandes effectivement confirmées. Définissez les dénominateurs avant de calculer un taux. Les tests de développement ne deviennent pas des statistiques commerciales ; l’identifiant de test doit les distinguer des commandes réelles.
Avant Q4, la décision de lancement doit reposer sur cette grille, un responsable de correction et un repli utilisable. Une erreur de devise, une soumission sans accord ou une issue incertaine non gérée bloque la validation. La rapidité éventuelle de l’agent reste secondaire tant que ces invariants ne sont pas respectés.
Pour compléter le parcours, le dossier Q4 fournit une préparation éditoriale et les ressources gratuites peuvent servir à consigner les contrôles. Ces supports aident à organiser la revue ; ils n’apportent aucune preuve de classement, de citation IA ou de vente supplémentaire.
