Le 1er octobre approche : l'échéance Polaris web components pour les extensions checkout

Shopify a fixé au 1er octobre 2026 la date à partir de laquelle vous ne pouvez plus déployer de mise à jour d'une application qui contient encore une extension de checkout ou de compte client en version d'API 2025-07 ou antérieure. C'est dans trois semaines, et cela tombe dans la fenêtre où la plupart des boutiques cherchent à se stabiliser avant le pic plutôt qu'à refactoriser du code d'interface.

L'application de la règle est un blocage de déploiement, pas une coupure d'affichage. Une extension déjà publiée en 2025-07 continue de tourner. Shopify n'a pas dit qu'elle cesse de s'afficher, et il n'y a pas de bascule automatique vers une version plus récente. Ce que vous perdez le 1er octobre, c'est la possibilité de livrer toute mise à jour de cette application tant que l'extension n'est pas en 2025-10 ou ultérieure. Ces versions utilisent les Polaris web components, donc le changement de version et la migration de composants sont le même travail.

Nous en parlons maintenant pour la même raison que Scripts en juillet et l'échéance des pages de remerciement la semaine dernière. C'est la troisième échéance plateforme du trimestre, et le schéma est constant : les équipes prises de court ne sont pas celles qui ont des problèmes difficiles, ce sont celles qui l'ont appris tard.

Ce qui change

Les extensions d'interface checkout et les extensions de compte client ont été construites contre une bibliothèque de composants propre à ces surfaces. La migration les fait basculer vers les Polaris web components, alignant ces surfaces sur le modèle de composants que Shopify utilise dans l'admin.

Concrètement, pour un développeur d'extension, les imports de composants, les noms d'éléments et, dans certains cas, la sémantique des propriétés et des événements changent. Ce n'est pas une réécriture de la logique de votre extension. C'est une réécriture de la façon dont cette logique s'affiche.

Qui doit agir

Plus de monde que la plupart des équipes ne le supposent. Passez cette liste en revue honnêtement.

• Les extensions sur mesure construites par votre équipe. Évidentes, et généralement celles dont on se souvient.
• Les extensions construites par une ancienne agence. Très fréquent, et le dépôt source n'est peut-être plus un endroit d'où vous pouvez déployer aujourd'hui. Vérifiez cela avant de vérifier le code.
• Les extensions d'applications tierces. L'éditeur est responsable, mais vous en subissez les conséquences. Demandez à chaque éditeur dont l'application s'affiche dans le checkout ou les comptes clients une confirmation écrite de son avancement.
• Tout ce qui a été construit lors d'une migration Checkout Extensibility en 2023 ou 2024. Assez ancien pour que personne dans l'équipe actuelle ne l'ait écrit.

Commencez par un inventaire de chaque extension s'affichant dans le checkout et les comptes clients, avec un nom de responsable en face. Les équipes découvrent régulièrement une extension qu'elles ne parviennent pas à attribuer, et cette découverte prend plus de temps que la migration elle-même.

La séquence d'audit et de migration

1. Inventorier et attribuer. Listez chaque extension, son dépôt source, son responsable, et si elle est à vous ou à un éditeur. Comptez deux jours, car les réponses ne sont souvent pas là où vous les attendez.
2. Écrivez à chaque éditeur cette semaine. Demandez une réponse précise : leur extension est-elle migrée, et sinon à quelle date le sera-t-elle. Une assurance vague n'est pas une réponse. Il vous faut une date, car après le 1er octobre cet éditeur ne pourra plus livrer un correctif, un changement de texte ou toute autre mise à jour tant que l'extension n'est pas sortie de 2025-07.
3. Comparez chacune de vos extensions à la référence de composants actuelle. Identifiez chaque composant utilisé et si son remplacement est une substitution directe ou un changement de comportement.
4. Migrez d'abord l'extension la plus risquée. Celle qui, si elle cessait de s'afficher, vous coûterait de l'argent plutôt que de la gêne. En général un sélecteur d'option de livraison, un champ de bon de commande B2B ou un contrôle d'âge ou d'éligibilité.
5. Testez sur une boutique de développement avec une vraie configuration. Chaque langue, chaque devise, et les deux surfaces checkout et compte client. Un composant qui s'affiche correctement en français sur écran large ne prouve rien.
6. Déployez avec la publication progressive. Elle est arrivée en juin. Servez-vous-en ici plutôt que d'envoyer des changements d'extension à tout le trafic d'un coup.

Une forme d'inventaire, plus utile en document suivi qu'en note mentale :

