Checkout Components disponible sur Plus : comment planifier la refonte

Lors des Editions Summer '26 du 17 juin, Checkout Components est devenu généralement disponible pour Shopify Plus. L'annonce est arrivée dans la même vague que l'extinction des Scripts, et les deux sont plus liées que les notes de version ne le laissent penser : le modèle consistant à personnaliser le checkout en greffant de la logique sur une page rendue par Shopify est terminé, et ce qui le remplace est une surface composable que vous assemblez vous-même.

La plupart des échanges que nous avons eus depuis juin commencent par la même question : faut-il vraiment migrer. La réponse est généralement non, ou pas encore. Cet article explique comment trancher.

Ce que Checkout Components change réellement

Checkout Extensibility, adopté par la majorité des boutiques Plus entre 2023 et 2025, vous donnait des emplacements définis. Vous écriviez des extensions d'interface, vous les placiez dans les positions exposées par Shopify, et vous travailliez avec l'API de branding pour tout le reste. La mise en page, elle, ne vous appartenait pas.

Checkout Components déplace la frontière. Au lieu d'injecter dans une page rendue par Shopify, vous composez le checkout à partir de primitives : groupes de champs, récapitulatif, sections livraison et paiement, chacune adressable comme un composant que vous positionnez. Résultat : le checkout cesse d'être une page que l'on décore pour devenir une surface que l'on construit, Shopify conservant la maîtrise de ce qui ne doit pas être touché, à savoir le traitement des paiements, le périmètre PCI, l'analyse de fraude et le chemin de création de commande.

À qui cela s'adresse vraiment

La disponibilité sur votre plan n'est pas une raison d'adopter. Trois profils en tirent un bénéfice réel.

Les boutiques dont la logique de checkout n'a jamais tenu dans les emplacements. Si votre équipe traîne un backlog de demandes checkout classées comme impossibles sous l'extensibilité, chiffrez ce backlog. Parcours multi-étapes, groupes de champs conditionnels, saisie de bon de commande B2B devant apparaître avant le choix de livraison, divulgation progressive pour produits configurables complexes : ce sont les cas récurrents.

Les marques pour lesquelles le checkout est une surface de marque. Pour la plupart des boutiques, il ne l'est pas, et prétendre le contraire est la meilleure façon de dépenser six chiffres pour ne rien gagner en conversion. Pour une minorité de marques à forte considération, la rupture visuelle entre le site et le checkout se mesure en abandon. Mesurez-la avant de supposer qu'elle vous concerne.

Les boutiques déjà en pleine refonte. Si vous passez à un storefront headless, le coût marginal de composer le checkout au même moment est bien inférieur à celui d'un projet séparé plus tard. Nous avons traité le volet storefront de cette décision dans notre comparatif Hydrogen et Next.js.

Tous les autres devraient rester sur l'extensibilité. Elle n'est pas dépréciée, elle continue d'être investie, et elle coûte nettement moins cher à maintenir.

Les coûts que personne ne met dans le chiffrage

Une migration vers Checkout Components n'est pas un portage. Trois postes sont systématiquement sous-estimés.

• La surface de régression. Vous êtes désormais propriétaire de la mise en page, donc de chaque combinaison d'appareil, de langue, de devise, d'affichage fiscal et de mode de livraison. Une boutique vendant en France, au Royaume-Uni et au Canada avec trois options de livraison a une matrice de tests qui croît plus vite que le chiffrage ne le suppose.
• L'accessibilité. Le checkout par défaut de Shopify est accessible parce que Shopify l'a rendu tel. Dès que vous composez le vôtre, ce travail vous incombe, et le checkout est la surface où un défaut d'accessibilité se convertit directement en chiffre d'affaires perdu et en exposition juridique.
• La maintenance continue. Chaque amélioration plateforme du checkout par défaut arrivait auparavant gratuitement. Un checkout composé hérite moins automatiquement. Budgétez du temps d'ingénierie récurrent, pas une construction unique.

Les équipes qui regrettent la migration l'avaient presque toujours cadrée comme une refonte graphique. Celles qui s'en félicitent l'avaient cadrée comme la prise de propriété définitive d'une surface critique pour le chiffre d'affaires.

Séquencer sans casser le pic saisonnier

Nous sommes à la mi-juillet. Le Black Friday est à environ dix-neuf semaines. C'est suffisant, mais uniquement avec une date de gel ferme.

