Fin de Shopify Scripts le 30 juin 2026 : Comment migrer vos remises sans développeur

Shopify Scripts cessent de s'exécuter le 30 juin 2026, et chaque règle personnalisée de remise, d'expédition ou de paiement que vous avez créée dans l'Éditeur de Scripts cesse de s'appliquer à cette date. Le remplacement est Shopify Functions, qui exécute votre logique côté serveur à l'intérieur du paiement. Vous avez trois façons d'y arriver : embauchez un développeur pour écrire des Functions, payez une agence pour le faire, ou reconstruisez une logique de remise basée sur les règles dans une application Functions sans codage. La partie urgente est que l'échec est silencieux. Un Script qui cesse de se déclencher, ou une règle migrée qui ne correspond pas à un panier, ne lance pas d'erreur et ne vous avertit pas. Cela facture simplement silencieusement le prix complet jusqu'à ce qu'un client se plaigne.

Ce guide explique ce que les Scripts faisaient, pourquoi Shopify les retire, ce que les Functions sont réellement, pourquoi "migrer mon Script" est vraiment jusqu'à trois migrations séparées, le piège de l'échec silencieux et exactement comment le tester, ce qu'une application sans codage peut et ne peut pas couvrir, et une ventilation honnête de quand vous avez toujours besoin d'un développeur.

Que se passe-t-il avec Shopify Scripts, et quand?

Les Shopify Scripts sont en cours de suppression. Selon la documentation pour développeurs de Shopify, « Shopify Scripts sera supprimé le 30 juin 2026. Tous les Scripts Shopify existants cesseront de fonctionner après cette date. » Il y a deux dates qui comptent, et la première a déjà passé :

• 15 avril 2026 : l'édition et la publication de nouveaux Scripts Shopify ne sont plus possibles. Selon le journal des modifications pour développeurs Shopify, après cette date, vous ne pouvez plus créer ou modifier un Script du tout.
• 30 juin 2026 : tous les Scripts Shopify cessent de s'exécuter entièrement. Toute logique de remise, d'expédition ou de paiement qui vit dans un Script cesse simplement de fonctionner.

Si votre magasin s'appuyait toujours sur un Script le 1er juillet 2026, cette logique est déjà hors ligne au moment où vous lisez ceci. Les personnalisations n'ont pas échoué ou n'ont pas été annulées à une valeur par défaut sûre. Elles sont devenues silencieuses. C'est la chose la plus importante à comprendre sur cette date limite : ce n'est pas un échec bruyant que vous remarquerez d'une alerte de tableau de bord. C'est une absence.

Shopify fournit également un outil pour vous aider à évaluer le travail. Le rapport de personnalisations Shopify Scripts vous aide à identifier quelles sont vos personnalisations actuelles qui peuvent être transférées à Functions ou des applications publiques. Si vous ne l'avez pas exécuté, c'est l'étape un.

IMAGE PLACEHOLDER (Image 1): The Scripts sunset timeline

Suggested visual: A clean 16:9 horizontal timeline on a white background with three milestone markers in violet and deep gold. Marker one, "April 15, 2026 - editing ends" in gold. Marker two, "June 30, 2026 - Scripts stop executing" in violet with a small red "silent" tag. A trailing arrow labeled "Shopify Functions" continues past the last marker. Flat, minimal, sans-serif labels, no photography.

Qu'est-ce que Shopify Scripts faisaient et pourquoi Shopify les retire-t-il?

Les Shopify Scripts étaient de petits programmes Ruby qui s'exécutaient dans l'application Éditeur de Scripts et personnalisaient trois parties du flux d'achat : les remises sur les lignes d'articles et le panier, les tarifs d'expédition et les méthodes de paiement. Un commerçant sur Shopify Plus pouvait écrire un Script qui donnait une remise échelonnée, cachait une option d'expédition pour certaines adresses ou réorganisait les méthodes de paiement au paiement. Les Scripts étaient puissants précisément parce que c'était du code arbitraire : si vous pouviez l'exprimer en Ruby, vous pouviez le faire.

