Forward-to-Gilbert (Assistant Email)

Cette page s'adresse à l'équipe ITqui déploie Gilbert pour des collègues opérationnels (commerciaux, gestionnaires, support client). L'utilisateur final n'a presque rien à apprendre. Toi, tu configures une fois la forward address au niveau du workspace, tu autorises les membres à l'utiliser, et chaque membre forwarde depuis sa boîte habituelle.

Si tu cherches plutôt à embarquer Gilbert comme un chatbot dans ton produit, lis Embed iframe. Pour des tâches LLM planifiées par cron (briefing matinal, code review hebdo), lis Routines.

C'est le point à comprendre avant de configurer quoi que ce soit. Le forward email est multi-tenant par design :

• Le workspace porte le contexte. C'est lui qui détient l'adresse de forward (solve-ai--acme-direction@solveholding.com), la signature template, le mode de sortie (réponse directe ou brouillon Gmail), le rate cap, et la clé LLM (BYOLLM).
• Le membre porte l'exécution. C'est son identité (auth Gilbert), ses tokens OAuth Gmail/Calendar perso, et son historique de forwards. Quand Gilbert répond par mail, il signe avec la signature du workspace mais utilise le profil de style du membre (voir Former mon Gilbert).

Conséquence concrète : une même adresse de forward peut servir 5 membres d'une même équipe. Marie forwarde, Gilbert répond avec le style de Marie ; Pierre forwarde, Gilbert répond avec le style de Pierre. Les deux signent avec la signature de l'équipe.

Trois minutes, à faire une seule fois par workspace. Pré-requis : être admin du workspace.

