Aller au contenu

Matrice des permissions — Plateforme ESM (état au 2026-07-11)

Périmètre : toute l'application (backend + frontend). Source de vérité : BackEnd/prisma/seeds/seed.ts — vérifiée exécutable de bout en bout et réappliquée en base le jour même (voir note méthodologique en fin de document). Frontend : aligné sur cette matrice depuis le chantier A du 2026-07-11 — les gates UI (routes, menu, boutons) reflètent désormais la permission réellement vérifiée par la route backend correspondante, plus de rôles codés en dur. Document précédent (20260623_1808_matrice-permissions-profils.md, 32 permissions) : obsolète, remplacé par celui-ci — daté d'avant plusieurs corrections RBAC majeures (2026-06-24, 2026-07-08, 2026-07-11 matin et après-midi).

Légende : ✅ accordée · ❌ non accordée

Mise à jour 2026-07-11 (~13:50) : CONCERTATION_GERER ajoutée à PSYCHOLOGUE/ASSISTANT_SOCIAL (cf. note historique conservée plus bas) — Bernard tranché : oubli confirmé, corrigé comme INSERTION_MODIFIER. Tableau et détail par profil mis à jour en conséquence (24/39 désormais).

Vue d'ensemble — 39 permissions × 8 profils

Permission PSYCHO AS MEAL-C MEAL-N CHARGE BAILLEUR ADMIN SUPER
— ENFANTS —
ENFANT_LIRE ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
ENFANT_CREER ✅ ✅ ❌ ❌ ❌ ❌ ✅ ✅
ENFANT_MODIFIER ✅ ✅ ❌ ❌ ❌ ❌ ✅ ✅
ENFANT_VALIDER ❌ ❌ ✅ ✅ ❌ ❌ ✅ ✅
— ACCOMPAGNEMENT —
ACCOMPAGNEMENT_LIRE ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
ACCOMPAGNEMENT_CREER ✅ ✅ ❌ ❌ ❌ ❌ ✅ ✅
SUIVI_CREER ✅ ✅ ❌ ❌ ❌ ❌ ✅ ✅
CAS_ORIENTE_CREER ✅ ✅ ❌ ❌ ❌ ❌ ✅ ✅
APPUI_ALIMENTAIRE_GERER ✅ ✅ ❌ ❌ ❌ ❌ ✅ ✅
SOUTIEN_PSYCHOLOGIQUE_GERER ✅ ✅ ❌ ❌ ❌ ❌ ✅ ✅
PRISE_EN_CHARGE_SANITAIRE_GERER ✅ ✅ ❌ ❌ ❌ ❌ ✅ ✅
SEANCE_ALPHABETISATION_GERER ✅ ✅ ❌ ❌ ❌ ❌ ✅ ✅
ACCOMPAGNEMENT_VALIDER ❌ ❌ ✅ ✅ ❌ ❌ ✅ ✅
— ACTEURS — (maîtres coraniques, tuteurs, parents, insertion — voir note)
ACTEUR_LIRE ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
ACTEUR_CREER ✅ ✅ ❌ ❌ ❌ ❌ ✅ ✅
ACTEUR_MODIFIER ✅ ✅ ❌ ❌ ❌ ❌ ✅ ✅
ACTEUR_VALIDER ❌ ❌ ✅ ✅ ❌ ❌ ✅ ✅
— FORMATIONS —
FORMATION_LIRE ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
FORMATION_CREER ✅ ✅ ❌ ❌ ❌ ❌ ✅ ✅
SUPPORT_GERER ✅ ✅ ❌ ❌ ❌ ❌ ✅ ✅
FORMATION_VALIDER ❌ ❌ ✅ ✅ ❌ ❌ ✅ ✅
— INSERTION —
INSERTION_LIRE ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
INSERTION_CREER ✅ ✅ ❌ ❌ ❌ ❌ ✅ ✅
INSERTION_MODIFIER ✅ ✅ ❌ ❌ ❌ ❌ ✅ ✅
INSERTION_VALIDER ❌ ❌ ✅ ✅ ❌ ❌ ✅ ✅
— MOBILISATION —
MOBILISATION_LIRE ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
COMITE_GERER ✅ ✅ ❌ ❌ ❌ ❌ ✅ ✅
CONCERTATION_GERER ✅ ✅ ❌ ❌ ❌ ❌ ✅ ✅
MOBILISATION_VALIDER ❌ ❌ ✅ ✅ ❌ ❌ ✅ ✅
— PILOTAGE —
INDICATEUR_LIRE ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
INDICATEUR_CALCULER ❌ ❌ ✅ ✅ ❌ ❌ ✅ ✅
INDICATEUR_CREER ❌ ❌ ❌ ✅ ❌ ❌ ✅ ✅
ETUDE_LIRE ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅
ETUDE_CREER ❌ ❌ ❌ ✅ ❌ ❌ ✅ ✅
ETUDE_VALIDER ❌ ❌ ✅ ✅ ❌ ❌ ✅ ✅
RAPPORT_EXPORTER ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅
— ADMIN —
UTILISATEUR_GERER ❌ ❌ ❌ ❌ ❌ ❌ ✅ ✅
REFERENTIEL_MODIFIER ❌ ❌ ❌ ❌ ❌ ❌ ✅ ✅
EQUIPE_GERER ❌ ❌ ✅ ✅ ❌ ❌ ✅ ✅
— AUDIT —
AUDIT_LIRE ❌ ❌ ❌ ❌ ❌ ❌ ✅ ✅
— SYSTEM —
ACCES_TOUTES_COMMUNES ❌ ❌ ❌ ✅ ✅ ✅ ✅ ✅
Total accordées 24 24 18 21 10 10 41 41

