chore(capitalisation): integrate triage entries and anchor new knowledge

knowledge/backend/patterns/auth.md

@@ -296,3 +296,49 @@ Le helper `requireRoleAccess` doit retourner :
 - [ ] 401 pour tout problème de token (absent, expiré, malformé)
 - [ ] 403 uniquement quand le token est valide mais le rôle insuffisant
 - [ ] Frontend redirige vers `/login` sur 401, affiche "accès refusé" sur 403
+
+---
+
+<a id="pattern-auth-dernier-admin-actif"></a>
+## Pattern : Dernier admin actif non supprimable + auto-action admin encadrée
+
+- Objectif : préserver l'accès administratif global et éviter les auto-actions destructrices.
+- Contexte : endpoints d'administration utilisateurs/rôles.
+- Quand l'utiliser : toute action de suppression, désactivation, rétrogradation d'un compte admin.
+- Quand l'éviter : jamais.
+
+### Règle
+- Interdire toute action qui laisserait le système sans admin actif.
+- Encadrer les auto-actions admin (self-disable, self-demote, self-delete) avec règles explicites.
+
+### Checklist
+- Vérification atomique "reste au moins un admin actif".
+- Codes d'erreur explicites (`LAST_ADMIN_LOCKOUT`, `SELF_ACTION_FORBIDDEN` ou équivalent).
+- Test dédié pour chaque cas limite.
+
+- Validé le : 17-04-2026
+- Contexte technique : auth / RBAC admin — RL799_V2
+
+---
+
+<a id="pattern-auth-audit-best-effort-vs-regalien"></a>
+## Pattern : Distinguer audit best-effort et audit régalien
+
+- Objectif : expliciter quelles écritures d'audit sont non-bloquantes vs bloquantes.
+- Contexte : endpoints sensibles avec journalisation.
+- Quand l'utiliser : toute opération ayant une exigence de traçabilité.
+- Quand l'éviter : jamais.
+
+### Règle
+- Audit best-effort : ne bloque pas l'opération métier principale.
+- Audit régalien/traçabilité critique : fait partie de la transaction logique et bloque en cas d'échec.
+
+### Checklist
+- Classification explicite de chaque événement d'audit.
+- Politique d'échec documentée par endpoint.
+- Tests de comportement en cas de panne du canal d'audit.
+
+- Validé le : 17-04-2026
+- Contexte technique : auth / audit — RL799_V2
+
+---

knowledge/backend/risques/auth.md

