Date limite Shopify du 26 août : audit des pages de remerciement

Le 26 août 2026 est la date limite pour les boutiques Shopify hors offre Plus afin de mettre à niveau leurs pages de remerciement et de statut de commande vers les nouvelles versions. Le guide de migration Shopify pour les boutiques non-Plus précise qu’au moment de la mise à niveau, les pages existantes et leurs personnalisations sont remplacées. Les apps, scripts, pixels et personnalisations de page incompatibles doivent donc être examinés puis remplacés par des options prises en charge lorsqu’ils restent nécessaires.

Il s’agit de pages post-achat. Shopify décrit la page de remerciement comme une page affichée une seule fois après une commande réussie, tandis que la page de statut de commande est une page que le client peut consulter à nouveau une fois la commande créée. Selon la configuration de la boutique, ces pages peuvent aussi inclure du tracking et du contenu fourni par des apps, comme des enquêtes, des téléchargements, des messages de fidélité ou de parrainage, des upsells, des informations de livraison, des outils de retour et des liens d’assistance.

Pour les marchands Shopify, les responsables e-commerce, les agences et les équipes IT, cette échéance doit être traitée comme un audit de migration et de mesure. L’objectif n’est pas seulement de publier les nouvelles pages, mais de prouver que les données de chiffre d’affaires, les expériences post-achat et les relais opérationnels fonctionnent toujours après le changement.

Ce que confirme la documentation Shopify

La date limite concerne les pages post-achat de remerciement et de statut de commande. La documentation publiée par Shopify n’annonce pas un arrêt général du checkout le 26 août. Elle impose aux boutiques non-Plus de mettre à niveau ces pages avant cette date et indique que les pages existantes ainsi que leurs personnalisations sont remplacées lors de la migration. Cette formulation ne doit pas être interprétée comme une garantie qu’une configuration non testée ne rencontrera aucun problème.

Shopify précise séparément qu’une boutique éligible utilisant l’option temporaire de retour à l’ancienne version sera migrée automatiquement si elle n’effectue pas une nouvelle mise à niveau avant le 26 août. Cette mention figure dans les conditions de réversion et ne doit pas être généralisée comme un résultat universel documenté pour toutes les boutiques non-Plus.

Puisque Shopify exige le remplacement des personnalisations de page et du tracking incompatibles, les marchands doivent vérifier chaque fonction nécessaire après la migration, au lieu de supposer qu’un script existant ou le comportement d’une app a été conservé.

Qu’est-ce qui change ?

Shopify remplace les anciennes pages post-achat par des versions qui utilisent l’éditeur du checkout et des comptes clients, les blocs d’app, les extensions d’interface du checkout et le framework de pixels Shopify. Lorsqu’un marchand effectue la mise à niveau, les pages de remerciement et de statut de commande existantes, ainsi que leurs personnalisations actuelles, sont remplacées par les nouvelles pages.

Les solutions de remplacement diffèrent selon le rôle de l’ancienne personnalisation :

• Le contenu visible de la page doit être migré vers des fonctionnalités natives Shopify, des blocs d’app compatibles ou une extension d’interface checkout UI personnalisée.
• Le tracking et l’analytics doivent être migrés vers des app pixels ou, si nécessaire, vers un pixel personnalisé validé.
• Les apps qui dépendent encore d’un comportement legacy incompatible nécessitent une mise à jour de l’éditeur ou un remplacement.
• Le code qui repose sur le scraping du DOM ou qui utilise un pixel pour afficher des éléments d’interface ne peut pas être déplacé tel quel dans le sandbox pixel de Shopify ; il faut un mécanisme de remplacement pris en charge.

La documentation développeur de Shopify liste des cas d’usage pris en charge par les extensions, comme les enquêtes, les demandes d’avis, les offres d’upsell, le partage social et les liens de téléchargement. Elle distingue aussi la page de remerciement, affichée une seule fois, de la page de statut de commande, consultable à nouveau une fois les données de commande disponibles.

Pourquoi c’est un projet de tracking, pas seulement une migration de pages

Les Additional Scripts pouvaient servir au tracking et à l’analytics, mais aussi à des personnalisations de page. Le guide de migration personnalisé de Shopify identifie les scripts existants et les classe par usage, avec des catégories comme l’authentification et le suivi de commande. Les marchands doivent documenter le rôle de chaque script listé, la plateforme qui reçoit ses données et vérifier si cette fonction est toujours nécessaire.

