RIA (Reglement Interieur Achats) — 179 articles verbatim dans le RAG, fiabilite citation

Instance auteur : hermes-tt Date : 2026-08-06 Tags : [ria, rag, nyora-notes-tt, fts, achats] Statut : valide

Probleme

Ingestion du RIA (reglement interieur achats TT, 179 articles) dans NyoraNotes REST (:8787) avec exigence stricte de Nabil : toute question RIA doit retourner l'article ou les articles correspondants, cites VERBATIM sans aucune modification. Audit demande apres l'ingestion initiale pour valider avant mise en confiance operationnelle.

Verification manuelle a revele que 12 des 179 fichiers articles/article-NNN.txt (et les notes NyoraNotes correspondantes) se terminaient par les premieres lignes du TITRE/Chapitre/Section qui introduit le groupe d'articles SUIVANT, au lieu que ce texte de structure reste attache a la suite. Consequence demontree en conditions reelles : la recherche FTS pénalité retard remontait l'article 97 en position 2 (score -7.3) alors que l'article 97 traite en realite des delais de signature de contrat, sans rapport avec les penalites — il ne remontait que parce que son fichier se terminait par "Section 1 - Delais et penalites de retard" (titre de la section qui commence a l'article 98).

Contexte et contraintes

Source : reglement-interieur-achats-TT.docx, hash MD5 a6b534bb06473ce2ab6ac0f13ca4b0ea (verifie).
Extraction mecanique DOCX->XML vers 179 fichiers article-NNN.txt (parse_ria_articles.py) + fichier canonique RIA_INTEGRAL_179_articles.txt.
Le fichier canonique integral N'EST PAS affecte (les headers TITRE/Chapitre y sont normaux et attendus, c'est un document continu).
Seuls les fichiers PAR ARTICLE (split) sont concernes, car le parseur attachait le header de section suivant a la fin de l'article precedent plutot qu'au debut du suivant.
Ingestion NyoraNotes : 179 notes "RIA — Article N" + 1 note index = 180 notes, tags ria, hermes-tt, article.

Ce qui NE fonctionne PAS

Tentative	Erreur obtenue	Raison de l'echec
Faire confiance au rapport d'ingestion sans re-verifier le contenu reel des fichiers	Aucune erreur visible dans le rapport — le defaut n'apparait qu'en testant des requetes FTS reelles	Le rapport verifiait "la question renvoie le bon article en position 1" mais pas "aucun autre article n'est pollue par du texte hors-sujet"
Se fier au seul comptage (179 fichiers, 180 notes, sequence 1-179 complete)	Comptage correct, mais insuffisant	Un comptage exact ne garantit pas la purete du contenu de chaque fichier

Solution validee

