Analyse du schéma Prisma – Cas d’usage métier (sans authentification)¶

Domaine fonctionnel	Entités clés (du schéma)	Cas d’usage métier découlant
Gestion des profils utilisateurs	`ProfilUtilisateur`, `Utilisateur`	• Créer / modifier un profil fonctionnel (ex : « Administrateur », « Encadrant », « Référent », etc.) • Lister les profils actifs • Assigner un profil à un utilisateur
Gestion des utilisateurs	`Utilisateur`, `Commune`	• Créer / mettre à jour les données d’un usager (nom, prénom, email, téléphone, commune, etc.) • Activer / désactiver un compte • Historiser les changements (`createdAt`, `updatedAt`)
Référentiel géographique	`Commune`	• Consulter la liste des communes, leurs codes, départements • Lier une commune à un utilisateur, un enfant, un maître, une formation, un tuteur, etc.
Gestion des maîtres coraniques	`MaitreCoranique`, `Utilisateur`	• Enregistrer un maître coranique (identité, école, localisation, statut d’enregistrement) • Associer un maître à son propriétaire (l’utilisateur qui le gère) • Suivre les effectifs (nb de talibés, filles, garçons)
Gestion des enfants	`Enfant`, `Commune`, `MaitreCoranique`, `Utilisateur`	• Créer / mettre à jour les dossiers d’enfants (identité, date de naissance, genre, situation scolaire, santé, etc.) • Avoir le statut d’enregistrement (actif, sorti, perdu de vue, décédé) • Lier chaque enfant à un maître, à un tuteur, à son utilisateur propriétaire, et à la commune de résidence
Accompagnement des enfants	`Accompagnement`, `TypeAccompagnement`, `Enfant`, `Utilisateur`, `SuiviAccompagnement`	• Démarrer un accompagnement (choix du type, dates, objectif, responsable) • Modifier/terminer un accompagnement (statut : en cours, suspendu, terminé, abandonné) • Enregistrer les suivis (visites, observations, évolution, prochaine étape)
Catalogue des types d’accompagnement	`TypeAccompagnement`	• Définir / activer les différents types d’accompagnement (code, libellé, description) • Gérer la disponibilité (actif / inactif)
Gestion des formations / sensibilisations	`FormationSensibilisation`, `Commune`, `Utilisateur`, `ParticipationFormation`, `PersonneRessource`	• Créer une formation (titre, date, lieu, cible, thèmes) • Lier la formation à une commune et à l’animateur (`PersonneRessource`) • Suivre la participation (nombre de participants, présence, rôle du participant)
Gestion des participants aux formations	`ParticipationFormation`	• Inscrire un participant (enfant, parent, tuteur, maître, etc.) à une formation • Marquer la présence / absence • Garantir l’unicité (un même participant ne peut être inscrit deux fois à la même formation)
Gestion des tuteurs	`Tuteur`, `Commune`, `MaitreCoranique`	• Créer / mettre à jour les fiches tuteurs (identité, lien juridique, niveau d’instruction, activité principale) • Associer un tuteur à un maître coranique si besoin • Suivre la participation aux sensibilisations
Gestion des parents	`Parent`, `Commune`	• Enregistrer les informations des parents (identité, lien avec l’enfant, contact, niveau d’instruction) • Les associer aux enfants via les liens de parenté (type de lien)
Gestion des personnes ressources (animateurs / formateurs)	`PersonneRessource`	• Cataloguer les intervenants externes ou internes (type : intervenant, animateur, formateur) • Associer un intervenant aux formations qu’il anime
Suivi de sessions applicatives (sans auth)	`Session`	• Créer une session lorsqu’un utilisateur se connecte (token, CSRF, IP, user‑agent) • Gérer la durée de vie (expiration) et le nombre de tentatives d’échec • Marquer la session comme active / inactive
Gestion des réinitialisations de mot de passe	`TokenReset`	• Générer un token de réinitialisation lié à un utilisateur • Vérifier la validité (expiration, utilisation) • Marquer le token comme utilisé
Audit & journalisation des actions	`AuditLog`, `ActionAudit`, `RessourceAudit`	• Enregistrer chaque action métier (création, mise à jour, suppression) avec détails JSON, IP, user‑agent, date • Classifier les actions (slug, description, actif) • Lier les logs à une ressource (ex : “enfant”, “formation”)
Gestion de la sécurité (IP, logs, codes)	`IPBlacklist`, `SecurityLog`, `CodeVerification`, `BackupCode`	• Blocage / déblocage d’adresses IP (type de blocage, sévérité, période) • Historiser les événements de sécurité (login success/failure, changement de mot de passe, 2FA, activité suspecte) • Gérer les codes de vérification (email, reset, 2FA) avec expiration et usage • Gérer les codes de sauvegarde (backup) pour la 2FA
Gestion des tentatives de connexion (sans auth)	`TentativeConnexion`	• Enregistrer chaque tentative de connexion (email, IP, user‑agent, succès/échec, date) • Pouvoir analyser les schémas de connexion (brute‑force, compte bloqué)
Reporting & tableaux de bord (dérivé)	Tous les modèles ci‑dessus	• Produire des indicateurs :    • Nombre d’enfants par commune, par maître, par statut    • Taux de couverture des accompagnements (en cours / terminés)    • Participation aux formations (taux de présence, répartition par type de participant)    • Historique des actions critiques (audit, sécurité)    • Évolution des listes de blacklist IP    • Utilisation des codes de réinitialisation et de backup.

Synthèse des principaux cas d’usage métier¶

