La logique de tarification et de promotion est la couche de règles commerciales qui détermine ce qu’un client doit payer, pourquoi ce montant s’applique et comment la boutique doit expliquer le résultat. Un produit peut avoir un prix de base, un prix promotionnel, un prix propre à une variante, un prix réservé à un groupe client, un tarif dégressif, une remise de catalogue, un coupon, un avantage de livraison gratuite, un ajustement d’abonnement, une récompense de fidélité et une condition de prix liée à la fiscalité ou à une région. La boutique peut n’afficher qu’un montant final, alors que ce montant résulte de plusieurs objets de données et règles de calcul.
Dans une plateforme e-commerce, les données de prix ne se limitent pas à un champ de prix produit. Elles peuvent être réparties entre fiches produit, variantes, listes de prix, groupes clients, règles de catalogue, règles de panier, tables de coupons, paramètres fiscaux, règles de livraison, configuration des devises, systèmes d’abonnement, applications de fidélité, moteurs de tarification d’entreprise, intégrations ERP ou données d’extension personnalisées. Les promotions dépendent encore davantage des structures environnantes, car une remise nécessite souvent des critères d’éligibilité, des exclusions, des périodes d’activation, des limites d’utilisation, une priorité, des règles de cumul et un ordre de calcul.
Une analyse technique de la tarification et des promotions doit donc examiner où la règle commerciale est stockée, de quelles données elle dépend, comment la plateforme la calcule et comment le résultat apparaît dans le panier, le checkout, les commandes, les rapports, les remboursements et les communications client.
Ce que représentent la tarification et les promotions dans une boutique e-commerce
La logique de tarification et de promotion constitue le système de décision commerciale de la boutique. Elle répond simultanément à plusieurs questions : quel est le prix normal d’un article, si un client bénéficie d’un prix différent, si le panier remplit les conditions d’une remise, quels produits sont exclus, si la livraison est concernée, si la taxe est calculée avant ou après la remise et si plusieurs avantages peuvent se cumuler.
Une même boutique peut utiliser plusieurs couches de prix selon les objectifs commerciaux :
| Couche de prix ou de promotion | Ce qu’elle représente | Fonctionnement concerné |
|---|---|---|
| Prix de base | Prix de vente normal d’un produit ou d’une variante | Affichage de la page produit, montant de ligne panier, flux, reporting et total de commande |
| Prix promotionnel ou prix de comparaison | Différence temporaire ou de merchandising | Badges, prix barrés, pages de campagne et communication commerciale |
| Prix au niveau variante | Prix différents selon taille, couleur, matériau, taille de lot ou configuration | Sélection d’option, total panier, achat lié au stock et attentes de traitement |
| Prix par groupe client | Prix réservé aux grossistes, clients retail, VIP, B2B, employés ou membres | Prix après connexion, prix de compte, segmentation client et vente contractuelle |
| Prix dégressif ou par quantité | Prix qui varie selon la quantité achetée | Achat en volume, commerce de gros, grilles tarifaires et calcul panier |
| Règle de catalogue | Remise appliquée avant l’arrivée du client dans le panier | Merchandising de catégorie, affichage des listes produit et visibilité des promotions |
| Règle de panier | Remise appliquée selon les conditions du panier | Coupons, total panier, incitations au checkout et offres à seuil |
| Avantage de livraison | Livraison gratuite ou réduite sous conditions | Conversion au checkout, offres régionales et calcul de marge |
| Règle de fidélité ou récompense | Crédit, points, réduction de membre ou avantage acquis | Fidélisation, comportement de compte et économie des achats répétés |
| Prix d’abonnement ou récurrent | Règles tarifaires pour achats répétés ou cycles d’adhésion | Facturation, renouvellements, gestion de compte et automatisation des commandes |
| Source de prix externe | Prix contrôlé par ERP, POS, PIM, marketplace ou moteur de tarification | Gestion de la source de référence, synchronisation et gouvernance opérationnelle |
Ces couches peuvent se chevaucher. Un produit peut avoir simultanément un prix promotionnel, un prix propre au client, une promotion de catégorie, un coupon et un seuil de livraison gratuite. La question technique essentielle n’est pas seulement de savoir si chaque couche existe, mais laquelle l’emporte, lesquelles peuvent se combiner et comment la plateforme enregistre le résultat final.
Structures de données courantes derrière les prix produit
La tarification commence généralement par un champ de prix, mais la plupart des boutiques ont besoin de davantage qu’une seule valeur. Un produit simple peut avoir un prix de base unique. Un produit à variantes peut stocker un prix par SKU. Une boutique B2B ou connectée à des marketplaces peut stocker des listes de prix selon le marché, la devise, le groupe client, le catalogue, le contrat ou le canal.
Les champs courants incluent :
| Champ ou propriété | Fonction habituelle | Point de vigilance technique |
|---|---|---|
| ID produit ou variante | Relie le prix à l’article vendable | Détermine si le prix s’applique au produit parent ou à une variante |
| Prix de base | Prix de vente standard | Peut être au niveau produit sur une plateforme et au niveau variante sur une autre |
| Prix promotionnel | Prix réduit actif | Peut avoir ses propres dates ou dépendre de règles de campagne |
| Prix de comparaison ou prix catalogue | Prix de référence affiché à côté du prix actif | Peut modifier l’affichage sans changer le montant calculé |
| Coût ou marge | Base de coût interne | Généralement invisible au client mais importante pour le reporting ou la marge |
| Code devise | Devise de la valeur | Peut nécessiter listes de prix, règles de change ou valeurs propres au marché |
| Classe fiscale | Catégorie de taxe du produit | Influence le calcul fiscal et le comportement régional |
| Groupe client ou ID de liste de prix | Relation d’éligibilité | Contrôle les tarifs B2B, grossiste, membre ou contractuels |
| Seuil de quantité | Point de bascule d’un tarif dégressif | Détermine quand un prix unitaire différent s’applique |
| Périmètre de canal ou de marché | Relation avec boutique, région, marketplace ou canal de vente | Contrôle le prix affiché dans chaque contexte |
| Date de début et de fin | Fenêtre d’activation | Contrôle le calendrier des campagnes et le risque de prix obsolète |
| Priorité ou ordre | Valeur de résolution des conflits | Détermine quel prix ou quelle règle l’emporte |
Une plateforme qui stocke un seul prix produit se comporte très différemment d’une plateforme qui conserve plusieurs lignes de prix par produit, variante, groupe client, marché ou canal. Cette différence influence l’affichage, l’édition, l’export, la synchronisation et la validation des prix.
Les promotions comme données fondées sur des conditions
Un enregistrement de promotion contient généralement deux parties : un déclencheur et une règle. Le déclencheur peut être un code coupon, une remise automatique, un segment client, un calendrier de campagne ou une condition de panier. La règle définit ce qui se passe lorsque le déclencheur est valide.
Une règle de promotion peut contenir de nombreuses conditions :
| Condition de promotion | Exemples | Ce qui peut changer selon la plateforme |
|---|---|---|
| Éligibilité produit | SKU, variantes, catégories, collections, marques, tags, fournisseurs ou attributs précis | Le ciblage peut utiliser d’autres types d’objets ou une autre logique de requête |
| Exclusions | Produits déjà soldés, déstockage, cartes cadeaux, marques restreintes, bundles, abonnements ou certaines variantes | Les exclusions peuvent être limitées ou nécessiter une règle distincte |
| Éligibilité client | Groupes, tags, segments, domaines e-mail, statut de membre, niveau de fidélité ou compte B2B | Les modèles de segmentation peuvent ne pas correspondre directement |
| Seuil de panier | Dépense minimale, quantité minimale, dépense maximale, nombre d’articles ou sous-total après exclusions | Le seuil peut être calculé avant ou après remise, taxe ou livraison |
| Action de remise | Pourcentage, montant fixe, BOGO, article gratuit, livraison gratuite, offre dégressive ou prix de bundle | Certaines actions peuvent être natives et d’autres nécessiter une application |
| Limite d’utilisation | Par client, code, commande, durée de vie ou campagne | L’historique d’utilisation peut ne pas se transférer de la même manière |
| Période | Date de début, date de fin, campagne planifiée, fuseau horaire ou fenêtre récurrente | Le comportement dépend du fuseau horaire et du système de planification |
| Règle de cumul | Cumul avec remises produit, commande, livraison, fidélité ou ajustements manuels | La logique de combinaison est souvent propre à la plateforme |
| Priorité | Règle appliquée d’abord ou gagnante en cas de conflit | La priorité peut être explicite, implicite ou indisponible |
Un code coupon peut sembler identique après migration tout en produisant un autre résultat. Le code n’est que l’identifiant visible par le client. Le moteur de règles contrôle l’éligibilité, les exclusions, le montant de remise, les règles de cumul et le calcul final.
Ordre de calcul et cumul des remises
L’ordre de calcul constitue l’une des différences les plus importantes entre plateformes. Deux boutiques peuvent utiliser le même libellé de remise et obtenir des totaux différents si l’une applique la remise aux lignes avant taxes tandis que l’autre l’applique au sous-total après d’autres remises.
Questions courantes :
- La remise s’applique-t-elle à la ligne produit, au sous-total du panier, aux frais de livraison, au montant TTC ou au montant hors taxes ?
- Le prix promotionnel remplace-t-il le prix de base avant le calcul du coupon ?
- Un coupon peut-il s’appliquer à un article déjà remisé ?
- Les remises produit et les remises de commande peuvent-elles se cumuler ?
- Une remise de livraison gratuite s’applique-t-elle avant ou après le choix du mode de livraison ?
- La plateforme répartit-elle au prorata les remises de niveau commande entre les lignes ?
- La logique de remboursement conserve-t-elle la répartition originale des remises ?
- La plateforme arrondit-elle chaque ligne, chaque ligne de taxe ou uniquement le total final ?
Le cumul est particulièrement sensible. Certaines plateformes autorisent la combinaison de plusieurs remises automatiques et codes coupons. D’autres n’acceptent qu’un seul code, séparent remises produit et remises de commande, limitent la combinaison avec la livraison gratuite ou nécessitent une application pour les scénarios avancés. Si les règles de cumul changent, une promotion peut devenir trop généreuse, trop restrictive ou commercialement différente même si le montant visible paraît familier.
Différences entre les modèles de plateforme
Les plateformes diffèrent dans la part de logique de prix et de promotion qui est native, configurable, gérée par extension ou contrôlée par un système externe.
Les plateformes SaaS proposent souvent prix produit et variante structurés, codes de remise, remises automatiques, prix propres aux marchés et extensions par applications. Elles simplifient l’administration, mais peuvent limiter les combinaisons de remises, les prix B2B avancés, les priorités de règles ou les campagnes complexes sans applications supplémentaires ou fonctionnalités de niveau supérieur.
Les plateformes Open-Source donnent souvent davantage d’accès aux règles de prix catalogue, règles de panier, groupes clients, classes fiscales et tables d’extensions. Elles peuvent prendre en charge une logique commerciale complexe, mais les données peuvent être dispersées entre tables cœur, modules, attributs personnalisés, configurations sérialisées et code personnalisé. Une seule promotion visible peut dépendre de plusieurs enregistrements appartenant à des extensions.
Les plateformes d’entreprise peuvent séparer les prix en grilles, catalogues partagés, groupes clients, sites, marchés, contrats et comptes professionnels. Le prix B2B peut dépendre de la hiérarchie du compte, des autorisations d’entreprise, du rôle de l’acheteur, d’un contrat négocié, d’une liste d’achat ou d’une synchronisation ERP. Un même produit peut avoir de nombreux prix selon le client et le canal.
Dans les boutiques omnicanales ou connectées à des marketplaces, la plateforme e-commerce n’est pas forcément l’unique source du prix. Les prix peuvent provenir d’un ERP, POS, PIM, outil marketplace, moteur de repricing ou gestionnaire de canaux. La boutique peut les afficher et les traiter tout en laissant la source de référence dans un système externe.
Relations avec les autres données de la boutique
Tarification et promotions dépendent fortement des structures environnantes. Une promotion de catégorie dépend des affectations aux catégories ou collections. Un prix par niveau client dépend des groupes ou segments. Une remise de bundle dépend des relations produit et de la logique de stock. Une remise d’abonnement dépend des données de facturation récurrente. Une promotion régionale dépend du marché, de la devise, des zones de livraison, des taxes ou de la localisation.
| Dépendance | Impact sur la tarification ou la promotion |
|---|---|
| Structure produit et variante | Détermine si le prix ou la remise s’applique au produit parent, à un SKU, bundle, kit ou choix configurable |
| Attributs et tags | Peuvent piloter éligibilité, exclusions, collections automatisées, pages de promotion ou libellés visibles |
| Catégories et collections | Contrôlent souvent règles de catalogue, remises de pages d’atterrissage, promotions saisonnières et groupes de merchandising |
| Groupes et segments clients | Déterminent l’éligibilité B2B, grossiste, fidélité, membre, employé ou VIP |
| Paramètres fiscaux | Contrôlent prix TTC, classes fiscales, calcul régional et totaux de facture |
| Zones et modes de livraison | Contrôlent livraison gratuite, offres régionales, seuils et incitations au checkout |
| Devises et marchés | Contrôlent prix locaux, arrondis, valeurs affichées et différences de taux de change |
| Stock et traitement des commandes | Peuvent influencer offres de bundle, promotions sur produits en rupture différée, disponibilité d’abonnement et vente régionale |
| Systèmes externes | Peuvent remplacer ou synchroniser prix, remises, éligibilité client ou totaux de commande |
Une règle de prix doit être examinée avec les structures dont elle dépend. Si le produit passe d’un modèle de variantes à un autre, si les affectations de catégorie changent ou si les groupes clients sont recréés comme tags ou segments, la promotion peut devoir être réinterprétée même si son nom reste reconnaissable.
Fonctionnalités propres aux plateformes et comportements exclusifs
Certaines logiques de prix ou promotion reposent sur des fonctions qui n’existent pas partout. Elles peuvent être natives, gérées par application ou extension, réservées à l’entreprise ou synchronisées depuis l’extérieur.
Exemples importants :
- listes de prix propres aux marchés et tarification régionale ;
- tarifs par groupe client et comptes B2B ;
- catalogues partagés et grilles de prix par entreprise ;
- prix grossiste par quantité et tarifs unitaires dégressifs ;
- remises d’abonnement et règles de prix récurrents ;
- calculs de prix pour bundles, kits et produits configurables ;
- utilisation de points de fidélité et crédits de récompense ;
- interactions entre cartes cadeaux et avoirs ;
- remises automatiques sans code coupon ;
- offres du type un acheté/un offert et cadeaux ;
- arrondis par devise, marché, règle fiscale ou prestataire de paiement ;
- prix contrôlés par ERP et tarifs contractuels ;
- repricing marketplace et prix propres aux canaux.
Ces comportements ne sont pas interchangeables. Un prix par groupe client n’est pas toujours équivalent à une remise fondée sur un tag client. Une règle de catalogue n’équivaut pas nécessairement à une règle de panier. Un prix de comparaison n’est pas la même chose qu’un prix promotionnel activé par un calendrier. Un prix de bundle calculé par une application n’est pas un prix natif de variante. Préserver le comportement commercial exige d’identifier la fonction de plateforme qui produisait le résultat d’origine.
Ce qui échoue souvent lorsque la logique de prix est mal comprise
Les problèmes de prix peuvent être difficiles à détecter : l’enregistrement administratif peut sembler correct alors que la boutique ou le checkout produit un mauvais résultat.
| Mode d’échec | Cause probable | Impact client ou métier |
|---|---|---|
| Bon code coupon, mauvais montant de remise | Action de règle ou sous-total éligible modifié | Réclamations, erreurs de campagne, perte de marge |
| La remise s’applique à des produits exclus | Modèle d’exclusion mal transposé | Risque de marge et problèmes de politique de marque |
| Les grossistes voient les prix retail | Relation groupe client ou liste de prix modifiée | Friction B2B et escalade vers le support |
| Badge promotionnel sans le bon prix calculé | Prix d’affichage et prix actif stockés séparément | Confusion et merchandising inexact |
| Total panier différent de l’attendu | Ordre de calcul, fiscalité ou arrondi différent | Abandon au checkout, écart comptable, complexité des remboursements |
| Livraison gratuite trop large ou absente | Règle de livraison, zone, seuil ou relation de mode modifiée | Perte de marge ou baisse de conversion |
| Remise de fidélité ou d’abonnement disparue | Logique appartenant à une application ou un système externe non recréée | Problèmes de fidélisation et perturbation des commandes récurrentes |
| Prix multidevises qui dérivent | Taux de change, prix marché ou arrondis modifiés | Incohérences régionales et confusion dans le reporting |
Ces problèmes sont structurels. Ils proviennent généralement de modèles de plateforme non équivalents, et non d’un simple libellé manquant.
Comment examiner les prix et promotions avant migration
Une analyse utile avant migration doit séparer les valeurs de prix de la logique commerciale. La valeur est le nombre enregistré sur un produit ou une variante. La logique commerciale est l’ensemble de conditions qui décide quand ce nombre change.
Les marchands devraient examiner :
- les produits et variantes avec des prix non standard ;
- les prix promotionnels actifs et les prix de campagnes planifiées ;
- les tarifs par groupe client, grossiste, B2B ou membre ;
- les prix dégressifs, volume, abonnement et bundle ;
- les codes coupons actifs et remises automatiques ;
- les règles de catalogue et de panier ;
- les limites d’utilisation, périodes, priorités et règles de cumul ;
- les dépendances produit, catégorie, client, région, livraison et fiscalité ;
- les prix contrôlés par application, extension, ERP, POS, fidélité, abonnement ou marketplace ;
- les anciennes règles qui devraient être retirées plutôt que transférées.
L’analyse la plus utile commence par les scénarios commercialement importants plutôt que par tous les coupons obsolètes. Offres actives au lancement, prix de comptes B2B, remises de fidélité, prix d’abonnement, exclusions sensibles à la marge et seuils de livraison gratuite méritent davantage d’attention que les campagnes saisonnières expirées.
Implications de migration pour la tarification et les promotions
La migration des prix et promotions doit préserver les résultats commerciaux attendus lorsque la plateforme cible peut les prendre en charge. Certaines données peuvent être transférées comme valeurs directes. Certaines règles doivent être recréées dans les paramètres natifs. Certains comportements nécessitent le remplacement d’une application, une configuration manuelle ou un traitement personnalisé parce que le modèle de tarification cible est différent.
L’implication principale est que la validation doit utiliser des scénarios réalistes de client et de panier. Une règle ne doit pas être approuvée uniquement parce qu’un code coupon ou une valeur de prix existe dans l’administration.
Scénarios importants :
- produit retail normal sans promotion ;
- variante dont le prix diffère du produit parent ;
- produit avec prix promotionnel et prix de comparaison ;
- remise fondée sur une catégorie ou collection ;
- prix par groupe client ou compte B2B ;
- seuil de quantité ou tarif dégressif ;
- coupon avec exclusions et limites d’utilisation ;
- panier avec remises cumulables ou incompatibles ;
- seuil de livraison gratuite ;
- commande sensible à la fiscalité ;
- commande multidevise ou régionale ;
- tarification d’abonnement, bundle, fidélité ou extension.
Lorsque les règles ne peuvent pas être représentées par une correspondance directe, il faut distinguer la transformation de valeurs, la correspondance des relations, le traitement sélectif d’enregistrements, la configuration cible et la logique adaptée. Les règles d’application, tables de prix personnalisées, identifiants externes et calculs spécifiques nécessitent une interprétation explicite et des éléments d’acceptation plutôt que l’hypothèse qu’un simple déplacement des valeurs recréera le comportement.
Conclusion
La logique de tarification et de promotion est un problème d’architecture de données, pas seulement de configuration marketing. Le prix, le code coupon ou le libellé visible n’est que la surface d’un système de règles qui peut inclure produits, variantes, catégories, clients, paramètres fiscaux, zones de livraison, devises, systèmes externes et ordre de calcul propre à la plateforme.
Avant la migration, le travail principal consiste à identifier les comportements commerciaux qui doivent rester exacts après lancement. Prix de base, prix promotionnels, tarifs par groupe client, prix dégressifs, règles de panier et de catalogue, avantages de livraison et remises gérées par extension doivent être examinés selon les structures de données et fonctions de plateforme qui les produisent.
Pour les comportements complexes, utilisez des scénarios de panier représentatifs afin de valider le résultat. Si une règle dépend de structures de remise non prises en charge, d’une logique de prix personnalisée, de données d’application ou d’extension, de sources de prix externes ou de fonctionnalités non équivalentes, le traitement requis doit être clarifié avant une exécution plus large.
Questions fréquentes
Pourquoi la même promotion peut-elle fonctionner différemment sur une autre plateforme ?
Une promotion dépend de bien plus que son nom ou son code. Conditions d’éligibilité, exclusions, règles de sous-total, moment du calcul des taxes, comportement de livraison, cumul des remises, priorité, limites d’utilisation et arrondis peuvent tous différer entre moteurs de règles.
Quelle est la différence entre un prix produit et une règle de tarification ?
Un prix produit est une valeur stockée associée à un produit, une variante, une liste de prix ou un marché. Une règle décide quand cette valeur change ou quand une remise supplémentaire s’applique selon le client, le panier, le produit, la catégorie, la quantité, la date, la livraison ou d’autres conditions.
Faut-il migrer les promotions expirées ?
Pas toujours. Les promotions expirées, obsolètes, de test ou à faible impact peuvent souvent être retirées. Les campagnes actives, prix propres aux clients, offres de lancement, prix grossistes, règles de fidélité, remises d’abonnement et exclusions sensibles à la marge nécessitent une analyse plus poussée.
Comment valider la tarification et les promotions ?
La validation doit utiliser des scénarios réalistes de clients et de paniers. Examinez les remises propres aux produits, les articles exclus, les prix par groupe client, les tarifs dégressifs, les remises cumulées, les seuils de livraison gratuite, les totaux sensibles aux taxes, les prix régionaux et les comportements de prix gérés par extension.
Quand la logique de prix nécessite-t-elle un traitement personnalisé ?
Un traitement personnalisé peut être nécessaire lorsque le résultat attendu dépend d’une transformation de règle non prise en charge, de données d’application ou d’extension, d’une logique de fidélité, de tarification d’abonnement, de grilles de prix propres aux clients, de prix externes ERP/POS, de règles de cumul complexes ou de calculs spécifiques que la plateforme cible ne peut pas recréer directement.