Files
_Assistant_Lead_Tech/knowledge/backend/risques/nestjs.md
MaksTinyWorkshop 9b7af9f1b0 Refonte Structure
2026-03-25 08:34:19 +01:00

3.6 KiB

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