runbook: hermes-mail-browser search ne filtre pas par date reelle (30/07/2026)

hermes-tt/mail-o365-search-pas-de-filtre-date.md

@@ -0,0 +1,35 @@
+# hermes-mail-browser -- /search ne filtre pas par date reelle de reception
+
+**Date** : 30/07/2026
+**Contexte** : tentative d estimation du volume de mails TT depuis 2024 (projet nyora-notes-TT / RAG personnel mail).
+
+## Constat
+
+Le endpoint `/search?q=...` de hermes-mail-browser fait du matching texte brut sur la requete OWA,
+pas un filtre sur la date reelle de reception. Test : q=received:2024 a retourne des mails recus
+en 2025 (12/08/2025, 22/09/2025, 26/02/2025, 31/01/2025) simplement parce que 2024 apparaissait
+dans le sujet (numeros d AO type AO 76/2024, N066/2024). OWA traite received:2024 comme un
+terme de recherche libre dans ce contexte, pas comme un operateur de plage de dates fiable via cette API.
+
+## Autre limite observee
+
+/folders retourne count:0, folders:[] ou time out -- coherent avec le bug de staleness deja
+documente le 24/07 (liste virtualisee OWA non remontee sans navigation fraiche forcee). Pas de comptage
+fiable par dossier via cette route en l etat.
+
+## Cout reel
+
+Chaque appel /search prend ~35-40s pour 5 resultats (automatisation navigateur reelle sur OWA,
+pas une API rapide). Inadapte a une iteration/pagination pour estimer un volume total -- risque de
+degrader ou perdre la session authentifiee live (auth manuelle noVNC, MFA).
+
+## Recommandation
+
+Pour un comptage de volume par dossier/periode : lire directement le compteur natif OWA (volet dossiers,
+ou Filtrer > par date) via noVNC (port 8810) -- 30 secondes, fiable, zero risque sur la session.
+Ne pas utiliser /search avec un mot-cle annee en attendant un filtre de date reel.
+
+## A faire si le filtre date devient necessaire
+
+Verifier si OWA supporte un operateur de date fiable dans son moteur de recherche natif (ex.
+received>=01/01/2024) teste directement dans l UI avant de l attendre de cette API generique.