Shopify Scripts meurent dans 48 jours : le playbook de migration vers Functions pour les boutiques Plus

Shopify Scripts s'arrêtent de tourner le 30 juin 2026. Pas "deviennent moins prioritaires". Pas "perdent le support". S'arrêtent de tourner. Toute logique de remise, livraison ou paiement que votre boutique Plus a dans Scripts s'éteint à minuit.

Si vous traitez cela comme un problème pour plus tard, le plus tard est dans 48 jours. Et la fenêtre d'édition est déjà fermée : depuis le 15 avril 2026, vous ne pouvez plus créer, éditer ou republier un Script. Si un Script casse entre maintenant et le 30 juin, vous ne pouvez pas le corriger. Vous ne pouvez que le regarder échouer jusqu'à ce que vous ayez reconstruit la logique dans Functions.

Ce post est le playbook de migration que nous déroulons avec les clients Plus en ce moment. Il couvre ce qui casse réellement, l'audit que vous lancez d'abord, les patterns de reconstruction, les modes d'échec qui piègent les équipes sous pression de deadline, et un compte honnête de ce que le travail coûte. Il est écrit pour les boutiques Plus qui ont encore des Scripts actifs et qui doivent bouger avec méthode, pas dans la panique.

Si votre boutique est sur un plan non-Plus, la deadline Scripts ne vous concerne pas directement, mais la deadline Checkout Extensibility associée (26 août 2026) probablement si. Nous noterons où les deux divergent.

Deux deadlines, ne les confondez pas

L'erreur de planification la plus coûteuse en ce moment est de confondre les deux pistes de dépréciation. Elles sont séparées, elles ont des dates séparées, et elles cassent des choses différentes.

Shopify Scripts → 30 juin 2026. Les Scripts sont la couche de personnalisation en Ruby qui alimente la logique de remise au checkout, la personnalisation des tarifs de livraison et les règles de méthode de paiement sur les boutiques Plus. Édition verrouillée le 15 avril 2026. Le runtime est retiré le 30 juin 2026. Le remplacement est Shopify Functions.

Checkout Extensibility → 26 août 2026. C'est la dépréciation de checkout.liquid, du champ Additional Scripts et des personnalisations legacy des pages Thank You et Order Status. Cela affecte chaque plan, pas seulement Plus. Le remplacement est le Checkout Editor, les Checkout UI Extensions et les Web Pixels.

Une boutique Plus avec une logique de checkout custom a presque toujours une exposition aux deux. L'ordre compte : Scripts est la deadline la plus proche et la plus dure, donc elle passe en premier. Ce post parle de Scripts. Nous publierons le playbook Checkout Extensibility avant sa date d'août.

Ce qui casse réellement le 30 juin

Les Scripts couvrent trois domaines. Voici ce qui arrête de fonctionner dans chacun.

Line item scripts gèrent la logique de remise au niveau du panier et du checkout. Achetez-en-3-le-4e-offert, remises par paliers de volume, pourcentage-de-remise-par-tag-client, règles de prix wholesale, remises sur bundles. Quand les Scripts meurent, tout cela s'arrête. Le checkout se charge toujours. La remise ne s'applique simplement plus. Les clients paient plein tarif, ou la promotion que vous avez annoncée échoue silencieusement.

Shipping scripts personnalisent les tarifs de livraison affichés au checkout. Masquer la livraison express au-dessus d'un seuil de poids, afficher la livraison gratuite pour des groupes de clients spécifiques, renommer ou réordonner les options de tarif, faire remonter conditionnellement des tarifs selon la destination. Quand les Scripts meurent, les clients voient vos tarifs transporteurs bruts, non personnalisés. Pour les boutiques qui s'appuient sur une logique de livraison conditionnelle, c'est une régression visible du checkout.

Payment scripts personnalisent la visibilité et l'ordre des méthodes de paiement. Masquer le paiement à la livraison au-dessus d'un seuil de risque, restreindre les méthodes de paiement par région, réordonner les méthodes pour pousser l'option aux frais les plus bas. Quand les Scripts meurent, chaque méthode de paiement s'affiche pour tout le monde, y compris celles que vous masquiez délibérément.

Le pattern à travers les trois : le checkout ne plante pas, il revient discrètement au comportement par défaut. C'est ce qui rend cela dangereux. Il n'y a pas de page d'erreur. Il y a juste une lente hémorragie de marge, des promotions cassées et des expériences de checkout que vous avez passé des années à régler, le tout revenant au défaut d'un coup sans aucune alerte.

Pourquoi Shopify fait cela

Cela vaut le coup de le comprendre, parce que cela façonne la manière de reconstruire.

