Page intégrée au dossier PRISME — ne pas éditer ici sans resynchroniser.

SPEC — Module Webmail / Mail Assistant

Références :

Date : 2026-04-26

Statut : Rédigée — POC mono-utilisateur à intégrer, cible production multiuser PostgreSQL planifiée

Périmètre : intégration du projet mail-assistant comme module applicatif Qwik City accessible sur webmail dans l'application agenda.

Source plan Cursor : .

Complément multiuser : décision utilisateur 2026-04-26 — production multiuser, sauvegarde d'identifiants, cache mail serveur, synchronisations IMAP backend en arrière-plan et réseau fédéré Marty.

Références Plan-Directeur :

• Suivi : §0 ; .
• Schéma : .
• Specs liées :,, , SPEC_MARTY_AMELIORATION_CONTINUE_VESPA_GPU_CLIENT.md, , (rattachement fil → prep-tech), .

Conformité au schéma directeur

Alignement code (2026-05-27)

Audit spec ↔ dépôt (grep -ri webmail sous src) — ticket #3137. Les chemins ci-dessous sont relatifs à la racine du fork calendrier.

Routes et UI

Bibliothèque webmail

Fichiers sources (hors __tests__ et *.test) : account manager, action compatibility, assistant analysis, audit log, cache invalidation, content length exceeds, credential encryption, credentials, dashboard load, db repository, field visibility, fixtures, imap sync cursors, imap sync plan, imap sync worker, legacy mapping, mark processed post, Signaux d'apprentissage réseau, Suggestions fusion local / fédéré, observability, permissions, quotas, read json body, resolve action mail keys, scenarios, security rgpd, server, sqlite groups, sync brick attachments, sync brick body preview, sync brick folder list, sync brick message envelope, sync brick thread index, Templates e-mail (sources L0–L3), types, webmail a11y, webmail data policy, webmail db schema, webmail pg pool, webmail pg repository ; doc module : .

Tests Vitest (liste exhaustive au 2026-05-27)

webmail.test ; account manager.test, credentials.test, dashboard load.test, db repository.test, fixtures.test, imap sync plan.test, legacy mapping.test, scenarios.test, server.test, sync brick attachments.test, sync brick body preview.test, sync brick folder list.test, sync brick message envelope.test, sync brick thread index.test, webmail a11y.test, webmail db schema.test ; action compatibility.test, assistant analysis.test, audit log.test, cache invalidation.test, content length exceeds.test, credential encryption.test, field visibility.test, imap smtp backend.test, imap sync cursors.test, imap sync worker.test, mark processed post.test, marty signals.test, marty suggestions.test, observability.test, permissions.test, quotas.test, read json body.test, resolve action mail keys.test, security rgpd.test, server contracts.test, sqlite groups.test, sync bricks.test, templates.test, webmail data policy.test, webmail db repository.test, webmail e2e multiuser.test, webmail pg pool.test, webmail worker integration.test ; helpers.test, mark processed route.test, webmail proposals route.test, webmail sync post body.test.

