diff --git a/common/skills-concurrents-pdf-docx-pptx-xlsx.md b/common/skills-concurrents-pdf-docx-pptx-xlsx.md
index c996b8e..1a68c2f 100644
--- a/common/skills-concurrents-pdf-docx-pptx-xlsx.md
+++ b/common/skills-concurrents-pdf-docx-pptx-xlsx.md
@@ -104,3 +104,19 @@ supplémentaires trouvés, dont 4 cassés (références Pandoc/Gotenberg retiré
 
 - Caches `.skills_prompt_snapshot.json` purgés (seul tt en avait un, à la racine de `data/`).
 - Les 3 agents redémarrés un par un **depuis l'hôte NAS** (`ssh nas` puis `/usr/local/bin/docker restart hermes-agent-<i>`) — contrairement au 02/07 c'est faisable quand la session vient du Mac (le blocage ne concernait que le conteneur mcp-nas). Health = healthy, UI 3010/3020/3030 = 200, ownership `data/` = 1026:100 intact.
+
+---
+
+## Piège découvert 09/07 — cron référençant un skill archivé
+
+Le job cron hermes-perso « Veille Orientini 2026 » (actif, 3x/jour) référençait encore
+`pptx-presentation` (archivé le 02/07) comme skill principal + instruction « template
+light-theme » dans le prompt. Le job tournait sans erreur (last_status ok) et produisait
+ses PPTX en génération locale — exactement le contournement que l'archivage devait empêcher.
+
+Corrigé le 09/07 (GO Nabil) : référence retirée, génération routée vers nyora-doc-api,
+procédure docker stop → édition jobs.json → docker start.
+
+**Règle ajoutée à la méthode** : après tout archivage de skill, vérifier les
+`cron/jobs.json` des 3 instances (champs `skill`, `skills[]` et le texte du prompt)
+sur le nom du skill archivé. Détail : common/audit-data-hermes-20260709.md.