capitalisation: intégration ~60 entrées RL799_V2 (triage 2026-05-02)

Triage du 95_a_capitaliser.md (~75 propositions) :
- 60 entrées intégrées dans knowledge/ (backend, frontend, workflow)
- 4 nouveaux fichiers : backend/patterns/tests.md, backend/risques/tests.md,
  frontend/patterns/general.md, workflow/patterns/general.md
- 6 doublons rejetés
- Mise à jour des READMEs index pour refléter les nouvelles entrées
- 95_a_capitaliser.md restauré à sa structure initiale
- 40_decisions_et_archi.md : décision mono-tenant déployable vs SaaS multi-tenant
- 90_debug_et_postmortem.md : sub-agents Write indisponible, effet iceberg CI,
  prisma migrate diffs cosmétiques

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

40_decisions_et_archi.md

@@ -30,6 +30,7 @@ Dernière mise à jour : 2026-03-12
 - [Le front-end est un logiciel en production](#decision-frontend-production)
 - [Single source of truth des contrats — schémas runtime partagés (Zod) + z.infer (No-DTO)](#decision-contrats-sso-zod)
 - [User views — User public par défaut + MeUser explicite](#decision-user-views)
+- [Mono-tenant déployable vs SaaS multi-tenant](#decision-mono-tenant-deployable)
 
 ### 2. Infra
 
@@ -293,6 +294,48 @@ Règles associées :
 
 ---
 
+<a id="decision-mono-tenant-deployable"></a>
+
+## Mono-tenant déployable vs SaaS multi-tenant
+
+- Date : 2026-04-27
+- Statut : Accepted
+- Périmètre : global
+
+### Contexte
+
+Pour une app vendable à plusieurs clients qui fonctionnent chacun individuellement (ex : loges, cabinets, écoles), le choix d'architecture multi-tenant a un impact majeur sur la complexité, la sécurité et le coût opérationnel. Trois architectures possibles, à trancher tôt.
+
+### Options envisagées
+
+| Approche | Description | Pour | Contre |
+| -------- | ----------- | ---- | ------ |
+| **Mono-tenant déployable** | Chaque client = son instance app + DB + uploads + domaine | Pas d'isolation cross-tenant à coder, complexité ÷10, sécurité plus simple | Coût opérationnel par déploiement, pas de cross-tenant report |
+| **SaaS multi-tenant logique** | Une app, une DB, `tenantId` partout | Coût opérationnel ÷N, cross-tenant analytics | Isolation à coder partout (RLS, scoping, tests cross-tenant), risque leak data |
+| **SaaS multi-tenant physique** | Une app, plusieurs DBs (1 par tenant) | Isolation physique, scaling fin | Routing complexe, ops par tenant, migration cross-DB |
+
+### Décision
+
+Pour un projet dont la cible est constituée de clients indépendants qui veulent leur autonomie, **préférer le mono-tenant déployable** (Option 1) tant que :
+
+- pas de feature cross-tenant attendue (pas de "voir les statistiques tous clients")
+- l'admin technique de chaque instance peut être différent
+- la simplicité de la sécurité (pas de scoping `tenantId` partout, pas de RLS Postgres, pas de tests "leak cross-tenant") prime sur l'économie d'opérations
+
+### Justification
+
+- Population cible = clients indépendants qui veulent leur autonomie
+- Sécurité plus simple : pas de scoping multi-tenant à valider partout
+- Conséquence : modélisation des configurations en singleton (cf. `pattern-singleton-db-config-globale` dans `knowledge/backend/patterns/general.md`)
+
+### Conséquences
+
+- Chaque déploiement a sa propre DB, ses propres uploads, son propre domaine
+- Pipeline CI/CD par instance ou via template (cf. `pattern-pipeline-cicd-github-actions-vps` dans `knowledge/backend/patterns/general.md`)
+- Migration vers Option 2 si la cible évolue (back-office central pour toutes les instances) → **réécriture explicite** plutôt que rétro-fit (ajouter `tenantId` partout est non-trivial)
+
+---
+
 ## 2. Infra
 
 <a id="decision-structure-docker"></a>