Trois présentoirs de produits reliés à une jonction en laiton, à côté d’un ancien connecteur débranché.

Blog 1Design

Shopify Global Catalog : votre intégration utilise-t-elle encore l’API qui s’arrête le 2 novembre ?

L’API REST Global Catalog de Shopify s’arrête le 2 novembre 2026. Identifiez les appels concernés et préparez une migration MCP vérifiable, sans confusion.

Le 2 novembre 2026, Shopify annonce l’arrêt des réponses de son API REST Global Catalog, y compris pour les catalogues enregistrés. Cette échéance vise un service précis de découverte de produits. Elle ne signifie ni la fermeture des boutiques Shopify, ni l’arrêt de toutes les API REST de la plateforme.

La première décision n’est donc pas « faut-il migrer ma boutique ? », mais « une application dont je dépends appelle-t-elle encore ce service ? ». Un comparateur, un assistant d’achat ou une sélection de produits provenant de plusieurs marchands peuvent être concernés. Une boutique utilisant Shopify n’est pas automatiquement dans ce cas.

L’annonce officielle du 9 octobre, reconsultée le 23 octobre, donne quatre routes à rechercher et leur remplacement par Global Catalog MCP, qui implémente le protocole UCP. Le passage demande davantage qu’un changement d’adresse : les requêtes, les identifiants et les réponses doivent être adaptés. Voici le dossier à constituer avec votre intégrateur avant de décider d’une bascule.

Commencer par une adresse, pas par le nom Shopify

Demandez au responsable technique si le code, les réglages ou les journaux d’appels de l’intégration contiennent https://discover.shopifyapps.com/global/. L’annonce indique que les requêtes vers ce service échoueront après l’arrêt. Les chemins concernés sont /global/v2/search, /global/v2/p/{upid}, /global/v2/p/by-variant/{vid} et /global/v2/lookup.

Une recherche dans le code fournit une piste ; elle ne prouve pas qu’un appel est encore exécuté. À l’inverse, l’absence de cette chaîne dans votre propre dépôt n’exclut pas un usage par une application tierce. Demandez alors à son éditeur une confirmation écrite du service utilisé, de l’état de migration et des contrôles effectués. Ne lui transmettez pas de clés d’accès dans un formulaire public.

La conclusion de cet inventaire doit appartenir à l’un de trois états : usage confirmé, absence d’usage établie sur le périmètre examiné, ou dépendance non identifiée. « Nous avons mis Shopify à jour » n’est pas une réponse à cette question. Pour un service externalisé, le nom de l’éditeur et le responsable du suivi comptent autant que le nom du connecteur.

La documentation distingue aussi deux besoins : Global Catalog sert à découvrir des produits de plusieurs marchands ; Storefront Catalog concerne les agents rattachés à un seul marchand. Ne choisissez pas Global Catalog uniquement parce que son nom paraît plus complet. Commencez par le parcours réel : qui cherche quoi, chez quels vendeurs, et vers quelle page l’acheteur est-il envoyé ?

Ce qui remplace les quatre anciens appels

La nouvelle adresse documentée est https://catalog.shopify.com/api/ucp/mcp. MCP fournit des outils que l’application appelle ; UCP définit les structures de requête et de réponse à respecter. La table suivante est une correspondance de fonctions, pas une recette de remplacement caractère par caractère.

Appel REST existantOutil cibleAdaptation à faire valider
/global/v2/searchsearch_catalogRequête, filtres, contexte acheteur et pagination
/global/v2/p/{upid}get_productIdentifiant sous la forme gid://shopify/p/{upid}
/global/v2/p/by-variant/{vid}get_productIdentifiant sous la forme gid://shopify/ProductVariant/{id}
/global/v2/lookuplookup_catalogLot d’identifiants, avec un maximum annoncé de 50 par requête

Les accolades représentent ici des valeurs à fournir ; ce ne sont pas des identifiants à copier. Il faut notamment distinguer le produit regroupé dans le catalogue, sa variante et son vendeur. Une correspondance obtenue sur un titre ou une image ne remplace pas cette identité.

Chaque requête doit inclure l’URL du profil agent dans meta.ucp-agent.profile. La documentation précise que les outils proposés dépendent des capacités déclarées par ce profil. Une erreur de négociation n’est donc pas forcément une panne du catalogue. Le prestataire doit contrôler le profil, les capacités de base et les extensions nécessaires aux données utilisées par votre application.

