Tous les articles
Fondamentaux2026-06-02

Analytique prescriptive retail : définition et limites

L'analytique prescriptive est le sommet de l'échelle analytique : elle recommande une action. En retail, elle s'arrête juste avant d'exécuter la décision.

Kevin Didelot10 min de lecture

Demandez à dix responsables data retail de définir l'analytique prescriptive et vous obtiendrez dix versions de la même phrase de manuel : l'analytique qui dit quoi faire. C'est le dernier barreau de l'échelle de maturité analytique, celui au-dessus de la prédiction. C'est aussi le barreau où la définition survend discrètement ce que fait le logiciel sur un vrai terrain de vente.

Cet article fait deux choses. Il définit l'analytique prescriptive proprement, contre les barreaux du dessous — descriptive, diagnostique, prédictive — pour que le terme cesse d'être un brouillard marketing. Puis il trace la ligne que la plupart des éditeurs estompent : l'écart entre recommander une action et l'exécuter. Cet écart est minuscule sur un slide et énorme en production. C'est exactement là que la plupart des projets « prescriptifs » retail s'enlisent.

L'échelle de maturité analytique : descriptive, diagnostique, prédictive, prescriptive

La maturité analytique se dessine d'ordinaire en quatre barreaux. Chacun répond à une question plus difficile, et porte plus de valeur — et plus de difficulté — que celui du dessous.

BarreauQuestionExemple retailSortie
DescriptiveQue s'est-il passé ?Sell-through par rayon la semaine passéeUn tableau de bord
DiagnostiquePourquoi ?Pourquoi le cluster B a raté son planUne explication
PrédictiveQue va-t-il se passer ?Demande de ce SKU sur 8 semainesUne prévision
PrescriptiveQue devrait-on faire ?Démarquer cette ligne de 15 % dans 40 magasinsUne recommandation

Les deux premiers barreaux sont le territoire de la business intelligence — ils rendent le passé lisible. Le troisième, prédictif, est l'entrée du machine learning : il transforme l'historique en estimation future. La plupart des enseignes ont grimpé jusque-là. Elles ont des tableaux de bord, une prévision de demande, et la prévision est souvent bonne.

L'analytique prescriptive est le quatrième barreau. Elle prend la prévision, ajoute un objectif (maximiser la marge, tenir le taux de service, écouler le stock de saison) et des contraintes (budget, minimums fournisseur, calendrier de démarque). Elle calcule l'action qui sert le mieux l'objectif. Pas ce qui va arriverquoi en faire. Sur le papier, c'est le sommet ; en pratique, un barreau avant le sol.

Ce que fait vraiment l'analytique prescriptive en retail

Retirez l'abstraction et l'analytique prescriptive en retail est un moteur d'optimisation posé sur une prévision. Elle est réellement utile, et les exemples sont concrets.

  • Optimisation de démarque — selon l'élasticité prix prédite et le stock restant, recommander la profondeur et le calendrier de remise qui écoulent la saison au moindre sacrifice de marge.
  • Réassort — selon la prévision de demande et la politique de stock de sécurité, recommander la quantité de commande par SKU et par site.
  • Allocation — selon un achat national et les signaux de demande magasin, recommander comment répartir les unités sur le réseau.
  • Assortiment — selon les rôles de catégorie et la prévision, recommander quelles références garder, couper ou ajouter la saison prochaine.

Dans chaque cas, le moteur raisonne sur des dizaines de milliers de couples SKU/magasin d'un coup et applique les contraintes. Il fait remonter une recommandation classée qu'aucun humain ne calculerait à la main. C'est un vrai levier. C'est pourquoi l'analytique prescriptive mérite sa place au sommet de l'échelle. La discipline qui produit ces signaux est traitée dans du forecasting à la décision : pourquoi le ML ne suffit pas.

Jusqu'ici, rien à redire. Le problème n'est pas ce que fait l'analytique prescriptive. C'est ce qu'on suppose discrètement qu'elle fait ensuite.

Là où l'analytique prescriptive s'arrête (et pourquoi ça compte)

Voici la ligne que l'échelle de maturité cache. Une recommandation n'est pas une décision, et une décision n'est pas une action exécutée. L'analytique prescriptive livre la première. Les deux autres sont supposées suivre — et dans la plupart des déploiements retail, elles ne suivent pas toutes seules.

La recommandation atterrit sur un écran. Un planneur la lit et en approuve une partie. Il en surcharge une autre pour une raison que le modèle n'a jamais vue — une promesse fournisseur, un réagencement magasin, un engagement du comité d'achat. Puis il ressaisit les survivantes dans l'ERP, l'outil de prix ou le WMS à la main. Le temps qu'elle atteigne le terrain, l'optimisation élégante est passée par un filtre manuel qui en abandonne, par observation répétée, bien plus de la moitié.

Ce n'est pas un défaut des maths — c'est la frontière de la catégorie. L'analytique prescriptive a été conçue pour calculer la meilleure action, point. Savoir si cette action est engagée, exécutée et mesurée est le problème d'un autre — en général un humain et son tableur. C'est le même passage de relais hors écran qui rend les outils BI productifs en apparence sans rien changer. Le sommet de l'échelle analytique se révèle être un belvédère, pas un pont.

