docs: capitaliser les patterns valides du 16 mars

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 : 10-03-2026
+Dernière mise à jour : 16-03-2026
 
 ---
 
@@ -44,6 +44,8 @@ Dernière mise à jour : 10-03-2026
 - [Stripe `list()` sans gestion de `has_more`](#risque-stripe-list-has-more)
 - [Concurrence entre activation locale et webhook sur transition trial → payant](#risque-trial-payant-concurrence)
 - [`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)
 
 ---
 
@@ -503,3 +505,51 @@ if (!user?.userId) {
 - Éviter les `clearAllMocks()` concurrents à plusieurs niveaux de nesting
 - Préférer un setup explicite et local par scénario quand les mocks Prisma sont structurants
 - Contexte technique : Jest / Prisma / tests NestJS — 10-03-2026
+
+---
+
+<a id="risque-cookie-apres-revocation-db"></a>
+## Suppression du cookie après révocation DB sur logout
+
+### Risques
+
+- Si la révocation DB échoue avant la suppression du cookie, l’utilisateur garde un cookie local devenu incohérent
+- L’utilisateur peut rester bloqué dans un état où il ne peut plus se déconnecter proprement
+- Le comportement diffère selon la disponibilité de la base
+
+### Symptômes
+
+- Logout qui échoue par intermittence quand la DB est instable
+- Cookie de session toujours présent côté navigateur après erreur serveur
+- Réessais de logout qui produisent des états difficiles à diagnostiquer
+
+### Bonnes pratiques / mitigations
+
+- Toujours supprimer le cookie en premier, même si la révocation DB échoue ensuite
+- Traiter la suppression côté DB en best-effort ou avec gestion d’idempotence adaptée
+- Vérifier en test qu’un échec DB ne laisse pas l’accès browser actif
+- Contexte technique : Next.js / auth par cookie / session persistée — 16-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