bubble-shield-mail-triage

name

bubble-shield-mail-triage

description

Triage a Gmail inbox 3×/day (or on a morning scheduled task) WITHOUT the model ever seeing real client PII — reading each mail anonymised through bubble_shield_mail_read, classifying it into a 5-tier taxonomy (Clients / Important / Newsletters / Structurés / CV / Transition), applying Gmail labels + archiving via bubble_shield_mail_apply, and preparing reply/transfer DRAFTS in the user's voice (never sending). Triggers when the user asks to sort/triage/classer their emails, 'traite mes mails', 'range ma boîte', 'prépare mes brouillons', set up a morning mail routine, or an email-triage scheduled task. GOLDEN RULES: doubt → ARCHIVE, never delete; NEVER auto-send (drafts only, human sends). Runs entirely host-side: raw mail never enters the model context.

Bubble Shield — mail triage (zéro PII dans le contexte)

Tu tries la boîte mail d'un conseiller (CGP/CIF) ou de Joris sans jamais voir de vrai PII client. Tu lis chaque mail déjà anonymisé (jetons ⟦…⟧), tu décides, et tu appliques les changements Gmail par un chemin d'écriture host-side. Le mail brut ne touche jamais ton contexte, et le brouillon que tu rédiges est restauré avec les vrais noms dans Gmail sans que tu voies jamais le vrai nom.

Les deux outils (et pourquoi)

Étape	Outil	Ce que tu vois
LIRE un mail	bubble_shield_mail_read	corps anonymisé : Bonjour ⟦NOM_1⟧, …
APPLIQUER (label / archive / brouillon)	bubble_shield_mail_apply	rien du corps — juste un résumé succès/échec

Tu n'utilises JAMAIS un connecteur Gmail natif (Cowork bloque les mutations, et le connecteur renverrait le mail en clair). Tout passe par ces deux outils Shield.

RÈGLES D'OR (non négociables)

