Logiciel de planification de la demande retail : guide d'achat 2026

Vous évaluez un logiciel de planification de la demande. Trois éditeurs en short-list, un appel d'offres à moitié écrit, et l'équipe débat sur les benchmarks de précision et les fiches de fonctionnalités. Arrêtez la réunion. Quasiment rien de ce que vous allez noter ne prédit si la plateforme génère de la marge un an plus tard.

La ligne de partage la plus sous-évaluée ici, ce n'est pas la précision du forecast. C'est de savoir si la plateforme a été conçue pour prévoir ou pour décider. Sur une fiche fonctionnelle, ces deux camps se ressemblent. En production, ils n'ont rien à voir.

Ce guide propose les critères qui séparent vraiment les plateformes une fois le contrat signé. Il nomme les signaux d'alerte à repérer en démo. Il cartographie l'anatomie du pricing qui explique pourquoi deux éditeurs comparables peuvent vous chiffrer à un facteur 3. Le cadre est neutre. Les éditeurs cités plus bas le sont à titre descriptif — pour ancrer ce pour quoi chacun a été construit — jamais pour les opposer sur des deals hypothétiques.

La ligne de partage que personne ne nomme : forecasting-first vs décisioning-first

L'expression « logiciel de planification de la demande » masque deux catégories de produits réellement différentes. Les deux ingèrent l'historique de ventes, les deux produisent un forecast, les deux ont un dashboard. L'intention architecturale, elle, diffère — et la valeur en production aussi. Tout part d'une distinction encore plus basique que la plupart des acheteurs sautent — la différence entre planification de la demande et prévision elles-mêmes.

Les plateformes forecasting-first sont organisées autour du modèle. La roadmap se raconte en gains de précision : meilleur ML court-terme, meilleure décomposition promotionnelle, meilleur cold-start sur les nouveautés. La sortie est un forecast — et ce qu'il devient ensuite est le problème de quelqu'un d'autre, typiquement un planner devant un écran. RELEX, ToolsGroup, o9 et la longue traîne des suites supply-chain ont leur centre de gravité ici. Elles sont très bonnes à ce pour quoi elles ont été conçues : prévoir à grande échelle.

Les plateformes décisioning-first sont organisées autour de la décision exécutée. Le forecasting reste nécessaire, mais c'est de la plomberie.

La sortie principale est un ordre de transfert, une quantité de réapprovisionnement, un timing de démarque, ou une réallocation — réécrite dans le système qui exécute. Solya s'inscrit dans ce camp par conception. C'est aussi le cas de certaines briques Anaplan utilisées comme surface de modélisation et de décision plutôt que comme espace de planification. C'est le cas, enfin, de presque chaque plateforme interne qu'un distributeur s'est donné la peine de construire correctement.

La distinction compte parce qu'un forecast qui ne se traduit pas en décision opérationnelle est un rapport Excel avec des étapes en plus. Un planner qui doit relire chaque recommandation, arbitrer les compromis à la main, puis ressaisir le résultat dans l'ERP n'a pas acheté une plateforme de planification. Il a acheté un tableur plus cher avec une attribution ML.

Les éditeurs décisioning-first comblent ce trou par construction. Cela change tout en aval — l'intégration, l'adoption, le profil des personnes dont vous aurez besoin dans l'équipe. La version approfondie de cet argument est dans du forecasting à la décision : pourquoi le ML ne suffit pas.

Si cette ligne de partage est rarement formulée dans les RFP, c'est que les deux camps répondent « oui » aux mêmes questions de checklist. Les deux prévoient. Les deux planifient. Les deux se connectent à SAP. La différence apparaît à la question suivante : qui possède la décision une fois le forecast produit ?

Si la réponse est « un planner relit et ajuste », vous achetez une plateforme de forecasting. Si la réponse est « la plateforme valide une décision dans le système d'exécution, avec un chemin d'override humain », vous achetez une plateforme décisionnelle. Mettez cette question en première coupe de votre évaluation, pas en dernière.

Sept critères qui prédisent vraiment la réussite en production

Une fois la coupe de catégorie posée, la question de second ordre est ce qu'il faut pondérer à l'intérieur du camp que vous avez choisi. Les critères ci-dessous décident si la plateforme produit de la valeur ou rejoint le cimetière des projets data retail enlisés. À lire comme des questions à poser à l'éditeur sur vos données — pas comme des cases dans une grille.

1. La cadence de décision supportée

Quel est l'intervalle le plus court auquel la plateforme produit une décision fraîche ? Quotidien, hebdomadaire, ponctuel ? La plupart des suites de planification ont été architecturées pour un cycle hebdomadaire ou mensuel, avec une couche journalière greffée plus tard.

Cette greffe se voit. Une plateforme qui recalcule un plan complet en douze heures ne peut pas piloter une boucle de réapprovisionnement quotidienne sans compromis. La cadence pour laquelle la plateforme a été née en dit plus long que sa cadence maximale revendiquée. L'argument pour coupler la cadence du forecast à celle de la décision est développé dans demand sensing prêt pour la décision.

2. L'intégration aux systèmes d'exécution

