2.0 KiB
nyora-notes-tt -- Pieces jointes : chantier dedie futur, cible plutot qu'exhaustif
Date : 31/07/2026
Decision
L'extraction du texte des pieces jointes ne fait PAS partie du backfill texte actuellement en cours (205 dossiers, 2024-2026). C'est un chantier separe, a lancer une fois le backfill texte stabilise.
Infrastructure deja disponible (rien a construire cote hermes-mail-browser)
GET /message/{index}/attachments-- liste les pieces jointes d'un message (leger, pas de telechargement).GET /message/{index}/attachments/{filename}/text-- telecharge (via CDP, jusqu'a 45s d'attente -- pas de gestion de telechargement native sur un navigateur pilote a distance) puis extrait le texte (extract_text_from_file, PDF/Office geres).- Equivalents
/search/message/attachments*pour un contexte de recherche.
Pourquoi pas maintenant
- Cout : jusqu'a 45s par piece jointe telechargee. Applique a toutes les PJ de tous les messages, ca ralentirait significativement chaque dossier (les AO a plusieurs lots ont souvent une PJ par lot).
- Memoire a deux vitesses : ajouter cette capacite en cours de backfill laisserait les dossiers deja traites (Veille, Consultations, Medenine...) sans contenu de PJ, contrairement aux dossiers traites apres l'ajout -- incoherence de qualite dans le corpus.
Approche retenue pour le futur chantier
Cible, pas exhaustif. Pas de balayage systematique de toutes les PJ. A definir avec Nabil : quels dossiers/types de contenu ont une vraie valeur a extraire (grilles d'evaluation AO, notifications PDF de resultats) versus les PJ a faible valeur (signatures, logos) qui ne justifient pas le cout de 45s/telechargement.
Piste d'implementation (a affiner le jour venu)
Pour chaque message traite, appeler d'abord /attachments (leger) pour verifier s'il y a des PJ AVANT de decider si un telechargement+extraction est justifie -- eviter de payer le cout de verification lourde sur les messages qui n'en ont pas, et le cout de telechargement sur les PJ hors-cible.