# 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

1. 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.
2. 12 fichiers concernes : 2, 5, 41, 97, 109, 127, 132, 142, 148, 152, 164, 172.
3. Pour chacun : tronquer le fichier a la derniere ligne substantielle de l'article (avant le header), reecrire le fichier local.
4. Recuperer l'ID de la note NyoraNotes correspondante (`GET /notes?tag=ria&limit=100&page=N`, filtrer par titre "RIA — Article N").
5. `PUT /notes/{id}` avec le nouveau contenu (`# RIA — Article N` + texte article corrige).
6. 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)

```markdown
# 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.

```