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, intégrations OAuth dédiées, 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 de tout. Aucune donnée n'est partagée entre workspaces, même pour un même utilisateur membre des deux : les clés LLM, les tokens OAuth, l'historique de chat, les routines sont distincts. C'est le contrat d'isolation que vous offrez à vos clients ou à vos équipes.

Six étapes, environ deux minutes. Vous aurez besoin d'une clé API du provider LLM de votre choix.

1. Connectez-vous sur gilbert.solveholding.com/console/workspaces.
2. Cliquez sur + Nouveau workspace en haut à droite.
3. Choisissez un nom parlant pour vos équipes (ex : Acme Immo Paris). Le nom est modifiable plus tard.
4. Sélectionnez votre provider LLM initial: Anthropic Claude, Google Gemini, ou OpenAI. C'est le provider que Gilbert utilisera par défaut pour le chat et les briefings ; vous pourrez en ajouter d'autres plus tard pour des routines spécifiques.
5. Collez votre clé API. Gilbert exécute un ping mini (1 token) pour vérifier que la clé est valide et que le provider répond, avant de la stocker chiffrée en base.
6. Workspace créé. Vous arrivez sur sa page de détail. C'est désormais le workspace actif sur votre compte.

À 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 suit le switch : chat history, routines visibles, intégrations OAuth utilisées, clé LLM consommée pour vos messages.

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 central explicite. Par défaut, si aucune clé n'est configurée sur le workspace, Gilbert utilise sa clé Anthropic centrale (mode trial). Vous pouvez désactiver ce fallback via le toggle « Fallback sur la clé Gilbert centrale » (flag allow_central_fallback) — chaque appel fail-fast au lieu de transiter par notre infra. Mode privacy strict recommandé dès qu'une clé workspace est en place.
• 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).
• 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 OAuth, repos, clés MCP, clés LLM, chat history, members, usage tracking). C'est irréversible.

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é Google, qui a généré la clé 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 — voir la section Intégrations OAuth de la Console B2B.
• 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.