Search Engine Trends — Français : actualités

WebMCP checkout : vérifier l’état et l’accord de l’acheteur

Search Engine Trends — rédaction — Sat, 03 Oct 2026 00:00:00 GMT

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.

Publié par Search Engine Trends. Article original. Équipe et liens commerciaux.

Merchant API : migrer sans déplacer les offres

Search Engine Trends — rédaction — Sat, 03 Oct 2026 00:00:00 GMT

Une intégration catalogue encore fondée sur Content API for Shopping mérite une revue immédiate avant Q4. Google indique un sunset au 18 août 2026, des erreurs 410 intermittentes depuis le 1er septembre sans extension active, puis une extinction complète prévue début 2027, avec calendrier révisable. Il serait donc inexact de déclarer que tous les endpoints sont déjà coupés. Calendrier Google

Le travail utile consiste à identifier les appels concernés, préserver l’identité des offres et vérifier les produits traités après migration. Une réponse HTTP correcte ne prouve ni disponibilité dans les listings ni vente supplémentaire.

Identifier qui gère réellement l’intégration

Commencez par un inventaire : connecteur ecommerce, application de flux, scripts internes, jobs planifiés et opérations manuelles. Pour chaque chemin, nommez le responsable, le compte marchand, le projet d’authentification, les méthodes appelées et la source de données utilisée. Ne partagez pas les jetons ou secrets dans ce document.

Google distingue les intégrations personnalisées des plateformes tierces, dont le partenaire gère la migration. Périmètre du sunset Un marchand utilisant un connecteur géré doit demander son état de compatibilité plutôt que créer une seconde chaîne d’envoi en parallèle. Un développeur responsable d’appels directs doit examiner son propre client.

Pour un incident 410, conserver le code, l’horodatage et les métadonnées non sensibles disponibles. Vérifiez l’endpoint réellement appelé. Un échec de l’API legacy ne signifie pas que la page produit renvoie 410 au visiteur ; ce sont deux systèmes différents. Un retry peut masquer temporairement le problème et compliquer le diagnostic.

Séparer l’entrée envoyée du produit traité

Merchant API distingue ProductInput, destiné aux données envoyées, et Product, qui représente leur résultat traité. Une écriture doit préciser la source concernée. Migration produits

Concevez donc deux étapes de validation : la transformation de vos données locales, puis le contrôle du résultat disponible chez Google. La première vérifie que votre programme a produit les bons champs. La seconde vérifie ce qui reste après traitement et règles de sources. Fusionner les deux ferait apparaître un envoi accepté comme une offre déjà correctement distribuée.

Dans votre journal interne, séparez « préparé », « envoyé », « accepté techniquement », « relu après traitement » et « statut de destination contrôlé ». Ces libellés constituent une proposition de suivi, pas de nouveaux statuts officiels de l’API. Ils rendent visible l’étape qui manque lorsque l’équipe commerciale demande si une promotion peut commencer.

Cartographier les sources avant toute écriture

Merchant API utilise des sources API explicites ; leurs identifiants doivent être retrouvés et associés à votre intégration. Migration des sources

Notre procédure proposée commence par une lecture de l’inventaire autorisé. Construisez un registre reliant l’offre à sa source actuelle, aux règles pertinentes et au propriétaire opérationnel. Faites relire les écarts avant d’introduire une nouvelle source.

Google documente l’« offer stealing » : insérer une offre existante dans une autre source primaire peut la déplacer et changer les règles qui lui sont appliquées. Avertissement de migration Une duplication apparente n’est donc pas un test sans conséquence.

Pour comparer deux transformateurs, utilisez d’abord un mode local sans envoi. Le transformateur candidat produit un fichier de différences ; l’ancien reste l’unique chemin d’écriture tant que la bascule n’est pas autorisée. Signaler une différence n’exige pas de modifier une offre en production.

Préserver les identifiants et les variantes de marché