Shopify indique que les Additional Scripts ne sont pas pris en charge sur les nouvelles pages. Pour le tracking, Shopify recommande les app pixels et autorise les pixels personnalisés lorsqu’aucune app adaptée ne répond au besoin. Les personnalisations visibles doivent être recréées avec des blocs compatibles ou d’autres fonctionnalités prises en charge.

Shopify avertit que connecter un app pixel avant de désactiver un Additional Script crée une courte période de doublons d’événements, tandis que désactiver le script en premier peut interrompre le suivi pendant la transition. La séquence documentée par Shopify consiste à connecter et tester le pixel de remplacement, confirmer que la plateforme de destination reçoit bien les événements, puis désactiver le script legacy pour éviter de nouveaux doublons.

Étape 1 : ouvrir le guide de migration personnalisé de Shopify

Commencez dans l’admin Shopify, sous Paramètres > Checkout. Dans la section Configurations, développez l’avis intitulé « Upgrade Thank You and Order Status pages by August 26, 2026 », puis choisissez Review customizations.

Shopify génère un rapport propre à la boutique qui identifie les personnalisations existantes et distingue les apps compatibles et incompatibles, le tracking et l’analytics, les personnalisations de page et les Additional Scripts. Utilisez-le comme inventaire de départ, puis comparez-le aux systèmes utilisés par le marketing, la finance, le support, les opérations et les agences externes.

Terminé quand : une personne responsable a documenté le guide de migration et chaque élément listé a un responsable identifié, un objectif, une solution de remplacement et un statut de test.

Étape 2 : constituer un inventaire complet du post-achat

Auditez quatre groupes de dépendances.

1. Tracking et analytics

• Événements d’achat GA4 et Google Ads
• Pixels publicitaires Meta, TikTok, Pinterest ou autres
• Tags de conversion d’affiliation et de réseaux partenaires
• Attribution du chiffre d’affaires email ou SMS
• A/B testing, enregistrement de session, heatmaps et suivi d’enquêtes
• Événements personnalisés de data layer et analytics internes

2. Contenu post-achat visible

• Enquêtes, demandes d’avis et invitations au parrainage
• Offres post-achat, incitations au réachat et messages de fidélité
• Liens de téléchargement pour produits numériques
• Instructions de livraison, retrait, consigne, paiement à la livraison ou paiement
• Liens d’assistance, coordonnées, politiques et messages de réassurance

3. Actions sur la commande et self-service client

• Suivi de commande et statut des expéditions multiples
• Liens de retour, échange, annulation et modification de commande
• Liens de gestion d’abonnement ou de renouvellement
• Fonctionnalités de rachat et de nouvelle commande
• Authentification du compte client et liens de statut de commande expirés

4. Hypothèses techniques cachées

• URLs de page de remerciement codées en dur
• Code qui scrape le DOM ou lit des variables de page sans restriction
• Scripts qui supposent un numéro de commande ou un identifiant client particulier
• Tags installés à la fois manuellement et via une app
• Domaines de comptes clients qui ne partagent pas le domaine racine de la boutique en ligne

Étape 3 : prioriser selon le risque business

N’attribuez pas le même niveau d’urgence à chaque personnalisation legacy. Utilisez trois niveaux de risque afin que l’équipe protège d’abord le chiffre d’affaires et les opérations liées aux clients.

• Critique : l’élément enregistre un achat, transmet des montants de chiffre d’affaires ou des devises, attribue une vente affiliée, livre un produit numérique payant ou fournit des informations essentielles sur la commande et la livraison.
• Important : l’élément influence la confiance client, le réachat, la collecte d’avis, la fidélité, les retours, l’autonomie sur les abonnements ou la charge du support.
• Faible risque : l’élément est obsolète, dupliqué, inutilisé ou correspond à un contenu informatif déjà fourni ailleurs par Shopify.

Règle de suppression utile : si personne ne peut expliquer à qui appartient un script, quelle plateforme reçoit ses données ou quelle décision en dépend, ne le recréez pas automatiquement. Vérifiez d’abord s’il est vraiment nécessaire.

Étape 4 : choisir la solution de remplacement prise en charge

Pour le tracking : privilégier les app pixels, puis les pixels personnalisés

Le gestionnaire de pixels de Shopify prend en charge les app pixels installés via des apps marketing et data, ainsi que les pixels personnalisés ajoutés par un développeur. Les pixels se chargent sur la boutique en ligne, le checkout, la page de remerciement, la page de statut de commande et les comptes clients, sous réserve des permissions et des règles de sandbox applicables.

