Appearance
Méta-modèle multidimensionnel Heriade — Spécification technique
0. Contexte plateforme
Heriade est composé de plusieurs modules, rattachés à une entreprise cliente via une console d'administration centrale (création entreprise, utilisateurs, souscription aux modules). L'utilisateur navigue entre ses modules autorisés depuis un portail unique.
Console admin (entreprises, utilisateurs, modules souscrits)
↓
Portail Heriade (point d'entrée utilisateur)
Formulaire → fournisseur de données (collecte)
↓
BDD → hub de transformation (workflow planifiable et rejouable)
↓
Source Heriade (dossier de données prêtes)
↙ ↘
Addin Excel Rapport
(lecture directe) (import dans Movement, cf. section 3)Ce document (méta-modèle) et docs/spec-vue-pivot.md / docs/spec-bibliotheque-kpi.md concernent spécifiquement le module Rapport. BDD est responsable de produire les Sources Heriade dans un format exploitable, quel que soit le secteur du client — c'est ce qui rend le méta-modèle générique réellement opérationnel : BDD absorbe l'hétérogénéité des formats sources, Rapport n'a jamais à s'adapter au format brut d'un client.
À date, l'import d'une Source Heriade dans le modèle Movement de Rapport reste une action manuelle (déclenchement en un clic) — la Source elle-même peut être rafraîchie automatiquement en amont par BDD, mais ce rafraîchissement ne se répercute pas encore automatiquement dans Rapport.
1. Principe général
Le modèle ne doit jamais coder en dur des objets métier (Résident, Établissement, TO). Il définit des rôles génériques universels, que chaque client instancie avec son propre vocabulaire métier. Le moteur (structure de données, calculs) est générique ; l'interface visible par le client reste toujours en langage métier.
2. Deux natures d'objets dans le cube
- Dimensions : axes d'analyse (qui, quand, où, quel type). Hiérarchiques.
- Faits (mesures) : valeurs numériques agrégeables (montants, heures, quantités).
Ne jamais confondre les deux : une "Catégorie" actuelle (Gestion, Masse salariale, Activité) correspond en réalité à une table de faits, pas à une dimension.
3. Les 4 blocs de dimensions (niveau produit)
| Bloc | Nature | Alimentation | Contenu figé ou paramétrable |
|---|---|---|---|
| 1. Axes source | Dimensions importées, une par source connectée | Import automatique | Paramétrable (nb et nature des sources variables) |
| 2. Référentiels | Données saisies/maintenues manuellement dans l'outil | Saisie utilisateur | Coquille vide, remplie par le client |
| 3. Segments d'analyse | Niveaux hiérarchiques de dimension, rattachés à leur source d'origine | Import ou dérivé | Paramétrable, structuré en hiérarchie (pas de liste plate) |
| 4. Dimensions communes | Temps + Structure, transverses à tout le modèle | Mixte | Temps/Phase : préconfigurables en standard. Structure : paramétrable (libellé métier) |
Règle clé : une entité individuelle à cardinalité élevée (Résident, Salarié, Lot de production) n'est PAS une dimension séparée des segments qui la caractérisent (Poste, Type d'hébergement). C'est le niveau hiérarchique le plus fin de la dimension Structure/Entité, les segments en étant les niveaux intermédiaires.
Exemple de hiérarchie :
Structure
└── Établissement (niveau agrégé)
├── Salarié (RH) → attributs : Poste, Type de contrat
└── Résident (Métier) → attributs : Type d'hébergement3bis. Nature du compte et convention de signe — pour un calcul favorable/défavorable robuste
Deux attributs indépendants, jamais déduits du signe brut d'une valeur observée, nécessaires pour déterminer correctement si un écart est favorable ou défavorable (Vues, Écarts, Pastilles) :
nature(charge|produit) : attribut sur le nœud de dimension (compte), au même titre que les autresDimAttribute. Défini une fois lors de l'organisation des dimensions (docs/spec-onboarding-entreprise.md).conventionSigne(signe_comptable|valeur_absolue) : attribut au niveau de la connexion/source, pas du compte — propre à la façon dont l'entreprise exporte ses données.signe_comptable= charges négatives, produits positifs (convention standard).valeur_absolue= tout stocké en positif, y compris les charges.
Pourquoi ces deux attributs, et pas une déduction depuis le signe brut : un produit peut légitimement être négatif (avoir, note de crédit), et certaines entreprises exportent leurs charges en valeur absolue plutôt qu'en convention comptable standard. Le signe d'une valeur à un instant donné ne suffit donc jamais à en déduire ni sa nature, ni la convention de la source.
Formule de détermination favorable/défavorable, utilisée partout où cette notion apparaît (Vues, Écarts, Pastilles) :
multiplicateur =
nature = 'produit' → +1
nature = 'charge' ET convention = 'signe_comptable' → +1 (charge moins négative = favorable)
nature = 'charge' ET convention = 'valeur_absolue' → -1 (charge plus petite en absolu = favorable)
favorable = (valeur − référence) × multiplicateur > 0Cette formule est la référence unique — docs/spec-bibliotheque-widgets-restitution.md (Pastilles) et l'écran Écarts doivent tous deux s'y conformer, sans réimplémenter une logique de coloration propre.
4. Rôles génériques (table de correspondance sectorielle)
| Rôle générique | EHPAD | BTP | Agroalimentaire |
|---|---|---|---|
| Entité structurelle | Établissement | Chantier | Site de production |
| Entité individuelle métier | Résident | — | Lot de production |
| Entité individuelle RH | Salarié | Salarié | Salarié |
| Référentiel de capacité | Capacité lits, jours théoriques | Capacité horaire équipe | Capacité machine (cadence, heures dispo) |
| Mesure de remplissage/rendement | TO | Taux d'avancement | TRS |
Critère de définition d'une "entité individuelle" (générique, non limité aux personnes) : grain fin + cardinalité élevée + attributs propres + suivi dans le temps ou traçabilité.
5. Archétypes de tables de faits (génériques, à industrialiser)
| Archétype | Définition | Exemple EHPAD | Exemple Agro |
|---|---|---|---|
| Fait transactionnel | Événement daté, grain fin | Journée facturée par résident | Quantité produite par lot |
| Fait périodique (snapshot) | Mesure figée à une date | Effectif au 1er du mois | Stock matières premières à date |
| Fait cumulé | Compteur qui s'accumule | Ancienneté | Durée de vie restante avant DLC |
Ne pas fusionner les tables de faits de sources différentes dans une table unique : elles n'ont pas le même grain (ex. facturation au jour, paie au mois, référentiel saisi au mois). Fusionner dégraderait le grain le plus fin et empêcherait certains calculs (distribution, cohortes, drill-down individuel).
6. Pattern générique de KPI "remplissage/rendement"
Formule universelle, indépendante du secteur :
Taux = Volume réalisé (fait transactionnel)
/ Capacité théorique disponible (référentiel)Exemple EHPAD (TO) :
TO = SUM(Faits Facturation.journées)
/ (Référentiel.capacité × jours_période − Référentiel.jours_fermeture)Ce pattern doit être livrable comme formule KPI prête à l'emploi dans Heriade, où le client mappe juste ses propres champs (capacité, volume réalisé, indisponibilité) au lieu de recoder le calcul à chaque client.
Point structurant : ce type de KPI croise toujours au moins deux objets : un fait transactionnel ET un référentiel. Sans bloc Référentiels distinct, aucun dénominateur n'est disponible dans le cube — d'où la nécessité de le garder séparé des axes source.
7. Implications produit (back-office / éditeur de dimensions)
- Éditeur de dimension générique avec possibilité d'ajouter des niveaux hiérarchiques (pas listes plates) — fonctionnalité transverse, pas un cas spécifique EHPAD.
- Type de dimension "Entité individuelle" paramétrable : le client crée l'entité, la nomme, l'attache à une ou plusieurs sources, lui définit des attributs (= anciens "segments").
- Bibliothèque de formules KPI génériques (à commencer par le pattern remplissage/rendement) avec mapping de champs par le client, plutôt que du calcul codé en dur par secteur.
- Dimensions Temps et Phase : livrées préconfigurées, non modifiables dans leur structure (uniquement les membres, ex. années disponibles).
- Dimension Structure : toujours présente, libellé paramétrable ("Établissement", "Chantier", "Site").
8. Anti-pattern à éviter
Sur-abstraire l'interface utilisateur (ex. afficher "Entité individuelle type 1" au client). L'abstraction doit rester interne au moteur ; le client ne voit que son vocabulaire métier (Résident, Salarié, Lot, Chantier...).