Vibe Code : l’agent de code du terminal au cloud

L’article précédent traitait des assistants configurables de la conversation. Vibe Code applique la même logique au code. L’agent n’y discute toutefois pas : il ouvre des fichiers, lance un shell, écrit des tests et pousse une branche.

Ce sixième volet de la série « Maîtriser Mistral de A à Z » s’adresse aux développeurs et aux responsables techniques. Trois angles le structurent. Ce que l’outil fait réellement, d’abord. Comment le configurer sans se faire piéger par les réglages implicites, ensuite. Sous quel modèle d’exploitation le faire tourner, enfin.

Le vocabulaire de 2026 : quatre surfaces, un seul agent

Commençons par lever une confusion fréquente. Le nom « Vibe » désignait à l’origine ce seul agent de code. Depuis le changement de marque de mai 2026, Vibe nomme toute la suite Mistral, et l’agent de code s’appelle Vibe Code.

Il vit désormais sur quatre surfaces, qui partagent toutes le même moteur.

• Le CLI — l’agent terminal, publié en open source, distribué sur PyPI sous le nom mistral-vibe.
• Les extensions IDE — VS Code, JetBrains et Zed, ces deux dernières passant par le protocole ACP.
• Vibe Code Web — les sessions distantes, accessibles quant à elles depuis chat.mistral.ai/code.
• Les agents d’arrière-plan — les tâches lancées depuis l’application Vibe, qui tournent sans terminal ouvert.

Installation et premier lancement

L’installation prend moins de cinq minutes. Le CLI est un projet Python 3.12 géré avec uv. Le script officiel s’occupe ensuite de tout, y compris d’installer uv s’il manque.

# Script officiel — installe uv si besoin, puis le CLI
curl -LsSf https://mistral.ai/vibe/install.sh | bash

# Ou directement, si uv est déjà présent
uv tool install mistral-vibe

# Deux exécutables deviennent disponibles
vibe        # l'interface terminal interactive
vibe-acp    # le pont vers les IDE compatibles ACP

Si l’installeur signale que vibe n’est pas dans votre PATH, ajoutez le dossier affiché à votre profil shell, puis relancez le terminal. Un fichier de configuration par défaut est créé dans ~/.vibe/config.toml.

L’assistant de configuration

Lancez vibe dans votre projet. Un assistant vous propose alors deux voies. Vous vous connectez avec votre compte Mistral, et l’usage suit alors les limites de votre formule. Vous fournissez sinon votre propre clé API, générée depuis Code puis Vibe CLI. Elle prend alors le pas sur la connexion par compte. La variable MISTRAL_API_KEY reste une alternative si vous préférez éviter l’invite interactive.

Vous pouvez relancer cet assistant à tout moment avec vibe --setup. Un point mérite d’être noté : le CLI accepte aussi une clé provenant d’un autre fournisseur compatible.

Les dossiers de confiance

Au premier lancement dans un nouveau répertoire, le CLI demande si vous accordez votre confiance à ce dossier. La mesure est essentielle, puisque l’outil peut exécuter du shell. Les dossiers approuvés sont mémorisés dans ~/.vibe/trusted_folders.toml.

Prévoyez donc WSL sous Windows. Côté terminal, l’interface s’appuie sur le framework Textual : les émulateurs récents la rendent correctement, les anciens beaucoup moins.

Les profils d’agents : le réglage le plus important

Le CLI embarque quatre profils, qui déterminent ce que l’agent peut faire sans vous demander. Basculez de l’un à l’autre avec Shift+Tab en session interactive. Le drapeau --agent fait de même au lancement.

Notez bien la troisième ligne. Le profil par défaut n’est pas le plus prudent : accept-edits écrit dans vos fichiers sans rien demander. Il réserve en effet la confirmation aux seules commandes shell. Commencez donc en plan les premiers jours, le temps d’observer le raisonnement de l’agent.

Les permissions sont par ailleurs portées par la session, avec des dérogations possibles par fichier, par commande et par répertoire. Un subagent interne nommé explore complète enfin la liste. Il sert à la reconnaissance de codebase en lecture seule, et reste non sélectionnable.

config.toml : là où tout se règle

Le CLI lit d’abord ./.vibe/config.toml, la configuration locale au projet. Il lit ensuite ~/.vibe/config.toml, la configuration globale. Vous y définissez le modèle actif, les permissions par outil et les serveurs MCP.