PSYCHO = PSYCHOLOGUE · AS = ASSISTANT_SOCIAL · MEAL-C = MEAL_COMMUNAL · MEAL-N = MEAL_NATIONAL CHARGE = CHARGE_PROJET · ADMIN = ADMIN · SUPER = SUPER_ADMIN

Historique CONCERTATION_GERER (résolu) : à la première version de ce document, ni PSYCHOLOGUE ni ASSISTANT_SOCIAL ne l'avaient dans le seed (contrairement à COMITE_GERER, qu'ils ont tous les deux) — signalé sans être corrigé, en attente d'arbitrage. Bernard a confirmé le 2026-07-11 (~13:50) qu'il s'agissait bien d'un oubli, même profil que INSERTION_MODIFIER — ajoutée à agentTerrain dans seed.ts, réappliquée en base, vérifiée par appel HTTP réel (psychologue.test : 24 permissions dont CONCERTATION_GERER). Tableau ci-dessus déjà à jour.

Détail par profil

PSYCHOLOGUE et ASSISTANT_SOCIAL — agents de terrain (24/39)

Saisie et mise en œuvre au niveau de leur commune d'affectation uniquement (communeCode sur leur compte, pas de permission ACCES_TOUTES_COMMUNES).

Enfants        : LIRE, CREER, MODIFIER
Accompagnement : LIRE, CREER, SUIVI_CREER, CAS_ORIENTE_CREER,
                 APPUI_ALIMENTAIRE_GERER, SOUTIEN_PSYCHOLOGIQUE_GERER,
                 PRISE_EN_CHARGE_SANITAIRE_GERER, SEANCE_ALPHABETISATION_GERER
Acteurs        : LIRE, CREER, MODIFIER   (maîtres coraniques, tuteurs, parents)
Formations     : LIRE, CREER
Insertion      : LIRE, CREER, MODIFIER
Mobilisation   : LIRE, COMITE_GERER, CONCERTATION_GERER
Sensibilisation: SUPPORT_GERER (éducateurs pairs, radio, affiches, traductions, distributions)
Pilotage       : INDICATEUR_LIRE

Ni l'un ni l'autre n'a de droit de validation (*_VALIDER) sur ses propres données — c'est le rôle du MEAL. Aucun accès à Pilotage/Études/Rapports au-delà de la lecture d'indicateurs.

MEAL_COMMUNAL — contrôle qualité communal (18/39)

Ne crée ni ne modifie jamais de donnée de mise en œuvre — uniquement lecture + validation/ demande de correction, sur sa commune d'affectation.

= Lecture (LIRE) sur tous les modules métier +
Validation : ENFANT_VALIDER, ACCOMPAGNEMENT_VALIDER, ACTEUR_VALIDER, FORMATION_VALIDER,
             INSERTION_VALIDER, MOBILISATION_VALIDER, ETUDE_VALIDER
Pilotage    : INDICATEUR_CALCULER, RAPPORT_EXPORTER
Admin       : EQUIPE_GERER (gestion des agents de terrain de sa commune)

MEAL_NATIONAL — contrôle qualité national (21/39)

Identique à MEAL_COMMUNAL + ACCES_TOUTES_COMMUNES + création du référentiel d'indicateurs et des études diagnostiques (spécialité MEAL national, pas une sous-activité de terrain) : ETUDE_CREER, INDICATEUR_CREER.

CHARGE_PROJET et BAILLEUR — consultation stratégique (10/39 chacun)

Permissions strictement identiques (le bailleur de fonds AFD a le même paquet lecture seule que le chargé de projet Caritas) :

Lecture (LIRE) : Enfants, Accompagnement, Acteurs, Formations, Insertion, Mobilisation,
                 Indicateurs, Études
Pilotage       : RAPPORT_EXPORTER
System         : ACCES_TOUTES_COMMUNES

C'est l'identité de ce paquet entre CHARGE_PROJET et BAILLEUR qui a permis de repérer, le 2026-07-11, que le frontend excluait BAILLEUR de Pilotage/Mobilisation/Référencements reçus alors que CHARGE_PROJET y accédait — corrigé dans le cadre du chantier d'alignement (voir journal lié).

ADMIN et SUPER_ADMIN — accès total (41/41)

