Aller au contenu

Exécution — Refonte du module Accompagnements (suivi générique + orientations)

Chantier clos. Détail technique complet. Pour le contexte, l'usage et la justification métier, voir ProjetESM/Documents/20260710_1344_refonte-module-accompagnements-suivi-orientations.

Origine

Discussion partie d'une question simple de Bernard sur ce qu'affiche la section « Prise en charge holistique » de la fiche enfant, qui a mené à examiner ce que recouvre concrètement « Accompagnement » dans ce projet. Vérification contre la transcription intégrale du cadre logique (ProjetESM/Documents/20260709_1130_transcription-sous-activites-donnees-indicateurs) : aucune des 37 sous-activités officielles ne correspond au module Accompagnement générique, et son sous-module « Orientations » prétendait alimenter l'indicateur 2.1.2 qui concerne en réalité la formation des maîtres coraniques (déjà résolu par un tout autre modèle, ActionCommunautaireMaitreCoranique, lors du chantier ProjetESM/debug/execution-sous-activites-indicateurs). Conclusion partagée avec l'utilisateur : le module n'a pas de raison d'être sous sa forme actuelle. Décision validée : retirer le générique, garder le suivi (repensé en modèle générique par cible) et les orientations (rattachées à l'Enfant).

Vérification préalable (avant toute suppression)

accompagnements, suivis_accompagnement, cas_orientes : 0 ligne en production. types_accompagnement : 11 lignes, uniquement du référentiel de seed, aucune donnée utilisateur. Confirmé par requêtes directes avant de toucher au schéma — retrait sans perte de donnée réelle.

Schéma Prisma

  • Supprimés : Accompagnement, TypeAccompagnement, SuiviAccompagnement, enum StatutAccompagnement. Relations retirées sur Utilisateur et Enfant.
  • CasOriente : accompagnementId → enfantId (relation vers Enfant au lieu d'Accompagnement).
  • Nouveau modèle Suivi + enum CibleSuivi (HOLISTIQUE / MICRO_SUBVENTION / INSTALLATION) — exactement une des 3 FK (enfantId/microSubventionId/installationCQMId) renseignée selon la cible. Pas de statutValidation (entrée de journal append-only, comme l'ancien SuiviAccompagnement).
  • MicroSubvention/InstallationCQM : relation inverse suivis Suivi[] ajoutée.
  • Appliqué en base via prisma db push --accept-data-loss (perte acceptée = les 11 lignes de seed types_accompagnement, actées ci-dessus).

Backend — fichiers touchés par module

Modules/Accompagnements (le plus gros volume) : - Supprimés (~23 fichiers) : toute la chaîne CRUD Accompagnement (entity, DTO, exceptions, interfaces/usecases/controllers/handlers Creer/Modifier/Obtenir/Lister/ChangerStatut, repository Prisma). - Réécrits sur enfantId (au lieu d'accompagnementId) : toute la chaîne CasOriente (5 usecases, 5 controllers inchangés, 5 handlers ajustés) + nouveau ICasOrienteRepository/ CasOrienteRepositoryPrisma. - Réécrits en générique (cible/cibleId au lieu d'accompagnementId) : toute la chaîne Suivi (3 usecases Creer/Lister/Supprimer, pas de Modifier — même choix que l'ancien) + nouveau ISuiviRepository/SuiviRepositoryPrisma. - 4 volets holistiques (AppuiAlimentaire, SoutienPsychologique, PriseEnChargeSanitaire, SeanceAlphabetisation) : non touchés, déjà rattachés à Enfant directement. - AccompagnementsModule.ts (DI, 995 lignes) réécrit intégralement : repositories/usecases/ controllers Accompagnement retirés, CasOriente/Suivi rebranchés sur les nouveaux repositories. - Routes : /accompagnements/:id/suivis → /accompagnements/suivis (générique, cible+cibleId en query/body) ; /accompagnements/:id/cas-orientes → /accompagnements/enfants/:enfantId/cas-orientes (même convention que les volets). - Permissions réutilisées telles quelles (ACCOMPAGNEMENT_LIRE/ACCOMPAGNEMENT_CREER/ SUIVI_CREER) — simples chaînes internes, pas de valeur ajoutée à les renommer.

Modules/Referentiels : retrait complet du CRUD TypeAccompagnement (11 fichiers) — plus aucune raison d'être une fois Accompagnement disparu.

Modules/Rapports : TableauDeBordDTO.accompagnements → casOrientes: { total } ; KPIsPeriodeDTO.accompagnementsDebutes → casOrientesCrees ; FicheEnfantDTO.accompagnements → casOrientes (champs alignés sur le nouveau modèle) ; obtenirRepartitionAccompagnement retourne désormais [] avec commentaire explicatif (pas de notion de « type » à répartir côté CasOriente, endpoint jamais consommé côté frontend).

Modules/Administration : compterDonnees() (comptage avant suppression d'un utilisateur) basculé de accompagnement/suiviAccompagnement vers casOriente/suivi.

Modules/Synchronisation : les cas ACCOMPAGNEMENT/SUIVI du type EntiteSync (offline sync mobile) passés en no-op (return null / break), même traitement que EVALUATION déjà inexistant — pas de sync offline recréée pour les nouveaux CasOriente/Suivi, hors scope de ce chantier.

shared/infrastructure/config/dependencies.ts : config DI legacy (parallèle à l'auto-discovery, toujours utilisée au démarrage réel) — getAccompagnementsModuleControllers() et getReferentielsModuleControllers() nettoyées des handlers retirés. Cause du premier échec de démarrage serveur après la première vague d'édits : ce fichier n'apparaît dans aucun grep « routes » évident, à vérifier systématiquement pour tout retrait de handler à l'avenir.

Frontend — fichiers touchés

  • Modules/accompagnements : pages AccompagnementsPage.tsx/AccompagnementDetailPage.tsx supprimées (1700 lignes), entité Accompagnement, use-cases/repository/store associés. ICasOrienteRepository/CasOrienteRepository et ISuiviRepository/SuiviRepository créés (sans cache offline Dexie pour ces deux-là, contrairement à l'ancien — mêmes limites que côté sync backend). PriseEnChargeHolistiqueSection.tsx (4 volets) : non touché.
  • Modules/enfants/pages/EnfantDetailPage.tsx : nouvelles sections SectionSuiviHolistique (cible=HOLISTIQUE) et SectionOrientations, remplacent l'ancienne SectionAccompagnements.
  • Modules/insertionSocioEconomique/.../InsertionDetailPage.tsx : composant partagé SuiviInlineWidget (repliable, cible+cibleId en prop) monté sur chaque ligne LigneSubvention/LigneInstallation.
  • app/Router.tsx + shared/components/layout/Sidebar.tsx : routes et section de menu « Accompagnements » retirées (les 4 volets et le nouveau suivi n'ont jamais eu d'entrée de menu dédiée — cohérent avec le fait qu'ils s'affichent en ligne sur la fiche enfant).

Tests

Supprimés (fonctionnalité disparue, pas de valeur à corriger) : 7 tests unitaires + 1 e2e du module Accompagnements (Creer/Modifier/Lister/ChangerStatut Accompagnement, ancien Creer/SupprimerSuivi basé sur accompagnementId), 2 tests unitaires Referentiels (Creer/ListerTypeAccompagnement).

Adaptés (fonctionnalité conservée sous nouvelle forme) : referentiels.e2e.test.ts (Scénario TypeAccompagnement retiré, Communes conservées) ; rapports.fiche-enfant.test.ts et rapports.kpis-periode.test.ts (champs renommés accompagnements→casOrientes, accompagnementsDebutes→casOrientesCrees).

Non touchés et vérifiés stables : synchronisation.*.test.ts (3 suites, 34 tests, tous passants — les tests mockent au niveau de l'interface ISynchronisationRepository, insensibles au changement d'implémentation interne).

Vérifications finales

  • Backend : npx tsc --noEmit → 0 erreur. Démarrage serveur à froid → 282 routes actives, aucune erreur (après correction de dependencies.ts, voir ci-dessus).
  • Frontend : npx tsc --noEmit → 0 erreur. npm run build → OK, bundle légèrement plus petit qu'avant (1536 Ko vs 1575 Ko — code mort effectivement retiré).
  • Jest ciblé (Referentiels, Rapports, Synchronisation) : suites directement concernées passantes après correction. Échecs résiduels ailleurs (Enfants, Administration) confirmés pré-existants et sans rapport via git status (fichiers non touchés par ce chantier).
  • 1 commit sur main (ec7447f, 149 fichiers), non poussé sur le dépôt distant.

Liens connexes