# Exemple minimal
active_model = "mistral-medium-3.5"

# Permissions par outil — ask, always, never
[tools.bash]
permission = "ask"

[tools.write_file]
permission = "ask"

[tools.read]
permission = "always"

[tools.grep]
permission = "always"

# Un serveur MCP lancé en sous-processus
[[mcp_servers]]
name = "fetch_server"
transport = "stdio"
command = "uvx"
args = ["mcp-server-fetch"]

Trois niveaux existent par outil. ask demande à chaque appel, always auto-approuve, never interdit l’outil. Les motifs d’activation acceptent les noms exacts, les globs et les expressions régulières préfixées par re:.

Les outils intégrés

• read, write_file, edit — lecture, écriture et correctif ciblé, avec aperçu du diff.
• bash — exécution shell dans des sessions gérées, avec environnement persistant.
• grep — recherche récursive, accélérée par ripgrep sur les gros dépôts.
• todo — la liste de tâches que l’agent tient pour suivre son avancement.
• ask_user_question — la question à choix multiples posée en cas d’ambiguïté.
• task — la délégation à un subagent.

Un détail pratique peu documenté : vous pouvez joindre une image par mention @ dans le prompt. Les fichiers PNG, JPEG, GIF et WebP partent alors en contenu multimodal natif vers un modèle capable de vision.

Subagents : déléguer sans polluer le contexte

Un subagent exécute une tâche ciblée dans son propre contexte, avec ses propres instructions et permissions. Il rend ensuite un résultat synthétique au fil principal. Son journal d’exécution, lui, ne remonte pas. C’est le mécanisme qui garde une session longue lisible.

Deux types, une distinction qui compte

Tout agent personnalisé doit déclarer son type. Avec agent_type = "agent", il devient sélectionnable par vous, via --agent ou Shift+Tab. Avec agent_type = "subagent", il n’est plus sélectionnable : seul le modèle peut l’invoquer, par l’outil task. Confondre les deux est l’erreur classique du premier agent maison.

# ~/.vibe/agents/reviewer.toml — ou ./.vibe/agents/ pour le projet
display_name = "PR Reviewer"
description = "Relit une pull request sans toucher au code"
agent_type = "subagent"
system_prompt_id = "reviewer"

enabled_tools = ["read", "grep", "bash"]

[tools.bash]
permission = "ask"

[tools.read]
permission = "always"

Le champ system_prompt_id renvoie à un fichier markdown dans ~/.vibe/prompts/. Ce découplage permet de versionner les comportements séparément des permissions, et de réutiliser un même prompt sous plusieurs configurations d’outils.

Trois profils qui reviennent souvent

• Le relecteur — lecture seule, lit les diffs, lance la suite de tests, rend un rapport sans modifier une ligne.
• L’explorateur — cartographie un dépôt inconnu, trace les dépendances, retourne un plan d’architecture.
• Le générateur de tests — analyse une fonction, identifie les cas limites, écrit et vérifie la suite.

Skills et serveurs MCP : étendre l’agent

Les Skills du CLI

Une Skill est un fichier markdown avec un en-tête YAML, invocable par commande slash. Le CLI les cherche à trois endroits. D’abord ~/.vibe/skills/, pour vos skills personnelles. Ensuite .agents/skills/ à la racine du projet, qui suit le standard ouvert. Enfin .vibe/skills/, pour les skills locales. Ces deux derniers emplacements exigent par ailleurs un dossier de confiance.

Une skill peut par ailleurs décrire un enchaînement complet : exploration, cadrage, conception, implémentation, relecture. À l’invocation, l’agent suit la séquence sans dériver.

Brancher un serveur MCP

Le CLI parle nativement le Model Context Protocol, avec trois transports. stdio lance un sous-processus local, tandis que http et streamable-http visent un service distant. De quoi ouvrir l’agent sur vos bases, vos trackers et vos services internes.

# Serveur distant avec authentification par variable d'environnement
[[mcp_servers]]
name = "my_server"
transport = "http"
url = "http://localhost:8000"
api_key_env = "MY_API_KEY"
api_key_header = "Authorization"
api_key_format = "Bearer {token}"
startup_timeout_sec = 15
tool_timeout_sec = 120

Les outils exposés prennent le préfixe du serveur, avec des tirets bas et non des points : un serveur serena qui expose list devient serena_list. La convention compte pour les permissions et les motifs d’activation. Les clés se résolvent à l’exécution depuis l’environnement, jamais depuis le fichier de configuration.

