diff --git a/_INDEX.md b/_INDEX.md
index 5abcdd9..71d9dc7 100644
--- a/_INDEX.md
+++ b/_INDEX.md
@@ -206,3 +206,4 @@
 
 - [common/guardrails-flotte-hermes-hard-stop-tirith-verificateur-12-08-2026.md](common/guardrails-flotte-hermes-hard-stop-tirith-verificateur-12-08-2026.md) -- hard_stop_enabled et tirith_enabled actives sur les 4 instances (etaient false), verificateur delegate_task croise (NAS genere DeepSeek/verifie Mimo V2.5, hermes-nabil inverse) ; faille provenance mail->RAG confirmee par lecture code mais pas corrigee (chantier a part) ; hermes-agent-tt trouve down 8h (mort non-propre, cause inconnue), hermes-workspace-perso bloque par port 3030 orphelin (12/08/2026)
 - [hermes-tt/nyora-notes-tt-backfill-72h-perte-silencieuse-429-resync-error404-16-08-2026.md](hermes-tt/nyora-notes-tt-backfill-72h-perte-silencieuse-429-resync-error404-16-08-2026.md) -- Backfill mail 72h termine (643->4322 notes). Deux pieges : (1) 444 messages perdus en silence sur 63 dossiers (18%) -- 66% sur HTTP 429 embeddings jete au lieu de reessaye, reste sur raisonnement mimo-v2.5 tronquant le JSON (max_tokens partage) ; dossier passait 'done' quand meme, bilan ne comptait pas les echecs -- fix retries+backoff, max_tokens 2500->8000, compteur messages_ignores remonte au bilan (0 perte en tranche finale). (2) 122 error_404 mesuraient un resolveur de chemin perime (bugs C/D corriges le 10/08), pas des dossiers absents -- 105/122 resolubles apres confrontation normalisee a un /folders frais. Regle generale : tout pipeline lot-LLM doit exposer un compteur d'echecs a cote du compteur de succes (16/08/2026)
+- [common/synology-scp-sftp-indisponible-cat-ssh.md](common/synology-scp-sftp-indisponible-cat-ssh.md) -- scp/sftp echouent systematiquement vers ce DSM ("No such file or directory" malgre chemin valide) -- sous-systeme SFTP indisponible pour l'utilisateur/cle d'automatisation, ssh lui-meme non affecte. Contournement : `cat fichier | ssh nas 'cat > dest'` (tar czf/xzf pour un dossier). Rencontre 2x en contextes differents (git bundle nas-runbooks, deploiement fichier partage aux 3 instances Hermes) -> promu en runbook transverse plutot que note de session isolee (16/08/2026)
diff --git a/common/synology-scp-sftp-indisponible-cat-ssh.md b/common/synology-scp-sftp-indisponible-cat-ssh.md
new file mode 100644
index 0000000..dd68f86
--- /dev/null
+++ b/common/synology-scp-sftp-indisponible-cat-ssh.md
@@ -0,0 +1,37 @@
+# Synology NAS : scp/sftp indisponibles pour transférer un fichier depuis le Mac
+
+**Symptôme** : `scp -P 22222 fichier Best0f@192.168.100.33:/volume1/docker/...` échoue avec
+`scp: dest open "...": No such file or directory`, alors que le chemin de destination existe
+bel et bien et que `ssh` vers le même hôte fonctionne normalement.
+
+**Cause** : le sous-système SFTP n'est pas activé (ou pas correctement exposé) sur ce DSM pour
+l'utilisateur/la clé utilisés en automatisation. `scp` moderne (protocole SFTP par défaut) et
+`sftp` échouent tous les deux de la même façon. `ssh` lui-même n'est pas affecté — seul le
+sous-canal de transfert de fichiers l'est.
+
+**Contournement** : piper le contenu via une session `ssh` classique plutôt que d'ouvrir un
+canal SFTP :
+
+```
+cat fichier_local | ssh nas 'cat > /volume1/docker/chemin/destination'
+```
+
+Fonctionne pour tout fichier texte/binaire raisonnable (déjà utilisé pour des scripts Python,
+des `.md`, un `git bundle`). Pour un dossier entier, `tar` avant/après :
+
+```
+tar czf - dossier_local | ssh nas 'cd /volume1/docker/chemin && tar xzf -'
+```
+
+**Portée** : ce n'est pas propre à un projet — touche tout transfert de fichier vers le
+filesystem de l'hôte NAS, quel que soit l'instance/la sphère à l'origine du besoin. Déjà
+rencontré deux fois dans des contextes différents (transfert d'un `git bundle` pour
+`nas-runbooks`, déploiement d'un fichier de mémoire partagée vers les 3 instances Hermes) —
+d'où sa promotion en runbook `common/` plutôt que de rester une note de session isolée.
+
+**Ce qui marche normalement** : `ssh`, `git` (via HTTP avec token, pas SSH), `rsync` non
+testé sur cette voie (probablement affecté par la même cause si basé sur SFTP, à vérifier avant
+de s'y fier).
+
+Voir aussi `nas-deploy-ops` (mémoire Claude Code, référence) pour les autres pièges d'accès NAS
+(port SSH 22222, chemins, git absent de l'hôte).