Migrer de checkout.liquid vers les Checkout Extensions sur Shopify Plus

Points clés

• checkout.liquid est complètement désactivé. Les étapes d’Information, d’Expédition et de Paiement l’ont abandonné le 13 août 2024, les pages de Remerciement et de Statut de commande ont suivi le 28 août 2025, et Shopify a mis à jour automatiquement les retardataires à partir de janvier 2026.
• Quatre outils ont remplacé le fichier unique : les checkout UI extensions pour l’interface, les Shopify Functions pour la logique, l’API de branding pour le style, et les web pixels pour le tracking.
• La migration est un exercice d’inventaire et de mapping. Listez ce que faisait votre checkout.liquid, assignez chaque élément à son nouvel outil, reconstruisez dans une configuration de checkout en mode draft (brouillon), et publiez.
• Une bonne partie ne nécessite pas de développeur. Le branding, le layout, les app blocks et les custom pixels sont gérés depuis l’admin. Les custom UI extensions, les Functions et les app pixels nécessitent un développeur.
• Quelques éléments n’ont pas de remplacement exact (1:1), y compris les modifications arbitraires du DOM et le style par page. Prévoyez des contournements (workarounds) plutôt que d’attendre une parité parfaite.

Une migration de checkout.liquid vers les extensions en 2026 n’est plus un exercice de planification à long terme. Toutes les deadlines sont passées, le fichier est désactivé, et toute boutique Shopify Plus qui n’a pas fait la transition a été mise à jour automatiquement.

Cela change l’objectif de ce guide. Si votre logique de réduction est morte avec les Shopify Scripts le 30 juin, si le tracking de votre page de remerciement a disparu avec les mises à jour automatiques de janvier, ou si vous faites tourner un checkout presque par défaut depuis la bascule et que vous voulez retrouver vos personnalisations avant le BFCM, ceci est le playbook de reconstruction.

Notre ancien guide sur la modification de checkout.liquid sur Shopify Plus documente le système legacy que cet article remplace. Pour une vue d’ensemble du nouveau framework, consultez notre guide complet sur la checkout extensibility de Shopify - cet article reste sur la voie pratique, de l’ancien vers le nouveau.

Pourquoi vous pouvez nous faire confiance

Nous sommes dans l’écosystème Shopify depuis plus de quatre ans et avons travaillé avec des centaines de marques Shopify sur leurs vitrines (storefronts), y compris des boutiques qui ont traversé cette même mise à jour. Nous développons Fudge, l’opérateur IA pour les boutiques Shopify, avec une note de 4.9 sur le Shopify App Store, donc nous travaillons quotidiennement dans la couche thème et admin concernée par cette migration.

Où en est la fermeture de checkout.liquid en 2026

Toutes les dates de ce tableau sont passées. Il est là pour que vous puissiez comprendre quelles parties de votre ancienne configuration ont cassé et quand, et ce que vous êtes en train de reconstruire.

Deux détails de ce tableau comptent pour le travail à venir.

Votre ancien code est toujours lisible. Les scripts supplémentaires sont passés en lecture seule au lieu d’être supprimés², et le fichier checkout.liquid peut encore se trouver dans l’éditeur de code de votre thème. Cela rend l’audit de l’étape 1 possible sans faire de l’archéologie.

La mise à jour automatique n’a rien migré. Les boutiques mises à jour en janvier 2026 ont purement et simplement perdu leurs personnalisations legacy². Si votre checkout semble vide aujourd’hui, c’est pour ça.

Qu’est-ce qui a remplacé checkout.liquid ?

Un fichier modifiable s’est transformé en quatre outils sandboxés, chacun gérant une partie de ce que checkout.liquid couvrait auparavant.

• Checkout UI extensions : elles génèrent une interface personnalisée sur des cibles (targets) définies dans le checkout et sur les pages de Remerciement et de Statut de commande.⁵
• Shopify Functions : elles gèrent la logique backend : réductions, personnalisation de la livraison et des paiements, et validation du panier et du checkout.⁶
• L’API de branding : elle stylise le checkout via des design tokens définis avec la mutation checkoutBrandingUpsert dans l’API GraphQL Admin.⁷⁸
• Web pixels : ils s’abonnent aux événements clients dans une sandbox et remplacent le champ des additional scripts pour le tracking.⁹

