Audit de cohérence design — Ensemble des écrans Rapport

Document de synthèse, établi à partir d'un export de 19 écrans (Connexions, Console des droits, Dimensions, Écarts, Indicateurs d'établissement, KPI, Masse salariale, Modèles de présentation, Paramètres, Rapport, Sauvegardes, Scénarios, TDB, Vue). Objectif : identifier ce qui est déjà cohérent avec les specs produites, ce qui doit être harmonisé, et corriger un cadrage erroné établi dans une spec précédente.

1. Ce qui est déjà cohérent (à ne pas retoucher)

• Bibliothèque déjà groupée : Indicateurs (KPI), Pastilles, Graphiques (bientôt) apparaissent sous une même section de navigation, conforme à docs/spec-bibliotheque-widgets-restitution.md.
• Wizard KPI à 5 étapes (Modèle → Volume réalisé → Capacité → Nom & seuils → Visuel) : correspond exactement à docs/spec-bibliotheque-kpi.md.
• Écran Écarts documente déjà la règle vert/rouge en légende ("Écart = Réel − Budget ; vert = favorable, rouge = défavorable") — cohérent avec docs/spec-refonte-ecarts.md, reste à appliquer visuellement de façon allégée (cf. maquettes déjà produites).
• Sauvegardes reprend les 4 catégories déjà auditées dans docs/spec-sauvegardes.md (Structure / Présentation-config / Données CDG / Prévision-saisie), avec la précision utile "les mouvements comptables ne sont pas inclus, les accès BDD sont préservés" — à conserver telle quelle dans la documentation utilisateur.
• Modèles de présentation : système de règles par Rang / SIG / Rôle avec priorité explicite (SIG > rôle > rang), plus riche que ce qu'on avait anticipé — aucune retouche nécessaire, juste à documenter a posteriori dans le méta-modèle si besoin.

2. Correction de cadrage — préréglages par défaut, pas des bugs

Ce point corrige une lecture erronée faite dans un échange précédent. L'écran d'édition de Vue expose un vrai panneau de style : Densité (Compact/Normal/Confortable), Bordures (Quadrillage/Lignes horizontales/Aucune), Trame zébrée, Agrégats en gras, Détail en italique. Le rendu jugé "old school" sur les captures précédentes ne vient donc pas d'un défaut de code, mais de préréglages par défaut trop appuyés sur ces options déjà existantes.

Conséquence directe pour docs/spec-refonte-ecarts.md et le travail sur les Vues : ne pas supprimer la capacité d'affichage en italique ou les styles de bordure du code — modifier uniquement les valeurs par défaut :

• Détail en italique → décoché par défaut
• Bordures → "Lignes horizontales" plutôt que "Quadrillage" par défaut
• Trame zébrée → décochée par défaut (à valider selon préférence, mais cohérent avec la sobriété visée)

3. Chevauchement de deux systèmes de couleur — à unifier

Deux mécanismes définissent la couleur d'une même notion (phase Réel/Budget/A-1), sans lien explicite entre eux :

• Paramètres → Couleurs par phase (docs/spec-parametres-mise-en-forme.md) : Réel, Budget, A-1 chacun avec une couleur globale
• Scénarios — jeux de colonnes : chaque colonne d'un scénario a son propre champ Couleur, saisi indépendamment

Risque : un changement de la couleur "Budget" dans Paramètres n'a aucun effet sur les scénarios déjà configurés, qui gardent leur couleur de colonne codée séparément — deux sources de vérité pour la même information, destinées à diverger silencieusement.

Recommandation : la couleur d'une colonne de Scénario doit se déduire automatiquement de la Couleur par phase (section 2 de docs/spec-parametres-mise-en-forme.md) quand la colonne correspond à une phase connue (Réel, Budget, A-1). Un champ de couleur manuel reste pertinent uniquement pour les colonnes qui ne correspondent à aucune phase (Écart, Cumulé...). Ce changement s'inscrit dans le même principe déjà posé pour les KPI/Pastilles : une couleur définie une fois, appliquée automatiquement partout, plutôt que redéfinie à chaque objet.

