Un catalogue B2B avec prix par client : modélisation

Une boutique destinée aux professionnels ne se contente pas d'afficher un prix : chaque client dispose de conditions négociées, parfois par famille de produits, parfois par référence, souvent avec des paliers de quantité. Traiter cela avec les outils prévus pour les promotions grand public conduit rapidement à un système ingérable, où personne ne sait plus expliquer le prix affiché à un acheteur qui le conteste. La modélisation retenue au démarrage détermine ce qu'il sera possible de faire ensuite, et elle est très coûteuse à reprendre une fois que des centaines de clients ont leurs conditions enregistrées. Cet article détaille les structures qui fonctionnent, l'ordre d'application des règles et les points de synchronisation avec la gestion commerciale.

Ce qui distingue un prix négocié d'une remise

La confusion entre les deux notions est à l'origine de la plupart des systèmes bancals rencontrés. Une remise est un événement commercial temporaire, visible, communiqué, qui s'applique à une population et se termine à une date. Un prix négocié est une condition contractuelle, permanente jusqu'à renégociation, propre à un client et généralement confidentielle. Les traiter avec le même mécanisme revient à confondre une opération marketing et un contrat, ce qui produit des effets de bord dès que les deux coexistent. La distinction doit être posée dès la conception et elle structure toute la suite du travail. Elle rejoint les logiques de calcul que nous décrivons dans notre article sur le prix TTC ou HT selon le pays de livraison.

La permanence

Un prix négocié n'a pas de date de fin prévue et il s'applique à chaque commande du client concerné, sans qu'il ait à saisir quoi que ce soit. Le client ne doit jamais avoir à se souvenir d'un code ni à demander l'application de ses conditions. Cette exigence, évidente pour un acheteur professionnel, exclut d'emblée les mécanismes de bons de réduction. Elle impose que la tarification soit résolue au moment de l'affichage, pour un client identifié, et non au moment du panier. C'est la contrainte technique structurante de tout le sujet. Elle interdit notamment de calculer les prix en fin de parcours, comme le font la plupart des boutiques grand public.

La confidentialité

Les conditions accordées à un client ne doivent être visibles ni par les autres clients, ni par les visiteurs non connectés. Cette exigence a des conséquences sur le cache, sur les exports, sur les flux vers les comparateurs et sur les fils de données. Un catalogue mis en cache sans distinction de client affichera les conditions du premier arrivé à tous les suivants, incident classique et particulièrement embarrassant. Le sujet doit donc être traité au niveau de l'architecture de cache dès le départ. Il constitue le risque le plus élevé de ce type de projet. Un incident de ce genre ne se rattrape pas, l'information ayant été vue par un concurrent direct du client concerné.

La granularité

Un accord porte rarement sur l'ensemble du catalogue de façon uniforme. Il combine généralement une remise générale, des conditions particulières sur certaines familles et des prix nets sur quelques références stratégiques. La modélisation doit donc prévoir plusieurs niveaux et un ordre de priorité entre eux. Prévoir un seul niveau conduit à dupliquer les conditions référence par référence, ce qui devient ingérable au delà de quelques dizaines de produits. C'est l'erreur de conception la plus fréquente. Elle se manifeste par des tableaux de plusieurs milliers de lignes que plus personne n'ose modifier.

Les paliers de quantité

La vente aux professionnels s'accompagne presque toujours de tarifs dégressifs par quantité, propres au client ou communs à tous. Ces paliers se combinent avec les conditions précédentes, ce qui multiplie les cas à traiter. Ils doivent être modélisés comme une dimension supplémentaire plutôt que comme des lignes de prix distinctes. Cette approche évite l'explosion combinatoire et elle permet de faire évoluer les seuils sans reprendre chaque enregistrement. Un changement de politique de dégressivité se traduit alors par la modification de quelques lignes plutôt que de plusieurs milliers.

La question de l'affichage

