nas-runbooks/hermes-tt/nyora-notes-tt-roadmap-pieces-jointes.md

nyora-notes-tt -- Pieces jointes : chantier dedie futur, EXHAUSTIF, architecture 2 phases (31/07/2026)

Date : 31/07/2026 (v3 -- ajoute l'architecture 2 phases proposee par Nabil)

Decision finale (rappel v2)

Exhaustif : toutes les PJ, tous les dossiers. Dedoublonnage par CONTENU (similarite vectorielle sur texte extrait), jamais par nom de fichier -- une meme PJ peut etre diffusee plusieurs fois ou renommee. Chantier separe, lance APRES le backfill texte (205 dossiers, 2024-2026, deadline dimanche matin), jamais en parallele.

Architecture 2 phases (idee de Nabil, 31/07/2026)

Decouple explicitement la partie LENTE-MECANIQUE (telechargement, contrainte OWA) de la partie LENTE-LLM (resume/embedding) -- les deux etaient bundlees dans le concept initial, ce qui les faisait payer le meme prix (45s d'attente OWA) meme pour la relecture. Separer permet a la phase 2 de tourner vite, sur fichiers locaux deja presents, sans plus jamais toucher OWA.

Phase 1 -- Telechargement seul, aucun appel LLM

• Reproduit la structure des dossiers mail sur disque (miroir de l'arborescence O365).
• Chaque PJ telechargee et rangee dans le dossier correspondant, nommee {N}_{note_id}_{nom_original_assaini} -- le numero ET le note_id assurent la correspondance directe RAG<->Mail des cette etape (pas besoin d'attendre la phase 2 pour tracer quelle PJ vient de quel mail).
• Piege a eviter (deja paye une fois avec folder_path) : certains noms de dossiers mail contiennent un vrai / (ex "AO 66/2024 E Curatif"). Assainir ce caractere (remplacer par - ou equivalent) UNIQUEMENT pour le chemin disque -- la donnee en base garde le nom exact, seul le chemin fichier est assaini.
• Resultat : une archive locale complete et exploitable meme independamment du RAG.

Phase 2 -- Resume + alimentation RAG, sur fichiers locaux

• Opere uniquement sur les fichiers deja telecharges en phase 1 -- plus aucune navigation OWA, donc rapide.
• Nouvelle table dediee attachments (PJ = entite de premiere classe, pas un champ JSON annexe sur notes) :
  • id, note_id (FK vers notes), original_filename, local_path, content_hash (dedup par contenu), extracted_text, summary, embedding_rowid (table vec dediee ou reutilisation de notes_vec avec discriminant de type).
• Objectif final explicite de Nabil : hermes-tt consulte les PJ sans jamais avoir besoin de rouvrir O365 -- une fois phase 2 terminee, la dependance a la session OWA disparait completement pour la consultation (elle reste necessaire uniquement pour l'ingestion initiale).

Cout (rappel v2, toujours valable)

Volet API : Mimo/DeepSeek couverts par le forfait Go OpenCode, embeddings Gemini sur cle Google separee (non chiffre). Volet temps : jusqu'a 45s par telechargement en phase 1, potentiellement plusieurs heures a plus d'une journee sur l'ensemble de l'arborescence -- mais ce cout ne concerne QUE la phase 1 desormais ; la phase 2 devrait etre nettement plus rapide une fois les fichiers locaux disponibles.

Infrastructure deja disponible

• GET /message/{index}/attachments -- listing leger, deja integre au backfill texte en cours (colonne notes.attachments, JSON, best-effort) -- deviendra probablement redondant une fois la table attachments dediee en place, a evaluer.
• GET /message/{index}/attachments/{filename}/text -- combine actuellement telechargement+extraction en un seul appel ; pour l'architecture 2 phases, il faudra soit isoler la partie telechargement seule (nouvel endpoint ou parametre), soit telecharger via ce endpoint en phase 1 et ignorer le texte extrait a ce stade (extraction refaite en phase 2 depuis le fichier local si le format le justifie).