Brief Gemini — Audit indépendant du chantier « désaccentuation systémique »

Date : 2026-09-01 Demandeur : Nabil Rôle attendu : audit indépendant, pas relecture d'un rapport. Tu dois retester en direct chaque point ci-dessous en lisant les fichiers réels et en exécutant les vérifications toi-même, jamais en te fiant à ce brief pour conclure qu'un point est déjà bon.

Ticket

Ce travail est suivi dans le système de tickets Baserow (workspace Nyora, base 318) : ticket infra-2026-09-002, table tickets (id table 1100), ligne id 2. Statut actuel : ouvert, agent assigné : Gemini.

À la fin de ton audit, mets à jour ce ticket toi-même via l'API Baserow (même méthode que pour tout accès Baserow : lire Baserow_Nyora_API_Key dans /volume1/docker/.secrets-staging/baserow.env, header Authorization: Token <clé> + Host: baserow.bolbol.tn, base http://172.17.0.1:80/api/database/rows/table/) :

Pour chaque preuve (commit Gitea, health check, etc.), crée une ligne dans interventions (table id 1101) : Ticket = [2], Auteur = [3] (Gemini dans la table agents), Type de preuve parmi commit Gitea / health check HTTP / capture SSH / autre, Preuve en texte factuel (hash, URL, résultat brut — jamais une phrase narrative).
Renseigne Résumé agent sur le ticket (table tickets, id 1100, ligne id 2) avec ce que tu as vérifié et trouvé.
Mets Statut à en attente d'audit (PAS clôturé) — Claude fait l'audit final et décide de la clôture, conformément à la règle établie du circuit ticket.
Vérifie tes propres accents avant d'écrire dans Baserow. Ce serait absurde qu'un rapport sur la désaccentuation soit lui-même désaccentué.

Contexte (résumé)

