Plateforme décisionnelle vs plateforme de prévision vs BI

La plupart des shortlists technologiques du retail portent la même confusion. Un DSI ou un directeur data compare trois éditeurs côte à côte et les traite comme des concurrents sur la même ligne budgétaire. En réalité, ils appartiennent à trois catégories distinctes, répondant à trois problèmes distincts.

La business intelligence décrit ce qui s'est passé. La plateforme de prévision prédit ce qui va se passer. La plateforme décisionnelle décide quoi faire — et pousse cette décision jusqu'au terrain.

On les note sur la même grille d'appel d'offres, comme si davantage de dashboards, une prévision plus fine et une décision exécutée étaient interchangeables. Ils ne le sont pas. Et les enseignes qui les traitent comme substituables se retrouvent avec deux des trois, et un trou précisément là où la marge fuit.

Cet article trace la frontière entre les trois catégories. À quoi sert réellement chacune, où chacune atteint son plafond, et un test concret pour les distinguer. Et pourquoi une enseigne sérieuse a besoin des trois empilées, pas de l'une choisie contre les autres.

À quoi sert la BI (et son plafond)

La business intelligence est une couche de lecture. Son rôle : prendre les données éparpillées entre la caisse, l'ERP, l'e-commerce et la supply chain, les réconcilier, et les présenter sous forme de dashboards qu'un humain peut interpréter. Chiffre d'affaires par magasin, sell-through par catégorie, couverture de stock par SKU, dérive de marge d'une semaine à l'autre. La BI fait cela très bien, et toute enseigne d'une certaine taille devrait en disposer. Reporting financier, comités de direction, lecture historique des KPI — rien de tout cela ne fonctionne sans une couche BI solide en dessous.

Le plafond est structurel, pas un défaut de maturité. La BI est descriptive par construction : elle répond aux questions qu'un humain pose, elle n'en pose aucune elle-même. Elle vous montrera que la marge brute sur les chaussures femme a perdu trois points le mois dernier. Elle ne vous dira pas pourquoi, quels SKU l'ont tirée, ni quoi faire.

L'analyste doit filtrer, croiser, conclure à la main. Sur un assortiment de 50 000 SKU répartis dans 200 magasins, aucune équipe ne pose la bonne question sur chaque ligne, chaque semaine.

La seconde partie du plafond, c'est l'exécution. Un outil BI s'arrête à l'écran. Le transfert qu'il rend visible doit encore être ressaisi dans l'ERP. La démarque qu'il fait remonter doit encore être déclenchée dans le pricing.

Entre le dashboard et l'action s'intercale une chaîne de ressaisies qui détruit en silence la valeur de la visibilité. Nous avons détaillé cet écart dans pourquoi vos outils BI ne prennent pas de décisions. En résumé, aucune accumulation de dashboards ne transforme la description en action, parce que ce n'est pas ce pour quoi la BI a été conçue.

À quoi sert une plateforme de prévision (et son plafond)

Une plateforme de prévision est une couche de prédiction. Elle prend l'historique, la saisonnalité, le prix, la météo, les promotions et une dizaine d'autres signaux. Elle estime ce qui va se passer : demande par SKU et par magasin, sell-through attendu, probabilité de rupture, résiduel de fin de saison. Le forecast moderne est réellement performant — les modèles de demand sensing atteignent couramment des niveaux de précision qui auraient relevé de la science-fiction il y a dix ans. Pour la planification, les achats et les décisions de capacité, une prévision fine est un vrai atout.

Mais une prévision est une entrée, pas une décision. Savoir qu'un SKU va vendre 40 unités la semaine prochaine ne dit rien sur le fait de le réassortir, de le transférer, de le démarquer, ou de ne rien faire.

Ce choix dépend du stock courant, du minimum de commande fournisseur, du calendrier commercial et du plancher de marge. Il dépend aussi de ce que fait le même SKU dans les onze autres magasins. Réassortir ici revient peut-être à affamer un magasin où il tourne trois fois plus vite. La prévision alimente cet arbitrage. Elle ne le réalise pas.

C'est le plafond que les éditeurs de prévision nomment rarement. Un forecast à 92 % de précision et un forecast à 78 % produisent souvent la même action correcte. L'action est verrouillée par les contraintes, pas par la deuxième décimale de la prédiction. Pousser la précision plus haut a des rendements vite décroissants une fois passé le seuil où la décision bascule.

Nous développons ce point dans du forecasting à la décision : pourquoi le ML ne suffit pas. Les propriétés manquantes sont l'arbitrage multi-options, l'application des règles métier, l'explicabilité et l'exécution, qu'aucun moteur de prédiction ne porte.

À quoi sert une plateforme décisionnelle

Une plateforme décisionnelle est une couche de décision. Son unité de sortie n'est ni un graphique ni un chiffre. C'est une action recommandée sur un objet précis, avec le raisonnement et les moyens de la mener à bien. Pour un couple SKU/magasin donné, elle produit un verdict : réassortir cette quantité, transférer vers ce magasin, démarquer de cette profondeur, retourner au fournisseur, ou ne rien faire. Puis elle propage la décision validée dans l'ERP, le WMS ou le pricing, sans ressaisie manuelle.

Pour cela, une plateforme décisionnelle doit porter quatre choses que la BI et la prévision n'ont pas. D'abord, l'arbitrage multi-options : elle pèse réassort vs transfert vs démarque vs statu quo comme des options concurrentes, pas une prédiction à la fois. Ensuite, les règles métier intégrées au moteur — planchers de marge, contraintes fournisseurs, calendriers commerciaux, traitements spécifiques par catégorie — appliquées systématiquement, pas comme un filtre ajouté après coup. Troisièmement, l'explicabilité, pour qu'un responsable ops voie pourquoi cette action et lui fasse confiance. Quatrièmement, l'exécution, pour que la décision atterrisse réellement sur le terrain dans la cadence commerciale.