Teleport : envoyer une session dans le cloud

Voici la fonctionnalité la plus spectaculaire du CLI. La commande /teleport déplace une session locale vers un bac à sable distant. La tâche continue sans que votre terminal reste ouvert, et vous la suivez depuis n’importe quel appareil connecté.

Le CLI vous renvoie une adresse Vibe Code Web. Là-bas, l’agent clone votre dépôt et travaille. Il diffuse également sa progression en temps réel, et pose ses questions. En fin de parcours, il pousse enfin une branche et ouvre une pull request en brouillon. Le bac à sable est ensuite détruit, mais les commits et la branche restent dans votre dépôt.

Un raccourci existe pour partir directement dans le cloud : préfixez votre prompt par & et la tâche s’exécute en bac à sable distant dès le départ.

Les quatre prérequis

La fonction demande une clé API rattachée à un compte Pro, Team ou Enterprise. L’application GitHub de Mistral doit être installée sur le dépôt concerné. Votre session doit ensuite tourner sur un modèle Mistral. Celles qui s’appuient sur un modèle tiers ne peuvent pas être téléportées. Vous devez enfin lancer le CLI depuis un dépôt Git.

Notez que le bac à sable Vibe Code Web reste en préversion publique. Ses capacités et ses limites peuvent évoluer avant la disponibilité générale.

Dans votre éditeur : VS Code, JetBrains et Zed

Le même agent tourne dans votre éditeur, avec les subagents, les commandes slash et les permissions par outil. Seule la façade change.

VS Code

Mistral publie une extension dédiée, installable depuis la place de marché ou depuis la page des extensions de Vibe Code. Une icône apparaît ensuite dans la barre d’activité, et l’agent travaille sur l’ensemble du projet.

Zed et JetBrains via ACP

Ces deux familles passent par le protocole Agent Client Protocol, servi par l’exécutable vibe-acp. Zed propose une extension officielle qui télécharge le binaire et gère ses versions. Côté JetBrains, déclarez le serveur. Assurez-vous par ailleurs que vibe-acp se trouve dans le PATH de l’IDE.

# Zed — ~/.config/zed/settings.json
{
  "agent_servers": {
    "Mistral Vibe": {
      "type": "custom",
      "command": "vibe-acp",
      "args": [],
      "env": {}
    }
  }
}

# JetBrains — acp.json
{
  "agent_servers": {
    "Mistral Vibe": {
      "command": "vibe-acp"
    }
  }
}

Le moteur : quel modèle pour quel usage

Vibe Code tourne par défaut sur Mistral Medium 3.5, un modèle dense de 128 milliards de paramètres avec 256K de contexte. Il atteint 77,6 % sur SWE-bench Verified. Ce benchmark mesure la résolution d’issues GitHub réelles, avec leurs tests associés. Il est publié en poids ouverts et s’auto-héberge sur quatre GPU.

Trois autres modèles complètent la pile de développement. Devstral 2 reste disponible comme moteur alternatif, notamment pour l’auto-hébergement. Codestral assure les complétions rapides en frappe. Codestral Embed alimente enfin la recherche sémantique dans le code.

GLM-5.2 et les modèles tiers comme moteur

Depuis août 2026, la plateforme accepte également des modèles ouverts tiers. Le premier est GLM-5.2, développé par le laboratoire chinois Z.ai. Vous pouvez donc le déclarer comme moteur du CLI, au même titre qu’un modèle maison. Gardez toutefois une contrainte en tête : une session qui tourne sur un modèle tiers ne peut pas être téléportée vers le cloud.

Leanstral, pour la preuve formelle

Voici la brique la plus singulière de l’écosystème. Leanstral 1.5, publié le 2 juillet 2026, s’attaque aux preuves formelles en Lean 4. Architecture éparse de 119 milliards de paramètres dont 6 actifs par token, licence Apache 2.0, et un endpoint API gratuit pendant la phase de retours.

Dans le CLI, activez-le avec la commande /leanstall, ou lancez directement vibe --agent lean. Le modèle sait traduire des preuves depuis d’autres assistants vers Lean 4. Il sait également déboguer du code Lean défaillant, et migrer entre versions majeures du langage. Pour la cryptographie, les logiciels critiques ou les mathématiques formalisées, c’est aujourd’hui la seule option ouverte à ce niveau de spécialisation.

Auto-hébergement : garder le code chez soi

