Former mon Gilbert (style perso)

Deux profils-types se croisent sur cette feature :

• L'utilisateur final qui forwarde régulièrement à Gilbert et trouve que les brouillons sonnent « trop générique »ou « trop ChatGPT ». Il veut que Gilbert ouvre ses mails comme lui, ferme comme lui, garde sa longueur habituelle. Une seule action sur l'UI et c'est calé.
• L'IT lead qui déploie Gilbert à une équipe commerciale ou support, et veut que chaque membre conserve son identité de plume. Tu pointes les membres vers la carte, ils cliquent une fois, et leurs forwards suivants sortent dans leur voix sans aucune config supplémentaire.

Si tu n'as pas encore configuré le forward-to-Gilbert, commence par cette page : l'entraînement n'a d'intérêt que si tu utilises ensuite la voix apprise.

Trois étapes, déclenchées par un clic. Délai typique end-to-end : 30 à 60 secondes selon le provider LLM de ton workspace.

1. Scan et tri des Sent. Le worker Inngest gilbert-user-style-train (event gilbert.user_style.train) appelle l'API Gmail avec tes tokens OAuth perso et liste tes 100 derniers messages dans SENT. Il écarte les transferts et les mails que tu t'es envoyés à toi-même, plafonne à 3 mails par destinataire principal pour qu'un correspondant très sollicité ne fasse pas tout ton style, puis lit les corps par lots et s'arrête dès qu'il en tient 30 exploitables, 60 lectures au plus. Chaque corps est nettoyé du texte cité (l'historique du mail auquel tu réponds) ; les mails trop courts une fois ce nettoyage fait (moins de 120 caractères) sont écartés. Si rien ne passe ces filtres, Gilbert repart des mails disponibles. Pas de scan d'Inbox, pas de lecture des mails reçus, uniquement ce que tu as écrit.
2. Extraction par LLM workspace. Les corps retenus (jusqu'à 30) sont envoyés à un seul prompt au LLM du workspace, résolu via getLLMClient(supabase, workspaceId, { tier: "smart" }). C'est ton workspace qui paie ces tokens (BYOLLM Anthropic / Google / OpenAI), tracké via logUsage(pipeline: "user_style_train"). Le parse est sécurisé par generateObject + un schéma Zod strict : le profil retourné est structuré, pas du texte libre.
3. Persistance du profil. Le résultat est upserté dans gilbert.user_style_profile avec user_id = auth.uid() comme PK. Une seule row par utilisateur, partagée par tous tes workspaces. Chaque ré-entraînement remplace la précédente (pas d'historique persisté côté row, juste un trained_at).

Le profil est un JSON structuré, validé par Zod avant insertion. La carte l'affiche une fois l'entraînement terminé, et tu peux corriger à la main ce qui te gêne. Voici concrètement les champs captés :

Exemple de profil construit pour un compte commercial typique :

{
  "language": "fr",
  "formality": "vouvoyer",
  "registers": {
    "professional": "Vouvoiement, formules neutres, phrases courtes et actionnables.",
    "familiar": "Tutoiement, ton direct, blagues internes tolérées."
  },
  "formulas": {
    "professional": {
      "greeting": "Bonjour <Nom>,",
      "closing": "Bien cordialement,"
    },
    "familiar": { "greeting": "Salut <Nom>,", "closing": "À très vite," }
  },
  "signature_template": "Sophie Durand\nImo Plus",
  "frequent_contacts": [
    { "email": "marc@banque-x.fr", "name": "Marc", "tone": "professionnel", "topic": "financements" }
  ],
  "recurring_topics": ["compromis", "états des lieux", "quittances"]
}

Chacun ouvre et ferme ses mails à sa façon, et pas de la même façon selon la personne en face. Gilbert retient donc deux paires de formules : celle que tu emploies avec les clients, celle que tu emploies avec les collègues proches. Quatre champs sur la carte te laissent les corriger à la main : « Début de mail avec les clients », « Fin de mail avec les clients », et les deux équivalents pour les collègues proches.

Dans une formule d'appel, écris <Nom> à la place du nom du correspondant : Gilbert le remplace au moment de rédiger (« Bonjour Madame <Nom>, »). Ne mets pas ton propre nom dans la formule de fin, ta signature est apposée juste après.

Côté signature, Gilbert reconnaît plusieurs signatures dans tes mails envoyés et choisit celle de l'entité au nom de laquelle tu réponds, d'après l'adresse qui a reçu le mail et le correspondant. Si tu écris tantôt pour une société, tantôt pour une autre, chaque réponse part sous le bon nom. Quand rien ne permet de trancher, Gilbert applique ta signature la plus fréquente.

L'apprentissage lit tes mails envoyés. Ce qu'il ne peut pas deviner, tu peux le dire toi-même, de deux façons.

Mes consignes, sur la même carte : quelques lignes que Gilbert applique à tous tes brouillons, par exemple « Commence toujours par Bonjour Madame ou Bonjour Monsieur suivi du nom ». Elles valent pour chaque brouillon, dans tous tes espaces, et restent en place quand tu relances l'entraînement. Jusqu'à 1 000 caractères. Les adresses e-mail sont retirées à l'enregistrement, et la carte te le signale. Une consigne ne l'emporte jamais sur la règle de ne rien inventer : quand une information manque, Gilbert laisse un blanc à compléter.

« À refaire », depuis Gmail, pour un seul brouillon qui ne te convient pas :

1. Ouvre le brouillon et écris tout en haut, avant la formule d'appel, une ligne qui commence par Retour :, par exemple « Retour : dis Bonjour Monsieur Dupont ». Une ligne par remarque.
2. Pose sur le fil le libellé « À refaire », rangé sous le nom de ton assistant : dans Gmail, il s'affiche comme le nom de ton assistant suivi de /À refaire.
3. Dans les minutes qui suivent, Gilbert réécrit le brouillon en tenant compte de tes remarques, garde les destinataires et l'objet que tu avais laissés, retire le libellé et pose « À vérifier ».

C'est l'invariant critique de la feature, et le tableau principal de la page (carte violette) l'affiche en clair :« Visible et utilisé uniquement par toi : aucun autre membre du workspace ne voit ton style ».

• RLS SELECT strict. La policy sur gilbert.user_style_profile n'autorise SELECT que si user_id = auth.uid(). Pas d'exception admin, pas de override pour les owners du workspace. Un admin qui dumperait la table en SQL via l'UI ne verra que son propre profil.
• Writes via service_role uniquement. Le worker Inngest tourne en service_role et upsert le profil. Aucun chemin client ne peut écrire ou modifier le profil d'un autre user.
• Global per-user, pas per-workspace. Le profil est keyé sur user_id. Si tu es membre des workspaces acme-direction et acme-support, les deux workspaces draftent dans ta voix avec la même row. C'est voulu : ton style est une propriété de toi, pas d'une org.
• Pas de partage cross-workspace au-delà de toi. Pierre dans le même workspace ne voit pas ton profil et ne peut pas drafter dans ta voix. L'invariant cross-user de Gilbert tient (cf. CASA Tier 2).

Le profil ne se ré-entraîne pas tout seul : c'est volontaire, pour éviter de cramer du quota LLM sur des refreshes invisibles. À relancer manuellement dans ces cas :

• Tu changes de poste ou d'équipe. Nouveau registre (plus formel chez un grand compte, plus direct chez un client startup), nouvelles formules, nouveau ton.
• Tu sens que les brouillons dérivent. Les drafts ne sonnent plus comme toi : souvent parce qu'un point de rupture récent dans ta manière d'écrire (nouveau poste, nouveau ton) n'est pas encore capté. Le plafond de 3 mails par destinataire réduit l'effet d'un correspondant ponctuellement très sollicité, sans l'annuler.
• Tu as fait un « grand ménage » de ton style. Tu as consciemment changé tes ouvertures, raccourci tes mails, passé du vouvoiement au tutoiement avec l'équipe, relance pour que Gilbert se cale sur la nouvelle norme.

• Forward-to-Gilbert : le principal consommateur du profil. Sans forward configuré, entraîner ton style ne sert à rien.
• Workspaces : pour configurer le provider LLM (BYOLLM) qui exécute l'entraînement.
• Intégrations : pour connecter Gmail au niveau de ton compte perso, prérequis du scan des Sent.