runbook: desaccentuation systemique SOUL.md/PROTOCOL-INFRA.md/DSH (01/09/2026)

common/desaccentuation-systemique-soul-md-20260901.md

@@ -0,0 +1,118 @@
+# Désaccentuation systémique des prompts système et générateurs de documents (SOUL.md, PROTOCOL-INFRA.md, DSH)
+
+**Date** : 2026-09-01
+**Instances concernées** : hermes-nyora, hermes-tt, hermes-perso, DSH-VPS (hermes-nabil vérifié sain)
+**Tags** : accents, langue, soul-md, protocol-infra, dsh, docx, context-hub, qualite-production
+
+---
+
+## Problème
+
+Symptôme initial : la veille automatique 20h (hermes-nyora) produisait du français
+intégralement désaccentué, malgré une règle explicite de langue déjà présente dans le
+prompt système. Signalé par Nabil comme récurrent ("nième fois"). Investigation étendue
+au reste de la plateforme sur demande explicite, révélant un défaut structurel bien plus
+large que la seule veille.
+
+Deuxième occurrence distincte le même jour : DSH-VPS a généré un document Word (.docx)
+dont la page de garde et le sommaire étaient désaccentués, alors que le contenu importé
+du markdown source restait correctement accentué.
+
+## Contexte et contraintes
+
+Nabil travaille au clavier QWERTY, sans accents faciles d'accès. Les documents (SOUL.md,
+scripts, index) rédigés directement par lui, ou par un agent dans une session où l'habitude
+"ASCII" domine, héritent de ce biais. Un correctif de règle ajouté en tête d'un document
+ne corrige pas rétroactivement le corps existant.
+
+## Ce qui NE fonctionne PAS
+
+| Tentative | Erreur obtenue | Raison de l'échec |
+|-----------|----------------|-------------------|
+| Ajouter une règle "accents obligatoires" en tête de SOUL.md (fix du 18/07/2026) | La règle est respectée localement mais le reste des sorties reste désaccentué | Le corps préexistant du document (des milliers de caractères désaccentués) sert de contre-exemple dominant ; un LLM suit le volume de style observé plus qu'une instruction énoncée une fois |
+| Corriger uniquement le fichier signalé (ex. seulement le job veille) | Le symptôme réapparaît ailleurs (runbooks, sous-agents, autres instances) | La cause est structurelle (le system prompt lui-même), pas locale à un job |
+| Réécrire un script de génération de document sans relire ses chaînes fixes | Régression : une version antérieure (v1/v2) avait les bons accents, la réécriture (v3) les a reperdus | Aucune règle persistante ne rappelait de vérifier les chaînes codées en dur lors d'une réécriture |
+
+## Cause racine
+
+**Côté Hermes (nyora/tt/perso)** : SOUL.md est le vrai system prompt, chargé à chaque
+session (chat et cron). Le 18/07/2026, un bloc de règle de langue correctement accentué
+avait été ajouté en tête des 3 SOUL.md, mais le corps préexistant (rédigé à l'origine par
+Nabil) était resté intégralement désaccentué. Même pattern retrouvé dans RUNBOOK-TEMPLATE.md
+(source directe de la contamination de tous les runbooks produits depuis), les 3 sous-agents
+nyora (agent-veille/contenu/commercial.md), plusieurs fichiers references/, un profil Bot
+Mode (profiles/veilleur/SOUL.md), et une bonne partie du corps de PROTOCOL-INFRA.md
+(règles + entrées de changelog datées de juillet-août).
+
+**Côté DSH-VPS** : pas de SOUL.md équivalent — l'identité de l'agent vient de context-hub,
+interrogé à chaque session (`GET /api/context`). Aucune règle de langue n'y existait, donc
+rien ne contrebalançait le biais QWERTY lors d'une réécriture de script.
+
+**Trouvaille annexe distincte (bug différent, même terrain)** : 4 occurrences du texte
+littéral `\x27` à la place d'apostrophes réelles dans PROTOCOL-INFRA.md, et le même motif
+retrouvé dans _INDEX.md (`ui_meta[\x27hermes-bots\x27]`) — probable fuite d'échappement
+Python d'une session antérieure ayant écrit du JSON/repr au lieu du texte brut.
+
+## Solution validée
+
+```
+# Réaccentuation intégrale (corps complet, pas juste la tête), sauvegarde
+# .bak_accents_niveau2_20260901 avant chaque écriture, checksum vérifié à chaque transfert :
+- SOUL.md ×3 instances (nyora, tt, perso) — tt recevait en plus le bloc RÈGLE DE LANGUE
+  qui lui manquait entièrement
+- boot.md, USER.md (nyora)
+- RUNBOOK-TEMPLATE.md ×3
+- agent-veille.md, agent-contenu.md, agent-commercial.md (nyora)
+- api-calls.md, nyora-synthese-reference.md (nyora et perso)
+- veille-sources-ia.md (perso), mail-o365-tt.md (tt)
+- profiles/veilleur/SOUL.md (nyora)
+- PROTOCOL-INFRA.md intégral ×3 (tronc commun + tout le changelog daté + sections
+  spécifiques tt) + correctif \x27 -> apostrophe (4 occurrences ×3 instances)
+- Redémarrage propre (stop puis start, jamais restart) des 3 containers hermes-agent-*
+  après chaque lot de correctifs, cron vérifié intact à chaque fois (next_run_at cohérent)
+
+# Côté DSH-VPS :
+- generate-docx-v3.mjs : 8 chaînes codées en dur réaccentuées (page de garde, sommaire,
+  métadonnées docx), document régénéré et vérifié
+- Ajout d'une règle de langue permanente dans context-hub, scope infra (lu par Claude,
+  Gemini et DSH) via PATCH /api/rules/infra — clé "langue_rule", incluant explicitement
+  la consigne de revérifier les chaînes fixes d'un générateur lors d'une réécriture
+- Corrigé au passage : deux fautes ("ecrire") dans secrets_rule (infra) et rules (nyora)
+  de context-hub lui-même
+```
+
+## Vérification
+
+```
+# Ratio caractères accentués / 1000 caractères sur PROTOCOL-INFRA.md, avant/après :
+# avant : ~5.4-5.8   après : ~21.3-21.7 (comparable à du français correctement rédigé)
+
+# Document DSH régénéré :
+node generate-docx-v3.mjs
+# -> page de garde et sommaire vérifiés accentués par extraction du XML interne (word/document.xml)
+
+# context-hub, scope infra :
+curl http://100.86.197.88:3093/api/rules/infra -H "X-API-Key: ..."
+# -> langue_rule présent et correctement accentué
+```
+
+## Pièges spécifiques DSM / NAS
+
+- Un bloc de règle ajouté en tête d'un prompt système ne suffit jamais si le corps existant
+  n'est pas lui-même corrigé — le volume l'emporte sur l'instruction unique.
+- Toute réécriture de script générateur de document doit relire ses chaînes fixes
+  (page de garde, sommaire, métadonnées), pas seulement le contenu dynamique importé —
+  une version antérieure correcte n'empêche pas une régression lors d'une réécriture ultérieure.
+- Pour DSH (pas de fichier persistant type SOUL.md), le bon point d'ancrage pour une règle
+  durable est context-hub (`PATCH /api/rules/{scope}`), lu à chaque session via
+  `GET /api/context` — pas un fichier local qui ne survivrait pas à une reconstruction.
+- Pour transférer du texte accentué depuis un environnement d'outils tiers (chat) vers un
+  fichier NAS/VPS sans corruption : passer par un script Python local (heredoc direct dans
+  le shell cible), jamais par une commande shell avec accents inline échappés à la main —
+  risque de désynchronisation d'échappement (constaté une fois pendant ce chantier même,
+  avec une note NyoraNotes republiée correctement après coup).
+
+## Références
+
+- `bolbol/nas-runbooks/hermes-nyora/` pour tout détail spécifique nyora
+- Note NyoraNotes : `infra/desaccentuation-systemique-SOUL-md-resolue-2026-09-01`