Pricing, achats, category managementsortir des fichiers séparés
.avif)
Le prix final résulte de trois apports distincts (achats (conditions fournisseur), category management (assortiment), pricing (arbitrage)) et 85 % des entreprises jugent avoir une marge de progression significative sur leur pricing (Bain & Company, 2018), souvent faute de workflow partagé entre ces trois fonctions. La question du workflow partagé reste distincte de celle de la gouvernance décisionnelle : l'une porte sur l'information disponible, l'autre sur le mandat de trancher.
Un prix n'est jamais décidé par une seule fonction, même quand un seul fichier porte le nom « pricing ». Les achats détiennent les conditions fournisseur, le category management pilote l'assortiment et l'espace en rayon, le pricing arbitre le prix final, et ces trois fonctions travaillent trop souvent sur trois fichiers qui ne se parlent pas.
Ce guide détaille le coût réel de ce cloisonnement, distinct de la question de savoir qui a le dernier mot sur un prix, et ce qu'implique concrètement un workflow partagé entre ces trois métiers.
Trois métiers, trois fichiers, une seule décision de prix
Dans une organisation retail typique, le prix final d'un produit résulte de trois apports distincts. Les achats négocient les conditions fournisseur, coût d'achat, remises, conditions logistiques. Le category management pilote l'assortiment, l'espace en rayon et la cohérence de l'offre par catégorie. Le pricing arbitre le prix de vente final, en tenant compte de ces deux apports et du positionnement concurrentiel.
Ces trois fonctions ont chacune leur outil de suivi, souvent un fichier Excel propre à leur périmètre. Le problème n'est pas l'existence de ces fichiers en tant que tels, c'est qu'ils ne se parlent pas. Un ajustement de condition d'achat négocié un lundi peut n'atteindre le fichier pricing que plusieurs semaines plus tard.
Le coût invisible d'un workflow non partagé
85 % des entreprises jugent avoir une marge de progression significative sur leur pricing, alors même que le sujet est identifié comme prioritaire, selon Bain & Company, enquête menée auprès de 1 700+ entreprises (Is Pricing Killing Your Profits?, 2018).
Ce décalage entre priorité affichée et résultats obtenus a plusieurs causes, mais l'une des plus fréquentes reste opérationnelle plutôt que stratégique : le pricing n'a pas accès, au bon moment, aux informations détenues par les achats et le category management. Ce n'est pas un manque d'intention, c'est un manque de plomberie entre les fonctions.
Le coût de ce cloisonnement reste largement invisible tant qu'il n'est pas mesuré explicitement : une marge légèrement erronée sur un produit ne déclenche aucune alerte. C'est un coût diffus, réparti sur des milliers de décisions individuelles, mais réel et cumulatif.
Ce que « collaboratif » veut dire concrètement
Achats, conditions visibles en temps réel : une négociation fournisseur actualisée doit être visible du pricing sans attendre un point de synchronisation manuel.
Category management, impact marge visible avant décision : un plan d'assortiment doit pouvoir intégrer une estimation d'impact marge, pas seulement d'espace disponible.
Pricing, arbitrage sur des données à jour : un prix fixé sur une condition d'achat périmée produit une décision fausse dès le départ.
Les trois, workflows de validation croisés : une modification significative d'un côté déclenche une notification de l'autre.
Un exemple de désynchronisation courante
Un scénario revient régulièrement : les achats obtiennent une amélioration de condition fournisseur sur une référence. Le category management prépare une opération de mise en avant sur cette même référence. Le pricing, informé ni de l'un ni de l'autre, arbitre sur la base d'un coût d'achat déjà obsolète.
Résultat : une marge calculée fausse, une opération de mise en avant qui n'exploite pas la nouvelle condition d'achat, et une correction découverte des semaines plus tard, si elle l'est. Le problème est structurel, pas humain.
Construire une vue commune sans fusionner les métiers
Chez Booper, la logique de Pricing Analytics chez Booper n'est pas de réunir pricing, achats et category management dans une seule équipe, chacun garde son périmètre. Elle consiste à leur donner accès à une vue partagée des données qui alimentent la décision de prix, conditions d'achat, plan d'assortiment, marges en temps réel, avec des workflows de validation qui notifient chaque fonction quand une donnée qui la concerne change ailleurs.
Ce qui change quand les trois fonctions partagent leurs données
1. Les décisions s'appuient sur des données à jour, une condition d'achat renégociée se répercute immédiatement dans le calcul de marge.
2. Les opérations commerciales gagnent en cohérence, une mise en avant peut être calée sur une amélioration de condition d'achat.
3. Le temps de recollement disparait, les réunions de synchronisation manuelle cèdent la place à une visibilité continue.
4. Les erreurs de marge deviennent visibles avant, pas après, un écart entre coût réel et coût utilisé se détecte au moment de la décision.
Les erreurs qui pérennisent les fichiers séparés
- Considérer que c'est un problème d'organigramme. Réorganiser les équipes sans changer le workflow reproduit le même cloisonnement.
- Attendre une réunion pour synchroniser les données. Un point trimestriel ne suffit pas à corriger des décisions prises entre-temps.
- Confondre vue partagée et décision partagée. Donner accès à la même information ne signifie pas que chaque fonction doit valider les décisions des deux autres.
- Ne mesurer le coût du cloisonnement qu'après un incident visible. Le coût existe en continu, bien avant qu'une erreur de marge ne devienne assez grosse pour être remarquée.
Questions fréquentes
Parce que chaque fonction a historiquement son propre outil de suivi, sans qu'aucun système commun ne les relie. Le problème n'est pas l'existence de ces fichiers en tant que tels, c'est qu'ils ne se parlent pas : un ajustement de condition d'achat négocié un lundi peut n'atteindre le fichier pricing que plusieurs semaines plus tard.
Des décisions prises sur des informations partielles ou périmées, ce coût reste largement invisible tant qu'il n'est pas mesuré explicitement. C'est un coût diffus, réparti sur des milliers de décisions individuelles (une marge légèrement erronée sur un produit ne déclenche aucune alerte) mais réel et cumulatif à l'échelle d'un catalogue complet.
Non, ce n'est pas une question d'organigramme mais de workflow. Les trois fonctions gardent leur périmètre propre. Réorganiser les équipes sans changer le workflow reproduit le même cloisonnement sous une autre forme, c'est la vue partagée, pas la fusion, qui corrige le problème.
En centralisant les données qui alimentent la décision de prix dans un système partagé avec des workflows de validation croisés. Concrètement : les conditions d'achat visibles en temps réel côté pricing, l'impact marge visible avant décision côté category management, et une notification croisée dès qu'une donnée qui concerne une autre fonction change quelque part.
Oui. La gouvernance décisionnelle porte sur qui a le mandat de trancher. Le workflow partagé porte sur la disponibilité de l'information au moment de trancher. Une vue partagée ne signifie pas une décision partagée : donner accès à la même information aux trois fonctions ne veut pas dire que chacune doit valider les décisions des deux autres.
À lire aussi dans ce dossier : Avant de déployer un outil de pricing, fiabilisez votre donnée · Changer d'outil de pricing sans reproduire ses erreurs · Piloter ses rangs tarifaires avec peu de données de vente.
Un POC de pricing repose sur cinq familles de données : le référentiel produit, les ventes à la maille produit, jour, point de vente et canal, les stocks, les conditions d'achat avec une règle de valorisation choisie, et l'historique des prix réellement pratiqués et des promotions. Les enrichissements (relevés concurrents, parts de marché, trafic web) sont utiles mais ne conditionnent pas le démarrage.
Ce qui transforme ces extractions en socle exploitable, c'est le contrôle de cohérence : le chiffre d'affaires, les volumes et la marge recalculés à partir des données doivent retomber sur ceux du contrôle de gestion, mois par mois et catégorie par catégorie, avant toute recommandation. Un socle validé une fois sert ensuite à tous les éditeurs consultés.
Le modèle est la partie facile. Un moteur de recommandation fonctionne en quelques mois ; ce qui prend des années, c'est le référentiel, l'appariement concurrentiel, le parc de règles, l'explicabilité et la conformité. D'après Exclaimer (2025), 71 % des développements internes finissent abandonnés, et 83 % dans les secteurs réglementés : le point de rupture n'est presque jamais la mise en service, c'est l'entretien.
Le coût caché est un coût de continuité : un outil interne repose sur deux ou trois personnes, et leur départ transforme l'actif en passif. Le build garde du sens sur un périmètre étroit et stable, en complément d'une solution plutôt qu'à sa place. Le critère de choix n'est pas la compétence de l'équipe, c'est sa capacité à tenir dix ans.
Donnée et contexte sont deux actifs différents : la donnée décrit ce qui s'est passé, le contexte explique ce qu'on a le droit de faire et ce qui serait absurde. Ce contexte est tacite par nature : il n'a jamais été écrit parce qu'il n'a jamais eu besoin de l'être tant que les décisions étaient prises par des humains qui le partageaient.
Quatre familles en couvrent l'essentiel : les repères de prix, les contraintes relationnelles, les interdits non écrits et les intentions commerciales par catégorie. Les formaliser a une valeur durable, car le contexte survit aux modèles : les algorithmes se remplacent tous les deux ou trois ans, un contexte écrit reste un actif de l'entreprise.