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

Shopify a fixé au 1er octobre 2026 la date à laquelle les extensions de checkout et de compte client doivent avoir achevé leur migration vers les Polaris web components. 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.

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 assez de préavis pour désactiver une application avant qu'elle ne casse quelque chose.
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 elles qui vous surprendront 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. 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, vous avez trois options, et mieux vaut trancher maintenant que le 30 septembre.

Désactiver l'extension avant l'échéance et accepter temporairement la fonctionnalité manquante. Peu glorieux et presque toujours juste, car une fonctionnalité désactivée est un état connu, et une extension non migrée ne l'est pas.

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 porte sur son calendrier, pas sur le vôtre.

Questions fréquentes

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

Partez du principe qu'elle cesse de s'afficher correctement. Planifiez en supposant que les extensions non migrées échouent plutôt qu'elles ne se dégradent proprement : cette hypothèse ne vous coûte presque rien si elle est fausse.

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.