Le Guide Complet de l'Extensibilité du Checkout Shopify

À retenir

• Shopify checkout extensibility est le framework qui a remplacé checkout.liquid. Il divise la personnalisation du checkout en outils structurés : Checkout UI extensions, Shopify Functions, l’API de branding et les web pixels.
• Les boutiques Plus ont perdu checkout.liquid, les scripts supplémentaires et les balises de script sur les pages de remerciement et de statut de commande le 28 août 2025, avec des mises à niveau automatiques commençant en janvier 2026.¹²
• Les boutiques non-Plus ont jusqu’au 26 août 2026 pour mettre à jour les pages de remerciement et de statut de commande.³ Les Shopify Scripts cesseront de fonctionner après le 30 juin 2026.¹
• Le code personnalisé va désormais dans des extensions et des pixels isolés (sandboxed), et non plus en JavaScript brut dans un champ du checkout. C’est plus limité, mais c’est le prix à payer pour un checkout plus rapide et plus sûr.
• La migration nécessite un vrai travail sur le thème et les applications. Un outil orienté brouillon (draft-first) comme Fudge gère les modifications de la vitrine (storefront) autour sans que vous ayez à tout coder à la main.

Shopify checkout extensibility est la méthode actuelle et prise en charge pour personnaliser le checkout Shopify. Ce n’est pas une fonctionnalité unique. C’est un ensemble de composants - Checkout UI extensions, Shopify Functions, une API de branding et des web pixels - qui gèrent chacun une partie du checkout que checkout.liquid gérait auparavant dans un seul fichier.

Ce guide est votre feuille de route. Il explique ce qu’est la checkout extensibility, pourquoi Shopify a déprécié checkout.liquid, les dates limites importantes, chaque composant et sa place, les cibles d’extension (extension targets), les pages de remerciement et de statut de commande, comment faire la mise à niveau, et les limites à prévoir. Chaque section renvoie à un guide ciblé si vous souhaitez approfondir.

Toutes les dates et versions ci-dessous proviennent d’une source officielle de Shopify. Les dates limites du checkout ont déjà été repoussées, alors vérifiez sur les pages Shopify en lien avant de planifier une migration.

Si vous avez un forfait non-Plus, la date limite du 26 août 2026 est maintenant dépassée. Nos mises à jour Shopify d’août 2026 couvrent ce qui a changé, et notre guide de migration détaille l’ensemble de la transition si vous avez encore des personnalisations obsolètes à remplacer.

---

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 boutiques.

Jacques, notre CTO, a plus de 15 ans d’expérience en développement et a créé et migré des vitrines pour de nombreuses marques Shopify, y compris des travaux sur les pages de paiement.

Nous avons créé Fudge - un constructeur de pages et éditeur de boutique Shopify natif à l’IA avec une note de 4.9 sur le Shopify App Store et un badge Built for Shopify. Nous sommes évidemment partiaux envers notre propre produit, et nous disons clairement quand il est adapté et quand il ne l’est pas.

---

Qu’est-ce que l’extensibilité du checkout Shopify ?

L’extensibilité du checkout est un framework structuré pour personnaliser le checkout via des API approuvées par Shopify plutôt que du code arbitraire.

L’ancien modèle vous permettait d’injecter n’importe quel script JavaScript, Liquid ou tiers dans le checkout via checkout.liquid et le champ des scripts additionnels. C’était flexible mais fragile. Un script de tracking lent ou un bout de code cassé pouvait détériorer ou faire planter la page la plus importante de la boutique.

Le nouveau modèle divise cette surface en outils bien définis :

• Les extensions UI du checkout pour les changements d’interface.
• Les Shopify Functions pour la logique backend comme les réductions, la livraison, le paiement et la validation.
• L’API de branding pour le style.
• Les pixels web pour le tracking et l’analytics.

Chaque outil s’exécute dans l’environnement de rendu et la sandbox de Shopify. Vous avez moins de liberté brute, mais vous obtenez un checkout qui reste rapide, facile à mettre à jour et cohérent sur le web et l’application Shop.