Le coût de cet écart est invisible en POC et brutal à l'échelle. Une recommandation que personne n'exécute produit zéro marge. Une recommandation exécutée trois jours trop tard, après la ressaisie et la réunion du lundi, produit une fraction de sa valeur modélisée. Le moteur peut être parfaitement juste et le résultat rester médiocre. Car la valeur n'a jamais été dans la recommandation — elle était dans la décision exécutée, précisément le barreau que l'échelle ne dessine pas.

Analytique prescriptive vs couche de décision

La catégorie qui porte l'action à travers cet écart est une couche de décision — ce que nous appelons ailleurs l'IA opérationnelle. Le plus simple est de prolonger l'échelle de deux barreaux que l'analytique prescriptive omet.

Analytique prescriptiveCouche de décision
Sortie finaleUne action recommandéeUne action engagée et exécutée
ContraintesAppliquées dans l'optimisationEmbarquées dans le moteur, imposées à l'exécution
Rôle humainLit et arbitre chaque recommandationPose les garde-fous, valide les cas sensibles
Où ça finitÀ l'écranDans l'ERP / WMS / moteur de prix
BoucleRelancer le modèle au cycle suivantLe résultat exécuté affine la décision suivante
Métrique de succèsQualité de la recommandationDécisions exécutées × leur impact mesuré

Regardez les deux dernières lignes. Une couche de décision engage l'action — transférer 40 unités du magasin A au magasin C avant jeudi — et la réinjecte dans le système qui l'exécute. Le résultat revient affiner la décision suivante. L'analytique prescriptive s'arrête à la première ligne et confie le reste à un humain ; ce sont deux barreaux de plus qui font bouger la marge. On les voit à l'œuvre dans le cas d'usage agents de démarque et de transfert.

Comment savoir laquelle un éditeur vend

Les deux se vendent avec le même mot. La distinction remonte avec une question et deux relances, à poser dans n'importe quelle démo.

  • « Après la recommandation, que se passe-t-il ? » Si la réponse est « un planneur revoit et applique », vous achetez de l'analytique prescriptive. Si c'est « la plateforme engage l'action et l'écrit dans le système d'exécution, avec une voie de surcharge humaine », vous achetez une couche de décision.
  • « La sortie atterrit sous quelle forme ? » Un graphique, une liste classée, un export — versus un ordre de transfert, un changement de prix, une quantité de réassort, posté dans le système qui agit dessus.
  • « Quel pourcentage de recommandations est exécuté sans modification aujourd'hui, chez un client en production ? » Un éditeur d'analytique prescriptive mesure rarement ce chiffre, car le taux d'exécution n'a jamais été son livrable. Un éditeur de couche de décision devrait répondre tout de suite.
  • « Où vivent les contraintes ? » Appliquées une fois dans l'optimisation, ou embarquées dans le moteur et réimposées au moment de l'exécution, pour qu'une recommandation périmée ne parte pas ?

Rien de tout cela ne fait de l'analytique prescriptive un mauvais achat. Si votre goulot est vraiment de calculer la meilleure action, c'est l'outil juste. Le piège est de l'acheter en croyant que la décision exécutée est dans la boîte. On découvre, deux saisons plus tard, que le barreau recommandation était le seul obtenu.

Où cela vous laisse

L'analytique prescriptive est un barreau réel et précieux — le point où l'analytique cesse de décrire le monde et commence à proposer comment agir. La formulation honnête est de la voir pour ce qu'elle est : le sommet de l'échelle analytique, pas le sommet de l'échelle décisionnelle. Les deux barreaux supplémentaires — engager et exécuter — sont au-dessus, et ce sont eux qui touchent le P&L.

C'est la couche que Solya est conçue pour être. La couche intelligence tient ensemble la prévision, l'objectif et les règles métier. La couche orchestration engage l'action résultante et la réinjecte dans les systèmes qui font tourner le terrain, puis ferme la boucle sur le résultat. L'analytique prescriptive calcule la recommandation. La couche de décision en fait un réassort, un transfert ou une démarque qui arrive vraiment.

La question à se poser n'est pas « avons-nous de l'analytique prescriptive ? » — beaucoup d'enseignes en ont. C'est « sur les actions que nos modèles recommandent, combien sont exécutées, sans modification, à temps ? » Si ce chiffre est bas, la pièce manquante n'est pas une meilleure recommandation. Ce sont les deux barreaux au-dessus.


Jusqu'où votre stack grimpe-t-elle vraiment ?

Chez Solya, nous proposons aux responsables data et opérations un diagnostic de 30 minutes. Nous cartographions, sur votre contexte, là où votre analytique cesse de recommander et si quelque chose porte l'action jusqu'à l'exécution.

Vous repartez avec :

  • Une lecture du barreau que votre stack atteint — prédictif, prescriptif, ou décision exécutée
  • Une estimation de la perte entre recommandation et exécution sur vos boucles clés
  • Les premières décisions à boucler, de la démarque au transfert au réassort
Kevin DidelotCo-founder & CTO, Solya

Co-fondateur et CTO de Solya.

Articles similaires