Le guide pilier sur la checkout extensibility couvre chaque outil en profondeur. Ce dont vous avez besoin ici, c’est du mapping (la correspondance).

Étape 1 : Auditer ce que faisait réellement votre checkout.liquid

Avant de reconstruire quoi que ce soit, faites une liste exhaustive de chaque tâche effectuée par l’ancien checkout. La plupart des checkouts Plus ont accumulé des années de snippets que personne n’a documentés.

Récupérez les preuves à partir de trois endroits :

1. L’ancien fichier checkout.liquid, toujours visible dans l’éditeur de code du thème pour les thèmes qui en avaient un. Lisez-le de haut en bas et notez chaque bloc non standard.
2. Le champ des scripts supplémentaires en lecture seule, qui conserve les balises exactes qui se déclenchaient sur les pages de remerciement et de statut de commande.²
3. Votre liste d’applications. Toute application qui injectait des balises de script dans le checkout a cessé de fonctionner aux dates de retrait, alors vérifiez que chaque application touchant au checkout dispose d’une version compatible avec Checkout Extensibility.

Triez chaque découverte dans l’une des huit catégories : tracking, contenu de réassurance (trust content), champs personnalisés, upsells, validation, logique de réduction et d’expédition, styling, header et footer. Chaque catégorie correspond à une ligne du tableau ci-dessus.

Ensuite, faites le tri. Une migration est la meilleure occasion pour supprimer le pixel d’une régie publicitaire morte ou le badge d’une certification expirée. Ne reconstruisez que ce qui mérite encore sa place sur la page avec le plus haut taux de conversion que vous possédez.

Étape 2 : Reconstruire les éléments côté marchand dans un checkout draft

L’admin Shopify appelle l’unité de personnalisation du checkout une checkout configuration. L’API Admin l’appelle toujours un checkout profile, c’est pourquoi la mutation de branding prend un checkoutProfileId.⁸ Dans les deux cas, il s’agit d’un bundle versionné de branding, de layout et de blocs que vous pouvez préparer comme draft (brouillon) et publier une fois prêt.¹⁰

Le flow dans l’admin :

1. Allez dans Paramètres > Checkout (Passage en caisse). Dans la section Configurations, cliquez sur Dupliquer à côté de votre configuration active pour créer un draft.¹⁰
2. Cliquez sur Modifier sur le draft pour ouvrir l’éditeur de checkout et de comptes.¹⁰
3. Définissez votre branding : logo, arrière-plan, couleurs et polices sur le checkout, la page de Remerciement et la page de Statut de commande.¹¹
4. Choisissez votre layout. Les paramètres de l’éditeur vous permettent de basculer entre un checkout en une page (one-page) ou trois pages ; une page est le paramètre par défaut.¹²
5. Ajoutez des app blocks pour les badges de confiance, les upsells et le contenu personnalisé, en les positionnant dans l’éditeur.
6. Prévisualisez le draft, puis cliquez sur Publier. La publication le remplace en tant que configuration active, et l’ancienne configuration active devient un draft auquel vous pouvez revenir (rollback).¹⁰

Rien de tout cela ne nécessite de code, et le workflow draft-first signifie que le checkout live ne voit jamais un état inachevé. Notre guide sur l’ajout de badges de confiance au checkout Shopify parcourt la version basée sur des blocs de la personnalisation simple la plus courante.

Étape 3 : Migrer le tracking vers les web pixels

Le tracking est l’élément que la plupart des boutiques Plus ont perdu sans s’en rendre compte, car la panne est silencieuse : le checkout fonctionne, mais les plateformes publicitaires arrêtent simplement de recevoir des conversions.

Vous disposez de deux remplacements pour les anciens tags des additional scripts.⁹

Les app pixels s’exécutent dans une sandbox stricte et proviennent de l’application de la plateforme - Google, Meta, TikTok et les autres maintiennent les leurs. C’est le choix par défaut : le fournisseur le garde à jour et cela ne nécessite aucun code de votre part.

