20260612 1747 Analyse croisée du Cadre Logique et Modèle schéma

Excellent. J'ai maintenant une vue complète des trois documents. Voici mon analyse structurée.

Analyse du modèle Prisma face au cadre logique¶

Vue d'ensemble¶

Le schéma est globalement bien aligné avec le projet. La majorité des domaines métiers du cadre logique y sont couverts. Mais il y a des lacunes réelles, quelques redondances, et des incohérences structurelles à corriger.

✅ Ce qui est bien couvert¶

Domaine métier	Tables concernées
Gestion des enfants (ESM)	`Enfant`, `MaitreCoranique`, `Tuteur`, `Parent`
Accompagnement & suivi individuel	`Accompagnement`, `TypeAccompagnement`, `SuiviAccompagnement`
Prise en charge holistique	`PriseEnChargeHolistique`
Parcours d'insertion professionnelle	`ParcoursInsertion`
Formations & sensibilisations	`FormationSensibilisation`, `ParticipationFormation`
Comités villageois de veille	`ComiteVillageois`, `MembreComite`, `ReunionComite`
Cadres de concertation	`CadreConcertation`, `SessionConcertation`
Étude diagnostique	`EtudeDiagnostique`
Supports de communication	`SupportCommunication`, `DistributionSupport`
Émissions radio	`EmissionRadio`
Sessions de parole/jeunes	`SessionParoleJeunes`
Sécurité & authentification	`Session`, `AuditLog`, `SecurityLog`, etc.

❌ Tables manquantes¶

1. `IndicateurSuivi` — critique¶

Le cadre logique est entièrement structuré autour d'indicateurs objectivement vérifiables (IOV) avec des valeurs de référence (SR) et des cibles (C). Il n'existe aucune table pour enregistrer les valeurs mesurées dans le temps, les comparer aux cibles, ou produire des rapports de suivi-évaluation. C'est le cœur du M&E (Monitoring & Evaluation).

model IndicateurSuivi {
  id            String   @id @default(cuid())
  code          String   @unique  // ex: "1.1.1.1"
  libelle       String
  resultatRef   String   // R1.1, R2.1, etc.
  valeurRef     String?  // SR
  valeurCible   String?  // C
  unite         String?  // %, nombre, rapport...
  mesures       MesureIndicateur[]
}

model MesureIndicateur {
  id            String   @id @default(cuid())
  indicateurId  String
  valeur        String
  dateMesure    DateTime
  sourceVerif   String?  // rapport d'activité, photos...
  periode       String?  // T1-2025, S2-2024...
  idUtilisateur String
  indicateur    IndicateurSuivi @relation(fields: [indicateurId], references: [id])
}

2. `RapportActivite` — important¶

Les sources de vérification citent systématiquement des "rapports d'activités". Aucune table ne structure ces rapports ni ne les lie aux activités, résultats et indicateurs.

3. `EducateurPair` → lien `ParticipationFormation` manquant¶

La table EducateurPair existe mais n'est pas reliée à ParticipationFormation. Le participantId de cette dernière est une simple String non typée — cela empêche de savoir si le participant est un maître coranique, un membre de comité, un éducateur pair, ou un acteur communautaire.

4. `CasOriente` — important pour l'indicateur 2.1.2¶

L'indicateur 2.1.2 mesure le "nombre de cas d'enfants mendiants orientés". Il n'y a pas de table pour tracer les orientations (vers GUPS, services sociaux, etc.) distinctement des accompagnements.

5. `MicroSubvention` / `PlanAffaires` — à externaliser¶

Ces données sont enfouies dans ParcoursInsertion sous forme de champs scalaires. Vu que les indicateurs 3.1.4.2, 3.1.4.3 et 3.1.4.4 les mesurent séparément, ils méritent des entités distinctes pour un suivi fin.

⚠️ Tables redondantes ou en surplomb¶

1. `ActionAudit` et `RessourceAudit` — inutiles en l'état¶

Ces deux tables ne sont pas reliées à AuditLog. Elles flottent sans usage. Soit il faut les relier (remplacer les champs action: String et ressource: String de AuditLog par des FK), soit les supprimer.

2. `Tuteur` vs `Parent` — redondance structurelle¶