Extensibilité du checkout vs checkout.liquid

Capacité	checkout.liquid (legacy)	Checkout extensibility
Changements d’UI	Édition de Liquid/HTML brut	Checkout UI extensions sur des targets définis
Logique métier	Shopify Scripts, code custom	Shopify Functions
Styling	CSS dans le fichier checkout	API de branding et éditeur de checkout
Tracking	Champ de scripts additionnels	Web pixels
S’exécute sur	Injection directe dans la page	Sandbox gérée par Shopify
Upgrade path	Manuel, casse lors des MAJ plateforme	APIs versionnées
Disponibilité	Plus uniquement, déprécié	Checkout complet sur Plus ; partiel sur tous les forfaits

L’idée de ce tableau : rien n’a été retiré sans être remplacé. Le travail consiste à mapper chaque ancienne customisation vers son nouvel outil.

---

Pourquoi Shopify a-t-il déprécié checkout.liquid ?

Trois raisons expliquent ce choix : les performances, la sécurité et la capacité de mise à jour.

checkout.liquid laissait les marchands modifier le checkout directement, ce qui signifiait que Shopify ne pouvait pas modifier le checkout en arrière-plan sans risquer de casser chaque personnalisation. Les scripts injectés s’exécutaient également avec un accès complet à la page, y compris sur la page gérant le paiement et les données personnelles.

L’extensibilité du checkout règle cela en plaçant les personnalisations derrière des API versionnées et des sandbox. Shopify peut donc déployer des améliorations du checkout - fonctionnalités de conversion, One Page Checkout, correctifs d’accessibilité - sans casser votre code, car celui-ci communique avec une interface stable plutôt qu’avec la page brute.

Les dates limites importantes en 2026

C’est la partie à ne pas louper, car rater une date signifie que Shopify supprimera vos customisations à votre place.

Type de boutique / feature	Deadline	Ce qui se passe
Plus - Pages Thank you et Order status	28 août 202512	checkout.liquid, les scripts additionnels et les balises de script sont retirés de ces pages ; deviennent non-éditables2
Plus - Upgrades automatiques	Janvier 20262	Shopify met à jour automatiquement les boutiques Plus restantes ; les customisations legacy sont supprimées et ne peuvent pas être migrées2
Shopify Scripts	30 juin 20261	Les Scripts continuent de fonctionner avec les checkout extensions jusqu’à cette date, puis s’arrêtent1
Non-Plus (Basic, Shopify, Advanced)	26 août 20263	Deadline pour upgrader et remplacer les pages Thank you et Order status3

Quelques notes pour bien lire ce tableau.

Pour les boutiques Plus, les étapes checkout.liquid pour l’Information, l’Expédition (Shipping) et le Paiement n’étaient déjà plus supportées avant le retrait (sunset) des pages Thank you et Order status.¹ La date du 28 août 2025 et l’upgrade automatique de janvier 2026 s’appliquent spécifiquement aux pages Thank you et Order status.¹²

Pour les boutiques non-Plus, ce sont les pages Thank you et Order status qui sont impactées, et la date est le 26 août 2026.³ Tout ce qui se trouve dans le champ des scripts additionnels sur ces pages (tags de conversion, pixels, snippets custom) doit trouver une nouvelle maison avant cette date.

Les Shopify Scripts ont une deadline distincte. La logique de réduction, d’expédition et de paiement construite avec des Scripts continuera de tourner uniquement jusqu’au 30 juin 2026, après quoi cette logique devra passer sur les Shopify Functions.¹

---

Les briques de construction de l’extensibilité du checkout

Quatre outils remplacent ce que faisait checkout.liquid. Voici ce que gère chacun d’eux.

Extensions UI du checkout

Les extensions UI du checkout ajoutent une interface et une logique personnalisées dans le checkout, et les pages de Remerciement et de Statut de commande à des emplacements définis.⁴

