# Un même catalogue, des prix différents selon le client

> Un distributeur B2B vendait aux mêmes références à des profils de clients très différents, chacun avec sa propre grille tarifaire négociée.

- Source canonique : [https://allaux.fr/realisations/marges-configurables-par-client](https://allaux.fr/realisations/marges-configurables-par-client)
- Langue : FR
- Dernière mise à jour : 2026-07-26

## Le contexte

La boutique servait plusieurs catégories de clients professionnels : des revendeurs, des centrales d'achat, des entreprises passant commande ponctuellement. Chacun avait négocié des conditions différentes, parfois par famille de produits, parfois par volume d'achat annuel. PrestaShop propose nativement des groupes de clients avec des remises simples, mais ce mécanisme ne suffisait plus dès que les règles se sont complexifiées : une remise différente selon la marque, un plancher de marge à ne jamais descendre, des exceptions négociées produit par produit pour certains comptes.

Gérer ça avec des remises manuelles saisies compte par compte serait devenu ingérable à mesure que le nombre de clients professionnels augmentait.

## Ce que j'ai fait

1. **Cadrage des règles réelles** — Recueil de toutes les règles de tarification effectivement appliquées, y compris les exceptions non documentées ailleurs que dans la tête de l'équipe commerciale.
2. **Conception du moteur de règles** — Développement d'un module qui calcule le prix affiché à partir d'une hiérarchie de règles : prix de base, remise par groupe, remise par famille, exception par compte, avec priorité claire entre les niveaux.
3. **Interface d'administration dédiée** — Écran back-office permettant à l'équipe commerciale de créer et modifier une grille sans intervention technique à chaque changement de condition.
4. **Vérification du plancher de marge** — Ajout d'un garde-fou empêchant qu'une combinaison de remises fasse descendre un prix sous un seuil de marge minimale défini par produit.

## Ce qui a demandé le plus de soin

- **Cohérence avec les promotions natives** — Le moteur devait cohabiter avec les règles de promotion déjà existantes dans PrestaShop, sans double application ni conflit de priorité.
- **Performance au moment de l'affichage** — Le calcul de prix intervient à chaque affichage de fiche produit et de liste : la logique a été pensée pour rester rapide même avec un grand nombre de règles actives.
- **Traçabilité du prix affiché** — Possibilité de savoir, pour un prix donné, quelle règle a été appliquée — utile en cas de question d'un client sur son tarif.

## Résultat

> L'équipe commerciale a pu créer et ajuster des grilles tarifaires sans passer par une demande de développement à chaque nouveau compte, tout en gardant un plancher de marge garanti.

## FAQ

### Ce système remplace-t-il les groupes de clients natifs de PrestaShop ?

Non, il s'appuie dessus et les complète. Les groupes natifs restent la base de segmentation, le moteur de règles ajoute les niveaux de priorité et les exceptions que le natif ne couvre pas seul.

### Combien de règles peuvent coexister sans ralentir la boutique ?

Le nombre de règles compte moins que leur structure : une hiérarchie bien pensée avec les bons index en base reste rapide même avec plusieurs centaines de règles actives.

### L'équipe commerciale peut-elle modifier les grilles seule ?

C'est justement l'objectif de l'interface d'administration : créer, modifier ou désactiver une grille ne nécessite pas d'intervention technique une fois le module en place.

### Que se passe-t-il en cas de règles contradictoires ?

La hiérarchie de priorité définie à la conception tranche automatiquement. Les cas ambigus détectés en amont ont été discutés avec l'équipe commerciale avant la mise en production.