Shopify les remplace par Shopify Functions. Selon la documentation de migration, « Avec Shopify Functions, ces personnalisations sont désormais gérées via des API Functions dédiées qui offrent de meilleures performances et flexibilité. » Les Functions s'exécutent sur l'infrastructure propre de Shopify à l'intérieur du pipeline de paiement, ce qui les rend plus rapides et plus évolutives que l'ancien modèle de Scripts, et cela signifie que la même logique s'applique qu'un acheteur se paie sur la page du panier, la page de paiement ou un portefeuille accéléré comme Shop Pay.

L'inconvénient est que les Functions ne sont pas une boîte de texte dans laquelle vous collez du Ruby. Ce sont des artefacts pour développeurs : vous les scaffoldez avec la CLI Shopify, écrivez la logique en Rust ou JavaScript, définissez une requête d'entrée GraphQL et les déployez via une application. Ce changement, de « le commerçant écrit un Script » à « le développeur expédie une Function, » est toute la raison pour laquelle cette migration est un projet et non une case à cocher.

Qu'est-ce que Shopify Functions et pourquoi ont-elles généralement besoin d'un développeur?

Shopify Functions vous permet d'étendre ou de remplacer des parties de la logique backend de Shopify par du code personnalisé qui s'exécute pendant le paiement. Il existe des API Functions dédiées pour les choses que les Scripts faisaient autrefois, y compris une Discount Function API, une Delivery (expédition) Customization API et une Payment Customization API.

Deux propriétés des Functions importent pour votre plan de migration.

Les Functions s'exécutent côté serveur, une fois

Une Function s'exécute à l'intérieur du paiement de Shopify, pas dans votre thème. C'est une véritable amélioration par rapport aux méthodes de remise qui calculent un total en JavaScript de thème sur la page du panier et puis ne s'accordent pas avec ce que le paiement facture. Parce que la Function est la seule source de vérité, l'aperçu du panier et le charge finale sont le même calcul. C'est aussi pourquoi une Function correctement construite s'applique de manière identique à Shop Pay, Apple Pay et Google Pay, qui ignorent entièrement la page du panier.

Les Functions sont construites, non configurées, par défaut

L'écriture d'une Function à partir de zéro est une tâche pour développeurs. Vous avez besoin de la CLI Shopify, d'une chaîne d'outils de langage et d'une familiarité avec la requête d'entrée de la Function et la forme du résultat. Il y a une nuance utile à connaître sur la disponibilité des plans : selon la documentation de disponibilité des Functions, « Les magasins sur n'importe quel plan peuvent utiliser des applications publiques distribuées via l'App Store Shopify et contenant des functions. Seuls les magasins sur un plan Shopify Plus peuvent utiliser des applications personnalisées contenant des API Shopify Functions. » En termes simples : une application publique de l'App Store peut apporter des Functions à n'importe quel plan, mais une Function personnalisée et construite sur mesure est un chemin réservé à Plus. Cette distinction est ce qui rend une application Functions sans codage attrayante pour les commerçants non-Plus qui s'appuyaient autrefois sur un développeur.

La bonne nouvelle est qu'une fois qu'une Function est déployée à l'intérieur d'une application, le commerçant la configure depuis l'administration sans toucher du code. Comme Shopify l'a dit lors du lancement des Functions, « les utilisateurs finaux commerçants n'auront jamais à toucher une ligne de code pour modifier leurs personnalisations. » Le code est écrit une fois ; les paramètres vivent dans l'administration.

Pourquoi « migrer mon Script » est-il vraiment trois migrations séparées?

Voici le détail qui surprend les gens, et il vient directement de comment les commerçants décrivent le travail sur les forums de la communauté Shopify. Un fichier Script unique pourrait toucher la remise, l'expédition et la logique de paiement à la fois. Les Functions divisent délibérément cela en types de Function séparés et indépendants.