// Suivi de migration des extensions. À garder dans le dépôt, pas dans un fil de discussion.
const extensions = [
  {
    handle: "delivery-instructions",
    surface: "checkout",
    owner: "internal",
    repo: "shop-extensions",
    risk: "high",          // bloque un choix de livraison si l'affichage échoue
    migrated: false,
    verifiedOn: null
  },
  {
    handle: "loyalty-enrol",
    surface: "customer-account",
    owner: "vendor:loyalty-app",
    repo: null,
    risk: "medium",
    migrated: null,        // en attente de confirmation éditeur
    verifiedOn: null
  }
];

const blocking = extensions.filter(
  (e) => e.risk === "high" && e.migrated !== true
);

console.log({ total: extensions.length, blocking: blocking.length });

La valeur est dans les lignes migrated: null. Ce sont les extensions éditeurs dont personne n'a confirmé quoi que ce soit, et ce sont les applications que personne ne pourra mettre à jour après le 1er octobre.

Le problème du pic saisonnier

L'échéance est à trois semaines, et le Black Friday au 27 novembre. Cela laisse un intervalle réellement inconfortable où le travail sur les extensions doit atterrir, être testé, puis rester stable pendant une période de gel.

Nous recommandons de traiter cela comme le dernier changement significatif d'extension avant le gel. Migrez, vérifiez, puis ne touchez plus au code d'extension. Après le 1er octobre, s'arrêter n'est plus un choix. Si l'extension est encore en 2025-07, la plateforme bloque le déploiement pour vous, y compris un correctif découvert en novembre. Si vous prévoyiez d'autres travaux checkout ce trimestre, par exemple une évaluation de Checkout Components, intégrez la migration de composants à cet effort maintenant plutôt que de les séquencer, car les faire séparément revient à tester deux fois les mêmes surfaces.

Que faire si vous n'y arriverez pas

Si l'inventaire révèle une extension que vous ne pouvez pas migrer en trois semaines, décidez maintenant de ce que vous ferez la première fois que cette application aura besoin d'un changement.

Laissez en place une extension qui fonctionne. Elle continuera de s'afficher. La désactiver ne lève pas le blocage de déploiement, et retire une fonctionnalité dont Shopify n'a pas dit qu'elle échouerait. Le blocage porte sur l'application : si une seule de ses extensions est encore en 2025-07 ou antérieure, Shopify CLI refuse la prochaine mise à jour de toute l'application. Un correctif sur une autre extension de la même application attend cette migration.

Retirez l'extension de l'application seulement si vous pouvez accepter de la perdre et que vous devez continuer à livrer le reste. La désactiver dans l'éditeur de checkout n'est pas la même chose. L'ancienne version doit quitter l'application déployée.

Déplacer la fonctionnalité ailleurs. Certaines choses vivant dans une extension checkout peuvent passer dans une Function, une modification de thème ou un webhook de commande. Pas tout, mais plus qu'on ne le croit. Notre analyse de quand utiliser Shopify Functions précise cette frontière.

Escalader auprès de l'éditeur. Si une application tierce est le point bloquant, la conversation à avoir cette semaine est de savoir s'ils pourront encore déployer après le 1er octobre, pas si l'extension disparaîtra ce jour-là.

Questions fréquentes

Qu'arrive-t-il à une extension non migrée au 1er octobre ?

Elle continue de s'afficher. Shopify n'a décrit ni une panne d'affichage, ni une dégradation progressive, ni une mise à niveau automatique. À partir du 1er octobre 2026, Shopify CLI bloque les mises à jour de toute application qui contient encore une extension en version d'API 2025-07 ou antérieure. La version déjà en production reste en place. La première fois que vous devez livrer un changement sur cette application, le déploiement échoue tant que l'extension n'est pas en 2025-10 ou ultérieure, la ligne de versions qui utilise les Polaris web components.

Cela concerne-t-il les Shopify Functions ?

Non. Les Functions n'ont pas de surface d'affichage et ne sont pas touchées par une migration de bibliothèque de composants. Cela concerne les extensions d'interface checkout et les extensions de compte client.

Dois-je migrer les extensions d'applications tierces ?

L'éditeur fait le travail, mais vous devez le vérifier plutôt que le supposer. Demandez à chacun une confirmation écrite et une date, et suivez les réponses.

Est-ce la même chose que Checkout Components ?

Non. Checkout Components, généralement disponible sur Plus depuis juin, est un modèle architectural différent et optionnel. Cette migration est obligatoire et s'applique aux extensions existantes que vous adoptiez ou non Components. Nous avons traité Checkout Components séparément.

Combien de temps prend la migration d'une extension type ?

Une extension simple à quelques composants prend souvent une journée. Les extensions à mise en page personnalisée, affichage conditionnel ou gestion de formulaire lourde prennent davantage, surtout en tests plutôt qu'en écriture de code.