Modéliser des flux logistiques : le schéma en étoile n'est pas toujours la réponse
Sur des données de traçabilité colis, la granularité événementielle casse le modèle dimensionnel classique. Comment j'ai contourné le problème.


Une partie de ce que je publie ici vient directement de ces projets.
Le schéma en étoile est l'outil par défaut du décisionnel, et pour de bonnes raisons : une table de faits, des dimensions autour, des mesures additives, et l'analyse devient limpide. Mais sur des flux logistiques faits d'événements successifs - prise en charge, tri, transport, mise en distribution, livraison - ce modèle montre vite ses limites.
Le heurt : un événement n'est pas un fait agrégé
Un colis n'est pas une ligne : c'est une suite d'événements datés, chacun avec son lieu, son statut, son horodatage. Vouloir en faire une table de faits classique pose un problème de fond : la mesure intéressante n'est pas une quantité additive (un montant, un volume), c'est un délai entre deux jalons - donc quelque chose qu'on ne peut ni sommer ni moyenner naïvement sans se tromper.
De plus, un même colis peut repasser par un statut, être réacheminé, rester bloqué. La granularité événementielle produit des trajectoires irrégulières que la grille figée d'une étoile classique modélise mal.
Ce qui casse dans l'étoile classique
Trois symptômes reviennent quand on force le modèle :
- L'explosion des lignes : une table de faits à l'événement gonfle vite, et les jointures sur les dimensions deviennent coûteuses pour des questions simples.
- Les mesures non additives : sommer des délais ou des statuts n'a aucun sens, mais l'outil de BI, lui, proposera joyeusement de le faire.
- Le temps non linéaire : un colis qui recule dans son parcours casse l'hypothèse implicite « chaque événement fait avancer l'état ».
L'approche retenue
Plutôt qu'une table de faits à l'événement, j'ai basculé vers une logique de snapshot accumulé (accumulating snapshot) : une ligne par colis, et les jalons du parcours en colonnes datées. Prise en charge, tri, distribution, livraison deviennent chacun un horodatage. Les délais entre jalons se calculent alors par simple différence, et les statuts terminaux se lisent d'un coup d'œil.
Ce que ça change pour l'analyse
Une fois le modèle en place, les questions métier deviennent triviales à répondre côté Power BI : délai moyen entre prise en charge et livraison, taux de colis passés par un ré-acheminement, part de trajets dépassant un seuil. Ce qui demandait des requêtes tortueuses sur des événements se lit désormais directement sur des colonnes.
La morale n'est pas « le schéma en étoile est mauvais ». C'est qu'un modèle dimensionnel se choisit d'après la question posée, pas d'après l'habitude. Sur des flux, le bon réflexe est de raisonner en jalons datés avant de raisonner en faits et dimensions.


