EME_APP/review.md

review.md — Journal des décisions EME

Ce fichier trace chaque étape réalisée et chaque choix technique, avec sa justification. Il est mis à jour au fil de l'avancement. Lecture du plus ancien (haut) au plus récent (bas).

Règles métier -> docs/regles-metier/regles-gestion.md · Contexte -> CONTEXT.md · Plan -> TODO.md

---

Conventions et choix transverses

Ces décisions s'appliquent à tout le projet, sauf mention contraire.

Décision	Pourquoi
Statuts métier en String côté Prisma (pas d'enum natif)	SQL Server ne supporte pas les enums Prisma. Les valeurs sont validées côté TypeScript via src/models/enums.ts.
Timestamps automatiques : createdAt @default(now()), updatedAt @updatedAt	Évite d'avoir à fournir ces valeurs manuellement ; updatedAt est géré par Prisma au runtime.
actif Boolean @default(true)	Une entité créée est active par défaut.
@unique sur les identifiants fonctionnels	Intégrité : un identifiant en double casse l'authentification / l'unicité métier.
Champs nullable selon les cardinalités 0..1 du diagramme de classes	Un champ non connu à la création (ex. date de retour) ou optionnel doit être NULL, sinon le workflow métier est bloqué.
onDelete: NoAction, onUpdate: NoAction sur les données de traçabilité (Emprunt, Checklist, ChecklistElement, Anomalie, Historique)	Ces données ne doivent jamais être supprimées/altérées automatiquement en cascade. Toute suppression sera explicite côté service. Évite aussi l'erreur SQL Server "multiple cascade paths".
ERD tenu à jour en miroir du schéma (docs/conceptions/uml/ERD.md)	La source de vérité doit refléter le code réel (nullable, UK, etc.).
Workflow Git : commits sur develop uniquement	master est figé ; develop reste toujours à jour de master (aucune divergence puisque master ne bouge plus).
Process avant chaque migration : prisma format -> prisma validate -> npm run build -> migration	Détecter toute erreur de schéma/typage avant de toucher la base.

Note outillage — migrations en environnement non-interactif

prisma migrate dev se bloque quand il doit demander une confirmation (ex. ajout de contrainte @unique sur table existante) car le terminal est non-interactif. Contournement utilisé : générer le SQL avec prisma migrate diff --from-config-datasource --to-schema ... --script, écrire le fichier de migration, puis appliquer avec prisma migrate deploy. Résultat strictement identique à migrate dev, sans perte de données. En terminal interactif (VS Code), migrate dev fonctionne normalement (taper y).

---

Journal chronologique

Étape 0 — Audit initial

• Constat : Block 0 (bootstrap) terminé mais non coché ; schéma à 4/16 entités ; aucune migration ; aucun commit Git.
• Décision : compléter le schéma par petits blocs (et non d'un coup) pour valider/committer au fur et à mesure.

Étape 1 — Configuration des migrations Prisma

• Correction DATABASE_URL (mot de passe désaligné avec DB_PASSWORD).
• Découverte : Prisma 7 interdit url dans schema.prisma -> la connexion vit dans prisma.config.ts. Ligne url retirée du datasource.

Étape 2 — Modèles de référence (Campus, Role, Utilisateur, CategorieMateriel)

• Defaults + timestamps auto ajoutés sur Campus, Utilisateur, CategorieMateriel (Role n'a pas de timestamps -> non modifié).
• @unique sur Role.code, Utilisateur.microsoftId, Utilisateur.email.
• Utilisateur.classe -> nullable : un RESPONSABLE n'a pas de classe (seuls les étudiants en ont).
• ERD mis à jour en miroir (UK, nullable).
• Choix laissé de côté : tailles @db.NVarChar(n) (colonnes restées en NVARCHAR(1000) par défaut). À reconsidérer plus tard.

Étape 3 — Bloc A : Infrastructure (SallePret, PosteEmprunt) — commit d026b75

• SallePret rattachée à Campus ; PosteEmprunt rattaché à SallePret. Conforme à l'ERD.

Étape 4 — Bloc B : CarteEtudiante — commit dfa73cd

• Rattachée à Utilisateur.
• Dette notée : qr_code devrait être @unique (sert à l'identification, RG02) — non posé pour rester fidèle à l'ERD.

Étape 5 — Bloc C : Matériel (Materiel, Accessoire, MaterielAccessoire) — commit 0774ee3

• Table de liaison MaterielAccessoire (sans timestamps, conforme ERD).
• Dette notée : @@unique([materielId, accessoireId]) et Materiel.statut @default("DISPONIBLE").

Étape 6 — Bloc D : Transactions (Emprunt, Checklist, ChecklistElement) — commit 6908a2b

• Champs de retour/optionnels nullable : dateRetourReelle, modeIdentificationRetour, commentaireDepart, commentaireRetour, Checklist.commentaire, ChecklistElement.commentaire.
  • Pourquoi : RG12 crée l'emprunt au départ ; les infos de retour n'existent pas encore. En NOT NULL, la création serait impossible.
• ChecklistElement.accessoireId nullable : conforme au diagramme de classes (Accessoire "0..1"), un élément peut être un libellé libre sans accessoire catalogué.
• Les 9 FK en NoAction : traçabilité + évitement des cascade paths.
• ERD mis à jour en miroir (champs annotés nullable).

Étape 7 — Stratégie Git : branche develop

• Création de develop depuis master. Désormais tous les commits vont sur develop ; master figé au Bloc C.

Étape 8 — Bloc E : Suivi (Anomalie, Notification, Historique) — commit 0fc9f9e

• Schéma 16/16 complet.
• Nullable selon 0..1 : Anomalie.traiteeParId (null tant que non pris en charge), observation, dateResolution ; Notification.anomalieId ; les 5 FK optionnelles d'Historique (un événement n'a pas toujours d'emprunt/matériel/etc.).
• Double relation Anomalie vers Utilisateur nommée : @relation("AnomalieEtudiant") (étudiant concerné) et @relation("AnomalieResponsable") (responsable qui traite).
• Defaults : Anomalie.detecteeAutomatiquement @default(true), Notification.lu @default(false), Notification.dateCreation @default(now()).
• Les 12 FK en NoAction (traçabilité).
• Notification et Historique sans updatedAt (conforme ERD).
• ERD mis à jour en miroir.

Étape 9 — Seeds de référence — commit 2c3a5db

• Fichier prisma/seed.ts autonome (adapter MSSQL, lecture directe des variables DB), lancé via npm run seed (script ajouté au package.json).
• Choix npm run seed (ts-node) plutôt que prisma db seed : l'API de configuration du seed en Prisma 7 (prisma.config.ts) n'étant pas confirmée, un script direct est plus fiable.
• Données : 2 rôles (ETUDIANT, RESPONSABLE), 1 campus (Campus Saint-Christophe, Cergy, 95800, adresse provisoire), 1 salle (Salle de prêt principale), 1 poste (POSTE-01), 6 catégories (Ordinateur portable, Vidéoprojecteur, Tablette, Caméra, Périphérique audio, Câble / Adaptateur).
• Idempotence : upsert sur Role.code ; findFirst avant create pour les entités sans clé unique. Relance vérifiée (aucun doublon).
• Incident : le client Prisma était obsolète (ne connaissait que les 4 modèles de référence). Régénéré avec npx prisma generate avant le seed. Leçon : après des migrations, régénérer/vérifier le client avant d'exécuter du code qui l'utilise.

Étape 10 — Fixtures de test

• Fichier prisma/fixtures.ts + script npm run fixtures (séparé du seed : données de dev/test, non installées en production).
• Non destructif : détection via un email témoin (marie.dupont@ensitech.eu) ; si présent, le script s'arrête (cohérent avec le principe "pas de suppression automatique").
• Contenu : 4 utilisateurs (3 étudiants + 1 responsable), 3 cartes, 6 matériels (statuts variés), 3 accessoires + liaisons, 4 emprunts couvrant EN_COURS / EN_RETARD / CLOTURE / RETOUR_NON_CONFORME, 6 checklists, 1 anomalie + 1 notification, 2 entrées d'historique.
• Idempotence vérifiée (2e exécution = skip).

Contexte métier clarifié — structure ENSUP (impacte la modélisation)

• ENSUP est un groupe multi-campus (Saint-Christophe/Cergy, Saint-Quentin, Nantes, Marseille...).
• Chaque campus héberge deux écoles : ENSUP (filières généralistes) et Ensitech (informatique). Bâtiments et salles partagés.
• La distinction d'école se fait par le domaine email : ensitech.eu (info) et ensup.eu (reste). La validation de domaine (RG, à venir) doit accepter les deux.
• Le modèle n'a pas d'entité "École" : seule Campus existe. Un campus = un lieu physique partagé par les deux écoles (et non une école).
• MVP : on démarre avec le seul campus Saint-Christophe (Cergy) ; les autres campus viendront ensuite.

---

Dette technique en attente

À traiter ensemble plus tard (avec mise à jour ERD en miroir) :

1. CarteEtudiante.qr_code -> @unique (identification, RG02)
2. MaterielAccessoire -> @@unique([materielId, accessoireId]) (un accessoire une seule fois par matériel)
3. Materiel.statut -> @default("DISPONIBLE") (un matériel neuf est disponible, RG07)
4. Tailles de colonnes @db.NVarChar(n) (actuellement NVARCHAR(1000) partout)
5. Block 1 : middleware d'erreurs global, logs, ESLint + Prettier, Swagger/OpenAPI

---

Dernière mise à jour : 2026-06-15 — Fixtures de test en place, Block 2 terminé.