Aller au contenu

Synthèse de session — 2026-07-11 (~11:29 → 13:45)

Contexte

Bernard demande une matrice des permissions couvrant toute l'application, avec une méthode imposée explicitement : analyser d'abord le mécanisme RBAC réel du backend (source de vérité), comparer avec le frontend, discuter tout écart avant toute correction — pas de correction silencieuse. Il demande aussi, en cours de session, une généralisation de la règle "journal wiki tenu en direct" (jusque-là limitée aux tests E2E) à toute tâche non triviale — voir [[feedback_journal_wiki_temps_reel]] côté mémoire projet. Enfin, en toute fin de session, il établit une nouvelle règle durable : taper "Fin session" déclenche cette synthèse ([[feedback_fin_session_recap]]).

Contenu

1. Audit RBAC backend vs frontend

Deux agents Explore en parallèle ont cartographié : le backend (schéma Prisma Permission/ProfilPermission, middleware autoriser(), table route→permission des 16 modules) et le frontend (authStore, ProtectedRoute, Router.tsx, Sidebar.tsx, gates de boutons). Écart architectural majeur trouvé : le backend est permission-based (37 codes en base, table ProfilPermission) depuis le 2026-06-14, mais le frontend est resté role-based depuis sa construction le 2026-06-16/17 — 9 fichiers avec des tableaux ROLES_* codés en dur et dupliqués, zéro permissionCodes, zéro hook usePermission. Cause racine identifiée dans l'historique git : le frontend avait suivi architecture-fonctionnelle.md §3 (modèle simplifié) plutôt que systeme-rbac-permissions.md qui décrivait déjà le bon mécanisme.

Écarts concrets trouvés : BAILLEUR exclu à tort de Pilotage/Mobilisation/Référencements reçus malgré des permissions backend identiques à CHARGE_PROJET (bug réel) ; scope "toutes communes" fragile (ACCES_TOUTES_COMMUNES non lue par le code, seul un rôle en dur fonctionnait, sur 4 fichiers Pilotage uniquement) ; rôles fantômes frontend ; 5 permissions mortes côté backend ; module Formations absent du menu.

2. Discussion architecturale et document pédagogique

