Vue Pivot — Tableau croisé dynamique self-service

Spécification technique pour Heriade Rapport. Répond à l'écart identifié face à Power BI : permettre à l'utilisateur de composer sa propre vue en assignant des dimensions par clic (façon TCD Excel simplifié), sans développement, plutôt que de dépendre uniquement de vues prédéfinies (TDB, Vues, Rapports actuels).

1. Objectif

Donner à l'utilisateur (DAF, contrôleur de gestion) un écran où il choisit lui-même :

• quel(s) axe(s) mettre en lignes
• quel(s) axe(s) mettre en colonnes
• quelle mesure afficher (montant, quantité, ou un KPI de la bibliothèque)
• quel niveau de la hiérarchie afficher (agrégé ou détaillé)

... sans configuration développeur, sur le modèle d'un tableau croisé dynamique Excel/Power BI, mais nativement branché sur les Movement et les Dimension/DimNode existants.

2. Prérequis modèle (déjà en place, aucune migration nécessaire)

D'après le modèle confirmé (schéma en étoile Movement, moteur pivot()) :

• Chaque axe (compte, analytique, etablissement, segment2/3/4, mois, phase, annee) est déjà un champ exploitable de Movement.
• Le moteur pivot() sait déjà grouper par axe et consolider en remontant l'arbre DimNode.
• La vue pivot est donc une nouvelle interface au-dessus du moteur existant, pas un nouveau moteur de calcul.

3. Modèle de configuration d'une vue pivot

interface PivotViewConfig {
  id: string
  nom: string                       // nom donné par l'utilisateur, sauvegardable
  dupliqueDe?: string                // id de la PivotViewConfig source si créée par duplication (traçabilité, pas de lien vivant)
  lignes: PivotAxisRef[]            // axes empilés en lignes, dans l'ordre (hiérarchie d'affichage)
  colonnes: PivotAxisRef[]          // axes empilés en colonnes
  mesure: {
    type: 'axe_financier' | 'kpi'   // valeur brute (Movement) ou KPI calculé (KpiDefinition)
    ref: string                      // axisField ou kpiDefinitionId
  }
  filtres: PivotFiltre[]            // ex: établissement = X, phase = Réel, année = 2026
  perimetreHierarchique: {
    axis: string
    niveau: 'racine' | 'feuille' | number  // profondeur d'affichage par axe
  }[]
}

interface PivotAxisRef {
  axis: string                       // ex: 'etablissement', 'segment2', 'mois'
  niveauAffiche?: string             // code du DimNode à partir duquel afficher (drill-down partiel)
}

interface PivotFiltre {
  axis: string
  codes: string[]                     // valeurs retenues (multi-sélection)
}

4. Interface utilisateur

Zone de construction

Quatre zones visibles simultanément : Filtres / Lignes / Colonnes / Valeurs, alimentées par la liste des dimensions disponibles (reprend l'arbre en 4 blocs du méta-modèle : Axes source, Référentiels, Segments d'analyse, Dimensions communes).

Mode d'assignation retenu pour le MVP : clic, pas drag & drop inter-zones. Comparé à un TCD Excel, le geste le plus coûteux à développer proprement est le glisser-déposer entre zones (retour visuel au survol, gestion tactile, annulation). On le reporte à une itération ultérieure si l'usage montre que le clic est trop lent en pratique. Pour le MVP :

• Cliquer sur un champ dans la liste des dimensions ouvre un menu court : "Ajouter à Lignes / Colonnes / Filtres / Valeurs".
• Un champ déjà assigné affiche un badge indiquant sa zone actuelle ; cliquer dessus permet de le réassigner ou de le retirer.
• Réordonnancement intra-zone (ex. remonter "Poste" au-dessus de "Établissement" en lignes) via boutons haut/bas ou drag limité à l'intérieur d'une même zone — pas de drag inter-zones.

Imbrication multi-niveaux symétrique. Lignes et colonnes supportent l'empilement de plusieurs axes (ex. Colonnes : Année puis Phase, avec en-têtes fusionnés sur 2 niveaux — voir PivotAxisRef[] en section 3, déjà conçu pour ce cas).

