Aller au contenu

Fusion du schéma Prisma auth dans jobPipeline

Date : 2026-07-03

Ce qui a été fait

jobPipeline/BackEnd/prisma/schema.prisma a été mis à jour avec les modèles du fragment auth-backend/prisma/auth.prisma.fragment : - 13 nouveaux modèles : ProfilUtilisateur, Permission, ProfilPermission, Session, TokenReset, TentativeConnexion, CodeVerification, BackupCode, AuditLog, ActionAudit, RessourceAudit, IPBlacklist, SecurityLog. - 6 nouveaux enums : MethodeDeuxFacteurs, TypeCode, TypeBlocage, NiveauSeverite, TypeLogSecurite, NiveauLog. - Le modèle Utilisateur existant a été étendu (pas dupliqué/renommé — fusionné) avec les champs et relations du module Auth.

Décisions prises sur la fusion (collision de modèle)

Utilisateur existait déjà dans jobPipeline avec un shape différent. Choix fait plutôt que de dupliquer sous un autre nom :

Champ jobPipeline (avant) Devenu
nom String? / prenom String? nom String / prenom String (obligatoires — requis par le flux d'inscription du module Auth)
refreshToken String? Retiré — remplacé par le modèle Session (multi-session, plus complet qu'un seul token scalaire)
tentativesConnexion Int Retiré — remplacé par loginAttempts Int (même rôle, nom du module Auth) + le modèle TentativeConnexion (audit détaillé par tentative)
derniereConnexionAt DateTime? Retiré — remplacé par lastLogin DateTime? (même rôle, nom du module Auth)
telephone, titre Conservés tels quels (spécifiques à jobPipeline, absents du module Auth)
Relations métier (subscription, resumes, scores, etc.) Conservées telles quelles

Ces trois champs retirés ne sont utilisés nulle part dans jobPipeline/BackEnd/src/ (vérifié par recherche) — aucun code cassé.

Vérifications faites (aucune écriture en base)

  • npx prisma validate : schéma syntaxiquement valide.
  • npx prisma generate : client généré sans erreur, tous les nouveaux modèles bien présents (typeof prisma.session === 'object', etc. — vérifié pour les 13 modèles).
  • npm run typecheck (jobPipeline/BackEnd) : toujours vert, aucune régression sur le code existant.
  • scripts/smoke-test-auth-package.mjs : AuthModule s'initialise toujours correctement (34 use cases, 36 controllers).

Mise à jour (2026-07-03, 14h15) — db push exécuté

Vérifié avant exécution : Utilisateur (0 lignes), Application (0), JobOffer (0), MatchingScore (0) — base entièrement vide, aucun risque de perte de données réelle.

npx prisma db push --accept-data-loss exécuté avec succès. Le flag était nécessaire à cause d'un avertissement sans rapport avec la fusion auth : un décalage préexistant entre schema.prisma et la base sur les enums StatutApplication (valeurs A_ANALYSER/VALIDEE obsolètes) et StatutOffre (SCOREE/TRAITEE obsolètes), plus une contrainte unique ajoutée sur matching_scores. Confirmé sans impact (tables vides).

Les 13 tables du module Auth existent maintenant réellement dans jobpipeline_db (PostgreSQL, localhost:5432) et sont interrogeables sans erreur (session, codeVerification, backupCode, tokenReset, tentativeConnexion, auditLog, profilUtilisateur, permission, etc., toutes à 0 ligne).

Reste à faire avant un usage réel

  1. Seed ProfilUtilisateur : Utilisateur.profilId est obligatoire — aucune ligne ProfilUtilisateur n'existe encore. Il faudra en créer au moins une avant de pouvoir créer un premier Utilisateur via le module Auth (ex. via InscrireUtilisateurUseCase).
  2. Câbler réellement AuthModule dans jobPipeline/BackEnd/src/server.ts (actuellement non fait — le smoke test instancie le module isolément, il n'est pas branché dans l'app).
  3. Aligner @hookform/resolvers et lucide-react côté frontend (voir 20260703_1346_test-integration-tarball-auth-packages.md).