Stack data retail vs stack décisionnel

Dessinez le stack technologique d'un retailer au tableau et presque tout le monde dessine la même chose. Les sources en bas — caisse, ERP, WMS, e-commerce. Une couche d'ingestion au-dessus, un entrepôt ou un lakehouse au milieu, une couche de transformation. Et la BI au sommet, là où le schéma s'arrête. Il a l'air complet parce que chaque case est remplie et chaque flèche connectée.

Il n'est pas complet. Il manque l'étage où les décisions se prennent réellement.

La modern data stack a résolu un vrai problème : amener une donnée propre, réconciliée et interrogeable au même endroit. Ce problème est aujourd'hui largement résolu. Ce qu'elle n'a jamais prétendu résoudre, et que la plupart des schémas retail omettent en silence, c'est la conversion de cette donnée en action sur le terrain. Cet article sépare les deux étages : le stack data qui décrit, et le stack décisionnel qui décide. Ce ne sont pas la même architecture, et on n'atteint pas l'un en prolongeant l'autre.

Deux stacks qu'on dessine comme un seul

La confusion est structurelle, pas négligente. Le stack data et le stack décisionnel partagent les mêmes entrées et cohabitent sur le schéma, donc on les dessine comme une colonne unique. Mais ils répondent à des questions différentes et émettent des unités de travail différentes.

Le stack data répond à qu'est-ce qui est vrai et que s'est-il passé. Son unité de sortie est une ligne, une métrique, un graphique. Le stack décisionnel répond à qu'est-ce qu'on en fait, et fais-le arriver. Son unité de sortie est une action engagée sur un objet précis — réapprovisionner ce SKU, transférer celui-là, démarquer un troisième.

Les traiter comme un seul étage, c'est ainsi qu'une enseigne se retrouve avec un entrepôt magnifiquement instrumenté et un dashboard de sell-through rafraîchi toutes les heures. Pendant ce temps, un acheteur ressaisit encore les ordres de transfert dans l'ERP à la main. La donnée est composable. La décision n'est même pas sur le schéma.

Le stack data retail : conçu pour décrire

Le stack data a une forme bien comprise, et il a sa raison d'être. L'ingestion récupère depuis les systèmes opérationnels — les outils d'extraction qui posent les flux caisse, ERP, WMS et e-commerce au même endroit. Le stockage les conserve dans un entrepôt ou un lakehouse. La transformation les modélise — la couche sémantique où « stock disponible » et « sell-through » reçoivent une définition canonique unique. La BI lit là-dedans et le restitue à un humain.

Chaque couche ici est réellement composable. Vous pouvez changer l'outil d'ingestion, changer l'entrepôt, refondre la BI, et le contrat entre couches tient. C'est la grande réussite de la dernière décennie d'ingénierie data, et le retail en profite autant que n'importe quel secteur.

Mais regardez ce que fait la couche du sommet. La BI est descriptive par construction — elle répond aux questions qu'un humain pose, et s'arrête à l'écran. Elle montrera que la marge sur la chaussure femme a perdu trois points le mois dernier. Elle ne décidera pas lequel de 50 000 SKU traiter, dans quel ordre, sous quelles contraintes.

Le stack data se termine sur un graphique, volontairement. C'était le métier, depuis le début.

Le stack décisionnel : conçu pour décider

Le stack décisionnel se pose au-dessus du stack data et le consomme. Il ne remplace ni l'entrepôt ni la couche BI — il lit dans ceux-ci, puis fait ce pour quoi ils n'ont jamais été conçus. Il a ses propres couches, et elles répondent à un autre contrat : non pas la lisibilité, mais l'action exécutée.

Une couche de signaux transforme les métriques réconciliées du stack data en entrées prêtes pour la décision — prévisions de demande, probabilités de rupture, risque de surstock. Une couche d'arbitrage pèse les options concurrentes pour chaque objet : réapprovisionner versus transférer versus démarquer versus ne rien faire, sous planchers de marge, minimums fournisseurs et calendrier commercial. Une couche d'exécution réécrit l'action retenue dans l'ERP, le WMS ou le pricing — sans ressaisie. Et une couche de feedback mesure ce que l'action a produit et le réinjecte.

L'unité de sortie est le révélateur. Le livrable du stack data est un graphique qu'on lit. Celui du stack décisionnel est un ordre d'allocation ou de réapprovisionnement qui atterrit dans le WMS sans qu'un humain le retape. Nous ouvrons l'intérieur de cet étage dans l'architecture d'une plateforme decision intelligence. Le point ici est plus étroit : c'est un étage distinct, pas une fonctionnalité de la BI.

