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

6.9 KiB Raw Permalink Blame History Unescape Escape