_Assistant_Lead_Tech/knowledge/backend/risques/nestjs.md

Backend — Risques & vigilance : NestJS

Extrait de la base de connaissance Lead_tech. Voir knowledge/backend/risques/README.md pour l'index complet.

---

NestJS 11 — TooManyRequestsException inexistante

Risques

• TooManyRequestsException n'est pas exportée par @nestjs/common en NestJS ≥ 11
• Erreur de compilation ou 500 si utilisée directement

Symptômes

• Cannot find name 'TooManyRequestsException' à la compilation
• Test qui passe sur NestJS 10 mais échoue sur 11+

Bonnes pratiques / mitigations

// Pattern sûr pour HTTP 429
throw new HttpException(
  { error: { code: 'QUOTA_EXCEEDED', message: '...' } },
  HttpStatus.TOO_MANY_REQUESTS,
);

• Contexte technique : NestJS v11+ — 20-03-2026

---

Controller NestJS corrompu par insertions multiples

Risques

• Des méthodes imbriquées, décorateurs orphelins ou routes dupliquées cassent la syntaxe TypeScript sans que le compilateur ne l'attrape toujours
• La story est marquée "completed" alors que le code ne compile pas

Symptômes

• @Get('/route') apparaît dans le corps d'une autre méthode
• La même route est déclarée 2-3 fois dans le même controller
• Erreur NestJS au runtime mais pas à la compilation

Bonnes pratiques / mitigations

• Quand on ajoute >3 endpoints à un controller existant, réécrire le fichier entier en partant du fichier original

• Ne jamais insérer par blocs séparés — la concaténation casse la structure AST

• Checklist review : grep @Get\|@Post\|@Patch\|@Delete dans le controller et vérifier qu'aucune route n'est dupliquée

• Contexte technique : NestJS / TypeScript — app-alexandrie 20-03-2026

---

Repository layer non branché (dead layer)

Risques

• Donner une impression de sécurité alors que le code métier continue d'appeler l'ORM directement
• Multiplier les chemins d'accès aux données avec des règles différentes
• Payer le coût d'une abstraction qui n'a aucun effet réel

Symptômes

• Un repository est créé mais les anciens call sites Prisma restent en place
• Les nouvelles règles de scoping ou de sécurité ne s'appliquent pas partout
• La review montre des fichiers de repository peu ou jamais importés

Bonnes pratiques / mitigations

• Vérifier qu'une nouvelle couche d'abstraction est réellement branchée dans les call sites existants
• Rechercher explicitement les appels directs restants lors de la review
• Refuser l'introduction d'une couche repository tant que la migration effective n'est pas faite
• Contexte technique : TypeScript / Prisma / refactor d'accès aux données — 16-03-2026

---

Interface provider incomplète ou divergente de ses implémentations

Risques

• Une implémentation expose des méthodes non déclarées dans le contrat commun
• Les appelants contournent l'interface et se couplent à un provider concret
• Une stratégie provider devient non interchangeable en pratique

Symptômes

• Appels avec cast ou accès direct à une implémentation spécifique
• Méthodes présentes dans une classe mais absentes de l'interface
• Régression lors d'un changement de provider

Bonnes pratiques / mitigations

• Toute capacité commune attendue par les appelants doit être déclarée dans l'interface
• Interdire les méthodes "cachées" consommées hors contrat
• Tester au moins une implémentation par le contrat abstrait
• Contexte technique : TypeScript / provider strategy — 10-03-2026

---

Guard multi-statut : ordre READ_METHODS avant statut et whitelist des writes critiques

Risques

• Un guard qui vérifie le statut BLOCKED avant la méthode HTTP bloque aussi les GET, enfermant l'utilisateur sans moyen de sortir (ex : révoquer un appareil).
• Sans whitelist explicite des writes autorisés en état bloqué, le circuit de sortie est fermé.

Symptômes

• L'utilisateur avec sessionStatus === 'BLOCKED' ne peut pas accéder à GET /auth/devices
• Tests passent mais l'ordre des conditions est inversé

Bonnes pratiques / mitigations

// ❌ DANGEREUX — BLOCKED bloque aussi les GET
if (user.sessionStatus === 'BLOCKED') throw new HttpException(...);
if (READ_METHODS.has(request.method)) return true; // jamais atteint pour BLOCKED

// ✅ CORRECT
if (READ_METHODS.has(request.method)) return true;
if (isDeviceManagementPath(request.path)) return true; // whitelist writes critiques
if (user.sessionStatus === 'BLOCKED') throw new HttpException(...);

• Règle : dans tout guard multi-statut, vérifier READ_METHODS.has(request.method) EN PREMIER, avant tout check de statut.

• Règle : définir une whitelist explicite des writes autorisés même en état bloqué.

• Contexte technique : NestJS / guard statut — app-alexandrie 30-03-2026