Analyse : Correspondance Backend ↔ cas d’utilisation du document « 20260612_1825_Cas Utilisation.md »

Correspondance Backend ↔ cas d’utilisation du document « 20260612_1825_Cas Utilisation.md »

Domaine du document (numéro)	Modules / tables déjà présents dans le Backend (Prisma)	Couverture fonctionnelle	Observations / lacunes
1️⃣ Gestion des utilisateurs & de la sécurité	Utilisateur, ProfilUtilisateur, Session, TokenReset, CodeVerification, BackupCode, TentativeConnexion, IPBlacklist, SecurityLog, AuditLog, ActionAudit, RessourceAudit	✅ Très complet : création, attribution de profil, MFA, réinitialisation, gestion des sessions, journalisation, listes noires, audit.	Aucun besoin immédiat.
2️⃣ Référentiel territorial	Commune	✅ Permet de créer, lire, lier des entités à une commune (enfants, maîtres, formations, etc.).	Aucun point manquant.
3️⃣ Gestion des maîtres coraniques	MaitreCoranique (lié à Utilisateur et à Commune)	✅ Enregistrement, suivi des effectifs, localisation école, statut d’enregistrement.	Aucun.
4️⃣ Gestion des enfants bénéficiaires	Enfant (lié à Commune, MaitreCoranique, Utilisateur)	✅ Identité, statut, historique, lien avec maître, tuteur (via tuteurId), suivi d’accompagnement.	Aucun.
5️⃣ Gestion des parents & tuteurs	Parent, Tuteur (sans relations explicites vers Enfant)	⚠️ Tables existent, mais il manque : • Relation Parent → Enfant (many‑to‑many ou one‑to‑many). • Relation Tuteur → Enfant déjà via tuteurId dans Enfant, mais pas de contraintes / cascade.	À compléter : ajouter une table de jointure ParentEnfant (ou un champ parentId si 1 : 1) et préciser les cardinalités.
6️⃣ Gestion des accompagnements individuels	Accompagnement, TypeAccompagnement, SuiviAccompagnement	✅ Création, statut, objectifs, suivi, responsable, type d’accompagnement.	Aucun.
7️⃣ Gestion des orientations	Aucune	❌ Le document mentionne un modèle CasOriente (orientation d’un enfant vers un service).	À créer : modèle Orientation (ou CasOriente) avec : • enfantId → Enfant • typeService (enum : GUPS, centre santé, service social, …) • dateOrientation • statutRetour • observations
8️⃣ Sensibilisation & mobilisation communautaire	FormationSensibilisation, ParticipationFormation, PersonneRessource (animateur), tables ajoutées : SupportCommunication, DistributionSupport, EducateurPair	✅ Couverture des formations, participants, animateurs, supports de communication et éducateurs pairs.	Aucun.
9️⃣ Gouvernance communautaire	Tables ajoutées : ComiteVillageois, MembreComite, ReunionComite, CadreConcertation, SessionConcertation	✅ Gestion des comités villageois, réunions, décisions, cadres de concertation (communal, départemental).	Aucun.
🔟 Réinsertion socio‑professionnelle	Table ajoutée : ParcoursInsertion	✅ Suivi du parcours d’insertion (formation, CQM, micro‑subvention, installation, statut).	Aucun.
1️⃣1️⃣ Espaces de parole & participation des jeunes	Table ajoutée : SessionParoleJeunes (type : groupe de parole / parlement des jeunes)	✅ Organisation, date, lieu, thème, nombre de participants, animateur.	Aucun.
1️⃣2️⃣ Études & diagnostics	Table ajoutée : EtudeDiagnostique	✅ Saisie d’études, période, statut, communes couvertes, rapport, observations.	Aucun.
1️⃣3️⃣ Suivi‑Évaluation (MEAL)	Aucun (pas de tables IndicateurSuivi, MesureIndicateur, PreuveVerification, etc.)	❌ Le coeur du module MEAL n’est pas présent.	À ajouter : ```prisma
model IndicateurSuivi {
id String @id @default(cuid())
code String @unique
libelle String
description String?
cible Float?
type String // ex : résultat, effet, impact
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
mesures MesureIndicateur[]
}

model MesureIndicateur { id String @id @default(cuid()) indicateurId String valeur Float dateMesure DateTime @default(now()) preuve Json? // lien / fichier utilisateurId String indicateur IndicateurSuivi @relation(fields: [indicateurId], references: [id]) utilisateur Utilisateur @relation(fields: [utilisateurId], references: [id]) } ```
Ces tables permettront : création d’indicateurs, saisie de mesures, stockage de preuves, agrégation pour tableaux de bord. | | 1️⃣4️⃣ Rapports & tableaux de bord | Implicitement couvert par les modèles existants (requêtes agrégées). | ✅ Pas de table dédiée, mais les données sont disponibles. | Aucun, mais les nouveaux modèles MEAL faciliteront les rapports. |

