diff --git a/hermes-tt/n8n-cron-orphelin-hermes-mail-browser-instabilite.md b/hermes-tt/n8n-cron-orphelin-hermes-mail-browser-instabilite.md
new file mode 100644
index 0000000..e870333
--- /dev/null
+++ b/hermes-tt/n8n-cron-orphelin-hermes-mail-browser-instabilite.md
@@ -0,0 +1,77 @@
+# Cron n8n orphelin (ingestion continue nyora-notes-tt) : boucle infinie sur folders error_409/404, cause reelle de la lenteur hermes-mail-browser
+
+**Instance auteur** : hermes-tt
+**Date** : 2026-08-02
+**Tags** : n8n, hermes-mail-browser, nyora-notes-tt, cron, stabilite
+**Statut** : valide
+
+---
+
+## Probleme
+
+hermes-mail-browser semblait instable/lent (deja documente hier : 20/21 timeouts sur /search
+profonds). Aujourd'hui, un test de telechargement de PJ a semble bloquer 3+ minutes sur un
+simple /search. Diagnostic initial : suspicion de probleme structurel OWA/Playwright.
+
+## Diagnostic reel
+
+Les logs `docker logs hermes-mail-browser` montrent un appel `GET /search?q=*&folder_path=00
+2026|Divers` **toutes les 10 minutes, exactement**, depuis le 31/07 (source IP 172.27.0.34 =
+nyora-notes-tt). 292 occurrences. `n8n:search_executions` sur le workflow correspondant
+(`Hovzm2wTOOJFxzpb`, "nyora-notes-tt -- Ingestion continue") confirme : 292 executions, toutes
+marquees "success" (le noeud HTTP a `neverError:true`, donc un 409 ne fait pas echouer
+l'execution n8n -- invisible dans le monitoring standard).
+
+Le workflow : `Planification continue (10 min)` -> `GET /pending-folders?limit=1` ->
+`POST /ingest` sur le dossier recupere. Conçu pour "s'arreter seul quand tout est done" --
+mais les statuts `error_409` (5 dossiers, doublons ambigus) et `error_404` (dossiers vides
+confirmes) sont des **etats finaux legitimes**, jamais retraitables avec succes. Le dossier
+"00 2026|Divers" (error_409) revient donc systematiquement en tete de `/pending-folders`,
+le workflow le re-ingere en boucle, obtient un 409, ne progresse jamais -- la condition
+d'arret ("plus rien en pending/error") ne se declenche donc jamais non plus.
+
+Consequence : contention reguliere (toutes les 10 min, ~10-90s par execution) sur la page
+Playwright partagee de hermes-mail-browser, pour un travail strictement inutile.
+
+## Ce qui n'etait PAS la cause (verifie, pour eviter de re-chasser cette piste)
+
+| Hypothese | Verification | Resultat |
+|-----------|--------------|----------|
+| Fuite memoire Chromium / ressources hermes-mail-browser | `docker stats` | 1 Go RAM / 19 Go, CPU ~0%, uptime 8h -- sain |
+| /search reellement bloque/casse | Test instrumente (`-u`, timing explicite) apres arret du cron | search ~35s, list_attachments ~10-15s/message -- conforme aux baselines deja documentees (mail-o365-search-pas-de-filtre-date.md) |
+| Le "blocage" de 3 min pendant le test PJ | Logs serveur hermes-mail-browser au meme timestamp | La requete a bien progresse (200 OK x8), c'etait un faux positif cote client (stdout bufferise sur pipe ssh/docker exec sans `-u`, aucune visibilite temps reel) |
+
+## Solution validee
+
+```bash
+# Identifier le workflow via n8n MCP : search_workflows puis get_workflow_details
+# Desactiver :
+n8n:unpublish_workflow(workflowId="Hovzm2wTOOJFxzpb")
+```
+
+Verification : plus aucune ligne `172.27.0.34` recurrente a intervalle de 10 min dans les
+logs hermes-mail-browser apres desactivation.
+
+## Piege generique a retenir
+
+Toute boucle n8n avec condition d'arret "automatique" basee sur un etat DB (type
+`/pending-folders` jusqu'a vide) doit garantir une VRAIE terminaison, pas juste supposer que
+la source se tarira. Un statut d'erreur "final" (409 ambigu, 404 confirme vide) n'est pas
+la meme chose qu'un statut "en attente de retry" -- si le endpoint source ne distingue pas
+les deux, la boucle ne se videra jamais. Corollaire : `neverError:true` sur un noeud HTTP
+masque ce genre de boucle inutile dans le monitoring n8n standard (toutes les executions
+semblent "success") -- verifier le CONTENU des reponses, pas seulement le statut d'execution,
+pour tout workflow recurrent cense s'auto-arreter.
+
+Avant de blamer un service externe (ici hermes-mail-browser/OWA) pour de la lenteur ou de
+l'instabilite persistante, verifier D'ABORD s'il existe un consommateur interne recurrent
+(cron n8n, watchdog, boucle de retry) qui genere du bruit de fond -- `docker logs` filtre par
+IP source est souvent le moyen le plus rapide de le confirmer ou de l'ecarter.
+
+---
+
+## References
+
+- `hermes-tt/mail-o365-search-pas-de-filtre-date.md` (30/07/2026) -- baseline timing /search deja mesuree (~35-40s/appel)
+- `hermes-tt/nyora-notes-tt-backup-wal-moteur-mixte.md` (02/08/2026) -- incident precedent du meme jour, meme famille de lecon (verifier le comportement reel avant de blamer l'infra sous-jacente)
+- Workflow n8n `Hovzm2wTOOJFxzpb` (desactive, pas supprime -- conserve pour historique)