Aller au contenu

Fusion du schéma Prisma auth dans jobPipeline

Contexte

Suite au test d'intégration révélant que jobPipeline et @kanmaber/auth-backend avaient chacun leur propre modèle Utilisateur incompatible (voir jobPipeline/debug/test-integration-packages-file-vs-tarball), il a fallu fusionner le fragment Prisma du package (auth-backend/prisma/auth.prisma.fragment) dans le schéma réel de jobPipeline, avant de pouvoir câbler le module pour de vrai (voir jobPipeline/architecture/procedure-cablage-auth-package).

Contenu

Ce qui a été ajouté

  • 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.

Décision sur la collision du modèle Utilisateur

Utilisateur existait déjà dans jobPipeline avec un shape différent. Choix fait : fusionner, pas 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)
tentativesConnexion Int Retiré — remplacé par loginAttempts Int + le modèle TentativeConnexion (audit détaillé)
derniereConnexionAt DateTime? Retiré — remplacé par lastLogin DateTime?
telephone, titre Conservés tels quels (spécifiques jobPipeline)
Relations métier (subscription, resumes, scores...) Conservées telles quelles

Les trois champs retirés n'étaient utilisés nulle part dans le code — vérifié par recherche, aucune régression.

Vérifications faites avant écriture en base

  • npx prisma validate : schéma syntaxiquement valide.
  • npx prisma generate : les 13 nouveaux modèles bien présents côté client.
  • npm run typecheck : vert, aucune régression.
  • Smoke test package : toujours vert.

Exécution du db push

Base vérifiée vide avant exécution (Utilisateur, Application, JobOffer, MatchingScore à 0 ligne) — 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 : décalage préexistant sur les enums StatutApplication/StatutOffre (valeurs obsolètes) et une contrainte unique ajoutée sur matching_scores — confirmé sans impact (tables vides).

Les 13 tables du module Auth existent depuis dans jobpipeline_db (PostgreSQL, localhost:5432), interrogeables sans erreur.

Décision / Conclusion

Schéma fusionné et poussé en base avec succès. Utilisateur.profilId devient obligatoire — nécessite un seed ProfilUtilisateur avant tout usage réel (traité dans l'étape 4 de jobPipeline/architecture/procedure-cablage-auth-package, avec son propre bug de résolution documenté dans jobPipeline/debug/lecons-cablage-auth-package).

Liens connexes