Réorganisation du bandeau — Lecteur / Modeleur / Administrateur

Spécification technique pour Heriade Rapport. Fait suite à la réorganisation en 4 blocs du méta-modèle (docs/meta-modele-dimensions.md), qui portait sur la classification des dimensions. Cette spec porte sur un axe différent et complémentaire : la classification de l'ensemble des écrans du bandeau selon le niveau d'intervention de l'utilisateur.

1. Objectif

Réorganiser le bandeau de navigation en 3 niveaux empilés verticalement, du plus consultatif au plus structurant :

LECTEUR       (haut)    — consultation pure, aucune configuration possible
MODELEUR      (milieu)  — pilotage régulier : saisie, ajustement, création de KPI
CONSTRUCTEUR  (bas)     — structure et administration du modèle

Le critère de tri n'est pas la nature fonctionnelle de l'écran (compta/RH/métier, déjà traité par le méta-modèle), mais qui a besoin d'y agir et avec quel niveau de risque : un utilisateur limité au niveau Lecteur ne peut rien casser dans le modèle.

2. Mapping des écrans existants

D'après la structure actuelle du bandeau (Restitution, Planification, Contrôle de gestion, Modélisation, Sources, footer) :

Niveau	Section	Écrans
Lecteur	Restitution	Tableaux de bord, Vues, Rapports
Lecteur	Vue pivot	Consultation et exploration (lecture seule, pas de sauvegarde de configuration partagée)
Modeleur	Vue pivot	Création et sauvegarde de configurations pivot (cf. section 3, doublon volontaire)
Modeleur	Planification	Projection/Saisie, Modèles de fiches, Écran de saisie
Modeleur	Contrôle de gestion	Écarts, Ajustements
Modeleur	Bibliothèque	KPI, Pastilles, Graphiques — regroupés sous une même entrée de navigation (cf. docs/spec-bibliotheque-widgets-restitution.md)
Administrateur	Modélisation	Axes source, Référentiels, Segments d'analyse, Dimensions communes, Scénarios, Domaines, Modèles de présentation
Administrateur	Sources	Connexions
Administrateur	Administration	Console des droits, Sauvegardes, Paramètres

3. Cas particulier : Vue pivot présente à deux niveaux

Décision retenue (à date de cette spec) : Vue pivot apparaît à la fois en Lecteur et en Modeleur, avec un périmètre de droits différent à chaque niveau — pas deux écrans distincts.

• Entrée Lecteur : consultation de vues pivot déjà configurées (par soi-même ou partagées), exploration ad hoc, aucune sauvegarde de configuration.
• Entrée Modeleur : création de nouvelles configurations pivot, sauvegarde personnelle ou partagée (cf. docs/spec-vue-pivot.md, section 4 sur la sauvegarde).

Ce doublon est volontaire et non figé : si l'usage réel montre que la distinction n'apporte rien (ex. la majorité des lecteurs ne consultent jamais de pivot sans vouloir en créer un), les deux entrées pourront être fusionnées dans une itération ultérieure. Ne pas sur-interpréter cette dualité comme un principe général à répliquer sur d'autres écrans sans réexamen au cas par cas.

4. Cas particulier : Indicateurs (KPI) classé Modeleur

Le KPI est une définition structurante (elle affecte tous les rapports qui l'utilisent ensuite), mais le choix retenu est de le classer en Modeleur, pas Administrateur, pour rester cohérent avec l'objectif produit : un CDG « un peu tech » doit pouvoir créer son propre KPI de façon autonome via le wizard (docs/spec-bibliotheque-kpi.md), sans dépendre d'un profil Administrateur.

Point de vigilance qui en découle : un KPI mal configuré par un profil Modeleur peut fausser tous les rapports qui l'utilisent. Le wizard doit donc porter l'essentiel de la responsabilité de prévention d'erreur (aperçu en direct, garde-fous de cohérence — cf. section 8 du doc bibliothèque KPI), puisque le niveau d'accès ne filtre plus ce risque en amont.

5. Articulation avec la Console des droits existante

Le modèle de droits actuel (Console des droits, restriction par établissement) doit être étendu pour porter aussi ce critère de niveau (Lecteur / Modeleur / Administrateur), en plus du périmètre par établissement déjà existant. Un utilisateur a donc deux dimensions de droits croisées :

• Quel périmètre (quels établissements il voit/modifie) — déjà en place
• Quel niveau d'action (Lecteur/Modeleur/Administrateur) — nouveau, objet de cette spec

Le rôle "contrôleur" visible dans l'interface actuelle (ex. "M. Bernard · contrôleur") est probablement un bon point de départ pour un premier mapping rôle → niveau par défaut, à affiner ensuite écran par écran plutôt que rôle par rôle si des exceptions apparaissent.

6. Phasage suggéré

1. Étape 1 : réorganisation purement visuelle du bandeau (3 groupes empilés), sans toucher aux droits réels — tous les utilisateurs actuels voient tout, seul l'ordre/regroupement change. Valide l'ergonomie avant de restreindre quoi que ce soit.
2. Étape 2 : introduction du champ de niveau (Lecteur/Modeleur/Administrateur) dans le modèle de droits, mapping par défaut selon les rôles existants.
3. Étape 3 : application effective de la restriction d'accès par niveau, avec possibilité de personnalisation fine si un profil a besoin d'un accès non standard (ex. un Modeleur qui a aussi besoin de consulter Sauvegardes).

7. Point de vigilance

Ne pas faire de l'étape 1 (réorganisation visuelle) un prétexte pour retarder la vraie question de fond (qui a le droit de faire quoi) : la réorganisation seule améliore la lisibilité, mais ne règle rien tant que l'étape 2 n'a pas été menée. Prioriser en fonction du besoin réel : si le risque principal aujourd'hui est qu'un CDG modifie accidentellement la Modélisation, l'étape 2 devient urgente ; si le seul objectif est de rendre le bandeau plus lisible pour un usage mono-utilisateur (toi), l'étape 1 seule peut suffire pour l'instant.