Les Scripts tournent sur un interpréteur Ruby en sandbox, isolé du reste de la plateforme Shopify moderne. Ils ne peuvent pas parler à Flow. Ils ne peuvent pas utiliser GraphQL. Ils ne peuvent pas s'intégrer aux Checkout UI Extensions. Ils sont lents sous fort trafic précisément quand vous en avez le plus besoin, pendant les ventes flash. Et chaque mise à jour de plateforme que Shopify livre doit contourner le comportement legacy des Scripts.

Les Functions sont des modules WebAssembly compilés qui tournent nativement dans l'infrastructure de Shopify aux points pertinents du cycle de vie commerce. Elles sont plus rapides, elles sont testables avec de vraies fixtures input/output, elles sont pilotées par configuration, et elles s'étendent à des capacités que les Scripts n'ont jamais eues : cart transforms, validation de checkout, personnalisation de livraison, routage de commande, contraintes de fulfillment.

La migration est réellement une amélioration. Le piège est que c'est une reconstruction, pas une traduction. Vous ne portez pas le Ruby ligne par ligne. Vous ré-exprimez la logique métier dans un modèle de programmation différent avec un runtime différent et des contraintes différentes. Cela prend du vrai temps de développement, et c'est pourquoi commencer en mai plutôt que fin juin compte.

L'audit que vous lancez d'abord

Avant que quiconque écrive une Function, il vous faut un inventaire complet et honnête. Le pattern que nous utilisons :

Étape 1 : sortir le Scripts Customizations Report

Dans l'admin Shopify, le Scripts Customizations Report liste chaque Script actif sur votre boutique et signale ceux qui ont des équivalents Function ou natifs directs. C'est un point de départ, pas un audit complet. Il rate de manière fiable les Scripts ajoutés via deep links, extensions POS ou apps tierces.

Étape 2 : balayage manuel

Ouvrez le Script Editor et lisez chaque Script, y compris ceux désactivés. Pour chacun, notez en langage clair quel résultat métier il produit. Pas "du Ruby qui vérifie cart.line_items" mais "10% de remise quand un client avec le tag wholesale achète 5 unités ou plus". Le résultat métier est ce que vous reconstruisez. Le Ruby n'est qu'une expression de ce résultat.

Étape 3 : catégoriser chaque Script

Triez chacun dans un seau :

• Script mort : désactivé, ou actif mais ne servant plus aucune promotion en cours. Documentez-le et abandonnez-le. Ne migrez pas de poids mort.
• Remplacement natif : Shopify gère désormais cela sans code. Beaucoup de scénarios basiques de pourcentage de remise et de remise automatique sont couverts par les remises automatiques natives.
• Remplacement par app publique : une app Built for Shopify fait déjà ce pattern. Les remises par paliers, le prix de volume simple et les règles de livraison courantes ont souvent une app no-code ou low-code.
• Custom Function requise : logique spécifique à la boutique qu'aucune fonctionnalité native ni app ne couvre. C'est là que se trouve le vrai développement.

Étape 4 : identifier tôt le problème d'appel réseau

C'est la contrainte qui surprend les équipes. Les Functions ne peuvent pas faire de requêtes réseau au runtime. Tout ce dont une Function a besoin au moment de l'exécution doit venir de sa requête d'entrée ou de metafields stockés sur des objets Shopify.

Si un Script appelle actuellement une API externe pour décider de l'éligibilité à une remise, vérifier le statut d'un client dans votre ERP, ou chercher un prix dans un autre système, ce pattern ne se porte pas directement. Vous devez le ré-architecturer : synchroniser les données externes dans des metafields Shopify à l'avance, ou déplacer cette partie de la logique vers un point d'extension qui supporte les opérations async. Trouvez ces Scripts dans l'audit, pas en troisième semaine de reconstruction.

Étape 5 : classer par risque et revenu

Un Script qui alimente votre plus grosse promotion a une priorité différente d'un Script qui réordonne les méthodes de paiement. Séquencez la reconstruction par rayon d'impact : la logique qui perd le plus d'argent ou casse le plus visiblement si elle échoue passe en premier, avec le plus de temps de test.

Les patterns de reconstruction

Une fois l'audit fait, la reconstruction suit un petit ensemble de patterns.

Remises automatiques natives

Pour les promotions simples de pourcentage de remise, montant fixe et achetez-X-obtenez-Y basique, les remises automatiques natives de Shopify couvrent désormais le cas sans code. Si l'audit met un Script dans ce seau, la migration est un changement de configuration dans l'admin, pas une tâche de développement. Faites-les en premier ; elles se règlent vite et réduisent le backlog de reconstruction.

Apps publiques basées sur Functions

