feat(corrections): Sprint 3.6a — nouveaux prompts + taxonomie erreurs + génération parallèle

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/TECH_DEBT.md

@@ -98,6 +98,20 @@
 
 ---
 
+### TD-15 — Jobs asynchrones modèle/exercices : status peut rester "pending" indéfiniment
+**Priorité :** 🟡 Important
+**Statut :** Ouvert — introduit au Sprint 3.6a
+**Description :** Le flux POST /corrections/ee lance deux jobs DeepSeek en fire-and-forget (`runModeleJob`, `runExercicesJob` dans `correctionController.ts`). Si le process Node redémarre (deploy Render, crash, OOM) pendant l'exécution d'un de ces jobs, la colonne `exercices_status` ou `modele_status` reste figée à `'pending'` — l'utilisateur voit un loader infini côté frontend.
+**Impact actuel :** faible en conditions normales (DeepSeek répond en ~5-15 s, Render redémarre rarement). Perceptible uniquement si un deploy a lieu pendant une correction active.
+**À faire :**
+- Option 1 (simple) : job de reprise au boot → scanner `productions WHERE (exercices_status='pending' OR modele_status='pending') AND created_at < NOW() - INTERVAL '2 minutes'` → relancer.
+- Option 2 (robuste) : file d'attente persistée (pg-boss, BullMQ) au lieu de fire-and-forget.
+- Option 3 (minimal) : timeout côté frontend → si `pending` depuis > 2 min, afficher "La génération a échoué, réessayer ?" + endpoint `POST /simulations/:id/retry-jobs`.
+**Session concernée :** à planifier après livraison Sprint 3.6a/3.6b en prod stable.
+**Condition de résolution :** après 7 jours d'observation en prod avec monitoring des colonnes `*_status='pending'` âgées.
+
+---
+
 ### TD-14 — Erreurs TypeScript TS2835 pré-existantes
 **Priorité :** 🟡 Important
 **Statut :** Résolu — session correction build TypeScript