Demand sensing retail : prévoir pour décider, pas pour briller

Depuis dix ans, les équipes forecast du retail sont jugées sur un seul chiffre : la précision. MAPE, WAPE, biais sur les huit dernières semaines. Les comités de pilotage s'écharpent sur 88 % ou 91 %. Les nouveaux éditeurs sont benchmarkés sur trois catégories test avant qu'on n'évoque le déploiement. Et chaque saison, l'équipe revient avec un modèle quelques points meilleur que le précédent.

Et chaque saison, les chiffres opérationnels — taux de service, taux de réussite du réappro, résiduel fin de saison — ne bougent presque pas.

Ce n'est pas un artefact de mesure. C'est le symptôme d'un décalage structurel entre ce que l'équipe forecast optimise et ce que l'enseigne a réellement besoin de décider. L'industrie a passé une décennie à affiner la précision de prévisions qui arrivent après le moment où la décision aurait dû être prise.

Ou à une granularité qui ne correspond pas à la façon dont l'action est exécutée. Le bon KPI n'a jamais été la précision. C'est le prêt-à-décider.

Le demand sensing — forecast court terme, à signal frais, couplé à la décision — existe précisément pour cette raison. Pas parce que le ML long terme s'est amélioré. Parce que la prémisse même du forecast hebdomadaire batch est incompatible avec les boucles de décision continues qui régissent le retail moderne. Cet article assume cette thèse et en tire les implications opérationnelles pour l'équipe forecast.

Une version plus large de l'argument — pourquoi le ML seul ne suffit pas, quelle couche de décision doit s'asseoir au-dessus — est posée dans du forecasting à la décision. Le présent article est la couche en dessous, spécifique au KPI et à l'architecture de l'équipe forecast.

Pourquoi la précision a discrètement cessé d'être le bon KPI

Le KPI de précision est hérité de l'époque où le forecast servait à poser un plan saisonnier. Dans ce monde-là, la prévision était produite une fois par saison, alimentait un open-to-buy, déclenchait une décision d'achat unique. Forecast et décision se faisaient à la même cadence — lente, batchée, rythme comité. La précision était un proxy raisonnable : un meilleur forecast donnait un meilleur plan saisonnier.

Ce monde n'existe plus. La boucle de décision dominante du retail aujourd'hui n'est pas saisonnière — elle est continue. Le réapprovisionnement tourne quotidiennement, parfois plusieurs fois par jour. Les markdowns sont ré-arbitrés plusieurs fois par saison, parfois chaque semaine sur les SKU à risque. Les transferts inter-magasins, l'allocation e-commerce, le routage de fulfillment se jouent sur des horizons mesurés en heures, pas en semaines.

Quand la cadence de décision s'accélère et que la cadence de forecast suit son propre rythme, la précision comme KPI commence à mesurer la mauvaise chose. Une prévision batch hebdomadaire calculée dimanche soir, propagée lundi matin, livrée au planner lundi après-midi, a perdu trois ou quatre jours de signal au moment où elle est utilisée. Les deux points de précision gagnés sur le modèle précédent sont écrasés par la vétusté. C'est l'écart entre les données vues par le modèle et la réalité que la décision doit traiter.

Ce n'est pas hypothétique. Dans la plupart des enseignes, la première source d'erreur du forecast au moment de la décision n'est pas l'erreur du modèle. C'est l'erreur de vétusté — celle introduite par l'écart entre la génération de la prévision et l'exécution de la décision. Et la vétusté n'est sur aucun dashboard de l'équipe.

Prêt-à-décider : une définition que l'industrie n'utilise pas encore

Posons proprement le KPI manquant. Une prévision est prête-à-décider quand trois conditions sont simultanément vraies au moment où une décision doit être prise :

1. La prévision existe pour l'horizon et le périmètre concernés.
2. Elle est à la granularité à laquelle la décision se prend — SKU/magasin/jour, pas catégorie/semaine.
3. Elle est assez récente pour intégrer les signaux les plus récemment observés.

Si l'une des trois manque, la prévision n'est pas prête-à-décider, quelle que soit sa précision sur backtest. Une prévision SKU/magasin/semaine ne peut pas piloter un réappro magasin quotidien — mauvaise granularité. Une prévision du lundi matin ne peut pas piloter un arbitrage de transfert le mardi après-midi qui dépend du sell-through du mardi matin — mauvaise récence. Une prévision calculée seulement sur les 20 % de tête de l'assortiment ne peut pas piloter un re-buy de longue traîne — mauvais périmètre.

