Shopify Scripts s'est éteint le 1er juillet : l'audit d'après extinction

Shopify Scripts a cessé de s'exécuter le 30 juin 2026. L'édition et la publication étaient déjà désactivées depuis le 15 avril, si bien que la plupart des équipes ont pris la date finale pour une formalité. Pour les boutiques ayant terminé leur migration, c'en était une. Pour les autres, le 1er juillet a été le premier jour d'une panne très particulière : rien n'a planté, aucune alerte ne s'est déclenchée, et les commandes ont continué d'arriver. La seule chose qui a changé, c'est que certaines étaient mal tarifées.

Nous avons passé la première semaine de juillet à réaliser des audits post extinction pour des marchands Plus. Le schéma était assez constant pour être documenté.

Ce qui a réellement cessé de fonctionner

Les Scripts couvraient trois surfaces, et chacune échoue différemment maintenant que le moteur Ruby a disparu.

Aucun de ces cas ne produit un échec de commande. C'est précisément le problème. Une application cassée renvoie une erreur 500 et quelqu'un s'en aperçoit dans l'heure. Une remise absente ressemble simplement à un client qui n'a pas utilisé son code promo.

Pourquoi tant d'équipes en ont oublié un

Les migrations que nous avons revues étaient rarement incomplètes par défaut d'ingénierie. Elles l'étaient par défaut d'inventaire. Trois causes reviennent.

Des scripts sans propriétaire. L'éditeur de Scripts permettait à toute personne disposant d'un accès Plus de publier du Ruby. Plusieurs boutiques auditées contenaient des scripts écrits par une agence qui n'intervenait plus depuis 2022. Rien dans le dépôt n'y faisait référence.

Une logique conditionnelle rarement déclenchée. Un script qui applique une remise uniquement aux clients grossistes au-delà d'un certain seuil peut se déclencher deux fois par mois. Il n'apparaîtra pas dans un contrôle rapide des commandes de la semaine, ni dans une recette sur boutique de développement si personne ne construit délibérément ce panier.

Des applications qui installaient des scripts pour vous. Certaines applications d'abonnement, de fidélité ou de bundles écrivaient des scripts de ligne lors de leur configuration. Si l'éditeur a migré vers Functions dans son propre cycle de publication, tout va bien. Si l'application a été désinstallée en laissant le script orphelin, ou si l'éditeur a discrètement abandonné le support, non.

L'audit, dans l'ordre

1. Récupérez l'inventaire historique des Scripts. L'éditeur a disparu, mais pas forcément la trace. Vérifiez votre gestion de versions, la documentation de passation de votre agence et tout export réalisé avant le 15 avril. Si rien n'existe, reconstituez à partir du comportement plutôt que du code.
2. Rapprochez les montants de remise de part et d'autre de la bascule. Comparez la valeur totale des remises appliquées par jour sur les deux semaines précédant le 30 juin et les deux semaines suivantes. Une rupture nette au 1er juillet, ce sont vos scripts de ligne. C'est le signal le plus rapide à obtenir et il ne demande aucune archéologie de code.
3. Comparez vos tarifs de livraison. Ouvrez le tunnel avec trois paniers représentatifs : une commande domestique légère, une commande domestique lourde, une commande internationale. Tout tarif visible aujourd'hui et absent en juin était supprimé par un script de livraison.
4. Comparez vos moyens de paiement. Même exercice à l'étape paiement. Surveillez en particulier les méthodes à frais élevés que vous masquiez sur les petits paniers, et les passerelles B2B censées être réservées aux clients tagués.
5. Interrogez l'équipe merchandising. Elle sait quelles promotions existaient. Demandez ce qui devrait tourner ce mois-ci, puis vérifiez chaque cas de bout en bout dans un vrai panier.

Pour l'étape deux, une courte requête sur l'API GraphQL Admin fournit les données de rapprochement sans attendre la construction d'un rapport.

// Compare l'application des remises de part et d'autre de l'extinction des Scripts.
// À exécuter une fois pour le 16-29 juin, une fois pour le 1er-14 juillet, puis à comparer.
const query = `
  query OrdersInWindow($cursor: String, $search: String!) {
    orders(first: 250, after: $cursor, query: $search) {
      pageInfo { hasNextPage endCursor }
      edges {
        node {
          name
          createdAt
          totalDiscountsSet { shopMoney { amount } }
          discountApplications(first: 10) {
            edges { node { __typename allocationMethod targetType } }
          }
        }
      }
    }
  }
`;

