Configuration Admin

La configuration administrateur, aussi appelée configuration gérée, permet aux administrateurs d'Organization et de Workspace de distribuer les paramètres de Vibe Code CLI à tous les utilisateurs. Vous la définissez une fois dans l'Admin Panel, puis la CLI l'applique aux utilisateurs de l'Organization ou du Workspace. Utilisez-la pour distribuer des modèles, des fournisseurs, des serveurs MCP et des politiques d'outils sans demander aux utilisateurs de modifier config.toml.

Contrairement à config.toml, la configuration administrateur ne se trouve pas sur la machine de l'utilisateur. La CLI la récupère en HTTP au démarrage, la conserve uniquement en mémoire et ne l'écrit jamais sur disque.

La configuration administrateur est disponible à deux niveaux :

• Niveau Organization : configurez-la dans Admin Panel›Vibe›Preferences ↗. Elle s'applique à tous les utilisateurs de l'Organization.
• Niveau Workspace : ouvrez Admin Panel›Administration›Workspaces ↗, sélectionnez un Workspace, puis ouvrez Settings. Cette configuration peut remplacer ou bloquer des paramètres définis au niveau de l'Organization.

Le serveur fusionne les configurations de l'Organization et du Workspace. Le client reçoit une seule configuration résolue.

La prise en charge de la configuration administrateur commence avec les versions suivantes :

Les versions antérieures ne demandent pas la configuration administrateur et n'appliquent pas ses paramètres. Mettez à niveau tous les clients avant de distribuer une configuration administrateur.

1. Dans Admin Panel›Vibe›Preferences ↗, saisissez une configuration TOML sous Vibe Code Clients managed config.
2. Au démarrage et après /reload, la CLI appelle l'endpoint de configuration gérée avec la clé API Mistral de l'utilisateur.
3. Si la configuration administrateur est activée, ses valeurs sont prioritaires sur toutes les autres sources de configuration.

La gestion de la configuration administrateur nécessite l'autorisation de contrôle d'accès basé sur les rôles (RBAC) manage_code_config au niveau de l'Organization. Les administrateurs d'Organization peuvent déléguer cette gestion sans accorder un accès administrateur complet.

La configuration administrateur est désactivée par défaut et Mistral doit l'activer pour votre Organization. Contactez votre équipe de compte pour demander l'activation.

Le processus d'activation dépend du type de déploiement :

La configuration administrateur est la couche prioritaire. Elle prévaut sur les options de ligne de commande, les variables d'environnement, ainsi que les deux fichiers config.toml, celui du projet et celui de l'utilisateur :

admin config  >  CLI flags  >  env vars  >  project config.toml  >  user config.toml

admin config  >  CLI flags  >  env vars  >  project config.toml  >  user config.toml

Cette priorité signifie que les valeurs fournies par l'administrateur s'appliquent aux utilisateurs par défaut, sans qu'ils aient à mettre à jour leur propre config.toml.

La configuration Admin accepte la plupart des mêmes clés que config.toml, par exemple :

• Modèle actif, modèles et providers.
• Serveur MCP.
• Connecteurs, ainsi que les outils, agents et skills activés ou désactivés.
• Interrupteurs de télémétrie, de mise à jour automatique et de notifications.

active_model = "mistral-large-latest"
enable_auto_update = false
disabled_tools = ["shell"]

[[providers]]
name = "mistral"
api_base = "https://api.mistral.ai"
api_key_env_var = "MISTRAL_API_KEY"

active_model = "mistral-large-latest"
enable_auto_update = false
disabled_tools = ["shell"]

[[providers]]
name = "mistral"
api_base = "https://api.mistral.ai"
api_key_env_var = "MISTRAL_API_KEY"

Un cas d’usage courant consiste à fournir à toute l’organisation des modèles prêts à l’emploi dès le départ. Au lieu de laisser chaque utilisateur configurer manuellement les fournisseurs et les modèles, les Admin livrent une fois le modèle et le fournisseur appropriés, pointés vers votre endpoint d’entreprise avec le bon backend, l’URL de base et les en-têtes corrects. Les utilisateurs obtiennent une configuration fonctionnelle au premier lancement, sans rien avoir à configurer.

active_model = "mistral-large-enterprise"

[[providers]]
name = "acme-enterprise"
backend = "mistral"
api_base = "https://mistral.acme.internal/v1"
api_key_env_var = "ACME_MISTRAL_API_KEY"
api_style = "openai"
region = "eu-west-1"

[providers.extra_headers]
"x-acme-tenant" = "engineering"

[[models]]
name = "mistral-large-2411"
provider = "acme-enterprise"
alias = "mistral-large-enterprise"

active_model = "mistral-large-enterprise"

[[providers]]
name = "acme-enterprise"
backend = "mistral"
api_base = "https://mistral.acme.internal/v1"
api_key_env_var = "ACME_MISTRAL_API_KEY"
api_style = "openai"
region = "eu-west-1"

[providers.extra_headers]
"x-acme-tenant" = "engineering"

