E-commerce13 minutes de lecture

Prix barrés e-commerce : construire une promotion prouvable

Appliquez la règle des 30 jours aux prix barrés, reliez variantes et canaux, puis testez chaque promotion avant sa mise en ligne.

Des blocs d’historique de prix passent sous un portique de contrôle avant une offre verte

Un prix barré e-commerce ne doit pas venir d’un champ saisi au dernier moment dans le back-office. En France, lorsqu’un marchand annonce une réduction, le prix antérieur affiché correspond en principe au prix le plus bas qu’il a pratiqué auprès de tous les consommateurs pendant les trente jours précédents. Le pourcentage annoncé doit partir de cette référence.

La difficulté réelle commence dans les données : une variante change de prix, une remise précédente entre dans la fenêtre, le site et le magasin n’appliquent pas le même tarif, ou un code diffusé largement modifie l’historique. La réponse utile consiste à relier offre, variante, canal, prix pratiqué, période, promesse et preuve, puis à bloquer toute promotion qui ne peut pas être reconstruite.

Ce guide propose cette matrice et huit scénarios de recette. Il aide à concevoir le flux ; il ne remplace pas l’analyse juridique de votre campagne.

Quelle règle appliquer à un prix barré ?

L’article L. 112-1-1 du Code de la consommation pose la règle française en vigueur depuis le 28 mai 2022 : toute annonce d’une réduction indique le prix antérieur, défini comme le prix le plus bas pratiqué par le professionnel au cours des trente jours précédents.

La fiche pratique de la DGCCRF mise à jour le 25 août 2026 précise que la règle s’applique en ligne comme en magasin. Le marchand reste libre de présenter la baisse en pourcentage, en montant ou par un prix barré. Cette liberté d’affichage ne change pas la référence utilisée pour calculer la réduction.

Trois distinctions évitent déjà beaucoup d’erreurs.

Une baisse de prix n’est pas toujours une annonce de réduction

Un marchand peut modifier un prix sans nécessairement afficher « promotion », un pourcentage ou une comparaison avec son propre tarif antérieur. La qualification dépend de la présentation complète de l’offre. Dès que le message crée l’impression d’un rabais — prix barré, « offre spéciale », campagne générale ou réduction chiffrée — la règle du prix antérieur doit être examinée.

Ne transformez pas cette distinction en échappatoire éditoriale. Retirer le symbole % tout en conservant une mise en scène de remise peut maintenir l’impression d’une réduction. Le contrôle doit porter sur le contenu visible, pas seulement sur le type technique de la campagne.

Un prix conseillé n’est pas le prix antérieur

Une comparaison avec le tarif d’un fabricant ou avec les prix d’autres professionnels ne relève pas du même mécanisme. La DGCCRF demande alors que la nature de la comparaison soit claire pour le consommateur. Un champ compare_at_price ne suffit donc pas : il faut savoir s’il contient votre propre prix antérieur, un prix conseillé ou une autre référence, puis afficher un libellé qui ne mélange pas ces notions.

Les exceptions doivent être qualifiées, pas supposées

Le Code prévoit notamment un traitement particulier pour les réductions successives pendant une période déterminée, exclut de ce dispositif les produits périssables menacés d’une altération rapide et sépare les comparaisons avec d’autres professionnels. Ces cas ne justifient pas une case générique « exception » accessible à toute l’équipe.

Conservez le motif, la règle validée, la période concernée et la personne qui l’a approuvée. Pour un produit nouveau, une offre personnalisée, un programme de fidélité ou un code largement diffusé, faites vérifier la qualification au lieu d’inventer une durée ou une exemption locale.

À retenir : le système n’a pas seulement besoin d’un ancien prix. Il doit pouvoir expliquer quel prix a été pratiqué, sur quelle variante, dans quel canal, pendant quelle fenêtre et pourquoi cette référence est utilisée.

Pourquoi le back-office se trompe-t-il ?

