La directive européenne 2019/2161, dite « Omnibus », est applicable depuis le 28 mai 2022. En 2026, après quatre ans d’application et plusieurs vagues de contrôles DGCCRF, la conformité n’est plus optionnelle : les sanctions vont jusqu’à 4 % du chiffre d’affaires annuel pour les manquements graves, et la DGCCRF a publiquement annoncé une intensification des contrôles e-commerce en 2025-2026 sur les soldes, les Black Friday et les annonces de promotion permanente.
Le problème : la règle Omnibus est simple à énoncer, complexe à implémenter techniquement, et catastrophique sur les promotions si elle est mal appliquée. Cet article décortique la règle, les pièges qui tuent les promos, et la mécanique correcte sur PrestaShop.
Ce que dit exactement la directive Omnibus
Article L121-4 du Code de la consommation, modifié par l’ordonnance 2021-1734 transposant Omnibus :
« Toute annonce d’une réduction de prix indique le prix antérieur pratiqué par le professionnel avant l’application de la réduction. Le prix antérieur correspond au prix le plus bas pratiqué par le professionnel à l’égard de tous les consommateurs au cours des trente derniers jours précédant l’application de la réduction. »
Concrètement, quatre règles s’imposent :
- Toute promotion doit afficher le prix de référence = prix le plus bas des 30 derniers jours.
- Ce prix de référence doit être visible à côté du nouveau prix promotionnel.
- Le calcul est par produit et par référence (combinaison déclinaison), pas par catégorie.
- Le pourcentage de réduction affiché doit être calculé sur ce prix de référence, pas sur un prix gonflé.
Les exceptions et cas particuliers
Soldes officiels
La règle Omnibus s’applique aux soldes. Le « prix de référence » affiché en soldes doit être le prix le plus bas des 30 jours précédant l’ouverture des soldes — pas le prix barré arbitraire des fabricants.
Promotion progressive
Si vous appliquez -20 % la première semaine, puis -30 % la deuxième, le prix de référence reste celui des 30 jours précédant la PREMIÈRE remise. Le -30 % se calcule par rapport au prix d’origine, pas par rapport au prix promo précédent.
Nouveau produit (moins de 30 jours)
Si le produit est en vente depuis moins de 30 jours, on prend le prix le plus bas depuis sa mise en vente. La règle n’invente pas un prix antérieur — elle utilise l’historique disponible.
Denrées périssables
Exception : produits frais à date de péremption courte. L’Omnibus s’applique avec souplesse, mais la traçabilité reste exigée.
Produits non commercialisés au public auparavant
Une remise initiale (« prix de lancement ») n’a pas à afficher de prix de référence. Mais on ne peut pas indiquer un faux « prix barré ».
Le piège qui tue les promos : le prix barré gonflé
Avant Omnibus, beaucoup d’e-commerçants alignaient leur PVC sur un prix « catalogue fabricant » fantaisiste et affichaient -50 % en permanence. Pratique morte en 2022 et activement sanctionnée en 2025-2026.
Exemple type d’un contrôle DGCCRF : une boutique affiche un produit à 39,90 € avec un prix barré à 79,90 € (-50 %). L’audit DGCCRF demande l’historique des prix. Le produit n’a jamais été vendu au-dessus de 49,90 €. Sanction : amende administrative, retrait de l’allégation promotionnelle, publication du contrôle.
L’erreur de fond : confondre prix conseillé fabricant (PVC, non opposable) et prix de référence Omnibus (prix réellement pratiqué).
La mécanique technique sur PrestaShop
PrestaShop 8 et 9 ne gèrent pas nativement le prix de référence Omnibus. Le module catalogue gère les « réductions » et « specific prices », mais sans historique des 30 derniers jours ni calcul automatique du prix antérieur réel.
L’implémentation manuelle demande quatre couches :
1. Tracking de l’historique des prix
Une nouvelle table ps_price_history enregistre chaque changement de prix par id_product et id_product_attribute, avec timestamp. Soit déclenché par hook actionObjectProductUpdateAfter, soit par un cron quotidien qui snapshotte les prix.
CREATE TABLE ps_price_history (
id_history INT AUTO_INCREMENT PRIMARY KEY,
id_product INT NOT NULL,
id_product_attribute INT DEFAULT 0,
id_shop INT NOT NULL,
id_currency INT NOT NULL,
price DECIMAL(20,6) NOT NULL,
date_change DATETIME NOT NULL,
INDEX idx_product_date (id_product, date_change)
) ENGINE=InnoDB;2. Calcul du prix de référence
Au moment d’afficher une promotion, le module calcule pour chaque produit le prix le plus bas des 30 derniers jours :
SELECT MIN(price) AS prix_reference
FROM ps_price_history
WHERE id_product = :product_id
AND id_product_attribute = :attribute_id
AND date_change >= DATE_SUB(NOW(), INTERVAL 30 DAY)
AND date_change < :promo_start_date;3. Affichage conforme
Sur la fiche produit et dans les listings, le bloc prix affiche :
- Prix promotionnel actuel (en grand)
- Prix de référence des 30 derniers jours, barré (« Prix antérieur le plus bas (30j) : 39,90 € »)
- Pourcentage de réduction calculé sur le prix de référence
Optionnellement, un tooltip ou un lien « Voir l’historique des prix » améliore la transparence (et désamorce les contestations).
4. Traçabilité pour l’audit
En cas de contrôle DGCCRF, vous devez pouvoir produire l’historique sur demande. La table ps_price_history doit être conservée au moins 2 ans, idéalement 5 ans. Exportable en CSV depuis le BO.
Les erreurs fréquentes en production
- Calculer le prix de référence sur le prix HT au lieu du prix TTC ou inversement. La règle s’applique au prix payé par le consommateur — donc TTC pour le B2C.
- Ignorer les déclinaisons. Le prix de référence est par référence physique, pas par produit parent.
- Ne pas gérer le multi-devise. Si vous vendez en euros et en dollars, l’historique doit être par devise.
- Réinitialiser l’historique à chaque mise à jour catalogue. Une migration ou un import en masse peut écraser l’historique. Le module doit préserver l’historique passé.
- Afficher le « prix conseillé fabricant » à la place du prix de référence. C’est l’erreur juridique majeure.
- Ne pas couvrir les pages catégorie et les listings. Si la fiche produit est conforme mais que la vignette en catégorie affiche un prix barré gonflé, vous êtes en infraction.
Notre module dfomnibus : conformité automatique
Implémenter cette mécanique à la main est un projet de 5 à 8 jours de dev, avec tests sur multi-shop, multi-devise et déclinaisons. Notre module dfomnibus pour PrestaShop 8 et 9 industrialise toute la stack :
- Tracking automatique de l’historique via hook sur la modification de prix (sans cron, en temps réel).
- Calcul du prix de référence Omnibus par produit et par déclinaison, avec gestion multi-shop et multi-devise.
- Affichage conforme sur fiches produit, listings catégorie, blocs cross-sell, panier.
- Traçabilité auditable : export CSV de l’historique, prêt pour la DGCCRF.
- Pourcentage de réduction recalculé sur le prix de référence, jamais sur un prix arbitraire.
- Compatible avec les soldes officiels et les promotions programmées.
- Multilingue FR/EN/ES/DE pour les boutiques internationales (la directive Omnibus s’applique dans toute l’UE).
Pour 79 €, vous passez en conformité sans toucher au catalogue et sans risque sur les promotions à venir.
Au-delà de la conformité : la conversion
Paradoxalement, une promotion conforme Omnibus convertit souvent mieux qu’une promotion gonflée. La raison : les consommateurs sont devenus méfiants face aux prix barrés artificiels. Afficher un prix de référence vérifié et un pourcentage honnête renforce la crédibilité. Sur les boutiques que nous avons converties à la conformité stricte, le taux de clic sur les vignettes promotionnelles s’est stabilisé ou a légèrement augmenté.
Et surtout, la conformité supprime un risque opérationnel majeur : un signalement DGCCRF (souvent fait par un concurrent) déclenche un audit qui peut paralyser la stratégie promotionnelle pendant des mois.
FAQ
La directive Omnibus s’applique-t-elle aux soldes ?
Oui, intégralement. Le prix de référence affiché en soldes doit être le prix le plus bas pratiqué au cours des 30 jours précédant l’ouverture des soldes — pas le « prix catalogue » ou le « PVC fabricant ». La DGCCRF a explicitement ciblé les soldes 2024 et 2025 dans ses contrôles e-commerce.
Que faire pour les produits en promotion permanente ?
La promotion « permanente » est incompatible avec Omnibus. Si un produit est en remise -30 % depuis trois mois, le prix de référence est en réalité le prix de remise (puisque c’est le prix le plus bas des 30 derniers jours). Donc -30 % par rapport à… -30 % = 0 % de remise réelle affichable. Soit on supprime la communication promotionnelle, soit on alterne périodes promotionnelles et périodes au prix normal.
Le module gère-t-il la rétroactivité ?
Si vous installez dfomnibus aujourd’hui, l’historique commence à la date d’installation. Pour les contrôles DGCCRF portant sur des promotions passées (avant installation), il faudra produire l’historique par d’autres moyens (sauvegardes BDD, exports CSV anciens). Nous recommandons d’installer le module en amont des soldes ou des opérations promotionnelles majeures, pas le jour J.
Quelle sanction en cas de non-conformité ?
L’article L132-2 du Code de la consommation prévoit jusqu’à 300 000 € pour les personnes physiques et 4 % du chiffre d’affaires annuel pour les personnes morales pour les manquements graves. En pratique, les sanctions DGCCRF sur les e-commerçants en 2024-2025 oscillent entre 5 000 € et 80 000 € selon la gravité et la récidive.
La directive Omnibus s’applique-t-elle hors UE ?
Non, c’est une directive européenne. Mais si votre boutique vend à des consommateurs européens depuis un pays tiers (UK, Suisse, US), vous êtes soumis à la règle pour les ventes B2C dans l’UE. Le critère est le ciblage du consommateur, pas le siège du marchand.
Pour aller plus loin
La conformité réglementaire en e-commerce 2026 se structure autour de trois piliers : RGPD (Consent Mode v2), Omnibus (prix de référence), et sectoriel (age gate, INCO, sécurité produits). Voir aussi notre guide RGPD Consent Mode v2 PrestaShop et le récent dossier sur la vérification d’âge e-commerce. Trois couches indépendantes, à empiler proprement.
