D'Excel au tableau de bord de direction : la BI chez un distributeur canarien

Il arrive un moment, dans la vie de tout distributeur, où Excel cesse d'être un outil de gestion pour devenir un problème de gestion. Le symptôme est toujours le même : chaque responsable a son propre fichier, les chiffres ne concordent pas d'un service à l'autre et la direction décide avec des informations qui ont entre deux et sept jours de retard. C'est exactement là qu'en était notre client lorsqu'il nous a contactés.

Le défi : décider à l'aveugle dans une entreprise qui a des données partout

Ce distributeur de produits surgelés est présent sur trois îles —Grande Canarie, Tenerife et Lanzarote— et réalise un peu plus de 14 millions d'euros de chiffre d'affaires annuel. Son catalogue compte plus de 600 références actives : poissons, fruits de mer, viandes, volailles et plats cuisinés. Il sert environ 280 clients actifs : hôtels, restaurants, supermarchés et restauration collective.

À notre arrivée, le paysage technologique était le suivant : l'ERP principal était Oracle SIGES, utilisé pour les achats, les ventes, la facturation et la comptabilité. En parallèle, une base PostgreSQL maison permettait à l'équipe d'entrepôt de gérer le stock en temps réel (les limites du module de stock de SIGES avaient motivé ce développement parallèle). Et puis il y avait les fichiers Excel : au moins huit classeurs différents, que plusieurs personnes des équipes financière et commerciale mettaient à jour à la main chaque semaine à partir d'exports de l'ERP.

Le problème central était l'absence de visibilité sur les marges. La direction savait combien elle vendait et combien elle achetait globalement, mais ne pouvait pas répondre à des questions de base : quelle catégorie de produits a la meilleure marge ce mois-ci ? Quelle île est la plus rentable ? Quels clients génèrent le plus de volume mais le moins de marge ? Pour répondre à n'importe laquelle de ces questions, le directeur financier avait besoin de trois à cinq jours de travail manuel.

Diagnostic : trois problèmes techniques et un problème d'organisation

Problème 1 : des sources de données dispersées

Les ventes et les achats se trouvaient dans Oracle SIGES. Le stock réel, dans PostgreSQL. Les prix moyens pondérés (PMP) —indicateur essentiel dans la distribution pour calculer la marge réelle de chaque vente— étaient dans Excel. Aucun système ne communiquait avec les autres. Pour calculer la marge d'une vente, il fallait rapprocher à la main le prix de vente de SIGES et le PMP du fichier Excel correspondant.

Problème 2 : la latence de l'information

Dans le meilleur des cas, les données des tableaux de bord de direction avaient 24 à 48 heures de retard. Les exports de SIGES étaient lancés manuellement et traités dans Excel le lendemain matin. En pratique, la plupart des rapports dataient de 3 à 7 jours.

Problème 3 : aucun KPI de marge par axe d'analyse

Il n'existait aucun rapport systématique de marge par catégorie de produits, par client, par île ou par commercial. Le calcul existait en tant que concept dans l'ERP, mais la structure des tables de SIGES (en particulier la table TCABMOVISTOCKS et ses types de documents CDCLADOC) rendait difficile l'extraction directe d'une marge par vente sans un processus ETL dédié.

Problème d'organisation : la dépendance aux personnes

90 % du savoir sur la manière d'interpréter les données était dans la tête de deux personnes : le directeur financier et le responsable des achats. Si l'une des deux était absente, l'information s'arrêtait. Il n'y avait ni documentation du processus, ni contrôles automatiques, ni traçabilité des modifications dans les fichiers Excel.

La solution : un Data Warehouse moderne avec une restitution pour la direction

Nous avons proposé une architecture en trois briques : un Data Warehouse sur PostgreSQL managé dans AWS comme couche de stockage et de transformation, des pipelines ETL en Python + Apache Airflow pour extraire et charger les données depuis les sources, et Power BI Embedded comme couche de visualisation accessible depuis le navigateur, sans licences de bureau.

Extraction depuis Oracle SIGES

L'extraction depuis SIGES a été la partie la plus délicate du projet. La base Oracle présente une structure de tables héritée, à la nomenclature cryptique, et les types de mouvements de stock sont codés dans le champ CDCLADOC de TCABMOVISTOCKS, avec des valeurs qui indiquent s'il s'agit d'une vente, d'un retour, d'un transfert entre entrepôts ou d'un ajustement d'inventaire. Il a fallu comprendre précisément quelles valeurs de CDCLADOC correspondaient à des ventes réelles (aux clients finaux, hors transferts internes) pour construire correctement le compte d'exploitation.

