PD-13 — Rétrospective¶

1. Contexte¶

2. Métriques¶

3. Learnings clés¶

• Dockerfile multistage : npm ci --only=production suivi de npm run build échoue car TypeScript/Nest CLI sont en devDependencies. Le Dockerfile doit installer toutes les dépendances pour builder, puis copier uniquement les artefacts.

• Validation env obligatoire : Sans schéma Joi dans ConfigModule.forRoot(), une variable manquante ne sera détectée qu'au runtime en production.

• Module vide = dette : Un module sans service ni test (jobs) n'est pas utilisable. Mieux vaut ne pas créer le dossier que de le laisser vide.

• CloudHSM + Alpine : SDK 5 requiert GLIBC 2.32+ (Debian Bookworm), incompatible avec Alpine.

4. Patterns applicables¶

Nouveau pattern : Validation Joi obligatoire¶

Tout ConfigModule.forRoot() DOIT inclure un validationSchema Joi avec abortEarly: false.

ConfigModule.forRoot({
  validationSchema: Joi.object({
    DATABASE_URL: Joi.string().required(),
    // ...
  }),
})

Nouveau pattern : Dockerfile builder complet¶

Le Dockerfile multistage doit installer TOUTES les dépendances (y compris devDependencies) dans le stage builder, puis copier uniquement /app/dist et /app/node_modules (prod only) dans le stage final.

5. Signal CLAUDE.md¶

Priorité haute : Ajouter une règle "Validation Joi obligatoire" dans CLAUDE.md.

### Validation env obligatoire (2026-02-XX)

**OBLIGATOIRE** pour tout ConfigModule NestJS :
- Schéma Joi avec `abortEarly: false`
- Toutes les variables requises listées
- Fail-fast au démarrage si variable manquante

6. Conclusion¶

PD-13 a posé les fondations du backend NestJS mais avec 4 écarts majeurs. Les learnings sur Dockerfile et validation env sont critiques et doivent être documentés pour éviter leur répétition. L'intégration CloudHSM a révélé des contraintes d'image Docker (GLIBC) non anticipées.

Rétrospective générée 2026-02-19 (Étape 10 batch backend-core)