Inversion en un geste. Un bouton "Inverser" par zone (Lignes ↔ Colonnes globalement, ou au sein d'une zone pour changer l'ordre d'empilement, ex. Année→Phase devient Phase→Année) permet de retourner la logique d'imbrication sans réassigner chaque champ un par un. Techniquement : permutation de l'ordre des PivotAxisRef[], ou échange du contenu de lignes et colonnes.

• Lignes : axes empilés verticalement (ex. Établissement > Poste)
• Colonnes : axes empilés horizontalement (ex. Mois > Phase)
• Valeurs : une ou plusieurs mesures (montant, ou KPI de la bibliothèque comme le TO)

Zone de filtres

Filtres rapides au-dessus du tableau (établissement, période, phase) — réutiliser le composant TreePicker existant pour la sélection sur les axes hiérarchiques.

Zone de résultat

Tableau croisé rendu dynamiquement :

• Cellules calculées via pivot(), consolidation identique aux Vues actuelles (somme par défaut, moyenne pondérée pour les indicateurs de stock)
• Totaux de ligne et de colonne calculés automatiquement
• Drill-down au clic sur une cellule ou un en-tête de ligne/colonne (développer un niveau hiérarchique supplémentaire sans reconfigurer toute la vue)
• Export Excel stylé en réutilisant le mécanisme d'export déjà existant sur les Vues

Sauvegarde

• L'utilisateur peut sauvegarder sa configuration de vue pivot (PivotViewConfig) pour la retrouver, au même titre qu'un Rapport existant.
• Optionnel : partage de la configuration entre utilisateurs d'un même compte (à trancher selon le modèle de droits existant, Console des droits).

Duplication de vue

Répond au cas d'usage "reprendre une vue existante et l'adapter" (ex. passer d'une comparaison annuelle Budget/Réel à une vue mensuelle filtrée sur une seule Phase), plutôt que reconstruire depuis zéro.

• La duplication copie l'intégralité de la PivotViewConfig (lignes, colonnes, mesure, filtres, périmètre hiérarchique) vers une nouvelle configuration modifiable indépendamment. Le champ dupliqueDe conserve une traçabilité de l'origine, sans lien vivant : modifier la source après duplication ne modifie pas la copie, et inversement.
• Les graphiques ou insertions liés à la vue source ne sont pas dupliqués automatiquement. Un graphique inséré dans un rapport correspond à une intention de présentation précise ; le dupliquer aveuglément sur une vue pivot potentiellement restructurée (axes inversés, granularité différente) risquerait de produire un graphique incohérent avec sa nouvelle source. Si l'utilisateur veut illustrer la vue dupliquée, il insère un nouveau graphique pointant explicitement dessus.

5. Différence avec les écrans existants (Vues, TDB, Rapports)

Écran	Configuration	Flexibilité
Vues / TDB / Rapports actuels	Prédéfinie par Heriade ou paramétrée en amont	Fixe côté utilisateur final
Vue Pivot (nouveau)	Composée librement par l'utilisateur, axe par axe	Totale, façon tableau croisé Excel/Power BI

La vue pivot ne remplace pas les écrans existants — elle comble l'écart "self-service" identifié face à Power BI, pour les cas où un DAF veut explorer les données sans attendre une configuration développeur ou une demande à Heriade.

6. Intégration avec la bibliothèque de KPI

Si mesure.type = 'kpi', le pivot doit pouvoir croiser un KPI de type remplissage/rendement (TO, TRS) par n'importe quelle combinaison ligne/colonne — par exemple TO en ligne par Établissement, en colonne par Mois. Le moteur de calcul du KPI (docs/spec-bibliotheque-kpi.md, section 5) doit donc être appelable à la maille demandée par la configuration pivot, pas seulement à la maille par défaut d'un dashboard.

7. Phasage suggéré

1. Étape 1 : lecture seule, un axe en ligne + un axe en colonne + une mesure simple (montant), assignation par clic (pas de sauvegarde de configuration) — valider l'ergonomie et la performance du moteur pivot() sur ce nouvel usage.
2. Étape 2 : support multi-axes empilés (lignes et colonnes), réordonnancement intra-zone, inversion en un geste, filtres, drill-down.
3. Étape 3 : sauvegarde de configuration, duplication de vue, export Excel.
4. Étape 4 : intégration des KPI de la bibliothèque comme mesure sélectionnable (dépend de l'avancement de docs/spec-bibliotheque-kpi.md).
5. Étape 5 (optionnelle, selon retours d'usage) : drag & drop inter-zones si le clic d'assignation s'avère trop lent à l'usage pour les utilisateurs avancés.

8. Point de vigilance

Le risque principal n'est pas technique (le moteur pivot() existe déjà) mais ergonomique : un tableau croisé mal maîtrisé par l'utilisateur final peut produire des vues illisibles ou des croisements dénués de sens (ex. moyenne d'un indicateur de stock croisée avec une somme financière sur le même tableau). Prévoir des garde-fous simples : suggestion de consolidation par défaut selon le kind de l'axe, avertissement visuel si deux mesures de nature incompatible sont combinées dans la même vue.