Elles sont construites avec les composants web de Shopify - boutons, textes, champs de formulaire, cases à cocher - combinés à des primitives de mise en page comme les stacks, grids et sections.⁴ Vous les affichez sur des cibles spécifiques plutôt que de modifier la page directement, et elles lisent les données du checkout via des API de cible : identité de l’acheteur, coût, articles, attributs et champs méta.⁴

Utilisations courantes : champs personnalisés (notes de livraison, messages cadeaux), éléments de réassurance, upsells et bannières de contenu. Les étapes complètes du checkout (Information, Livraison, Paiement) acceptent les extensions UI sur le forfait Plus ; les pages de Remerciement et de Statut de commande les acceptent sur tous les forfaits.⁴

La version actuelle de l’API Checkout UI extensions est la 2026-04.⁴

Sur le même sujet, pour modifier les libellés et les champs du checkout : comment modifier les libellés des champs du checkout Shopify.

Shopify Functions

Les Shopify Functions personnalisent la logique métier en backend - les décisions que prend le checkout, pas son apparence.⁵

Ces requêtes couvrent ce que géraient les Scripts et plus encore :⁵

• Réductions - types et combinaisons de remises personnalisées.
• Personnalisations de livraison - renommer, réorganiser ou masquer des options de livraison.
• Personnalisations de paiement - masquer ou réorganiser des moyens de paiement.
• Validation du panier et du checkout - bloquer le checkout lorsque certaines conditions ne sont pas remplies.
• Routage des commandes, points de retrait et bundles.

Les Functions sont compilées en WebAssembly et s’exécutent sur l’infrastructure de Shopify.⁵ Il existe des modèles pour Rust et JavaScript, et Shopify recommande Rust car c’est le choix le plus performant, évitant ainsi que les fonctions ne plantent sur les gros paniers.⁵ Elles s’exécutent sans accès au réseau ou aux fichiers, ce qui permet de les garder rapides et prévisibles dans le checkout.

C’est le remplaçant direct des Shopify Scripts. Si vous avez des Scripts, c’est la première chose à migrer avant la date limite du 30 juin 2026.¹

Sur le même sujet : comment ajouter du JavaScript personnalisé dans Shopify explique où le JS s’intègre encore en vitrine et à quel endroit les Functions ont désormais pris le relais sur la logique backend.

L’API de branding

L’API de branding personnalise le style du checkout grâce à des tokens de design structurés (jetons de conception) et non avec du CSS libre.

Elle fonctionne via la mutation checkoutBrandingUpsert dans l’API GraphQL Admin, avec un designSystem qui définit les couleurs de base, la typographie, le rayon des angles et les espacements, et un objet customizations qui stylise des composants en particulier.⁶ Les styles s’appliquent de manière globale au checkout, aux extensions UI et aux pages du compte client, et non page par page.⁷

Une contrainte importante : le styling avancé du checkout via l’API de branding est uniquement disponible pour les marchands Shopify Plus.⁷ Les boutiques non-Plus personnalisent les couleurs, polices et logos via les paramètres de l’éditeur de base.

Sur le même sujet, pour ajouter des éléments de réassurance : comment ajouter des badges de confiance sur le checkout Shopify.

Pixels web

Les pixels web remplacent le champ des scripts additionnels pour le tracking.

L’API de Pixels Web s’abonne aux événements clients - pages vues, vues de produits, ajouts au panier, finalisations d’achat - au sein d’une sandbox, ce qui permet au tracking d’observer ces événements sans toucher directement au checkout.⁸ Les “app pixels” s’exécutent dans une sandbox stricte et peuvent récupérer les configurations de l’API Admin ; les pixels personnalisés tournent dans une sandbox plus souple sans nécessiter de boilerplate complexe.⁸

C’est ici que les balises de conversion Google Ads, les pixels Meta, Google Tag Manager et l’analytics doivent migrer. Si vous les collez dans l’ancien champ des scripts additionnels, ils s’arrêteront de fonctionner à la date limite de votre boutique.¹³

---

Comprendre les “targets” (cibles) d’extension

Les targets définissent où une UI extension apparaît et comment elle se comporte.⁴ Il en existe trois sortes :

