L'autre échéance checkout vient de passer : ce qui a cassé sur les boutiques non Plus le 26 août

Il y a deux mois, nous écrivions sur l'extinction de Shopify Scripts et le type de panne très particulier qu'elle produisait : rien ne plante, aucune alerte ne se déclenche, et les dégâts n'apparaissent que lorsque quelqu'un rapproche un chiffre plusieurs semaines plus tard. Le 26 août, la même forme de défaillance est arrivée pour un autre groupe de marchands.

C'était l'échéance pour les boutiques non Plus afin d'achever la migration hors de checkout.liquid pour les pages de remerciement et de statut de commande. Les boutiques Plus avaient franchi leur échéance équivalente en août 2025. Les étapes principales du checkout avaient migré en 2024. Il s'agissait du dernier morceau, et il touche les marchands les moins susceptibles d'avoir un développeur qui surveille le changelog.

Ce qui vivait réellement sur ces pages

La page de remerciement a longtemps été l'endroit commode pour placer tout ce qui devait se déclencher sur une commande finalisée. Cette commodité explique précisément l'accumulation.

Le contrôle en cinq minutes

Avant tout travail de migration, déterminez si vous êtes réellement concerné. Trois vérifications, dans l'ordre.

1. Comparez les conversions déclarées par les régies aux commandes réelles. Sortez les conversions d'achat de chaque régie du 12 au 25 août, puis du 27 août à aujourd'hui. Comparez les deux aux commandes de votre admin Shopify sur les mêmes fenêtres. Si les conversions ont chuté sans que les commandes bougent, votre pixel était sur la page de remerciement.
2. Passez une commande test. Le diagnostic le plus rapide disponible. Finalisez une vraie commande sur votre boutique et observez les requêtes réseau sur la page de remerciement. Tout ce qui se déclenchait et ne se déclenche plus constitue votre liste.
3. Cherchez du code orphelin dans le thème. Recherchez dans le thème toute référence au statut de commande, au checkout ou à l'objet order en dehors des templates normaux. Les vieux extraits survivent souvent à la page qui les appelait.

Une requête de rapprochement rapide sur les commandes, pour disposer du dénominateur auquel comparer les chiffres des régies :

// Commandes par jour de part et d'autre du 26 août.
// À comparer aux conversions d'achat déclarées par les régies sur les mêmes jours.
const query = `
  query DailyOrders($cursor: String, $search: String!) {
    orders(first: 250, after: $cursor, query: $search) {
      pageInfo { hasNextPage endCursor }
      edges {
        node {
          createdAt
          totalPriceSet { shopMoney { amount } }
        }
      }
    }
  }
`;

function bucketByDay(orders) {
  const days = new Map();

  for (const order of orders) {
    const day = order.createdAt.slice(0, 10);
    const current = days.get(day) || { count: 0, revenue: 0 };
    current.count += 1;
    current.revenue += Number(order.totalPriceSet.shopMoney.amount);
    days.set(day, current);
  }

  return Object.fromEntries([...days].sort());
}

Si votre nombre de commandes est stable de part et d'autre du 26 août et que celui de la régie ne l'est pas, vous avez votre réponse et il est inutile de chercher plus loin.

Où va désormais chaque élément

Le modèle de remplacement n'est pas un mécanisme unique. Différentes responsabilités ont migré vers différents endroits, et placer un élément au mauvais endroit est la meilleure façon de faire la migration deux fois.

• Le tracking et l'analytique vont dans les Web Pixels. Le framework de pixels de Shopify exécute votre code de mesure dans un environnement isolé avec un schéma d'événements défini. Cela couvre les pixels de conversion, les événements analytiques et la plupart des scripts d'attribution.
• Les éléments d'interface vont dans des extensions d'interface checkout. Tout ce que le client doit voir ou avec quoi il doit interagir sur la page de remerciement ou de statut : enquêtes, invitations fidélité, informations de livraison, messages personnalisés.
• Les offres post-achat vont dans des extensions post-achat, un type d'extension distinct avec son propre placement dans le parcours.
• La logique côté serveur va dans les webhooks. Si du code de la page de remerciement appelait vos propres systèmes pour enregistrer quelque chose, cela relève d'un webhook de création de commande, pas du navigateur. C'était de toute façon plus fiable ainsi.

Reconstruire le tracking correctement, pas à l'identique

La tentation est de reproduire exactement ce qui existait. Résistez-y, pour une raison : le suivi des achats côté navigateur était déjà lacunaire avant cette échéance, et le reconstruire dans le navigateur préserve la perte.

Outils de consentement, extensions et restrictions navigateur suppriment une part significative et non aléatoire des événements d'achat côté client. Puisque vous reconstruisez de toute façon, c'est le moment le moins coûteux que vous aurez jamais pour basculer le rapport d'achat côté serveur, où l'événement est construit à partir de la commande réellement créée par votre backend plutôt que d'une page que le client n'a peut-être jamais entièrement chargée. Nous avons détaillé la mise en œuvre dans notre guide du tracking côté serveur.

Ainsi, la migration produit de meilleures données qu'en juillet, au lieu de simplement rétablir l'existant.

Puis documentez ce que vous avez fait

Deux dépréciations silencieuses en deux mois devraient trancher un débat récurrent en revue d'ingénierie. Les boutiques qui ont traversé l'extinction des Scripts et cette échéance sans incident n'avaient pas de meilleurs développeurs. Elles étaient simplement capables de répondre à la question de savoir quel code s'exécute où.

Une autre échéance est déjà visible. Les extensions de checkout et de compte client ont une exigence de migration au 1er octobre, que nous traiterons la semaine prochaine. Si vous travaillez de toute façon sur vos extensions ce mois-ci, faire les deux d'un coup coûte nettement moins cher que de les espacer de quatre semaines.

Questions fréquentes

Les boutiques Shopify Plus sont-elles concernées ?

Non. Les boutiques Plus avaient leur échéance pour les pages de remerciement et de statut en août 2025. Celle-ci concernait les marchands non Plus, ce qui explique qu'elle ait bien moins circulé.

Mes commandes se finalisent normalement. Suis-je concerné ?

Possiblement. La finalisation des commandes n'a jamais été en jeu. Ce qui a cassé, c'est tout ce qui était rattaché à la page de finalisation : vérifiez le reporting de conversion des régies et toute ligne de revenu post-achat plutôt que le tunnel de commande.

Puis-je récupérer les données de tracking perdues ?

Non. Les événements qui ne se sont jamais déclenchés sont irrécupérables. Vous pouvez en revanche rapprocher les commandes réelles des conversions déclarées sur la période de trou, afin que votre reporting soit honnête sur le manque.

Faut-il une application pour remplacer tout cela ?

Rarement. L'essentiel du tracking passe en Web Pixels, qui se configurent plutôt qu'ils ne se développent. Les éléments d'interface sur mesure demandent une extension, donc du développement, mais de faible ampleur.

Combien de temps prend la migration ?

Pour une boutique avec des pixels éditeurs standards, un à deux jours. Pour une boutique avec scripts sur mesure, ventes additionnelles post-achat et intégrations d'affiliation, prévoyez une à deux semaines, tests inclus.