Aller au contenu

Analyse croisée Cadre Logique ↔ Schéma Prisma & Cas d'utilisation métier

Contexte

ProjetESM est un système de suivi d'un programme de protection, d'accompagnement et de réinsertion des enfants talibés (ESM = Enfants en Situation de Mendicité) pour Caritas Bénin — avec volets sensibilisation communautaire, gouvernance locale, suivi-évaluation (MEAL) et sécurité informatique. Cette note consolide plusieurs analyses menées début projet (12 juin) pour croiser le cadre logique du projet (bailleur) avec le schéma Prisma existant, et en dériver les cas d'utilisation métier complets.

Contenu

14 modules applicatifs identifiés

  1. Administration et sécurité
  2. Référentiel géographique (communes/départements)
  3. Gestion des maîtres coraniques
  4. Gestion des enfants (bénéficiaires — cœur du système)
  5. Gestion des parents et tuteurs
  6. Accompagnement des enfants (case management psychosocial/médical/éducatif/juridique/économique)
  7. Orientation et référencement (CasOriente — GUPS, centres de santé, services sociaux)
  8. Sensibilisation et communication (formations, supports, émissions radio, éducateurs pairs)
  9. Gouvernance communautaire (comités villageois, cadres de concertation)
  10. Réinsertion socio-professionnelle (CQM, plan d'affaires, micro-subvention, installation)
  11. Participation des jeunes (groupes de parole, parlement des jeunes)
  12. Études et diagnostics
  13. Suivi-évaluation MEAL (IndicateurSuivi/MesureIndicateur)
  14. Rapports et tableaux de bord

Architecture très proche d'un système d'information de projet financé par l'UNICEF, l'OIM ou l'UE pour la protection et réinsertion d'enfants.

Lacunes du schéma Prisma identifiées (analyse croisée cadre logique)

Bloquants Prisma (empêchent la génération du client) : - Enfant.tuteurId sans @relation + champ inverse manquant dans Tuteur - Enfant sans relations inverses priseEnCharge[]/parcoursInsertion[] - Tuteur.maitreCoranId sans @relation vers MaitreCoranique - Parent totalement déconnecté de Enfant (aucun lien enfant↔parent) - animateurId dans FormationSensibilisation sans @relation vers PersonneRessource

Fonctionnels critiques : - ActionAudit/RessourceAudit orphelines (pas de FK vers AuditLog, qui utilise encore des champs String bruts) - 13 modèles de la section additionnelle sans @@map(...) (incohérence de nommage de tables) - IndicateurSuivi/MesureIndicateur incomplets (pas de timestamps, idUtilisateur, contrainte d'unicité sur (indicateurId, periode)) - Manque CasOriente pour l'indicateur 2.1.2 (distinguer orientation formelle vs suivi interne)

Domaines fonctionnels entièrement absents du schéma (croisement avec le cadre logique)

Identifiés en croisant chaque activité/indicateur du cadre logique avec le schéma existant — neuf domaines entiers manquants, avec modèles Prisma proposés pour chacun :

Domaine manquant Tables proposées Indicateurs couverts
Étude diagnostique EtudeDiagnostique 1.1.1.1, 1.1.1.2
Supports de communication SupportCommunication, DistributionSupport 1.1.2.1
Éducateurs pairs EducateurPair 1.1.2.2
Émissions radio EmissionRadio 1.1.3.2
Comités villageois ComiteVillageois, MembreComite, ReunionComite 1.2.1.1, 1.2.1.2, 1.2.1.3, 1.2.2.1, 1.2.2.3
Cadres de concertation CadreConcertation, SessionConcertation 2.2.1.1, 2.2.2.1, 2.2.2.2, 2.2.3.1
Prise en charge holistique (4 volets : alimentaire/psycho/santé/alphabétisation) PriseEnChargeHolistique 3.1.3.1
Parcours insertion (CQM, plan d'affaires, micro-subvention, installation) ParcoursInsertion 3.1.4.1 à 3.1.4.4
Sessions parole/jeunes SessionParoleJeunes 3.1.1.2, 3.1.1.3, 3.1.1.4

Le schéma initial couvrait bien le cœur opérationnel (enfants, maîtres, accompagnements, formations) mais presque rien des mécanismes de gouvernance/redevabilité ni du parcours d'insertion, pourtant au cœur des indicateurs MEAL du projet.

Incohérences cadre logique ↔ liste Excel des indicateurs

  • Numérotation dupliquée dans R3.1 (3.1.1.2 utilisé deux fois pour des activités différentes).
  • Indicateur 1.2.1.2 (membres comités formés, cible 600) mal numéroté 12.1.3 dans l'Excel — risque de traçabilité.
  • Indicateurs de niveau OS (résultat agrégé, ex. 1.1.1, 1.2.1, 1.3.1, 2.1.1, 2.1.2, 2.2.1, 2.2.2) absents de l'Excel — normal, ce sont des indicateurs calculés/agrégés, pas collectés en activité, mais à ne pas oublier au niveau du reporting bailleur.

Options envisagées pour la gestion des rôles multi-niveaux (terrain/diocésain/national)

Besoin : distinguer acteurs de terrain, responsables diocésains, et MEAL national. Quatre options analysées (du plus simple au plus flexible) : 1. Trois nouvelles entrées dans ProfilUtilisateur existant (retenu — zéro changement de schéma, cohérent avec les conventions du projet). 2. Enum Role + champ scalaire sur Utilisateur. 3. Relation many-to-many UtilisateurRole (si rôles multiples requis un jour). 4. Hiérarchie via un champ niveau sur ProfilUtilisateur.

Vérification de couverture backend (suite, même journée)

Croisement du backend Prisma existant avec les 14 domaines ci-dessus : couverture très bonne sur la majorité des modules (utilisateurs/sécurité, référentiel territorial, maîtres coraniques, enfants, accompagnements, sensibilisation, gouvernance, réinsertion, études). Trois lacunes majeures confirmées à combler en priorité haute : 1. Relation Parent ↔ Enfant manquante — aucune table de jointure ni FK. 2. Modèle Orientation/CasOriente absent — orientation vers GUPS/service social/centre de santé non traçable. 3. Module MEAL totalement absent — ni IndicateurSuivi ni MesureIndicateur n'existaient à cette date (ajoutés depuis, voir plus haut).

Plan d'action priorisé à cette date : 1) relation Parent↔Enfant (haute), 2) modèle Orientation (haute), 3) module MEAL (haute), 4) contraintes cascade/onDelete (moyenne), 5) DTO/interfaces (moyenne), 6) tests unitaires (moyenne), 7) diagramme d'architecture (faible), 8) doc API (faible).

Décision / Conclusion

Approche pragmatique retenue : ajouter les 3 profils dans ProfilUtilisateur sans changement de schéma ni de logique métier, avec possibilité de migrer vers UtilisateurRole plus tard si le besoin de rôles multiples se confirme. Les lacunes de schéma identifiées ici ont guidé les développements ultérieurs (RBAC, modules backend — voir ProjetESM/architecture/analyse-modules-rbac et ProjetESM/debug/conformite-modules-backend).

Liens connexes