Dans son guide de migration, Shopify recommande les app pixels pour une meilleure stabilité, sécurité et performance. Si aucune app adaptée ne répond au besoin, Shopify autorise un pixel personnalisé.

Pour le contenu visible : utiliser des blocs ou des extensions UI

Utilisez l’éditeur du checkout et des comptes clients pour ajouter des blocs d’app compatibles. Les besoins spécifiques peuvent être couverts par des extensions d’interface du checkout, mais l’implémentation doit s’appuyer sur les API prises en charge par Shopify plutôt que de recréer un JavaScript legacy sans restriction.

La nouvelle page de statut de commande inclut aussi des fonctionnalités natives comme Buy Again et, si configurés, les retours en self-service. Vérifiez d’abord ce que Shopify fournit déjà avant de payer pour reconstruire un comportement personnalisé équivalent.

Pour Google Tag Manager : en faire un choix assumé

Le guide Shopify de migration GTM recommande l’app Google & YouTube pour la plupart des boutiques. Les marchands qui utilisent déjà un pixel personnalisé GTM peuvent le mettre à jour, mais Google ne recommande ni ne prend en charge cette configuration en pixel personnalisé, et Google Tag Assistant ne peut pas la tester.

Si la boutique conserve un pixel personnalisé GTM, vérifiez qu’il s’abonne bien à l’événement checkout_completed de Shopify et testez les deux côtés de la connexion : Shopify Pixel Helper pour la livraison des événements, et le produit Google concerné pour leur réception. Mettez aussi à jour toute logique d’URL codée en dur, car la nouvelle page de remerciement remplace /thank_you par /thank-you.

Pour les tags non Google auparavant configurés dans Google Tag Manager, Shopify demande aux marchands d’installer des apps alternatives utilisant des app pixels. Chaque destination doit être testée séparément.

Étape 5 : valider le consentement, les domaines et la qualité des événements

Un événement réussi n’est pas seulement un événement qui se déclenche. Il doit se déclencher avec le bon consentement, les bons identifiants, le bon chiffre d’affaires, la bonne devise et le bon comportement de déduplication.

• Consentement : sur les marchés configurés pour exiger un consentement, que Shopify indique comme étant généralement l’EEE et le Royaume-Uni, les web pixels ne s’exécutent qu’après l’accord du client selon les permissions requises par la configuration du pixel.
• Continuité du domaine : si la boutique utilise un domaine personnalisé, configurez le domaine du compte client comme sous-domaine du domaine de la boutique en ligne. Shopify précise que sinon, les pixels et le consentement aux cookies ne fonctionneront pas sur la page de statut de commande.
• Données de chiffre d’affaires : confirmez les montants, la devise, les remises, les taxes, les frais de livraison et les identifiants de commande dans la plateforme de destination.
• Déduplication : si les événements navigateur et serveur remontent tous deux les achats, vérifiez que la plateforme identifie bien une seule commande et non deux conversions.
• Attribution : comme recommandation d’audit, établissez une base de référence avant migration pour les commandes Shopify et chaque plateforme de destination, puis analysez toute variation brutale après migration dans leur relation.

Ne surinterprétez pas une baisse liée au consentement. Shopify indique que les app pixels et les pixels personnalisés peuvent remonter moins d’événements que les anciens scripts, car les pixels pris en charge respectent les paramètres de consentement configurés. Un volume plus faible ne signifie pas automatiquement que la migration a échoué ; il faut l’évaluer à la lumière des paramètres de consentement, des commandes Shopify et des diagnostics des plateformes de destination.

Étape 6 : tester de vrais parcours clients

Un aperçu de page ne suffit pas. Passez de vraies commandes contrôlées et revisitez la page de statut de commande comme le ferait un client : depuis l’email de confirmation, le SMS, la navigation dans le compte et les liens du support.

• Checkout standard par carte sur desktop et mobile
• Shop Pay ou autres parcours de paiement accéléré utilisés par la boutique
• Paiement à la livraison, y compris la confirmation et les instructions de livraison
• Un nouvel abonnement et un panier mixte abonnement + achat ponctuel
• Retrait local, livraison locale ou commande en consigne colis
• Un upsell post-achat ou un parcours de réachat
• Une commande de produit numérique avec lien de téléchargement
• Une commande internationale avec la bonne langue et la bonne devise
• Une commande partiellement traitée ou scindée avec plusieurs mises à jour de suivi
• Un client récurrent ouvrant la page de statut de commande après la session initiale
• Un client ayant donné ou non son consentement marketing ou analytics

