Comment les données retail deviennent inutiles sans couche de décision
Il y a une question qui revient de plus en plus fréquemment dans les comités de direction retail, et qu'on n'osait pas formuler il y a encore quelques…
Il y a une question qui revient de plus en plus fréquemment dans les comités de direction retail, et qu'on n'osait pas formuler il y a encore quelques années. « On a tellement investi dans la data depuis cinq ans — data warehouse, data lake, Snowflake, Databricks, équipes data engineering, plateforme BI moderne, modèles prédictifs... où est le retour ? ». La question est polie. Elle est rarement frontale. Mais elle est de plus en plus présente, et de plus en plus difficile à esquiver. Parce que le constat est troublant. Les enseignes qui ont massivement investi dans leurs infrastructures data se retrouvent, dix ans après le début de la grande vague, avec des stacks remarquablement sophistiquées — pétaoctets de données collectées, modèles ML entraînés, dashboards d'une beauté graphique impressionnante. Et avec des KPI opérationnels qui n'ont, en moyenne, presque pas progressé. Les taux de démarque restent élevés. Les ruptures persistent. Les surstocks s'accumulent. La marge nette du secteur reste tendue. Ce paradoxe — masse de données accumulée mais performance inchangée — n'est pas un échec technique de la donnée. C'est l'expression d'une vérité que peu d'éditeurs et de cabinets veulent dire à voix haute : la donnée retail, à elle seule, ne produit aucune valeur. Elle ne devient utile qu'au moment où elle alimente une décision exécutée. Tant que cette dernière étape n'est pas franchie, tous les investissements amont — collecte, stockage, transformation, modélisation — restent du coût sans bénéfice. Cet article propose de regarder en face ce point aveugle : pourquoi accumuler de la donnée ne suffit pas, pourquoi les couches BI et data science ne comblent pas le gap, et ce qu'il faut construire pour que vos investissements data cessent d'être un centre de coût et deviennent enfin un levier de performance.
La promesse data des années 2015-2020 : revenir sur ce qu'on a vraiment vendu
Pour comprendre où nous en sommes, il faut revenir sur ce qui a été promis. À partir de 2015 environ, le retail a basculé dans une logique « data-driven » portée par trois récits convergents. Premier récit : « la donnée est le nouveau pétrole ». Une formule séduisante qui suggérait qu'il suffisait d'extraire, raffiner et stocker la donnée pour qu'elle libère de la valeur. Deuxième récit : « il faut casser les silos et créer un référentiel unique ». D'où la vague des data lakes, puis data lakehouses, censés devenir la source unique de vérité de l'entreprise. Troisième récit : « l'IA et le ML vont transformer le retail ». D'où les recrutements massifs de data scientists, les POC algorithmiques, les annonces de modèles propriétaires. Ces trois récits ne sont pas faux. La donnée a effectivement une valeur potentielle. Casser les silos est une bonne idée. L'IA peut produire de la valeur. Mais ils partagent un même biais implicite : ils traitent la donnée comme une fin en soi, alors qu'elle n'est qu'un moyen. Et ce biais a structuré une décennie d'investissements qui ont accumulé l'amont sans construire l'aval — c'est-à-dire la couche qui transforme la donnée en décision exécutée. Le résultat, c'est une situation que je qualifierais de « data riche, décision pauvre ». Les enseignes disposent désormais de tout ce dont elles auraient pu rêver en termes de matière première. Et elles ne savent toujours pas l'exploiter pour piloter leur réseau.
Le malentendu du « data-driven » : ce que ça ne veut pas dire
Il faut être précis sur le vocabulaire, parce que c'est là que se logent les confusions les plus coûteuses. Être « data-driven », ce n'est pas avoir beaucoup de données. Ce n'est pas non plus avoir de beaux dashboards. Ce n'est même pas avoir des modèles prédictifs sophistiqués. Toutes ces choses sont des conditions nécessaires mais largement insuffisantes. Être réellement data-driven, c'est avoir construit une chaîne complète où la donnée alimente la décision, où la décision alimente l'exécution, où l'exécution produit un retour mesuré, et où ce retour réalimente la donnée — sans rupture humaine intermédiaire systématique. C'est une propriété de bout en bout, pas une caractéristique de l'amont seul. Or dans la plupart des enseignes, le « data-driven » s'arrête à l'amont. La donnée est collectée, stockée, transformée. Elle est éventuellement modélisée. Elle est restituée dans des dashboards. Et puis... rien. Ou plutôt : un humain ouvre le dashboard, l'interprète à sa façon, formule une décision manuellement, et la fait exécuter par des équipes qui ne sont pas connectées au système data initial. Le retour de l'exécution, lui, ne revient presque jamais dans la chaîne data. Le résultat est une organisation qui a investi des dizaines de millions d'euros pour produire de la donnée descriptive de qualité, qu'elle consomme à 5 % de son potentiel parce qu'elle n'a pas construit la couche qui transformerait cette donnée en performance opérationnelle. C'est exactement ce que veut dire « data riche, décision pauvre ».
Les quatre stades de la valeur data — et pourquoi presque personne ne dépasse le stade 2
Pour rendre la chose plus précise, je propose un cadre simple en quatre stades. À chaque stade correspond un type de valeur produit, et à chaque stade correspond un type d'investissement nécessaire. Stade 1 : la donnée existe et est accessible. C'est le stade fondateur. Vos données de ventes, de stocks, de e-commerce, de supply chain sont collectées, nettoyées, stockées, accessibles via des requêtes. La plupart des retailers ont atteint ce stade, parfois imparfaitement, mais l'investissement initial est fait. À ce stade, la donnée n'a aucune valeur intrinsèque. Elle est juste là. Stade 2 : la donnée est restituée et compréhensible. C'est le stade BI classique. Vos données sont présentées dans des tableaux de bord, des rapports, des analyses ponctuelles. Les équipes peuvent les consulter, les explorer, en extraire des observations. La majorité des retailers se situent à ce stade. La valeur produite est descriptive : on sait ce qui s'est passé. Mais cette valeur reste largement potentielle — elle dépend entièrement de ce que les humains font de cette compréhension. Stade 3 : la donnée alimente une prescription automatique. C'est le stade où un système ne se contente plus de montrer la donnée, mais en tire automatiquement une recommandation d'action. Pas un humain qui ouvre un dashboard et réfléchit — un moteur qui balaye les données et formule, pour chaque SKU/magasin, ce qu'il faut faire (démarquer, transférer, réassortir, retourner). Très peu de retailers ont atteint ce stade, et ceux qui prétendent y être confondent souvent avec des alertes paramétrées qui ne sont pas de vraies recommandations contextualisées. Stade 4 : la prescription est exécutée et la boucle apprend. C'est le stade ultime où la recommandation se propage automatiquement vers les systèmes d'exécution (ERP, WMS, pricing, e-commerce), où son effet est mesuré, et où ce retour alimente le système pour ajuster les recommandations suivantes. À ce stade, la donnée produit enfin la valeur économique pour laquelle elle a été collectée. Une fraction très minoritaire des retailers — typiquement les leaders mondiaux — opère effectivement à ce niveau. Cette grille est utile pour une raison simple : elle révèle que passer du stade 2 au stade 4 est un saut qualitatif, pas une amélioration quantitative. On ne franchit pas ce saut en ajoutant plus de dashboards, plus de data scientists ou plus de capacité de stockage. On le franchit en construisant une couche de nature différente — la couche de décision et d'exécution — qui n'a presque rien à voir avec ce qui a été déployé en amont.
Pourquoi la couche descriptive ne devient jamais prescriptive « toute seule »
L'une des erreurs les plus coûteuses que commettent les directions retail, c'est de croire qu'en perfectionnant continuellement la couche descriptive (BI, dashboards, modèles), elles finiront par produire mécaniquement de la prescription. Cette croyance est commode parce qu'elle justifie les investissements en cours et reporte indéfiniment le moment de changer de paradigme. Mais elle est fausse, pour trois raisons structurelles. Raison n°1 : la BI ne formule pas de questions. Elle répond à celles qu'on lui pose. Tant qu'un humain doit ouvrir le dashboard et se demander « qu'est-ce que je devrais regarder aujourd'hui ? », l'écrasante majorité des situations qui méritent une action ne sont pas regardées du tout. Aucune amélioration de la BI ne change cette propriété — c'est inscrit dans son architecture. Raison n°2 : les modèles prédictifs prédisent, ils ne prescrivent pas. Un forecast à 92 % de précision ne dit toujours pas s'il faut démarquer, transférer ou ne rien faire. Ces décisions supposent une logique d'arbitrage que les modèles ne portent pas. On peut empiler des modèles de plus en plus sophistiqués, le saut prescriptif ne se fera pas spontanément. Raison n°3 : la couche descriptive n'exécute rien. Même si elle parvenait à produire une recommandation, il n'y a pas de canal automatique entre cette recommandation et les systèmes d'exécution. La décision doit être ressaisie par un humain dans un autre outil — ce qui produit délai, déperdition, perte de cohérence. La chaîne reste structurellement cassée. Tant que ces trois propriétés architecturales ne sont pas adressées par une couche dédiée, la couche descriptive restera ce qu'elle est : un coût d'infrastructure utile pour la culture data de l'organisation, mais sans impact direct mesurable sur la marge nette.
Le coût caché de la donnée non exploitée
Combien coûte cette situation où la donnée est accumulée mais non transformée en décision ? L'exercice est rarement fait honnêtement dans les enseignes, mais quand il l'est, les ordres de grandeur sont saisissants. Il faut additionner plusieurs postes. Premièrement, le coût direct de l'infrastructure data : licences cloud, ETL, plateformes BI, abonnements modèles. Pour un retailer de taille moyenne, c'est régulièrement entre 2 et 5 millions d'euros par an. Deuxièmement, le coût des équipes data : data engineers, data scientists, analystes BI, chefs de projet. Encore plusieurs millions d'euros. Troisièmement, le coût d'opportunité des projets qui ne livrent pas : POC algorithmiques qui n'aboutissent jamais en production, dashboards construits puis abandonnés, données collectées et jamais consultées. Mais le coût le plus important n'est pas dans la facture des projets data. Il est dans le manque à gagner opérationnel. Une enseigne qui dispose de toutes les données nécessaires pour optimiser ses décisions, mais qui continue à prendre ses décisions à la main parce qu'elle n'a pas la couche prescriptive, supporte un coût d'opportunité qui se chiffre en plusieurs points de marge nette par an. Sur un retailer générant 500 M€ de chiffre d'affaires, c'est 5 à 15 millions d'euros par an de marge récupérable qui restent sur la table. Cumulé sur une décennie d'investissements data sans couche de décision, on parle de plusieurs dizaines de millions d'euros de potentiel non réalisé. Et la facture continue à courir tant que la couche prescriptive n'est pas mise en place.
Le paradoxe : plus on a de données, plus l'absence de couche de décision coûte cher
Voici la dynamique qui rend la situation actuelle si particulière. Plus une enseigne accumule de données de qualité, plus l'absence de couche de décision devient économiquement absurde — parce que la valeur potentielle non réalisée croît à mesure que la matière première s'enrichit. Une enseigne avec peu de données et pas de couche de décision a peu à gagner d'en construire une — elle manque de matière première. Une enseigne avec énormément de données et pas de couche de décision a énormément à gagner — sa matière première est sous-exploitée à un niveau industriel. C'est exactement la situation dans laquelle se trouvent la plupart des grandes enseignes retail aujourd'hui : elles ont passé dix ans à enrichir l'amont, et chaque année qui passe sans construire l'aval rend le gap plus coûteux à supporter. Cette dynamique inversée — « plus on a investi, plus on perd à ne pas franchir l'étape suivante » — n'est pas intuitive. Mais elle est mathématiquement implacable. Et elle explique pourquoi les directions data les plus lucides commencent aujourd'hui à orienter leurs investissements non plus vers l'amont (où le rendement marginal s'effondre) mais vers la couche prescriptive (où le rendement marginal explose).
Ce qu'il faut construire : une couche de décision dédiée
Construire une couche de décision n'est pas une extension naturelle de votre stack data actuelle. C'est un projet de nature différente, qui suppose des choix d'architecture spécifiques. Premièrement, une logique de prescription continue. Le système doit balayer en permanence l'ensemble des données disponibles, identifier les situations qui méritent une action, et formuler la recommandation adaptée. Pas attendre qu'un humain pose la question. Pas se limiter aux situations atteignant un seuil paramétré. Une surveillance continue, contextuelle, prescriptive. Deuxièmement, une intégration des règles métier comme citoyen de première classe. Les recommandations doivent respecter par construction les contraintes opérationnelles de l'enseigne — planchers de marge, contraintes fournisseurs, calendriers commerciaux, traitements spécifiques. Sans cette intégration, les recommandations sont théoriquement optimales mais pratiquement inapplicables. Troisièmement, une exécution sans rupture. Les décisions validées doivent se propager dans les systèmes d'exécution existants sans ressaisie. Le délai entre la formulation d'une recommandation et son effet réel sur le terrain doit être compatible avec la dynamique commerciale — quelques heures, pas quelques jours. Quatrièmement, une boucle de retour mesurable. L'effet de chaque décision exécutée doit être mesuré et intégré au système pour ajuster les décisions suivantes. C'est cette boucle d'apprentissage qui transforme une couche de décision figée en système de plus en plus intelligent à chaque cycle. Une plateforme qui porte ces quatre capacités transforme radicalement la valeur de votre stack data existante. Vos données cessent d'être un coût d'infrastructure pour devenir le carburant d'un système de décision qui produit, mesurablement, de la marge. Et la question gênante du retour sur investissement data trouve enfin une réponse positive.
La trappe à éviter : reconstruire son stack data avant d'ajouter la couche de décision
Une dernière mise en garde, parce qu'elle coûte cher aux retailers qui tombent dedans. Quand les directions data prennent conscience du gap entre leur stack actuelle et la couche de décision dont elles ont besoin, la tentation est souvent de reconstruire l'amont avant d'ajouter l'aval. « Avant de construire la couche de décision, il faut d'abord moderniser notre data warehouse, refondre nos modèles, améliorer la qualité de nos données. » Cette logique est presque toujours une erreur. Pour deux raisons. Premièrement, elle reporte indéfiniment le moment où la valeur sera réellement produite. Une refonte data lake dure typiquement 18 à 36 mois. Pendant tout ce temps, l'organisation continue à supporter le coût d'opportunité de l'absence de couche de décision — qui se chiffre en millions par an. Deuxièmement, et c'est le point clé, la qualité parfaite de la donnée n'est pas un prérequis à la couche de décision. Une couche de décision moderne, bien conçue, sait composer avec des données imparfaites, identifier les zones de faible qualité, demander des compléments, prioriser les décisions là où la donnée est suffisamment fiable. Elle n'attend pas que tout soit parfait pour commencer à produire de la valeur — et en commençant à produire de la valeur, elle finance souvent les améliorations data dont elle a besoin. La bonne approche est donc inverse de l'intuition habituelle : commencer par la couche de décision sur l'existant, identifier les zones où elle bute sur la qualité data, et faire évoluer la donnée en fonction des besoins de la couche prescriptive. Pas l'inverse.
L'approche Solya : transformer votre stack data en levier de décision
C'est précisément la philosophie de Solya. Pas un nouveau data lake. Pas un énième outil de BI. Pas un modèle ML supplémentaire. Mais la couche de décision et d'exécution qui transforme vos investissements data existants en performance opérationnelle mesurable. Concrètement, Solya se connecte à vos sources de données — POS, ERP, e-commerce, supply chain, data lake existant — et reconstruit une vue exploitable au niveau SKU/magasin, mise à jour en continu. Le moteur de décision balaye cette vue en permanence pour identifier les situations qui méritent une action, formule pour chacune une recommandation contextualisée intégrant vos règles métier et vos contraintes opérationnelles, et propage les décisions validées vers vos systèmes d'exécution sans ressaisie. L'effet observé alimente en retour le moteur pour ajuster les décisions suivantes. Le changement de paradigme est simple à formuler. Vous avez investi pour avoir beaucoup de données. Solya ajoute la couche qui transforme ces données en marge. Vos infrastructures data existantes ne sont pas remplacées — elles deviennent enfin rentables, parce qu'elles sont désormais branchées sur un système qui exploite leur potentiel jusqu'au bout de la chaîne. Pour les directions data, c'est aussi une réponse à la question gênante du retour sur investissement. Au lieu de devoir continuer à justifier des budgets data sur des promesses d'usage futur, on peut désormais les justifier sur de la marge récupérée mesurable. C'est un changement de positionnement qui transforme la fonction data, d'un centre de coût toléré à un levier de performance reconnu.
La vraie question à se poser
Quelle proportion des données que vous collectez aujourd'hui produit-elle effectivement de la marge récupérée pour votre organisation ? Pas combien sont stockées. Pas combien sont consultées dans vos dashboards. Combien alimentent une décision opérationnelle exécutée qui n'aurait pas été aussi bonne sans elles. Si la réponse est « une fraction marginale », vous vivez le paradoxe que cet article décrit : une organisation data riche mais décision pauvre. Et chaque année qui passe sans construire la couche prescriptive aggrave le coût d'opportunité que vous supportez. La sortie de ce paradoxe n'est pas dans plus de données, plus de modèles, ou plus de dashboards. Elle est dans le franchissement du palier qui transforme la donnée en décision exécutée. Et c'est ce palier, plus que toute autre transformation, qui sépare aujourd'hui les retailers qui rentabilisent réellement leurs investissements data de ceux qui les accumulent en espérant qu'un jour, ils finiront par produire la valeur promise.
Vos données produisent-elles vraiment de la marge ?
Chez Solya, nous proposons aux directions retail un diagnostic personnalisé de 30 minutes pour évaluer, sur votre propre contexte, le taux d'exploitation réel de vos investissements data — et chiffrer le potentiel de marge récupérable par l'ajout d'une couche de décision prescriptive au-dessus de votre stack existante. 👉 [Réservez votre diagnostic Solya] — 30 minutes, en visio, avec un de nos experts retail. À l'issue de cet échange, vous repartirez avec :
- Une cartographie du taux d'exploitation réel de vos investissements data
- Une estimation chiffrée du potentiel de marge récupérable par une couche de décision
- Les premiers cas d'usage à fort ROI pour transformer votre stack data en levier opérationnel
Articles similaires
Les 3 erreurs classiques dans les projets data retail (et pourquoi elles échouent après le POC)
Il existe dans le retail un phénomène silencieux mais massif : le cimetière des POC data. Pour chaque projet data retail qui finit en production avec un…
Les 5 signaux faibles qui indiquent qu’un produit doit être liquidé (mais que vos systèmes ignorent)
Dans la vie d'un produit retail, il y a un moment charnière. Un moment précis où il bascule, sans bruit, du statut de référence active à celui de futur…
Pourquoi automatiser un workflow ne suffit pas si la décision reste manuelle
Depuis cinq à sept ans, l'automatisation des workflows s'est imposée comme l'un des grands chantiers des directions retail. RPA, orchestrateurs no-code,…