Organisations et Workspaces

Structurer votre équipe sur AI Studio

Tant que vous travaillez seul, une clé API suffit. Dès que trois développeurs partagent le même compte, les ennuis commencent : personne ne sait quelle clé alimente quelle application, la facture arrive en un seul bloc indéchiffrable, et le jour où quelqu’un quitte l’équipe il faut tout révoquer. AI Studio répond à ce problème avec une architecture à deux niveaux, Organisations et Workspaces. Comprendre cette structure conditionne votre gestion de la facturation, des permissions et de l’isolation des ressources.

Le modèle Organisation / Workspace

L’Organisation occupe le niveau le plus haut de la hiérarchie. Elle est créée automatiquement lors de votre inscription et représente votre entité — entreprise, équipe ou département. C’est à ce niveau que tout se consolide : la facturation, qui regroupe l’ensemble des coûts ; le choix de l’abonnement entre les tiers Experiment, Scale et Enterprise ; les limites d’usage, c’est-à-dire les quotas globaux de tokens et de requêtes ; et enfin l’allocation des membres, avec l’invitation et la gestion des sièges. Créer une nouvelle organisation ne demande qu’un nom et l’acceptation des conditions d’utilisation, et rien n’empêche un même utilisateur d’appartenir à plusieurs organisations simultanément.

Les Workspaces, eux, sont des sous-ensembles au sein d’une Organisation, destinés à segmenter l’accès et les coûts par projet, par équipe ou par environnement. Chaque workspace isole ses clés API, qui ne donnent accès qu’à ses propres ressources, et partage entre ses membres les modèles fine-tunés ainsi que les datasets d’entraînement. La consommation reste traçable workspace par workspace, ce qui permet de dire précisément combien coûte le chatbot support par rapport au moteur de recherche interne.

Gestion des rôles et permissions

Trois rôles cohabitent au niveau de l’Organisation, avec des périmètres volontairement tranchés.

Retenez la ligne du milieu : un Admin gère les équipes et les workspaces mais ne touche jamais à la facturation. C’est ce qui permet de confier l’administration technique à un lead ML sans lui ouvrir la carte bancaire de l’entreprise.

La création d’un workspace suppose donc les permissions administrateur. Depuis la page Admin de votre organisation :

1. Accédez à la section Workspaces
2. Cliquez sur Create Workspace
3. Donnez un nom descriptif (par exemple : production, staging, research)
4. Configurez les permissions initiales

L’ajout d’un collaborateur suit une logique voisine :

1. Allez dans Admin > Members
2. Cliquez sur Invite
3. Entrez l’adresse email du collaborateur
4. Assignez un rôle (Admin, Member)
5. Sélectionnez les workspaces auxquels il aura accès

Bonnes pratiques d’organisation

La première règle consiste à séparer les environnements. Créez au minimum deux workspaces, idéalement trois, pour cloisonner ce qui se passe en développement de ce qui touche vos utilisateurs.

Organisation "MaStartup"
├── Workspace "development"    → clés API de dev, quotas réduits
├── Workspace "staging"        → tests d'intégration
└── Workspace "production"     → clés API de prod, quotas élevés

Cette séparation évite qu’une boucle infinie écrite un vendredi soir en développement ne dévore les quotas de production, et elle rend le suivi des coûts par environnement immédiatement lisible.

Vient ensuite la rotation des clés. Comme chaque clé est rattachée à un workspace, la remplacer sans interrompre le service demande de procéder dans l’ordre : générez la nouvelle clé dans le workspace concerné, déployez-la dans votre application, vérifiez que les requêtes passent effectivement avec elle, et seulement alors supprimez l’ancienne. Inverser les deux dernières étapes vous garantit une coupure.

import os

# Bonne pratique : clé API via variable d'environnement
client = Mistral(api_key=os.environ["MISTRAL_API_KEY"])

Une clé écrite en dur dans le code source finit toujours par se retrouver dans un dépôt Git, puis dans l’historique de ce dépôt, où elle survivra à toutes vos tentatives de nettoyage. Passez par une variable d’environnement dès la première ligne.

Dans les grandes organisations, enfin, la gouvernance gagne à s’appuyer sur un workspace par équipe fonctionnelle — data science, backend, produit — complété par un workspace dédié au fine-tuning, qui centralise les datasets au lieu de les laisser se dupliquer. Des noms de workspace explicites facilitent d’autant le reporting mensuel.

Scénario concret : mise en place

Prenons une entreprise de quinze personnes qui adopte Mistral. Le CTO crée l’Organisation et souscrit au tier Scale, puis y ouvre trois workspaces : dev, staging et prod. Les développeurs reçoivent un accès Member limité au workspace dev, tandis que le lead ML obtient un accès Admin sur les trois. Chaque workspace dispose de ses propres clés API, isolées les unes des autres, si bien qu’une clé de développement fuitée ne compromet rien en production.

Le dashboard admin, accessible sur admin.mistral.ai, affiche ensuite la consommation par workspace. C’est ce tableau que le CTO ouvrira en fin de mois pour ventiler les coûts par projet, sans avoir à instrumenter quoi que ce soit dans le code.

Points clés à retenir

• L’Organisation est le niveau de facturation et de gestion globale
• Les Workspaces isolent les clés API, les modèles fine-tunés et les coûts
• Séparez toujours développement, staging et production dans des workspaces distincts
• Les clés API doivent être stockées dans des variables d’environnement, jamais dans le code
• Le dashboard admin permet de suivre la consommation par workspace en temps réel