Écarts vs cette SPEC (P0 — #3137)

Prochaine passe doc (hors périmètre #3137) : renommer références HFSQL → PostgreSQL dans §3.4–§3.7 et §9.2 ; mettre à jour §3.1–§3.2 avec les chemins kebab-case et modules réels ; traiter les stubs ouverts #2988–#2991.

1. Contexte & objectif

Le projet mail-assistant doit être intégré dans l'application agenda comme un module complet de traitement webmail, accessible depuis la route Qwik City webmail.

Le POC est volontairement simple : mono-utilisateur, configuration issue de .env, persistance locale SQLite, traitement local des messages et actions QCM. La cible production évolue vers un modèle multiuser adossé à un PostgreSQL serveur (remplace SQLite et l’ancienne cible HFSQL documentée en 2026-04-26) pour les identifiants, les comptes mail, les états de synchronisation, le cache mail et les préférences de templates.

Décisions utilisateur actées dans cette demande (2026-04-26) :

• Route applicative cible : webmail.
• POC : mono-utilisateur.
• Configuration POC : .env.
• Stockage POC : SQLite.
• Production : version multiuser.
• Production : PostgreSQL comme stockage serveur du module webmail, en remplacement de SQLite (et de l’option HFSQL initiale).
• Production : sauvegarde d'identifiants mail par utilisateur, protégés côté backend et jamais exposés au client.
• Production : cache mail PostgreSQL synchronisé en arrière-plan côté backend depuis IMAP.
• Production : comparaison, mise à jour et invalidation du cache par briques pendant les synchronisations IMAP.
• Production : réseau fédéré Marty utilisé pour les suggestions et pour construire localement les templates par défaut de chaque utilisateur.
• Accès : seuls les utilisateurs Baserow authentifiés ont accès à webmail et aux routes *.

Objectif métier

Offrir un espace de traitement assisté des mails entrants : lire, regrouper, qualifier, préparer des réponses, classer, archiver, traiter les pièces jointes et générer des prompts/action plans exploitables par l'utilisateur.

Périmètre inclus

• Intégration du projet mail-assistant comme module webmail.
• Reprise de la logique QCM compacte définie dans le plan refonte_ui_qcm_ce395ce3.
• Page Qwik City avec cartes compactes, groupes, sélection multiple, toolbar sticky et navigation focus type Typeform.
• Contrats JSON stables pour propositions, scénarios, champs visibles, prompt et état traité.
• POC avec adaptateur serveur local vers SQLite et logique Python existante si nécessaire.
• Préparation de la trajectoire production multiuser.
• Stockage HFSQL multiuser pour la production : comptes, credentials chiffrés, cache mail, pièces jointes indexées, jobs de synchronisation, préférences et templates utilisateur.
• Worker backend de synchronisation IMAP indépendant du rendu Qwik.
• Boucle Marty : suggestions fédérées, scoring local, génération et amélioration des templates par défaut utilisateur.

Hors périmètre immédiat du POC

• Mutualisation multiuser complète.
• Migration complète de toute la logique Python vers TypeScript.
• Hébergement externalisé multi-tenant.
• Synchronisation temps réel entre plusieurs utilisateurs sur une même boîte.
• Automatisation d'actions destructives sans validation humaine explicite.

Hors périmètre production initiale

• Synchronisation collaborative temps réel d'un même message entre plusieurs opérateurs.
• Apprentissage fédéré qui transmettrait du contenu brut de mail ; seules des métriques, embeddings ou signaux anonymisés explicitement autorisés peuvent alimenter le réseau fédéré Marty.
• Dépendance UI directe au conteneur HFSQL : toutes les lectures/écritures passent par les routes backend *.
• Accès public, accès Guest 564 ou lecture seule anonyme à webmail.

2. Description fonctionnelle

2.1 Vue webmail

La page webmail présente une liste de messages regroupés par besoin d'action. L'utilisateur peut traiter les messages un par un ou par sélection multiple.

Comportement attendu :

• affichage compact des messages ;
• regroupement visuel par groupe calculé ;
• carte active unique pour le focus clavier ;
• sélection multiple indépendante de la carte active ;
• toolbar sticky pour les actions applicables au lot sélectionné ;
• panneau d'édition ouvert uniquement quand un champ est manquant, demandé par l'utilisateur ou nécessaire à l'arbitrage ;
• aperçu de mail, brouillon ou prompt dans une modal ;
• upload local contrôlé pour les pièces jointes à utiliser dans un prompt ou une réponse.

2.2 Groupes fonctionnels

Les groupes sont calculés côté serveur et mis en cache SQLite. Ils aident l'utilisateur à prioriser sans devenir une vérité métier permanente.

Groupes POC attendus :

• reply_needed : réponse à préparer ;
• classification : classement sans réponse ;
• archive_ready : archive possible ;
• meeting : demande ou invitation de réunion ;
• attachment_needed : document ou pièce jointe à fournir ;
• manual_review : ambiguïté ou confiance faible ;
• incompatible_action : suppression, lecture explicite ou conflit d'action.

2.3 Actions et scénarios

Les actions doivent être dérivées d'un scénario proposé, pas seulement d'une liste brute action_types.

Actions couvertes :

• réponse unifiée ;
• classement vers dossier ;
• archive vers dossier ;
• création de dossier ;
• réponse réunion ou proposition de réunion ;
• ajout de pièce jointe ;
• drapeau / suivi ;

Synthèse PRISME — 1201 lignes dans la source complète.

Voir aussi PRISME : Vision module Webmail · README module