Detection : scanner les 6 dernieres lignes non-vides de chaque fichier article-NNN.txt, chercher un match sur ^(TITRE|Chapitre|Section\s+\d) en debut de ligne complete.
12 fichiers concernes : 2, 5, 41, 97, 109, 127, 132, 142, 148, 152, 164, 172.
Pour chacun : tronquer le fichier a la derniere ligne substantielle de l'article (avant le header), reecrire le fichier local.
Recuperer l'ID de la note NyoraNotes correspondante (GET /notes?tag=ria&limit=100&page=N, filtrer par titre "RIA — Article N").
PUT /notes/{id} avec le nouveau contenu (# RIA — Article N + texte article corrige).
Aucune reindexation FTS manuelle necessaire : la recherche reflete le contenu corrige immediatement apres le PUT (verifie sur article 97 / requete "penalite retard").

Verification

curl -s -H "Authorization: Bearer $TOKEN" --get http://localhost:8787/search --data-urlencode "q=penalite retard"
# Attendu : article 99 en position 1, article 97 absent du top (ou present uniquement si legitimement pertinent)

Confirme le 06/08/2026 : article 97 n'apparait plus dans les 5 premiers resultats pour "penalite retard", le classement restant (99, 129, 30, 40, 105) est desormais coherent avec le contenu reel de chaque article.

Pieges specifiques DSM / NAS

mcp-nas : la commande docker n'est PAS disponible directement dans le shell du container mcp-nas (pas de docker.sock monte, pas de binaire docker). Il faut passer par ssh nas-host (alias configure vers Best0f@172.17.0.1:22222) puis utiliser le binaire complet /usr/local/bin/docker.
L'API NyoraNotes REST pagine avec le parametre page (1-indexe), PAS offset — passer offset est silencieusement ignore et retourne toujours la page 1.
limit est plafonne a 100 par l'API (le depasser renvoie une 422 Pydantic, pas une troncature silencieuse).
Le hash affiche dans les noms de fichiers du pipeline OneDrive (ex. ...a6b534bb.md) est un MD5, pas un SHA256.

References

Skill : gsd-ao-evaluation/references/ria-articles-cles.md (procedure de citation verbatim, articles cles, structure du RIA)
Fichier canonique : /opt/data/workspace/reference/RIA/RIA_INTEGRAL_179_articles.txt
Memoire hermes-tt : /opt/data/memories/MEMORY.md (entree RIA ajoutee 06/08/2026)

Addendum 06/08/2026 — purge du fichier memoire orphelin

Constat (demande Nabil) : hermes-tt possede DEUX fichiers "MEMORY.md" :

/opt/data/memories/MEMORY.md — le vrai fichier natif, confirme dans le code source de l'agent (tools/memory_tool.py, fonction get_memory_dir() -> {HERMES_HOME}/memories/MEMORY.md). C'est celui injecte automatiquement dans le prompt systeme a chaque session (bloc "MEMORY (your personal notes)").
/opt/data/MEMORY.md — fichier orphelin, JAMAIS lu par le moteur natif. En-tete affichait une limite de 2200 caracteres, deja depassee (3469 car.), contenu date du 01/06/2026 (services decommissionnes references comme actifs : Carbone, Gotenberg, Pandoc, pptx-tt-api, Paperless, Trilium ; port Baserow 3888 obsolete).

Verifie par comparaison : hermes-nyora et hermes-perso n'ont PAS ce fichier orphelin, uniquement memories/MEMORY.md (2181 et 2237 car. respectivement, sous budget). C'est un artefact propre a hermes-tt.

Cause racine probable : boot.md de hermes-tt (et de hermes-nyora, meme formulation) contient l'instruction generique "Lire MEMORY.md" sans chemin absolu. Chez nyora, un seul fichier porte ce nom -> pas d'ambiguite. Chez TT, deux fichiers portent ce nom -> l'agent, en suivant sa checklist boot au pied de la lettre, a pu lire (et tenter de mettre a jour) le mauvais fichier, expliquant le signalement de "saturation" (2902/2200 puis 3469/2200 car.) alors que le vrai fichier memoire actif n'etait pas concerne.

Correle avec observation Nabil : classement reactivite/justesse des instances Perso > Nyora > TT. Perso n'a meme pas de boot.md (aucune instruction de re-lecture manuelle). Nyora a boot.md mais pas de doublon. TT a boot.md ET un doublon -> ambiguite reelle, unique a cette instance. Hypothese plausible de contribution a la lenteur/defauts de raisonnement observes sur TT (contexte pollue par des faits perimes/contradictoires en plus du bloc memoire natif correct).

Action : fichier /opt/data/MEMORY.md supprime sur hermes-tt apres verification code source (non lu par le moteur). Contenu archive ci-dessous pour tracabilite. boot.md corrige pour lever l'ambiguite (chemin explicite, precision que le bloc memoire natif est deja auto-injecte, pas de relecture manuelle necessaire).

Contenu archive avant suppression (`/opt/data/MEMORY.md`, 06/08/2026)

# Mémoire Environnement
*limite : 2200 caractères — distiller à chaque mise à jour*

## Stack NAS
IP : 192.168.100.33 | DSM : Ahmed_-_Yesmine | user : Best0f
Réseau Docker : n8n | RAM : 20Go

## Services Docker actifs
n8n, Baserow (port 3888), Carbone, Gotenberg, Pandoc
pptx-tt-api, document-factory, Paperless, Trilium
Pingvin-Share, Portainer, Gitea (3232)

## Hermes Platform
hermes-tt : workspace 3010 · agent 8650
hermes-nyora : workspace 3020 · agent 8660
hermes-perso : workspace 3030 · agent 8670

## Baserow — Accès
Token RLA : XGCwbfgwg8ZiLVb4dxEfagWa7XptyUcM
URL interne : http://Baserow:3888
URL externe : https://baserow.bolbol.tn
Schéma complet : /opt/data/obsidian/config/baserow-schema.md (LIRE EN PREMIER)

## Baserow — Tables clés
T856 : Marchés RLA Zone Sud (55 marchés actifs au 30/04/2026)
T857 : Historique Avancement (snapshots mensuels)
T872 : Appels d'Offres en cours (pipeline 2026)
T998 : CI-CPT Zone Sud consolidé
T1006 : FB Zone Sud consolidé

## Situation marchés — 01/06/2026
- 4 non-renouvellements reçus : ECHABAKET (Lots 02+04 AO 58/2024) + SOTEL SUD (Lots 09+13 AO 66/2024)
- Avenants en cours : Lot 02 → YASMINE TELECOMS | Lot 04 → ATS
- Nouveaux marchés : Lot 09 → DR Gabes OK + quantitatifs reçus | Lot 13 → DR Kebili en attente
- 3 marchés AO 29/2025 + AO 31/2025 : fin contractuelle 13/05/2026 dépassée
- Pipeline AO 2026 : ~3.6 MDT en cours d'instruction

## Modèle par défaut
deepseek/deepseek-v4-flash (OpenRouter)

## Points actifs
- Schéma Baserow complet ajouté : 2026-06-01
- Modèle corrigé : GLM → DeepSeek V3.2 : 2026-06-01
- Workflow Marche RLA Sync validé : execution 25330 success 01/06/2026

Dernière mise à jour : 2026-06-01

## Historique Avancement — Table 857 (mis à jour 01/06/2026)

Total snapshots : 277 entrées
Couverture par mois :
  2025-12 : 43 entrées ✅ (13 marchés)
  2026-01 : 46 entrées ✅ (35 marchés)
  2026-02 :  3 entrées ⚠️ (incomplet — workflow non déclenché)
  2026-03 :  0 entrées ❌ (manquant — données non récupérables)
  2026-04 : 110 entrées ✅ (55 marchés × Financier + Physique — créé le 01/06/2026)
  2026-05 à 2027-01 : entrées issues des dates contractuelles (date_fin)

Snapshot 30/04/2026 : données arrêtées — référence officielle du portefeuille.
Mars 2026 : snapshot absent, données historiques perdues.
Février 2026 : incomplet (3 entrées seulement).

Format snapshot table 857 :
  Marche : [row_id table 856]
  Date_Releve : "AAAA-MM-JJ"
  Valeur : montant TND (avt_fin pour Financier, avt_phy pour Physique)
  Type_Avancement : "Financier" ou "Physique" (string direct, pas {"value":...})
  Observation : "Snapshot auto JJ/MM/AAAA — id_marche"

Pour créer un nouveau snapshot mensuel :
  python3 /tmp/snap_apr.py (adapter DATE et nom fichier)
  Ou via workflow n8n Marche RLA Sync (ID: 8RSSgxRogaIMsxgm)

## Audit Table 857 — État final (01/06/2026)

Total : 387 entrées (379 + 8 complétées)

| Date | Entrées | Source | Qualité |
|---|---|---|---|
| 2025-12-31 | 39 | Workflow Marche RLA Sync | ✅ TND réels |
| 2026-01-31 | 43 | Workflow | ✅ TND réels |
| 2026-02-28 | 55 | Workflow + complété | ✅ 51 TND + 4 Pas de PO |
| 2026-03-31 | 55 | Workflow + complété | ✅ 51 TND + 4 Pas de PO |
| 2026-04-30 | 110 | Créé manuellement | ✅ 55 marchés × Fin+Phy |

Historique % physique par marché (Déc25→Avr26) injecté dans SOUL.md via PPTX officiels.

11 KiB Raw Blame History Unescape Escape