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. Première exception, décidée par l'espace qui publie : un espace enfant peut publier un document à sa famille, que son espace parent, et ses frères si la famille est ouverte, retrouvent dans la recherche documentaire. Mails, conversations et mémoire ne sortent jamais d'un espace. C'est le contrat d'isolation que vous offrez à vos clients ou à vos équipes.

Seconde 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, OpenAI ou Mistral, 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 agenda, nécessaires aux routines qui lisent la boîte mail. Drive est facultatif, il sert à citer un chiffre exact tiré d'un document.
2. Email de livraison : l'adresse qui recevra les routines (l'email de login par défaut).
3. Former mon assistant : 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 commune du 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 Activation des membres (/console/workspaces/<id>/eval, dans Réglages › Avancé) : 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. Cela vaut pour l'espace qui apporte sa propre clé ; pour un espace sans clé configurée, c'est la clé de Solve qui sert les appels et sa prise en charge qui s'applique, détaillée dans Conso.

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.

• Quatre providers supportés : Anthropic Claude, Google Gemini, OpenAI, Mistral AI. Vous pouvez en configurer un ou plusieurs 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 / premium au 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.
• Chaque type de tâche aussi : dans Réglages › Quel modèle pour quelle tâche, un admin de l'espace confie une tâche à un autre fournisseur ou à un autre niveau d'intelligence. Cinq tâches : quand Gilbert discute, quand il écrit vos mails, quand il lit un document, quand il classe et résume, quand il répond au téléphone. Une tâche non réglée suit la clé par défaut de l'espace, et un réglage qui pointe vers un fournisseur dont vous n'avez pas la clé vous le dit à l'écran, au lieu de replier en silence. Sous les tâches, la case Indexation par Solve fait aussi indexer vos documents par le moteur de recherche hébergé par Solve, et rien ne les y envoie tant qu'elle n'est pas cochée. Elle ne change ni le fournisseur ni le niveau de la lecture de document. La décocher efface cet index, et la recocher ne le rend pas : il faut réindexer vos documents.
• 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.

Dès que vous connectez Google, et si un workspace peut indexer ses documents (voir plus bas), les mails de votre boîte de réception et de vos envois sont ajoutés à la recherche dans les documents d'un seul workspace. Les onglets Promotions, Réseaux sociaux, Forums et Notifications ne sont pas indexés, et les mails que vous avez archivés n'y entrent pas. Si un seul workspace peut les recevoir, le choix se fait tout seul et l'indexation démarre dans les minutes qui suivent. Sinon, vous choisissez le workspace dans Mes intégrations. Les mails plus anciens s'ajoutent petit à petit. La plupart des mails qui portent un code de connexion ou un mot de passe temporaire ne sont pas indexés.

Pour rédiger vos brouillons, l'assistant s'appuie sur les documents du workspace et sur vos seuls mails envoyés. Vos mails reçus restent consultables dans le chat : l'assistant les traite comme des messages reçus, jamais comme des consignes.

Un mail supprimé, déplacé dans la corbeille ou classé comme spam dans Gmail est retiré de la recherche peu après, de même qu'un mail que vous rangez ensuite dans l'un des onglets non indexés. À l'inverse, un mail que vous sortez du spam, de la corbeille ou d'un onglet non indexé, et qui se retrouve dans votre boîte de réception ou vos envois, entre en général dans la recherche au passage suivant ; un mail restauré en même temps que beaucoup d'autres, ou pendant que l'indexation est en pause ou rattrape son retard, peut ne pas y entrer. Si vous connectez un autre compte Google, les mails indexés de l'ancienne boîte sont effacés et l'indexation repart avec la nouvelle.

Si vous déconnectez Google, l'indexation s'arrête au passage suivant et vos mails indexés sont effacés. Si votre connexion Google n'autorise plus l'accès à Gmail, ou si l'assistant ne parvient plus à lire votre boîte, l'indexation se met en pause : reconnectez Google avec l'accès à Gmail pour la reprendre. Au bout de 7 jours sans lecture réussie, elle s'arrête et vos mails indexés sont effacés de la même façon. Une indexation arrêtée ne reprend pas toute seule : reconnectez Google avec l'accès à Gmail, puis relancez-la depuis Mes intégrations.

Ces mails ne sont visibles que de vous : ni vos collègues ni les administrateurs du workspace ne peuvent les retrouver. Le bouton Arrêter et effacer, dans Mes intégrations, supprime les mails indexés en quelques minutes. Quitter le workspace les supprime aussi, peu après votre départ.

Pour recevoir vos mails, le workspace doit pouvoir les vectoriser, de l'une de ces trois façons. Si un administrateur coche Indexation par Solve dans Réglages, section Quel modèle pour quelle tâche, le modèle hébergé par Solve s'en charge, gratuitement. Sinon, si le workspace a sa propre clé Mistral (ajoutée dans Modèles d'IA), l'indexation passe par elle et vous la payez à votre fournisseur. Sinon, par défaut, l'indexation passe par la clé de Solve : elle est refacturée au coût majoré de 20 %, dans la limite du plafond mensuel du workspace. Seule la clé du fournisseur qui indexe les documents (Mistral par défaut) compte : une clé d'un autre fournisseur n'y change rien. Un workspace ouvert par un revendeur n'utilise pas la clé de Solve tant que ce revendeur ne l'a pas autorisée : sans clé Mistral ni case cochée, il n'indexe pas vos mails.

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. Gilbert enregistre l'invitation côté serveur, avec le workspace et le rôle accordé, valable sept jours, puis l'invité reçoit son lien par email (Postmark notifie directement les personnes qui ont déjà un compte, ajoutées sur-le-champ). À la connexion, la membership est attachée sur la seule invitation en attente qui porte l'adresse vérifiée du compte qui entre, et elle se consomme une fois. 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 dangereuse tout 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 DELETE sur 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_id qui 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 log dans 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.