• Logique de remise (tarification échelonnée, BOGO, remises de commande et de produit, règles d'empilement) correspond à la Discount Function API. L'API Discount Function unifiée de Shopify peut appliquer des économies dans les trois classes de remise, produit, commande et expédition, à partir d'une seule fonction.
• Logique d'expédition et de livraison (renommage, réorganisation ou masquage des options de livraison) correspond à l'API Delivery Customization Function, une fonction complètement séparée.
• Logique de paiement (renommage, réorganisation ou masquage des méthodes de paiement) correspond à l'API Payment Customization Function, une troisième fonction séparée.

Donc la phrase « Je dois migrer mon Script » signifie souvent migrer jusqu'à trois choses différentes, configurées et déployées indépendamment. Une application de remise sans codage peut reconstruire le premier compartiment. Elle ne touche pas aux compartiments d'expédition et de paiement, ce qui est exactement pourquoi vous devez inventorier votre ancien Script avant d'assumer qu'un seul outil le couvre. Divisez d'abord le travail par surface, puis choisissez un chemin pour chaque surface.

IMAGE PLACEHOLDER (Image 2): One Script becomes three Functions

Suggested visual: A 16:9 diagram. On the left, a single labeled box "One Shopify Script (Ruby)" in slate. Three arrows fan out to the right to three separate boxes: "Discount Function" in violet, "Delivery Function" in gold, "Payment Function" in slate-blue, each with a small "deployed independently" caption. Clean flat vector, brand colors violet and gold, no photography.

Le danger de l'échec silencieux et comment le tester

C'est la partie qui coûte de l'argent réel aux commerçants, et elle mérite sa propre section parce qu'elle s'applique à la fois à la date limite elle-même et à chaque règle que vous reconstruisez.

Une Shopify Function est soit bien formée et en cours d'exécution, soit mal configurée et silencieuse. Il n'y a pas d'état intermédiaire visible. Une Function dont les conditions ne correspondent pas à un panier donné ne se déclenche pas, n'échoue pas et ne vous alerte pas. C'est par conception : le même silence que vous obtenez d'une Function fonctionnant correctement (elle a correctement rien fait pour un panier qui ne devrait pas se qualifier) est le silence que vous obtenez d'une Function brisée (une typo dans un seuil, une règle limitée à la mauvaise collection, un niveau qui ne se déclenche jamais).

Les commerçants qui traversent cette migration décrivent la même expérience sur les forums de la communauté Shopify : une règle cesse silencieusement d'appliquer une remise, et le commerçant ne le découvre que parce qu'un client se plaint d'avoir été facturé au prix complet. Pas d'erreur, pas d'alerte, rien dans les journaux de commandes. Le magasin avait fonctionné sur une configuration brisée pendant des semaines avant que quelqu'un le remarque.

La seule défense fiable est de tester les deux sens avant de faire confiance à une règle en direct :

1. Créez un panier doit-se-déclencher. Assemblez un panier réel qui répond à chaque condition de la règle, passez une commande brouillon ou de test et lisez le résumé du paiement ligne par ligne. Confirmez que la remise exacte que vous attendez est présente, au montant auquel vous vous attendez.
2. Créez un panier ne-devrait-pas-se-déclencher. Assemblez un panier qui ne se qualifie délibérément pas, par exemple un article en dessous de votre seuil de quantité, et confirmez que la remise reste correctement désactivée.

Une Function qui se déclenche quand elle ne devrait pas coûte tout autant qu'une qui ne se déclenche jamais silencieusement. Vous n'avez pas terminé les tests jusqu'à ce que vous ayez vu la règle à la fois s'appliquer et se décliner correctement. Exécutez également le panier doit-se-déclencher via Shop Pay, afin de confirmer que le chemin accéléré s'accorde avec le paiement standard.

Une autre étape de préservation pendant que vous êtes ici : gardez votre source de Script ancien maintenant. Une fois que l'Éditeur de Scripts est pleinement retraité, son code stocké devient irrécupérable auprès de Shopify. Exportez ou copiez votre source de Script aujourd'hui, même si vous n'êtes pas prêt à la reconstruire, pour que vous ayez une référence pour tout ce qui la remplace.

Une application sans codage peut-elle migrer mes Scripts? Ce qu'elle couvre et ce qu'elle ne couvre pas

Pour la surface de remise spécifiquement, une application Functions sans codage peut absorber une grande part de ce que les commerçants utilisaient les Scripts pour. Si la logique de votre Script se réduit à des règles, c'est-à-dire « quand le panier ressemble à X, appliquez la remise Y », une application pilotée par la configuration peut généralement le reconstruire sans développeur. Cela couvre beaucoup de terrain commun :

• Remises échelonnées et volumétriques, comme « achetez 3 ou plus, économisez 15 pour cent. »
• Logique Buy X Get Y et BOGO, y compris les niveaux répétés comme « achetez 6 obtenez 2, achetez 9 obtenez 3. »
• Règles d'empilement et de combinaison explicites entre les offres.
• Début programmé, fin et pause instantanée sur une campagne.

Ce qu'une application de remise sans codage ne peut pas faire est tout aussi important à dire clairement, parce que supposer le contraire est comment les migrations échouent silencieusement :

• Code personnalisé arbitraire. Si votre Script exécutait une formule de tarification unique ou une condition ponctuelle qui ne se réduit pas à une règle que n'importe quel générateur expose, aucune application de remise ne peut l'exprimer. Cette logique a toujours besoin d'un développeur pour écrire une Function personnalisée.
• Personnalisations d'expédition et de paiement. Ce sont des types de Function séparés (livraison et paiement). Une application uniquement de remise ne les atteint pas. Un développeur les migre indépendamment.
• Tout ce qui sort de la configuration de remise basée sur les règles. Si ce n'était pas fondamentalement « conditions entrantes, remise sortante, » un écran de configuration est la mauvaise forme pour cela.

Le test honnête est simple : écrivez une phrase décrivant ce que chaque morceau de votre ancien Script faisait. Si la phrase est une règle sur les remises, une application sans codage est un candidat solide. Si c'est une formule, un changement d'expédition, un changement de paiement ou quelque chose que vous ne pouvez pas exprimer comme une règle, budgétisez un développeur pour cette pièce.

Exécutez cette migration de manière fiable avec Stackable

Si la logique de remise de votre Script était basée sur les règles, les niveaux, BOGO, l'empilement et la planification, Stackable reconstruit exactement cette surface sur Shopify Functions natif sans code, et c'est honnête sur ses limites.

• Il reconstruit la logique de remise basée sur les règles, y compris la tarification volumétrique et échelonnée, BOGO, l'empilement de remise explicite, et le début programmé, la fin et la pause, comme configuration que vous modifiez dans l'administration plutôt que Ruby que vous maintenez.
• Le calcul s'exécute à l'intérieur d'une Shopify Function, donc le panier, le paiement et Shop Pay calculent un total identique. Il n'y a pas de dérive thème-versus-paiement, ce qui est un mode d'échec courant des anciennes configurations de remise.
• Un simulateur de panier vous permet d'exécuter un panier doit-se-déclencher et ne-devrait-pas-se-déclencher avant de passer en direct, donc vous attrapez une méconfiguration silencieuse dans un aperçu au lieu d'une plainte de client.
• C'est honnête sur la portée. Stackable ne s'exécute pas sur du code personnalisé arbitraire et ne touche pas aux personnalisations d'expédition (livraison) ou de paiement. La logique véritablement unique et ces deux types de Function séparés ont toujours besoin d'un développeur.

Installez Stackable gratuitement et reconstruisez vos règles de remise sur Shopify Functions avant qu'elles ne vous coûtent discrètement une vente, sur usestackable.com/pricing. 🚀

Exemple travaillé : une liste de contrôle de migration que vous pouvez suivre aujourd'hui

Utilisez cette séquence pour transformer « mon Script s'est cassé » en migration contrôlée. Le tableau mappe un Script multi-objectif typique vers ses destinations.

Ensuite, travaillez les étapes dans l'ordre :

1. Inventoriez l'ancien Script avant de construire quoi que ce soit

Ouvrez l'Éditeur de Scripts pendant que vous le pouvez toujours et écrivez une phrase par comportement. Exécutez le rapport de personnalisations Scripts de Shopify pour confirmer que rien ne se cache. Exportez la source Ruby et stockez-la quelque part de sûr, parce qu'elle devient irrécupérable une fois que l'éditeur est retraité.

2. Divisez l'inventaire par surface

Triez chaque comportement en remise, expédition ou paiement. Cela vous dit immédiatement quels éléments une application de remise sans codage peut prendre et quels éléments ont besoin d'un développeur. Ne supposez pas qu'un seul outil couvre les trois.

3. Reconstruisez les pièces de remise basées sur les règles sans code

Pour chaque comportement qui se réduit à « conditions entrantes, remise sortante, » recréez-le dans les remises Shopify natives ou une application Functions basée sur les remises. Définissez explicitement les règles de combinaison si les offres sont censées s'empiler.

4. Confiez les pièces non-règles à un développeur

Les formules uniques, les personnalisations de livraison et les personnalisations de paiement vont à un développeur ou une agence pour construire comme leurs propres Functions. Donnez-leur votre source de Script exportée comme spécification.

5. Testez chaque règle reconstruite dans les deux sens

Pour chaque règle, exécutez un panier doit-se-déclencher et un panier ne-devrait-pas-se-déclencher. Lisez le résumé du paiement ligne par ligne. Une règle n'est pas migrée jusqu'à ce que vous l'ayez vue à la fois s'appliquer et se décliner correctement.

6. Vérifiez les paiements accélérés

Exécutez votre panier doit-se-déclencher via Shop Pay. Parce que les Functions calculent côté serveur, une règle correctement construite s'applique de manière identique. C'est votre dernière vérification que rien ne dépend du code thème que les portefeuilles ignorent.

IMAGE PLACEHOLDER (Image 3): Test both directions before you trust it

Suggested visual: A 16:9 split illustration. Left panel labeled "Should-fire cart" shows a checkout summary with a green discount line correctly present. Right panel labeled "Shouldn't-fire cart" shows a checkout summary with the discount correctly absent and a green checkmark. A center caption reads "A silent rule never errors - test both." Brand colors violet and gold, flat vector, no photography.

L'essentiel

• Shopify Scripts cessent de s'exécuter le 30 juin 2026, et l'édition s'est déjà terminée le 15 avril 2026. Tout Script encore utilisé est maintenant hors ligne.
• L'échec est silencieux. Un Script qui s'est arrêté, ou une règle migrée qui ne correspond pas à un panier, n'échoue jamais et ne vous avertit jamais. Cela facture simplement le prix complet.
• Les Functions sont le remplacement, s'exécutant côté serveur à l'intérieur du paiement, mais l'écriture d'une à partir de zéro est une tâche pour développeurs, et les Functions personnalisées sont un chemin réservé à Plus.
• Un Script devient souvent trois migrations : remise, livraison et paiement Functions, chacun déployé indépendamment.
• Une application Functions sans codage peut reconstruire une logique de remise basée sur les règles (niveaux, BOGO, empilement, planification). Elle ne peut pas faire du code arbitraire, de l'expédition ou des personnalisations de paiement.
• Gardez votre ancienne source de Script maintenant. Elle devient irrécupérable une fois que l'Éditeur de Scripts est retraité.
• Testez chaque règle reconstruite avec un panier doit-se-déclencher et un panier ne-devrait-pas-se-déclencher, et lisez le résumé du paiement ligne par ligne, y compris via Shop Pay.

Articles connexes

• Migration depuis Shopify Scripts: le chemin de sauvetage complet, ce qui se reconstruit sans code et ce qui a toujours besoin d'un développeur.
• Comment fonctionne l'empilement de remise dans Shopify: pourquoi native applique uniquement la remise la plus élevée et comment combiner correctement les offres.
• Remises volumétriques et ruptures de quantité: reconstruisez la tarification échelonnée qui compte le même produit, pas la collection entière.
• Empilement de remise, fait correctement: les trois interrupteurs de combinaison par classe, avec un simulateur de panier en direct.
• La limite de 100 produits de Shopify sur Buy X Get Y: exécutez 3-pour-2 sur un catalogue complet après la migration.
• Tarification Stackable: plans, le niveau gratuit et ce que chacun inclut.