Bernard, surpris et déçu de découvrir cette divergence (tout le code étant issu de sessions Claude Code antérieures), a demandé une explication écrite RBAC vs "permission-based" avant de trancher. Document produit : ProjetESM/Documents/20260711_1210_explication-rbac-vs-permission-based (modèle NIST à 3 niveaux Utilisateur→Rôle→Permission, tableau comparatif, complété ensuite d'un paragraphe sur le NIST lui-même suite à une question de Bernard). Décision : aligner le frontend sur le design d'origine (option A), en incluant la correction du scope commune dans le même chantier plutôt que de le traiter à part.

3. Chantier A — alignement frontend permission-based

Backend : ServiceAutorisationDonnees.construireScopeCommune() vérifie désormais la permission ACCES_TOUTES_COMMUNES réelle (pas un rôle en dur), appliqué uniformément sur 17 controllers de module + 4 fichiers Pilotage. permissionCodes[] exposé au frontend sur les 3 chemins de connexion (login direct, 2FA, code de secours). Bug racine trouvé au passage : RoleInfo.permissions codé en dur à [] depuis toujours dans UtilisateurRepositoryPrisma (vestige jamais branché sur la vraie table Permission) — corrigé à la racine.

Frontend : authStore.user.permissionCodes[], hook usePermission(codes, mode) + possedePermission() (variante fonction pure pour les boucles, exportés depuis Modules/auth/index.ts). ProtectedRoute accepte requiredPermission. Router.tsx, Sidebar.tsx et 6 pages (Enfants, Formations, Mobilisation ×10 sous-composants, Pilotage, ValidationActions) recâblés sur la permission réellement vérifiée par la route backend correspondante. Effet de bord corrigé en cascade : le filtre d'onglets interne de Pilotage aurait laissé BAILLEUR sur une page vide — supprimé (redondant une fois le scope aligné). Effet de bord assumé et signalé : les agents de terrain gagnent accès à la section Pilotage (ils ont bien INDICATEUR_LIRE en base).

Déployé (deploy.sh --target backend|frontend) et vérifié par appels HTTP réels (login BAILLEUR + Bearer token) : GET /pilotage/indicateurs et /mobilisation/comites → 200.

4. Trois écarts restants traités

Après discussion, Bernard tranche les 3 points en attente (choix recommandés retenus) : 1. Rôles fantômes : déjà réglés de fait par le chantier A. 2. ENFANT_SUPPRIMER retirée du seed (aucune route DELETE, dossier désactivé jamais supprimé). 3. Câblage Insertion/CAS_ORIENTE_CREER corrigé — avec vérification d'impact faite avant modification (comme annoncé) : révèle un vrai trou du seed, INSERTION_MODIFIER absente d'agentTerrain alors qu'ils ont INSERTION_CREER — corrigée en même temps que le recâblage de 27 routes Insertion + 3 routes cas-orientés. 4. Formations ajoutée au menu latéral (Sidebar.tsx), gatée sur FORMATION_LIRE.

Découverte en marge, non prévue : en tentant d'appliquer ces changements via npx tsx prisma/seeds/seed.ts, le script plantait dès le démarrage — le modèle Prisma TypeAccompagnement référencé n'existe plus depuis le 2026-07-10 (refonte Accompagnements). Ce bloc mort bloquait tout le seed depuis cette date ; la section RBAC plus bas (dont le fix MEAL du 2026-07-11 matin) n'avait donc probablement jamais pu s'exécuter via ce fichier. Conséquence concrète repérée : le compte psychologue.test avait RAPPORT_EXPORTER en trop (dérive jamais nettoyée). Bloc obsolète retiré (fix sans ambiguïté), seed exécuté avec succès pour la première fois depuis longtemps, anomalie confirmée disparue après réapplication.

5. Document final publié

ProjetESM/Documents/20260711_1335_matrice-permissions-rbac-complete — 39 permissions × 8 profils, remplace la version du 2026-06-23 (32 permissions, marquée obsolète dans Documents/index.md). Inclut le détail par profil, le mécanisme de scope commune corrigé, la confirmation d'alignement frontend, les particularités de regroupement (ACTEUR_* partagé entre 4 entités, SUPPORT_GERER couvrant 6 sous-modules lecture+écriture) et une note méthodologique sur la fraîcheur des données (le piège du seed cassé pendant ~24h). Un écart repéré en rédigeant le document n'a pas été corrigé silencieusement : CONCERTATION_GERER manque probablement à agentTerrain (même profil de bug qu'INSERTION_MODIFIER), signalé dans le document, laissé en attente de décision de Bernard.

Décision / Conclusion

Chantier RBAC (audit + alignement frontend + 3 écarts + document final) entièrement clos côté documentation et déploiement. Le code applicatif ProjetESM (56 fichiers, 43 backend + 13 frontend, +430/−232 lignes) n'est PAS commité ni poussé — en attente explicite de l'accord de Bernard, jamais donné dans cette session. Le backend et le frontend sont néanmoins déployés en production (deploy.sh) avec ces changements non commités — état de travail présent sur le disque du VPS mais absent de l'historique git tant que le commit n'est pas fait.

À faire

  • Committer + pousser les 56 fichiers ProjetESM dès accord explicite de Bernard (ne pas le faire de son propre chef — jamais demandé dans cette session).
  • Trancher CONCERTATION_GERER manquante à agentTerrain (voir section 5 ci-dessus et la note finale de la matrice).
  • Mettre à jour [ProjetESM/architecture/systeme-rbac-permissions](<../../ProjetESM/architecture/systeme-rbac-permissions.md>) (encore daté du 2026-06-23, décrit l'ancien état 32 permissions / mécanisme frontend jamais construit) pour refléter l'état réel post-chantier A — signalé dans la matrice finale, pas fait dans cette session.

Liens connexes