Type de target	Ce qu’il fait	Exemple
Static	Fait un rendu automatique à un emplacement fixe	Après les champs de contact, après les articles du panier
Block	Le marchand le positionne dans l’éditeur de checkout	Un bloc de contenu custom que le marchand glisse-dépose à sa place
Runnable	Exécute de la logique sans faire de rendu d’UI	Réagit à un changement dans un champ d’adresse

Les targets static et block couvrent la plupart des customisations visibles. La différence se situe au niveau du contrôle : les targets static s’affichent là où le target est défini, tandis que les targets block laissent le marchand choisir l’emplacement dans l’éditeur de checkout.⁴

Une seule extension peut déclarer plus d’un target, ce qui permet à une app d’ajouter à la fois un champ et la logique qui y réagit.

---

Extensibilité des pages de Remerciement et de Statut de commande

Les pages de Remerciement et de Statut de commande sont celles où la plupart des boutiques non-Plus ressentent ce changement, car c’est là que se trouvaient leur tracking et leur contenu post-achat.

Ces deux pages sont désormais personnalisées via l’éditeur de checkout et de comptes clients avec des UI extensions et des pixels web, et non plus avec checkout.liquid ou des scripts additionnels.²³ Les UI extensions peuvent afficher un message personnalisé, un sondage ou du contenu post-achat, avec un accès en lecture aux méta-champs de la commande.⁴ Le tracking qui se trouvait dans les scripts additionnels passe aux app pixels pour que les événements continuent de se déclencher.² Les offres post-achat sont l’utilisation la plus rentable de ces espaces ; notre comparatif des meilleures apps d’upsell post-achat Shopify présente les apps déjà construites sur ces bases.

Pour une boutique sous forfait Basic, Shopify ou Advanced, voici la checklist pratique avant le 26 août 2026 :³

1. Trouvez chaque balise dans le champ des scripts additionnels (conversion, retargeting, analytics).
2. Recréez chacune d’elles en tant qu’app pixel ou custom pixel.
3. Reconstruisez tout contenu post-achat sous forme de UI extension sur la page de Remerciement.
4. Vérifiez que les événements se déclenchent bien dans une commande test avant la date limite.

Si vous ne faites rien, Shopify mettra la boutique à jour pour vous et les anciennes personnalisations ne seront pas conservées.²³

---

Comment migrer depuis checkout.liquid

La mise à niveau est un exercice de correspondance. Prenez chaque chose que l’ancien checkout faisait et déplacez-la vers l’outil qui la gère désormais. Notre guide de migration de checkout.liquid vers checkout extensions détaille tout le processus étape par étape.

Ce que vous aviez	Où cela va maintenant
Champs / contenus personnalisés dans checkout.liquid	Checkout UI extension sur une cible (target)4
Shopify Scripts (réductions, expédition)	Shopify Functions15
Style CSS dans le fichier checkout	API de branding (Plus) ou éditeur de checkout7
Balises (tags) dans les scripts supplémentaires	Web pixels28
Modifs page de remerciement / statut de commande	UI extensions dans l’éditeur de checkout23

Un ordre de marche réalisable :

1. Faites l’inventaire de l’ancien checkout. Listez chaque personnalisation, script et application touchant le checkout, la page de remerciement et le statut de commande.
2. Triez par outil. Assignez chaque élément à une UI extension, une Function, au branding ou à un pixel.
3. Vérifiez d’abord vos applications. De nombreuses applications proposent déjà des versions compatibles avec la checkout extensibility. Mettre à jour l’application est souvent plus rapide que de recréer du code personnalisé. Les applications d’abonnement sont un cas fréquent, car elles touchent le checkout, les réductions et le compte client en même temps ; les meilleures applications d’abonnement Shopify sont toutes basées sur les nouvelles API.
4. Recréez les éléments personnalisés en tant qu’extensions. Générez la structure avec la CLI Shopify et testez sur une boutique de développement.
5. Passez des Scripts aux Functions très tôt. Cette date limite (30 juin 2026) arrive avant celle des pages non-Plus.¹
6. Vérifiez avec une vraie commande de test avant de vous reposer dessus.