Aucune permission métier retenue — accès à tout, y compris administration des utilisateurs (UTILISATEUR_GERER), modification des référentiels (REFERENTIEL_MODIFIER) et consultation des journaux d'audit (AUDIT_LIRE), strictement réservés à ces deux profils.

Isolation par commune (scope)

Profil Communes accessibles
PSYCHOLOGUE / ASSISTANT_SOCIAL Commune d'affectation uniquement
MEAL_COMMUNAL Commune d'affectation uniquement
MEAL_NATIONAL Toutes (ACCES_TOUTES_COMMUNES)
CHARGE_PROJET Toutes (ACCES_TOUTES_COMMUNES)
BAILLEUR Toutes (ACCES_TOUTES_COMMUNES)
ADMIN / SUPER_ADMIN Toutes (ACCES_TOUTES_COMMUNES)

Mécanisme (corrigé le 2026-07-11) : ServiceAutorisationDonnees.construireScopeCommune() vérifie désormais la permission ACCES_TOUTES_COMMUNES dans permissionCodes[] (chargée en base à chaque requête), et non plus une liste de rôles codée en dur limitée à 4 endroits. Appliqué de façon uniforme sur les 17 modules qui filtrent des données par commune. Avant cette date, le scope "toutes communes" ne fonctionnait réellement que sur 4 endpoints du module Pilotage — partout ailleurs, un profil national ne voyait "toutes les communes" que si son propre communeCode était null en base, par chance de données plutôt que par garantie de code.

Alignement frontend (chantier A, 2026-07-11)

Le frontend reflète désormais fidèlement cette matrice — plus de rôles codés en dur dupliqués :

  • authStore porte permissionCodes[] (reçu à la connexion, y compris via 2FA et code de secours), persistant comme le reste du profil.
  • usePermission('CODE') / possedePermission() remplacent les anciens tableaux ROLES_*.
  • ProtectedRoute, Router.tsx, Sidebar.tsx et les boutons d'action (créer/modifier/valider/ calculer) sont câblés sur la permission réellement vérifiée par la route backend correspondante — pas une permission supposée par le nom du module.
  • Écran admin /administration/permissions (édition profil ↔ permission en base) : désormais réellement utile — modifier une permission en base change immédiatement ce que l'utilisateur voit côté UI, sans redéploiement.

Détail complet du chantier : ProjetESM/debug/20260711_1130_journal-matrice-permissions-rbac.

Particularités à connaître (regroupements de permissions moins granulaires que le module)

  • ACTEUR_* couvre 4 entités distinctes : maîtres coraniques, tuteurs, parents, et le module Insertion socio-économique (jusqu'au 2026-07-11 ; Insertion a désormais ses propres permissions INSERTION_*, voir ci-dessous). Une seule permission ACTEUR_LIRE/CREER/MODIFIER gouverne encore MaîtresCoraniques/Tuteurs/Parents malgré leur nature différente.
  • SUPPORT_GERER couvre 6 sous-modules de Sensibilisation (éducateurs pairs, émissions radio, poses d'affiches, supports de communication, traductions, distributions) sans granularité — et couvre à la fois la lecture et l'écriture (pas de SUPPORT_LIRE séparée). Conséquence assumée le 2026-07-11 : seuls agentTerrain et ADMIN/SUPER_ADMIN peuvent voir cette section, MEAL et CHARGE_PROJET/BAILLEUR ne l'ont jamais pu (côté backend) même si le frontend le suggérait avant la correction.
  • Formations (session de formation) ≠ Sensibilisation : deux entités distinctes gouvernées par des permissions différentes (FORMATION_* vs SUPPORT_GERER), toutes deux affichées sous des libellés proches dans le menu.
  • CAS_ORIENTE_CREER gouverne spécifiquement la création/modification/suppression des cas orientés (recâblé le 2026-07-11 depuis ACCOMPAGNEMENT_CREER), tandis que leur lecture reste sous ACCOMPAGNEMENT_LIRE (pas de permission de lecture dédiée).

Note méthodologique — pourquoi ce document est fiable aujourd'hui, pas nécessairement demain

Cette matrice reflète l'état de seed.ts tel qu'exécuté avec succès le 2026-07-11 à 13:31, vérifié par appels HTTP réels (login + inspection de permissionCodes[] retourné). Point de vigilance découvert ce jour : seed.ts était cassé (référence à un modèle Prisma supprimé) depuis le 2026-07-10 et n'avait donc probablement pas pu s'exécuter de bout en bout depuis — la base réelle avait dérivé du fichier source (ex. psychologue.test avait RAPPORT_EXPORTER en trop). Avant de faire confiance à ce document dans le futur, si un doute existe sur la fraîcheur des données : relancer npx tsx prisma/seeds/seed.ts depuis BackEnd/ et vérifier qu'il se termine par "Seed terminé avec succès !" sans erreur — sinon la base peut avoir dérivé du fichier source sans que personne ne le sache, comme cela s'est produit ici pendant environ 24h.

Liens connexes