1. Semaines 1 à 2, inventaire. Listez chaque comportement de votre checkout actuel : extensions, surcharges de branding, Functions, règles de validation, pixels tiers et offres post-achat. C'est le document que l'extinction des Scripts aurait dû apprendre à tout le monde à tenir.
2. Semaines 3 à 4, arbitrage par comportement. Pour chaque élément, décidez s'il reste une Function, devient un composant, ou disparaît. Supprimer est l'activité la plus rentable de cette phase. La plupart des boutiques traînent une logique de checkout qui ne sert plus personne.
3. Semaines 5 à 10, construction sur boutique de développement. Composez le checkout avec un vrai catalogue, une vraie configuration fiscale et de vrais profils de livraison. Les données synthétiques masquent exactement les problèmes que vous cherchez.
4. Semaines 11 à 13, test de la matrice. Chaque langue, chaque devise, chaque mode de livraison, sur appareils réels. Incluez une passe lecteur d'écran et une passe clavier seul.
5. Semaines 14 à 16, déploiement progressif. Summer '26 a aussi livré les tests A/B natifs et la publication progressive via Rollouts. Servez-vous-en. Envoyez une petite part du trafic vers le nouveau checkout et maintenez-la assez longtemps pour atteindre la significativité sur le taux de complétion, pas seulement une journée.
6. Semaine 17, gel. Si le nouveau checkout n'est pas pleinement en ligne et stable à la mi-novembre, gardez l'ancien pendant le pic et reprenez en janvier. Cette décision se prend maintenant, par écrit, pas la troisième semaine de novembre.

L'instrumentation à poser avant de commencer

On ne peut pas évaluer une refonte de checkout sans référence, et cette référence doit exister avant le début des travaux. Au minimum, capturez le taux de complétion par étape, par appareil et par langue sur quatre semaines complètes du checkout actuel.

// Structure d'événement de référence à capturer par étape de checkout, avant refonte.
// À stocker sur un support que vous maîtrisez, pas uniquement dans un tableau de bord tiers.
function checkoutStepEvent(step, context) {
  return {
    event: "checkout_step_viewed",
    step,                        // "information" | "delivery" | "payment"
    checkoutToken: context.token,
    locale: context.locale,      // "fr-FR", "en-GB", "fr-CA"
    currency: context.currency,
    deviceClass: context.deviceClass,
    deliveryMethod: context.deliveryMethod || null,
    hasDiscount: Boolean(context.discountCodes?.length),
    timestamp: new Date().toISOString()
  };
}

Envoyez ces événements côté serveur plutôt que de vous reposer sur le navigateur seul, pour les raisons exposées dans notre guide du tracking côté serveur. Un checkout composé qui semble mieux convertir parce que votre mesure côté client a changé est pire que pas de mesure du tout.

La recommandation honnête

Pour la majorité des boutiques Plus, la bonne décision en juillet 2026 consiste à faire l'inventaire, chiffrer le backlog de demandes checkout que vous refusez depuis des années, puis trancher. Si ce backlog est maigre, restez sur l'extensibilité et investissez le budget dans la donnée catalogue ou la performance, dont le retour est plus clair cette année.

Si le backlog est réel, commencez maintenant plutôt qu'en septembre. C'est le calendrier comprimé qui transforme un projet raisonnable en incident de pic saisonnier.

Questions fréquentes

Checkout Extensibility est-il déprécié ?

Non. L'extensibilité reste supportée et demeure le bon choix pour la majorité des boutiques Plus. Les composants sont un modèle supplémentaire, pas un remplacement imposé.

Checkout Components exige-t-il un storefront headless ?

Non. Cela concerne le checkout indépendamment de la construction du reste du storefront. Les boutiques headless adoptent plus tôt parce que l'équipe et l'outillage sont déjà en place.

Composer le checkout modifie-t-il le périmètre PCI ?

La capture du paiement reste dans la frontière Shopify, votre position PCI est donc inchangée. Tout ce que vous composez se situe par conception hors de cette frontière.

Puis-je tester le nouveau checkout contre l'ancien ?

Oui. Summer '26 a ajouté les tests A/B natifs et la publication progressive pour les configurations de checkout, sans outil tiers.

Que deviennent mes extensions d'interface checkout existantes ?

La plupart sont portables, mais elles ont été écrites contre des positions d'emplacement qui ne décrivent plus la mise en page. Prévoyez de revoir chacune plutôt que de supposer une reprise à l'identique.