Pour la méthode spécifique à Shopify Plus, y compris les cas où la modification limitée du checkout s’applique toujours, consultez comment modifier checkout.liquid sur Shopify Plus.

---

Tester les extensions du checkout

Le checkout est la dernière page que vous souhaitez voir planter en ligne. Testez-le bien avant de le publier.

• Boutiques de développement. Construisez et prévisualisez vos extensions sur une boutique de développement, pas sur l’environnement de production.
• Prévisualisation avec Shopify CLI. L’exécution de shopify app dev sert votre extension pour ainsi simuler sa présence lors d’un vrai checkout avant déploiement.
• Commandes tests. Passez une commande complète de bout en bout en passant par les pages du Statut de commande, et confirmez que les pixels ont bien réagi.
• Thèmes brouillons pour les modifications environnantes. Le contenu du checkout voisine souvent celui du panier et des pages de produit ; conservez ces changements sous forme de brouillons jusqu’à ce que vous les publiiez.

Pour les logiques d’upsell et cross-sell qui agissent sur le panier et le checkout ensemble, voir comment ajouter des upsells dans le panier Shopify. Il est par ailleurs utile d’analyser vos performances après ces changements ; notre Guide CRO pour Shopify détaille quoi tester pour booster vos conversions.

---

Limites et contraintes à prévoir

L’extensibilité du checkout est délibérément beaucoup plus stricte que checkout.liquid. Anticipez ces contraintes avant de concevoir l’expérience finale.

• Pas de code arbitraire dans le checkout. Vous agissez via des cibles et des API définies. S’il n’y a pas de cible pour un emplacement donné, vous ne pourrez pas y faire de rendu pour le moment.
• La personnalisation totale du checkout est exclusive à Plus. Les extensions UI sur les étapes d’Information, de Livraison et de Paiement, ainsi que l’API de branding, sont réservées à Shopify Plus.⁴⁷ Les boutiques non-Plus sont limitées aux pages de Remerciement, de Statut de commande et aux paramètres de style classiques.
• Les Functions s’exécutent en sandbox. Aucun accès réseau ou système de fichiers, et la performance est surveillée sur les grands paniers (d’où l’importance de Rust).⁵
• Le branding est global au checkout. Les styles se propagent proportionnellement sur toute l’expérience de paiement, et non page par page.⁷
• Les API sont versionnées. Les extensions ciblent une version précise (actuellement 2026-04 pour les UI extensions) et ces montées en versions requièrent d’être faites manuellement.⁴

Ces limites sont le compromis d’un checkout qui reste performant, plus sécurisé, et beaucoup moins exposé lors des évolutions futures du produit.

---

Où intervient Fudge lors d’un travail sur le checkout

L’extensibilité du checkout s’adresse surtout aux développeurs : initialiser des extensions, générer des Functions, lier les pixels, ou tester l’environnement.

La vitrine environnante - landing pages, bloc panier, fiches produits, témoignages clients et événements saisonniers - est là où se cristallisent l’immense majorité des conversions en boutique, ce qui ne nécessite l’aide d’aucun développeur dans 99% des cas.

C’est la spécialité de Fudge. Intégré dans l’admin de Shopify en fonctionnant uniquement par incitations via des prompts (plutôt qu’avec du code en dur), cet outil préserve vos ébauches de tests avant toute publication publique. Le fait qu’il convertisse tous ses rendus en code natif Liquid, JS et CSS assure que vous n’êtes jamais condamné(e) à en rester client. Ainsi, pour ce qui relève de ces pages qui habillent vos expériences et qu’un éditeur va avoir plus de facilité à manipuler, l’éditeur de boutique centralisera parfaitement ces requêtes afin de libérer de l’espace à vo(s)/tre développeur(s) pour s’affairer exclusivement aux extensions requises par le checkout.

Ce sont deux couches d’intervention distinctes. Les API d’extension interviennent sur la procédure du paiement, pendant qu’un système d’édition focalisé sur vos drafts (brouillons) viendra agir sur votre vitrine afin d’en affiner ses contours.

