Pilotage de la supply chain d'un réseau de points de vente

Cette mission est couverte par un accord de confidentialité. Le client, son enseigne et ses chiffres ne sont pas cités.

Le contexte

Une PME de vente au détail exploitant plusieurs points de vente et un dépôt central.

Contrairement à beaucoup de structures de cette taille, ce client était déjà bien digitalisé : un ERP, des caisses, des données centralisées. Le problème n'était donc pas un manque d'outils, mais un outil devenu inadapté à la trajectoire de l'entreprise.

Dans les limites de l'accord de confidentialité, je n'entre pas dans le détail du nombre de points de vente ni du volume de références — ce qui compte pour cette étude de cas, c'est que la structure gère un réseau multi-magasins avec un dépôt central, à une échelle où le pilotage manuel par extraction et Excel n'est plus tenable.

Le problème à résoudre

L'ERP en place faisait très bien le travail cinq ans plus tôt. Avec la croissance de l'entreprise et ses perspectives d'évolution, il était devenu le principal point de friction — précisément là où l'enjeu était le plus fort : la gestion des stocks et le pilotage par les chiffres.

Le processus réel ressemblait à ceci, à chaque cycle :

1. extraire manuellement de l'ERP les données de ventes ;
2. extraire manuellement les données de stocks ;
3. enchaîner de lourdes manipulations Excel pour croiser les deux jeux de données ;
4. reconstituer à la main les indicateurs nécessaires au pilotage de la supply chain.

Le coût de ce processus était double. D'abord le temps — des heures absorbées par de la manipulation de tableur. Ensuite, et c'est plus grave, le délai : le temps que les indicateurs soient prêts, la situation qu'ils décrivaient avait déjà changé. On pilotait avec un rétroviseur.

Ce cycle se répétait à intervalle régulier, avec la même charge de travail à chaque fois — puisqu'aucune partie n'en était automatisée, rien ne se capitalisait d'un cycle sur l'autre.

Ma méthode

Comprendre avant de coder

Je n'ai pas reçu un cahier des charges : je suis allé le chercher. J'ai recueilli le besoin moi-même, en interviewant les personnes concernées et en observant précisément ce que le chargé de supply chain faisait à la main.

C'est une étape qu'on saute trop souvent, et c'est pourtant celle qui décide de tout. Automatiser un processus sans l'avoir compris revient à figer ses défauts dans du code. En l'observant, on identifie ce qui doit être automatisé tel quel, et ce qui doit d'abord être optimisé parce que la manière manuelle de faire était elle-même un contournement.

Concevoir avec les contraintes, pas contre elles

J'ai ensuite conçu l'architecture en partant des contraintes réelles : celles de l'ERP existant et celles de leur système d'information.

Livrer tôt, puis itérer

Les premières versions sont arrivées rapidement. J'ai formé les utilisateurs, recueilli leurs retours, et on a amélioré et optimisé l'outil au fur et à mesure avec le client. C'est ce cycle court qui explique que le périmètre ait continué à s'enrichir jusqu'en mars 2026.

L'architecture, et pourquoi elle compte

La contrainte : un ERP WinDev sur base HFSQL

L'ERP est développé en WinDev, avec HFSQL comme base de données. Pour construire un outil de KPI, il fallait pouvoir lire ces données — ce qui n'est pas trivial avec cet écosystème.

J'ai donc pris en main WinDev et HFSQL pour monter une API exposant les données, déjà prétraitées et agrégées côté source.

Le découplage, le vrai choix d'architecture

C'est le parti pris central de ce projet, et il est stratégique plus que technique.

Tous les calculs complets de KPI et la finalisation des agrégations vivent dans un BFF en Nuxt, pas dans l'API adossée à l'ERP. L'API ne fait que fournir de la donnée ; l'intelligence métier est ailleurs.

La raison est simple : l'ERP finira par changer. C'était même une hypothèse explicite du projet. Avec cette séparation, un changement d'ERP ne remet pas l'outil en cause — il suffit de réécrire l'API qui alimente le BFF, et tout le reste continue de fonctionner. On a donc construit un outil qui survit à la brique qu'il compense.

Le front

Nuxt avec Vuetify pour l'interface.

Le choix de Vuetify tient en partie à une contrainte du moment : au démarrage du projet, Nuxt UI nécessitait encore une licence payante pour son offre la plus complète, ce qui ne se justifiait pas pour un outil interne à périmètre encore mouvant. Vuetify apporte par ailleurs des composants de data — tableaux denses, graphiques — mieux taillés pour un outil de pilotage que pour un site vitrine, où la priorité va davantage à l'image et à la conversion.

Les fonctionnalités livrées

Le pilotage de la supply chain

• alertes de stock, pour ne plus découvrir un problème quand il est déjà là ;
• prévision de rupture, calculée à partir des ventes constatées sur une période donnée ;
• anticipation des commandes fournisseurs, pour commander au bon moment plutôt qu'en urgence ;
• réapprovisionnement du dépôt vers les magasins ;
• dispatch entre magasins en fonction du stock dormant, pour faire circuler ce qui ne tourne pas dans un point de vente vers celui où il se vendra.

Le mail quotidien d'alerte

Chaque jour, un mail signale les produits et les stocks qui nécessitent une attention parce qu'une rupture est imminente.

C'est le point qui change le plus le quotidien : l'information vient à l'utilisateur, il n'a plus à aller la chercher dans un outil. Un tableau de bord qu'on doit penser à ouvrir n'est consulté qu'après le problème.

L'analyse à la demande

L'outil permet de lancer une analyse de l'état actuel des stocks en tenant compte des ventes sur une période choisie. C'est ce qui remplace, en quelques secondes, la séquence extraction/Excel qui prenait des heures.

L'export Excel complet

Un export Excel complet reste disponible. Ce n'est pas une contradiction avec l'objectif du projet : on a supprimé le tableur comme outil de calcul obligatoire, pas comme format d'échange. Il reste précieux pour une analyse ponctuelle, une transmission au comptable ou une négociation fournisseur.

Dans les limites du NDA, je ne détaille pas ici les seuils exacts ni la mécanique fine des calculs. Le principe reste le même que pour tout indicateur de ce type : croiser l'historique des ventes avec le stock disponible pour distinguer ce qui va manquer de ce qui ne se vend simplement pas, plutôt que de traiter les deux situations comme un même problème de stock.

Les résultats

Le NDA m'empêche de partager des chiffres précis sur cette mission. Ce que je peux dire, tel que rapporté par le client : un gain de temps réel sur le cycle de pilotage, et surtout un confort de travail qui n'existait pas avant — l'équipe supply chain passe désormais son temps à décider plutôt qu'à préparer les données qui permettent de décider.

Ce que j'en retiens

Un ERP qui ne suit plus la croissance d'une entreprise n'appelle pas forcément son remplacement. C'est souvent la réaction par défaut — et la plus coûteuse, en temps comme en risque. Ici, la bonne réponse a été de construire au-dessus ce que l'ERP ne savait plus faire, en isolant suffisamment l'outil pour qu'il survive au jour où l'ERP sera effectivement changé.

Le choix qui a le plus de valeur dans ce projet n'est pas visible dans les fonctionnalités livrées, il est dans l'architecture : séparer la lecture des données brutes du calcul des indicateurs revient à accepter, dès le premier jour, que l'ERP est une pièce temporaire. Peu de projets sont conçus avec cette hypothèse en tête, et c'est souvent ce qui les rend fragiles le jour où cette pièce change.