Le pipeline d'extraction utilise une connexion JDBC vers Oracle et s'exécute via Airflow avec des rafraîchissements toutes les heures, en chargeant de manière incrémentale les mouvements de la dernière heure. La latence des tableaux de bord est passée de 24-48 heures à moins d'une heure. Les données sont chargées dans une couche de staging, puis transformées par des traitements versionnés en tables dimensionnelles du modèle en étoile.

Le calcul du PMP : le cœur de la marge

Le prix moyen pondéré est l'indicateur le plus important pour un distributeur : il reflète le coût réel de chaque unité vendue, pondéré par les différents achats qui composent le stock disponible. Sa formule est simple en théorie (PMP = (Stock précédent × PMP précédent + Quantité entrée × Prix d'entrée) / (Stock précédent + Quantité entrée)), mais en pratique elle dépend d'une mise à jour correcte à chaque mouvement d'entrée.

Dans SIGES, le PMP est mis à jour automatiquement à chaque bon de réception, mais certaines situations le faussent : retours clients réintégrés au stock au prix de vente, régularisations d'inventaire et achats assortis de remises rétroactives. Le pipeline ETL comprend une couche de contrôle du PMP qui détecte les anomalies statistiques et alerte (variations de plus de 15 % du PMP d'une référence en une seule journée).

Calendrier du projet : 8 semaines entre la signature et le go-live

Le tableau de bord de direction : ce que voit la direction

Le résultat final se compose de quatre vues principales dans Power BI, accessibles depuis le navigateur avec l'authentification de l'entreprise :

• Compte d'exploitation mensuel : ventes brutes, retours, ventes nettes, coût des ventes (calculé sur le PMP), marge brute et taux de marge. Comparaison avec le mois précédent et avec le même mois de l'année dernière.
• Marge par catégorie : vue détaillée des cinq catégories principales (poissons, fruits de mer, viandes, volailles, plats cuisinés) avec leur évolution mensuelle. C'est dans cette vue que l'équipe a découvert, dès la deuxième semaine d'utilisation, que la catégorie des plats cuisinés avait une marge négative sur deux des trois îles.
• Analyse par client et par île : classement des clients par volume de ventes, par marge brute et par ratio marge/ventes. Filtres par île et par canal (hôtellerie-restauration, distribution, restauration collective).
• Gestion des stocks : stock actuel par référence et par entrepôt, jours de couverture (stock / moyenne des ventes des 30 derniers jours), alertes de surstock (couverture supérieure à 60 jours) et de rupture (couverture inférieure à 7 jours).

Résultats : ce qu'ils ne savaient pas qu'ils ignoraient

L'impact le plus immédiat n'a pas été le gain de temps, mais les découvertes. Dès la première semaine d'utilisation du tableau de bord, la direction a identifié trois situations invisibles avec l'ancien système :

• La catégorie des plats cuisinés à Lanzarote et à Tenerife affichait une marge négative sur les trois derniers mois. En cause : des prix d'achat en hausse de 12 % et des prix de vente qui n'avaient pas été actualisés sur ces îles. La correction tarifaire a généré un impact positif estimé à 38 000 € par an.
• Trois clients du canal hôtellerie-restauration à Grande Canarie représentaient 22 % du volume des ventes mais seulement 8 % de la marge brute, car on leur appliquait des remises commerciales excessives qui ne compensaient pas leur fort volume de retours.
• Le stock de fruits de mer de l'entrepôt de Tenerife présentait une couverture moyenne de 87 jours, bien au-delà d'un seuil raisonnable. Une partie de ce surstock correspondait à des références sans aucun mouvement depuis plus de 45 jours.

La clôture mensuelle, qui demandait cinq jours de travail manuel au directeur financier, se limite désormais à deux heures de revue et de validation du tableau de bord. Le ROI du projet a été atteint en quatre mois, en ne comptant que les gains liés à la correction des prix des plats cuisinés et à l'optimisation du stock de fruits de mer.

Les enseignements du projet

La complexité de SIGES était connue d'avance, mais on n'en mesure la véritable ampleur qu'une fois face au modèle de données. La nomenclature des tables (TCABMOVISTOCKS, TDETMOVISTOCKS, TARTIGEN, TCLIENTES) obéit à une logique propre qui demande du temps avant de pouvoir construire la moindre extraction fiable. Documenter précisément quel CDCLADOC utiliser pour chaque type de mouvement a été décisif pour que le compte d'exploitation concorde avec la comptabilité officielle.

Le second enseignement a été l'importance d'impliquer l'équipe financière dès le premier jour. Non pas comme valideurs en fin de projet, mais comme co-concepteurs du modèle de données et des KPI. Les marges qui comptent pour le directeur financier ne sont pas celles qui comptent pour le dirigeant. Avoir cette conversation en semaine un, et non en semaine six, a évité deux semaines de refonte.