Pour les patterns courants, remises par paliers, prix de volume, livraison conditionnelle standard, il y a généralement une app Built for Shopify construite sur Functions qui expose la configuration via l'admin. L'arbitrage est un abonnement mensuel et la roadmap de quelqu'un d'autre, contre zéro développement et maintenance. Pour la logique non différenciante, c'est souvent le bon choix. Pour la logique qui fait partie de votre position concurrentielle, construisez-la.

Custom Functions

Pour la logique spécifique à la boutique, vous construisez une Function. L'architecture :

Une Function est un petit module WebAssembly, écrit en Rust ou JavaScript, que Shopify invoque à un point d'extension spécifique. Elle reçoit une entrée définie par une requête GraphQL que vous écrivez, et elle retourne une sortie structurée. Les APIs Function que vous utiliserez le plus pour une migration Scripts sont la Discount Function API, la Delivery Customization API et la Payment Customization API. La logique complexe qui combine plusieurs types de Scripts peut aussi mobiliser Cart Transform ou Checkout Validation.

La forme d'une Function de remise :

// src/run.js : tourne au point d'extension de remise panier/checkout
export function run(input) {
  const discounts = [];

  // input est exactement ce que votre requête run.graphql a demandé, rien de plus
  const cart = input.cart;
  const wholesaleTier = cart.buyerIdentity?.customer?.wholesaleTier?.value;

  if (wholesaleTier === "tier_2") {
    const eligibleLines = cart.lines.filter(
      (line) => line.quantity >= 5
    );

    for (const line of eligibleLines) {
      discounts.push({
        targets: [{ cartLine: { id: line.id } }],
        value: { percentage: { value: "10.0" } }
      });
    }
  }

  return {
    discounts,
    discountApplicationStrategy: "MAXIMUM"
  };
}

La requête run.graphql qui l'alimente demande seulement ce dont la logique a besoin :

query Input {
  cart {
    buyerIdentity {
      customer {
        wholesaleTier: metafield(namespace: "custom", key: "wholesale_tier") {
          value
        }
      }
    }
    lines {
      id
      quantity
    }
  }
}

Deux choses à intégrer de ce petit exemple. D'abord, la Function ne reçoit que les données que la requête demande. Si vous oubliez de demander un champ, il n'est tout simplement pas là au runtime, et c'est le bug le plus courant dans les migrations Scripts. Ensuite, le palier wholesale du client vient d'un metafield, pas d'un appel API, parce que la Function ne peut pas atteindre vos systèmes au runtime. La donnée doit déjà être sur l'objet Shopify.

C'est aussi là qu'une architecture metafield propre paie. Nous avons écrit sur les metaobjects et metafields Shopify le mois dernier ; la discipline de ce post est exactement ce qui rend les entrées de Function fiables.

Les modes d'échec qui piègent les équipes

De la vague de migration qui tourne depuis fin 2025, les mêmes erreurs reviennent. Les connaître à l'avance transforme un incendie de six semaines en un projet de deux semaines.

Supposer que l'entrée a ce dont vous avez besoin. La Function ne reçoit que les champs que votre requête run.graphql demande explicitement. Les équipes écrivent la logique en supposant qu'un champ est disponible, livrent, et la Function se comporte silencieusement comme si la valeur était null. Testez avec de vraies fixtures.

Oublier la contrainte no-network jusqu'à trop tard. Une équipe reconstruit une Function de remise, la fait marcher dans une fixture, puis découvre que le Script original appelait une API de prix externe. Maintenant il leur faut un pipeline de sync de metafields qu'ils n'avaient pas budgété. Trouvez-les dans l'audit.

Traduire le Ruby au lieu de reconstruire la logique. Scripts et Functions ont des modèles différents. Essayer de porter mécaniquement le Ruby produit des Functions maladroites et buguées. Ré-exprimez le résultat métier de zéro dans le modèle Function.

Oublier de mapper le champ revenu ou valeur. Un échec largement rapporté : une équipe a migré un tag Google pendant le travail de checkout associé mais n'a pas mappé le champ revenu, et a fait tourner des campagnes pendant trois semaines avec des conversions reportant à zéro valeur, ce qui a détruit le Smart Bidding. L'équivalent Scripts est de migrer la logique de remise mais de mal mapper la valeur ou la cible de la remise. Vérifiez les sorties contre des commandes connues.

Tester seulement le chemin heureux. La logique de remise a des cas limites : panier vide, mélange d'articles éligibles et non éligibles, cumul avec d'autres remises, cas limites de devise, paniers B2B versus B2C. Les Functions sont testables avec des fixtures input/output précisément pour que vous puissiez couvrir ces cas. Utilisez cela.

Basculer sans vérification parallèle. Faites tourner la nouvelle Function aux côtés de l'ancien Script en développement, alimentez les deux avec les mêmes entrées, comparez les sorties. Ne basculez que quand elles correspondent sur vos cas limites.

