diff --git a/runbooks/vpn-nas-vps-pont-api.md b/runbooks/vpn-nas-vps-pont-api.md
index 260277e..8126855 100644
--- a/runbooks/vpn-nas-vps-pont-api.md
+++ b/runbooks/vpn-nas-vps-pont-api.md
@@ -4,6 +4,51 @@
 > le **pont** (interne, sur le NAS), lequel parle à la gestion (Dolibarr) + ThingsBoard.
 > **La gestion n'est JAMAIS exposée.** Documenté pour être reproductible — ne rien casser.
 
+---
+## ⭐ CONNEXION VPS↔NAS ACTUELLE (depuis 2026-08-06) — TUNNEL SSH INVERSÉ
+
+> **SOURCE DE VÉRITÉ.** L'IPsec/IKEv2 Freebox (plus bas) est **RETIRÉ** : il cassait à chaque reboot
+> LWS (noyau externe `6.12` livré **sans module ESP** → tunnel mort, remontée SAV gelée). Le nouveau
+> lien ne dépend **ni du noyau LWS, ni de la Freebox** — seulement « le NAS a un accès internet
+> sortant » + « le VPS répond en SSH ».
+
+**Montage :** le **NAS compose** (dial-out) un SSH sortant vers le VPS et publie 2 *remote-forwards* :
+- `VPS 127.0.0.1:18080` → `NAS localhost:8080` = **pont SAV**
+- `VPS 127.0.0.1:11981` → `NAS localhost:1981` = **SSH du NAS** (sauvegarde / accès distant)
+
+**Côté NAS (Synology) :**
+- Clé dédiée `/volume1/docker/sav-tunnel/id_tunnel`, autorisée sur le VPS (`~deploy/.ssh/authorized_keys`,
+  option `restrict,port-forwarding` = ce couple de clés ne peut RIEN faire d'autre que du forwarding).
+- Persistance = **Planificateur de tâches DSM** → tâche déclenchée « **Au démarrage** », utilisateur
+  **root**, commande :
+  ```sh
+  KEY=/volume1/docker/sav-tunnel/id_tunnel
+  while true; do
+    ssh -i "$KEY" -o BatchMode=yes -o StrictHostKeyChecking=no -o ExitOnForwardFailure=yes \
+        -o ServerAliveInterval=30 -o ServerAliveCountMax=3 \
+        -N -R 18080:localhost:8080 -R 11981:localhost:1981 deploy@78.138.45.8
+    sleep 5
+  done
+  ```
+  La boucle `while` = **reconnexion automatique** (« autossh du pauvre »).
+
+**Côté VPS :**
+- Le pont lit le NAS via le tunnel : `/opt/navier-sav/.env` → `NAS_PONT_URL=http://127.0.0.1:18080`
+  (sauvegarde de l'ancien `.env` : `/opt/navier-sav/.env.bak-pretunnel`). Relais confirmé actif,
+  remontée SAV restaurée (plus aucun « fetch failed »).
+- Atteindre le NAS **depuis le VPS** : `ssh -p 11981 SteveC@127.0.0.1`
+  (⚠️ **plus** `192.168.10.104` : l'ancienne route IPsec est morte).
+
+**Vérif de bout en bout :**
+```bash
+ssh navier-vps 'curl -s http://127.0.0.1:18080/healthz'   # 200 => pont NAS joint via le tunnel
+ssh navier-vps 'ss -ltn | grep -E ":18080|:11981"'        # les 2 forwards doivent être UP
+```
+
+**Si ça retombe :** vérifier que la tâche DSM tourne (Planificateur de tâches), que le NAS a internet,
+puis `ss -ltn | grep 18080` sur le VPS. La tâche se relance seule ; sinon « Exécuter » dans DSM.
+
+---
 ## Architecture cible
 ```
 public ──HTTPS──▶ api.navier-instruments.com
@@ -103,7 +148,13 @@ curl -I https://api.navier-instruments.com/health
 ```
 
 ---
-## ✅ RÉALISÉ (2026-07-13) — VPN opérationnel = Freebox IKEv2 (pas WireGuard)
+## ⛔ RETIRÉ le 2026-08-06 — ancien VPN Freebox IKEv2 (remplacé par le tunnel SSH inversé, voir en tête)
+
+> **Ne plus utiliser.** Cassé par le reboot LWS du 31/07 (noyau `6.12` sans ESP). Remplacé par le
+> **tunnel SSH inversé** (section « CONNEXION VPS↔NAS ACTUELLE » en tête). Le 06/08/2026, strongSwan a
+> été **arrêté + désactivé au démarrage** sur le VPS, et `/etc/ipsec.conf` **archivé** dans
+> `/opt/navier-sav/ipsec-retired-2026-08-06/`. Conservé ci-dessous **pour l'historique uniquement**.
+
 WireGuard abandonné pour NAS↔VPS : le réseau du NAS (Freebox Pro) **filtre l'UDP sortant** (seul dport 53 passe, prouvé par tcpdump) → WireGuard (UDP) impossible depuis le NAS. **Retenu : serveur VPN IKEv2 de la Freebox Pro.**
 
 Montage : `VPS (client strongSwan) → 160189667.box.freepro.com (Freebox, VPN IKEv2) → LAN → NAS 192.168.10.104`.