Beaucoup de boutiques séparent les informations qui devraient rester reliées. Le catalogue conserve le prix courant. Un module de promotion calcule la remise. L’ERP envoie un tarif différent. La caisse du magasin possède son propre historique. Le flux publicitaire reprend une valeur mise en cache. Enfin, l’équipe marketing programme le bandeau et le compte à rebours.

Chaque outil peut fonctionner isolément tout en produisant une promesse incohérente.

Prenons une variante vendue 80 €, puis 70 € pendant trois jours, remontée à 100 € et annoncée à 75 € la semaine suivante. Le dernier prix enregistré avant la campagne est 100 €, mais le prix le plus bas de la fenêtre est 70 €. Une règle fondée sur le dernier tarif, le prix catalogue ou le tarif conseillé calculera une réduction trompeuse.

La même erreur apparaît quand une promotion est préparée au niveau du produit alors que le prix est porté par la variante. Une taille, une couleur ou un conditionnement peut avoir son propre historique. Afficher une remise commune sans vérifier chaque référence produit des cartes correctes pour certaines variantes et fausses pour d’autres.

Le guide Zence du SEO e-commerce recommande déjà de conserver une page propriétaire, des données produit cohérentes et une vérité marchande lisible. La promotion ajoute une dimension temporelle : l’exactitude ne se juge plus seulement entre la page et le flux, mais aussi entre la promesse présente et les prix réellement pratiqués auparavant.

La matrice offre, variante, canal, prix, fenêtre, promesse et preuve

Créez une ligne par variante et canal de vente concernés. Si deux canaux partagent réellement le même prix et le même historique, cette relation peut être explicite. Sinon, ne dédupliquez pas artificiellement leurs preuves.

Offre et variante Canal Prix pratiqué Fenêtre observée Promesse prévue Référence calculée Preuve conservée Décision
produit simple site France historique horodaté, taxes incluses selon le contexte trente jours complets avant le début prix barré et baisse chiffrée minimum de la fenêtre événements de prix, règle et aperçu daté publier si le calcul concorde
variante couleur application historique propre à la référence trente jours complets remise commune à la famille minimum par variante identifiant, prix, date d’effet et résultat du contrôle exclure la variante incohérente
produit omnicanal magasin Orléans prix du point de vente période du canal concerné campagne nationale référence du canal à qualifier export caisse, calendrier et contenu affiché segmenter ou harmoniser avant diffusion
code largement accessible site et email prix après code à qualifier fenêtre incluant les campagnes précédentes « remise membres » règle validée pour l’offre réelle conditions d’accès, audience, calcul et capture faire valider puis publier ou retirer
baisse progressive site prix initial puis paliers période déterminée documentée remise croissante référence autorisée pour la séquence calendrier verrouillé et version de règle bloquer une remontée intermédiaire non prévue

Cette matrice ne doit pas devenir un tableur rempli après la campagne. Elle sert de contrat entre la tarification, le merchandising, le développement et la validation. La colonne « décision » permet de refuser proprement une promotion sans empêcher la vente au prix courant.

Le modèle de données minimal

Un modèle robuste sépare le prix commercial, l’annonce et la preuve. Il n’est pas nécessaire de reconstruire toute la plateforme pour commencer.

Conservez au minimum :

  • un identifiant stable de produit et de variante ;
  • le canal, le pays, la devise et le contexte fiscal du prix ;
  • la valeur effectivement pratiquée auprès des consommateurs ;
  • la date et l’heure de début, ainsi que la date de fin lorsqu’elle existe ;
  • la source ayant imposé le changement : ERP, plateforme, caisse ou action manuelle ;
  • le type de campagne et la période annoncée ;
  • le prix antérieur calculé, la version de la règle et l’instant du calcul ;
  • le contenu visible : prix courant, prix barré, pourcentage, libellé et dates ;
  • l’éventuelle exception, son justificatif et son approbateur ;
  • le résultat du contrôle et la raison d’un blocage.

