Du forecasting à la décision : pourquoi les modèles ML ne suffisent pas en retail
Depuis quelques années, le discours est devenu omniprésent dans le retail. « On va mettre du machine learning. » « Notre nouveau forecast atteint 92 % de…
Depuis quelques années, le discours est devenu omniprésent dans le retail. « On va mettre du machine learning. » « Notre nouveau forecast atteint 92 % de précision. » « On a entraîné un modèle de demande au SKU/magasin. » Les directions data des grandes enseignes se sont équipées, les éditeurs ont multiplié les offres, et il n'est plus rare de croiser des projets de forecasting embarquant plusieurs data scientists à temps plein. Et pourtant, quand on regarde les résultats opérationnels — taux de rupture, niveau de surstock, taux de démarque, performance de réassort — la situation a remarquablement peu bougé dans la plupart des enseignes. Les forecasts sont plus précis qu'il y a cinq ans. Les décisions, elles, restent largement sous-optimales. Cette dissonance n'est pas un échec du machine learning. C'est l'expression d'un malentendu structurel sur ce qu'un modèle ML peut, et ne peut pas, faire dans un contexte retail. Un forecast n'est pas une décision. Et tant que cette distinction n'est pas comprise — et surtout, traduite dans l'architecture des plateformes — les investissements en data science continueront à produire de très belles prédictions qui ne changent rien à la performance terrain. Cet article propose de regarder en face ce gap entre forecasting et décision : pourquoi il existe, pourquoi il est aussi tenace, et ce qu'il faut mettre en place pour le franchir.
Le malentendu fondateur : confondre prédire et décider
Dans la plupart des projets data retail des dix dernières années, le raisonnement implicite a été le suivant : « si on prédit mieux la demande, on prendra mécaniquement de meilleures décisions. » Cette idée semble du bon sens. Elle est pourtant profondément fausse. Un forecast, aussi précis soit-il, ne dit qu'une seule chose : combien d'unités de tel produit risquent d'être vendues dans tel magasin sur tel horizon. Il ne dit pas si vous devez réassortir, démarquer, transférer, ou ne rien faire. Il ne dit pas à quelle profondeur démarquer. Il ne dit pas vers quel magasin transférer. Il ne dit pas comment arbitrer entre ces options quand plusieurs sont possibles simultanément. Il ne dit pas si la décision est compatible avec vos règles métier, vos contraintes fournisseurs, votre stratégie commerciale du moment. Entre la prédiction et la décision, il y a un fossé qui contient quasiment toute la complexité opérationnelle du retail. Et ce fossé, les modèles ML de forecasting ne le franchissent pas. Ils ne le prétendent même pas — ce sont leurs utilisateurs qui ont projeté sur eux une promesse qu'ils n'ont jamais portée. Le résultat est connu de toutes les directions retail qui ont investi dans ce type de projet. On obtient un forecast techniquement remarquable, salué en comité, présenté dans les conférences sectorielles. Et trois mois plus tard, sur le terrain, les magasins continuent à recevoir des réassorts inadaptés, les démarques continuent à se prendre dans Excel, et la performance opérationnelle n'a pas bougé.
Pourquoi un excellent forecast ne produit pas, à lui seul, une bonne décision
Plusieurs raisons structurelles expliquent ce gap. Il vaut la peine de les regarder en détail, parce qu'elles déterminent ce qu'il faut construire par-dessus le forecast pour qu'il devienne réellement utile.
Raison n°1 : un forecast ne porte pas d'arbitrage
Une décision retail typique est presque toujours un arbitrage entre plusieurs objectifs concurrents. Faut-il démarquer maintenant à -20 % ou attendre deux semaines en risquant de devoir aller à -40 % ? Faut-il transférer ce stock du magasin A vers le magasin B, ou le laisser sur place en espérant qu'une promotion locale relancera les ventes ? Faut-il réassortir cette référence au risque de créer un surstock, ou accepter une rupture de quelques jours ? Chacune de ces questions implique de pondérer des coûts : coût de la démarque vs coût du portage, coût du transfert vs probabilité de vente, coût de la rupture vs risque de surstock. Le forecast donne une partie des inputs nécessaires à cette pondération. Il ne fait pas la pondération lui-même. Faire la pondération suppose une logique économique, des règles métier, des préférences stratégiques — autant d'éléments qui ne sont pas dans un modèle de demande.
Raison n°2 : un forecast ignore les contraintes réelles
Un modèle de demande prédit ce qui pourrait se vendre. Il ne sait rien des contraintes qui limitent ce qui peut être fait. Le fournisseur impose un MOQ de 200 unités quand la prédiction suggère d'en commander 50. Le contrat magasin interdit certaines démarques avant la S+8. La marge plancher de la catégorie ne permet pas une remise au-delà de 35 %. Le coût logistique d'un transfert dépasse la marge récupérée. La capacité de réception d'un magasin limite ce qu'on peut lui envoyer cette semaine. Aucune de ces contraintes n'est dans le forecast. Et pourtant, ce sont elles qui déterminent ce qui est réellement faisable. Un système qui propose des décisions sans intégrer ces contraintes produit, par construction, des recommandations qui sont soit inapplicables, soit ignorées par les équipes — ce qui revient au même.
Raison n°3 : un forecast est probabiliste, une décision est binaire
Un bon modèle ML ne donne pas une prédiction unique : il donne une distribution. « Il y a 70 % de chances que les ventes hebdo soient entre 8 et 12 unités, 20 % qu'elles soient au-dessus, 10 % qu'elles soient en dessous. » Cette information est précieuse — elle dit quelque chose sur l'incertitude qui entoure la prédiction. Mais dans la vraie vie, vous ne pouvez pas réassortir « 70 % d'une commande ». Vous ne pouvez pas démarquer « probablement à -25 % ». À un moment, il faut trancher : commander ou pas, démarquer ou pas, transférer ou pas. Cette traduction d'un continuum probabiliste en décision binaire suppose une logique de seuil, de coût d'erreur, d'aversion au risque. Là encore : ce n'est pas dans le forecast.
Raison n°4 : un forecast est local, une décision est systémique
Les modèles ML retail prédisent généralement à la maille SKU/magasin/semaine. Chaque prédiction est faite indépendamment — ou avec une faible prise en compte des autres prédictions. Or, dans la réalité, les décisions retail sont interdépendantes. Démarquer le produit A peut cannibaliser les ventes du produit B. Transférer du stock entre deux magasins crée un coût logistique global. Réassortir une catégorie consomme une capacité de réception qui ne sera plus disponible pour une autre. Une décision retail à grande échelle, c'est un problème d'optimisation sous contraintes systémiques, pas une addition de prédictions individuelles. Confier la décision finale à un agrégat de forecasts SKU/magasin, c'est ignorer toute la dimension d'orchestration qui fait la différence entre un pilotage efficace et un pilotage incohérent.
Raison n°5 : un forecast est silencieux sur l'action à mener
C'est la limite la plus fondamentale, et celle qui rend toutes les autres opératoires. Même si un modèle a parfaitement prédit qu'un produit va sous-performer dans un magasin, il ne dit pas ce qu'il faut faire. Lancer une démarque ? Transférer le stock ? Activer une promotion ciblée ? Demander un retour fournisseur ? Ne rien faire et accepter la perte ? Chacune de ces actions a un coût, un délai, un risque, des conséquences sur d'autres dimensions du business. Choisir entre elles, ce n'est plus de la prédiction — c'est de la prescription. Et la prescription suppose une couche logicielle d'un autre type que le modèle ML : un moteur de décision qui, sur la base des forecasts et des règles métier, formule la recommandation d'action adaptée à chaque cas.
Le piège de la précision : pourquoi chasser le 95 % est souvent une erreur stratégique
L'industrie a longtemps confondu performance d'un projet data avec performance du forecast lui-même. Combien de projets ont été lancés avec comme objectif principal : « passer de 78 % à 90 % de précision sur la prévision de demande » ? Combien de comités de pilotage ont consacré leurs réunions à analyser pourquoi le modèle se trompait sur tel cluster ou telle catégorie ? Ce n'est pas que la précision n'a pas d'importance. Elle en a. Mais elle compte beaucoup moins qu'on le pense — et son rendement décroît brutalement après un certain seuil. Voici pourquoi. La précision d'un forecast améliore une décision uniquement dans la mesure où la décision est sensible à cette précision. Or, dans la majorité des cas opérationnels, la décision n'est pas cette sensible. Un produit qui se vend deux fois moins vite que ses pairs sera démarqué, qu'on prédise 5 unités par semaine ou 7. Un magasin en surstock structurel sera identifié comme tel, que la prédiction soit à 90 % ou 95 % de précision. La décision finale dépend de seuils, de règles, d'arbitrages — pas de la deuxième décimale de la prédiction. Pendant ce temps, passer de 90 % à 95 % de précision coûte typiquement plus cher que de passer de 70 % à 90 % : il faut plus de données, plus de features, plus d'entraînement, plus de gouvernance. Et ce coût marginal est, dans la pratique, presque toujours dépensé sur le mauvais problème. Le vrai gisement de valeur n'est pas dans les cinq derniers points de précision du forecast. Il est dans la transformation des forecasts existants en décisions exécutées. C'est ce passage de la prédiction à l'action qui contient l'essentiel de la marge récupérable — et c'est précisément celui que la plupart des projets data négligent.
Le data scientist solitaire : un anti-pattern fréquent
Il faut le dire clairement, parce que c'est l'une des causes structurelles du gap entre forecast et décision : dans beaucoup d'organisations retail, la donnée et l'opération vivent dans des mondes séparés. D'un côté, une équipe data, souvent rattachée à la DSI ou à une direction transverse, construit des modèles de plus en plus sophistiqués. Elle parle de RMSE, de cross-validation, de feature engineering, de drift de modèle. Elle livre ses prédictions sous forme de fichiers, de dashboards, ou d'API. De l'autre, les équipes merchandising, supply, opérations, qui parlent de couverture, de margelle, de sell-through, de réassort, de calendrier commercial. Ces équipes ont des règles métier dans la tête, des contraintes opérationnelles dans les jambes, et un sens du terrain que personne d'autre n'a. Entre les deux, le fossé est rarement comblé. Les data scientists produisent des forecasts techniquement excellents mais déconnectés des règles métier réelles. Les équipes opérationnelles reçoivent ces forecasts et n'ont aucune confiance dans des prédictions qui ignorent les contraintes qu'elles connaissent par cœur. Résultat : le forecast est utilisé en marge — voire pas utilisé du tout — et les décisions continuent à être prises comme avant, sur la base de l'expérience et de tableurs Excel. Ce n'est la faute de personne. C'est le résultat d'une architecture organisationnelle qui sépare ceux qui prédisent de ceux qui décident. Et tant que cette séparation existe, aucun investissement dans le ML ne produira les gains attendus.
Ce qu'il faut construire par-dessus le ML : la couche décisionnelle
La question n'est donc plus de savoir s'il faut faire du machine learning en retail — la réponse est évidemment oui. La question est : que faut-il construire par-dessus pour transformer ces prédictions en performance opérationnelle ? Quatre briques sont nécessaires. Brique 1 : un moteur de décision qui transforme les prédictions en recommandations d'action. Sur la base des forecasts (de demande, de risque de démarque, de probabilité de rupture), le moteur formule pour chaque SKU/magasin une recommandation concrète : transférer, démarquer, réassortir, activer une promotion, retourner au fournisseur, ou ne rien faire. La sortie n'est plus un chiffre, c'est une action. Brique 2 : l'intégration native des règles métier et contraintes. Planchers de marge, contraintes fournisseurs, calendriers commerciaux, capacités logistiques, règles d'arbitrage entre catégories — tout cela doit être codifié dans le moteur pour que les recommandations soient à la fois optimales et applicables. Une recommandation parfaite mais qui viole une règle métier ne sera jamais exécutée. Une recommandation moins optimale mais compatible avec les contraintes sera, elle, mise en œuvre. Brique 3 : une logique d'optimisation systémique. Au-delà des décisions SKU/magasin prises individuellement, le moteur doit prendre en compte les interactions : cannibalisation entre produits, mutualisation des coûts logistiques, allocation de capacités contraintes. C'est cette vue systémique qui permet de passer d'une somme de bonnes intentions locales à une optimisation globale du réseau. Brique 4 : une exécution sans rupture. Une décision n'a de valeur que si elle est exécutée. Le moteur doit donc être connecté en aval aux systèmes d'exécution — ERP, WMS, e-commerce, pricing — pour propager les actions validées sans ressaisie. C'est ce continuum prédiction → décision → exécution qui transforme le ML d'un exercice analytique en levier opérationnel. Cette architecture en quatre briques, c'est ce qui sépare un projet data retail qui produit de la marge d'un projet data retail qui produit des dashboards. Et c'est elle, pas la précision du forecast, qui mérite l'essentiel de l'investissement.
Le rôle réel du ML dans cette architecture
Soyons clairs : tout cela ne minimise pas la valeur du machine learning. Au contraire — le ML reste indispensable dans une plateforme de décision retail moderne. Il fournit les inputs sans lesquels le moteur de décision serait aveugle : forecasts de demande, élasticités prix, probabilités de rupture, scores de risque, segmentations de produits, clustering de magasins. Mais son rôle change. Il cesse d'être la finalité du projet pour redevenir ce qu'il aurait toujours dû être : un composant d'une architecture plus large, dont la finalité est la décision opérationnelle. Le succès du projet ne se mesure plus à la précision du modèle, mais à la qualité et à la vitesse des décisions qu'il permet d'exécuter sur le terrain. Ce changement de paradigme a des implications concrètes. On accepte qu'un forecast à 85 % de précision, exploité par un moteur de décision intelligent et exécuté sans friction, produira beaucoup plus de valeur qu'un forecast à 93 % qui finit ignoré dans un dashboard. On arrête de chasser les décimales de précision pour investir dans la chaîne de transformation prédiction → décision → action. Et on réaligne l'organisation autour d'un objectif unique — la performance opérationnelle — plutôt qu'autour d'objectifs techniques disjoints.
L'approche Solya : du forecast à l'action exécutée
C'est précisément l'architecture que Solya met en place chez les retailers qui veulent transformer leurs investissements data en performance opérationnelle. Pas en proposant un énième moteur de forecasting concurrent des modèles existants — mais en construisant la couche manquante qui transforme les prédictions, qu'elles viennent de Solya ou d'ailleurs, en décisions exécutées sur le terrain. Concrètement, Solya se connecte à vos sources de données — POS, ERP, e-commerce, supply chain, outils internes — et reconstruit une vue unifiée du réseau au niveau SKU/magasin. Cette donnée alimente un moteur de décision qui combine les prédictions de demande, les règles métier de l'enseigne et les contraintes opérationnelles pour formuler, en continu, les actions optimales : transferts, démarques, réassorts, retours fournisseurs, ou statu quo argumenté. Les recommandations validées sont propagées dans les systèmes d'exécution existants sans ressaisie. Les modèles ML, qu'ils soient développés en interne par vos équipes data ou intégrés par Solya, ne sont plus une finalité — ils deviennent un input parmi d'autres dans un système conçu pour décider et exécuter. Et c'est cette intégration de bout en bout, du forecast à l'action terrain, qui rend mesurable l'impact économique de vos investissements data.
La vraie question à se poser
Ce n'est pas « notre forecast est-il assez précis ? ». C'est « combien de décisions opérationnelles notre organisation prend-elle, chaque semaine, sur la base de nos prédictions ? ». Si la réponse se compte en centaines plutôt qu'en dizaines de milliers, vos modèles produisent probablement bien plus d'analyses que d'actions. Et la prochaine étape n'est pas de perfectionner les modèles. C'est de construire la couche qui transforme leurs sorties en décisions exécutées à l'échelle. Dans un secteur où la complexité combinatoire dépasse depuis longtemps les capacités d'arbitrage humaines, ce n'est plus la qualité des prédictions qui fait la différence. C'est la capacité à les convertir, en continu et sans friction, en actions concrètes sur le réseau. C'est là, et nulle part ailleurs, que se joue la prochaine génération de gains de performance retail.
Vos prédictions méritent-elles d'être exécutées ?
Chez Solya, nous proposons aux directions retail un diagnostic personnalisé de 30 minutes pour évaluer, sur votre propre stack data, le gap entre vos capacités prédictives et vos capacités décisionnelles — et chiffrer le potentiel de valeur que vous laissez sur la table dans cette zone aveugle. 👉 [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 de la chaîne actuelle entre vos forecasts et vos décisions opérationnelles
- Une estimation du potentiel de marge récupérable en industrialisant cette chaîne
- Les premiers cas d'usage à fort ROI pour transformer vos prédictions en performance terrain
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,…