@@ -330,3 +330,39 @@ it('retourne 403 si subscription inactive', async () => {
 - **Signal review** : import de `verifyToken` dans un fichier service (hors `authHelpers.ts`)
 
 - Contexte technique : auth / architecture — RL799_V2 08-04-2026
+
+---
+
+<a id="risque-auth-acl-unique-champ-sensible"></a>
+## ACL unique pour ressource globale et sous-champ sensible
+
+### Risques
+- Champs sensibles exposés à des rôles qui ne devraient accéder qu'à la vue agrégée.
+
+### Symptômes
+- Endpoint fonctionnellement "autorisé" mais fuite de notes/valeurs sensibles en clair.
+
+### Bonnes pratiques / mitigations
+- Séparer explicitement les règles d'accès : liste globale vs détails sensibles.
+- Appliquer des guards dédiés au niveau du champ ou du sous-endpoint.
+
+- Contexte technique : auth / ACL granulaire — RL799_V2 13-04-2026
+
+---
+
+<a id="risque-auth-jwt-user-introuvable"></a>
+## JWT valide mais utilisateur introuvable en base
+
+### Risques
+- Retour `403` trompeur (authz) au lieu d'un `401` (auth invalide côté sujet).
+
+### Symptômes
+- Frontend affiche "accès refusé" au lieu de forcer une ré-authentification.
+
+### Bonnes pratiques / mitigations
+- Si le sujet JWT ne résout plus un user actif : répondre `401`.
+- Déclencher invalidation de session côté client.
+
+- Contexte technique : auth / cycle de vie compte — RL799_V2 17-04-2026
+
+---

knowledge/backend/risques/general.md

@@ -748,3 +748,123 @@ try {
 - Les checks applicatifs seuls ne suffisent pas sous concurrence
 
 - Contexte technique : Prisma / contraintes — RL799_V2 08-04-2026
+
+---
+
+<a id="risque-deploiement-migrations-apres-redemarrage"></a>
+## Docker Compose — migrations exécutées après redémarrage applicatif
+
+### Risques
+- Fenêtre de non-compatibilité entre code déployé et schéma DB.
+- Crash silencieux sur colonnes/contraintes nouvellement requises.
+
+### Symptômes
+- Redéploiement "vert" puis erreurs runtime immédiates sur accès DB.
+
+### Bonnes pratiques / mitigations
+- Appliquer les migrations avant le redémarrage applicatif.
+- Séquence recommandée : `docker compose build` -> `docker compose run --rm api prisma migrate deploy` -> `docker compose up -d`.
+
+- Contexte technique : Docker Compose / déploiement — RL799_V2 08-04-2026
+
+---
+
+<a id="risque-shell-sourcing-global-env"></a>
+## Scripts shell — sourcing global de `.env`
+
+### Risques
+- `set -a; source .env` exporte tous les secrets à tous les sous-processus.
+
+### Symptômes
+- Secrets inutiles visibles dans l'environnement de commandes annexes (docker/curl/webhooks).
+
+### Bonnes pratiques / mitigations
+- Charger uniquement les variables nécessaires (`grep`/`cut` ou équivalent).
+- Réserver `source .env` aux scripts qui ont réellement besoin de tout le contexte.
+
+- Contexte technique : shell / secrets env — RL799_V2 08-04-2026
+
+---
+
+<a id="risque-compose-service-sans-healthcheck"></a>
+## Docker Compose — services auxiliaires sans `healthcheck`
+
+### Risques
+- Faux positifs de disponibilité d'un service qui démarre mais n'est pas prêt.
+
+### Symptômes
+- Service "up" mais non exploitable (port bloqué, DB locale corrompue, etc.).
+
+### Bonnes pratiques / mitigations
+- Ajouter un `healthcheck` homogène sur tous les services critiques et auxiliaires.
+- Aligner la politique de readiness/liveness sur l'ensemble du compose.
+
+- Contexte technique : Docker Compose / observabilité service — RL799_V2 08-04-2026
+
+---
+
+<a id="risque-securite-bind-fail-open-production"></a>
+## Configuration fail-open d'un bind réseau en production
+
+### Risques
+- Dashboard/service exposé publiquement si variable d'environnement manquante.
+
+### Symptômes
+- Service censé rester localement accessible exposé sur `0.0.0.0`.
+
+### Bonnes pratiques / mitigations
+- Forcer le bind sûr dans l'override de production (`127.0.0.1` ou réseau privé explicite).
+- Ne pas dépendre d'un `.env` optionnel pour une contrainte de sécurité.
+
+- Contexte technique : Docker Compose / sécurité réseau — RL799_V2 08-04-2026
+
+---
+
+<a id="risque-logs-preview-pii"></a>
+## Logging de previews payload/HTML contenant des PII
+
+### Risques
+- Fuite de données personnelles via logs applicatifs agrégés.
+
+### Symptômes
+- Logs de debug contenant noms/emails/contenu message en clair.
+
+### Bonnes pratiques / mitigations
+- Ne jamais logger le body complet d'un message métier en prod.
+- Journaliser uniquement des métadonnées minimales (id, statut, taille, hash tronqué).
+
+- Contexte technique : logs / conformité — RL799_V2 15-04-2026
+
+---
+
+<a id="risque-base64-buffer-from-sans-exception"></a>
+## Base64 invalide — `Buffer.from(..., 'base64')` ne lève pas d'exception
+
+### Risques
+- Configuration/signature invalide traitée comme erreur avaleuse (401 répétés sans cause claire).
+
+### Symptômes
+- Échec systématique de vérification HMAC sans signal de configuration corrompue.
+
+### Bonnes pratiques / mitigations
+- Valider explicitement le format/base64 attendu avant dérivation HMAC.
+- Retourner un signal d'erreur opérationnelle explicite (config invalide) côté logs internes.
+
+- Contexte technique : crypto / intégration webhook — RL799_V2 15-04-2026
+
+---
+
+<a id="risque-date-locale-sans-timezone"></a>
+## Dates localisées sans `timeZone` explicite
+
+### Risques
+- Rendu de date divergent entre dev/CI/prod selon TZ machine.
+
+### Symptômes
+- Même ISO affiché sur des jours différents selon environnement.
+
+### Bonnes pratiques / mitigations
+- Toujours passer `timeZone` dans `toLocaleDateString`/`Intl.DateTimeFormat` pour les sorties métier.
+- Définir une timezone métier unique pour les communications utilisateur.
+
+- Contexte technique : dates / formatage serveur — RL799_V2 15-04-2026

knowledge/backend/risques/prisma.md

@@ -407,3 +407,37 @@ Checklist minimale après `prisma migrate resolve --applied` :
 - **Signal review** : `catch {` ou `catch (e) {` sans vérification de `e.code` dans un repository Prisma
 
 - Contexte technique : Prisma / error handling — RL799_V2 08-04-2026
+
+---
+
+<a id="risque-prisma-filtre-lecture-ecriture-desaligne"></a>
+## Filtre de lecture appliqué mais filtre d'écriture oublié
+
+### Risques
+- Mutation (`updateMany`/`deleteMany`) affectant des lignes hors périmètre autorisé.
+
+### Symptômes
+- Le listing semble correct, mais les opérations d'écriture touchent des données invisibles pour l'utilisateur.
+
+### Bonnes pratiques / mitigations
+- Aligner strictement les prédicats lecture/écriture sur les mêmes dimensions métier (ex: grade, tenant, statut).
+- Factoriser le filtre dans un helper partagé côté service/repository.
+
+- Contexte technique : Prisma / filtres métier — RL799_V2 09-04-2026
+
+---
+
+<a id="risque-prisma-deletemany-sans-partition"></a>
+## `deleteMany` partiel sans clé de partition métier
+
+### Risques
+- Suppression transversale de données d'autres partitions (ex: grade, segment, scope logique).
+
+### Symptômes
+- Comportement correct tant que le frontend envoie un payload complet, puis corruption lors d'un refactor/concurrence.
+
+### Bonnes pratiques / mitigations
+- Inclure toutes les dimensions de partition dans les clauses `deleteMany`/`updateMany`.
+- Ajouter des tests ciblés sur payload partiel et concurrence logique.
+
+- Contexte technique : Prisma / partition logique — RL799_V2 09-04-2026