Cette page t'a-t-elle aidé ?
Cette page t'a-t-elle aidé ?
Console
Tout part du workspace : intégrations OAuth, agents embed, repos liés, routines automatisées. Une vue centrale par équipe ou par client.
Dernière mise à jour : 30 septembre 2026
Un workspace regroupe une équipe (ou un client) et tout ce qu'elle a configuré dans Gilbert : sa clé LLM, ses agents embed, ses repos GitHub liés, ses routines cron, ses connexions MCP, son historique de chat. Les connexions OAuth personnelles (Google, GitHub, LinkedIn) appartiennent à chaque utilisateur, pas au workspace.
Chaque user a au moins un workspace : un trigger Postgres en crée un automatiquement à chaque signup (nommé <email> (personnel)). Il peut en créer d'autres pour cloisonner ses projets ou ses clients.
Une fois connecté, le header de la console porte trois repères permanents : le logo (retour à l'accueil), un switcher de workspace au centre, et le menu compte, qui porte tout ce qui vous concerne vous. La nav marketing (Playground, Essayer Gilbert) reste sur les pages publiques uniquement.
/console) : on vient sur la console pour configurer un espace, donc /console vous y emmène directement, sur le dernier espace consulté (sinon un espace où vous êtes admin, sinon le premier). Le repère est un cookie posé à la visite réelle d'un espace, purgé à la déconnexion : sur un navigateur partagé, le compte suivant ne voit pas vos habitudes. Il est toujours revalidé contre vos accès réels côté serveur, donc un cookie périmé ou trafiqué n'ouvre jamais un espace qui n'est pas le vôtre./console/workspaces) : la vue transverse, avec la conso cumulée sur 30 jours, les dernières routines lancées et la liste de vos espaces. Ce qui vous concerne vous (comptes, canaux, conso) est aussi sous l'avatar, en haut à droite, donc atteignable sans quitter un espace.Un membre non-admin voit la Vue d'ensemble en lecture seule : description, nom d'assistant et liens du workspace apparaissent dans une section « À propos du workspace ». Les actions (clés LLM, invitations, rôles, suppression) restent réservées aux admins, côté interface comme côté serveur.
Sur /console/workspaces vous gérez la vie d'un workspace.
/reglages, admin only), champ inline avec save instant.Tout espace peut avoir des espaces enfants, eux-mêmes parents d'autres espaces. L'écran Famille, dans le menu de l'espace et réservé à ses admins, montre l'arbre de ces espaces avec leur statut et la colonne « Payé par », les « Demandes en attente » et les documents publiés à la famille. Sur la vue d'ensemble d'un espace, une ligne « Parent » indique l'espace au-dessus de lui.
Le bouton Créer un enfant ouvre une fenêtre où vous nommez le nouvel espace et répondez à « Qui paie ? ». Vous en devenez admin et membre dès sa création. Un espace peut avoir jusqu'à 200 sous-espaces ouverts ; un sous-espace fermé ne compte pas.
Rattacher un espace propose deux chemins. Avec « Un espace que j'administre », vous choisissez l'un de vos espaces, y compris un espace qui a déjà un parent et qui le quitte alors. Pour un enfant direct, l'entrée « Déplacer sous… » du menu ⋯ de sa ligne l'envoie sous un autre parent, chaque destination étant nommée par son chemin depuis l'espace affiché. Votre espace personnel, celui que votre inscription a créé, ne se rattache pas à une famille.
Quand vous administrez les deux côtés, le geste aboutit tout de suite. Sinon, une demande part, valable 14 jours, et un admin de l'autre côté l'accepte ou la refuse depuis ses « Demandes en attente » (« Accepter », « Refuser »). Vous pouvez l'annuler (« Annuler la demande ») ou la relancer (« Relancer »). Avant de confirmer un rattachement ou un déplacement, la fenêtre dit ce que les nouveaux ascendants de l'espace pourront régler.
Avec « Un autre espace », vous saisissez l'adresse courriel de l'admin de cet espace, répondez à « Qui paie ? », puis cliquez sur « Envoyer l'invitation ». Le lien reçu sert une fois et reste valable 14 jours. La personne invitée l'ouvre connectée avec le compte dont l'adresse confirmée est celle qui a reçu l'invitation, choisit l'un des espaces qu'elle administre et qui n'ont pas encore de parent (« Choisis un espace »), voit qui paiera, puis clique sur « Rattacher à… », suivi du nom de votre espace. Tant qu'elle n'a pas répondu, l'invitation figure dans vos demandes en attente, où « Annuler l'invitation » la retire.
Chaque création, rattachement, déplacement ou invitation pose la question « Qui paie ? » : l'espace parent, ou l'enfant lui-même (« Lui-même »). Quand l'espace parent est lui-même payé par un autre, l'option nomme l'espace qui reçoit réellement la facture. Seul un admin de l'espace qui paiera peut mettre un enfant à sa charge : sans ce rôle, l'option du parent reste grisée et l'écran dit pourquoi. Un espace qui arrive avec ses propres enfants se paie lui-même, sauf s'il change de parent sans changer d'espace payeur.
Sous « Partage entre enfants », le réglage « Famille ouverte » décide si vos enfants directs voient ce que leurs frères publient. La famille est cloisonnée par défaut : chaque enfant ne voit alors que son parent. Ouvrir la famille vaut pour les publications à venir : un document publié famille fermée reste réservé au parent, et l'enfant le dépublie puis le republie pour le montrer à ses frères.
Depuis l'écran Famille d'un enfant, « Publier un document » propose les documents déjà partagés avec tout l'espace, et « Publier à la famille » les rend visibles du parent et, famille ouverte, des frères. Ils les retrouvent dans la recherche documentaire, avec le nom de l'espace d'origine. Les documents reçus apparaissent sous « Publié par la famille », les vôtres sous « Ce que je publie à la famille », où « Dépublier » les retire. Mails, conversations et mémoire ne sortent jamais d'un espace.
Le menu ⋯ de chaque ligne de l'arbre propose « Suspendre », « Réactiver » et « Fermer », à n'importe quelle profondeur. Le geste s'applique aussi aux espaces situés en dessous, et la fenêtre de confirmation les compte. Un espace suspendu ou fermé garde son contenu, mais plus personne n'y entre.
« Détacher », dans le menu ⋯ d'un enfant direct, le sort de la famille : il redevient un espace sans parent, avec ses propres enfants. Côté enfant, « Quitter la famille » fait la même chose depuis son écran Famille. Un espace suspendu ou fermé ne change pas de parent, et un espace client ouvert par un produit partenaire ne peut être détaché que par ce produit ou par un espace au-dessus de lui.
Un workspace peut avoir plusieurs clés LLM configurées en parallèle : une par défaut pour le chat et les briefings, plus des clés dédiées par routine (ex : une routine veille code en Anthropic, une routine résumé mails en Google Gemini).
La clé par défaut est marquée is_default = true. Un index partiel garantit qu'un seul provider est default à la fois par workspace.
Les connexions OAuth personnelles (Google, GitHub, LinkedIn) sont rattachées à chaque utilisateur, pas au workspace (table gilbert.user_integrations, une row par utilisateur et par provider). Elles se gèrent depuis Mes intégrations et sont utilisables depuis tous vos workspaces. Les canaux d'équipe (Slack), eux, sont scopés au workspace.
| Intégration | Sert à | Setup |
|---|---|---|
| Google (Gmail, agenda, Drive) | Lire les mails, brouillons de réponse, briefing matinal, lecture agenda, lecture de documents Drive (facultatif) | /console/me/integrations/google |
| GitHub | Lire les repos liés (repo_list_files, repo_read_file, repo_search) | /console/me/integrations/github |
| Publier des posts UGC depuis une routine | /console/me/integrations/linkedin | |
| Telegram | Canal de notification personnel (briefings, confirmations, fallback d'appel) | /console/me/integrations/telegram |
| Slack (workspace) | Canal d'équipe : scopé au workspace, supprimé avec lui | Page du workspace, section Slack |
Les tokens sont chiffrés AES-256-GCM côté serveur (clés par intégration : GOOGLE_TOKEN_KEY, LINKEDIN_TOKEN_KEY, GITHUB_TOKEN_KEY). Lecture server-only, jamais retournés en clair après le premier connect.
Chaque agent appartient à un workspace : c'est lui qui en pilote le system prompt, le HMAC secret, le statut, les tools autorisés. Les agents se gèrent donc depuis le menu de l'espace, entrée Agents embarqués (/console/workspaces/:id/agents, admins uniquement). La vue /console/agents liste en plus tous vos agents, tous espaces confondus.
CRUD complet depuis l'espace : créer (modal avec validation, l'agent naît dans cet espace), éditer (form inline), régénérer le HMAC secret (confirm-twice), supprimer (zone dangereuse).
Le HMAC secret est affiché une seule fois à la création (et à chaque rotation). Stockez-le côté backend client pour signer vos JWTs. Voir JWT SSO.
Une routine peut lire le code d'un ou plusieurs repos GitHub liés au workspace. V1 read-only via GitHub API (pas de clone, pas de /tmp) : zéro infrastructure additionnelle, instant cold-start.
Trois tools deviennent automatiquement disponibles aux routines :
repo_list_files : arbre complet via git/trees?recursive=1repo_read_file : contenu UTF-8 (max 100 KB) via Contents APIrepo_search : Code Search API (requiert un token GitHub valide)Pour lier un repo, deux chemins : (1) picker GitHub OAuth si vous avez connecté votre compte (liste vos repos accessibles) ; (2) mode avancé avec PAT manuel si vous voulez attacher un repo d'une org sans OAuth.
Une routine est une tâche LLM planifiée par cron, scopée à un workspace. Configurable depuis le chat (wizard /chat?wizard=routine) ou côté workspace.
Chaque routine choisit son provider à la création (Anthropic / Google / OpenAI). Les tools disponibles selon les intégrations configurées : Gmail (list, search, read, create draft), Calendar (list today, list range), repos (list_files, read_file, search), fetch_url (SSRF-safe).
status=cancelled)Chaque utilisateur peut autoriser un client MCP via OAuth 2.1 PKCE pour exposer les capacités Gilbert à n'importe quel client compatible : Claude Code, claude.ai web (Connectors), ChatGPT custom connectors, Cursor, Codex CLI, n8n, scripts custom. Tools exposés aujourd'hui : notify_canal, mark_reply_processed, sync_scheduled_tasks, mark_task_synced, publish_linkedin_post, gmail_list_recent, gmail_search, gmail_read_message, calendar_list_today, calendar_list_range, list_routines, list_workspaces et les tools list_workspace_*.
Setup : page Mes intégrations → Bridge MCP. L'auth recommandée passe par token Bearer OAuth court-vivant ; l'ancien mode clé hashée reste temporaire derrière feature flag. Tools destructifs (envoi mail, RSVP calendar, post Slack) non exposés via MCP tant que leur confirm-flow asynchrone n'est pas généralisé.
La page /console/usage agrège la consommation LLM de vos workspaces : tokens entrants et sortants par provider, coût estimé, graphe journalier, et distingue désormais les appels payés par votre clé de ceux payés par la clé Solve en repli. Depuis le 20 septembre 2026, chaque ligne porte un nom lisible (« Rédaction de brouillon », « Tri du courrier ») à la place d'un identifiant technique. Ces totaux restent un plancher : certains appels peuvent ne pas encore y remonter.
Solve prend en charge chaque mois une part de la consommation IA de votre espace, proportionnelle aux sièges réellement actifs. Vous pouvez fixer, dans Réglages › Avancé › « Dépassement facturé », le montant que votre espace accepte de payer au-delà : nul par défaut. Sans montant fixé, une fois la prise en charge épuisée, l'assistant se met en pause jusqu'au mois suivant, ou jusqu'à ce qu'un montant soit posé. Ce qui dépasse apparaît sur la facture mensuelle, détaillé par fournisseur, et ne dépasse jamais le montant accepté. Ces totaux restent malgré tout un plancher : ce qui n'est pas mesuré n'est pas facturé.
Une section dédiée aux appels téléphoniques (durée, coût Vapi) est prévue mais pas encore disponible. En attendant, le détail voix est visible dans les logs de la page workspace concernée. Voir Appels → Coûts.
Les réglages personnels (indépendants du workspace) vivent sous /console/me :