Les Shopify Scripts cessent de fonctionner le 30 juin. Si vous n'êtes pas passé aux Functions, le checkout casse.

Si votre boutique fait tourner la moindre logique personnalisée au checkout, il y a une date à afficher au mur : le 30 juin 2026. C'est le jour où les Shopify Scripts cessent de s'exécuter. Pas déprécié-mais-encore-boiteux. Arrêté. Quelle que soit la règle de remise, de livraison ou de paiement que vous avez construite dans un Script, elle ne tourne tout simplement plus après cette date.

Ce qui prend les gens de court ici, c'est que rien de spectaculaire ne se produit. Pas de page d'erreur, pas de bandeau d'avertissement, pas d'e-mail le matin venu. La remise que vous attendiez ne s'applique simplement pas. Le client B2B censé contourner les conditions de paiement ne le peut soudain plus. Vous l'apprenez par un ticket de support ou en jetant un œil perplexe aux chiffres du jour, ce qui est la pire façon de l'apprendre.

Si vous avez déjà migré, vous pouvez fermer cet onglet. Si vous n'êtes pas certain d'avoir migré, c'est précisément cette incertitude qu'il vaut la peine de lever ce mois-ci. Voici ce qui change réellement et comment cadrer le travail sans paniquer.

Deux dates, et la seconde est le précipice

Il y a deux échéances, et il est facile de les confondre. La première est déjà passée. Le 15 avril 2026, Shopify a verrouillé le Script Editor. Vous ne pouvez plus écrire de nouveau Script ni en modifier un existant. Ceux que vous aviez ont continué de tourner, donc pour beaucoup de boutiques rien n'a visiblement changé et l'échéance a glissé hors des radars.

La seconde date, c'est celle qui mord. Le 30 juin 2026, chaque Script cesse de s'exécuter. Cette échéance a déjà été repoussée une fois, depuis août 2025, d'où la tentation de supposer qu'elle glissera encore. Planifiez comme si ce n'était pas le cas. Une seconde prolongation serait une bonne surprise, pas une stratégie.

Un détail rend la transition plus facile qu'il n'y paraît : Scripts et Functions peuvent tourner côte à côte jusqu'à la date butoir. Vous n'avez pas à tout basculer en un week-end. Vous pouvez reconstruire une règle en Function, la tester face au Script qu'elle remplace, confirmer son comportement, puis passer à la suivante. L'horloge est la seule chose qui impose le rythme.

Ce qui casse vraiment

Les Scripts portaient la logique de checkout qui ne tient pas dans les réglages standard de Shopify. Si vous êtes un marchand Plus, une partie est probablement porteuse pour votre chiffre d'affaires. Les catégories qui s'éteignent le 30 juin :

• Remises. Promotions automatiques, tarification par paliers et par volume, achetez-X-recevez-Y, règles au niveau du panier. Si un Script décide qui obtient quelle remise, cette décision cesse d'être prise.
• Livraison. Logique de tarifs personnalisée, masquage ou réordonnancement des méthodes, règles liées au contenu du panier ou à la destination. Le Script qui faisait remonter le bon tarif disparaît, et les clients voient ce qu'il reste.
• Paiements. Filtrage ou renommage des modes de paiement, masquage de certaines options pour certains paniers. Quand le Script s'arrête, le filtrage s'arrête, et les options que vous aviez masquées réapparaissent.
• B2B et restrictions. Règles de vente en gros construites sur les tags clients, limites de quantité, restrictions de produits, blocage par région. C'est la catégorie la plus susceptible de cacher une règle que personne ne se souvient avoir écrite.

Le mode de défaillance qui devrait vous inquiéter n'est pas la remise qui s'arrête en silence, vous coûtant quelques conversions. C'est la restriction qui s'arrête en silence. Un plafond de quantité qui laisse quelqu'un vider votre stock, un blocage régional qui laisse passer une commande que vous ne pouvez pas honorer, un filtre de paiement qui rouvre une méthode coupée pour des raisons de fraude. Celles-là ne vous font pas perdre une vente. Elles créent un désordre que vous nettoyez plus tard.

Les Functions sont le remplacement, et ce ne sont pas juste des Scripts rebaptisés

Les Shopify Functions sont ce vers quoi vous migrez. Techniquement, c'est une vraie montée en gamme. Les Scripts étaient du Ruby réservé à Plus tournant dans un bac à sable ; les Functions se compilent en WebAssembly et tournent sur l'infrastructure cœur de Shopify, donc elles sont plus rapides et se comportent de façon plus prévisible sous charge. Pour un fondateur, la vitesse n'est pas l'essentiel. Deux autres choses le sont.

D'abord, les Functions sont livrées dans des apps. Cela signifie qu'une part de logique qui demandait à un développeur de coller du Ruby dans un éditeur peut désormais venir d'une app de l'App Store que vous installez et configurez. Ensuite, comme elles vivent dans des apps, les Functions ne sont pas réservées à Plus. Les boutiques sur des plans inférieurs ont accès à la même personnalisation du checkout qui était autrefois un avantage Plus, ce qui change discrètement ce qui est possible pour les plus petits marchands.

Shopify a aussi intégré certains cas courants directement dans la plateforme. Les remises BOGO et par volume qui demandaient autrefois un Script peuvent maintenant être configurées dans les réglages de remises, sans aucune app. Donc avant de supposer que vous devez reconstruire quoi que ce soit, il vaut la peine de vérifier ce qui est devenu natif, car la migration la moins chère, c'est la règle que vous n'avez pas à reconstruire.

Comment cadrer la migration sans deviner

Shopify vous fournit un rapport de personnalisations Scripts qui liste vos Scripts actuels et signale lesquels correspondent à une fonctionnalité native ou à une app publique. Lancez-le en premier. Il transforme un vague "on a des Scripts quelque part" en une vraie liste, et pour beaucoup de boutiques il montrera que la moitié du travail est un changement de réglage, pas un développement.

Ce que le rapport ne peut pas faire à votre place, c'est la raison pour laquelle cela prend des semaines plutôt qu'un après-midi. Vos Scripts encodent des décisions commerciales qui n'ont jamais été couchées par écrit : le client qui bénéficie d'un tarif spécial à cause d'un accord conclu il y a deux ans, le plafond de quantité ajouté après une mauvaise semaine de traitement des commandes, la région que quelqu'un a bloquée pour une raison que personne n'arrive à reconstituer. Le Ruby vous dit ce que la règle fait. Il ne vous dit pas pourquoi, ni si elle devrait encore exister. Migrer est l'occasion de reconstruire les règles que vous voulez encore et d'abandonner celles qui rapiéçaient des problèmes que vous n'avez plus.

Un ordre des opérations sensé : sortez le rapport, classez chaque Script en natif / app publique / Function sur mesure nécessaire, puis traitez les développements sur mesure tant qu'il reste de la marge pour les tester face à de vrais paniers. Gardez les Functions sur mesure pour le dernier week-end de juin et vous déboguerez la logique de checkout sans aucune marge, soit exactement le moment où un cas limite oublié se transforme en remboursements.

Si votre logique de checkout est simple, c'est un petit chantier que vous pouvez mener vous-même à partir du rapport. Si vous êtes une boutique Plus avec des années de Scripts accumulés et de l'argent réel qui transite par eux, traitez ça comme un projet avec un responsable et une échéance, pas comme une tâche dont quelqu'un s'occupera un jour. L'échéance n'est pas négociable, l'échec est silencieux, et l'écart entre "on s'en occupe" et "le checkout fait un truc bizarre" tient à une seule date du calendrier. Mieux vaut passer une semaine en juin qu'un mois de juillet à nettoyer.