---

Conclusion

La checkout extensibility a remplacé un fichier flexible mais fragile par quatre outils bien définis : les UI extensions pour l’interface, les Functions pour la logique, l’API de branding pour le style et les web pixels pour le suivi (tracking). Vous échangez une liberté totale contre un checkout qui reste rapide et facile à mettre à jour.

Toutes ces dates sont désormais derrière nous. Les boutiques Plus ont été mises à niveau au cours de l’année 2025 jusqu’en janvier 2026.¹² Les Shopify Scripts se sont arrêtés après le 30 juin 2026.¹ Les boutiques non-Plus avaient jusqu’au 26 août 2026 pour migrer les pages de remerciement et de statut de commande.³ Vérifiez chacune de ces dates sur les pages Shopify en lien ci-dessous avant de vous organiser, car les délais du checkout ont déjà été modifiés par le passé.

Associez chaque ancienne personnalisation à son nouvel outil, portez d’abord les Scripts vers les Functions, déplacez les balises vers les pixels, et testez avec une vraie commande. C’est ça, la migration.

---

FAQ

Footnotes

1. “checkout.liquid,” documentation développeur Shopify, indiquant que checkout.liquid, les scripts supplémentaires et les balises de script pour les pages de remerciement et de statut de commande disparaissent le 28 août 2025, que les étapes Informations/Expédition/Paiement ne sont plus prises en charge, et que les Shopify Scripts fonctionnent aux côtés des extensions de checkout jusqu’au 30 juin 2026 : https://shopify.dev/docs/storefronts/themes/architecture/layouts/checkout-liquid ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴

2. “Plus - Mettre à niveau et remplacer vos pages de remerciement et de statut de commande,” Centre d’aide Shopify, notant la date limite Plus du 28 août 2025, que les scripts supplémentaires et checkout.liquid deviennent non modifiables, que les mises à niveau automatiques commencent en janvier 2026, et que le suivi passe aux app pixels : https://help.shopify.com/en/manual/checkout-settings/customize-checkout-configurations/upgrade-thank-you-order-status/plus-upgrade-guide ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²

3. “Mettre à niveau et remplacer vos pages de remerciement et de statut de commande,” Centre d’aide Shopify, indiquant que les boutiques non-Plus avaient jusqu’au 26 août 2026 pour mettre à niveau et remplacer les pages de remerciement et de statut de commande : https://help.shopify.com/en/manual/checkout-settings/customize-checkout-configurations/upgrade-thank-you-order-status ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰

4. “Checkout UI extensions,” documentation développeur Shopify, décrivant les cibles (statiques, blocs, exécutables), les API cibles, les composants web, la disponibilité des pages, et la version actuelle 2026-04 de l’API : https://shopify.dev/docs/api/checkout-ui-extensions/latest ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹

5. “Shopify Functions,” documentation développeur Shopify, listant les types de fonctions (réductions, livraison, paiement, validation, routage des commandes, retrait, bundles), la compilation WebAssembly, et les templates Rust/JavaScript avec Rust recommandé pour les performances : https://shopify.dev/docs/apps/build/functions ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

6. “checkoutBrandingUpsert,” API Admin GraphQL, décrivant le designSystem (couleurs, typographie, rayon de bordure, espacement) et l’entrée de personnalisations pour le branding du checkout : https://shopify.dev/docs/api/admin-graphql/latest/mutations/checkoutBrandingUpsert ↩

7. “About checkout styling,” documentation développeur Shopify, indiquant que les personnalisations de style du checkout via l’API de branding sont disponibles uniquement pour les marchands Shopify Plus et s’appliquent à l’ensemble du checkout : https://shopify.dev/docs/apps/build/checkout/styling ↩ ↩² ↩³ ↩⁴ ↩⁵

8. “Web Pixels API,” documentation développeur Shopify, décrivant l’abonnement aux événements clients dans les sandbox Lax ou Strict et la différence entre les app pixels et les custom pixels : https://shopify.dev/docs/api/web-pixels-api ↩ ↩² ↩³