Pourquoi les remises Shopify échouent dans la mode

Pour de nombreuses boutiques en ligne, une remise est une campagne temporaire. Dans la mode, les promotions peuvent faire partie des opérations quotidiennes. De nouvelles collections arrivent chaque semaine, les exclusions changent d’une campagne à l’autre et le même prix doit être correct sur le site, en caisse, dans les applications et dans les flux publicitaires.

À ce stade, calculer 20 % de remise n’est plus le plus difficile. La vraie question est la suivante : quel système est propriétaire du prix, quand le modifie-t-il et quels autres systèmes écrivent dans le même champ ?

Nous avons rencontré cette situation chez un détaillant de mode néerlandais utilisant Shopify Plus. Environ 3 900 variantes actives étaient publiées sur huit canaux de vente, tandis que les promotions étaient presque permanentes. Pris séparément, les outils standard fonctionnaient comme prévu. Ensemble, ils formaient un processus tarifaire devenu impossible à gérer de manière fiable.

Une promotion, huit endroits où le prix doit correspondre

Le même catalogue alimentait la boutique Shopify, la caisse physique, un storefront headless, une application mobile, Facebook et Instagram, TikTok, ainsi que Google et YouTube.

Tous ces canaux ont besoin d’un prix produit clair. Une remise appliquée uniquement dans le panier ou dans le thème ne résout donc qu’une partie du problème. Google Merchant Center compare le prix du flux à celui de la page de destination et peut refuser un produit en cas d’écart. Ce ne sont pas seulement les chiffres visibles sur le site qui doivent être corrects : les données produit sous-jacentes doivent l’être également.

Pour les enseignes disposant de magasins physiques, la caisse ajoute une dépendance supplémentaire. Des règles distinctes par canal semblent flexibles, mais rendent plus difficile l’identification du prix réellement applicable.

Les limites de l’approche standard

Shopify Launchpad est conçu pour des événements planifiés : soldes, lancements de produits ou mises en stock. Il peut modifier les prix au début et à la fin d’un événement. Ce modèle est logique pour une campagne courte sur un catalogue stable.

Ce détaillant fonctionnait à l’inverse : remises presque permanentes, nouveaux articles chaque semaine et exclusions changeantes. Trois hypothèses du modèle événementiel se heurtaient aux opérations quotidiennes.

Les nouveaux produits échappaient à la promotion

Les articles ajoutés pendant une campagne ne recevaient pas automatiquement la même remise. Chaque livraison exigeait un nouvel événement et une nouvelle mise à jour de l’ensemble du catalogue. Entre le 8 et le 22 juillet, six événements ont été nécessaires, parfois espacés de seulement sept minutes. La planification commerciale était devenue de la maintenance de catalogue.

Les changements manuels étaient annulés

Lorsqu’un employé modifiait un prix pendant un événement actif, l’état initial enregistré pouvait ensuite écraser ce changement. Une robe volontairement affichée à 12,99 € revenait à 7,99 € le lendemain matin.

Faute de journal de modification exploitable, nous avons dû reconstituer la chronologie à partir des lignes de commande. Ce n’est pas un processus viable pour une boutique qui gère chaque jour nouveautés et démarques.

Les exclusions entraient en conflit avec la navigation

Les campagnes reposaient sur des tags et des collections. Dans cette configuration, retirer un article de la promotion pouvait aussi le faire disparaître de la navigation.

La demande métier était simple : exclure les manteaux d’hiver de la remise de 20 % tout en les laissant visibles dans leur collection. Le merchandising et la logique promotionnelle étaient trop étroitement liés.

Ajouter une application de remise a aggravé le problème

Quand le premier outil manque de souplesse, en ajouter un deuxième paraît logique. Mais si les deux modifient le même champ de prix, un problème plus profond apparaît : deux systèmes qui ne savent rien l’un de l’autre.

Une application supplémentaire a calculé sa remise à partir de prix déjà réduits par Launchpad. Dix-neuf articles se sont retrouvés à -36 % au lieu de -20 %. Lors de sa désinstallation, l’application n’a restauré que 18 variantes sur 3 382.

Ce n’est pas une case manquante dans les paramètres. Le modèle tarifaire n’a plus de propriétaire clair.

Les remises au panier et le code du thème présentent une limite similaire. Ils peuvent corriger la boutique ou le checkout, mais ne mettent pas automatiquement à jour le prix source utilisé par la caisse, l’application et les flux produits. Le site peut sembler correct alors qu’un autre canal affiche toujours le mauvais montant.

Inverser le modèle de prix

Le développement sur mesure n’a pas commencé par un nouvel outil de remise, mais par une règle simple :

L’équipe gère le prix de vente normal. Le logiciel calcule le prix promotionnel.

Les deux champs de prix Shopify ont reçu des rôles distincts :

• compare_at_price contient le prix de vente normal et reste géré par les employés ;
• price contient le prix promotionnel actuel et est calculé par l’automatisation.

Comme le résultat est écrit dans le véritable champ de prix Shopify, le site, le POS, les applications et les flux utilisent tous le même montant. Il n’y a plus de moteur promotionnel séparé pour chaque canal.

Les règles sont configurées directement dans l’interface d’administration Shopify : type de remise, pourcentage ou montant fixe, tags inclus et tags exclus. Elles suivent le principe « tout le catalogue sauf ces exceptions ». Les nouveaux produits participent donc automatiquement. Si deux promotions se chevauchent, le prix le plus bas l’emporte.

