Workspaces

Cette page s'adresse à l'équipe IT qui déploie Gilbert dans une entreprise B2B. Vous configurez Gilbert pour vos équipes opérationnelles (commerciaux, gestionnaires, support) qui ne touchent pas à la config.

Exemple concret. Une agence immobilière déploie Gilbert : elle crée un workspace « Acme Immo Paris » qui contient sa routine Gmail (draft quotidien de réponses), son agent embed sur le site public, sa clé Google Gemini (l'agence a déjà un Google Workspace avec billing Cloud, autant rationaliser). Six mois plus tard, l'agence rachète un confrère : nouveau workspace « Acme Immo Lyon », nouvelle clé LLM, isolation totale des données clients entre les deux entités.

Si vous êtes développeur intégrateur (vous embarquez Gilbert dans votre propre SaaS), lisez plutôt Console B2B et Embed iframe.

Le workspace est le tenant de Gilbert : la frontière de tout ce qui appartient à une équipe. Si vous connaissez déjà un de ces modèles, le mapping est direct :

Le workspace est la frontière des données d'équipe. Aucune donnée workspace n'est partagée entre workspaces, même pour un même utilisateur membre des deux : les clés LLM, l'historique de chat, les routines sont distincts. C'est le contrat d'isolation que vous offrez à vos clients ou à vos équipes.

Exception assumée : les connexions OAuth personnelles (Google, GitHub, LinkedIn) sont rattachées à l'utilisateur, pas au workspace (table gilbert.user_integrations, une row par utilisateur et par provider). Elles sont utilisables depuis tous les workspaces de cet utilisateur, et jamais par un autre membre : voir Intégrations OAuth.

Le parcours canonique est le wizard /configure. Comptez 6 à 12 minutes pour définir une identité cohérente, pas seulement créer un tenant technique.

1. Ouvrez /configure. Vous pouvez commencer avant de vous connecter ; après les canaux, le login restaure votre brouillon sur l'étape Modèle IA.
2. Définissez le nom du workspace, sa palette et son dégradé.
3. Nommez l'assistant et choisissez sa personnalité, ses missions et ses canaux.
4. Sélectionnez Anthropic, Google ou OpenAI, puis fournissez votre clé ou autorisez explicitement le fallback Solve.
5. Vérifiez le récapitulatif. Si vous n'êtes pas connecté, le login intervient à la création et restaure votre brouillon, sauf la clé API.
6. Créez le workspace puis vérifiez le chat, la console et le premier appel headless avec la même identité de marque.

Chaque workspace a un wizard Premiers pas (/console/workspaces/<id>/onboarding) qui guide un nouveau membre en quatre étapes jusqu'à sa première routine reçue :

1. Connecter Google : Gmail et Calendar, nécessaires aux routines qui lisent la boîte mail.
2. Email de livraison: l'adresse qui recevra les routines (l'email de login par défaut).
3. Former mon Gilbert: l'étape est validée une fois les deux apprentissages faits, le style d'écriture (onglet Brouillons) et le tri des mails (onglet Tri des mails). La carte est embarquée directement dans le wizard : on entraîne sans quitter Premiers pas.
4. S'abonner à la routine communedu workspace. Si elle n'existe pas encore, un admin la crée en un clic depuis cette même étape.

Les admins suivent l'activation dans Suivi béta (/console/workspaces/<id>/eval, aussi dans la navigation du workspace) : onboarding, connexions, abonnements, runs et livraisons des 7 derniers jours, et les cas d'usage soumis par les membres en répondant aux emails de routine. Métadonnées uniquement : le contenu des runs et des boîtes mail n'y apparaît jamais.

À chaque inscription, un trigger Postgres crée automatiquement un workspace « personnel » pour le nouvel utilisateur. Il est nommé <email> (personnel)et l'utilisateur en est l'admin.

Conséquence : aucun utilisateur n'existe sans workspace. Utilisez ce workspace personnel pour vos propres projets, ou laissez- le dormant et créez un workspace « équipe » dédié pour le travail. Vous pouvez switcher entre les deux à tout moment.

Un utilisateur peut être membre de plusieurs workspaces. Le dropdown workspace en haut du chat Gilbert (/chat) liste tous les workspaces dont vous êtes membre et permet de switcher.

Le workspace actif est persisté dans un cookie HTTP-only (gilbert_workspace) côté domaine Gilbert. À votre prochain login, Gilbert reprend le dernier workspace actif. Tout ce qui est workspace suit le switch : chat history, routines visibles, clé LLM consommée pour vos messages. Vos connexions OAuth personnelles (Google, GitHub, LinkedIn), elles, restent les mêmes : elles sont rattachées à votre compte, pas au workspace.

BYOLLM (Bring Your Own LLM) est l'une des features les plus structurantes de Gilbert pour une équipe IT. Vous branchez la clé API du provider de votre choix ; Gilbert s'en sert pour tous les appels du workspace ; la consommation est facturée directement chez le provider (Anthropic console, Google Cloud, OpenAI dashboard). Aucun markup Solve, aucun intermédiaire de facturation.

Une seule clé suffit pour démarrer (celle que vous configurez à la création du workspace). Vous pouvez ensuite en ajouter d'autres depuis la section Providers LLM de la page workspace.