1. Ouvre /console/workspaces/<id>/mails. Le hero affiche l'adresse de forward dérivée du nom de l'assistant et du slug du workspace, par exemple solve-ai--acme-direction@solveholding.com pour un assistant par défaut sur le slug acme-direction(le préfixe suit le nom si l'assistant est personnalisé en marque blanche). Si la row gilbert.forward_addresses n'existe pas encore, un admin peut la provisionner depuis la page : Gilbert crée alors la vraie adresse que le webhook Postmark saura résoudre.
2. Renommer l'assistant fait tourner l'adresse. Si tu personnalises ou changes le nom de l'assistant (y compris un retour au nom par défaut) après avoir déjà provisionné une adresse, Gilbert en calcule automatiquement une nouvelle au prochain passage d'un admin sur cette page : rien n'est supprimé, l'ancienne adresse continue de router normalement. Mets à jour tes filtres de transfert automatique (règle Gmail/Outlook) vers la nouvelle adresse quand tu renommes : sinon tes mails continuent de transiter par l'ancienne, ce qui fonctionne toujours mais ne reflète plus la marque actuelle.
3. Règle la signature template (le bloc qui termine chaque mail) et le mode de sortie :
   • direct_reply: Gilbert répond par mail au sender, en te mettant en copie. Idéal V1 pour démarrer (pas besoin d'OAuth Gmail).
   • gmail_draft : Gilbert crée un brouillon dans ton Gmail (OAuth Gmail du membre requis via /console/me/integrations). Tu le retrouves dans Brouillons, adressé à toi-même en V1. Corrige le champ À :vers l'expéditeur original avant d'envoyer. Si le membre n'a pas connecté Gmail, le run est marqué skipped:no_gmail_oauthet rien n'est livré.
   • both : Gilbert envoie la réponse email via Postmark et crée un brouillon Gmail (OAuth requis). Utile pour garder une trace dans la boîte du membre.
4. Règle le rate cap horairepar défaut (10/h V1). Empêche un loop ou un membre qui flood l'adresse de cramer ton quota LLM.
5. Autorise les membres qui peuvent forward. Le tableau Membres sur la même page liste tous les membres du workspace avec un toggle can_forward. Coche les membres concernés.
6. Cas spécial : email de login ≠ email pro. Si un membre se connecte à Gilbert avec son compte Google perso mais qu'il forwarde depuis son email pro, set forward_alias_email côté membership pour que le webhook matche correctement.

Si tu préfères piloter en SQL (admin avancé / Supabase Studio) :

-- Cas A : ton email Gilbert = ton email pro
-- Pas besoin d'alias séparé, le lookup tombe sur auth.users.email.
UPDATE gilbert.workspace_members
SET can_forward = true, forward_alias_email = NULL
WHERE workspace_id = '<workspace-uuid>'
  AND user_id = '<user-uuid>';

-- Cas B : ton email Gilbert (login Google perso) ≠ ton email pro
-- Set forward_alias_email pour matcher le From entrant.
UPDATE gilbert.workspace_members
SET can_forward = true,
    forward_alias_email = '<email-pro>'
WHERE workspace_id = '<workspace-uuid>'
  AND user_id = '<user-uuid>';

Côté membre, c'est 60 secondes :

1. Il reçoit un magic link Gilbert par mail (voir invitations workspace), clique, atterrit sur /console connecté.
2. Tu lui demandes sa signature exacte (impératif : tu la lui demandes en direct, pas par email rétro-actif, sinon elle dérive). Tu la rentres dans le champ signature du workspace, ou tu l'y guides sur l'UI.
3. Il met l'adresse de forward en contact dans son client mail sous le nom « Gilbert ». Plus jamais à la retaper.
4. (Optionnel V1, requis V1.5) Il connecte Gmail via /console/me/integrations. Sans ça, Gilbert répond par mail (mode direct_reply). Avec ça, Gilbert peut drafter dans son Gmail directement.

L'ergonomie tient en un geste. Tu reçois un mail, tu cliques « Transférer », destinataire = solve-ai--<workspace>@solveholding.com, et tu écris en haut du corps du mail ce que tu veux répondre. Exemple :

À : solve-ai--acme-direction@solveholding.com
De : marie@acme-immo.fr
Sujet : Tr: Demande de visite · 12 rue de Lyon

Réponds-lui qu'on peut faire jeudi 14h ou vendredi 10h, et qu'on a besoin
de sa pièce d'identité avant la visite.

--- Forwarded message ---
De : Sophie L. <sophie.l@gmail.com>
À : marie@acme-immo.fr
Sujet : Demande de visite · 12 rue de Lyon

Bonjour,
J'ai vu votre annonce sur SeLoger pour le T3 rue de Lyon.
Possible de visiter cette semaine ?
Sophie

Tu envoies. Sous 90 secondes, Gilbert te renvoie un brouillon pro polish. En mode direct_reply, il arrive par mail dans ta boîte. En mode gmail_draft, il apparaît directement dans tes brouillons Gmail (OAuth Gmail requis).

Pour les curieux et les IT qui auditent. Le chemin d'un forward du moment où il quitte ta boîte jusqu'au brouillon reçu :

1. MX → Postmark Inbound. Le DNS de solveholding.comroute l'adresse de forward vers Postmark, qui dépose le mail dans son endpoint inbound.
2. Webhook signé. Postmark POST /api/webhooks/email/inboundavec une signature qu'on vérifie côté serveur. Replay window de 5 minutes.
3. Lookup membre. La RPC SECURITY DEFINER gilbert.lookup_forwarding_user(workspace_id, from_email) résout le Fromdu forward vers l'user_id du membre (via forward_alias_email ou auth.users.email). Si le membre n'est pas autorisé, le forward est rejeté avec un mail d'erreur.
4. Inngest worker gilbert-email-inbound-polish (3 retries avec backoff exponentiel pour les 5xx Anthropic / Postmark intermittents). Idempotency via Message-ID dans forward_processed_ids.
5. LLM BYOLLM. Le worker appelle getLLMClient(supabase, workspaceId, { tier: "smart" }) pour respecter la config LLM du workspace. Un workspace sur Google Gemini paie Google ; un workspace sur Anthropic paie Anthropic. Pas de bypass silencieux vers la clé centrale Gilbert.
6. Output. En mode direct_reply, la réponse est envoyée via Postmark (EmailReplyTransport). En mode gmail_draft, le transport fonctionne en capture-only (pas d'envoi Postmark) et gmailCreateDraft (Gmail API) crée le brouillon dans le compte Gmail du membre (OAuth Gmail connecté obligatoire). Le To est adressé à toi-même (V1). En mode both, Postmark envoie la réponse ET un brouillon est créé dans Gmail. Le run est loggé dans gilbert.forward_runs.

Trois choses à savoir si ton service achats ou ton DSI te pose la question :

• RLS strict sur les runs. gilbert.forward_runsn'est lisible que par executing_user_id = auth.uid() (le membre qui a forwardé) ou par un admin du workspace. Un autre membre du même workspace ne voit pas tes forwards.
• Chiffrement AES-256-GCM au repos. Les 3 colonnes sensibles de forward_runs (subject_enc, intent_excerpt_enc, draft_preview_enc) sont chiffrées en DB sous FORWARD_ENC_KEY. Un dump de la base sans la clé n'est pas lisible. Le from_email reste en clair (nécessaire pour le lookup).
• Tokens OAuth perso. Si tu actives le mode gmail_draft, les tokens Google du membre sont chiffrés sous GOOGLE_TOKEN_KEYet scopés à son user, jamais partagés avec d'autres membres du workspace.

Plus de détails sur la posture sécurité globale (CASA Tier 2 ASVS 64/86 ✅) sur le changelog 28 mai 2026.

La V1 fait volontairement moins que ce qui est possible : on déploie progressivement pour éviter les surprises.

• Le brouillon n'arrive jamais.Vérifie d'abord tes spam : le premier mail d'une nouvelle adresse atterrit parfois là. Marque-le « Pas spam » et ajoute Gilbert à tes contacts. Si vraiment rien après 5 min, regarde le statut dans /console/workspaces/<id>/mails : la timeline affiche received, polishing, delivered, error avec le message.
• « Forward rejeté : membre non autorisé ». Le From du forward ne matche aucun membre du workspace avec can_forward = true. Si tu te connectes à Gilbert avec un email différent de ton email pro, il faut set forward_alias_email sur ta membership (voir Setup admin).
• Gilbert hallucine des faits. Vérifie ton intent line. Si tu écris « réponds-lui » sans préciser, Gilbert improvise à partir du contexte. Sois précis : « réponds OK pour jeudi 14h et demande son RIB ».
• Le ton n'est pas le tien. Lance « Former mon Gilbert » sur la page Assistant Email : la carte violet scanne tes 30 derniers Sent Gmail et construit un profil de style per-user. Tu peux le relancer aussi souvent que tu veux ; chaque run remplace le précédent.
• Rate limit hit (429).Le cap par défaut est 10 forwards / heure par membre. Tu peux le bumper côté workspace settings, mais si tu hit régulièrement le cap, c'est souvent le signe d'un loop (tu forwardes Gilbert qui répond, ton client mail re-route, etc.). Audit la chaîne avant de bumper.