Synthèse des écarts majeurs

Type d’écart	Action recommandée
Relations manquantes (Parent ↔ Enfant)	Créer une table de jointure ParentEnfant ou ajouter un parentId dans Enfant (selon cardinalité).
Absence de modèle Orientation	Ajouter le modèle Orientation (voir description ci‑dessus).
Module MEAL totalement absent	Implémenter les tables IndicateurSuivi et MesureIndicateur (et éventuellement PreuveVerification).
Vérification de cohérence	• S’assurer que les nouvelles tables (EtudeDiagnostique, SupportCommunication, etc.) possèdent les champs de traçabilité (createdAt, updatedAt, idUtilisateur). • Ajouter les index nécessaires pour les requêtes fréquentes (ex. @@index([enfantId]) sur Orientation).
Mise à jour du diagramme d’architecture	Le diagramme 5‑couches du projet (domain → application → infrastructure → interface‑adapters → index) doit intégrer les nouveaux modèles :   • EtudeDiagnostique → Infrastructure → repositories/prisma/EtudeDiagnostiqueRepositoryPrisma   • SupportCommunication, DistributionSupport → même couche   • EducateurPair, ComiteVillageois, …   • IndicateurSuivi / MesureIndicateur en domain + application (use‑cases de création, saisie, agrégation).
Tests unitaires / d’intégration	Ajouter des jeux de tests pour chaque nouveau use‑case (ex. CréerOrientationUseCase, SaisirMesureIndicateurUseCase).

Proposition de tâches de mise à jour (plan d’action)

Étape	Description	Priorité
1️⃣	Ajouter la relation Parent ↔ Enfant (table ParentEnfant).	Haute
2️⃣	Créer le modèle Orientation (prisma + repository + use‑case).	Haute
3️⃣	Implémenter le module MEAL (IndicateurSuivi / MesureIndicateur).	Haute
4️⃣	Vérifier les contraintes de cascade / onDelete sur les nouvelles relations (ex. supprimer un enfant doit nettoyer ses orientations, mesures, etc.).	Moyenne
5️⃣	Mettre à jour les DTO / interfaces (DonneesOrientation, ResultatOrientation, etc.) conformément au pattern “5 étapes” du projet.	Moyenne
6️⃣	Ajouter tests unitaires pour chaque nouveau use‑case (création, mise à jour, lecture, agrégation).	Moyenne
7️⃣	Réviser le diagramme d’architecture pour inclure les nouvelles entités et leurs dépéndances.	Faible
8️⃣	Documenter les API REST/GraphQL (ou routes HTTP) correspondantes (ex. /orientations, /indicateurs, /mesures).	Faible

---

Conclusion

Le Backend couvre déjà la plupart des domaines métier décrits dans le fichier Cas Utilisation : gestion des utilisateurs, référentiel territorial, maîtres, enfants, accompagnements, sensibilisation, gouvernance, réinsertion, espaces de parole et études.

Les lacunes majeures concernent : - Relations parent‑enfant (manquantes), - Le suivi des orientations (modèle absent), - Le module complet de suivi‑évaluation (MEAL) (indicateurs et mesures inexistants).

En ajoutant les trois ensembles de tables évoqués ci‑dessus, le schéma Prisma sera entièrement aligné avec les besoins métier exprimés dans le document. Les prochains pas consistent à mettre à jour les repositories, les use‑cases et les tests, puis à documenter les nouvelles API.