Exemple de situation — Distributeur B2B industriel : e-commerce Medusa.js avec tarifications client complexes

#Contexte : un catalogue en ligne, des commandes au téléphone

Ce cas est un exemple de situation, construit pour illustrer notre méthode : il ne décrit aucun client réel et ne contient aucun résultat chiffré.

Le profil : un distributeur B2B de pièces techniques et de consommables pour des clients professionnels sous contrat. Comptes ouverts, conditions négociées compte par compte, relation directe entre le client et son commercial référent — un profil classique du secteur E-commerce & Retail côté distribution.

Une plateforme de vente en ligne existe, mais sur un périmètre étroit : catalogue simplifié, prix publics, aucune prise en compte des conditions contractuelles de chaque compte. Conséquence mécanique, la majorité des clients continue de commander par téléphone ou via son commercial — le seul canal capable de restituer son prix réel.

Le sujet n'est donc ni une question d'audience ni d'ergonomie, mais de moteur : la plateforme ne sait pas calculer le bon prix pour le bon client. Tant que ce point reste ouvert, aucun budget marketing ne déplacera l'aiguille.

#L'enjeu : la tarification, pas la vitrine

Trois contraintes structurent ce type de projet, posées avant le chiffrage.

Première contrainte, l'exactitude tarifaire. En B2B, un prix erroné n'est pas un défaut d'affichage, c'est un incident commercial : une commande hors grille contractuelle se règle par un avoir, parfois par une renégociation. Le moteur doit être aussi fiable que l'ERP, sur des règles qui s'empilent — grille par compte, paliers de volume, remises par famille, conditions spécifiques, tarifs contractuels.

Deuxième contrainte, ne pas casser le canal téléphonique. L'objectif n'est pas de supprimer la relation commerciale mais de la libérer : sortir les commerciaux de la saisie répétitive pour les réorienter vers le conseil.

Troisième contrainte, l'expansion. Ouvrir un marché européen prend du temps quand il faut dupliquer et retraduire à la main des données dispersées entre l'ERP, des tableurs métier et le site.

#La solution : PIM d'abord, moteur de commerce ensuite

Notre position est constante : on chiffre le bénéfice attendu avant de signer, on livre, on mesure. Le business case s'appuie sur trois postes mesurables — part de chiffre d'affaires transférable en ligne, coût de traitement d'une commande téléphonique, coût d'ouverture d'un marché. C'est ce chiffrage, pas une conviction technologique, qui valide l'architecture : une stack de commerce composable en deux briques.

Akeneo PIM joue le rôle de référentiel produit unique : donnée catalogue centralisée, structurée par famille et par attributs, enrichie selon un workflow avec responsables et niveaux de complétude, multilingue dès l'origine. C'est la brique qui conditionne le reste — sans donnée produit propre, une plateforme B2B ne se vend pas, elle se subit.

Medusa.js porte le moteur de commerce, en architecture headless. Le choix s'argumente devant la direction : la logique tarifaire de ce distributeur est son avantage concurrentiel, elle devait vivre dans du code maîtrisé plutôt qu'être tordue pour rentrer dans les limites d'une suite SaaS — arbitrage détaillé dans notre comparatif Hydrogen vs Magento vs Medusa.

Medusa permet d'étendre le module de prix et d'exposer à chaque compte connecté sa propre grille, récupérée depuis l'ERP qui reste source de vérité commerciale.

#Déroulé de la mission

Cadrage. Audit du référentiel produit, cartographie exhaustive des règles tarifaires, business case chiffré. Cette phase met souvent au jour un écart classique entre règles documentées et règles réellement appliquées dans l'ERP ; leur réconciliation fait partie du périmètre.

PIM. Mise en place d'Akeneo, reprise et enrichissement du catalogue, appropriation du workflow par les équipes produit. Le PIM est livré et adopté avant qu'une ligne du nouveau front ne soit visible.

Moteur. Implémentation Medusa.js, synchronisation des comptes et des grilles depuis l'ERP, puis développement sur mesure des parcours propres au B2B : commande sur référence, réassort, import de listes, comptes multi-utilisateurs, validation hiérarchique.

Pilote. Ouverture à un panel de comptes volontaires accompagnés par leurs commerciaux, avec réconciliation systématique entre prix affiché et prix ERP — corriger les cas limites sans exposer tout le portefeuille.

Généralisation, puis ouverture d'un nouveau marché, traitée comme un test de l'architecture.

#Ce que l'on mesure

Aucun résultat chiffré n'est publié ici : il s'agit d'un exemple de situation. Sur un projet de ce type, nous mesurons, avant puis après, la part des commandes passées en ligne, la charge du service commercial téléphonique, le délai d'ouverture d'un nouveau marché et l'écart entre prix affiché et prix ERP.

Le canal digital peut devenir majoritaire sans campagne d'acquisition : les clients existants basculent dès lors que la plateforme affiche leur prix. Le temps libéré chez les commerciaux a vocation à être réaffecté au suivi de compte et à la prospection, conformément à l'engagement pris auprès des équipes.

Quand la donnée produit est centralisée et déjà structurée pour le multilingue, un nouveau marché ne demande plus un chantier de reprise mais une déclinaison.

#Enseignements

Le PIM avant le commerce. En B2B, l'ordre inverse est la cause d'échec la plus fréquente : on livre une plateforme correcte alimentée par des données incomplètes, les clients ne trouvent pas, ils reprennent le téléphone.

La tarification est une décision d'architecture, pas une fonctionnalité. Un distributeur dont les prix sont contractuels et multi-règles ne choisit pas sa plateforme sur un catalogue de fonctionnalités, mais sur sa capacité à héberger sa logique de prix sans contorsion. L'inverse vaut aussi : pour un catalogue à prix publics, une suite SaaS reste souvent le bon choix.

Le digital soulage la force de vente, il ne la remplace pas. Une baisse de charge téléphonique n'est acceptée en interne que si elle est annoncée comme un transfert, pas comme une coupe.

Le deuxième marché est le vrai test. Le premier déploiement valide des fonctionnalités, le second valide l'architecture — et c'est la TMA qui préserve ensuite ce socle. Voir aussi notre cas d'usage e-commerce B2B.