Les custom pixels sont collés dans le gestionnaire de pixels de l’admin et s’exécutent dans une sandbox plus permissive, avec l’API d’événements pré-câblée.⁹ Ils constituent la solution de secours pour les plateformes sans app pixel. Deux bémols : Shopify indique clairement que les custom pixels ne sont pas supportés, que la conformité, la sécurité et l’entretien relèvent de votre responsabilité, et que toutes les fonctionnalités des pixels ne fonctionnent pas dans la sandbox.¹³

Dans tous les cas, vérifiez avec une vraie commande de test que checkout_completed atteint chaque plateforme qui vous intéresse. Pour les plateformes publicitaires en particulier, associez le pixel à un tracking server-side ; notre guide sur Meta CAPI sur Shopify couvre la déduplication et l’Event Match Quality (EMQ) pour exactement cette configuration.

Étape 4 : Reconstruire l’UI personnalisée et la logique avec un développeur

Deux seaux de votre audit représentent un véritable travail de développement.

Checkout UI extensions personnalisées

Tout ce qu’un app block ne peut pas couvrir - un champ personnalisé spécifique, une bannière conditionnelle, un sondage sur la page de Remerciement - devient une checkout UI extension. Les extensions s’affichent sur des cibles (targets) statiques ou de bloc définies, sont construites à partir des composants checkout de Shopify, et s’exécutent dans une sandbox isolée sans accès au code HTML de la page de checkout ni aux données de paiement.⁵

Les extensions sur les étapes d’Information, d’Expédition et de Paiement sont une fonctionnalité Plus ; les targets de page de Remerciement et de Statut de commande sont ouvertes à tous les forfaits.⁵ Un développeur les construit via le Shopify CLI, les teste sur une boutique de développement, et le marchand place les extensions de type block target dans le même éditeur de checkout qu’à l’étape 2.

Shopify Functions

Les règles de cumul de réductions (discount stacking), la réécriture des frais de port et le filtrage des moyens de paiement (payment gating) qui vivaient dans les Shopify Scripts vivent désormais dans les Shopify Functions, qui compilent en WebAssembly et s’exécutent sur l’infrastructure de Shopify pendant le checkout.⁶ Les API Function couvrent les réductions, la personnalisation de la livraison et du paiement, la validation du panier et du checkout, le routage des commandes et plus encore.⁶

Étant donné que les Scripts ont cessé de s’exécuter le 30 juin 2026, toute boutique qui a sauté cette migration fonctionne sans cette logique depuis le 30 juin 2026.⁴ Si vos marges ou vos grilles tarifaires d’expédition semblent erronées depuis lors, commencez par là.

Shopify publie des templates pour Rust et JavaScript et recommande Rust pour les performances sur les gros paniers.⁶ Avant de commander des Functions sur mesure, vérifiez si une application de réduction ou d’expédition n’offre pas déjà cette logique via sa configuration - pour les règles courantes, c’est généralement le cas.

Ce qui n’a pas de remplacement exact (1:1)

Un plan de migration honnête nomme les manques. Quatre éléments de l’ère checkout.liquid ne reviendront pas.

Modifications arbitraires du code HTML du checkout. Les extensions ne peuvent pas du tout toucher au HTML de la page - elles s’affichent à l’intérieur de leur propre sandbox aux targets définies par Shopify.⁵ S’il n’existe aucune target à l’endroit où s’affichait votre ancien snippet, il n’y a aucun moyen de l’afficher là. Le workaround est de choisir la target la plus proche, ou de déplacer l’élément sur la page panier, où votre thème fait toujours la loi.

Style spécifique par page. Le branding s’applique de manière globale au checkout, aux checkout UI extensions et aux pages de compte client de manière conjointe ; Shopify ne supporte explicitement pas le style de pages individuelles.⁸ Concevez le design une seule fois pour l’ensemble du flux.

Scripts nécessitant le DOM du checkout. Les enregistrements de session (session recording), certains outils d’A/B testing et d’anciens tags d’affiliation lisent la page directement, et la sandbox des pixels ne l’expose pas.¹³ Demandez à chaque fournisseur son app pixel ou une intégration server-side ; là où aucun des deux n’existe, cet outil ne peut plus être utilisé dans le checkout.

