diff --git a/common/veille-dr-nexum-cron-timezone-publish-n8n.md b/common/veille-dr-nexum-cron-timezone-publish-n8n.md
new file mode 100644
index 0000000..24a133d
--- /dev/null
+++ b/common/veille-dr-nexum-cron-timezone-publish-n8n.md
@@ -0,0 +1,34 @@
+# Cron Hermes ne se relit pas au vol + publish n8n casse : veille Dr Nexum non recue
+
+**Date** : 2026-07-07
+**Tags** : infra, cron, hermes, n8n, publish, timezone, veille, nyora
+
+## Symptome
+Veille Dr Nexum (Hermes 3x/jour + workflow n8n) non recue le 06/07 20h ni le 07/07 7h, sur les deux pipelines simultanement.
+
+## Cause 1 -- Cron Hermes fige en memoire (jobs.json)
+Le service cron de chaque agent Hermes charge `jobs.json` uniquement au demarrage du container. Une edition directe du fichier (passage de 1x a 3x/jour le 06/07) s'est bien ecrite sur disque, mais le processus tournait toujours avec l'ancien horaire quotidien (11h30 UTC) en memoire -- `next_run_at` restait fige sur l'ancienne valeur meme un jour apres l'edit.
+
+**Fix** :
+1. Editer `jobs.json` (cron expr).
+2. Recalculer et ecrire manuellement `next_run_at` a la bonne valeur (le daemon ne le fait pas toujours correctement au premier boot suivant).
+3. Redemarrer le container **agent** correspondant -- nom reel `hermes-agent-tt` / `hermes-agent-nyora` / `hermes-agent-perso` (piege : ne pas confondre avec `hermes-workspace-*`, qui sont d'autres containers).
+4. Restart via API Portainer : `POST /api/endpoints/2/docker/containers/{id}/restart` timeout systematiquement sur cette instance -- utiliser `stop` puis `start` explicites (2 appels separes).
+5. Verifier apres coup que `next_run_at` a la bonne valeur.
+
+Portainer : endpoint local = id `2`. Auth via `172.17.0.1:9000/api/auth` depuis un container (jamais l'IP LAN). Credentials dans `hermes-platform/.env`.
+
+## Cause 2 -- Fuseau horaire (NAS + n8n en UTC, pas Tunis)
+Le NAS et n8n tournent en UTC. Tunis = UTC+1 toute l'annee (pas de changement d'heure). Un cron `0 7,12,20 * * *` tire a 8h/13h/21h Tunis, pas 7h/12h/20h.
+
+**Fix** : toujours retirer 1h a l'expression cron pour un horaire "heure de Tunis" -- `0 6,11,19 * * *` en UTC pour obtenir 7h/12h/20h Tunis. Applique sur jobs.json (Hermes) et sur le node Schedule Trigger n8n.
+
+## Cause 3 -- publish_workflow n8n casse sur un workflow specifique (non systemique)
+Un workflow deja actif, modifie via l'outil `update_workflow`, ne bascule pas automatiquement en production -- `update_workflow` cree un nouveau `versionId` (brouillon) mais le workflow continue de servir son `activeVersionId` existant. Sur ce workflow precis, `publish_workflow` echouait de facon persistante avec `"Version not found"`, y compris en reessayant **depuis l'UI n8n elle-meme** (capture d'ecran a l'appui) et apres un `unpublish_workflow` prealable -- confirme comme un etat corrompu propre a ce workflow (chaine de versions cassee en base), pas un bug de l'outil MCP.
+
+**Fix qui a marche** : dupliquer le workflow (bouton **Duplicate** dans l'UI n8n). La copie repart avec une chaine de versions saine et se publie normalement des le premier essai. Renommer la copie pour retirer le suffixe " copy", puis `unpublish_workflow` + `archive_workflow` sur l'original casse une fois la copie confirmee active.
+
+**Verification obligatoire apres toute modif d'un workflow n8n deja actif** : `get_workflow_details` -> comparer `versionId` et `activeVersionId`. S'ils different, le changement n'est PAS en production, meme si l'outil de modification a repondu succes.
+
+## Lecon generale
+Une reponse "success" d'un outil de modification (`update_workflow`, edition de `jobs.json`) ne garantit jamais que le changement est en production. Toujours verifier l'etat reel apres coup : `next_run_at` recalcule pour un cron Hermes redemarre, `activeVersion == draft` pour un workflow n8n.