# Acces boite mail O365 pro (hermes-tt) — historique et decision

## Echec V0 : hermes-mail-proxy (Graph API device code flow)
Tentative : client public officiel Microsoft ("Microsoft Graph Command Line Tools",
client_id 14d82eec-204b-4c2f-b7e8-296a70dab67e) via MSAL device code flow, pour
contourner le besoin d'enregistrement d'appli Azure AD (bloque en self-service sur
le tenant TT). Code deploye port 3060 (hermes-mail-proxy), jamais authentifie :
consentement Mail.Read/Mail.ReadWrite/Mail.Send bloque par l'admin meme sur ce
client pre-consenti. Confirme le 22/07/2026 (curl /auth/status -> authenticated:false
apres plusieurs semaines up). Container arrete et supprime le 22/07/2026, port 3060
libere. Ne pas retenter la voie Graph API sur ce tenant sans intervention admin TT.

## Decision V1 : hermes-mail-browser (session navigateur persistante)
Principe : authentification 100% humaine (Nabil, MFA inclus) via noVNC sur un
navigateur reel tournant sur le NAS (IP maison tunisienne). L'automatisation ne
fait QUE lire sur la session deja ouverte — jamais de re-authentification
automatisee, jamais de credentials stockes en clair.

Stack :
- Microsoft Edge reel (channel msedge, pas Chromium generique) — fingerprint
  Sec-CH-UA coherent avec un poste Windows corporate, reduction des heuristiques
  de detection cote Defender for Cloud Apps.
- Affichage virtuel Xvfb + x11vnc, expose uniquement en LAN via noVNC (port 8810,
  bind 192.168.100.33, AUCUN vhost DSM, AUCUN reverse-proxy).
- Edge lance en persistant (--user-data-dir sur volume monte, profil survit aux
  redemarrages) avec remote debugging port 9222 (localhost uniquement).
- API FastAPI (port 3110) se connecte au MEME navigateur via CDP
  (connect_over_cdp) — pas d'instance separee — pour lire la boite de reception.
  hermes-tt consomme cette API en lecture seule.

Scope Phase 1 (lecture seule) : liste boite de reception (expediteur, objet, date,
lu/non lu, apercu), lecture corps complet d'un mail. Aucune action d'ecriture
(envoi, suppression, deplacement) en V1.

Gestion expiration session : l'API detecte l'atterrissage sur
login.microsoftonline.com et renvoie 409 "reauthentification manuelle requise"
plutot que de tenter quoi que ce soit — Nabil rouvre noVNC, se reauthentifie,
la session persiste a nouveau.

Ports : 3110 (API interne), 8810 (noVNC, LAN uniquement). Conteneur :
hermes-mail-browser, reseau n8n, UID/GID 1026:100, volume data/ pour le profil
navigateur.

Statut : conteneur deploye et sain, en attente authentification manuelle (22/07/2026).

## Mise a jour 22/07/2026 soir — validation phase 1 complete

Bug corrige pendant la validation : premiere version de main.py ouvrait une
nouvelle connexion Playwright a CHAQUE requete. Deux requetes de test annulees
cote client (timeout curl) ont laisse des coroutines bloquees cote serveur,
qui ont ensuite bloque toute nouvelle tentative (verrou de spawn du driver
Playwright). Corrige : connexion unique partagee, ouverte au demarrage de
app (FastAPI lifespan), reutilisee pour toutes les requetes, timeout de
securite 15s sur la connexion CDP.

Piege reseau rencontre en testant : ports 3110/8810 bindes UNIQUEMENT sur
192.168.100.33 (delibere, pas de bind 0.0.0.0). Injoignable depuis un
conteneur Docker (mcp-nas) via 172.17.0.1 ou directement via 192.168.100.33
depuis un container — passer par ssh nas-host pour tout test/usage agent.

Tests reussis en conditions reelles (session Nabil authentifiee) :
- GET /auth/status -> authenticated:true
- GET /inbox?limit=5 -> expediteur/objet/heure/apercu corrects (5/5), y compris
  un mail metier Zone Sud reel
- GET /message/0 -> corps complet correctement extrait

Phase 1 (lecture seule boite de reception) fonctionnelle, prete pour usage
par hermes-tt.

Reste a faire : calibrer le 409 sur expiration reelle de session (pas encore
observe) ; evaluer robustesse des selecteurs OWA dans la duree ; envisager
V1.5 (appel API interne OWA via page.evaluate+fetch) si le DOM scraping
devient trop lent.