Un visiteur non connecté doit il voir un prix, un prix public, ou rien du tout. Les trois réponses existent selon les secteurs et elles engagent le référencement du catalogue : une fiche sans prix se positionne moins bien qu'une fiche avec prix. Le compromis courant consiste à afficher un tarif public et à remplacer par le tarif négocié après connexion. Ce choix relève du commerce autant que de la technique et il doit être tranché explicitement avant de construire quoi que ce soit. Le revenir dessus après la mise en ligne suppose de reprendre les gabarits, le cache et souvent les flux sortants.

La cohérence avec la gestion

Les conditions tarifaires existent généralement déjà dans l'outil de gestion commerciale de l'entreprise, qui fait foi. Les ressaisir dans la boutique garantit qu'elles divergeront, et la question devient de savoir laquelle des deux sources a raison lors d'un litige. La bonne architecture consiste à ne saisir qu'à un endroit et à synchroniser, sujet développé dans notre article sur les connecteurs ERP et ce qu'ils font vraiment.

Les structures de données

Trois entités suffisent à couvrir la quasi totalité des besoins, à condition d'être correctement articulées. Leur simplicité est ce qui rend le système maintenable dans le temps.

Le groupe tarifaire

Rattacher chaque client à un groupe, plutôt que de lui attribuer des conditions individuelles, réduit considérablement le volume de données à gérer. Un distributeur, un revendeur et un installateur relèvent de trois grilles distinctes, chacune partagée par des dizaines de clients. Les conditions individuelles ne concernent alors que les quelques comptes réellement négociés, ce qui ramène le problème à une taille raisonnable. Cette structure permet aussi de modifier une grille entière en une opération. C'est la décision de modélisation qui a le plus d'effet sur la charge de maintenance. Un système à trois cents clients et huit groupes se gère confortablement, un système à trois cents jeux de conditions individuelles ne se gère pas du tout.

La règle de tarification

Une règle associe une cible, un produit, une famille ou l'ensemble du catalogue, à un bénéficiaire, un client ou un groupe, et à un effet, remise en pourcentage, remise fixe ou prix net. Cette structure unique couvre tous les cas rencontrés. Y ajouter une priorité explicite et des dates de validité facultatives complète le modèle. Une table de ce type, correctement indexée, se lit rapidement même avec plusieurs dizaines de milliers de lignes. Les index utiles portent sur le bénéficiaire et sur la cible, les deux critères employés à chaque résolution.

Le palier de quantité

Les paliers se rattachent à une règle plutôt qu'à un produit, ce qui permet d'en définir de différents selon le client. Chaque palier porte une quantité minimale et un effet, qui remplace celui de la règle au delà du seuil. Cette modélisation reste lisible et elle évite de créer une ligne par combinaison de client, produit et quantité. Le nombre de paliers doit rester modeste, trois à cinq suffisant à toutes les situations commerciales courantes. Au delà, la grille devient illisible pour l'acheteur et l'effet commercial recherché se dissout.

Le prix net contre la remise

Un prix net figé et une remise en pourcentage ne se comportent pas de la même façon lorsque le tarif public évolue. Le prix net reste inchangé, ce qui peut devenir une perte, la remise suit le tarif public, ce qui préserve la marge. Les acheteurs préfèrent le prix net, les vendeurs la remise, et l'arbitrage relève du commerce. Techniquement, les deux doivent être supportés, avec une alerte lorsqu'un prix net devient inférieur à un seuil de marge défini. Cette alerte doit remonter au commercial responsable du compte plutôt qu'à une adresse générique, faute de quoi personne ne la traitera.

La modélisation du catalogue lui même

Un catalogue professionnel comporte souvent des produits invisibles pour certains groupes, des conditionnements spécifiques et des références réservées. La visibilité doit donc être une propriété de la relation entre produit et groupe, et non une propriété du produit seul. Prévoir cette dimension dès le départ évite une reprise ultérieure lourde. Elle sert aussi lorsque l'entreprise ouvre une boutique grand public en parallèle, cas fréquent et rarement anticipé, ce qui rejoint les arbitrages de structure décrits dans notre article sur la manière de modéliser un catalogue produit en JSON.