Pour un catalogue enregistré, l’annonce demande de transmettre son identifiant dans catalog.catalog_id, au lieu d’appeler une adresse spécifique à ce catalogue. Ce point est important si votre sélection est volontairement limitée à certains vendeurs ou produits. Obtenir des résultats ne prouve pas que le bon périmètre a été conservé.

Shopify indique que le mécanisme d’authentification ne change pas : les jetons peuvent toujours être générés à partir des identifiants client du Dev Dashboard. Cela ne dispense pas de vérifier les droits et la configuration effectivement utilisés. Cet article ne nécessite ni création de compte, ni rotation de secret, ni partage de jeton ; ces opérations ne doivent pas être improvisées pour contourner un test qui échoue.

Une offre française ne se résume pas à un produit trouvé

Imaginons un assistant d’achat fictif qui compare des sacs de plusieurs marchands pour un acheteur en France. Après modification du connecteur, il retrouve un sac du même nom. Est-ce une preuve de migration réussie ? Pas encore : la variante peut avoir changé, le prix peut être interprété avec une mauvaise unité ou le vendeur peut ne pas livrer à l’adresse souhaitée.

La documentation expose un contexte acheteur avec notamment pays, langue et devise, ainsi que des filtres de livraison. Le contexte sert à la pertinence et à la localisation ; il ne faut pas le confondre avec une preuve de livraison ni avec un filtre explicitement appliqué. Le dossier de recette doit préciser le pays et la devise attendus, puis relever les informations réellement retournées et affichées.

Les prix sont exprimés en unités monétaires mineures. Pour un montant en euros, 4 990 centimes correspondent à 49,90 € : afficher directement le nombre 4 990 comme un montant en euros serait une erreur d’intégration. La devise doit être lue avec le montant, pas ajoutée par habitude parce que l’interface est française.

Le champ list_price, lorsqu’il est présent, correspond au prix de comparaison communiqué pour le marché de l’acheteur. La documentation le conditionne au partage de cette information par le marchand et à un montant supérieur au prix courant. Il ne faut donc pas fabriquer de prix barré lorsqu’il manque. Sa présence n’établit pas à elle seule la conformité juridique d’une annonce de réduction en France : la présentation commerciale nécessite sa propre validation.

Une autre frontière est moins visible. Certains champs, dont la description, les options ou des attributs, sont marqués Inferred : Shopify peut les générer ou les enrichir. Ce sont des signaux de découverte, pas nécessairement le texte rédigé par le marchand. Pour une matière, une compatibilité ou une caractéristique décisive, ne transformez pas silencieusement cette information en engagement du vendeur.

Cette distinction doit rester visible dans le parcours conçu autour du catalogue e-commerce. La migration technique ne doit pas rendre l’interface plus affirmative que les données dont elle dispose.

Le bon dossier de recette contient aussi les absences

Une démonstration sur une recherche qui fonctionne est utile, mais insuffisante. Préparez un jeu de cas stable et autorisé, avec les mêmes intentions d’achat et les mêmes identifiants avant et après adaptation. L’objectif n’est pas d’exiger un classement identique entre deux systèmes de recherche ; il est de vérifier que le service reste juste et compréhensible.

Le cas nominal. Rechercher un produit connu pour un acheteur en France, sélectionner une variante puis relever le vendeur, le prix, la devise, la disponibilité et le lien de destination. Faire valider les informations affichées par la personne responsable du parcours commercial, pas seulement par le développeur du connecteur.

Le changement de variante. Passer d’une couleur ou d’une taille à une autre. Vérifier que l’identifiant, le prix et la destination correspondent à la sélection finale. Une image restée en cache ou un lien attaché à la variante précédente peut produire une interface convaincante mais incorrecte.

Le produit introuvable ou indisponible. La documentation de lookup_catalog prévoit des messages not_found pour les identifiants non résolus. Elle indique également un filtre de disponibilité activé par défaut. L’absence de résultat doit être distinguée d’une indisponibilité, d’un filtrage et d’une erreur technique. Un message « aucun produit » ne doit pas masquer un échec d’authentification.

