Shopify Scripts a cessé de fonctionner le 30 juin 2026. Voici ce qu'il faut faire maintenant.
Si votre boutique utilisait un Script de remise personnalisée, de BOGO ou de bundle, il a cessé de s'exécuter le 30 juin 2026, silencieusement. Aucune erreur, aucune alerte, rien dans vos journaux. Voici exactement ce qui s'est passé, ce qu'implique réellement la migration vers Shopify Functions, et une réponse honnête sur ce que Stackable peut reconstruire pour vous.
- Shopify Scripts a cessé de s'exécuter le 30 juin 2026 pour toutes les boutiques qui les utilisaient encore.
- Toute logique de remise personnalisée, de BOGO ou de bundle hébergée dans un Script a cessé de s'appliquer à cette date.
- Cet échec est silencieux par conception : une Shopify Function dont les conditions ne correspondent pas à un panier donné ne se déclenche tout simplement jamais. Elle ne génère aucune erreur, et Shopify ne vous avertit pas.
Les marchands qui traversent cette migration décrivent le même danger sur les forums de la communauté Shopify :
“Mon ancien Script a discrètement cessé d'appliquer une remise, et je ne l'ai découvert que parce qu'un client s'est plaint d'avoir payé le plein tarif. Il n'y a eu aucune erreur, aucune alerte, rien dans les journaux de commande. Ma configuration était défaillante depuis des semaines avant que je ne m'en aperçoive.”
C'est le risque central du passage de Scripts à Functions : une Function est soit correctement formée et active, soit mal configurée et silencieuse. Il n'existe pas d'état intermédiaire visible, si bien qu'une condition mal alignée, une faute de frappe dans un seuil, ou une règle ciblant la mauvaise collection produit exactement le même silence qu'une Function qui fonctionne correctement. La seule façon de le détecter est de tester délibérément les deux scénarios avant de lui faire confiance en production.
Quatre choses à savoir avant de commencer
Un seul Script devient souvent trois migrations
Un seul fichier Script pouvait toucher à la fois la logique de remise, les tarifs de livraison et la personnalisation des paiements. Functions répartit cela en types de Function distincts : remise, livraison et paiement, chacun configuré et déployé indépendamment. Migrer « mon Script » signifie généralement migrer jusqu'à trois éléments différents, et c'est la plainte que les marchands expriment le plus souvent à propos de cette transition.
Les générateurs sans code couvrent généralement les remises et le BOGO uniquement
Si votre Script touchait également les tarifs de livraison ou les modes de paiement, un générateur sans code de Function de remise, Stackable y compris, n'y a pas accès. Les personnalisations de livraison et de paiement nécessitent qu'un développeur écrive directement cette Function.
Conservez dès maintenant le code source de votre ancien Script
Une fois l'éditeur de Scripts définitivement retiré, le code qui y était stocké devient irrécupérable. Exportez ou copiez dès aujourd'hui le code source de votre ancien Script, même si vous n'êtes pas encore prêt à migrer, afin de disposer d'une référence pour ce qui le remplacera.
Testez un panier qui doit déclencher la règle et un panier qui ne le doit pas
Avant de faire confiance à une nouvelle Function, créez deux paniers de test : un qui doit la déclencher, et un qui, délibérément, ne le doit pas. Une Function qui se déclenche alors qu'elle ne le devrait pas coûte tout aussi cher qu'une Function qui ne se déclenche jamais silencieusement.
Les trois éléments qui expliquent chaque décision de migration
Presque tout débat sur ce qui peut ou ne peut pas être reconstruit se résume à trois faits : Scripts existait en trois types avec un seul emplacement chacun, Functions répartit ces trois types sur quatre API différentes, et une Function doit déclarer à l'avance chaque donnée qu'elle lira. Une fois ces trois faits acquis, le reste de cette page n'est plus que de l'arithmétique.
Shopify Scripts existait en trois types
L'éditeur de Scripts vous demandait de choisir un type avant même d'écrire une ligne de Ruby, et ce type décidait de ce que votre code avait le droit de toucher.
Scripts sur les articles
Ceux qui changeaient le prix des produits. Ils parcouraient le panier ligne par ligne pour le retarifer, c'est là que vivaient toutes les remises par palier, les BOGO, les prix de lot et les soldes.
Scripts de livraison
Ceux qui agissaient sur les tarifs de livraison. Ils pouvaient remiser un tarif, le masquer, le renommer ou réorganiser la liste vue par le client. Seule la première de ces quatre actions est une remise.
Scripts de paiement
Ceux qui agissaient sur les modes de paiement, avec les quatre mêmes actions : masquer un mode, le renommer, réorganiser la liste ou, en pratique, surtout le masquer pour certains paniers.
Voici maintenant la contrainte qui a façonné chaque Script réel que vous lirez : un seul Script de chaque type pouvait être publié à la fois. Un seul emplacement pour les articles, pour toute la boutique. Un marchand qui faisait tourner une remise VIP, un prix de liquidation, un seuil de dépense et une promotion saisonnière n'écrivait donc pas quatre Scripts. Il écrivait un seul fichier où les quatre étaient fusionnés, généralement avec une règle artisanale du type « garder le prix le plus avantageux » ajoutée à la fin. C'est pour cela que les vrais Scripts paraissent enchevêtrés. Ce n'est pas une règle mal écrite, ce sont plusieurs règles qui n'ont jamais eu le droit d'être séparées.
Voir un vrai Script avec quatre campagnes fusionnées dans un seul fichierQuatre API Function les ont remplacés
Shopify n'a pas remplacé Scripts par une seule chose. Il les a remplacés par quatre, réparties selon ce que le code a le droit de modifier plutôt que selon l'endroit du panier où il s'exécute.
Discount Function API
De l'argent en moins. Les remises produit, les remises commande et les remises de livraison vivent désormais toutes ici, dans une seule API unifiée. Si votre Script changeait un prix, c'est ici qu'il va.
La documentation de ShopifyDelivery Customization API
Masquer, renommer et réorganiser les options de livraison. Shopify est explicite : c'est la seule API capable de personnaliser les options de livraison au paiement, donc une application de remises ne peut pas l'atteindre, quelle que soit la façon dont elle est construite.
La documentation de ShopifyPayment Customization API
Masquer, renommer et réorganiser les modes de paiement, ainsi que les modalités de paiement et le fait qu'une commande nécessite ou non une vérification. La moitié « paiement » de l'ancien éditeur de Scripts, réunie en un seul endroit.
La documentation de ShopifyCart and Checkout Validation API
Bloquer le paiement avec un message. Les limites d'achat, les vérifications d'âge et les règles de commande minimale se trouvent ici. Elle renvoie des erreurs, elle peut donc arrêter une commande mais ne peut pas la modifier silencieusement.
La documentation de ShopifyStackable est une application Discount Function, et rien d'autre. Nous construisons des fonctions de remise, nous pouvons donc reconstruire tout ce que votre Script faisait à un prix, y compris les remises de livraison. Nous ne proposons ni personnalisation de livraison, ni personnalisation de paiement, ni fonction de validation, donc masquer un tarif de livraison, renommer un mode de paiement ou plafonner une quantité d'achat n'est pas quelque chose que nous refusons faute de l'avoir construit. C'est un autre genre d'application.
Mettez les deux moitiés ensemble et vous obtenez la phrase que les marchands découvrent à leurs dépens : un seul Script devient souvent trois migrations. Un Script d'article qui masquait aussi un tarif de livraison et bloquait un mode de paiement devient désormais une fonction de remise, une personnalisation de livraison et une personnalisation de paiement, écrites et déployées séparément. Nous préférons que vous le lisiez ici plutôt que de le découvrir après coup.
Voir un Script de livraison qui ne s'avère pas être une remise du toutLes Functions sont pures, et chaque champ est déclaré à l'avance
Un Script s'exécutait comme du Ruby ordinaire sur le contenu du panier, quel qu'il soit. Une Function s'exécute dans un bac à sable, et Shopify garantit qu'elle ne dispose d'aucun des éléments suivants :
- Pas de réseau. Une Function ne peut pas appeler votre ERP, votre prestataire de fidélité ou tout autre service pendant qu'un client passe commande.
- Pas d'horloge. Une Function ne peut pas savoir quelle heure il est, donc « moitié prix le mardi » doit devenir une remise programmée plutôt qu'une condition dans le code.
- Pas de hasard. Rien ne peut tirer au sort un client sur dix.
- Pas de système de fichiers, et aucune possibilité d'aller chercher un champ qu'elle n'a pas demandé. Chaque donnée qu'une Function lit doit être nommée à l'avance, dans une requête d'entrée, et cette requête a un plafond de coût strict fixé par Shopify.
Cette dernière règle est celle qui coûte le plus cher aux marchands, et il vaut la peine de préciser à qui elle coûte. Ce n'est pas que Shopify cache les données. Notre propre requête de paiement se trouve déjà au coût maximal autorisé par Shopify, donc demander un champ de plus signifie en abandonner un autre. Neuf des formes de Script que nous refusons aujourd'hui sont refusées pour exactement cette raison, et aucune autre, y compris ignorer les articles déjà soldés, lire une province ou un code postal, et vérifier le nombre de commandes déjà passées par un client. Shopify propose chacun de ces éléments. Nous ne leur avons pas encore fait de place. C'est notre lacune, et prétendre que c'est une limite de la plateforme serait un mensonge.
Seuls deux refus dans toute la bibliothèque sont de véritables limites de Shopify, et toutes deux viennent du même fait : toutes les fonctions de remise d'une boutique s'exécutent au même moment, et aucune ne peut voir ce que les autres ont fait. Un Script qui demandait « cet article a-t-il déjà été remisé ? » ou qui mesurait un seuil par rapport à un sous-total déjà réduit ne peut être reconstruit ni par nous ni par personne d'autre, aujourd'hui, à quelque prix que ce soit. Tout le reste de notre liste de refus est de notre ressort, et nous l'indiquons ainsi dans l'application et sur chaque page de la bibliothèque.
Lire les deux refus qui sont réellement des limites de ShopifyFixer un prix n'est pas la même chose que retirer de l'argent
Si vous ne devez lire qu'une seule chose avant de reconstruire un Script à la main, lisez celle-ci. Deux fichiers peuvent appeler la même méthode, avec la même constante et le même message, et vouloir dire le contraire l'un de l'autre. Les deux exemples suivants sont réels, tous deux courants, et la seule différence entre eux est un signe de soustraction.
Ceci FIXE le prix à $9.99
FIXED_PRICE = Money.new(cents: 999)
Input.cart.line_items.each do |line_item|
next unless line_item.variant.product.product_type == "Clearance"
line_item.change_line_price(FIXED_PRICE * line_item.quantity, message: "Clearance $9.99 each")
end
Output.cart = Input.cartSur un article à $79.00, la remise est de $69.01 et le client paie $9.99. Reconstruit comme une offre de volume dont la récompense est un prix fixe, comptée par variante et répétée, de sorte que chaque unité est retarifée.
L'exemple concret, avec le panier et les réglagesCeci retire $9.99
DISCOUNT = Money.new(cents: 999)
Input.cart.line_items.each do |line_item|
next unless line_item.variant.product.product_type == "Clearance"
new_price = line_item.line_price - (DISCOUNT * line_item.quantity)
line_item.change_line_price(new_price, message: "$9.99 off each")
end
Output.cart = Input.cartSur le même article à $79.00, la remise est de $9.99 et le client paie $69.01. Reconstruit comme une offre de volume dont la récompense est un montant de réduction par unité, comptée par produit et se déclenchant une seule fois.
L'exemple concret, avec le panier et les réglagesMême méthode, même $9.99, même formulation dans le message. Le seul indice est que le second fichier soustrait de `line_item.line_price` avant d'assigner. Lisez-le à l'envers sur un article à $79.00 et vous êtes à côté de $59.02 sur une seule unité, dans le sens qui fait le plus mal. Et les deux reconstructions ne diffèrent pas seulement par le chiffre : l'une compte par variante et se répète, l'autre compte par produit et se déclenche une seule fois, elles divergent donc aussi dès que le client en achète deux.
C'est l'échec que les conseils habituels ne peuvent pas détecter. Une offre reconstruite qui lit le fichier à l'envers se déclenche quand même sur un panier qui doit la déclencher, et reste silencieuse sur un panier qui ne doit pas la déclencher, si bien que tester les deux sens la laisse passer. Sauvetage des Scripts règle cela en posant une autre question : avant de vous laisser publier, il demande le montant que votre ancien Script facturait sur un panier que vous pouvez encore reproduire, et le compare à ce que calcule l'offre reconstruite. Un centime d'écart et la publication reste bloquée. Parmi les cinq applications qui vendent aujourd'hui la migration des Scripts, notre étude n'en a trouvé aucune qui demande à un marchand de prouver l'exactitude du montant.
Ce que devient chaque morceau de Ruby dans une campagne
Une reconstruction se trompe toujours aux mêmes quelques endroits, et ce ne sont presque jamais les plus évidents. La récompense est généralement facile. C'est le comptage et la répétition qui font discrètement bouger l'argent, parce qu'un Script les exprime en arithmétique et une campagne les exprime dans un réglage.
| Dans votre Script | Dans une campagne | Où ça se trompe |
|---|---|---|
change_line_price(PRICE * qty) | Une offre de volume avec une récompense de type prix fixe. | Affectation, pas soustraction. C'est le piège vu plus haut. Le prix unitaire devient la constante, si bien qu'un article à $79 se vend $9.99. |
line_price - (AMOUNT * qty) | Une offre de volume avec une récompense de type montant de réduction par unité. | La soustraction est tout le signal. Même constante que la ligne du dessus, une facture totalement différente. |
line_price * 0.9 | Une récompense en pourcentage de 10. | Le multiplicateur est ce que le client garde, pas ce qu'il économise. Saisi tel quel comme 90, il donne neuf dixièmes du catalogue. |
next unless line_item.quantity >= 3 | Un palier avec une quantité minimale de 3. | Les paliers sont inclusifs à la limite, et seul le palier satisfait le plus élevé se déclenche. Les Scripts qui empilaient une règle sur une autre n'ont pas d'équivalent en une seule offre, il en faut une par règle. |
line_items.size > 1 | Une quantité minimale de 2. | Ce n'est pas la même règle. Ici, les Scripts comptaient des lignes de panier distinctes, les campagnes comptent des unités, si bien qu'une ligne contenant deux fois le même article est désormais éligible là où le Script l'ignorait. |
sets = quantity / (BUY + GET) | Achetez X Obtenez Y avec les unités gratuites comptées en supplément. | Diviser uniquement par ACHETER rend au contraire les unités gratuites inclusives. Sur neuf unités d'un achetez 3 obtenez 1, cela fait deux ou trois articles gratuits. Un seul caractère d'écart, et la moitié en plus est offerte. |
customer.tags.include?("vip") | Éligibilité du client limitée aux étiquettes. | Shopify fait correspondre les étiquettes exactement, majuscules comprises, alors que beaucoup de dialectes de Script mettaient d'abord les deux côtés en minuscules. Vérifiez l'orthographe avant de publier, pas après. |
product.tags / product_type / vendor | Portée de ciblage définie sur des étiquettes, des types de produits ou des fournisseurs. | Une ligne de portée oubliée est l'erreur la plus coûteuse de ce tableau, car elle transforme « 20 % sur l'étiquette solde » en 20 % sur tout ce que vous vendez. |
Une chose que vous ne trouverez pas dans ce tableau : les collections. Un Script pouvait lire les étiquettes, le type et le fournisseur d'un produit, mais jamais ses collections, donc tout Ruby prétendant vérifier une collection ne faisait pas réellement ce qu'il semblait faire. Les campagnes peuvent cibler des collections ; votre ancien Script ne le pouvait pas.
Recherchez votre Script au lieu de le déduire
Chaque forme de Script que nous avons cataloguée a sa propre page : le Ruby d'origine, ce qu'il est reconnu comme étant, la configuration exacte qu'il devient, un panier de notre boutique de démonstration publique avec la remise calculée pour lui par le vrai moteur, et le panier qui doit rester silencieux. Les refus sont décrits de la même façon, chacun étiqueté comme une limite de Shopify, notre propre lacune, ou une tâche pour un autre type d'application. C'est la référence que nous aurions voulu avoir à nos débuts, alors elle est publique.
- Formes de Script
- 42
- Reconstruits aujourd'hui
- 38
- Refusés, avec motif
- 21
Une réponse honnête sur le périmètre
Stackable reconstruit la logique de remise basée sur des règles avec les Shopify Functions natives. Il n'exécute pas de code personnalisé arbitraire.
Ce que Stackable reconstruit
- Remises par palier / volume (par ex. « achetez 3+, économisez 15 % »)
- Logique Achetez X Obtenez Y et BOGO, y compris les paliers répétés
- Règles explicites de cumul de remises entre offres
- Démarrage et fin programmés, ainsi que mise en pause instantanée, sur toute campagne
Vous aurez encore besoin d'un développeur pour ceci
- Le code personnalisé arbitraire exécuté par votre ancien Script (formules de tarification sur mesure, conditions ponctuelles qu'aucun générateur ne couvre)
- Les personnalisations de livraison / expédition (un type de Function distinct)
- Les personnalisations de paiement (un type de Function distinct)
- Tout ce qui ne se ramène pas à une configuration de remise basée sur des règles
Si votre ancien Script faisait quelque chose de cette liste, un créateur sans code, Stackable inclus, ne peut pas l'atteindre. C'est une Function écrite par un développeur, pas un écran de configuration.
Questions fréquentes
Mes anciens Scripts ont-ils disparu ?
Scripts a cessé de s'exécuter le 30 juin 2026, mais ce n'est pas nécessairement le moment où le code stocké dans l'éditeur de Scripts est supprimé. Exportez ou copiez dès maintenant le code de votre ancien Script dans tous les cas : une fois que Shopify aura définitivement retiré l'éditeur, il deviendra irrécupérable.
Recevrai-je une erreur si une Function est mal configurée ?
Non. Une Function dont les conditions ne correspondent pas à un panier ne se déclenche tout simplement jamais, silencieusement, sans erreur ni alerte. Testez toujours avec un panier qui doit la déclencher et un panier qui ne le doit pas avant de lui faire confiance en production.
Stackable remplace-t-il tout ce que faisait mon ancien Script ?
Seulement la partie basée sur des règles : remises par palier et par volume, BOGO, cumul de remises et programmation, toutes reconstruites sur des Shopify Functions natives. Stackable n'exécute pas de code personnalisé arbitraire. Si votre Script effectuait quelque chose de véritablement sur mesure, une formule de tarification personnalisée ou une condition qu'aucun générateur ne couvre, cela nécessite toujours qu'un développeur écrive directement la Function.
Qu'en est-il de la logique de livraison ou de paiement que gérait mon Script ?
Il s'agit de types de Function distincts (livraison et paiement) auxquels Stackable ne touche pas. Un développeur doit les migrer indépendamment de votre logique de remise.
Sur quel forfait se trouve Sauvetage des Scripts ?
Sauvetage des Scripts, l'outil qui lit votre ancien Ruby et le reconstruit, se trouve sur le forfait Pro. Stackable elle-même est gratuite à installer, et le moteur de réduction principal, y compris les paliers de volume, Achetez X Obtenez Y, les objectifs de dépense, la livraison gratuite, la programmation et le simulateur, est gratuit sur tous les forfaits. Le sauvetage du Ruby, lui, ne l'est pas : il se trouve aux côtés du multi-boutique et de Shopify Flow sur le forfait Pro.
Comment savoir si la remise reconstruite facture le même montant que l'ancienne ?
Parce que vous êtes tenu de le prouver avant de pouvoir publier. Tester un panier qui doit se déclencher et un autre qui ne le doit pas est le conseil habituel, et il ne détecte pas le pire des échecs, celui d'une offre qui se déclenche correctement mais pour le mauvais montant. Sauvetage des Scripts vous demande le montant que votre ancien Script facturait sur un panier que vous pouvez encore reproduire, le compare à ce que calcule l'offre reconstruite, et garde la publication bloquée tant que les deux ne correspondent pas au centime près. Notre étude des cinq applications qui vendent la migration des Scripts n'en a trouvé aucune qui demande cela.
Pourquoi mon Script paraissait-il si compliqué ?
Parce qu'un seul Script de chaque type pouvait être publié à la fois. Une boutique qui faisait tourner quatre promotions ne pouvait pas écrire quatre Scripts, elle écrivait donc un seul fichier où les quatre étaient fusionnés, avec une règle à la fin pour décider laquelle l'emportait. La plupart du Ruby qui paraît illisible est en réalité plusieurs règles simples partageant un même emplacement, et chacune se reconstruit généralement proprement une fois séparée.
Où puis-je lire l'article complet sur la migration ?
Notre premier article de blog détaille l'abandon de Scripts et le parcours de migration, et la bibliothèque d'exemples de Scripts propose une page par forme de Script avec le Ruby d'origine et la reconstruction exacte.
Fonctionnalités associées
Discount Stacking
How to stack discounts in Shopify comes down to settings the platform hides by default: every discount belongs to a class (product, order, or shipping), and whether two discounts combine is decided per offer, per class. Stackable puts those combine switches on every offer, so a volume tier, a spend goal, and free shipping add up exactly the way you configured them, every time.
BOGO / Buy X Get Y
Running BOGO beyond the 100-product cap isn't possible with Shopify's native Buy X Get Y discount: it stops letting you add eligible products once you pass 100, and it only applies once per order. Stackable removes both limits and adds cheapest-item-free logic on top.
Scheduled Sales
Shopify scheduled sales fail two ways in the wild: campaigns that silently never start, and live campaigns with no pause button. Stackable's scheduler runs on the same reliability guarantee as its checkout math, and pausing takes effect storefront-wide in under a minute.
Installez Stackable et reconstruisez vos remises basées sur des règles
Paliers de volume, BOGO, cumul et programmation, fonctionnant sur les Shopify Functions natives dès le premier jour.
Sauvetage des Scripts fait partie du forfait Pro. Stackable elle-même est gratuite à installer, sans carte requise.