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 évoluons dans l’écosystème Shopify depuis plus de quatre ans et avons travaillé avec des centaines de marques Shopify sur leurs vitrines, y compris des boutiques qui ont traversé exactement cette même mise à jour. Nous concevons Fudge, un éditeur de boutique IA noté 4.9 sur le Shopify App Store, nous travaillons donc quotidiennement dans la couche thème et admin concernée par cette migration.

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

Chaque date dans ce tableau est passée. Il est là pour vous aider à déterminer quelles parties de votre ancienne configuration se sont cassées et quand, et ce que vous devez réellement reconstruire.

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

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

La mise à jour automatique n’a rien migré. Les boutiques mises à jour en janvier 2026 ont tout simplement perdu leurs personnalisations legacy². Si votre checkout a l’air 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, produisez une liste simple de toutes les tâches effectuées par l’ancien checkout. La plupart des checkouts Plus ont accumulé des années de snippets que personne n’a documentés.

Tirez les preuves de trois endroits :

1. L’ancien fichier checkout.liquid, toujours visible dans l’éditeur de code sur les thèmes qui en possédaient un. Lisez-le de haut en bas et notez chaque bloc non-standard.
2. Le champ additional scripts en lecture seule, qui conserve les tags exacts qui se déclenchaient sur les pages de Remerciement et de Statut de commande.²
3. Votre liste d’applications. Toute app qui injectait des script tags dans le checkout a cessé de fonctionner aux dates de sunset, vérifiez donc chaque app touchant au checkout pour trouver une version prête pour l’extensibility.

Triez chaque découverte dans l’un des six seaux : tracking, contenu de confiance (trust content), champs personnalisés, upsells, validation, style. Chaque seau correspond exactement à une ligne du tableau ci-dessus.

Ensuite, faites du tri. Une migration est le moment le plus opportun que vous aurez pour supprimer le pixel d’une plateforme publicitaire défunte ou le badge d’une certification expirée. Ne reconstruisez que ce qui mérite encore sa place sur la page au taux de conversion le plus élevé 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, les remplacements de tarifs d’expédition et les blocages de méthodes de paiement qui vivaient dans les Shopify Scripts vivent désormais dans les Shopify Functions, qui sont compilées en WebAssembly et s’exécutent sur l’infrastructure de Shopify pendant le checkout.⁶ Les API des Functions couvrent les réductions, la personnalisation de la livraison et des paiements, la validation du panier et du checkout, le routage des commandes, etc.⁶

Puisque les Scripts ont cessé de s’exécuter le 30 juin 2026, toute boutique qui a sauté ce portage fonctionne sans cette logique depuis deux mois.⁴ Si vos marges ou vos tableaux d’expédition vous semblent anormaux depuis le début de l’été, commencez par chercher ici.

Shopify publie des modèles 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 ne propose pas déjà cette logique en tant que 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

Travaillez à rebours depuis fin novembre.

• Septembre : terminez l’audit et la refonte côté marchand dans une configuration draft. Commandez vos extensions et Functions sur mesure maintenant - les files d’attente des développeurs se remplissent à partir d’octobre.
• Début octobre : publiez, puis passez des commandes de test et vérifiez chaque pixel, Function et champ sur une vraie commande.
• Novembre : freeze (gel des modifications). Le checkout est le dernier endroit où déployer des changements pendant la période de pointe ; gardez un draft de rollback de la configuration fonctionnelle.¹⁰

Un checkout publié en octobre dispose de plusieurs semaines de commandes réelles pour faire ses preuves avant le Black Friday. Un checkout publié à la mi-novembre, non.

Où Fudge intervient

Les checkout extensions, Functions et pixels ont leur propre environnement de développement, et Fudge ne les construit pas.

Ce que Fudge gère, c’est tout ce que l’acheteur voit avant le checkout : les landing pages, les pages produits, le contenu du panier et les sections de réassurance qui décident si un visiteur atteint le checkout ou non. Décrivez le changement dans un langage simple, et Fudge génère le code natif en Liquid, CSS et JavaScript dans votre thème sous forme de draft que vous prévisualisez et publiez - le même modèle draft-first qu’utilise l’éditeur de checkout.

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

FAQ