Le tag PRIJS-VAST sert de frein d’urgence pour les articles qui doivent conserver un prix manuel. Au moment de la migration, 170 produits utilisaient cette exception.

Une petite architecture pour un impact opérationnel important

Techniquement, l’automatisation repose sur un webhook Shopify, une file d’attente et une petite fonction AWS. Après chaque modification produit, la fonction recalcule le prix et n’écrit que si le résultat a réellement changé.

Il n’y a ni base de données, ni scan périodique du catalogue, ni serveur actif en permanence. Avec environ 1 500 webhooks par jour, le coût d’infrastructure reste inférieur à un euro par mois.

Le faible coût est appréciable, mais la vraie valeur réside dans un modèle que les employés comprennent et auquel ils peuvent faire confiance :

• les modifications manuelles restent intactes ;
• les nouveaux produits rejoignent automatiquement la bonne promotion ;
• les exceptions restent visibles dans leurs collections ;
• tous les canaux reçoivent le même prix actuel ;
• le détaillant active ou désactive ses campagnes sans développeur.

De 22 minutes à 5 minutes et 12 secondes

La migration était la partie la plus risquée. La fin de l’ancien événement Launchpad faisait temporairement revenir le catalogue au plein tarif et disparaître les prix barrés. Chaque minute était visible par les clients.

Nous avons donc mesuré au lieu d’estimer. La lecture du catalogue a pris 4,2 secondes et l’écriture a dépassé vingt produits par seconde. Le retour arrière a été testé en altérant volontairement un produit avant de le restaurer. Le flux complet a ensuite été validé sur cinq brouillons non publiés. Les cinq ont réagi comme prévu et un second passage n’a écrit aucune modification, prouvant que l’automatisation ne se déclenchait pas en boucle.

Le 3 août 2026, la migration en production a commencé à 14 h 48 min 22 s. À 14 h 53 min 34 s, tout le catalogue était à nouveau correct. La période visible sans remise a duré 5 minutes et 12 secondes.

Le contrôle final a confirmé :

• 3 933 variantes correctes sur 3 933 ;
• aucun écart ;
• aucune variante sans prix de comparaison ;
• contre 22 minutes sans remise lors de la précédente conversion manuelle.

Le code était limité. Identifier ce qu’il fallait construire, comprendre les interactions entre les outils existants et prouver une migration sûre représentait l’essentiel du travail.

Quand revoir le modèle tarifaire d’une enseigne de mode ?

Toutes les boutiques de mode n’ont pas besoin de développement sur mesure. Une fonction standard suffit généralement pour une promotion temporaire, un catalogue stable et un canal principal.

Le modèle mérite d’être réexaminé lorsque plusieurs conditions se cumulent :

• les promotions fonctionnent presque en permanence ;
• de nouveaux produits arrivent pendant les campagnes ;
• les exclusions changent selon la collection ou la semaine ;
• les employés ajustent aussi les prix manuellement ;
• les produits sont vendus via le site, le POS, des apps et des flux ;
• plusieurs applications ou scripts modifient le même champ ;
• personne ne peut dire avec certitude quel système détermine le prix final.

Ne commencez pas par comparer les listes de fonctionnalités des applications. Commencez par trois questions de propriété :

1. Quel système possède le prix normal ?
2. Quel système peut calculer et écrire le prix promotionnel ?
3. Comment chaque canal reçoit-il le même résultat sans écraser un autre système ?

Ce n’est qu’ensuite que vous pourrez choisir correctement entre application standard, automatisation et développement sur mesure.

Les règles européennes exigent une couche distincte

Dans l’Union européenne, une réduction annoncée doit généralement utiliser comme prix antérieur le prix le plus bas pratiqué au cours des 30 jours précédents. Cela exige un historique fiable, et pas seulement un champ de prix barré renseigné.

L’automatisation de ce projet maintient les prix actuels cohérents sur tous les canaux. Elle ne conserve pas un historique complet sur 30 jours et ne garantit donc pas, à elle seule, le respect de la réglementation européenne sur les prix. L’enregistrement historique et l’évaluation juridique restent des besoins séparés.

Des prix techniquement cohérents et des prix de référence juridiquement corrects sont liés, mais ce ne sont pas le même problème.

Utiliser le standard tant qu’il convient

Launchpad et les applications de remise ne sont pas de mauvais produits parce qu’ils n’ont pas résolu ce cas. Ils ont été conçus autour d’autres hypothèses : campagnes temporaires, catalogue stable et une seule couche de remise.

Les détaillants de mode avec des promotions permanentes, des collections qui changent vite et plusieurs canaux peuvent dépasser ces hypothèses. Ajouter une application supplémentaire rétablit rarement la maîtrise. Il faut d’abord cartographier le parcours des prix, puis construire uniquement la partie manquante.

C’est là que Duxly intervient. Les intégrations standard existent déjà. Lorsque le standard ne suffit plus, nous développons la couche sur mesure qui fiabilise l’ensemble.

Découvrez aussi nos guides sur Shopify POS pour la mode et les meilleures applications Shopify pour le e-commerce de mode, ou consultez notre expertise Shopify.

Plusieurs applications, canaux et exceptions se disputent-ils le contrôle de vos prix ? Planifiez un échange technique. Nous déterminerons d’abord quel système doit posséder chaque prix.

Sources

• Centre d’aide Shopify : Launchpad
• Google Merchant Center : prix du produit incohérent
• Commission européenne : authenticité des réductions de prix