L'historisation

Une commande doit conserver le prix appliqué et la règle qui l'a produit, et non se contenter de référencer le produit. Sans cette trace, il devient impossible de justifier un prix six mois plus tard, lorsque les conditions ont changé. Cette exigence est fondamentale et elle est régulièrement oubliée. Elle demande une colonne supplémentaire sur les lignes de commande et elle règle définitivement les discussions avec les acheteurs. Conserver également l'identifiant de la règle appliquée permet de reconstituer le raisonnement complet, ce qui vaut mieux que le seul montant.

L'ordre d'application des règles

Une fois les structures posées, la question devient celle de la résolution : quelle règle s'applique lorsque plusieurs correspondent. Y répondre par un ordre explicite et documenté est indispensable, faute de quoi le comportement dépend de l'implémentation et devient impossible à expliquer.

La règle la plus spécifique gagne

Le principe le plus lisible consiste à faire gagner la règle dont la cible est la plus précise : un prix net sur une référence l'emporte sur une remise de famille, qui l'emporte sur une remise générale. Ce classement correspond à l'intuition commerciale et il s'explique en une phrase à un acheteur. Il doit être implanté par un score de spécificité calculé plutôt que par une cascade de conditions, ce qui le rend extensible. C'est le modèle retenu par la plupart des systèmes matures. Il présente l'avantage de rester valable lorsqu'un nouveau niveau est ajouté, celui ci prenant simplement sa place dans l'échelle de spécificité.

Le non cumul par défaut

Les remises ne doivent pas s'additionner sauf décision explicite. Un client bénéficiant d'une remise de groupe et d'une remise personnelle ne doit pas obtenir la somme des deux, sauf si l'accord commercial le prévoit. Le cumul, lorsqu'il est voulu, doit être marqué sur la règle concernée par une propriété dédiée. Cette approche évite les surprises et elle rend le comportement prévisible. Le cumul silencieux est la source de fuite de marge la plus fréquente sur ce type de boutique. Il passe d'autant plus inaperçu qu'il ne produit aucune erreur, seulement un prix un peu plus bas que prévu.

L'articulation avec les promotions

Les opérations promotionnelles grand public coexistent souvent avec les tarifs négociés, et leur combinaison doit être arbitrée. Trois politiques existent : le meilleur des deux prix, le tarif négocié uniquement, ou le cumul. La première est la plus favorable au client et la plus simple à expliquer, la deuxième protège les marges négociées. Le choix doit être unique pour toute la boutique et écrit, chaque exception ouvrant la porte à des cas particuliers ingérables. Lorsqu'une exception est réellement nécessaire, elle doit être portée par une propriété de la règle plutôt que par du code spécifique.

Le plancher de marge

Un mécanisme empêchant qu'une combinaison de règles ne descende sous un prix plancher protège contre les erreurs de saisie. Ce plancher se définit par produit ou par famille et il déclenche une alerte plutôt qu'un blocage silencieux, afin que le commercial concerné soit informé. Sa mise en place demande une demi journée et elle évite des ventes à perte. C'est une sécurité que les entreprises regrettent systématiquement de ne pas avoir prévue. Une erreur de saisie sur un pourcentage, virgule mal placée, suffit à vendre un catalogue entier à un dixième de sa valeur pendant plusieurs heures.

La transparence du calcul

Un acheteur professionnel qui conteste un prix doit obtenir une explication. Afficher, dans l'interface d'administration, la liste des règles évaluées et celle qui a été retenue transforme une discussion pénible en vérification de trente secondes. Cette fonction de traçabilité coûte peu à développer et elle est presque toujours absente. Elle sert autant aux commerciaux qu'aux développeurs lors des diagnostics. Un affichage textuel simple, listant chaque règle candidate avec son score et son effet, suffit largement.