4. Nommage des rôles — tranché

Décision : les trois niveaux de droits s'appellent Administrateur / Modeleur / Lecteur dans toute l'interface. La Console des droits affichait déjà "Administrateur" (bon), mais utilisait "Utilisateur" là où le reste de la documentation (docs/spec-reorganisation-bandeau.md, docs/permissions-model.md) attend "Modeleur" — ce nom doit être corrigé partout où "Utilisateur" apparaît comme rôle. L'identifiant technique en base peut rester admin en minuscule ; seul le libellé affiché change.

5. Matrice de permissions à étendre

La Matrice de permissions actuelle (onglet "Matrice — qui voit quoi") n'a que 5 ressources en ligne : Restitution (vues), Rapports, Tableaux de bord, Saisie/Projection, Administration. À étendre avec les ressources ajoutées au modèle dans docs/permissions-model.md section 1bis : Écarts, KPI, Pivot, Modélisation — sans quoi le modèle de droits étendu (folders: { dashboards, views, saisie, ecarts, kpi, pivot, modelisation }) n'a pas d'interface pour être réellement configuré.

6. Le produit est en avance sur la spec — à rattraper dans la documentation

L'édition de TDB propose déjà des options non présentes dans docs/spec-bibliotheque-widgets-restitution.md :

• Regroupement des pastilles par Section (domaine)
• Largeur par défaut des pastilles (Automatique/Étroite/Normale/Large/Très large)
• Bascule "Afficher la section (domaine) des pastilles"

Action : mettre à jour docs/spec-bibliotheque-widgets-restitution.md pour documenter ces options déjà construites, plutôt que de laisser la spec désynchronisée de l'implémentation réelle — un désalignement dans ce sens (produit en avance) est moins risqué qu'un désalignement dans l'autre sens, mais reste une dette documentaire à corriger.

7. Bandeau — réorganisation toujours pas appliquée

Tous les écrans montrent encore la navigation à plat d'origine (Restitution / Planification / Contrôle de gestion / Modélisation / Sources / Portfolio / Console des droits / Sauvegardes / Paramètres), sans la réorganisation en 3 blocs Lecteur / Modeleur / Administrateur décrite dans docs/spec-reorganisation-bandeau.md. Cette réorganisation reste à faire — c'est le chantier le plus visible parmi les points de cet audit.

8. Priorisation suggérée

1. Corriger le nommage des rôles (section 4) — changement simple et isolé, lève une ambiguïté immédiatement gênante.
2. Ajuster les préréglages par défaut de style de Vue (section 2) — cohérent avec le travail de refonte déjà engagé, faible risque.
3. Étendre la Matrice de permissions (section 5) — prérequis pour que le modèle de droits étendu soit réellement utilisable.
4. Unifier les deux systèmes de couleur phase (section 3) — plus structurant, à traiter avec un peu plus de soin pour ne pas casser les scénarios déjà configurés par les clients existants.
5. Mettre à jour la documentation du TDB (section 6) — pas urgent, mais à ne pas oublier pour éviter que la spec continue de diverger de l'implémentation.
6. Appliquer la réorganisation du bandeau (section 7) — le chantier le plus large, à traiter une fois les points plus isolés ci-dessus stabilisés.

9. Point de vigilance

Le point 3 (unification des couleurs phase/scénario) touche des configurations déjà utilisées par des scénarios existants (ex. "Réel / Budget / Écart / A-1" déjà en usage sur Serenis). Prévoir une migration qui préserve le rendu actuel pour les scénarios déjà configurés (en pré-remplissant la couleur déduite avec la couleur actuellement codée en dur, plutôt qu'en la réinitialisant), pour ne pas changer visuellement des rapports déjà utilisés par un client sans action de sa part.