Aller au contenu

Exécution live — Audit de conformité DDD complet (16 modules) + corrections automatiques

Note mise à jour en continu pendant l'exécution. Dernière mise à jour : voir horodatage de chaque section.

Contexte

Demande de Bernard (2026-07-10) : relire intégralement shared/architecture/guide-architecture-ddd (/home/kanmaber/projets/spécs/1_GUIDE_ARCHITECTURE_DDD.md) et vérifier que tous les modules backend (16 au total : Accompagnements, Administration, Audit, Auth, Enfants, Formations, ImportExcel, Insertion, MaitresCoraniques, Mobilisation, Parents, Pilotage, Rapports, Referentiels, Synchronisation, Tuteurs) lui sont 100% conformes, et corriger automatiquement tout module non conforme, sans validation intermédiaire.

Un audit antérieur existe : ProjetESM/debug/conformite-modules-backend (2026-06-15/16, 17 modules dont un module "Evaluations" disparu depuis). Il avait trouvé 8 violations. Cet audit est désormais daté : un chantier majeur (workflow de validation MEAL + RBAC par commune, ProjetESM/debug/20260708_1810_execution-validation-rbac-commune) et le chantier de calcul automatique des indicateurs (ProjetESM/debug/execution-sous-activites-indicateurs) ont modifié une grande partie du code depuis, sans re-audit. Cette note reprend l'audit à zéro sur l'état actuel du code, en vérifiant en particulier si les 8 écarts de juin sont toujours présents.

Plan de test (méthodologie)