La référence impose offerId, contentLanguage et feedLabel. Elle décrit aussi les noms encodés en base64url sans padding, recommandés notamment pour les caractères spéciaux. Référence ProductInput

Évitez de reconstruire une URL avec un simple remplacement des deux-points. Stockez les noms retournés par l’API, dont les formes encodées lorsque nécessaires, et vérifiez qu’ils correspondent à la bonne offre. Ajoutez au test un SKU contenant une barre oblique pour découvrir une hypothèse d’encodage trop simple.

Pour les audiences US et UK, une langue anglaise commune n’implique pas une même devise, une même livraison ou une même source. Le ciblage dépend également des paramètres de source et des attributs produit ; une étiquette de flux n’est pas une politique de livraison. Gestion et ciblage des produits

Séparez donc l’identité technique de l’offre, le pays servi et les faits commerciaux affichés. Ce contrôle protège aussi le lecteur humain, qui doit retrouver sur la page d’arrivée le prix et la promesse correspondant à sa sélection.

Exemple de registre Q4, sans appel API

Voici deux offres entièrement fictives dans un registre interne. Les alias de source ci-dessous ne sont pas des identifiants directement utilisables dans une requête.

Offre	Langue	Feed label	Prix attendu	Alias de source validé
KIT-Q4-01	en	US	49,90 USD	source-us
KIT-Q4-01	en	GB	39,00 GBP	source-uk

Le scénario d’acceptation impose que chaque ligne reste associée à sa source réelle vérifiée. Si le transformateur UK réutilise le prix USD ou l’alias américain, le test local doit échouer avant envoi. Ces prix n’expriment aucun cours de change ou tarif réellement pratiqué.

Contrôlez ensuite les champs visibles : titre, lien produit, disponibilité et devise. Une règle supplémentaire doit détecter une offre dont le prix promotionnel n’est pas prêt sur la page. Cette vérification est une proposition de contrôle commercial, distincte d’une garantie d’approbation Merchant Center.

Organiser une bascule limitée et observable

La documentation de gestion précise que les écritures concernent les sources API et que le résultat produit doit être consulté séparément. Guide de gestion Préparez une petite sélection représentative avant de traiter le catalogue entier : offre simple, variante, caractère spécial et contexte international.

Fixez un responsable de bascule, une fenêtre adaptée et une règle d’arrêt. Après chaque opération autorisée, rapprochez l’offre attendue, la source utilisée et le résultat relu. Un délai de traitement doit rester un état d’attente, jamais une validation improvisée.

La référence limite versionNumber aux insertions dans des sources primaires ; ce champ ne constitue pas une protection universelle pour PATCH. Portée de versionNumber Si plusieurs producteurs mettent à jour les mêmes offres, définissez d’abord leur responsabilité et leur ordre de traitement. Un champ mal appliqué ne corrige pas une architecture d’écriture concurrente.

Définir les preuves nécessaires avant la promotion

Notre grille d’acceptation requiert :

le responsable de chaque connecteur identifié et son état de migration consigné ;
les clés d’offre et sources rapprochées sans déplacement involontaire ;
les cas d’encodage vérifiés sur des fixtures ;
les prix, devises et disponibilités concordants après traitement ;
les diagnostics de destination examinés, séparément des réponses HTTP ;
une procédure de suspension de l’écriture défectueuse documentée.

Cette grille n’a pas été exécutée sur un compte marchand pendant cette recherche. Aucun taux de réussite ou délai garanti n’est avancé. Les fixtures locales démontrent au mieux la cohérence du transformateur, pas l’éligibilité d’un vrai produit.

Suivez ensuite erreurs par méthode, ancienneté des offres non rapprochées et écarts source/produit. Le registre gratuit de campagnes peut accueillir ces tâches. L’objectif Q4 est une information produit fiable ; visibilité, clics et commandes exigent leurs propres observations.

Publié par Search Engine Trends. Article original. Équipe et liens commerciaux.