[[models]]
name = "mistral-large-2411"
provider = "acme-enterprise"
alias = "mistral-large-enterprise"

Ici, le modèle mistral-large-2411 est accessible via le fournisseur acme-enterprise, exposé aux utilisateurs sous l’alias mistral-large-enterprise, défini comme modèle actif. L’identifiant est toujours fourni localement via la variable d’environnement ACME_MISTRAL_API_KEY.

La configuration Admin ne contient jamais de secrets en clair. Les champs d’identifiants doivent référencer une variable d’environnement, par exemple api_key_env_var = "MISTRAL_API_KEY", jamais la clé elle-même. Les clés API, tokens ou mots de passe en clair sont rejetés par le serveur.

Lorsque la configuration administrateur est active, les utilisateurs de Vibe Code CLI voient les éléments suivants :

• Les paramètres gérés par un administrateur dans /config apparaissent grisés avec le glyphe de verrouillage ⚿ et indiquent your administrator comme origine. Une légende en bas de l'écran affiche ⚿ Settings are managed by your organization.
• Les champs gérés par un administrateur sont en lecture seule dans /config. Les tentatives de modification ou de réinitialisation n'ont aucun effet.
• Le sélecteur de modèle constitue une exception. Si un utilisateur change de modèle alors que active_model est géré par un administrateur, un avertissement indique que l'administrateur contrôle ce paramètre.
• Les utilisateurs voient les marqueurs de gestion uniquement lorsqu'ils ouvrent /config. Aucune bannière ni aucun indicateur global ne s'affiche au démarrage.
• La CLI récupère la configuration administrateur en arrière-plan au début de chaque session. Elle la conserve en mémoire et ne l'écrit jamais dans le fichier config.toml local.
• Si une erreur réseau ou serveur empêche la récupération, la session continue sans configuration administrateur. La CLI journalise l'échec au niveau debug et n'affiche aucun avertissement.

La désactivation de l'option masque uniquement l'interface d'administration. Les clients continuent de récupérer et d'appliquer la configuration enregistrée.

Pour arrêter d'appliquer la configuration administrateur, envoyez une configuration vide avant de désactiver l'option. Cette opération empêche l'application d'une configuration obsolète aux sessions des utilisateurs.

Si les utilisateurs de déploiements dédiés ou auto-hébergés ne reçoivent pas la configuration administrateur, vérifiez les endpoints et les domaines.

Le client doit accéder à deux endpoints authentifiés :

• <console_base_url>/api/vibe/whoami renvoie les domaines Vibe et API du tenant dans vibe_base et api_base.
• <vibe_base_url>/api/v1/code/managed-config renvoie la réponse de configuration administrateur. Le client déduit vibe_base_url de la valeur vibe_base renvoyée par /whoami.

Définissez les URL du déploiement de l'utilisateur, vérifiez que MISTRAL_API_KEY est disponible dans l'environnement, puis exécutez les deux requêtes depuis cet environnement :

CONSOLE_BASE_URL="https://console.mistral.ai"
VIBE_BASE_URL="https://chat.mistral.ai"

curl --silent --show-error --fail-with-body \
  --header "Authorization: Bearer ${MISTRAL_API_KEY}" \
  "${CONSOLE_BASE_URL}/api/vibe/whoami"

curl --silent --show-error --fail-with-body \
  --header "Authorization: Bearer ${MISTRAL_API_KEY}" \
  "${VIBE_BASE_URL}/api/v1/code/managed-config"

CONSOLE_BASE_URL="https://console.mistral.ai"
VIBE_BASE_URL="https://chat.mistral.ai"

curl --silent --show-error --fail-with-body \
  --header "Authorization: Bearer ${MISTRAL_API_KEY}" \
  "${CONSOLE_BASE_URL}/api/vibe/whoami"

curl --silent --show-error --fail-with-body \
  --header "Authorization: Bearer ${MISTRAL_API_KEY}" \
  "${VIBE_BASE_URL}/api/v1/code/managed-config"

Pour les déploiements dédiés et auto-hébergés, remplacez les deux URL par les origines de la console et de Vibe propres au déploiement.

• Si une requête ne peut pas se connecter, vérifiez la configuration DNS, TLS et réseau du déploiement. Contactez votre équipe de compte ou le support Mistral si l'endpoint reste indisponible.
• Si une requête renvoie 401 ou 403, vérifiez la clé API et l'accès de l'utilisateur.
• Si les deux requêtes renvoient un code HTTP de succès, vérifiez les domaines.

La réponse de /whoami doit contenir les origines vibe_base et api_base attendues. Le client enregistre une valeur vibe_base valide sous vibe_base_url dans le fichier config.toml de l'utilisateur. Il l'utilise pour construire l'URL de configuration gérée.

Si /whoami renvoie un domaine incorrect, contactez le support Mistral pour corriger la configuration du serveur. Si la réponse est correcte mais que le client ne récupère pas la configuration administrateur, examinez le client Vibe Code.