Purge _ A capitaliser

10_backend_risques_et_vigilance.md

@@ -8,7 +8,7 @@ Ce fichier recense des risques back-end susceptibles de provoquer :
 - régressions coûteuses,
 - incohérences de données.
 
-Dernière mise à jour : 16-03-2026
+Dernière mise à jour : 20-03-2026
 
 ---
 
@@ -46,6 +46,9 @@ Dernière mise à jour : 16-03-2026
 - [`jest.clearAllMocks()` dans des `beforeEach` imbriqués avec mocks Prisma](#risque-jest-clearallmocks-imbrique)
 - [Suppression du cookie après révocation DB sur logout](#risque-cookie-apres-revocation-db)
 - [Repository layer non branché (dead layer)](#risque-repository-dead-layer)
+- [NestJS 11 — `TooManyRequestsException` inexistante](#risque-nestjs-toomanyrequest)
+- [`ForbiddenException` utilisé pour des erreurs de validation](#risque-forbidden-pour-validation)
+- [PrismaService — getter explicite manquant sur nouveau modèle](#risque-prismaservice-getter-manquant)
 
 ---
 
@@ -553,3 +556,90 @@ if (!user?.userId) {
 - 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-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-forbidden-pour-validation"></a>
+## `ForbiddenException` (403) utilisé pour des erreurs de validation
+
+### Risques
+
+- Les clients qui filtrent par HTTP 400 manquent les erreurs de validation lancées en 403
+- Sémantique API incorrecte → comportements clients imprévisibles
+
+### Symptômes
+
+- `ForbiddenException` lancée pour des tags invalides, des formats incorrects, des liens HTTP
+- Clients API qui ignorent ces erreurs ou les traitent comme des refus d’accès
+
+### Bonnes pratiques / mitigations
+
+Tableau de correspondance :
+
+| Cas | Exception correcte | Code HTTP |
+|---|---|---|
+| Tags invalides, contenu trop long, format incorrect | `BadRequestException` | 400 |
+| Accès refusé explicitement (accès forum, trial read-only) | `ForbiddenException` | 403 |
+| Quota dépassé | `HttpException(429)` via `HttpStatus.TOO_MANY_REQUESTS` | 429 |
+
+- **Règle** : HTTP 403 = "tu n’as pas le droit d’effectuer cette action". HTTP 400 = "ta requête est mal formée".
+- Contexte technique : NestJS / HTTP — 20-03-2026
+
+---
+
+<a id="risque-prismaservice-getter-manquant"></a>
+## PrismaService — getter explicite manquant sur nouveau modèle
+
+### Risques
+
+- L’ajout d’un modèle dans `schema.prisma` sans son getter dans `PrismaService` casse le typecheck
+- Erreur silencieuse si les modules sont peu typés
+
+### Symptômes
+
+- `Property ‘forum’ does not exist on type ‘PrismaService’` à la compilation
+- Module fonctionnel sur le `PrismaClient` direct mais cassé via `PrismaService`
+
+### Bonnes pratiques / mitigations
+
+Tout ajout de modèle Prisma = **deux actions** :
+
+1. Ajouter le modèle dans `schema.prisma`
+2. Ajouter le getter dans `prisma.service.ts`
+
+```typescript
+// apps/api/src/infra/prisma/prisma.service.ts
+get forum() {
+  return this.client.forum;
+}
+```
+
+- **Checklist review** : à chaque nouvelle migration Prisma, vérifier que `prisma.service.ts` est mis à jour.
+- Contexte technique : NestJS / PrismaService encapsulé — app-alexandrie 20-03-2026