Le mot « pratiqué » est important. Un journal purement technique qui enregistre chaque écriture ne prouve pas toujours le prix réellement proposé dans le parcours. Reliez l’événement à la page, au canal, à la période d’effet et, lorsque le risque le justifie, à une capture ou un rendu archivé sans donnée personnelle.

Ne gardez pas seulement la valeur finale. Un écrasement en place empêche de reconstruire la fenêtre. Préférez des événements de prix immuables ou un historique versionné : valeur, début d’effet, fin d’effet, canal, source et correction éventuelle. Une correction n’efface pas l’ancienne ligne ; elle explique pourquoi elle ne doit plus être utilisée.

Cette logique protège aussi la migration. Le comparatif Shopify ou PrestaShop recommande de tester le prochain changement réel plutôt que la seule démonstration. Pour les promotions, ce test de sortie consiste à exporter l’historique, rejouer le calcul sur un échantillon et retrouver la preuve sans dépendre d’un module opaque.

Où placer les contrôles ?

Un contrôle uniquement exécuté à minuit avant le lancement arrive trop tard. Répartissez les vérifications selon la décision qu’elles protègent.

À la préparation de la campagne

Le système calcule le prix antérieur sur la fenêtre applicable pour chaque variante et canal. Il compare cette valeur au prix barré et au pourcentage préparés. Toute donnée manquante, période incomplète ou source contradictoire bloque la réduction, mais ne doit pas nécessairement rendre le produit indisponible au prix courant.

À la publication

La page, la liste produit, le panier et les flux réutilisant l’offre doivent exposer la même promesse. Vérifiez aussi les caches, les applications mobiles, les emails, les campagnes publicitaires et les données envoyées à des plateformes tierces. Le contrôle porte sur ce que le client voit, pas uniquement sur la réponse de l’API de tarification.

Pendant la campagne

Surveillez les changements de prix, l’expiration, la disponibilité et les substitutions de variante. Si un flux externe réécrit le tarif ou si une campagne précédente est prolongée, recalculez la décision au lieu de conserver aveuglément l’ancien prix barré.

À la clôture

Fermez la période, retirez les messages et conservez un dossier minimal : échantillon des références, calcul, règle, approbation, rendu et anomalies. Cette preuve aide à répondre à un contrôle ou à un incident ; elle permet aussi d’améliorer le prochain lancement.

Le protocole de migration Merchant API illustre la même séparation entre donnée source, traitement, destination, preuve et repli. Une promotion devient fiable quand cette chaîne reste lisible jusque dans les canaux qui la diffusent.

Huit scénarios de recette avant la prochaine campagne

Une recette utile provoque les cas que la campagne idéale ne révèle pas.

  1. Aucune promotion antérieure. Le minimum de la fenêtre correspond au prix régulier réellement pratiqué et le pourcentage affiché est exact.
  2. Réduction récente. Une remise terminée dix jours plus tôt entre dans le calcul ; le système refuse une référence artificiellement plus haute.
  3. Variante moins chère. La promotion fonctionne sur une taille, mais une autre possède un historique différent. Chaque variante reçoit une référence correcte ou est exclue de l’annonce commune.
  4. Canaux différents. Le site, l’application et le magasin ne partagent pas les mêmes prix. La campagne utilise la preuve propre au canal ou affiche une portée explicitement limitée.
  5. Code largement diffusé. L’équipe qualifie l’offre et vérifie si le prix obtenu doit intervenir dans l’historique avant de publier une nouvelle baisse.
  6. Réduction progressive. Les paliers, la période et le prix de référence restent stables selon la règle validée ; une interruption imprévue déclenche une nouvelle vérification.
  7. Erreur et reprise. Une source envoie un ancien prix. La campagne est suspendue pour les références touchées, l’anomalie est journalisée et le recalcul précède la remise en ligne.
  8. Fin de campagne. Les prix barrés, pourcentages, bandeaux, flux et caches expirent ensemble ; le dossier permet ensuite de reconstruire ce qui a été affiché.

Pour chaque scénario, conservez l’entrée, la sortie attendue, le rendu observé et la décision. Un test qui affirme seulement « API 200 » ne prouve ni le prix affiché, ni le calcul, ni la cohérence du panier.