Pas « connecteurs disponibles ». Write-back bidirectionnel, en production, vers les systèmes qui agissent sur la décision : WMS, OMS, ERP, applications opérations magasin, moteur de pricing. Demandez précisément ce que la plateforme écrit, sous quel format, à quelle latence, et ce qui se passe en cas de panne partielle. Une plateforme qui se contente de produire un fichier à importer a renvoyé la moitié difficile du travail vers vos équipes. C'est aussi la moitié que personne ne cadre pendant le POC.

3. Le time-to-decision sous problèmes de qualité de données

Les démos tournent sur des données propres. La production, non. Un flux arrive en retard, un référentiel SKU est corrompu, ou deux systèmes ne s'accordent pas sur le stock. À quelle vitesse la plateforme produit-elle encore une décision, et avec quelle netteté signale-t-elle l'incertitude ?

Une plateforme qui lève des erreurs et attend la correction des données restera silencieuse précisément pendant les périodes où vous en avez le plus besoin. Demandez à la voir tourner sur un flux délibérément cassé.

4. La plateforme possède-t-elle la décision ou seulement le forecast ?

La seule question qui sépare les deux camps nommés plus haut. La plateforme valide-t-elle une décision précise, exécutable, contrainte — « transférer 40 unités du magasin A vers le magasin C avant jeudi » ? Ou produit-elle un forecast et une recommandation qu'un humain doit encore convertir en action ? Une décision possédée peut être mesurée, gouvernée, apprise. Une recommandation qui exige un arbitrage ne fait que déplacer le goulot.

5. La profondeur multi-échelon

Une plateforme mono-échelon prévoit au SKU et laisse la logique réseau à un planner avec un tableur. Une vraie plateforme multi-échelon raisonne conjointement sur entrepôt, magasin et SKU — en tenant compte des contraintes entre les trois. La différence se voit immédiatement sur un parc de plus de vingt magasins, où les décisions se fragmentent entre magasins et régions faute d'un moteur capable de tenir l'image entière. Demandez à l'éditeur de dérouler une décision depuis un forecast national jusqu'à une action magasin-SKU — dans les deux sens.

6. Override et gouvernance : le merchandiser voit-il et peut-il changer le raisonnement du modèle ?

La plateforme qui l'emporte est rarement la plus précise — c'est celle en qui les opérateurs ont assez confiance pour agir. Cette confiance dépend d'un merchandiser capable de voir pourquoi une décision a été prise. Il doit aussi pouvoir l'écraser proprement, et faire absorber l'override par la décision suivante au lieu de le faire disparaître. Un chemin d'override en boîte noire détruit l'adoption en deux saisons. C'est aussi pour cela que 80 % des règles métier retail finissent mal utilisées dans les systèmes data qui ne les modélisent pas au cœur.

7. Le modèle de pricing : au SKU ? au magasin ? à la décision ?

Le modèle de pricing est un indicateur. Un pricing au SKU vous pénalise quand l'assortiment grossit. Un pricing au magasin vous pénalise quand le parc s'étend. Un pricing à la décision aligne le revenu de l'éditeur sur votre sortie.

C'est la structure qu'il vous faut, parce qu'elle force l'éditeur à produire des décisions que les opérations exécutent réellement. Demandez comment la ligne grossit sur trois ans d'expansion plausible avant de signer.

Signaux d'alerte en démo

La démo est la pièce de preuve la moins chère que vous allez collecter. Utilisez-la. Les signaux ci-dessous prédisent un déploiement enlisé plus sûrement que n'importe quel appel de référence.

• Boucles infinies de tuning de forecast. L'éditeur déroule des gains de précision, des sweeps d'hyperparamètres, des leaderboards de modèles. Conversation intéressante à l'intérieur, sans rapport avec le fait que les décisions soient exécutées sur votre terrain. Un éditeur forecasting-first plongera dedans ; un éditeur décisioning-first pivotera vers l'action que le forecast déclenche.
• Pas d'API de décision. Demandez si les décisions peuvent être consommées par un autre système — votre OMS, votre app opérations magasin, un workflow custom. Si la seule sortie est une UI pour planner, la plateforme ne peut pas s'industrialiser ; elle ne peut qu'assister.
• Les démos tournent toujours sur des données propres. Demandez à voir la plateforme sur un flux délibérément dégradé — un jour de ventes manquant, un stock hors-bornes, un SKU dupliqué. Un éditeur qui ne peut ou ne veut pas le faire n'a pas industrialisé les modes de panne.
• Délai d'implémentation supérieur à neuf mois pour un premier périmètre. Le time-to-value est une propriété d'architecture, pas une promesse commerciale. Une intégration à neuf mois signale que les connecteurs ne sont pas aussi produits que le deck le prétend, et que vos équipes absorberont le coût. Un premier périmètre crédible part en production en semaines.
• « Oui, on sait faire » à chaque question. Une plateforme qui a un point de vue dit non à certaines choses. Un accord uniforme signifie que la capacité est configurable en principe et prouvée nulle part.
• Les références sont des pilotes, pas des sites en production. Demandez à la référence quelles décisions la plateforme possède aujourd'hui de bout en bout, à quelle cadence, et quel pourcentage de sa sortie est exécuté tel quel. Une référence incapable de répondre est une référence pour POC.