Pour chaque parcours, consignez si :

• La bonne page de remerciement et la bonne page de statut de commande se sont affichées
• Les blocs d’app essentiels étaient visibles et restaient utilisables sur mobile
• L’événement d’achat est bien arrivé une seule fois dans chaque plateforme attendue
• Le chiffre d’affaires, la devise, les identifiants de commande et les données produit étaient corrects
• Les liens de commande, téléchargements, retours, accès au compte et suivi fonctionnaient toujours
• Le support pouvait expliquer l’expérience sans solution manuelle de contournement

Questions à poser aux éditeurs d’apps et aux agences

• Votre app utilise-t-elle des blocs d’app, des checkout UI extensions ou des web pixels sur les nouvelles pages de remerciement et de statut de commande ?
• Quelle personnalisation legacy la nouvelle implémentation remplace-t-elle ?
• Le marchand doit-il ajouter un bloc, connecter un compte, activer un pixel ou publier une configuration ?
• Quels événements doivent apparaître dans Shopify Pixel Helper et dans la plateforme de destination ?
• Comment évitez-vous les doublons d’événements d’achat pendant et après la migration ?
• L’implémentation respecte-t-elle les paramètres Shopify de confidentialité client et de consentement ?
• Est-ce compatible avec les domaines personnalisés de compte client, les marchés multiples, les abonnements, le paiement à la livraison, le retrait et les expéditions fractionnées ?
• Quel est le plan de rollback ou de support avant le 26 août ?

Une réponse vague ne signifie pas que tout est prêt. Demandez les étapes de configuration côté marchand, les pages prises en charge, les noms d’événements, les consignes de test et un parcours de support documenté.

Que surveiller après la migration

• Les commandes Shopify comparées aux événements d’achat enregistrés par plateforme
• L’exactitude du chiffre d’affaires et de la devise
• Le taux de conversions dupliquées et les changements soudains d’attribution
• Les alertes sur les campagnes payantes ou les variations de performance inexpliquées
• L’affichage des blocs sur les pages de remerciement et de statut de commande sur desktop et mobile
• Les échecs de suivi de commande, de retour, de téléchargement et d’accès au compte
• Les tickets support mentionnant l’absence de confirmation, de suivi ou d’actions post-achat
• Les performances de page et les erreurs signalées par les apps ou les extensions personnalisées

Progus recommande de désigner un responsable du suivi quotidien pendant au moins la première semaine, afin d’analyser rapidement les événements manquants ou dupliqués avant qu’ils n’affectent une période de reporting plus longue.

Checklist pratique de validation

1. Guide de migration relu. Terminé lorsqu’aucun élément critique n’est sans responsable ou sans explication.
2. Scripts legacy traités. Terminé lorsque chaque script est remplacé, volontairement retiré ou documenté comme inutile.
3. Contenu des pages publié. Terminé lorsque chaque bloc d’app nécessaire apparaît sur la bonne page et le bon appareil.
4. Pixels vérifiés. Terminé lorsque Shopify et chaque plateforme de destination reçoivent l’événement attendu une seule fois avec les bonnes valeurs.
5. Doublons supprimés. Terminé lorsque le tracking de remplacement validé reste actif après la désactivation des scripts legacy.
6. Consentement et domaines vérifiés. Terminé lorsque les pixels se comportent correctement pour les parcours avec et sans consentement sur le domaine du compte client.
7. Parcours clés validés. Terminé lorsque les scénarios de paiement, marché, abonnement, paiement à la livraison et livraison utilisés par la boutique fonctionnent de bout en bout.
8. Support prêt. Terminé lorsque la documentation, les responsabilités d’escalade et les consignes destinées aux clients sont à jour.
9. Suivi actif. Terminé lorsqu’un responsable, une base de référence, une fréquence de revue et un seuil d’alerte sont documentés.

En conclusion

L’échéance du 26 août ne concerne que deux pages, mais les fonctions placées sur ces pages peuvent relier le marketing, l’analytics, le support, la logistique et l’expérience client. C’est pourquoi la migration doit inclure un inventaire et des tests fonctionnels, pas seulement une revue dans l’éditeur de page.

Profitez de cette migration pour supprimer le code inconnu, basculer le tracking vers des pixels pris en charge, ne reconstruire que les éléments de page encore utiles aux clients et valider le résultat avec de vraies commandes. Une migration réussie ne se résume pas à une nouvelle page de remerciement : elle garantit une mesure fiable, une communication claire autour de la commande et moins de surprises opérationnelles avant la haute saison.