Le prêt-à-décider est une vérification binaire, décision par décision. Soit la prévision était utilisable au moment de la décision, soit elle ne l'était pas. La métrique agrégée — quel pourcentage des décisions opérationnelles ont eu une prévision prête-à-décider disponible ? — devrait être ce sur quoi l'équipe forecast est mesurée.

Dans la plupart des enseignes que nous avons regardées, ce chiffre est étonnamment bas. Pas parce que les modèles sont mauvais. Parce que l'architecture de prévision a été conçue pour une autre cadence de décision que celle sur laquelle les opérations tournent aujourd'hui.

Pourquoi « prévoir plus souvent » est la mauvaise réponse

Le réflexe, une fois le problème de vétusté nommé, est de faire tourner le forecast plus souvent. Quotidien au lieu d'hebdomadaire. Deux fois par jour au lieu de quotidien. Certaines enseignes sont passées à du batch horaire sur les SKU à forte vélocité.

Cela aide à la marge. Cela rate aussi le sujet.

La fréquence est une réponse symptomatique à un problème architectural. Tant que la prévision et la décision sont découplées, augmenter la fréquence réduit l'écart statistiquement. Cela ne l'élimine pas. Et cela multiplie le coût de calcul, la charge de gouvernance, et le risque de présenter au planner deux recommandations contradictoires issues de deux runs adjacents.

La bonne architecture n'est pas prévoir plus souvent. C'est prévoir couplé à la décision. La prévision est recalculée *parce qu'*un événement déclencheur arrive, sur le périmètre dont la décision a besoin, avec une fraîcheur garantie par le déclencheur lui-même. La prévision devient un appel de fonction à l'intérieur de la boucle de décision, pas un job planifié dans un pipeline parallèle.

C'est ce que demand sensing veut réellement dire, quand le terme est utilisé avec précision. Pas « prévision court terme ». Pas « intègre des signaux plus récents ». Une architecture de prévision dans laquelle la prévision est générée, à la granularité nécessaire, au moment où la décision est sur le point d'être prise. Le « sensing » est le couplage au signal déclencheur de décision, pas la récence des données d'entrée en tant que telle.

Ce qui couple une prévision à une décision

Trois bascules architecturales séparent un forecast couplé à la décision d'un forecast batch.

D'abord, le déclencheur. Un forecast batch tourne sur une horloge. Un forecast couplé à la décision tourne sur un événement : une alerte de rupture, un cut-off de réappro qui approche, une demande d'arbitrage de transfert, l'ouverture d'un comité markdown. Le déclencheur porte le périmètre et l'horizon. La couche forecast répond à l'événement, pas à un cron.

Ensuite, le contrat de granularité. Un forecast batch produit un cube figé — disons SKU × magasin × semaine, sur tout l'assortiment. Un forecast couplé à la décision produit uniquement la tranche dont la décision a besoin, à la granularité à laquelle la décision se prend.

Un cut-off de réappro pour le magasin 47 a besoin de prévisions SKU/jour sur sept jours pour les SKU concernés. Rien de plus. Le calcul est borné, la sortie est serrée, la propagation est rapide.

Enfin, la surface de livraison. Un forecast batch est livré dans un fichier, une table, un dashboard. Un forecast couplé à la décision est livré dans le contexte de décision : le moteur de réappro, l'écran d'arbitrage markdown, le recommandeur de transfert. Il y arrive au moment précis où la décision est en cours de calcul. L'équipe forecast cesse de livrer des chiffres ; elle livre des réponses aux questions que pose un système aval.

Quand ces trois conditions sont réunies, le débat sur la précision se rétrécit. Une prévision SKU/jour, générée trois minutes avant le cut-off, sur les SKU exactement concernés, le POS du matin déjà intégré, battra presque toujours le batch hebdo à 92 %. Même si sa précision backtest est de quelques points inférieure sur le papier. Parce que la précision backtest n'est pas ce que l'enseigne paie. C'est la qualité des décisions exécutées.

Ce que cela change pour l'équipe forecast

Il ne s'agit pas de jeter les modèles existants. Le stack ML qu'une enseigne a construit — gradient boosting sur la demande, réconciliation hiérarchique, gestion des demandes intermittentes, modèles de lift promo — tout cela reste utile. Ce qui change, c'est la façon dont il est packagé et déployé.

Trois bascules concrètes.

L'équipe cesse de livrer un cube hebdomadaire et commence à livrer un service de prévision. Une API que les systèmes de décision appellent quand ils ont besoin d'une prévision pour un périmètre, un horizon, une granularité précis. Le forecast passe de livrable à capacité.