C'est pourquoi la couche de décision est une catégorie à part entière, pas une BI 2.0 ni un forecast 2.0. Décider sous contraintes, à l'échelle de dizaines de milliers de couples SKU/magasin, dans une fenêtre de quelques jours, est un problème fondamentalement différent. Sur le plan calculatoire et architectural, il est distinct de décrire le passé ou de prédire l'avenir. On n'y arrive ni en ajoutant des dashboards à un outil BI, ni en relevant la précision d'une prévision. C'est un autre objet, bâti autour d'un autre métier.

Le test pour les distinguer

La façon la plus nette de classer n'importe quel outil de votre shortlist consiste à faire passer une seule décision à travers lui et à observer où il s'arrête. Prenez un SKU réel dans un magasin réel. Disons la robe en lin marine, taille M, à Bordeaux, en milieu de saison, sous le plan de vente. Puis posez à l'outil quatre questions, dans l'ordre.

• Que se passe-t-il ? Si l'outil répond à cela et ne va pas plus loin, c'est de la BI. Il montre la sous-performance, le niveau de stock, la tendance. Utile, et terminé.
• Que va-t-il se passer ? S'il vous donne en plus le sell-through attendu et le risque de rupture sur les prochaines semaines, il a une couche de prévision. C'est encore une entrée.
• Que dois-je faire, et pourquoi ? S'il renvoie une action précise — transférer vers Saint-Émilion où la robe tourne trois fois plus vite, parce que le plancher de marge tient et que le MOQ fournisseur ne joue pas pour un transfert — il raisonne comme une plateforme décisionnelle.
• Sait-il exécuter ? Si l'action choisie se propage dans votre WMS sous forme d'ordre de transfert sans que personne la ressaisisse, vous avez une vraie couche de décision. S'il s'arrête à la recommandation, l'écart de ressaisie est toujours là.

La plupart des outils échouent à la question trois ou quatre. Une plateforme qui répond aux deux premières mais reste muette sur les deux dernières n'est pas, par définition, une plateforme décisionnelle. Peu importe la façon dont l'éditeur la positionne. Ce contrôle décision par décision tranche plus vite que n'importe quelle grille d'appel d'offres. Il teste la seule chose qui sépare décrire et prédire de décider : la sortie est-elle une action exécutée, ou un écran sur lequel quelqu'un doit encore agir ?

Pourquoi vous avez besoin des trois (et où se branche la couche de décision)

Rien de tout cela ne plaide pour un remplacement. Les trois catégories s'empilent — elles ne se substituent pas. La BI reste le bon outil pour le reporting financier, les comités et l'analyse historique ; on ne pilote pas une enseigne sans elle.

La plateforme de prévision reste le bon moteur pour la planification de la demande, les achats et la capacité. Une couche de décision qui ignore les prévisions décide à l'aveugle. L'erreur n'est pas de posséder les trois — c'est d'en posséder deux en attendant que la troisième en émerge d'elle-même.

La couche de décision se place au-dessus et consomme les deux autres comme entrées. Elle lit la vue unifiée et réconciliée que la BI assemble déjà. Elle ingère les signaux de demande et de risque produits par la plateforme de prévision. Puis elle fait ce qu'aucune des deux n'a été conçue pour faire : peser les options sous vos contraintes, choisir, expliquer, exécuter.

Imaginez les quatre couches. La donnée, puis la prévision et la BI qui la lisent, puis la couche de décision qui arbitre par-dessus, puis l'orchestration qui repousse le résultat dans vos systèmes. La plateforme décisionnelle est la couche qui convertit la valeur que les autres produisent en valeur que les autres ne peuvent pas capter.

C'est exactement là que se situe Solya. Pas un remplaçant de votre BI, pas un concurrent de votre plateforme de prévision — la couche de décision et d'exécution au-dessus des deux. Solya lit vos données réconciliées et vos prévisions existantes, puis mène l'arbitrage multi-options sous vos règles métier au niveau SKU/magasin. Elle propage les décisions validées dans votre ERP, votre WMS et votre pricing sans ressaisie.

Les autres couches décrivent et prédisent. Solya décide, et l'amène jusqu'au terrain.

La question à trancher avant de faire une shortlist

Avant de noter trois éditeurs sur une seule grille, tranchez d'abord la catégorie réelle de chacun. Passez le test des quatre questions, et vous découvrirez en général que deux d'entre eux décrivent ou prédisent et qu'un seul décide. Vous ne compariez jamais des choses comparables. Une fois les catégories séparées, comment rédiger un appel d'offres de plateforme décisionnelle transforme cette clarté en structure de sélection.

Les enseignes qui prennent de l'avance ne sont pas celles qui ont le plus de dashboards ou le forecast le plus fin. Ce sont celles qui ont cessé d'attendre qu'une décision tombe d'un outil de lecture ou d'un moteur de prédiction, et qui ont ajouté la couche conçue pour décider.

---

Où s'arrête votre stack — à décrire, prédire, ou décider ?

Chez Solya, nous proposons aux directions retail un diagnostic personnalisé de 30 minutes pour cartographier, sur votre propre stack, où chaque outil s'arrête et où manque la couche de décision. À l'issue de cet échange, vous repartirez avec :

• Un placement clair de vos outils actuels entre les catégories BI / prévision / décision
• Les décisions précises qui passent aujourd'hui à travers l'écart entre prédiction et exécution
• Les premiers cas d'usage à fort ROI pour brancher une couche de décision au-dessus de l'existant