La remise de fidélité apparaît bien. La livraison express est toujours proposée. Le paiement passe. Après l’arrêt de Shopify Scripts, ces trois voyants au vert ont pu suffire pour clore le projet.
Mais six semaines plus tard, qui possède la nouvelle logique ? Quelle application porte la remise ? Quel composant masque un moyen de paiement ? Où surveille-t-on l’échec d’une synchronisation de stock ? Et qui lit les annonces Shopify marquées « Action required » ?
Shopify a désactivé le 30 juin 2026 les Scripts encore publiés. La migration vers Shopify Functions était donc un passage obligatoire pour les boutiques concernées. Elle n’a toutefois pas supprimé leurs dépendances : elle les a déplacées vers des Functions, des applications, des extensions de checkout, des automatisations et des intégrations externes.
Le contrôle utile maintenant n’est pas un nouveau bilan nostalgique de Scripts. C’est une radiographie de ce qui fait réellement fonctionner la vente.
Reconstituer une commande sans ouvrir la liste des applications
La page « Applications » de l’administration est un mauvais point de départ. Elle mélange outils critiques, fonctions secondaires, essais oubliés et connecteurs dont le nom ne révèle pas l’effet.
Partez plutôt d’une commande réelle et suivez six décisions :
- quel prix et quelle remise sont présentés ;
- quels modes et tarifs de livraison sont proposés ;
- quelles règles autorisent ou bloquent le checkout ;
- quels paiements sont affichés ;
- où partent la commande et le stock ;
- quels événements alimentent la mesure et le marketing.
Pour chaque décision, inscrivez le mécanisme qui l’exécute : fonction Shopify, application publique, application personnalisée, extension de checkout, Shopify Flow, thème, pixel, webhook ou service externe.
Cette cartographie révèle les zones où deux outils interviennent sur le même résultat. Une application de promotion peut calculer une remise tandis qu’une autre affiche son message. Un connecteur logistique peut fournir le tarif, mais une Function réordonne les modes de livraison. Un parcours qui semble natif peut donc dépendre de plusieurs propriétaires et de plusieurs calendriers de mise à jour.
Après Scripts, vérifier le résultat et sa provenance
Shopify indique que les anciens Scripts publiés ont été désactivés et oriente leurs usages vers plusieurs API de Functions : remises, transformation du panier, validation du panier et du checkout, personnalisation de la livraison ou des paiements.
Deux boutiques ayant remplacé un même Shipping Script peuvent ainsi avoir choisi des architectures différentes. L’une utilise une application de l’App Store ; l’autre une application personnalisée avec une Function. Cette différence compte pour le support, les droits d’accès et la maintenance.
Rejouez les règles héritées avec des cas qui les déclenchent vraiment :
- client VIP connecté et visiteur anonyme ;
- montant juste avant, puis juste après un seuil ;
- code promotionnel compatible puis incompatible ;
- panier contenant un lot, un cadeau ou une exclusion ;
- adresse française standard, Corse, outre-mer ou pays réellement desservi ;
- livraison gratuite, point relais et produit hors gabarit ;
- carte cadeau, portefeuille express et moyen de paiement conditionnel.
Pour chaque résultat, notez aussi son origine. « La remise fonctionne » ne suffit pas si personne ne sait quelle app la calcule ni comment la désactiver proprement.
Notre contrôle post-bascule détaillé reste disponible dans l’article Shopify Scripts est coupé : vérifier les remises, livraisons et paiements. Ici, l’objectif est différent : construire une méthode durable pour les prochaines évolutions.
Le checkout : surveiller les règles qui bloquent autant que celles qui affichent
Une extension peut ajouter un bloc visible au checkout. Elle peut aussi appliquer une règle métier moins perceptible : refuser un panier, contrôler une adresse, filtrer un paiement ou modifier une option de livraison.
Le changelog Shopify du 2 juillet 2026 illustre pourquoi l’inventaire est indispensable. Shopify y déprécie useBuyerJourneyIntercept et la capacité block_progress pour les extensions de checkout à partir de la version 2026-07. Les extensions existantes continuent de fonctionner sur leurs versions actuelles et antérieures, mais Shopify demande de planifier la migration ; pour des règles métier, la recommandation vise notamment les Functions de validation du panier et du checkout.
Cela ne signifie pas que chaque boutique doit développer une nouvelle Function. Cela signifie qu’un marchand doit pouvoir répondre à trois questions :
- une extension actuelle utilise-t-elle ce mécanisme ?
- l’éditeur de l’application a-t-il annoncé son plan de migration ?
- comment prouver que la règle fonctionne sur tous les parcours concernés, y compris les portefeuilles express ?
Demandez aux éditeurs des réponses datées, pas seulement un badge « compatible Shopify ». Conservez le ticket, la version de l’app et la date du prochain test.
Applications : attribuer un propriétaire et une solution de sortie
Une application critique sans propriétaire interne devient un abonnement que personne n’ose toucher. Ajoutez quatre colonnes à l’inventaire :
| Dépendance | Effet métier | Propriétaire | Sortie prévue |
|---|---|---|---|
| App de remise | Prix final et marge | Responsable e-commerce | Désactivation testée, règle de remplacement documentée |
| Livraison / point relais | Choix transporteur et étiquette | Logistique | Mode standard de secours et procédure manuelle |
| Connecteur ERP | Stock, commandes, statuts | Opérations / IT | File d’erreurs, reprise et export de secours |
| Pixel ou app marketing | Attribution et audiences | Marketing | Mesure de référence et consentement vérifié |
| Function personnalisée | Validation ou transformation | Prestataire / équipe technique | Dépôt, accès, documentation et rollback |
La « sortie prévue » n’impose pas de remplacer l’outil. Elle décrit ce qu’il faut faire si l’application change de prix, perd une fonction, n’est plus maintenue ou entre en conflit avec une évolution de plateforme.
Vérifiez également les accès. Une application personnalisée dépend-elle du compte d’un ancien prestataire ? Le dépôt et les secrets sont-ils contrôlés par l’entreprise ? Le support sait-il quel environnement correspond à la production ? Pour une boutique e-commerce conçue pour durer, cette propriété opérationnelle compte autant que l’apparence du thème.
API et changelog : transformer les annonces en décisions
Shopify publie régulièrement des changements ciblant l’Admin API, Storefront API, Customer Account API, Functions, checkout, webhooks, Flow ou les extensions. Certains sont signalés « Action required » ; d’autres annoncent une dépréciation ou une rupture dans une version future.
Une PME n’a pas besoin de lire chaque ligne comme un développeur de plateforme. Elle a besoin d’un circuit de tri :
- relever les surfaces utilisées par la boutique ;
- filtrer le changelog sur ces surfaces ;
- transmettre l’annonce au propriétaire de l’app ou de l’intégration ;
- obtenir une conclusion : non concerné, à surveiller, mise à jour prévue ou test requis ;
- conserver l’échéance et la preuve de clôture.
Le 7 juillet 2026, Shopify a par exemple expliqué une évolution de Shopify Flow : les anciens workflows utilisant une action peuvent continuer à envoyer une charge utile correspondant à une ancienne configuration, et le serveur du partenaire doit savoir gérer les champs manquants, supplémentaires ou inattendus. Pour un marchand, la question n’est pas d’implémenter ce traitement lui-même. Elle est de savoir quelles automatisations envoient des données à un service tiers et qui vérifie leur bonne exécution.
Le signal d’alerte n’est donc pas seulement « une API disparaît ». C’est aussi « personne ne sait si nous l’utilisons ».
Mesure, pixels et consentement : contrôler les trous silencieux
Une remise cassée se voit souvent au panier. Une rupture de mesure peut rester invisible pendant plusieurs semaines.
Après un changement d’application, de thème ou de checkout, comparez quelques indicateurs simples :
- commandes Shopify et achats mesurés ;
- chiffre d’affaires par canal avant et après la modification ;
- événements de panier et de checkout ;
- consentement accordé ou refusé et comportement attendu des balises ;
- doublons d’événements ;
- paramètres de campagne conservés ;
- flux produits et audiences qui dépendent d’une app.
Ne cherchez pas une égalité parfaite entre toutes les plateformes. Cherchez une rupture inexpliquée à la date d’un changement. Conservez une capture ou un export de référence avant chaque intervention importante.
Pour une boutique française, le test doit aussi respecter le dispositif de consentement réellement déployé. Faire réapparaître un pixel en contournant ce dispositif n’est pas une correction.
Stocks, commandes et ERP : tester l’aller, le retour et l’erreur
Un connecteur peut réussir à envoyer une commande et échouer à renvoyer un statut, un numéro de suivi ou un stock corrigé. Un audit limité au checkout manquerait alors la moitié du parcours.
Choisissez une commande test et suivez-la jusqu’au bout :
- décrément du stock ;
- transmission à l’ERP, au logisticien ou à la marketplace ;
- génération de l’expédition ;
- retour du suivi ;
- email au client ;
- annulation ou remboursement partiel ;
- remise en stock selon la règle prévue.
Provoquez aussi un incident contrôlé dans un environnement adapté : donnée obligatoire absente, SKU inconnu ou service momentanément indisponible. L’erreur apparaît-elle dans une file consultable ? Une alerte est-elle envoyée ? Peut-on relancer sans créer un doublon ?
Une intégration n’est fiable que si son mode d’échec est connu.
Le registre mensuel qui tient sur une page
L’audit initial peut être détaillé. Le suivi mensuel doit rester léger pour être réellement tenu.
Conservez une page avec :
- dépendances critiques et propriétaires ;
- versions ou surfaces API connues ;
- annonces Shopify ouvertes et échéances ;
- incidents depuis le dernier contrôle ;
- changements d’app, de thème, de Function ou de Flow ;
- cinq scénarios de commande à rejouer ;
- date de la prochaine revue.
Ajoutez un contrôle plus complet avant une période commerciale, un changement de thème, une grosse campagne, l’installation d’une app de checkout ou la mise à jour d’une intégration sur mesure.
Le bon livrable n’est pas une liste d’apps
Un audit Shopify utile doit produire trois éléments :
- une carte reliant chaque résultat métier à ses dépendances ;
- un plan de tests avec résultats attendus ;
- un registre d’actions attribuées, datées et vérifiables.
Il peut conclure que l’architecture actuelle est saine. Il peut recommander de retirer une app redondante, documenter une Function, corriger un connecteur ou demander un calendrier précis à un éditeur. Il ne doit pas déclencher une refonte sans diagnostic.
1Design peut réaliser ce contrôle sur un périmètre borné : remises, livraison, checkout, paiements, applications, automatisations, pixels et connecteurs. L’audit de site et de devis permet de cadrer les priorités ; la gestion technique peut ensuite couvrir les vérifications récurrentes qui ont une vraie valeur.
Pour commencer, contactez 1Design avec trois éléments : la liste des applications, un exemple de commande complexe et le nom des systèmes connectés. Nous reconstituerons d’abord les dépendances qui touchent directement la vente, avant de proposer le moindre chantier.
Vous voulez un site plus clair, plus crédible ou mieux pensé pour convertir ?