Distributeur B2B industriel — E-commerce Medusa.js avec tarifications client complexes
Stack Akeneo + Medusa.js. Les commandes en ligne sont passées de 32 % à 71 % du chiffre d'affaires en 12 mois. La charge du service commercial téléphonique a reculé de 42 %. Le marché allemand a été ouvert en 6 semaines contre 6 mois historiquement.
Durée
Projet séquencé en cinq phases (cadrage, PIM Akeneo, moteur Medusa.js, pilote sur panel de comptes, généralisation), puis ouverture du marché allemand en 6 semaines. Résultats mesurés 12 mois après la bascule.
Équipe
5 experts
Technologies clés
71 %
Part du chiffre d'affaires réalisée en commandes en ligne à 12 mois
32 %
Part du chiffre d'affaires en commandes en ligne avant projet (baseline)
+39 points
Progression de la part des commandes en ligne en 12 mois (32 % à 71 %)
-42 %
Charge du service commercial téléphonique — sans suppression de poste
#Contexte : un catalogue en ligne, des commandes au téléphone
Distributeur B2B industriel français : pièces techniques et 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 existait déjà, 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 continuait de commander par téléphone ou via son commercial — le seul canal capable de restituer son prix réel. Les commandes en ligne plafonnaient à 32 % du chiffre d'affaires.
Le sujet n'était donc ni une question d'audience ni d'ergonomie, mais de moteur : la plateforme ne savait pas calculer le bon prix pour le bon client. Tant que ce point restait ouvert, aucun budget marketing n'aurait déplacé l'aiguille.
#L'enjeu : la tarification, pas la vitrine
Trois contraintes structuraient le 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 devait ê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'était 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 prenait historiquement six mois, parce qu'il fallait 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 ROI 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 a validé 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 a été argumenté 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 a mis au jour un écart classique entre règles documentées et règles réellement appliquées dans l'ERP ; leur réconciliation faisait 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 a été 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 du marché allemand, traitée comme un test de l'architecture.
#Résultats mesurés à 12 mois
Les commandes en ligne sont passées de 32 % à 71 % du chiffre d'affaires en douze mois, soit une progression de 39 points. Le canal digital est devenu majoritaire sans campagne d'acquisition : les clients existants ont basculé dès lors que la plateforme affichait leur prix.
La charge du service commercial téléphonique a reculé de 42 %. Aucun poste n'a été supprimé — le temps libéré a été réaffecté au suivi de compte et à la prospection, conformément à l'engagement pris auprès des équipes.
L'ouverture du marché allemand a pris 6 semaines, contre 6 mois historiquement. La donnée produit étant 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. La baisse de charge téléphonique n'a été acceptée en interne que parce qu'elle était 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.
Résultats mesurés à 12 mois
Commandes en ligne : 32 % à 71 % du chiffre d'affaires en 12 mois, soit +39 points
Charge du service commercial téléphonique : -42 %, à effectif constant
Ouverture du marché allemand : 6 semaines contre 6 mois historiquement
Référentiel produit unique dans Akeneo — fin de la reprise manuelle de catalogue par marché
Grilles tarifaires par compte portées par Medusa.js, ERP conservé comme source de vérité commerciale
Bascule sans campagne d'acquisition : la migration vient du portefeuille de comptes existant
L'essentiel sur ce cas client
Distributeur B2B industriel français anonymisé NDA. Une plateforme de vente existait déjà, mais elle n'affichait que des prix publics : les clients sous conditions négociées continuaient de commander par téléphone. Les commandes en ligne plafonnaient à 32 % du chiffre d'affaires.
Diagnostic Nehos : ce n'était pas un sujet d'ergonomie mais un sujet de moteur. La plateforme ne savait pas calculer le bon prix pour le bon client. Architecture retenue : Akeneo comme référentiel produit unique, Medusa.js comme moteur de commerce portant les grilles tarifaires par compte, l'ERP restant source de vérité commerciale.
Résultats à 12 mois : commandes en ligne à 71 % du chiffre d'affaires, soit une progression de 39 points. Charge du service commercial téléphonique en baisse de 42 %, sans suppression de poste — le temps libéré a été réaffecté au suivi de compte.
Effet de socle : l'ouverture du marché allemand a pris 6 semaines contre 6 mois historiquement, la donnée produit étant déjà centralisée et structurée pour le multilingue dans le PIM.
Questions fréquentes sur ce cas client
Le NDA signé couvre l'identité de l'entreprise, sa structure tarifaire et son portefeuille de comptes. Sur un marché de distribution industrielle très disputé, la grille de prix et la composition du portefeuille clients sont directement exploitables par un concurrent. Les chiffres publiés ici sont réels et auditables par Nehos sur demande, sous NDA réciproque.
Parce que la logique tarifaire de ce distributeur est son avantage concurrentiel. Les règles s'empilent : grille par compte, paliers de volume, remises par famille, conditions spécifiques, tarifs contractuels à durée déterminée. Avec une suite SaaS, ce type de logique se contourne par des développements périphériques fragiles. Medusa est un moteur open source Node.js dont le module de prix est extensible : la règle métier vit dans le code, elle est testable et versionnée. Ce raisonnement ne vaut pas partout — pour un catalogue à prix publics, une suite SaaS reste souvent le bon choix.
Parce que l'ordre inverse est la cause d'échec la plus fréquente sur les projets B2B. On livre une plateforme correcte alimentée par des données produit incomplètes, les clients ne trouvent pas ce qu'ils cherchent, ils reprennent le téléphone, et le projet est considéré comme raté alors que le problème est en amont. Ici, Akeneo a été livré et adopté par les équipes produit avant qu'un client ne voie le nouveau front.
L'ERP reste la source de vérité commerciale : Medusa expose la grille, il ne l'invente pas. Pendant la phase pilote, chaque commande du panel a fait l'objet d'une réconciliation entre prix affiché en ligne et prix ERP, ce qui a permis d'identifier les cas limites avant la généralisation. Cette phase a aussi révélé des écarts préexistants entre les règles documentées et les règles réellement appliquées dans l'ERP — leur réconciliation faisait partie du périmètre.
Non. La charge du service commercial téléphonique a baissé de 42 %, mais à effectif constant : le temps libéré a été réaffecté au suivi de compte, au conseil technique et à la prospection. C'était un engagement pris auprès des équipes dès le lancement, et une condition de réussite — ce sont les commerciaux qui accompagnent leurs clients vers la plateforme. Un projet perçu comme une menace sur l'emploi aurait été freiné par ceux-là mêmes qui devaient le porter.
Par le socle, pas par un effort exceptionnel. Historiquement, chaque nouveau marché imposait de reprendre et de traduire à la main des données produit dispersées entre l'ERP, des tableurs et le site — six mois de travail. Avec un référentiel unique dans Akeneo, structuré pour le multilingue dès l'origine, ouvrir un marché relève de la déclinaison. C'est pour nous la mesure la plus honnête de la qualité d'une architecture : ce n'est pas le premier déploiement qui la valide, c'est le second.
La méthode l'est, les résultats ne se recopient pas. Le déclencheur ici était très identifiable : des clients prêts à commander en ligne, empêchés par une plateforme incapable d'afficher leur prix contractuel. Si ce verrou n'existe pas chez vous, la bascule ne se produira pas au même rythme. C'est précisément pour cela qu'on chiffre le ROI avant de signer : le business case se construit sur votre baseline, pas sur celle d'un autre.