Ce que cela coûte

Des chiffres honnêtes, parce que la question de planification que chaque marchand Plus a est "combien et combien de temps".

L'audit est d'une demi-journée à une journée, selon le nombre de Scripts que vous avez et la qualité de leur documentation.

Un Script simple qui se mappe sur une remise native ou une app publique est une tâche de configuration, une heure ou deux chacun.

Une Function custom pour une logique spécifique à la boutique est typiquement deux à quatre jours de développement incluant la requête run.graphql, la logique de la Function, les tests sur fixtures et la vérification parallèle. La logique complexe combinant plusieurs types de Scripts, ou la logique qui a besoin d'un nouveau pipeline de sync de metafields à cause de la contrainte no-network, prend plus longtemps.

Pour une boutique Plus avec une poignée de Scripts custom, le total réaliste est d'une à trois semaines de travail concentré. Les boutiques avec une logique promotionnelle lourde et imbriquée prennent plus longtemps, ce qui est la raison entière pour laquelle commencer en mai plutôt que fin juin compte. Les boutiques qui attendent reconstruiront la logique de checkout pendant leurs semaines les plus chargées, sous pression de deadline, sans accès en édition aux Scripts qui échouent.

FAQ

Que se passe-t-il exactement le 30 juin 2026 ?

Tous les Shopify Scripts arrêtent de s'exécuter. La logique de remise, livraison et paiement construite dans Scripts ne tourne plus. Le checkout continue de fonctionner mais revient au comportement par défaut pour tout ce qu'un Script personnalisait. Il n'y a pas d'extension et Shopify a été explicite que la date est finale.

Puis-je encore éditer mes Scripts d'ici là ?

Non. L'édition, la création et la republication de Scripts ont été verrouillées le 15 avril 2026. Les Scripts existants continuent de tourner jusqu'au 30 juin, mais vous ne pouvez pas les changer. Si l'un casse, il ne peut pas être corrigé.

Faut-il Shopify Plus pour utiliser Functions ?

Les apps publiques construites sur Functions fonctionnent sur n'importe quel plan. Les Functions custom, le vrai remplacement des Scripts custom, nécessitent Shopify Plus. Comme les Scripts étaient eux-mêmes une fonctionnalité Plus, la plupart des boutiques affectées par la deadline Scripts ont déjà Plus.

Rust ou JavaScript pour les Functions ?

Les deux sont supportés. JavaScript a une courbe d'apprentissage plus douce et convient pour la plupart de la logique de remise, livraison et paiement. Rust offre de meilleures performances et vaut le coup pour les Functions qui tournent sur chaque panier sous fort trafic. Pour une migration Scripts typique, JavaScript est un défaut raisonnable ; choisissez Rust délibérément là où les performances le justifient.

Et la deadline Checkout Extensibility ?

Piste séparée, date séparée : 26 août 2026, affectant checkout.liquid, le champ Additional Scripts et les pages legacy Thank You et Order Status, sur chaque plan. Une boutique Plus a généralement une exposition aux deux. Faites la migration Scripts en premier parce que la deadline est plus proche et le travail plus dur, puis gérez Checkout Extensibility.

Puis-je le faire moi-même ou ai-je besoin d'une agence ?

Les Scripts simples qui se mappent sur des fonctionnalités natives ou des apps publiques, vous pouvez les gérer en interne. Les Functions custom pour une logique complexe et spécifique à la boutique nécessitent généralement un développeur à l'aise avec le modèle Function, les requêtes GraphQL d'entrée et les tests sur fixtures. Si vos Scripts ont été écrits par un développeur à l'origine, supposez que vous avez besoin d'au moins un peu d'aide technique pour les reproduire correctement.

Pour aller plus loin

Si votre boutique a encore des Scripts actifs, l'audit est la chose à faire cette semaine. Il demande peu d'effort et il vous dit exactement combien de travail se trouve entre vous et le 30 juin.

Si vous voulez que nous fassions l'audit et la migration, contactez-nous. Nous commençons par l'audit d'une demi-journée, livrons l'inventaire de Scripts catégorisé et un plan de reconstruction séquencé, et livrons les Functions custom avec des tests sur fixtures et une vérification parallèle avant la bascule. Pour les boutiques Plus avec une logique promotionnelle complexe, plus tôt l'audit arrive, plus calmement le reste se passe. Vous pouvez aussi en savoir plus sur notre travail de développement d'apps et Functions Shopify.

Pour des lectures associées, notre guide metaobjects et metafields couvre l'architecture de données qui rend les entrées de Function fiables, et notre post app custom versus app publique aide avec la décision construire-ou-acheter qui revient constamment pendant une migration Scripts.