Parcours de création d'une entreprise — Onboarding et détection de dérive

Spécification technique pour Heriade Rapport. Formalise le parcours complet depuis la connexion des premières Sources Heriade jusqu'à la vigilance continue sur les nouveaux éléments apparaissant à chaque rafraîchissement de données.

0. Prérequis — Template des Sources Heriade

Chaque Source Heriade (RH, Finance, Métier) produite par BDD doit respecter un template de colonnes attendu par Rapport (cf. docs/meta-modele-dimensions.md, section 0, chaîne BDD → Source Heriade → Rapport). C'est ce template qui garantit que Movement peut être alimenté de façon prévisible quel que soit le client, indépendamment du format brut de ses systèmes sources.

1. Étape 1 — Première connexion : scan automatique

À la première connexion d'une Source Heriade, Rapport scanne les données reçues et extrait automatiquement :

• Les codes de comptes présents (axe compte, dimension Gestion/Finance)
• Les codes RH et Métier présents (axes correspondants)
• Les codes de segments présents (segment2/3/4)
• Les établissements présents (axe etablissement, dimension Structure)

Ce scan produit une liste à plat des éléments distincts rencontrés dans les données, sans hiérarchie ni classification — c'est la matière brute à partir de laquelle l'étape 2 construit l'arbre DimNode.

2. Étape 2 — Organisation des dimensions

2.1 Création des attributs

Avant de classer les éléments, on définit le schéma de classification de la dimension : quels attributs vont qualifier chaque élément (ex. pour les comptes : Niveau 1, Niveau 2, Groupe SIG ; pour un poste RH : Catégorie, Convention). Cette étape correspond au modèle DimAttribute déjà posé dans le méta-modèle (Phase 3/5).

2.2 Deux modes d'organisation