• Trois providers supportés : Anthropic Claude, Google Gemini, OpenAI. Vous pouvez en avoir un, deux, ou les trois configurés en parallèle.
• Plusieurs clés par provider. Chaque entrée porte un label (ex. « Clé prod », « Clé dev », « Projet X »). Utile pour séparer la consommation par environnement ou par équipe au sein du même workspace.
• Un provider par défaut marqué is_default = true. C'est celui que Gilbert utilise pour le chat web, les briefings, et tout pipeline qui ne spécifie pas explicitement un provider. Un index partiel Postgres (workspace_llm_config_default_key) garantit qu'un seul provider est default à la fois par workspace.
• Abstraction par tier. Chaque call site passe un tier fast / smart / premiumau lieu d'un modèle hardcodé. Le mapping concret (Haiku/Flash-Lite/mini, Sonnet/Flash/4o, Opus/Pro/4o) vit côté Gilbert et suit le provider configuré sur votre workspace. Quand un nouveau modèle sort, vous en bénéficiez automatiquement sans changer de config.
• Chaque routine peut surcharger: la routine « Gmail morning » peut tourner en Gemini (rapide, pas cher pour du résumé d'emails), pendant que la routine « Code review hebdomadaire » tourne en Anthropic (meilleur sur le raisonnement code). Les routines gagnent aussi un tier model_tier (default smart) pour piloter le budget par routine.
• Fallback Solve explicite. Il est désactivé par défaut. Le toggle « Autoriser le fallback Solve » active le flag allow_central_fallback. Sans clé valide et sans cet opt-in, la création ou l'appel échoue de façon actionnable au lieu de changer silencieusement de moteur.
• Coûts visibles côté provider: vous voyez vos tokens consommés et votre facture sur la console du provider, pas sur Gilbert. Gilbert affiche un mini-widget d'usage par workspace (tokens, appels, pipelines) à titre d'information, mais c'est votre provider qui fait foi pour le billing.

Le workspace est la frontière de sécurité de Gilbert. Pour un département IT qui doit auditer le déploiement, voici ce qui est garanti :

• RLS Postgres natif. Toutes les tables scopées à un workspace ont une FK workspace_id et des policies RLS qui filtrent automatiquement par appartenance via workspace_members. Aucune requête côté serveur ne peut accidentellement renvoyer des données d'un autre workspace.
• Schéma Postgres dédié. Toutes les tables Gilbert vivent dans le schéma gilbert, isolé du schéma public des produits Solve. Aucun JOIN cross-schéma : la communication avec les apps Solve se fait par webhooks HMAC signés.
• Clés LLM chiffrées AES-256-GCM au repos. Les colonnes api_key_encrypted de workspace_llm_config ne sont jamais lisibles en clair, même par les admins de la base : la clé de chiffrement (GILBERT_LLM_KEY) vit uniquement en variable d'environnement côté serveur Gilbert.
• Tokens OAuth chiffrés de la même manière (Google, GitHub, LinkedIn : clés dédiées GOOGLE_TOKEN_KEY, GITHUB_TOKEN_KEY, LINKEDIN_TOKEN_KEY). Ces tokens sont scopés à l'utilisateur (per-user, jamais lisibles par un autre membre), pas au workspace.
• Agents embed scopés au workspace propriétaire. Chaque agent a un HMAC secret unique, lié au workspace qui l'a créé. Un JWT SSO signé pour un agent du workspace A est rejeté par les endpoints du workspace B : la signature ne matche pas.

Liste exhaustive des entités scopées par workspace_id. Quand vous supprimez un workspace, tout ce qui suit est supprimé en cascade.

Invitations de membres(depuis le 28 mai 2026). Un admin saisit l'email du membre à inviter sur la page workspace. Supabase mint un magic link, Postmark envoie un email transactionnel d'invite (même quand le user existe déjà), et le callback auth attache la membership à la connexion. RBAC server-side via workspaceMemberGuard : un non-admin ne peut pas inviter, et supprimer le dernier admin du workspace est bloqué. Le créateur du workspace reste automatiquement admin via workspace_members.

La suppression se fait depuis la zone dangereusetout en bas de la page d'un workspace, accessible uniquement aux admins. La confirmation demande de retaper le nom du workspace pour éviter les accidents.

La suppression déclenche un cascade DELETEsur toutes les tables qui pointent vers ce workspace (routines, agents, intégrations workspace type Slack, repos, connexions MCP, clés LLM, chat history, members, usage tracking). C'est irréversible. Les connexions OAuth personnelles (Google, GitHub, LinkedIn) survivent à la suppression : elles appartiennent aux utilisateurs, pas au workspace. Chaque membre les révoque depuis son compte (/console/me/integrations) ou depuis le provider.

Chaque entité scopée à un workspace garde, en plus de workspace_id, un champ audit user_idqui identifie le membre à l'origine de l'action : qui a connecté Slack, qui a autorisé un client MCP, qui a créé la routine. C'est ce que vous regardez en cas d'incident de sécurité ou de audit interne.

Pour l'instant ces informations sont visibles en lisant la base directement (Supabase Studio, schéma gilbert). Une page dédiée Audit logdans la console arrive plus tard ; en attendant, le mini-widget d'usage sur la page workspace (Usage – 7 derniers jours) donne déjà une vue agrégée des appels LLM par pipeline.

Une fois votre workspace créé et votre clé LLM branchée, les chantiers IT typiques :

• Connecter Google, GitHub, LinkedIn (connexions personnelles, par membre) : voir Intégrations OAuth.
• Déployer un agent embed sur votre site : voir Embed iframe et JWT SSO pour l'identité utilisateur.
• Planifier une routine automatique (briefing matinal, draft de réponses Gmail, code review hebdomadaire) : voir la section Routines automatisées de la Console B2B.
• Recevoir les events Gilbert côté backend via webhooks HMAC-signés : voir Webhooks.