Là où le stack data s'arrête

La couture entre les deux stacks, c'est là que la marge retail fuit en silence. Le stack data vous remet une description parfaite du problème puis s'arrête, exactement un pas avant l'action. Tout ce qui suit est manuel.

Un dashboard fait remonter qu'un SKU est en surstock à Lyon et en rupture à Bordeaux. Quelqu'un doit le remarquer, décider qu'un transfert vaut mieux qu'une démarque, vérifier que la marge tient, et saisir l'ordre dans le WMS. Multipliez par des dizaines de milliers de couples SKU/magasin chaque semaine et l'arithmétique casse. Aucune équipe d'analystes ne pose la bonne question sur chaque ligne, chaque semaine — donc la plupart des lignes ne reçoivent aucune décision.

C'est l'écart que comble un stack décisionnel, et il est invisible sur le schéma standard parce que le schéma s'arrête simplement à la BI. Nous avons posé la version large de cet argument dans pourquoi les outils BI ne prennent pas de décisions et les données retail inutiles sans couche de décision. La lecture architecturale est la même : le stack est dessiné un étage trop court.

Ce que « composable » exige vraiment

La composabilité est le bon instinct — mais elle n'a été appliquée qu'à la moitié du stack. L'industrie est devenue rigoureuse sur la composition de l'étage data et n'a jamais prolongé la discipline vers le haut. Une architecture retail vraiment composable traite le stack décisionnel comme un étage de premier rang avec son propre contrat interchangeable, pas comme un module greffé sur la BI.

Cela a une conséquence de conception concrète. L'étage décisionnel doit se brancher sur le stack data que vous exploitez déjà — lire votre entrepôt, consommer vos prévisions existantes, respecter votre couche sémantique — sans imposer une refonte. Si ajouter du décisioning oblige à reconstruire votre stack data, il n'a jamais été composable. Le contrat à la couture est ce qui compte : entrées propres et réconciliées en entrée, actions engagées et explicables en sortie.

C'est aussi pourquoi « ajouter une fonction IA à l'outil BI » est la mauvaise forme. Cela replie un travail d'étage décisionnel dans l'étage de description et perd le contrat. L'arbitrage, l'application des contraintes, la réécriture — tout cela appartient à un étage que le stack data a été délibérément conçu pour ne pas contenir.

L'angle Solya

C'est précisément là que se situe Solya — pas une brique de plus dans votre stack data, mais l'étage décisionnel posé dessus. Solya lit la donnée réconciliée et les prévisions que votre stack produit déjà. Elle exécute un arbitrage multi-options sous vos règles métier au niveau SKU/magasin, puis propage les décisions validées vers votre ERP, votre WMS et votre pricing via la couche d'orchestration. La couche intelligence porte les signaux ; la couche application est l'endroit où les équipes ops pilotent et arbitrent.

Elle est conçue pour être composable de la manière dont le reste de votre stack l'est déjà. Elle se branche sur ce que vous possédez plutôt que de le remplacer — la couche data harmonise, l'étage décisionnel décide. Vous voyez cet étage à l'œuvre dans nos cas d'usage réassort en continu et agents IA sur les démarques et transferts. Le stack data que vous avez déjà bâti garde son métier. Solya ajoute celui du dessus.

La question à poser à votre propre stack

Dessinez votre stack au tableau et regardez la case du sommet. Si c'est de la BI — un graphique, une métrique, un écran — demandez où la décision se prend. Si la réponse honnête est « en réunion hebdo » ou « un acheteur le remarque et le ressaisit », votre stack s'arrête à la description. L'étage décisionnel est alors tenu par des humains qui font le travail d'un système.

Cet écart n'est pas un manque d'outillage à l'intérieur du stack data. C'est un étage manquant au-dessus. Les retailers qui prennent de l'avance ne sont pas ceux qui ont l'entrepôt le plus affûté ou le plus de dashboards. Ce sont ceux qui ont cessé de dessiner le stack un étage trop court.

---

Votre stack est-il dessiné un étage trop court ?

Chez Solya, nous proposons aux directions data et opérationnelles un diagnostic personnalisé de 30 minutes. Il cartographie votre stack actuel et pointe exactement où la description s'arrête et où le décisioning devrait commencer. À l'issue de cet échange, vous repartirez avec :

• Une carte couche par couche de votre stack, avec l'étage décisionnel marqué là où il manque
• Les décisions précises qui tombent aujourd'hui dans la couture entre la BI et vos systèmes opérationnels
• La première boucle à fort ROI à fermer de bout en bout par-dessus le stack data que vous possédez déjà