Option A — Organisation à la main Construction directe de l'arbre DimNode dans l'interface (glisser-déposer, rattachement d'un élément à un nœud parent), adaptée aux dimensions avec peu d'éléments (ex. établissements, quelques segments).

Option B — Export / complétion / import Adaptée aux dimensions volumineuses (typiquement le plan comptable — cas du P&L cité) :

1. Export de la liste à plat des éléments scannés (étape 1), avec des colonnes vides correspondant aux attributs définis (2.1)
2. Complétion hors outil (Excel, par le client ou un consultant Lamare Conseil) : rattachement de chaque élément à son niveau de hiérarchie, ses regroupements
3. Réimport du fichier complété → construction automatique de l'arbre DimNode à partir des colonnes renseignées

Cette double option est cohérente avec l'objectif de duplicabilité évoqué pour le forfait Lamare Conseil : un template d'export/import réutilisable d'un client EHPAD à l'autre accélère fortement l'étape la plus lourde de l'onboarding.

3. Étape 3 — Complétion des référentiels (indicateurs d'établissement)

Une fois les dimensions organisées, saisie des données de référentiel (capacité, jours de fermeture, etc. — cf. docs/spec-bibliotheque-kpi.md, section 5) nécessaires au calcul des KPI de type remplissage/rendement. Cette étape ne peut logiquement intervenir qu'après l'étape 2, puisque le référentiel se rattache aux établissements et segments déjà organisés (ex. capacité par type d'hébergement).

4. Étape 4 — Création des KPI et Pastilles

Une fois les dimensions organisées et les référentiels complétés, création des premiers KPI (wizard, docs/spec-bibliotheque-kpi.md) et Pastilles (docs/spec-bibliotheque-widgets-restitution.md) — ces deux briques dépendent d'un arbre de dimensions déjà stable, d'où leur position en dernière étape de l'onboarding initial.

5. Détection continue — nouveaux éléments à chaque rafraîchissement

Le problème à couvrir

Chaque rafraîchissement de Source Heriade (ex. chargement de la comptabilité d'avril) peut introduire des codes nouveaux, absents de l'arbre DimNode existant — un nouveau compte ouvert par l'expert-comptable, un nouveau poste RH, un nouvel établissement. Sans détection, ces éléments entrent dans Movement mais restent invisibles dans les dimensions déjà organisées (non rattachés à un DimNode), faussant silencieusement les totaux agrégés qui excluent ce qui n'est pas classé.

Mécanisme proposé

À chaque import d'une Source Heriade dans Movement (rappel : import manuel en un clic à ce stade, cf. docs/spec-vue-pivot.md section 2bis) :

1. Comparaison des codes présents dans le nouvel import avec l'ensemble des codes déjà connus par l'arbre DimNode de chaque axe concerné (compte/PnL, RH, Métier, Poste, Analytique, Établissement)
2. Tout code nouveau, non rattaché à un DimNode existant, est signalé comme élément non classé

Modèle de données — état explicite, pas d'absence de valeur

interface ElementNonClasse {
  id: string
  axis: string                    // compte, rh, metiers, segment2/3/4, etablissement...
  code: string                    // code brut détecté dans l'import
  detecteLe: Date
  statut: 'en_attente' | 'classe'  // jamais de statut implicite par défaut
  traitePar?: string               // userId de l'Admin ayant classé l'élément
  dimNodeIdCible?: string          // renseigné uniquement une fois classé explicitement
}

Règle non négociable : un ElementNonClasse reste au statut en_attente indéfiniment tant qu'aucun Admin n'a agi. Il ne doit exister aucun mécanisme, job planifié, ou valeur par défaut qui fasse passer un élément à classe sans une action explicite d'un utilisateur avec le rôle Admin (dimNodeIdCible et traitePar renseignés simultanément, jamais l'un sans l'autre). Un élément en_attente est exclu de tous les calculs agrégés qui dépendent de la hiérarchie DimNode — il vaut mieux un total visiblement incomplet (avec le badge d'alerte qui l'explique) qu'un total complet mais silencieusement faux.

Warning sur les profils Admin

Un indicateur visuel (badge de comptage, sur le modèle des badges déjà existants dans le bandeau — ex. le badge "68" sur Gestion/Finance) apparaît sur l'entrée Modélisation, visible uniquement pour les profils Admin (cohérent avec docs/spec-reorganisation-bandeau.md — Modélisation reste un écran Admin). Le badge indique le nombre d'éléments non classés en attente de traitement.

Un Admin peut alors :

• Rattacher chaque nouvel élément à un nœud existant (organisation à la main, comme en étape 2.1)
• Ou repasser par un cycle export/complétion/import si le volume de nouveaux éléments est important (ex. changement de plan comptable en début d'année)

Ce que ce mécanisme ne doit pas faire

Ne jamais classer automatiquement un nouvel élément par défaut (ex. le rattacher à un nœud générique "Non classé" qui serait ensuite inclus dans les totaux) — ça masquerait le problème plutôt que de le signaler. Un élément non classé doit rester visible comme tel jusqu'à ce qu'un Admin tranche explicitement où il doit apparaître dans la hiérarchie.

6. Récapitulatif du parcours

0. Template Sources Heriade (BDD)
        ↓
1. Première connexion → scan automatique (codes bruts)
        ↓
2. Organisation des dimensions
   2.1 création des attributs
   2.2 organisation manuelle OU export/complétion/import
        ↓
3. Complétion des référentiels (indicateurs établissement)
        ↓
4. Création des KPI et Pastilles
        ↓
5. En continu : détection de nouveaux éléments à chaque rafraîchissement
   → warning (badge) sur profils Admin → traitement manuel (2.1 ou 2.2)

7. Phasage suggéré

1. Étape A : scan automatique (étape 1) + organisation manuelle (option A de l'étape 2) — couvre le cas d'une dimension avec peu d'éléments (ex. établissements), valide le mécanisme de base.
2. Étape B : export/complétion/import (option B de l'étape 2) — nécessaire dès le premier client avec un plan comptable volumineux.
3. Étape C : détection continue de nouveaux éléments (section 5) — peut n'être développée qu'une fois qu'un premier client est en usage régulier avec des rafraîchissements mensuels réels, pour caler le mécanisme sur des cas concrets plutôt que des hypothèses.

8. Point de vigilance

Le risque principal de l'étape C est le volume de faux positifs si la définition de "nouveau" est trop stricte (ex. un code déjà connu mais avec une casse différente, ou un espace en trop, déclenchant un faux signalement). Prévoir une normalisation des codes avant comparaison (trim, casse) pour éviter de saturer le badge Admin avec des éléments qui ne sont pas réellement nouveaux.