Les deux tables ont une structure quasi-identique (nom, prénom, téléphone, commune, genre, niveau instruction, activité, participation sensibilisation). La seule différence est TypeLienTuteur vs TypeLienParent. Il vaudrait mieux une seule table PersonneProche avec un champ typeRelation (enum fusionné), et une relation vers Enfant pour lever l'ambiguïté.

De plus, Enfant a un champ tuteurId (FK non déclarée dans le schéma Prisma — bug : aucune relation @relation n'existe vers Tuteur).

3. `FormationSensibilisation.animateurId` — référence orpheline¶

Le commentaire dit "PersonneRessource qui anime" mais le champ est un String? sans @relation. Soit c'est une FK vers PersonneRessource, soit vers Utilisateur. À corriger.

🔧 Incohérences à corriger¶

Problème	Localisation	Correction
`Enfant.tuteurId` déclaré mais sans `@relation` ni table liée	`model Enfant`	Ajouter `tuteur Tuteur? @relation(...)`
`ParticipationFormation.participantId` est une `String` non typée	`model ParticipationFormation`	Créer un polymorphisme ou une union via une table `Participant`
`EtudeDiagnostique` sans `@map(...)` ni relation vers `Commune` (utilise `String[]`)	`model EtudeDiagnostique`	Remplacer `communes String[]` par une table de liaison
`SupportCommunication` sans `createdAt`, `idUtilisateur`, `@map`	plusieurs modèles de la section additionnelle	Harmoniser avec le reste du schéma
`SessionParoleJeunes` non reliée aux `Enfant` participants	`model SessionParoleJeunes`	Ajouter une table `ParticipationSession`

📋 Cas d'utilisation par domaine métier¶

Domaine 1 — Identification & enregistrement des ESM¶

Enregistrer un enfant identifié avec son dossier individuel complet
Rattacher un enfant à son maître coranique et à son tuteur/parent
Suivre le statut d'enregistrement (ACTIF, SORTI, PERDU_DE_VUE)

Domaine 2 — Prise en charge holistique¶

Créer un plan de prise en charge (alimentaire, psychologique, sanitaire, alphabétisation)
Enregistrer les séances de suivi avec observations
Mesurer le taux de couverture des 4 volets par enfant

Domaine 3 — Insertion socioprofessionnelle¶

Inscrire un enfant en formation professionnelle (courte/longue durée)
Enregistrer le plan d'affaires et la micro-subvention AGR
Suivre l'obtention du CQM et l'installation effective

Domaine 4 — Formation & sensibilisation des acteurs¶

Planifier une formation pour maîtres coraniques, leaders religieux ou acteurs communaux
Enregistrer les présences et calculer les taux de participation
Tracer l'engagement post-formation des maîtres coraniques comme acteurs communautaires

Domaine 5 — Comités villageois de veille¶

Créer ou dynamiser un comité villageois
Enregistrer les membres, leurs formations reçues et leurs rôles
Journaliser les réunions, le nombre de présents et les décisions actées

Domaine 6 — Cadres de concertation¶

Planifier les sessions trimestrielles (pilotage), semestrielles (communal) et annuelles (interdépartemental)
Enregistrer le taux de participation et les décisions appliquées

Domaine 7 — Suivi-évaluation (M&E) ← non couvert actuellement¶

Saisir les valeurs mesurées pour chaque IOV par période
Comparer automatiquement les valeurs réelles aux cibles
Générer un tableau de bord des indicateurs par résultat et par objectif spécifique

Domaine 8 — Supports de communication & médias¶

Gérer la production des boîtes à images, affiches, roll-up et banderoles
Tracer leur distribution par commune et type de destinataire
Enregistrer les émissions radio avec contrat et thème

Domaine 9 — Sécurité & administration système¶

Authentification à deux facteurs, gestion des sessions, audit des actions

Synthèse¶

Le modèle est solide pour la gestion opérationnelle (enfants, accompagnements, formations, comités). La lacune la plus critique est l'absence totale de module M&E pour saisir et suivre les indicateurs — ce qui est pourtant le mécanisme central d'un cadre logique. Les redondances Tuteur/Parent et les FK orphelines (tuteurId, animateurId) sont à corriger avant toute migration.