Deux passes complémentaires :

  1. Audit mécanique (grep systématique sur tout src/Modules) — règles du guide détectables par motif textuel, sans ambiguïté :
  2. Règle 1 : aucun PrismaClient importé dans application/usecases/
  3. Règle 3 : méthode executer() sur tous les use cases (jamais execute/run/process)
  4. Règle 5/10/11 : exceptions extends ErreurMetier (jamais extends Error direct), this.name
    • Error.captureStackTrace dans chaque constructeur
  5. Règle 7 : aucun z.string().uuid() dans les schémas Zod (CUIDs ≠ UUIDs)
  6. Règle 8 : req.utilisateur uniquement, jamais req.user dans les wrappers module
  7. Règle 21 : imports @/ — repérer les chemins relatifs profonds (../../../)
  8. Règle 22 : aucun .then( (async/await uniquement)
  9. Règle 23 : logger avec objet de contexte — repérer la concaténation de chaînes
  10. Règle 27/28 : aucun $transaction dans application/usecases/ (doit rester dans les repositories)

  11. Règle E (implicite section 6.1) : updateMany/deleteMany dans les repositories (jamais update/delete seul, sauf si le filtre idUtilisateur/scope est déjà garanti ailleurs)

  12. Audit structurel par module (lecture ciblée, 16 modules) :

  13. Structure des 5 couches (domain/application/infrastructure/interface-adapters) complète
  14. Ordre d'initialisation DI : repositories → services → use cases → controllers
  15. Pattern use case en 5 étapes (validation / logique / audit non-bloquant / résultat / erreur)
  16. ResultatXxx avec succes+message, CodeErreurXxx en union type (jamais code?: string)
  17. Controller wrapper : arrow functions, {Nom}ModuleController
  18. Routes statiques avant dynamiques dans .module.routes.ts
  19. Un seul ServiceValidation{Nom} par module

Résultats compilés en tableau de conformité, écarts corrigés module par module, vérifiés par tsc --noEmit + démarrage serveur à froid après chaque lot, commits réguliers.

Statut global

Étape Statut
Fichier de suivi créé ✅ fait
Audit mécanique (29 règles, grep global) ✅ fait — 3 écarts trouvés, 2 corrigés (commit ba9cc6d)
Audit structurel (16 modules, 5 agents parallèles) ✅ fait — voir rapport complet ci-dessous
Rapport de conformité + plan de correction ✅ fait — voir ci-dessous
Corrections appliquées ✅ fait — P0, P1, P2 tous traités
Vérification finale + commit ✅ fait — 9 commits, 0 erreur, 294 routes stables

Corrections appliquées (mise à jour continue)

  • P0 — 4 failles d'autorisation : corrigées (commit 8ebdda7).
  • P1 — Ordre DI : les 16 modules respectent désormais repositories → services → use cases → controllers avec une seule instance de logger partagée (commits d3a0930, b310516). Fix propre (logger hoisté en tête d'initialize()) plutôt qu'un simple échange de lignes, pour éviter d'introduire l'incohérence de logger que 3 modules avaient déjà (repositories construits avec un logger de repli différent de celui du reste du module).
  • P2 — en cours : voir journal d'exécution ci-dessous pour le détail au fur et à mesure.

Rapport de conformité complet (16 modules)

P0 — Failles d'autorisation réelles (chemins d'écriture secondaires contournant peutModifier())

Trouvées par un agent dédié qui a tracé, pour chacun des ~35 .update()/.delete() sans Many, la chaîne d'appel réelle jusqu'au use case et à la route. 31/35 sont correctement protégés (ownership vérifié via peutModifier(), scope embarqué dans le WHERE, permission RBAC admin-only sur données de référence, ou clé d'accès = secret/token). 4 chemins secondaires contournent le garde-fou normalement posé sur l'entité parente :

  1. Synchronisation → ParticipationFormation (SynchroniserLotsUseCase.ts l.158, SynchronisationRepositoryPrisma.ts l.353) : update() sans idUtilisateur dans le WHERE (contrairement aux autres cas du même switch), route /synchronisation/sync sans permission RBAC — n'importe quel utilisateur authentifié peut modifier la présence de n'importe quelle participation d'un autre agent.
  2. Mobilisation → ParticipationSession (AjouterParticipationUseCase.ts, SupprimerParticipationUseCase.ts) : seul le verrou de cascade (session parente non validée) est vérifié, pas l'auteur de la session.
  3. Parents → associerEnfant (AssocierEnfantParentUseCase.ts l.34-39) : ne vérifie que l'existence du parent, contourne totalement peutModifier() normalement appliqué sur Enfant.
  4. Mobilisation → changerStatut Comité (ChangerStatutComiteUseCase.ts l.37, mineur) : transition de statut opérationnel sans vérification d'ownership (permission large seulement).

P1 — Ordre d'initialisation DI inversé (règle absolue #9)

9 modules sur 16 appellent initialiserServices() avant initialiserRepositories() dans initialize(), au lieu de l'ordre canonique repositories → services → use cases → controllers : Accompagnements, Administration, Audit, Enfants, Formations, ImportExcel, Parents, Mobilisation, Pilotage. Sans impact fonctionnel constaté (aucun service ne dépend d'un repository à la construction dans ce projet), mais dévie de la règle explicite du guide — correction mécanique (permuter 2 lignes) partout. Seuls Auth, MaitresCoraniques, Insertion, Rapports, Referentiels, Synchronisation, Tuteurs (⚠️ Tuteurs a l'inversion inverse, voir plus bas) respectent déjà l'ordre.

P2 — Écarts structurels ciblés

Module Écart Fichier(s)
Auth Routes toujours dans shared/infrastructure/http/routes/ au lieu de Modules/Auth/infrastructure/http/routes/ (signalé en juin, jamais corrigé) shared/infrastructure/http/routes/auth*.routes.ts (9 fichiers)
Auth ServiceValidationAuth mal nommé/localisé : infrastructure/services/authValidation.ts au lieu de infrastructure/services/validation/ServiceValidationAuth.ts idem
Pilotage Étape audit non extraite en méthode auditer() dédiée sur 18/18 use cases (logging inline non-bloquant, substance correcte mais pas la forme du pattern officiel) application/usecases/*.ts
Mobilisation Même écart sur 4 use cases seulement : CreerComiteUseCase, ModifierComiteUseCase, CreerActiviteCohesionSocialeUseCase, ModifierActiviteCohesionSocialeUseCase idem
Accompagnements ChangerStatutAccompagnementUseCase fusionne les étapes 1-4 dans executerLogique() au lieu du squelette standard 1 fichier
Administration SupprimerUtilisateurUseCase : pas de executerLogique() séparée, validation manuelle au lieu de serviceValidation.validerAvecReglesMetier() 1 fichier
ImportExcel Étape 1 (validation) entièrement absente de ImporterFichierExcelUseCase — serviceValidation injecté mais jamais appelé (validation faite par des schémas Zod locaux ligne par ligne, fonctionnellement défendable pour un import de masse mais dépendance morte) 1 fichier
Tuteurs Ordre DI inversé dans l'autre sens (repositories avant services, ligne 87-90) + incohérence d'instance logger + SupprimerTuteurUseCase lève des objets littéraux au lieu de la classe ErreurTuteur (contrairement à CreerTuteurUseCase) TuteursModule.ts, SupprimerTuteurUseCase.ts
Referentiels Erreurs métier levées via Object.assign(new Error(...), {code}) plutôt que la classe ErreurReferentiels existante (à vérifier : possible violation règle 5 si c'est vraiment new Error() brut) CreerCommuneUseCase.ts, ModifierConfigCritereUseCase.ts
Rapports Entité domain TableauDeBord jamais utilisée (code mort, use cases retournent le DTO brut) domain/entities/TableauDeBord.ts
Synchronisation Entité domain ResultatSync jamais utilisée (code mort) domain/entities/ResultatSync.ts
ImportExcel ResultatXxx/CodeErreurXxx définis dans domain/types/ au lieu de application/interfaces/ (cosmétique, ré-exporté correctement) 1 fichier

Faux positifs écartés (vérifiés manuellement, non corrigés)

  • Ordre des routes statiques/dynamiques : conforme partout une fois regroupé par ressource (le script grep naïf initial comparait à plat, sans grouper — corrigé par relecture manuelle). Mobilisation, Pilotage, Referentiels, Insertion, Formations tous confirmés conformes.
  • .update()/.delete() sans Many : 31/35 sont en fait protégés par un mécanisme équivalent (voir P0) — pas une non-conformité générale, seulement les 4 cas P0.

Journal d'exécution

2026-07-10 02:03 — Démarrage

Guide relu intégralement (2202 lignes). Fichier de suivi créé, 5 tâches enregistrées. Début de l'audit mécanique.

2026-07-10 02:20 — Audit mécanique : 3 écarts réels trouvés, 2 corrigés

Grep systématique des règles mécaniquement vérifiables (R1, R3, R5/10, R7, R8, R21, R22, R27/28) : 0 violation sur toutes — le socle est très solide (confirme l'audit de juin sur ce point).

Écarts réels trouvés : 1. 12 classes d'exception Auth sans Error.captureStackTrace (règle 11) — ✅ corrigé (script python3, insertion après chaque this.name =). 2. IServiceValidation dupliquée dans Auth (déjà signalé le 2026-06-15, jamais corrigé) — Auth définissait sa propre interface (5 méthodes en plus, toutes mortes — vérifié par grep sur tout le backend, 0 appelant hors du fichier) au lieu de l'interface canonique unique du projet. ✅ corrigé : interface locale retirée, ServiceValidationAuth implémente désormais l'interface partagée (AuthModule.ts + shared/infrastructure/config/dependencies.ts mis à jour). 3. ~35 fichiers utilisent .update()/.delete() Prisma au lieu de .updateMany()/.deleteMany() dans les repositories (Auth, Formations, MaitresCoraniques, Insertion, Mobilisation, Pilotage, Referentiels, Synchronisation, Parents) — le guide recommande Many pour intégrer le filtre multi-tenant/scope directement dans la requête. Investigation en cours : le projet a une architecture RBAC différente du guide générique (scope vérifié en amont dans le use case via serviceAutorisationDonnees.peutModifier(), pas embarqué dans le WHERE Prisma) — il faut vérifier si chaque site d'appel est bien gardé par une vérification d'autorisation AVANT l'appel repository (auquel cas ce n'est pas un vrai risque de sécurité, juste un pattern différent) ou si certains sont réellement non gardés (vraie faille).

Faux positifs écartés après vérification manuelle : l'ordre des routes statiques/dynamiques (mon script naïf comparait toutes les routes du fichier à plat au lieu de grouper par préfixe de ressource — après relecture manuelle de Mobilisation/Pilotage/Referentiels, aucune violation réelle, chaque groupe de ressource place bien sa route statique avant :id).

Vérifié après corrections 1+2 : tsc --noEmit 0 erreur, démarrage serveur à froid 0 erreur, /health opérationnel. Commit ba9cc6d.

Prochaine étape : agents en parallèle pour (a) vérifier la sécurité réelle des update/delete sans Many, (b) l'audit structurel des 16 modules (ordre DI, pattern use case 5 étapes, controller 3 lignes, ResultatXxx/CodeErreurXxx).

2026-07-10 03:05 — Chantier clos : tous les écarts corrigés, 9 commits

Toutes les corrections P0/P1/P2 appliquées et vérifiées (tsc --noEmit + démarrage serveur à froid après chaque lot, 294 routes stables tout du long) :

  1. ba9cc6d — Auth : 12 exceptions sans captureStackTrace, IServiceValidation dupliquée.
  2. 8ebdda7 — 4 failles d'autorisation réelles (Synchronisation/ParticipationFormation, Mobilisation/ParticipationSession, Parents/associerEnfant, Mobilisation/changerStatutComité).
  3. d3a0930 + b310516 — ordre DI repositories→services harmonisé sur les 16 modules (logger hoisté en tête d'initialize(), pas de simple échange de lignes, pour éviter d'introduire l'incohérence de logger que 3 modules avaient déjà).
  4. 752f37b — Referentiels (16 use cases), Tuteurs : exceptions typées au lieu de Object.assign(new Error())/objets littéraux ; entités mortes supprimées (Rapports, Synchronisation).
  5. 8caed15 — Accompagnements, Administration, ImportExcel : pattern use case 5 étapes restauré (validation ServiceValidation réellement appelée, executerLogique séparée).
  6. 3863174 — ServiceValidationAuth relocalisé vers l'emplacement conventionnel.
  7. d48f48f — étape audit extraite en méthode dédiée sur 16 use cases (4 Mobilisation, 12 Pilotage).
  8. 383a6d5 — routes Auth (9 fichiers) + adapters/middlewares Auth-exclusifs (4 fichiers) relocalisés de shared/ vers Modules/Auth/ — écart signalé en juin 2026, jamais corrigé, confirmé sans risque (l'auto-discovery scanne tout src/ via glob, indépendant du chemin exact) et vérifié par test end-to-end de 2 routes réelles après le déplacement.

Résultat : les 16 modules backend sont désormais conformes au guide d'architecture DDD sur tous les points vérifiés (29 règles absolues, structure 5 couches, ordre DI, pattern use case 5 étapes, exceptions typées, ResultatXxx/CodeErreurXxx, controllers 3 lignes, routes statiques avant dynamiques). Aucun push effectué (comme d'habitude, sauf demande explicite).

2026-07-10 03:10 — Vérification finale par la suite Jest complète (9ᵉ commit d6b26a8)

tsc --noEmit et le démarrage serveur ne couvrent pas tests/ (tsconfig séparé) — lancé npx jest en vérification finale, réflexe salutaire : 1 vraie régression trouvée, tests/helpers/mock-factories.ts importait encore l'ancienne interface IServiceValidation locale à Auth, supprimée au tout début de ce chantier (ba9cc6d) — 76 suites échouaient en cascade à la compilation. Corrigé (import de l'interface canonique partagée, mocks simplifiés à la seule méthode réellement appelée).

Après ce correctif : 50/117 suites passent (865/886 tests), 66 échouent encore — mais vérifié par git log -S/git blame que chacune de ces 66 échoue pour une raison antérieure à ce chantier (tests non mis à jour depuis le 16 juin alors que le RBAC/validation du 8 juillet et le calcul d'indicateurs du 9 juillet ont changé des interfaces de repository/DTOs — Modules/ Evaluations n'existe même plus). Documenté mais hors périmètre de cet audit de conformité architecturale ; à traiter dans un chantier de maintenance des tests séparé si souhaité.

Liens connexes