Migration de l'API Global Catalog de Shopify : anticipez l'échéance de novembre

La migration de l'API Global Catalog de Shopify a une date limite fixe : le 2 novembre 2026. Si une application dont dépend votre entreprise appelle toujours l'API REST Global Catalog, elle doit passer à Global Catalog MCP avant que le service ne cesse de traiter le trafic. La première question à se poser est de savoir si l'un de vos outils dépend du point de terminaison en fin de vie. Voici comment nous identifierions ces dépendances, définirions le périmètre du travail et testerions le remplacement sans transformer un changement d'API spécifique en une reconstruction inutile.

Ce que la migration de l'API Global Catalog de Shopify implique

L'annonce faite par Shopify aux développeurs le 9 octobre indique que l'API REST Global Catalog, dépréciée en avril 2026, cessera de traiter le trafic le 2 novembre. Shopify désigne Global Catalog MCP, qui implémente le protocole de commerce universel (UCP), comme son remplaçant. La date d'arrêt figure également dans le journal des modifications pour les développeurs.

L'annonce concerne l'API REST Global Catalog. Cela ne signifie pas que toutes les intégrations Shopify basées sur REST cesseront de fonctionner le 2 novembre. Cette distinction est importante lors du briefing d'une agence ou d'un fournisseur d'applications. Une demande générale visant à « migrer nos API Shopify » peut créer de la confusion et gaspiller le temps limité disponible.

Ce changement concerne les développeurs et les entreprises dont les applications appellent cette API particulière. Un marchand n'ayant aucune dépendance de ce type n'a aucune migration à effectuer suite à cette annonce. Un marchand dont la découverte de produits côté client repose sur une application affectée a besoin de réponses de la part du propriétaire de l'application dès maintenant.

Notre point de vue : traitez ceci comme une revue de dépendances pouvant mener à une migration. Ne commencez pas par une demande de devis de développement. Commencez par prouver que vous êtes concerné.

Découvrez si votre boutique présente une dépendance

Demandez aux responsables de vos intégrations personnalisées d'examiner le code et le trafic réel. Une liste des applications installées est un bon point de départ, mais elle peut ne pas révéler un service externe ou un prototype mis en production par quelqu'un.

Posez à chaque responsable une question claire : « Un service de production, une tâche planifiée ou une expérimentation active appelle-t-il l'API REST Global Catalog de Shopify ? » Demandez-leur de la distinguer des autres API Shopify.

• Applications personnalisées : Recherchez des références au service en cours de retrait dans les référentiels, la configuration et l'historique de déploiement.
• Outils tiers : Demandez au fournisseur de confirmer par écrit s'il est concerné et, le cas échéant, de communiquer son calendrier de migration.
• Expérimentations : Incluez les démos de découverte de produits et les intégrations d'agents que les clients ou le personnel utilisent encore.
• Tâches planifiées : Examinez un historique suffisant pour capturer les tâches qui s'exécutent rarement. Une après-midi calme dans les logs ne prouve pas qu'une dépendance est inutilisée.

Pour chaque dépendance confirmée, enregistrez son responsable, son objectif et son lieu d'exécution en production. Ajoutez l'appel observé le plus récemment et ce qui se passe s'il échoue. « Les clients perdent un panneau de recommandation de produits » et « une expérience interne cesse de s'actualiser » ne doivent pas avoir la même priorité.

Tenez également une liste des éléments « non affectés » avec des preuves à l'appui. Cela évite que la même question ne circule au cours des deux prochaines semaines.

Définissez le périmètre de la migration autour du comportement

Shopify désigne Global Catalog MCP comme le remplaçant. Cela ne signifie pas que le travail consiste simplement à remplacer une URL. L'annonce seule ne précise pas tout ce dont votre implémentation aura besoin.

Votre développeur doit vérifier les exigences d'accès actuelles et les opérations prises en charge par le remplaçant par rapport aux besoins de l'application. Examinez explicitement la façon dont les requêtes sont construites, dont les réponses sont traitées et dont les erreurs sont gérées. Ne présumez pas que les modèles REST familiers fonctionneront sans modification.

Documentez le comportement existant

Avant de modifier le code, décrivez ce que fait l'intégration aujourd'hui en termes qu'un marchand peut vérifier. Par exemple : un client recherche un produit, l'application récupère les produits correspondants et l'interface affiche une offre renvoyant à la bonne destination.

Ceci est un flux illustratif, pas une description de chaque intégration de catalogue. Cette description peut plutôt concerner un processus en arrière-plan. L'objectif est de documenter le comportement observable, et non de préserver des détails d'implémentation dont personne n'a besoin.

