diff --git a/common/runbook-audit-charge-nas-ds920-methode-2026-07.md b/common/runbook-audit-charge-nas-ds920-methode-2026-07.md
new file mode 100644
index 0000000..a1af0d0
--- /dev/null
+++ b/common/runbook-audit-charge-nas-ds920-methode-2026-07.md
@@ -0,0 +1,36 @@
+# Runbook — Audit de charge NAS DS920+ : méthode et état de référence (2026-07-12)
+
+## Méthode de mesure (réutilisable)
+```bash
+ssh nas '/usr/local/bin/docker stats --no-stream --format "{{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}"'
+ssh nas 'free -m; cat /proc/loadavg; nproc; uptime'
+ssh nas 'ps aux --sort=-%cpu | head -12; ps aux --sort=-rss | head -8'
+```
+
+### Pièges de lecture (Synology)
+- Le `uptime` DSM décompose le loadavg en `[IO: x CPU: y]` → **lire la part CPU**, le total inclut l'attente disque.
+- Un scan de fichiers depuis le Mac (find/ls sur /Volumes/docker en SMB) fait monter `smbd` à 80 %+ CPU → fausse le load 1 min. Mesurer avant/sans scan.
+- `docker stats` = mémoire cgroup (sans cache) ≠ RSS hôte via `ps`. Ex. qbittorrent : 434 Mo cgroup vs 1,83 Go RSS.
+- Swap utilisé ≠ pression actuelle : croiser avec `Dirty` (/proc/meminfo) et l'activité kswapd.
+
+## État de référence 2026-07-12 (42 containers)
+- RAM : 6,4 / 19,85 Go utilisés, ~12,9 Go disponibles ; somme RSS containers ≈ 4,8 Go ; swap 3,2 Go (résiduel).
+- CPU (J4125, 4 cœurs) : ~27 % en moyenne 15 min.
+- **Goulot réel = IO disque** : load IO soutenu 2,0–2,4 (btrfs + Postgres n8n/Baserow + SQLite multiples). La machine plafonnera par l'IO avant la RAM/CPU.
+- Top RAM : Baserow stack 1,3 Go ; Hermes ×3 1,3 Go ; qbittorrent 1,83 Go RSS ; n8n 413 Mo.
+- Top CPU steady : crowdsec ~11 %, ActiveInsight 3,5 % (**obligatoire, ne pas désactiver — protection DSM**), dockerd 3 %.
+
+## Décisions actées
+- media-stack (prowlarr/radarr/sonarr) supprimé volontairement le 04/07 ; data conservée `/volume1/docker/media-stack/`.
+- wg-easy retiré : VPN NAS = **Tailscale**. WireGuard ne subsiste que sur le VPS (KeepSolid). `wg-admin-client` = client tunnel.
+- Verdict capacité : Family Help prod + nyora-veille passent sans dégradation (<300 Mo en pointe, LLM via Bifrost). Ne pas ajouter de service IO-intensif sans mesure préalable.
+
+## Actions en attente
+1. Purger l'orphelin flaresolverr : `docker stop flaresolverr && docker rm flaresolverr` (plus de client depuis la suppression de prowlarr).
+2. Appliquer la limite hermes-agent-perso 600→768 Mo (déjà stagée dans le compose racine) :
+   `cd /volume1/docker/hermes-platform && /usr/local/bin/docker compose up -d --force-recreate hermes-agent-perso`
+   puis vérifier `stat -c '%u:%g' hermes-perso/data` = 1026:100 et health = healthy.
+
+## Ce qui NE marche PAS
+- Backup de `hermes-perso/data` (4 Go dont 1,2 Go .browsers) via le montage SMB du Mac : cp/rsync time-out. Faire les copies côté NAS.
+- `ports-registry.md` dérive vite : resync v4 fait le 12/07 (source de vérité = docker ps réel).