Le KPI de succès de l'équipe change. Pas le WAPE des huit dernières semaines. Le taux de prêt-à-décider — la fraction des décisions opérationnelles, à travers réappro, markdown, transfert, allocation, pour lesquelles une prévision prête-à-décider était disponible au moment de la décision. Ce chiffre se calcule au niveau de la couche de décision, pas du forecast. Ce qui veut dire que l'équipe forecast commence à être mesurée sur quelque chose qu'elle ne peut améliorer qu'en travaillant avec les opérations.

La roadmap de l'équipe change. Moins de temps sur les deux prochains points de précision. Plus de temps sur le budget de latence — à quelle vitesse une prévision sur un slice arbitraire peut-elle être calculée et livrée dans un contexte de décision ? Plus de temps aussi sur la surface d'intégration — combien de systèmes de décision peuvent appeler le service forecast aujourd'hui, sur quels périmètres, avec quelles garanties ?

C'est une vraie réorientation. Elle sera inconfortable pour des équipes dont les évaluations annuelles citent encore les gains de WAPE. C'est aussi, autant qu'on puisse en juger à travers les enseignes que nous accompagnons, le seul chemin qui transforme une décennie d'investissement forecast en performance opérationnelle lisible au P&L.

L'approche Solya : la prévision comme capacité de la couche de décision

C'est exactement la logique sur laquelle la couche de décision Solya est construite. La prévision n'est pas un pipeline séparé produisant des fichiers dans l'entrepôt. C'est une capacité que la couche de décision appelle : au moment où un réappro se calcule, où un markdown s'arbitre, où un transfert se score. La couche forecast répond sur le périmètre et la granularité exacts dont la décision a besoin, avec le signal le plus frais disponible intégré.

Les modèles de prévision — les vôtres, les nôtres, hybrides — restent derrière cette capacité. Ils continuent à faire ce qu'ils font bien : prédire la demande. Ce qui change, c'est le contrat qu'ils exposent au reste de la chaîne. Un système de décision demande une prévision ; la couche forecast en renvoie une, assez vite et assez spécifique pour être utilisable. Le taux de prêt-à-décider devient mesurable, et améliorable, parce que l'architecture le permet.

Les enseignes qui adoptent ce schéma cessent de débattre de précision et commencent à débattre de couverture. Quelles boucles de décision ont aujourd'hui une prévision prête-à-décider, lesquelles ne l'ont toujours pas. C'est une conversation beaucoup plus productive. Et elle est corrélée aux résultats opérationnels d'une façon que la précision ne l'a jamais été.

La question à ramener à l'équipe

Ce recadrage se situe un cran sous la boucle de décision-exécution fermée vers laquelle les meilleurs retailers convergent. Si vous évaluez activement des éditeurs en parallèle, le guide d'achat logiciel de planification de la demande retail projette la même ligne forecasting-first vs décisioning-first sur la catégorie. Si vous dirigez une équipe forecast, ou si vous êtes la direction opérations à qui l'équipe livre, posez une seule question à votre prochaine revue. Pour chaque décision opérationnelle prise par l'enseigne la semaine dernière, une prévision prête-à-décider était-elle disponible au moment de la décision ?

Pas « quel était le WAPE ? ». Pas « le modèle a-t-il battu la baseline ?

». Le taux de prêt-à-décider, décision par décision, agrégé en un pourcentage. S'il est sous 60 %, le prochain point de précision est le mauvais investissement. C'est l'architecture qui l'est.

L'équipe forecast a fait du travail compétent dans le mauvais cadre. Recadrer n'est pas une critique de l'équipe — c'est une critique du KPI qu'on lui a tendu pendant une décennie. Les équipes qui changent de cadre les premières seront celles dont l'investissement forecast finit par faire bouger les chiffres opérationnels. Celles qui continuent d'optimiser la précision continueront de se demander pourquoi leurs excellents modèles n'apparaissent pas au P&L.

---

Votre stack forecast est-il prêt pour la boucle de décision ?

Chez Solya, nous proposons aux directions supply chain et merchandising un diagnostic personnalisé de 30 minutes. Sur votre propre assortiment et votre cadence de décision, nous évaluons à quel point votre stack forecast actuel est prêt-à-décider. Et nous identifions où le découplage entre prévision et décision vous coûte de la marge mesurable aujourd'hui.

Vous repartez avec :

• Une cartographie du prêt-à-décider sur vos trois principales boucles opérationnelles (réappro, markdown, transfert)
• Une estimation de l'écart de vétusté entre votre cadence de prévision et votre cadence de décision
• Les bascules concrètes pour rendre votre couche forecast appelable par vos systèmes de décision