Pricing, achats, category managementsortir des fichiers séparés
September 4, 2026
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 disparaît, 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 outil de pricing exécute fidèlement la donnée qu'on lui fournit — la qualité du résultat dépend d'abord de la qualité de la donnée en amont. Trois chantiers sont prioritaires avant tout paramétrage : un référentiel produit sans doublon, des prix et coûts synchronisés, un historique de vente continu. Inutile d'attendre une donnée parfaite pour démarrer : un point d'entrée par fichiers permet de fiabiliser progressivement.
Un premier outil sous-exploité contient une information précieuse — les causes précises de l'échec d'adoption, à diagnostiquer avant de changer — et le CHAOS Report du Standish Group rappelle que seuls 31 % des projets IT aboutissent pleinement, 50 % sont livrés avec compromis et 19 % échouent totalement. La reprise des données existantes (historique, catalogue, règles) doit être un critère explicite du cahier des charges, pas une option.
La majorité des projets de pricing démarrent par un simple import de fichiers déjà exportables, pas par une intégration API — trois niveaux d'intégration existent (import de fichiers, connecteur planifié, intégration API temps réel), et l'absence de connecteur ne doit jamais être un motif pour reporter un projet de pricing.