Aller au contenu

Audit de conformité DDD — 17 modules backend + focus module Auth

Contexte

Audit automatique du 2026-06-15 croisant les 17 modules backend avec les 29 règles absolues du guide d'architecture DDD du projet (référence shared/architecture/guide-architecture-ddd), suivi d'un focus spécifique sur le module Auth (deux passes : v1 le 2026-06-16 10h58, v2 après corrections le 2026-06-16 13h50).

Contenu

Score global (17 modules)

10/17 conformes | 6/17 partiels | 1/17 non conformes. 8 violations critiques au total, 13 warnings.

Module Statut Violations Warnings
Accompagnements, Administration, Audit, Evaluations, Formations, ImportExcel, Insertion, MaitresCoraniques, Rapports, Synchronisation, Tuteurs ✅ CONFORME 0 chacun 0-1 chacun
Auth, Enfants, Mobilisation, Parents, Pilotage, Referentiels ⚠️ PARTIEL 1-2 chacun 0-2 chacun

Points de conformité globaux (les plus importants, respectés à 17/17)

PrismaClient absent de la couche application, entités sans dépendance externe, méthode executer() (jamais execute/run/process), ResultatXxx avec succes+message, exceptions extends ErreurMetier avec this.name + captureStackTrace, aucun z.string().uuid(), aucun .then(). Architecture auto-discovery pleinement en place, BaseActionHandler respecté partout.

8 violations critiques identifiées

  1. Auth — routes mal placées : auth.module.routes.ts dans shared/infrastructure/http/routes/ au lieu de Modules/Auth/infrastructure/http/routes/ — viole l'encapsulation modulaire.
  2. Auth — IServiceValidation dupliquée entre Auth/domain/ et shared/domain/ — le guide impose une seule interface projet-wide.
  3. Enfants — Règle 14 : executerLogique() retourne le DTO brut du repository au lieu de l'entité domain, empêchant construireResultat() d'appeler versObjetPlainPublic() (3 use cases affectés : Creer, Modifier, ChangerStatut).
  4. Mobilisation — Règle 13 : étape audit (auditer()) totalement absente des 29 use cases — pattern réduit à 4 étapes au lieu de 5.
  5. Mobilisation — Règle 4 : code?: string libre au lieu d'un type union CodeErreurXxx dans tous les ResultatXxx de MobilisationDTO.ts.
  6. Parents — Règle E : .update()/.delete() sans Many dans ParentRepositoryPrisma, sans filtre idUtilisateur.
  7. Pilotage — Règle 13 : étape audit absente des 13 use cases (même pattern que Mobilisation).
  8. Referentiels — Règle E : .update()/.delete() sans Many dans 4 repositories (Commune, TypeAccompagnement, ProfilUtilisateur, PersonneRessource).

Recommandations priorisées : P1 (routes Auth + IServiceValidation + audit Mobilisation/Pilotage), P2 (Règle 14 Enfants, CodeErreur Mobilisation), P3 (updateMany/deleteMany Parents/Referentiels), P4 (nettoyage — fichier InscrireUtilisateur.ts redondant, filtrage idUtilisateur dans IndicateurSuivi.versObjetPlainPublic()).

Focus module Auth — 5 écarts critiques trouvés puis tous corrigés

Analyse v1 (2026-06-16 10h58) contre deux références (flow_connexion.md, 3_REFERENCE_GESTION_SESSIONS.md) a trouvé 5 écarts, tous corrigés par la mission 20260616_1101_corrections_ecarts_auth (commit f404d13), confirmés par l'analyse v2 (13h50) :

# Écart Avant Après
EC-1 emailVerifie absent du schéma Champ inexistant emailVerifie Boolean @default(false) + vérification active
EC-2 MAX_TENTATIVES 2FA à 3 au lieu de 5 MAX_TENTATIVES = 3 MAX_TENTATIVES = 5
EC-3 Blacklist Redis absente du refresh token Redis utilisé seulement en Pub/Sub isBlacklisted(sessionId) vérifié AVANT la requête BD, fail-closed si Redis down
EC-4 Rotation systématique du refresh token Rotation à chaque appel Rotation seulement si heuresRestantes < 24
EC-5 Champ localisation absent en session Absent du schéma localisation String? ajouté + mappé

Résultat final Auth : 100% conforme sur les points fonctionnels et sécuritaires, 0 erreur TypeScript, 706 tests Auth passants. 4 divergences mineures acceptées (format role en string+permissions[] plutôt qu'objet complet, has2FAEnabled absent du payload JWT, dateDerniereActivite absent du modèle Session, sessionId optionnel plutôt que requis) — aucune n'affecte la sécurité ou le comportement observable.

Décision / Conclusion

Socle DDD jugé "très solide" sur l'ensemble du projet malgré les 8 violations — aucune ne touche les règles les plus critiques (1, 3, 5, 7, 22), respectées à 17/17. Le module Auth, une fois les 5 écarts sécuritaires corrigés, atteint 100% de conformité aux deux documents de référence flow/sessions.

Liens connexes