La performance de la résolution

Résoudre le prix de cinquante produits pour un client donné, sur chaque affichage de liste, peut devenir coûteux si chaque produit déclenche plusieurs requêtes. La bonne approche consiste à charger en une fois toutes les règles applicables au client, puis à résoudre en mémoire. Cette optimisation ramène le coût à une requête par page quelle que soit la longueur de la liste. Elle doit être prévue dès la conception, une reprise ultérieure supposant de réécrire toute la couche de tarification. La différence de temps de réponse entre les deux approches se compte en secondes sur une page de catégorie bien remplie.

Cache, synchronisation et contrôles

Les trois sujets qui font échouer les projets de ce type ne sont pas la modélisation mais l'exploitation quotidienne. Ils méritent autant d'attention que le reste.

Segmenter le cache

Toute page affichant un prix doit être mise en cache par groupe tarifaire, jamais globalement. Sur les rares clients ayant des conditions individuelles, la mise en cache doit être désactivée ou segmentée par client. Cette contrainte réduit l'efficacité du cache et elle n'est pas négociable. Servir un prix négocié à un autre client est un incident commercial grave, bien plus coûteux qu'une page un peu plus lente. Le compromis raisonnable consiste à mettre en cache tout ce qui n'affiche pas de prix et à laisser dynamique le seul bloc tarifaire.

Protéger les flux sortants

Les fils de données destinés aux comparateurs, les exports et les interfaces de programmation doivent exposer le tarif public et jamais les conditions négociées. Une clé d'interface donnant accès aux prix d'un client doit être limitée à ce client. Ce point est régulièrement négligé lors de l'ouverture d'une interface pour un partenaire, et il constitue une fuite d'information contractuelle. Un contrôle explicite doit être posé sur chaque flux sortant. La liste de ces flux mérite d'être tenue à jour, chaque ajout de partenaire en créant un nouveau.

Synchroniser dans un seul sens

Les conditions tarifaires doivent descendre de la gestion commerciale vers la boutique, jamais l'inverse, afin qu'une seule source fasse foi. Une synchronisation bidirectionnelle sur ce type de donnée produit inévitablement des conflits impossibles à arbitrer automatiquement. La fréquence doit être adaptée au rythme réel de renégociation, une synchronisation nocturne suffisant dans l'immense majorité des cas. Un mécanisme de rattrapage manuel doit exister pour les urgences. Un bouton déclenchant la synchronisation d'un seul client suffit et il évite d'attendre le traitement de nuit après une renégociation.

Détecter les divergences

Une comparaison périodique entre les prix calculés par la boutique et ceux calculés par la gestion, sur un échantillon de clients et de produits, révèle les écarts avant qu'un acheteur ne les signale. Ce contrôle se scripte et se lance chaque nuit. Il constitue le meilleur indicateur de santé du dispositif. Son absence conduit à découvrir les problèmes par les réclamations, ce qui coûte nettement plus cher. Un écart détecté et corrigé avant la commande ne coûte rien, le même écart facturé coûte un avoir et une explication.

Tester les cas limites

Un jeu de scénarios couvrant les situations à risque, client avec prix net et promotion en cours, franchissement de palier, produit invisible pour le groupe, client sans conditions, permet de valider chaque évolution. Ces cas doivent être rejoués après toute modification de la couche de tarification. Les construire une fois demande une journée et sert pendant toute la vie du projet. C'est l'investissement le plus rentable du sujet.

Documenter le modèle

Un schéma d'une page décrivant les niveaux, l'ordre de priorité, la politique de cumul et la source de vérité permet à un commercial de comprendre le système et à un développeur de ne pas le défaire. Sans ce document, chaque question sur un prix mobilise la personne qui a construit le système. Cette dépendance devient un risque dès qu'elle quitte l'entreprise, ce qui arrive toujours au mauvais moment.