Collectez des entrées représentatives et les résultats attendus. Incluez une recherche qui ne renvoie aucun résultat et des produits avec plusieurs variantes. Décidez quels champs sont nécessaires au fonctionnement de l'application et desquels elle peut se passer sans induire quiconque en erreur.

Séparez le travail nécessaire des ajouts tentants

Une migration sous pression temporelle n'est pas le bon moment pour introduire une nouvelle stratégie de recommandation. Préservez d'abord le comportement requis. Mettez les améliorations optionnelles dans une version séparée, à moins que le remplacement ne les rende nécessaires.

Dans la mesure du possible, nous placerions également les appels spécifiques aux fournisseurs derrière un petit adaptateur. Cela permet au reste de l'application d'utiliser un format interne stable. Cela demande un peu plus de travail maintenant, donc évitez une abstraction élaborée pour une expérience qui sera de toute façon abandonnée. Pour un service de production maintenu, la séparation mérite généralement d'être envisagée.

Utilisez la mise à jour des prix comme test de régression

Un changement séparé le 9 octobre rend la gestion des prix particulièrement pertinente. La mise à jour de l'API Catalog de Shopify indique que le prix « compare-at » d'un marchand peut apparaître dans le champ optionnel de variante list_price. Le champ price existant ne change pas.

Selon Shopify, list_price utilise le même objet Price que price, avec un montant dans des unités monétaires mineures et une devise. Les produits renvoient également list_price_range, contenant le list_price le plus bas et le plus élevé parmi les variantes du produit. Le champ fait partie de la spécification de catalogue UCP, version 2026-08-25.

La documentation pour les développeurs de Shopify indique que list_price n'est renvoyé que lorsque le marchand partage les prix « compare-at » via le Catalog Mapping, que le prix « compare-at » est supérieur au prix dans le contexte de l'acheteur, et que le marchand affiche les prix « compare-at » dans la région de l'acheteur. Pour les acheteurs de l'EEE, le champ n'est pas renvoyé si la boutique y masque les prix « compare-at ».

Pour les marchands, c'est une raison d'examiner les prix de référence publiés. Pour les développeurs, c'est un test de régression utile pendant la migration. Il s'agit d'une mise à jour distincte, et Shopify précise que le nouveau champ lui-même ne nécessite aucune action. Ne le confondez pas avec le retrait obligatoire.

• list_price manquant : Shopify indique qu'un champ absent signifie qu'aucun prix « compare-at » n'est renvoyé pour cet acheteur et cette configuration. N'en déduisez rien sans vérifier le contexte.
• Formatage du montant : Interprétez correctement les unités mineures pour la devise. N'appliquez pas de conversion décimale universelle sans vérifier les règles de la devise.
• Correspondance des variantes : Calculez une économie affichée à partir du prix actuel et du list_price pour la même variante, dans la même devise.
• Plages de prix des produits : Ne combinez pas les bornes de plages de prix différentes pour annoncer une remise qu'aucune variante ne justifie.

À titre de test illustratif, une variante au prix de 800 SEK avec un prix « compare-at » de 1 000 SEK bénéficie d'une remise de 20 %. Le prix de référence d'une autre variante ne peut pas être utilisé comme dénominateur dans ce calcul. Un prix « compare-at » publié n'établit pas non plus, en soi, qu'une allégation promotionnelle est conforme aux règles de prix locales.

Établissez un plan de transition efficace après le 2 novembre

Au 12 octobre, il reste environ trois semaines avant la date limite. C'est suffisant pour une migration contrôlée si vous identifiez rapidement le responsable. Il reste peu de place pour une dépendance non gérée découverte à la fin du mois.

Les dates ci-dessous constituent notre calendrier de travail recommandé, et non des dates limites supplémentaires imposées par Shopify.

D'ici le 14 octobre : terminez l'examen des dépendances

Confirmez quels services sont affectés et attribuez un responsable à chacun. Si un fournisseur ne peut pas encore confirmer s'il utilise l'API en fin de vie, laissez cette dépendance marquée comme non résolue. Le silence n'est pas la preuve que la situation est sans risque.

D'ici le 21 octobre : démontrez que le remplacement fonctionne

Exécutez le remplacement via des flux représentatifs dans un environnement hors production. Comparez les résultats commerciaux au lieu d'exiger des structures de réponse identiques. Enregistrez les capacités manquantes suffisamment tôt pour choisir une solution de repli.