Anatomie du pricing : ce qui pilote vraiment la ligne

Les prix publics dans cette catégorie sont rares et largement fictifs. Les forfaits annuels négociés vont typiquement de l'ordre de 150 K€ pour une enseigne régionale plus petite jusqu'à 2 M€+ pour un groupe multi-pays. L'écart tient rarement aux fonctionnalités. Il tient aux pilotes de coût ci-dessous.

• Le volume de données. Nombre de SKU × nombre de magasins × profondeur d'historique. Les éditeurs facturent là-dessus parce que leur compute scale là-dessus. Une enseigne spécialisée de 40 magasins avec 5 000 SKU paie une fraction de ce que paie un groupe alimentaire de 600 magasins avec 60 000 SKU, sur la même plateforme.
• La fréquence des décisions. Un cas d'usage de planification hebdomadaire coûte moins cher qu'une boucle de réapprovisionnement quotidienne, qui coûte moins cher qu'un moteur de réallocation intra-journalier. Les plateformes décisioning-first tendent à facturer plus près de cet axe parce qu'il suit la valeur livrée.
• La surface d'intégration. Nombre de systèmes distincts en write-back, profondeur de chaque connecteur, exigences de latence. C'est là que le coût hors-budget se cache typiquement ; la licence est la partie visible, l'intégration est l'iceberg.
• Les services d'adoption. Que l'éditeur copilote ou non le déploiement avec vos équipes pendant les deux premières saisons. La licence la moins chère, sans co-déploiement, coûte habituellement plus en année 1 qu'une licence plus chère qui livre des décisions exécutées dans les temps.

Deux ordres de grandeur que Solya observe sur le terrain, à prendre avec précaution puisque chaque enseigne est unique. Un distributeur spécialisé européen de taille moyenne (50–150 magasins, 10–40 K SKU) atterrit dans la fourchette 250–600 K€ annuels pour un déploiement décisioning réel. Un groupe multi-pays dépasse confortablement le million une fois la portée d'intégration incluse. Ce sont des ordres de grandeur sectoriels, pas des devis.

La licence représente typiquement 40–60 % du coût total année 1. Le reste est intégration, conduite du changement et les profils côté client qu'il faut pour opérer la boucle. Le mécanisme par lequel une boucle fermée compose la valeur dans le temps est détaillé dans les retailers performants ont une boucle décision-exécution fermée.

Un cadre de négociation utile : demandez à chaque éditeur d'exprimer son prix en coût par décision exécutée par an. Les éditeurs forecasting-first peinent généralement sur cette arithmétique parce qu'ils ne mesurent pas les décisions exécutées. Les éditeurs décisioning-first devraient répondre immédiatement. L'exercice révèle plus que la négociation elle-même.

Solya dans le paysage

Solya est décisioning-first par conception. La plateforme est organisée autour de la décision que l'opérateur doit exécuter — un transfert, un réapprovisionnement, une démarque, une réallocation. Le forecasting reste en dessous, comme plomberie, pas comme surface produit.

Les règles métier sont intégrées au moteur plutôt qu'appliquées en filtre. Les décisions sont réécrites bidirectionnellement dans les systèmes d'exécution. La couche d'orchestration prend en charge la partie que les plateformes forecasting-first renvoient typiquement vers vos équipes.

Voir comment cela se traduit en flux déployés dans le cas d'usage réapprovisionnement continu et les agents démarque et transferts. C'est une option parmi plusieurs dans une catégorie qui en compte sincèrement. Tout le sens de ce guide est de faire le choix sur les critères ci-dessus, pas sur la marque au-dessus de la porte.

Avant le prochain rendez-vous éditeur

Posez-vous une question avant la prochaine démo : qui possède la décision une fois le forecast produit — un planner, ou la plateforme ? Si votre short-list mélange les camps forecasting-first et décisioning-first, le reste de l'évaluation comparera des choses qui ne se comparent pas. Réglez ça d'abord.

L'évaluation qui part de la coupe de catégorie survit à la démo. Celle qui part d'une checklist features-et-précision finit en déploiement enlisé six mois plus tard — et une grille que personne n'a remplie. La pièce sœur sur la façon de structurer la procédure d'achat autour de cette ligne est dans comment construire un appel d'offres pour une plateforme décisionnelle retail.

---

Vous évaluez un logiciel de planification de la demande ?

Nous proposons aux directions data et opérationnelles un diagnostic de 30 minutes. Il confronte votre short-list à votre propre parc, mix de catégories et surface d'intégration — sans parti pris éditeur, ancré dans ce que vos équipes auront réellement à opérer.

Vous repartirez avec :

• Une lecture sur le fait que votre short-list est forecasting-first, décisioning-first, ou accidentellement mixte
• Les deux ou trois critères parmi les sept ci-dessus qui sont décisifs dans votre contexte
• Une estimation d'anatomie de prix pour un premier périmètre réaliste, pas un chiffre de vitrine