async function windowTotals(searchWindow) {
  let cursor = null;
  let orderCount = 0;
  let discountTotal = 0;

  do {
    const res = await adminGraphql(query, { cursor, search: searchWindow });
    const page = res.data.orders;

    for (const edge of page.edges) {
      orderCount += 1;
      discountTotal += Number(edge.node.totalDiscountsSet.shopMoney.amount);
    }

    cursor = page.pageInfo.hasNextPage ? page.pageInfo.endCursor : null;
  } while (cursor);

  return {
    orderCount,
    discountTotal,
    discountPerOrder: orderCount ? discountTotal / orderCount : 0
  };
}

Comparez discountPerOrder entre les deux fenêtres. La saisonnalité fait bouger ce chiffre de quelques pourcents. Un script disparu le fait bouger beaucoup plus, et à une date unique et précise.

Reconstruire ce que l'audit révèle

La correspondance entre Scripts et Functions est presque univoque, et c'est la bonne nouvelle. Le travail se situe dans la sémantique, pas dans le périmètre.

• Les scripts de ligne deviennent des Discount Functions, enregistrées en remises automatiques ou en remises à code via les API de remise.
• Les scripts de livraison deviennent des Delivery Customization Functions, qui réordonnent, renomment ou masquent les options de livraison présentées au checkout.
• Les scripts de paiement deviennent des Payment Customization Functions, avec les mêmes trois opérations appliquées aux moyens de paiement.

Les différences qui piègent les équipes sont celles dont personne ne parle avant les tests. Les Functions compilent en WebAssembly et s'exécutent dans un budget de ressources strict : un script qui bouclait sur un gros panier et appelait un service externe n'a donc aucun équivalent direct. Toute donnée nécessaire à l'évaluation doit être présente dans la requête d'entrée, ce qui suppose généralement de déplacer les paliers clients, les prix contractuels ou les définitions de bundles vers des metafields ou des metaobjects avant que la Function puisse seulement fonctionner.

C'est cette étape de modélisation des données qui consomme l'essentiel des délais de reconstruction. Nous avons détaillé la structure sous-jacente dans notre guide développeur des metaobjects et metafields, et le séquencement global de la migration dans notre playbook Scripts vers Functions. Si vous hésitez encore sur ce qui relève d'une Function plutôt que d'une application ou du thème, cette analyse est la lecture la plus courte.

Éviter la prochaine panne silencieuse

Scripts est la dernière dépréciation de ce cycle, mais ce ne sera pas la dernière tout court. Deux changements méritent d'être faits pendant que l'incident est encore frais.

Posez un garde-fou sur le rapprochement des remises. Une tâche quotidienne comparant la valeur de remise par commande à une moyenne glissante sur sept jours, avec alerte au-delà d'un seuil, aurait détecté le problème en vingt-quatre heures au lieu de deux semaines. Cela coûte un après-midi.

Ensuite, documentez ce que fait réellement votre checkout. Pas le code, le comportement : chaque règle qui modifie un prix, un tarif ou un moyen de paiement, qui l'a demandée, et où elle vit désormais. La plupart des boutiques que nous auditons sont incapables de produire ce document, ce qui explique précisément qu'une dépréciation annoncée quatorze mois à l'avance ait fini en surprise.

Questions fréquentes

Puis-je encore consulter mes anciens Scripts quelque part ?

Non. L'éditeur de Scripts a été retiré et le code Ruby n'est pas récupérable via l'API Admin. Sans export réalisé avant le 15 avril 2026, il faut reconstituer le comportement à partir de l'historique de commandes, des archives merchandising et de l'observation du checkout.

Shopify va-t-il repousser l'échéance ?

Elle n'a pas été repoussée et le moteur a déjà été retiré. Il n'existe aucun retour en arrière.

Les Functions coûtent-elles plus cher à l'exécution que les Scripts ?

Les Functions s'exécutent sur l'infrastructure Shopify sans coût par exécution sur les plans éligibles. L'écart de coût porte sur le développement et la maintenance, pas sur le runtime.

Mes commandes semblent correctes. Dois-je quand même auditer ?

Faites au minimum le rapprochement de l'étape deux. Les scripts rarement déclenchés, comme les paliers grossistes ou les bundles saisonniers, n'apparaîtront pas dans une semaine ordinaire mais vous coûteront dès la première fois que la condition sera remplie.

Combien de temps prend une reconstruction ?

Une remise simple en pourcentage ou par palier prend généralement quelques jours, tests inclus. Une logique dépendant des segments clients ou des prix contractuels prend davantage, car le modèle de données doit exister avant que la Function puisse le lire.