C’est l’argument décisif pour les organisations qui ne peuvent pas envoyer leur code vers une API tierce. Secteur public, défense, banque, santé, juridique : la contrainte est la même partout.

Le matériel selon le profil

Servir le modèle, puis brancher le CLI

Trois chemins font consensus. Ollama reste le plus simple sur un poste de développeur. vLLM vise ensuite la production, avec un débit optimisé et une configuration plus exigeante. NVIDIA NIM couvre les infrastructures déjà outillées côté constructeur.

Le CLI accepte alors n’importe quel endpoint compatible avec l’API OpenAI. Vous le déclarez dans la section des fournisseurs de config.toml. Pointez l’adresse sur votre serveur, déclarez le modèle, et plus aucun token ne sort de votre réseau. Le sujet complet de l’auto-hébergement est traité dans l’article 8.

Mode programmatique : scripts et intégration continue

Le CLI tourne sans interface, ce qui ouvre les pipelines, les hooks Git et toute forme d’automatisme. Un avertissement s’impose avant d’aller plus loin.

Autrement dit, un vibe --prompt lancé sans préciser de profil approuve tout, y compris les commandes shell. Passez systématiquement un --agent explicite, ou verrouillez les outils autorisés.

# Tâche unique, bornée en tours et en outils
vibe --prompt "Mets à jour le CHANGELOG depuis le dernier tag" \
     --agent accept-edits \
     --max-turns 5 \
     --enabled-tools "read,write_file,bash" \
     --output json

# Confiance temporaire, limitée à cette invocation
vibe --trust --prompt "Analyse la couverture de tests"

Le drapeau --output accepte text, json et streaming, ce qui rend la sortie exploitable par un script. Le mode programmatique désactive par ailleurs les outils interactifs. L’agent ne pose donc plus de questions : il tranche.

Les raccourcis qui servent tous les jours

• Shift+Tab — bascule entre les profils d’agents en cours de session.
• @ suivi d’un nom — complète les chemins du projet, et joint les images.
• ! suivi d’une commande — exécute directement dans le shell, sans passer par l’agent.
• /compact — résume le contexte pour libérer de la place dans une session longue.
• /resume — reprend une session interrompue.
• /teleport — envoie la session dans le cloud.

Les limites à connaître

• Le teleport est à sens unique — une session partie dans le cloud se poursuit sur le web, sans retour possible vers le terminal.
• Le bac à sable web est en préversion — ses capacités et ses limites peuvent changer avant la disponibilité générale.
• Les modèles tiers ne se téléportent pas — la fonction exige une session sur un modèle Mistral.
• Windows reste secondaire — l’outil y fonctionne, mais Mistral cible officiellement UNIX. Prévoyez WSL.
• Les terminaux anciens rendent mal — l’interface Textual suppose un émulateur récent.
• Le raisonnement architectural a ses limites — sur un refactoring qui traverse des dizaines de fichiers, vérifiez toujours le plan avant de laisser exécuter.

À qui Vibe Code s’adresse vraiment

Quatre profils en tirent un bénéfice net.

• Les équipes en environnement réglementé — CLI ouvert, modèle à poids ouverts, exécution entièrement sur votre infrastructure. Le code ne sort jamais du réseau.
• Les développeurs attentifs au budget — le CLI est inclus dans les formules, et le mode clé API ne facture que les tokens consommés.
• Les codebases historiques — les modèles sont ajustables sur vos frameworks maison et vos langages internes, autrement invisibles.
• Les stacks déjà bâties sur MCP — l’agent s’y branche immédiatement, avec une granularité de permissions par outil.

Ce qu’il faut retenir

Vibe Code n’est pas l’agent de code le plus affûté sur le raisonnement architectural le plus exigeant. Son intérêt est ailleurs, et il est structurel. Un CLI ouvert, des poids publics, un auto-hébergement réellement supporté. S’y ajoutent une intégration MCP native et une exécution qui peut rester entièrement dans votre périmètre.

Pour démarrer, la progression compte plus que la configuration. Installez-le sur un projet réel, puis restez en plan quelques jours. Passez ensuite en accept-edits, quand vous avez vu comment l’agent raisonne. Ajoutez ensuite un ou deux subagents simples avant de vous lancer dans les skills élaborées.

Et gardez en tête le réglage qui surprend le plus : en mode programmatique, sans profil explicite, l’agent approuve tout. C’est la première ligne à écrire dans votre pipeline.