Le lot de références. Vérifier la correspondance entre chaque entrée et les variantes retournées. Plusieurs identifiants résolvant le même produit peuvent être regroupés dans une seule réponse produit : compter les objets retournés ne suffit donc pas pour décider qu’une référence a disparu. Conserver les informations de corrélation et traiter les références non résolues explicitement.

Le catalogue enregistré. Rejouer une sélection qui doit rester limitée et vérifier son identifiant, les filtres attendus et les résultats. Demander une explication si un vendeur hors périmètre apparaît. Ne pas remplacer discrètement un catalogue enregistré par une recherche globale pour obtenir une réponse sans erreur.

La page suivante. Vérifier la navigation au-delà du premier écran. La documentation utilise un curseur de pagination et précise que total_count est une estimation, pas un total exact. Une interface qui calcule un nombre définitif de pages à partir de ce champ peut donner une fausse impression d’exhaustivité. Le contrôle doit porter sur le curseur, l’indication de suite disponible et la manière dont le résultat est expliqué au visiteur.

Ces cas constituent un protocole proposé, pas des essais réalisés sur une boutique cliente. Chaque observation doit comporter la date, la configuration, l’entrée, la réponse utile expurgée de secrets, le résultat visible et une décision. Les journaux techniques complets restent dans un espace à accès limité ; ils n’ont pas à être copiés dans un ticket public.

La date d’arrêt change aussi le plan de retour arrière

Avant le 2 novembre, revenir temporairement à l’ancien connecteur peut encore être envisagé selon les conditions de l’intégration. Après l’arrêt annoncé, une restauration du code REST ne rétablit pas le service supprimé. Le plan de récupération doit donc prévoir autre chose qu’un simple bouton « revenir à la version précédente ».

Selon le rôle de la fonction, une solution de repli peut consister à suspendre clairement la recherche multi-marchands, à retirer une recommandation indisponible ou à orienter vers un parcours marchand connu et préalablement validé. Ce sont des choix de produit à approuver, pas des comportements à improviser pendant l’incident. Il ne faut pas continuer à présenter un ancien prix comme actuel uniquement pour éviter une page vide.

Demandez au prestataire une décision écrite : appels remplacés, cas acceptés, écarts restants, responsable de bascule et conduite à tenir en cas d’échec. Ajoutez un contrôle après mise en service, avec une observation des erreurs et du parcours visible. Cette responsabilité relève du suivi technique de l’intégration, même lorsque la boutique elle-même fonctionne normalement.

Ne mélangez pas cette opération avec les autres dépendances Shopify. La transmission des commandes à un ERP pose notamment des questions de doublons et de réception des événements. Ce sont d’autres flux, avec d’autres preuves à obtenir. Une migration Global Catalog acceptée ne valide pas l’ensemble de vos connecteurs.

Le message à envoyer à votre intégrateur

Notre service utilise-t-il encore Global Catalog REST sur discover.shopifyapps.com/global/ ? Merci d’indiquer le périmètre vérifié, les appels concernés et les éventuelles dépendances tierces. Si nous sommes concernés, nous souhaitons la correspondance vers les outils MCP/UCP, la validation du profil agent et des catalogues enregistrés, ainsi qu’une recette sur les identifiants, variantes, prix en euros, disponibilités, absences de résultat et pagination. Merci de préciser les écarts restants, le responsable de la bascule et le repli prévu après l’arrêt du 2 novembre 2026. Aucun secret ne doit être joint à cette réponse.

Si personne ne peut aujourd’hui répondre à la première phrase, commencez par un inventaire borné. 1Design peut vous aider à cadrer l’examen d’une intégration identifiée : appels réellement concernés, dépendances, correspondances et preuves nécessaires avant bascule. Le développement, les accès et l’intervention en production font l’objet d’un périmètre distinct ; cet examen ne vaut pas autorisation de migration.

Sources et périmètre

Sources officielles consultées le 23 octobre 2026 :

Aucun appel authentifié, test client ou changement de production n’a été réalisé pour cet article. Les scénarios sont illustratifs. L’annonce donne une date d’arrêt, pas une heure contractuelle reproduite ici : prévoyez la validation avant cette date et reconsultez les sources au moment de l’intervention.

Vous voulez un site plus clair, plus crédible ou mieux pensé pour convertir ?

Recevoir 3 pistes gratuites pour améliorer votre site