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

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