Appels réseau libres dans la logique. Les Functions ne peuvent pas appeler de services externes directement. Un mécanisme de fetch-target existe, où Shopify effectue une requête HTTP déclarée au nom de la Function, mais il doit être activé par Shopify et est limité à des accords enterprise et à des cas d’usage spécifiques.¹⁴ Le workaround standard consiste à précalculer les données dans des metafields que la Function peut lire.

Si l’un de ces manques est au cœur de votre checkout, décidez du workaround maintenant plutôt qu’au beau milieu de la reconstruction.

Ce que la mise à jour vous apporte

La contrepartie de ces limites est réelle, et c’est la raison pour laquelle vous ne devez pas regretter l’ancien fichier.

Un checkout plus rapide, qui convertit mieux. Shopify rapporte que son checkout convertit en moyenne 15 % mieux que la concurrence, et jusqu’à 36 %, en citant une étude de 2023 menée avec un grand cabinet de conseil.¹⁵ Ces chiffres sont ceux de Shopify, mais la direction correspond à ce que nous observons : moins de code custom dans le checkout signifie moins d’éléments pour le ralentir.

Shop Pay sur la nouvelle infrastructure. Shopify rapporte que le checkout Shop Pay est jusqu’à trois fois plus rapide et convertit jusqu’à 50 % mieux que le checkout standard.¹⁵

Un one-page checkout comme layout par défaut, avec la possibilité de revenir à trois pages en un clic si vos données prouvent le contraire.¹²

Mises à jour gérées par Shopify. C’est l’avantage silencieux. Les boutiques sur checkout.liquid restaient sur une version de maintenance qui ne recevait jamais automatiquement de nouvelles fonctionnalités de checkout.³ Sur l’extensibility, vos personnalisations communiquent avec des API versionnées, de sorte que Shopify déploie des améliorations de checkout en arrière-plan sans les casser.

Le timing de la refonte avant le BFCM

Planifiez à rebours depuis le Black Friday, le 27 novembre 2026.

• Huit semaines avant : terminez l’audit et la reconstruction côté marchand dans une configuration en brouillon. Commandez les extensions et Functions sur mesure à ce moment-là, car les plannings des développeurs se remplissent avant la haute saison.
• Six semaines avant : publiez, puis passez des commandes de test et vérifiez chaque pixel, Function et champ sur une vraie commande.
• Deux semaines avant : freeze. Le checkout est le dernier endroit où déployer des changements pendant les pics d’activité ; gardez un brouillon de rollback de la configuration fonctionnelle.¹⁰

Un checkout publié six semaines avant a plusieurs semaines de vraies commandes pour faire ses preuves avant le Black Friday. Un autre publié la semaine précédente, non.

Manque de temps ? Ne publiez que ce que vous pouvez tester sur de vraies commandes avant le freeze, comme le branding, les app blocks et les pixels, et repoussez les extensions et Functions sur mesure après le Cyber Monday le 30 novembre.

Où Fudge intervient

Les extensions de checkout, les Functions et les pixels ont leur propre chaîne d’outils, et Fudge ne les crée pas.

Fudge est l’opérateur IA pour les boutiques Shopify, et ce qu’il gère, c’est tout ce que l’acheteur voit avant le checkout : les landing pages, pages produits, le contenu du panier et les sections de réassurance qui déterminent si le checkout recevra un visiteur ou non. Décrivez la modification en langage naturel, par exemple “Ajoute une ligne sous le bouton d’ajout au panier avec la livraison gratuite, notre délai de retour et les moyens de paiement acceptés”, et le store editor de Fudge écrit du code natif Liquid, CSS et JavaScript dans votre thème sous forme de brouillon (draft) que vous prévisualisez et publiez - le même fonctionnement avec brouillon que l’éditeur de checkout utilise. Avec un objectif de conversion, Fudge repère aussi les pages où les acheteurs abandonnent avant d’atteindre le checkout, et compare le taux de conversion avant et après chaque correction.

Pendant qu’un développeur reconstruit vos extensions de checkout, la partie page builder de la préparation du BFCM n’a pas besoin de les attendre.

FAQ