Shopify UCP Location : aider les agents IA à trouver tes magasins physiques
Par Teo Comyn · Consultant Shopify · CRO, SEO & Liquid · EXPERAISE
Lecture ~11 min · Shopify · E-commerce · IA · Octobre 2026 · Mis à jour 2026-10-27
Shopify permet désormais à un agent UCP compatible de rechercher les magasins physiques d’un marchand et de repérer ceux où des variantes sont disponibles. Cela ne réserve aucun produit et ne confirme aucun retrait. Pour une marque qui vend en ligne et en boutique, la première tâche consiste à fiabiliser les établissements exposés, puis à vérifier ce que l’agent peut réellement en conclure.
L’annonce figure au 22 octobre 2026 dans le changelog développeur. Voici comment cadrer un pilote utile, avec les limites de l’implémentation Shopify et une grille de réponses attendues. Aucun magasin client ni assistant n’a été testé pour ce guide.
Ce qui change avec UCP Location sur Shopify
La nouvelle capacité concerne les vitrines Shopify qui possèdent au moins un magasin éligible. Elles annoncent les capacités dev.ucp.common.location.search et dev.ucp.common.location.lookup dans leur profil de découverte, à l’adresse /.well-known/ucp. Les outils deviennent disponibles lorsque l’agent négocie ces capacités avec la version UCP 2026-08-25. Cette évolution est facultative pour les intégrations qui n’utilisent pas les lieux. Annonce officielle de la découverte de magasins.
Le périmètre est important : tu interroges les établissements d’un marchand déterminé. Ce n’est pas une recherche universelle de toutes les enseignes autour de l’acheteur. La documentation distingue le Storefront Catalog, limité à une boutique, du Global Catalog, conçu pour une découverte de produits entre marchands. Choix du périmètre Storefront ou Global.
Une question pertinente serait : « Parmi les boutiques de cette marque, lesquelles peuvent proposer ces deux variantes près du lieu que j’ai choisi ? » Ce n’est pas encore : « Réserve-les dans le magasin le plus proche pour demain. » La recherche d’un lieu et l’engagement commercial restent deux opérations différentes.
Pour la vue d’ensemble du protocole, le guide UCP et Shopify conserve son rôle. Ici, on traite un besoin précis : la découverte d’établissements physiques et la qualité de la réponse donnée au client.
Côté marchand : vérifier quels établissements doivent être trouvables
Shopify décrit un magasin éligible comme un établissement actif, géré par le marchand, configuré pour vendre en personne et déclaré comme Physical storefront. Un emplacement de stockage n’est donc pas automatiquement une boutique à présenter au public. Définition retenue pour l’annonce.
Dans Paramètres → Emplacements, vérifie le nom et l’adresse de chaque lieu concerné. Le réglage Physical storefront permet de le lister comme magasin physique, notamment dans Shop et auprès des agents IA. La documentation des emplacements distingue ce réglage de la disponibilité du stock pour les achats en ligne. Gestion des emplacements et magasin physique.
Je préparerais une liste attendue avant de modifier quoi que ce soit : établissements ouverts au public, entrepôts à ne pas présenter comme magasins, noms permettant de distinguer deux adresses et personne responsable de chaque donnée. Le but n’est pas d’exposer davantage de lieux à tout prix. C’est d’éviter qu’un acheteur soit orienté vers un local qui ne l’accueille pas.
Contrôle aussi les coordonnées géographiques disponibles. L’annonce indique que les résultats contiennent notamment l’identifiant, le nom et l’adresse, ainsi que les coordonnées lorsqu’elles ont été renseignées. Une adresse lisible par un humain ne suffit pas à démontrer que la recherche par distance fonctionne correctement. Prévois une vérification dédiée, sans inventer de coordonnées pour compléter une réponse.
Cette préparation n’implique pas de remplacer ton thème ou de déployer un storefront headless. Ne lance pas un chantier d’architecture pour ce seul motif avant d’avoir vérifié l’état réel des capacités exposées par ta boutique et le besoin de l’assistant.
Côté agent : profils, recherche et récupération par identifiant
Le serveur MCP de la vitrine utilise un profil d’agent pour négocier les capacités disponibles. Shopify compare ce que l’agent déclare et ce que le marchand prend en charge ; une URL de profil invalide, inaccessible ou sans capacité compatible peut empêcher la négociation. Le profil doit être fourni dans les requêtes concernées via meta.ucp-agent.profile. Fonctionnement officiel des profils.
Pour le développeur, le livrable n’est pas simplement un appel qui répond. Il doit montrer la version négociée, les capacités effectivement retenues et les outils accessibles dans ce contexte. Ne copie pas un profil d’exemple destiné uniquement au checkout en supposant qu’il déclare aussi la découverte des magasins.
L’annonce expose deux outils distincts. search_locations recherche les magasins, avec des critères comme le nom, la ville, la distance ou les variantes recherchées. lookup_locations récupère des lieux par identifiant. Le premier découvre des candidats ; le second permet de retrouver précisément un lieu déjà identifié. L’endpoint documenté est celui de la vitrine, https://{storedomain}/api/ucp/mcp, pas une route de l’Admin API. Outils et conditions d’accès annoncés.
Évite de conserver uniquement « boutique centre-ville » dans le parcours. Deux établissements peuvent porter des noms proches. Garde l’identifiant retourné et le contexte du marchand pour la suite, puis revérifie les données utiles avant une réponse qui engage le déplacement de l’acheteur.
Point de documentation au 25 octobre : la page Storefront Catalog consultée liste encore les trois outils de catalogue produit, sans détailler les deux outils de lieux décrits par l’annonce. Cela ne prouve pas une panne du service. Avant une implémentation, confronte annonce, profil de découverte et schéma réellement retourné ; ne fabrique pas un corps de requête à partir d’une ancienne page. Aucun payload présenté comme exécutable ou testé n’est fourni dans ce guide.
Les limites à ne pas transformer en promesses commerciales
La spécification UCP décrit un modèle plus large que le sous-ensemble pris en charge par Shopify. Elle prévoit par exemple des critères d’horaires, de services et de desserte. Leur présence dans le standard ne signifie pas qu’un marchand Shopify peut tous les utiliser dans ce parcours. Spécification UCP Location.
Tableau : défilement horizontal si nécessaire.
| Besoin du client ou du développeur | Périmètre Shopify annoncé | Conclusion à éviter |
|---|---|---|
| Trouver une boutique à proximité | Recherche par distance avec un centre explicite et un rayon en mètres. | Déduire le point de départ depuis l’IP ou un contexte non partagé. |
| Vérifier deux variantes dans un même magasin | Le filtre accepte jusqu’à dix identifiants de variantes ; chaque variante doit être disponible pour que le lieu corresponde. | Additionner les disponibilités de plusieurs boutiques comme si tout était au même endroit. |
| Connaître le stock exact | Correspondance de disponibilité provisoire selon les règles Shopify. | Annoncer une quantité ou une réservation à partir de cette seule réponse. |
| Trouver un lieu ouvert ou un service particulier | Filtres hours, amenities, filtres personnalisés et relation serves non pris en charge dans cette implémentation annoncée. | Présenter « ouvert maintenant » ou « livre chez toi » comme une réponse vérifiée par ces filtres. |
| Acheter avec retrait dans le magasin choisi | Le checkout de retrait pour un lieu sélectionné n’est pas pris en charge par ce parcours annoncé. | Affirmer que le retrait est confirmé après une recherche de magasins. |
La source Shopify précise que les filtres non pris en charge renvoient une erreur invalid_input, plutôt que d’être ignorés. L’agent doit donc traiter cette erreur et expliquer la limite, pas reformuler un échec technique en « aucun magasin ne correspond ». Limites d’implémentation Shopify.
Pour la position de l’acheteur, demande un lieu qu’il choisit de partager : ville, point de départ ou position selon ton interface. N’affiche pas une proximité personnalisée si tu n’as pas ce contexte. Ne conserve pas des coordonnées précises dans tes outils marketing pour simplement mesurer une recherche.
Cadrer un pilote en cinq étapes
- Écrire la question et la bonne limite de réponse. Par exemple : trouver les magasins d’une marque où deux variantes peuvent être disponibles près d’une ville choisie. Définis ce que l’agent peut affirmer et ce qu’il doit encore faire vérifier. Exclue toute promesse de réservation ou de retrait que l’intégration ne sait pas tenir.
- Préparer un référentiel d’établissements attendu. Fais valider les noms, adresses, identifiants et lieux à présenter. Relève les incohérences avant de modifier les réglages. N’active pas un entrepôt comme magasin physique uniquement pour qu’il apparaisse dans un test.
- Vérifier la négociation avec le développeur. Contrôle le profil marchand, le profil d’agent, la version UCP et la présence des capacités de lieux. Fais relever les outils et leurs schémas dans une cible autorisée. Une capacité absente appelle une investigation de configuration ou de compatibilité, pas l’invention d’un endpoint alternatif.
- Exécuter les scénarios normaux et les erreurs. Utilise des variantes réelles de la cible de test et un lieu de référence explicitement choisi. Vérifie les noms, villes, distances et cas sans résultat. Le développeur doit aussi traiter la pagination : la recherche retourne dix lieux par défaut, avec une limite réglable jusqu’à 250 ; il faut reprendre le curseur de réponse pour la page suivante. Pagination annoncée.
- Recevoir la réponse client, pas seulement le JSON. Lis ce que l’assistant affiche après chaque résultat ou erreur. S’il écrit « prêt à retirer » alors que le service a seulement trouvé une correspondance de disponibilité, la recette échoue même avec une réponse technique valide. Documente les points non testés avant de décider d’ouvrir le pilote à d’autres utilisateurs.
Exemple fictif : une enseigne possède trois magasins. Une variante sable est disponible dans le premier, une variante marine dans le deuxième, et les deux dans le troisième. Pour une recherche contenant les deux identifiants, les deux premiers magasins ne doivent pas être fusionnés en une réponse « panier disponible sur place ». Le troisième reste un candidat de disponibilité, pas un engagement de stock réservé. Cette situation sert à préparer une recette ; elle n’a pas été exécutée sur une boutique.
La grille de recette : résultats, absence de résultat et erreurs
Tableau : défilement horizontal si nécessaire.
| Scénario proposé | Contrôle attendu | Preuve à conserver |
|---|---|---|
| Nom ou ville de magasin connue | La réponse renvoie le bon établissement du bon marchand. | Identifiant, adresse et contexte de requête, sans données personnelles inutiles. |
| Distance depuis un point choisi | Le centre et l’unité du rayon sont explicités. | Paramètres, résultats et vérification indépendante du lieu attendu. |
| Deux variantes réparties entre magasins | Un lieu doit correspondre à toutes les variantes demandées. | Référentiel attendu et réponse réelle, avec les limites de disponibilité. |
| Aucun lieu correspondant | L’assistant distingue absence de correspondance et panne. | Réponse technique et formulation montrée au client. |
| Filtre d’horaires non pris en charge | L’erreur est traitée sans inventer un magasin ouvert. | Erreur observée et solution de repli explicite. |
| Plusieurs pages ou plus de dix lieux à récupérer | Pagination et lots sont parcourus sans omission silencieuse. | Curseurs suivis et identifiants récupérés. |
| Passage vers l’achat | L’agent ne promet ni quantité réservée ni retrait confirmé. | Écran ou réponse finale et étape de validation restante. |
Pour la récupération par identifiant, l’annonce limite le traitement aux dix premiers identifiants distincts. Une demande plus longue produit un message batch_limit_applied ; le reste doit être envoyé dans une autre requête. La recette doit vérifier ce cas au lieu de déclarer des magasins introuvables parce qu’une liste a été tronquée. Limite de lookup.
Ajoute la date et l’environnement à chaque preuve. Les disponibilités peuvent évoluer entre la découverte et l’étape suivante. La spécification distingue précisément un signal provisoire de découverte et les conditions qui doivent être revérifiées lors d’une transaction. Frontière entre découverte et transaction.
Cette grille est proposée, pas exécutée sur les outils d’un client. Elle ne valide pas le fonctionnement de ChatGPT, Gemini ou de tous les assistants : chaque surface et chaque intégration doivent être observées séparément.
Ce que tu peux mesurer en SEO/GEO, et ce que tu ne peux pas en déduire
Sépare quatre observations : la capacité annoncée par le profil, une recherche technique réussie, une réponse effectivement montrée par un assistant et une action du client. Ces niveaux ne sont pas interchangeables. Un profil accessible ne prouve pas que ta marque est davantage recommandée dans les réponses IA.
Je suivrais d’abord les recherches terminées, les absences de résultat, les erreurs de négociation et les réponses nécessitant une correction. Puis les passages vers la page du magasin ou le parcours d’achat, si ton intégration permet de les mesurer correctement. Définis le périmètre avant de comparer ; ces indicateurs sont un plan proposé, pas un tableau de bord natif déjà installé.
Pour les références partagées avec tes pages publiques, maintiens des noms et adresses cohérents et des liens utiles vers les établissements réels. Cela sert la compréhension du client. Ce n’est pas une raison de générer des dizaines de pages de villes sans magasin ni contenu spécifique, ni une garantie de classement local.
La découverte d’un magasin ne configure pas non plus ta livraison locale. Le service à domicile et sa zone nécessitent un travail distinct. De même, les réponses de politique commerciale relèvent du guide Shopify Knowledge Base, tandis que la découverte de produits entre marchands est traitée dans le guide Global Catalog REST vers MCP.
Si tu veux cadrer ce pilote, commence par un inventaire de tes établissements et des réponses que l’assistant doit éviter. Un audit Shopify ciblé ou un accompagnement GEO Shopify peut définir les données, les responsabilités et les critères de réception. Pour discuter du besoin et de la cible à tester, parlons de ton projet.
Méthode et dernière vérification : 25 octobre 2026. Lecture de l’annonce Shopify du 22 octobre, des documentations de profils et d’emplacements, du guide Storefront Catalog et de la spécification UCP Location 2026-08-25. Le décalage entre l’annonce des outils de lieux et la page de catalogue consultée est explicité. Les matrices, le pilote et l’exemple sont des contributions éditoriales. Aucun appel à une boutique cliente, agent, transaction ou réservation n’a été exécuté. Relecture personnelle de Teo, indexation et citations IA non présumées.
Intégration éditoriale du 27 octobre 2026. Les dates de vérification des sources sont indiquées dans le texte ; aucune relecture personnelle ou recette marchande n’est présumée.
Sources & documentation officielle
Liens utiles (hors affiliation) pour creuser le sujet.
Articles connexes
- Universal Commerce Protocol : le jour où Shopify a réinventé l'e-commerce sans que personne ne s'en rende compteShopify ouvre l'Universal Commerce Protocol (UCP) aux développeurs : discovery, cart, checkout, orders via agents IA. Sy…
- Shopify Global Catalog : migrer de REST vers MCP avant le 2 novembreIdentifie les connecteurs concernés par l’arrêt du 2 novembre 2026, adapte appels et profil UCP, puis vérifie variantes,…
- Shopify Knowledge Base : le guide pour fiabiliser les réponses des IA sur ta boutiqueConfigurer Shopify Knowledge Base, vérifier les faits commerciaux, écrire les FAQ et suivre les questions des agents IA …
Accompagnement Shopify
Besoin d'aller plus loin qu'un article ? Pages services et audit.