D'ici le 28 octobre : déplacez le trafic de production

Laissez une marge de sécurité avant l'arrêt. Surveillez les taux de réussite des requêtes et les temps de réponse, puis vérifiez le résultat côté client. Un appel réseau réussi ne suffit pas si l'interface affiche la mauvaise variante ou ne peut pas ouvrir le bon produit.

Avant le 2 novembre : supprimez l'ancienne dépendance

Vérifiez à nouveau le trafic et les tâches planifiées. Désactivez les chemins obsolètes et mettez à jour la documentation opérationnelle. Assurez-vous que quelqu'un est responsable de la vérification de la première exécution normale après l'arrêt.

Après le retrait, revenir à l'ancienne API n'est pas une option. Définissez une solution de repli qui n'en a pas besoin. Selon l'application, cela pourrait signifier supprimer temporairement un module de découverte de produits optionnel ou diriger les clients vers la recherche existante de la boutique. Évitez d'afficher des prix obsolètes comme solution de repli par défaut.

Que demander à un fournisseur d'applications avant de conclure

Le « nous prenons en charge Shopify » d'un fournisseur est trop vague. Demandez si son service de production utilise l'API concernée, si le remplacement est déjà en ligne et quelles preuves démontrent sa préparation. Demandez une date de transition prévue si le travail reste à faire.

Pour un outil payant, nous demanderions également ce que les clients vivent lorsque le remplacement est indisponible. C'est un critère d'achat raisonnable : une application utile doit avoir un comportement en cas de défaillance compréhensible. Les petits marchands ne devraient pas avoir à cartographier l'infrastructure d'un fournisseur pour savoir si un panneau de produits va disparaître.

Clôturez le problème uniquement lorsqu'il existe une preuve : soit le service n'appelle pas l'API en cours de retrait, soit le remplacement fonctionne en production et les anciens appels ont cessé. Un changement de code terminé qui n'a pas été déployé laisse le risque exactement là où il était.

Résumé

• L'API REST Global Catalog cessera de traiter le trafic le 2 novembre 2026. Confirmez si vous en dépendez avant de commander des travaux.
• Migrez les intégrations affectées vers Global Catalog MCP et testez le comportement sur lequel les clients ou le personnel s'appuient.
• Incluez les prix « compare-at » optionnels et la gestion des montants au niveau des variantes dans les tests de régression.
• Terminez la transition avant la date limite et choisissez une solution de repli qui ne dépend pas de l'API retirée.

Sources

• L'API REST Global Catalog cesse de traiter le trafic le 2 novembre 2026
• L'API Catalog renvoie désormais les prix « compare-at » en tant que list_price

Vous voulez que nous nous en chargions ?

Nous sommes une agence Shopify Premier, et c'est notre quotidien : performance, optimisation du taux de conversion (CRO) et création de boutiques axées sur les résultats. Réservez une revue de boutique gratuite et nous vous montrerons les trois changements que nous ferions en priorité.

Foire aux questions

Quand l'API REST Global Catalog de Shopify cesse-t-elle de fonctionner ?

Selon Shopify, l'API REST Global Catalog cessera de traiter le trafic le 2 novembre 2026. Elle a été dépréciée en avril 2026. Les applications concernées doivent migrer avant l'arrêt.

Chaque boutique Shopify doit-elle migrer depuis l'API Global Catalog ?

Non. L'annonce concerne les applications qui appellent l'API REST Global Catalog. Demandez à vos développeurs et fournisseurs d'applications de vérifier si un service de production ou une tâche planifiée l'utilise.

Qu'est-ce qui remplace l'API REST Global Catalog de Shopify ?

Shopify désigne Global Catalog MCP, qui implémente le protocole de commerce universel, comme le remplaçant. Les développeurs doivent vérifier ses exigences actuelles et les opérations prises en charge au lieu de supposer que la migration n'est qu'un simple changement d'URL.

Que signifie list_price dans Shopify Catalog ?

list_price est un champ de variante optionnel pour le prix « compare-at » du marchand. Il utilise un objet Price avec un montant dans des unités monétaires mineures et une devise. Le champ price existant est inchangé. Shopify ne renvoie le champ que lorsque ses conditions pour le contexte de l'acheteur et les paramètres du marchand sont remplies.

Une application peut-elle revenir à l'ancienne API REST Global Catalog après le 2 novembre ?

Non. Ce n'est pas une solution de repli viable une fois que l'API a cessé de traiter le trafic. Prévoyez une expérience réduite ou un autre chemin pris en charge qui ne dépend pas du service retiré.