Claude a diagnostiqué et corrigé une cause racine : sur les 3 instances Hermes du NAS (nyora, tt, perso), le fichier SOUL.md (le vrai prompt système, chargé à chaque session) avait reçu le 18/07/2026 un bloc de règle de langue correctement accentué, ajouté en tête du document — mais le corps préexistant du fichier (rédigé à l'origine par Nabil au clavier QWERTY) n'avait jamais été réaccentué. Le volume de texte non accentué dans le corps écrasait la règle énoncée une seule fois en tête.

Le même défaut a été retrouvé et corrigé dans : RUNBOOK-TEMPLATE.md (×3), boot.md et USER.md (nyora), les 3 sous-agents nyora (agent-veille.md, agent-contenu.md, agent-commercial.md), plusieurs fichiers references/, un profil Bot Mode (profiles/veilleur/SOUL.md), et l'intégralité de PROTOCOL-INFRA.md (tronc + changelog daté juillet-août) sur les 3 instances.

Côté DSH-VPS (pas de fichier SOUL.md équivalent — son identité vient de context-hub, relue à chaque session) : un script de génération de document Word (/workspace/mp1/generate-docx-v3.mjs) avait régressé sur les accents de sa page de garde et de son sommaire par rapport à des versions antérieures (v1/v2) qui étaient correctes. Corrigé, document régénéré. Une règle de langue permanente a été ajoutée dans context-hub, scope infra (clé langue_rule), lue par Claude, Gemini et DSH à chaque session via GET /api/context.

hermes-nabil (VPS) a été vérifié sain — aucune correction nécessaire.

Runbook complet : bolbol/nas-runbooks/common/desaccentuation-systemique-soul-md-20260901.md

Pourquoi ce check

Nabil veut une garantie que ce n'est plus jamais un problème récurrent. Ton rôle est de vérifier deux choses distinctes :

Que les correctifs déjà appliqués tiennent (pas de régression, pas d'oubli localisé).
Qu'il n'existe pas d'autre foyer de la même maladie ailleurs dans la stack — le motif générique est : une règle de style/langue ajoutée en tête d'un document ou d'un prompt système, jamais appliquée au corps existant, ou un générateur de document avec des chaînes françaises codées en dur, jamais relues lors d'une réécriture.

Méthodologie de scan (accents)

Pour tout fichier .md/.mjs/.py/.js candidat, calcule le ratio de caractères accentués pour 1000 caractères :

ACCENTED = set("éèêëàâäùûüôöîïçœæÉÈÊËÀÂÄÙÛÜÔÖÎÏÇŒÆ")
ratio = sum(1 for c in content if c in ACCENTED) / len(content) * 1000

Un ratio en dessous de ~4-5/1000 sur un fichier de prose française de plus de 200 caractères est suspect. Un français correctement rédigé tourne plutôt autour de 15-25/1000.

Exclusions à respecter absolument (sinon tu vas noyer le signal sous du bruit) :

node_modules/, .venv/, venv/, site-packages/, .pnpm-store/, lazy-packages/
Tout paquet de skill tiers en anglais (ex. skills/agents/, skills/ai-seo/, skills/autonomous-ai-agents/, skills/creative/ascii-art/ sur les instances NAS — ce sont des skills vendor, pas du contenu de Nabil)
Les logs de sortie cron (/opt/data/cron/output/*.md) — ce sont des artefacts de runs passés, pas des instructions vivantes ; à signaler seulement s'ils révèlent un job cassé produisant toujours la même sortie (taille identique répétée), pas pour l'accentuation
Les fichiers .bak_accents_* (sauvegardes déjà connues)
Les données brutes (codes, identifiants, noms d'entreprises, gouvernorats TT sans accent par convention — Gabes, Kebili, Medenine, Tataouine, Tozeur)

Périmètre précis à vérifier

1. Re-vérification des correctifs Claude (échantillonnage, pas juste croire que c'est bon)

SOUL.md sur hermes-agent-nyora, hermes-agent-tt, hermes-agent-perso : lire le fichier entier, confirmer visuellement qu'aucun paragraphe n'est resté désaccentué
RUNBOOK-TEMPLATE.md ×3
PROTOCOL-INFRA.md ×3 : vérifier notamment qu'il n'y a plus d'occurrence du texte littéral \x27 (grep -c '\x27' PROTOCOL-INFRA.md doit renvoyer 0)
context-hub scope infra : curl http://100.86.197.88:3093/api/rules/infra et confirmer que langue_rule est présent et lisible avec ses accents

2. Recherche de nouveaux foyers — NAS (3 instances hermes-agent-*)

Balayer /opt/data/ (top-level + agents/, skills/ hors vendor, references/, profiles/*/, memories/) sur les 3 instances avec le scan ci-dessus. Toute trouvaille sous le seuil doit être lue en entier avant conclusion (un ratio bas peut aussi être un fichier légitimement technique/anglais).

3. DSH-VPS

Relire generate-docx-v3.mjs (déjà corrigé) et confirmer qu'aucune autre chaîne codée en dur n'a été manquée
Vérifier s'il existe d'autres scripts de génération de document dans /workspace/ (pas seulement mp1/) — chercher tout .mjs/.py qui construit un document Word/PDF/PPTX avec du texte français, et appliquer le même scan
Vérifier /home/dsh-agent/.dsh/memory/notes.md et tout fichier sous skills/

4. Au-delà de Hermes et DSH — autres générateurs de documents Nyora

nyora-doc-api (port 3050, formatting.py) : ce service centralise la charte Nyora pour tous les documents générés (XLSX/DOCX/PPTX/PDF) — vérifier qu'aucun libellé, en-tête, pied de page ou métadonnée codé en dur n'est désaccentué. C'est un point à fort effet de levier : un défaut ici se propage à tous les documents produits par ce service, comme RUNBOOK-TEMPLATE.md se propageait à tous les runbooks.
redaction-pro, family-help, nyora-veille, rla-api, gsparc-mezzouna : vérifier s'il existe des templates ou chaînes de titre/en-tête codées en dur (même recherche ciblée, pas un audit complet de ces apps si rien ne saute aux yeux rapidement)

Si tu trouves un problème

Applique le même protocole que Claude, sans exception :

Sauvegarde avant toute écriture (cp fichier fichier.bak_accents_gemini_20260901)
Corrige uniquement le texte français concerné — jamais les données, jamais le code fonctionnel, jamais les identifiants ou URLs
Vérifie après écriture (relire le fichier, confirmer visuellement)
Documente dans le runbook existant ou un nouveau runbook si le périmètre est distinct

Format de rapport attendu

Un runbook Gitea (bolbol/nas-runbooks/common/audit-gemini-accents-20260901.md), suivant la convention établie : ce qui a été vérifié, ce qui était déjà bon (avec preuve — extrait ou commande de vérification, pas juste "OK"), ce qui a été trouvé et corrigé (avec avant/ après), et ce qui reste incertain ou hors de ta portée. Mets à jour _INDEX.md.

Important : Claude relira ce rapport puis retestera en direct un échantillon des points listés — pas de clôture du chantier sur la seule foi du rapport. Sois donc précis et vérifiable plutôt qu'exhaustif et vague.

8.6 KiB Raw Permalink Blame History Unescape Escape