Une commande payée n’est pas la fin du parcours. Juste après, la boutique peut envoyer une conversion à un outil de mesure, afficher une information de livraison, proposer un complément, transmettre une référence au support ou enrichir le statut de commande.
Dans certaines boutiques Shopify, ces fonctions reposent encore sur des scripts ajoutés il y a plusieurs années. Personne ne les voit au quotidien. Personne ne sait toujours qui les a installés. Pourtant, Shopify fixe au 26 août 2026 la fin des script tags sur les pages Merci et Statut de commande pour les boutiques non-Plus.
Il reste cinq jours. Le mauvais réflexe serait de copier chaque morceau de JavaScript dans le premier emplacement moderne disponible. Le bon travail tient en trois verbes : attribuer, remplacer, prouver.
1. Attribuer : à quoi sert chaque trace après paiement ?
Commencez par une commande témoin et observez ce qui se passe après le paiement. Ne cherchez pas seulement « du code ». Cherchez des responsabilités métier.
Sur une feuille, ouvrez quatre colonnes :
| Fonction observée | Propriétaire métier | Mécanisme actuel | Preuve attendue après migration |
|---|---|---|---|
| Conversion publicitaire | acquisition | application, pixel ou script historique | événement unique rapproché de la commande test |
| Mesure analytics | marketing / data | balise ou intégration | achat, devise et montant cohérents sans doublon |
| Information client | service client | bloc, application ou script | message visible au bon client sur mobile et desktop |
| Offre post-achat | e-commerce | application | offre conforme, refus possible, commande lisible |
| Suivi / logistique | opérations | application ou donnée de commande | référence exploitable dans le statut et les outils aval |
Ce tableau sépare trois situations que l’on mélange souvent.
La fonction est déjà gérée par une application maintenue. Le vieux script peut être un vestige. Il faut le confirmer avant de le retirer, sous peine de créer un doublon ou de supprimer une exception utile.
La fonction existe encore uniquement dans le script. Elle a besoin d’un mécanisme pris en charge et d’un propriétaire capable de valider le résultat.
Personne ne sait ce que la fonction apporte. Ne la migrez pas par superstition. Isolez-la sur un environnement ou une commande test, consultez son éditeur et décidez si sa valeur justifie sa conservation.
L’inventaire doit couvrir les applications, les réglages du checkout, les pixels/événements clients, les intégrations publicitaires et les outils qui consomment la commande. Une gestion technique du site utile relie ces couches au lieu de considérer l’administration Shopify comme l’unique source de vérité.
2. Remplacer : choisir une destination selon la fonction
« Passer aux extensions Checkout » décrit une direction de plateforme, pas un remplacement automatique ligne par ligne. Le mécanisme cible dépend de ce que faisait l’ancien script.
- Une information ou une interaction sur les pages de fin de parcours peut relever d’une extension Checkout fournie par une application compatible.
- La mesure doit utiliser le dispositif pris en charge par Shopify et l’outil concerné, avec consentement et déduplication vérifiés.
- Une règle qui autorise ou bloque un achat ne devrait pas être cachée dans une personnalisation visuelle. Shopify oriente notamment les validations vers des Functions exécutées côté serveur.
- Une donnée nécessaire au support ou à la logistique doit vivre dans un emplacement durable de la commande, pas seulement dans un affichage éphémère.
Cette distinction évite une migration trompeuse : retrouver le même texte à l’écran tout en perdant la donnée dans l’administration, ou recevoir le même événement deux fois parce que l’application moderne et le script historique travaillent ensemble.
Le 26 août ne concerne pas tout de la même façon
La documentation Shopify distingue les surfaces et les calendriers. L’échéance du 26 août 2026 citée ici concerne les script tags des boutiques non-Plus sur les pages Merci et Statut de commande. D’autres éléments de checkout.liquid et scripts additionnels ont déjà atteint leur échéance, notamment en 2025 sur ces pages.
Avant d’ouvrir un chantier, écrivez donc : forfait, surfaces réellement utilisées, mécanisme détecté, application propriétaire et date affichée dans l’administration. Un article ne peut pas remplacer cet état des lieux propre à la boutique.
3. Prouver : faire voyager une commande jusqu’aux outils aval
La recette commence avant le bouton Payer et se termine après la page de statut. Utilisez un produit, un client et un moyen de paiement de test identifiables. Évitez un débit réel non maîtrisé.
Passage A — commande standard
Achetez depuis une session neuve. Conservez le panier, le total, la devise, les remises, le moyen de livraison et l’identifiant de commande. Sur la page Merci, vérifiez uniquement les composants attendus : aucun ancien bloc fantôme, aucun message en double, aucune information réservée à un autre type de client.
Passage B — retour sur le statut de commande
Revenez par le lien prévu pour le client. Testez sur téléphone puis ordinateur. L’information doit rester lisible, correspondre à la bonne commande et ne pas dépendre d’un cookie publicitaire ou d’une session administrateur.
Passage C — rapprochement des systèmes
Dans l’administration et les outils autorisés, rapprochez le même identifiant :
- une seule commande, avec le bon total et les bonnes données utiles ;
- un seul événement d’achat lorsque c’est le résultat attendu ;
- attribution considérée comme un signal, pas comme une vérité absolue instantanée ;
- email et information de suivi cohérents ;
- données nécessaires visibles par le support et la logistique ;
- remboursement ou annulation de test compris par les intégrations concernées.
Attendez le délai normal de chaque outil avant de conclure à une perte. Notez l’heure, l’environnement, le consentement choisi et le résultat attendu : sans cela, une différence de délai ressemble à tort à une régression.
Passage D — le cas négatif
Refusez le consentement non essentiel lorsque ce choix existe, revenez sur la page de statut depuis un autre appareil ou simulez un paiement échoué selon les outils prévus. Vérifiez que la boutique respecte ce choix, n’expose pas d’information et ne transforme pas un échec en conversion.
Pour une boutique e-commerce conçue ou reprise à Lyon, ce dossier de preuves est plus utile qu’une capture « la page marche ». Il montre que commande, client, mesure et opérations racontent la même histoire.
Le point de décision du 25 août
La veille de l’échéance, réunissez marketing, e-commerce, support et prestataire pendant trente minutes. Chaque fonction de l’inventaire doit finir dans une seule case.
Remplacée et prouvée. Le nouveau mécanisme est identifié, le test est daté et le propriétaire métier accepte le résultat.
Retirée volontairement. La fonction n’apportait plus de valeur, faisait doublon ou ne respectait plus la politique actuelle. La décision est documentée.
Encore inconnue. N’affichez pas un faux feu vert. Nommez le risque, l’outil et la personne qui doit trancher. Si la fonction touche la commande, le support ou une obligation client, prévoyez une surveillance renforcée et un plan de correction.
Un écart analytics limité et compris ne se traite pas comme la disparition d’une information de livraison. Classez les conséquences par activité réelle, pas par nombre de lignes de code.
Ce que cet audit ne doit pas devenir
Ce contrôle n’est pas une refonte générale du checkout, ni une promesse d’attribution parfaite. Il ne faut pas profiter de l’échéance pour ajouter simultanément une nouvelle offre post-achat, changer les règles de livraison et remplacer tous les pixels : vous ne sauriez plus quelle modification explique le résultat.
Il ne faut pas non plus confondre cette date avec la dépréciation de useBuyerJourneyIntercept. Les deux signaux montrent une évolution de l’architecture Shopify, mais ils touchent des mécanismes et des calendriers différents. L’article 1Design sur les validations Shopify quand une règle commerciale change couvre précisément la recette des règles panier/checkout ; le présent audit vise les fonctions exécutées ou affichées après la commande.
Cinq jours pour rendre la dépendance explicite
Si votre boutique non-Plus utilise encore des scripts historiques sur les pages Merci ou Statut de commande, 1Design peut mener un audit borné : inventaire des fonctions, attribution à une application ou un propriétaire, choix du mécanisme cible, commande témoin et dossier de preuves.
Envoyez à 1Design l’URL de la boutique, le forfait, les applications liées au checkout et une capture de l’avertissement visible dans l’administration via la page contact. Le premier livrable n’est pas « une migration terminée » : c’est une carte claire de ce qui doit survivre au 26 août, de ce qui peut disparaître et de la preuve exigée avant de déclarer le parcours sain.
Vous voulez un site plus clair, plus crédible ou mieux pensé pour convertir ?