# Backend — Risques & vigilance : NestJS

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

---

<a id="risque-nestjs-toomanyrequest"></a>
## 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

```typescript
// 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

---

<a id="risque-controller-corrompu-insertions"></a>
## 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

---

<a id="risque-repository-dead-layer"></a>
## 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

---

<a id="risque-interface-provider-incomplete"></a>
## 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

---

<a id="risque-guard-multistatut-read-methods"></a>
## 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

```typescript
// ❌ 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