Exemple fictif : trois canaux et une ancienne remise

Imaginons une enseigne fictive qui vend une lampe sur son site, son application et dans deux magasins. Le prix courant est 120 €. Une vente privée accessible par un code largement diffusé l’a proposée à 96 € quinze jours plus tôt sur le site. L’application n’a pas appliqué le code ; un magasin a pratiqué 110 € pendant un week-end.

L’équipe souhaite maintenant annoncer « 25 % de réduction » et un prix de 90 €. Un unique champ catalogue à 120 € produirait la même référence partout. La matrice révèle pourtant trois historiques et une offre antérieure à qualifier. L’équipe demande une validation juridique sur le code, calcule séparément chaque canal et limite la campagne aux surfaces dont la référence et le rendu sont prouvés.

Cet exemple n’est pas un cas client et ne conclut pas à la conformité d’une campagne réelle. Il montre pourquoi la bonne donnée n’est pas « l’ancien prix du produit », mais un historique situé, daté et relié à une présentation.

Faut-il acheter un module de promotions ?

Un module devient utile s’il calcule la bonne règle, importe l’historique nécessaire, isole les variantes et exporte sa preuve. Il devient une dépendance risquée s’il ne conserve qu’un prix catalogue et un prix soldé, masque son algorithme ou perd l’historique lors d’une migration.

Avant de choisir, demandez une démonstration sur vos cas difficiles : remise précédente, prix omnicanal, variante ajoutée récemment, cache, annulation, baisse progressive et export. Vérifiez aussi qui peut modifier la référence manuellement, comment cette action est journalisée et ce qui se passe lorsque trente jours de données ne sont pas disponibles.

Une solution plus simple peut suffire pour un petit catalogue : historique versionné, calcul quotidien, contrôle avant publication et revue humaine des exceptions. À l’inverse, un volume élevé de variantes, de canaux et de changements peut justifier un moteur tarifaire ou une intégration spécifique. Le besoin vient de la complexité réelle, pas du nombre de fonctionnalités promises par l’extension.

La méthode Zence pour automatiser un processus métier commence par la règle, les exceptions et la preuve. Elle évite de transformer une opération mal comprise en automatisation rapide mais impossible à auditer.

Par quoi commencer avant la prochaine promotion ?

Choisissez vingt références représentatives : produits simples, variantes, ancienne remise, code, stock faible et canaux différents. Exportez leurs événements de prix sur trente jours complets, puis comparez le minimum calculé au prix barré prévu, au pourcentage affiché et au panier.

Classez chaque ligne en trois états : prouvée, à corriger ou non reconstructible. La troisième catégorie ne doit pas être publiée comme réduction tant que l’historique ou la qualification manque. Elle peut rester vendue sans promesse promotionnelle si le reste du parcours le permet.

Reliez ensuite les anomalies à leur source : donnée produit, règle, import, interface, cache ou procédure marketing. Corrigez le maillon qui empêche la preuve avant d’ajouter un nouveau tableau de bord. Une fonctionnalité promotionnelle doit payer son loyer en rendant la promesse plus fiable, pas seulement plus facile à lancer.

Zence conçoit et fait évoluer des plateformes e-commerce reliées au catalogue, aux règles commerciales et aux opérations. Le premier périmètre peut rester ciblé : une famille de produits, deux canaux, la matrice, les huit scénarios et la correction du passage qui rend aujourd’hui le prix barré impossible à reconstruire.

Pour prolonger le diagnostic jusqu’au panier, à la marge et aux retours, utilisez aussi les priorités de performance et de conversion e-commerce. Une réduction techniquement correcte reste une mauvaise décision si elle dégrade la marge, crée des retours ou rend l’offre incompréhensible.

Sources principales

Écrit et relu par

Équipe ZenceThomas et Bastien croisent architecture logicielle, stratégie produit, design et opérations pour transformer des sujets complexes en produits numériques clairs et durables.