Administration des référentiels
Gestion des profils, communes, types d’accompagnement, personnes ressources et maîtres coraniques.
Permet d’avoir un catalogue centralisé et évolutif.
Gestion du périmètre des bénéficiaires
Enregistrement complet d’enfants, parents et tuteurs avec leurs relations familiales et géographiques.
Accompagnement éducatif et social
Création, suivi et clôture d’accompagnements personnalisés ; suivi des évolutions via les suivis d’accompagnement.
Organisation et suivi des formations / sensibilisations
Planification des sessions, gestion des intervenants, inscription des participants et suivi de la présence.
Gestion opérationnelle des maîtres coraniques
Suivi des effectifs, des données d’enregistrement et de la localisation des écoles.
Sécurité & conformité
Enregistrement des tentatives de connexion, gestion des codes de vérification/backup, blacklist d’IP, logs de sécurité et audit fonctionnel.
Gestion de session appli (hors authentification)
Création et expiration de sessions, contrôle d’accès temporel, suivi des tentatives d’accès.
Gestion des réinitialisations de mot de passe
Génération, validation et traçabilité des tokens de reset.
Reporting & analytique
Extraction de métriques (effectifs, taux d’achèvement, incidents de sécurité, usage des codes) pour les décideurs et les responsables de suivi.

Aménagement du schéma Prisma pour les nouveaux types d’utilisateurs¶

Le besoin : définir trois familles d’utilisateurs : - Acteurs de terrain - Responsables de suivi‑évaluateur diocésain - MEAL (Monitoring‑Evaluation‑Accountability‑Learning) au niveau national

Options d’implémentation¶

Utiliser le modèle existant ProfilUtilisateur
Créer trois nouvelles entrées de profil avec des code / libelle distincts :
- ACTEUR_TERRAIN
- RESPONSABLE_DIOCESAIN
- MEAL_NATIONAL
Chaque Utilisateur possède déjà la clé étrangère profilId.
Avantages : aucune modification du schéma, simple à maintenir.
Limites : un utilisateur ne peut porter qu’un seul profil ; si on veut des rôles multiples il faut un autre mécanisme.

Définir un enum Role et ajouter le champ role dans Utilisateur

enum Role {
  ACTEUR_TERRAIN
  RESPONSABLE_DIOCESAIN
  MEAL_NATIONAL
}

model Utilisateur {
  // ... champs existants
  role Role @default(ACTEUR_TERRAIN)
}

Avantages : typage fort, lisible, simple à requêter.
Limites : toujours un seul rôle par utilisateur.

Modéliser une relation many‑to‑many UtilisateurRole

model Role {
  id   String @id @default(cuid())
  code String @unique
  libelle String
  utilisateurs UtilisateurRole[]
}

model Utilisateur {
  // ... champs existants
  roles UtilisateurRole[]
}

model UtilisateurRole {
  utilisateurId String
  roleId String
  utilisateur Utilisateur @relation(fields: [utilisateurId], references: [id])
  role Role @relation(fields: [roleId], references: [id])
  @@id([utilisateurId, roleId])
}

Avantages : un utilisateur peut porter plusieurs rôles (ex. acteur de terrain + responsable diocésain).
Limites : complexité accrue, nécessite des migrations supplémentaires.
Enrichir le modèle ProfilUtilisateur avec une hiérarchie
Ajouter un champ niveau (enum NiveauProfil : TERRAIN, DIOCESAIN, NATIONAL).

Exemple :

enum NiveauProfil {
  TERRAIN
  DIOCESAIN
  NATIONAL
}

model ProfilUtilisateur {
  // ... champs existants
  niveau NiveauProfil
}

Permet de garder la table existante tout en ajoutant la granularité.

Recommandation pragmatique¶

Pour répondre rapidement à la nouvelle exigence tout en respectant les règles du projet (pas de changement de logique métier lourd), je recommande : 1. Créer trois nouveaux profils dans ProfilUtilisateur (option 1).
2. Documenter ces profils dans la table (ajouter description explicite).
3. Si besoin futur d’un rôle multiple, migrer ensuite vers le modèle many‑to‑many (UtilisateurRole).

Exemple de migration (option 1)¶

# 1. Insérer les nouveaux profils (exemple avec prisma db push + script SQL)
npx prisma db push   # crée le schéma si besoin
# puis exécuter via psql ou prisma studio
INSERT INTO profils_utilisateur (id, code, libelle, description, actif, "createdAt", "updatedAt") VALUES
  (gen_random_uuid(), 'ACTEUR_TERRAIN',        'Acteur de terrain',        'Utilisateur intervenant directement sur le terrain', true, now(), now()),
  (gen_random_uuid(), 'RESPONSABLE_DIOCESAIN','Responsable diocésain',    'Suivi‑évaluateur au niveau diocésain',               true, now(), now()),
  (gen_random_uuid(), 'MEAL_NATIONAL',        'MEAL national',            'Responsable suivi‑évaluation au niveau national',   true, now(), now());

Impacts sur le code¶

Domain : aucune modification nécessaire ; les use‑cases qui récupèrent le profil d’un utilisateur continueront de fonctionner.
Application : lorsqu’on crée un utilisateur, on pourra choisir le profilId correspondant au rôle souhaité.
UI / API : exposer un endpoint /profils qui renvoie les profils actifs afin que le front‑end propose les trois nouveaux types.

Conclusion : En ajoutant simplement trois nouvelles entrées dans ProfilUtilisateur, on répond immédiatement au besoin de différencier les acteurs de terrain, les responsables diocésains et le suivi‑évaluateur national. Cette solution est conforme aux conventions du projet et laisse la porte ouverte à une évolution future vers un modèle de rôle plus souple si la complexité métier augmente.