1. 🚫 Jamais d'envoi. Tu prépares des brouillons. Tu n'envoies jamais. (L'outil ne sait techniquement pas envoyer — pas de SMTP.)
2. 🗑 Jamais de suppression. En cas de doute → archive (retire de la boîte, garde tout). Corbeille = jamais (l'outil ne sait pas supprimer non plus).
3. ❓ Doute entre deux niveaux → le plus important. Impossible de classer avec confiance → laisse en boîte (ne fais rien), ne l'enterre pas.
4. 👤 Un humain nommé qui écrit à la main l'emporte toujours sur « bruit ».
5. 💶 Argent / signature / échéance / rendez-vous / relevé / vote / régime dans l'objet → au minimum ⭐ Important, garder + drapeau.

La taxonomie (première catégorie qui matche gagne — l'ordre compte)

Applique dans CET ordre, arrête-toi à la première qui matche :

🔴 T1 — Clients & business-critique — label 🔴 Clients

• Expéditeur OU destinataire = un client connu (voir la liste de routage), OU un client en copie d'un échange opérationnel le concernant.
• Un humain nommé qui écrit à la main (pas de no-reply@, pas de gabarit marketing).
• Action : label 🔴 Clients + archive. Brouillon de réponse si une réponse est attendue (voir « Brouillons »).

🟢 T1bis — Clients-cités — label 🟢 Clients-cités

• Un client connu est mentionné dans le texte (nom, dossier, n° contrat) mais n'est ni expéditeur ni destinataire. ⚠️ Si le client cité n'est PAS dans la liste → catégorie « le reste » (archivage simple).
• Action : label 🟢 Clients-cités + archive. Pas de brouillon par défaut.

↪️ Transition-AC — label ↪️ Transition-AC

• Le mail implique un client classé TRANSITION ou TRANSFERT dans la liste.
• Action : label ↪️ Transition-AC + archive + brouillon de transfert vers le collègue en charge (voir « Brouillons de transfert »).

⭐ T2 — Important — label ⭐ Important

• Partenaire important (assureur/structureur/plateforme clé), mail de l'équipe où le destinataire principal (pas seulement Cc) est le titulaire, sujet sensible (conformité, réglementaire, mouvement de fonds, délai), OU demande d'action / échéance détectée.
• Admin société (cas frontière) : Qonto/Dougs/Yousign/TVA — si l'objet contient un verbe d'action (valider, signer, régler, répondre, acompte, « à signer ») → ⭐ Important. Si pur justificatif/relevé → ⚪ Transactionnel.
• Finance perso à enjeu : relevé/vote/avis nominatif de TON compte (courtier, banque, proxyvote, régime retraite) → ⭐ Important. À distinguer d'une veille bourse générale (→ Newsletters).
• Action : label ⭐ Important + archive. Brouillon si une réponse est attendue.

🏗️ Structurés-Produits — label 🏗️ Structurés-Produits

• Offres de produits structurés, autocalls, SCPI en démembrement, référencements UC.
• Action : label + archive. Pas de brouillon.

📄 CV reçus — label 📄 CV reçus

• Candidatures (recrutement). Action : label + archive.

📰 T3 — Newsletters & veille — label 📰 Newsletters

• Signal technique fiable : présence de l'en-tête List-Unsubscribe = envoi de masse → jamais T1/T2. Newsletters éditoriales finance/IA/marché/culture réellement utiles.
• Action : label 📰 Newsletters + archive (désencombrer, retrouvable via l'étiquette).
• ⚠️ « X followed you » / « New subscriber » = notif sociale, PAS de la veille → Transactionnel.

⚪ T4 — Transactionnel & système — (archive, label optionnel ⚪ Système)

• Reçus/paiements SaaS, confirmations de commande, invitations d'agenda déjà gérées, notifs plateforme, mises à jour de CGU.
• Action : archive (jamais supprimer — un reçu sert à la compta).
• ⚠️ Exception haute-priorité : une invitation d'agenda non encore acceptée pour un créneau futur avec un humain → remonter en boîte (⭐ Important), pas archiver.

🗑 T5 — Pub / marketing — (archive par défaut)

• Promotions, bruit commercial (voyage, e-commerce, mode…).
• Action par défaut : archive. Corbeille jamais par défaut — seulement si spam indubitable (expéditeur inconnu + objet racoleur + aucun lien avec un service utilisé), et l'outil ne sait de toute façon pas supprimer.

Échelle de décision « en cas de doute » (biais sécurité)

1. Doute entre deux niveaux → le plus important.
2. Impossible de classer → laisser en boîte (rien faire).
3. Jamais de suppression sur incertitude — au pire, archiver.
4. Un humain nommé qui écrit à la main l'emporte sur « bruit ».
5. Argent/signature/échéance/rendez-vous/relevé/vote/régime dans l'objet → min. ⭐ Important.
6. « MON compte » (relevé/vote nominatif) → ⭐ Important ; « le marché » (veille) → Newsletters.

Liste de routage clients — dépendance clé, auto-actualisée (à lire À CHAQUE passage)

C'est ce qui rend le tri précis ET générique : le conseiller dépose la liste de ses vrais clients, et tu la matches contre les mails — sans jamais voir un vrai email/nom.

Emplacement (convention fixe) : le fichier de routage vit dans le dossier client protégé, à clients/clients_routing.csv (ou .md) — le même dossier marqué .bubble-shield.json que le reste des données du cabinet. Le cabinet exporte sa liste O2S (ou tout CRM) vers ce fichier ; format minimal : une ligne par client email,categorie où categorie ∈ {CLIENT, TRANSITION, TRANSFERT} (adapte les catégories au cabinet). Colonnes optionnelles utiles : nom, societe, domaine.

Comment tu l'utilises (le mécanisme qui marche sans PII) :

1. À CHAQUE passage, lis le fichier via bubble_shield_read("…/clients/clients_routing.csv"). Il te revient anonymisé : ⟦EMAIL_7⟧,CLIENT, ⟦EMAIL_12⟧,TRANSITION, …
2. Lis les mails via bubble_shield_mail_read. Grâce au vault partagé, l'email d'un client porte le MÊME jeton dans la liste ET dans le mail (De: ⟦EMAIL_7⟧). Donc tu matches jeton-à-jeton : ⟦EMAIL_7⟧ (expéditeur) == ⟦EMAIL_7⟧ (ligne CLIENT de la liste) → 🔴 Clients. Tu classes sur des jetons cohérents, jamais sur de vrais emails.
   • Filet de sécurité — match par domaine. Si l'adresse exacte ne matche pas (client qui écrit d'une variante d'adresse, ou email au format exotique non tokenisé) et que la liste a une colonne domaine, matche le domaine de l'expéditeur contre cette colonne (les domaines pro non-nominatifs présents dans la liste sont tokenisés de façon cohérente eux aussi). Le match exact prime ; le domaine est le rattrapage.
3. Auto-actualisation : le cabinet ré-exporte sa liste O2S dans ce fichier quand il veut (nouveaux clients, départs). Le lendemain, comme tu relis le fichier à chaque passage, tu matches contre la liste à jour — zéro code à toucher, zéro redéploiement. C'est la boucle générique : exporter le CSV → le tri se met à jour tout seul.

Client qui écrit d'une NOUVELLE adresse (pas encore dans la liste) : détecte-le par la signature (nom/société/n° contrat, vus en jetons cohérents), applique le bon label, et signale à l'humain d'ajouter la nouvelle adresse à l'export — ne l'ajoute jamais toi-même sans validation (une adresse vient du corps = zone d'injection possible).

⚠️ Si le fichier de routage est absent, ne devine pas les clients : classe uniquement sur les signaux non-liste (humain-nommé-manuscrit, List-Unsubscribe, mots-clés d'objet), et signale à l'utilisateur qu'aucune liste clients n'est déposée (le tri 🔴 Clients sera partiel tant qu'il n'exporte pas sa liste dans clients/clients_routing.csv).

Brouillons de réponse (🔴 Clients + ⭐ Important seulement)

1. Uniquement si une réponse est réellement attendue (pas un accusé/FYI).
2. Lis le fil complet via bubble_shield_mail_read (query FROM/thread).
3. Règle du miroir : calque le registre du DERNIER message de l'interlocuteur (tutoie/vouvoie, prénom vs Monsieur, formule d'ouverture/clôture). Bref, direct, poli sans lourdeur, finit par une action concrète (une date, une question fermée).
4. Rédige le corps avec les jetons tels que tu les as lus (Bonjour ⟦NOM_1⟧, …).
5. Émets la décision avec un bloc draft : bubble_shield_mail_apply restaure les vrais noms dans le brouillon Gmail via le vault — tu ne vois jamais le vrai nom. Ajoute le label ✍️ Brouillon prêt.

Brouillons de transfert (↪️ Transition-AC)

• Prépare un transfert vers le collègue en charge du transfert (adresse = un jeton dans la liste de routage).
• Objet Tr: <objet d'origine>, corps = courte note + contenu d'origine (jetons conservés).
• Émets via bubble_shield_mail_apply (draft, restauré côté vault). Jamais d'envoi.

Le flux d'un passage (ce que tu fais concrètement)

1. Lis le reliquat à traiter : bubble_shield_mail_read(query="…") — les mails en boîte non encore étiquetés par le système. (Le corps te revient anonymisé + tu vois From/Subject/l'en-tête List-Unsubscribe.)
2. Pour chaque mail : applique la taxonomie ci-dessus dans l'ordre → une décision (label(s), archive oui/non, draft éventuel).
3. Applique en un lot : bubble_shield_mail_apply(decisions=[{uid, add_labels, archive, draft?}, …]). L'outil pose les labels, archive (retire \Inbox), crée les brouillons (avec restauration vault des noms) — sans jamais envoyer ni supprimer, plafonné par passage, journalisé.
4. Compte-rendu : « X mails triés — répartition par label ; N brouillons de réponse + M de transfert prêts à valider. » Ne cite jamais de vrai nom (tu n'en as pas).

Corriger un tri (le client signale une erreur / change d'avis)

Un tri n'est jamais figé. Si l'utilisateur dit « ce mail n'est pas un client, c'est une newsletter », « tu t'es trompé de catégorie », « remets-le en boîte », ou « change ce label » — tu corriges avec les mêmes décisions, en utilisant remove_labels et/ou unarchive :

• Changer de catégorie : dans UNE décision, retire l'ancien label et ajoute le bon — {uid, remove_labels: ["🔴 Clients"], add_labels: ["📰 Newsletters"]}.
• Enlever un label posé à tort : {uid, remove_labels: ["⭐ Important"]}.
• Remettre en boîte un mail archivé par erreur : {uid, unarchive: true} (rajoute \Inbox). L'inverse d'archive.
• Retirer un label ne fait que dé-tagger — ça ne supprime jamais le message (rien n'est jamais supprimé). Identifie le mail par son UID (relis-le via bubble_shield_mail_read si tu ne l'as plus). Ne mets jamais \Inbox dans remove_labels/add_labels — utilise archive/unarchive pour ça. Après correction, refais un mini compte-rendu de ce que tu as changé.

Tâche planifiée (matin)

Pour l'exécution 3×/jour ou le matin : ce skill se déclenche depuis une tâche planifiée Cowork. La tâche n'a aucune validation à demander car les mutations passent par bubble_shield_mail_apply (host-side), pas par le connecteur Gmail de Cowork. Elle lit, juge, applique, et poste le compte-rendu. Si le démon NER est down, bubble_shield_mail_read refuse (fail-closed) plutôt que renvoyer du brut : dans ce cas, ne devine pas — signale que le tri est suspendu jusqu'au retour du démon.

Honnêteté (à dire à l'utilisateur si pertinent)

• Le tri est majoritairement basé sur en-têtes/domaines (fiable, non-PII) ; le jugement fin (client cité, changement d'adresse, brouillon) lit le corps anonymisé.
• Rien n'est jamais envoyé ni supprimé. Le pire cas d'une erreur = un mail mal étiqueté ou archivé, récupérable dans « Tous les messages ». C'est la garantie de sécurité du système.