Mistral Vibe CLI avec Devstral en local : mise en route
Mistral Vibe CLI est l'agent de code en terminal publié par Mistral AI avec Devstral 2, sous licence Apache 2.0 d'après l'annonce. Par défaut, il envoie vos requêtes à l'API de Mistral. Ce guide l'installe, puis le branche sur un Devstral Small 2 servi par Ollama sur votre machine, grâce au fichier config.toml décrit dans la documentation « offline models ». Il termine par les limites réelles d'un agent de code qui tourne entièrement en local.
#Mistral Vibe CLI : ce que c'est, et ce que ce n'est pas
Mistral Vibe CLI est un programme en ligne de commande, écrit en Python, publié en décembre 2025 en même temps que Devstral 2 et Devstral Small 2. Vous le lancez dans le dossier d'un projet, vous décrivez une tâche en langage naturel, et l'agent lit vos fichiers, propose des modifications, exécute des commandes et itère jusqu'au résultat. C'est le même principe que Claude Code, OpenCode ou Aider, mais conçu autour des modèles Devstral, qui ont été entraînés pour ce type de boucle agentique.
Le code source est publié sur GitHub dans le dépôt mistralai/mistral-vibe, sous licence Apache 2.0 selon l'annonce de Mistral. Vous pouvez le lire, le modifier et l'utiliser en entreprise sans redevance. La CLI sait parler à l'API de Mistral, mais aussi à n'importe quel serveur qui expose une API au format OpenAI : Ollama, llama.cpp, LM Studio ou vLLM. C'est ce second mode, documenté dans la page « offline models », qui nous intéresse ici.
Pourquoi vouloir un Vibe CLI local plutôt que l'API ? Trois raisons reviennent. Le code ne quitte pas la machine, ce qui compte pour du code propriétaire ou soumis à un accord de confidentialité. Il n'y a pas de facture à l'usage ni de quota : vous payez l'électricité et le matériel que vous avez déjà. Enfin, l'outil continue de fonctionner hors ligne ou derrière un pare-feu strict. En échange, vous perdez le modèle Devstral 2 de 123 milliards de paramètres, trop gros pour un poste de travail, et vous acceptez une vitesse plus faible qu'un serveur de production.
#Prérequis : Python, Ollama et la mémoire pour Devstral Small 2
Ce guide t'amène au modèle. Le kit t'amène au copilote qui code dans ton éditeur.
- Espace en ligne à vie
- PDF + fichiers
- Remboursé 30 j
Avant d'installer quoi que ce soit, vérifiez ces quatre points. Ils évitent les trois quarts des échecs rencontrés avec les agents de code locaux.
- Système
- Linux ou macOS sont les cibles principales. Sous Windows, utilisez WSL2 (Ubuntu) : la CLI s'y installe comme sous Linux et Ollama pour Windows reste joignable depuis WSL via l'adresse localhost.
- Python récent
- La CLI est distribuée comme paquet Python. Le dépôt indique la version minimale requise dans son README ; au moment de l'annonce, il s'agissait d'un Python 3.12 ou plus récent. Vérifiez avec python3 --version avant de continuer.
- Ollama installé et démarré
- Ollama sert le modèle et expose une API compatible OpenAI sur http://localhost:11434. Si ce n'est pas encore fait, notre guide d'installation d'Ollama couvre les trois systèmes.
- Mémoire pour un modèle 24B
- Devstral Small 2 compte 24 milliards de paramètres. En quantification Q4_K_M, les poids occupent environ 14 Go, auxquels s'ajoute le cache de contexte. Comptez un GPU de 24 Go (RTX 3090, RTX 4090) ou un Mac avec 32 Go de mémoire unifiée pour un fonctionnement confortable. L'annonce de Mistral cite d'ailleurs « une RTX 4090 ou un Mac avec 32 Go de RAM » comme configuration cible.
Avec un GPU de 16 Go (RTX 4080, RTX 5070 Ti de bureau), le modèle Q4 tient, mais le contexte déborde vite vers la mémoire système, et la vitesse chute. Avec 12 Go (RTX 3060, RTX 4070), Ollama répartit les couches entre GPU et CPU : l'agent fonctionne, mais chaque tour de boucle prend plusieurs dizaines de secondes. Nous n'avons pas chiffré ces débits sur ces cartes ; retenez simplement que 24 Go est le seuil de confort pour un 24B utilisé en agent, où le contexte grossit à chaque fichier lu.
#Installer Mistral Vibe CLI
Mistral propose un script d'installation en une ligne, qui met en place la CLI dans un environnement isolé. C'est la méthode recommandée dans le README du dépôt.
Si vous préférez contrôler l'installation, le paquet est publié sur PyPI sous le nom mistral-vibe. L'outil uv l'installe dans un environnement dédié, sans toucher à vos autres projets Python. Le pip classique fonctionne aussi, de préférence dans un environnement virtuel.
Vérifiez ensuite que la commande vibe est accessible. Si le terminal ne la trouve pas, fermez-le et rouvrez-le : le script d'installation ajoute un dossier à votre PATH, pris en compte au prochain démarrage du shell.
#Préparer Devstral Small 2 dans Ollama
Devstral Small 2 est publié par Mistral sous licence Apache 2.0, avec une fenêtre de contexte de 256 000 tokens. Ollama le propose dans sa bibliothèque ; la commande ci-dessous télécharge la version par défaut, en quantification 4 bits. Le téléchargement représente environ 14 Go.
Le nom exact du modèle dans la bibliothèque Ollama peut évoluer (variante de quantification, suffixe de taille). Si la commande échoue, cherchez « devstral » sur ollama.com/library et reprenez le nom affiché. C'est ce nom, tel qu'il apparaît dans ollama list, que vous recopierez dans la configuration de Vibe.
Il reste un réglage décisif : la longueur de contexte. Ollama charge les modèles avec un contexte par défaut court, souvent 4 096 tokens. Pour un agent de code, c'est beaucoup trop peu : le prompt système de Vibe, la liste des outils, le contenu des fichiers lus et l'historique de la session dépassent cette taille en quelques échanges. Le modèle oublie alors le début de la conversation et l'agent tourne en rond. Fixez un contexte de 32 000 tokens au minimum, par exemple avec un Modelfile dérivé.
Vous pouvez aussi fixer le contexte globalement avec la variable d'environnement OLLAMA_CONTEXT_LENGTH au démarrage du service Ollama. Le Modelfile a l'avantage de ne concerner que ce modèle et de garder un nom explicite. Un contexte plus long consomme plus de mémoire : à 32k tokens sur un 24B, prévoyez 2 à 4 Go supplémentaires selon le type de cache KV. Sur 24 Go, c'est la limite confortable ; au-delà de 64k, surveillez la mémoire avec nvidia-smi.
#Brancher le modèle local dans config.toml
Mistral Vibe CLI lit sa configuration dans le fichier ~/.vibe/config.toml. La documentation « offline models » y décrit deux tableaux : providers, qui déclare un serveur et son adresse, et models, qui associe un nom de modèle à un fournisseur. Une clé active_model désigne le modèle utilisé par défaut. Voici une configuration complète pour l'Ollama préparé ci-dessus.
Trois détails méritent une explication. L'adresse se termine par /v1, car Vibe parle le dialecte OpenAI et Ollama n'expose ce format que sous ce préfixe ; l'API native d'Ollama, sans /v1, ne conviendra pas. La clé api_key_env_var reste vide : Ollama n'exige aucune authentification en local. Les prix sont à zéro pour que l'estimation de coût affichée par la CLI reste cohérente ; ils n'ont aucun effet sur le fonctionnement.
Pour un autre serveur local, seule la section providers change. Avec llama.cpp (llama-server), l'adresse est en général http://localhost:8080/v1 ; avec LM Studio, http://localhost:1234/v1 ; avec vLLM, http://localhost:8000/v1. Dans tous les cas, le champ name du modèle doit être l'identifiant que ce serveur attend, celui qu'il renvoie sur sa route /v1/models.
Vous pouvez déclarer plusieurs modèles, par exemple Devstral Small 2 en local et Devstral 2 via l'API Mistral, puis basculer de l'un à l'autre dans la session. Pour le fournisseur Mistral, la clé API se lit dans une variable d'environnement, classiquement MISTRAL_API_KEY ; la clé n'a pas à figurer en clair dans le fichier. Si votre objectif est le 100 % local, n'ajoutez simplement aucun fournisseur distant : rien ne sortira de la machine.
#Première session : lancer vibe et vérifier le modèle
- 01Se placer dans un projetOuvrez un terminal dans le dossier d'un dépôt Git, de préférence propre (git status sans modification en attente). L'agent travaille sur les fichiers du dossier courant ; un dépôt propre permet de relire et d'annuler ses changements avec git diff et git checkout.
- 02Lancer la CLITapez vibe. Au tout premier lancement, la CLI peut proposer de saisir une clé API Mistral et de créer son dossier ~/.vibe. Si vous avez écrit config.toml avant, votre fournisseur local est déjà connu. Si l'invite de clé apparaît quand même, consultez /help : selon la version, elle se passe ou se laisse vide quand un fournisseur local est configuré.
- 03Vérifier le modèle actifL'interface affiche le modèle en cours. Il doit s'agir de votre alias devstral-small-local. La commande /help liste les commandes disponibles dans la session, dont celle qui change de modèle si vous en avez déclaré plusieurs.
- 04Donner une première tâche bornéeCommencez petit : « Lis le README et résume l'architecture du projet en cinq lignes », puis « Ajoute un test unitaire pour la fonction X dans le fichier Y ». Observez la première réponse : si le modèle répond sans utiliser d'outil, ou en inventant un chemin de fichier, le problème est en général le contexte trop court ou un modèle qui n'a pas été préparé au tool calling.
- 05Relire avant d'accepterVibe demande confirmation avant les actions sensibles, comme l'écriture de fichiers ou l'exécution de commandes. Lisez chaque diff proposé. Un modèle de 24B en local se trompe plus souvent qu'un modèle de 123B servi par l'API, surtout sur des bases de code larges : la relecture fait partie du flux de travail, pas de l'exception.
Pendant la session, gardez un œil sur la charge d'Ollama : la commande ollama ps indique le modèle chargé, la part en GPU et en CPU, et le contexte effectif. Si vous voyez une répartition partielle sur le CPU alors que vous pensiez tenir en mémoire vidéo, c'est le contexte qui a fait déborder la carte.
#Limites d'un Vibe CLI 100 % local
Un agent de code local fonctionne, mais il ne se compare pas terme à terme avec la version API. Voici ce à quoi vous attendre, sans chiffre inventé : nous n'avons pas conduit de banc de mesure pour ce guide, et les scores publiés par Mistral concernent les modèles servis dans des conditions de référence, pas une machine de bureau avec un modèle quantifié.
- Devstral 2 reste hors de portée
- Le grand modèle de 123 milliards de paramètres demande des dizaines de gigaoctets de mémoire même très quantifié. En local, vous travaillez avec Devstral Small 2, dont Mistral annonce 68,0 % sur SWE-bench Verified, contre 72,2 % pour Devstral 2. L'écart est modeste sur ce banc, mais il se ressent sur les tâches longues et les dépôts volumineux.
- La quantification change le modèle
- Le score annoncé vaut pour les poids complets. Un Q4_K_M dégrade légèrement la précision ; un Q8_0 la préserve mieux mais demande environ 26 Go pour les seuls poids, donc une carte de 32 Go ou un Mac bien doté. Choisir sa quantification est un compromis à faire en connaissance de cause.
- Le contexte local est bien plus court que 256k
- Devstral Small 2 accepte 256 000 tokens, mais vous ne les servirez pas sur 24 Go. Entre 32k et 64k tokens, l'agent couvre un module ou un petit service. Pour un monorepo, il faut cadrer la tâche fichier par fichier.
- La vitesse dépend du matériel, pas de la CLI
- Un 24B dense génère moins vite qu'un modèle MoE de taille comparable à mémoire égale. Chaque tour de boucle de l'agent inclut une relecture du contexte entier : plus la session dure, plus chaque réponse tarde. Prévoyez des sessions courtes et des tâches découpées.
- Tool calling et formats
- L'agent repose sur des appels d'outils structurés. Un modèle quantifié peut, de temps en temps, produire un appel mal formé que la CLI rejette. Devstral a été entraîné pour ce type d'usage et s'en sort bien mieux qu'un modèle généraliste, mais le phénomène n'est pas nul.
- Un outil jeune
- La CLI a été publiée en décembre 2025 et évolue à un rythme rapide. Les commandes, le format de configuration et l'intégration aux éditeurs changent. Mettez à jour régulièrement (uv tool upgrade mistral-vibe, ou relancez le script d'installation) et relisez le journal des versions sur GitHub avant de vous plaindre d'un comportement.
L'annonce de Mistral mentionne aussi une intégration aux éditeurs par le protocole ACP, notamment avec Zed. Si vous préférez un éditeur au terminal, notre guide Zed + Ollama montre comment cet éditeur dialogue déjà avec un modèle local ; combiner les deux revient à laisser Vibe piloter l'agent et Zed afficher les diffs.
#Dépannage
- « vibe : commande introuvable »
- Le dossier des exécutables n'est pas dans votre PATH. Rouvrez le terminal. Avec uv, le chemin est en général ~/.local/bin ; vérifiez avec uv tool dir --bin et ajoutez-le à votre fichier de shell si nécessaire.
- Erreur de connexion vers localhost:11434
- Ollama n'est pas démarré, ou il écoute sur une autre adresse. Testez curl http://localhost:11434/v1/models. Sous WSL2, assurez-vous qu'Ollama tourne bien côté Windows et que la variable OLLAMA_HOST n'a pas été restreinte.
- Le modèle est inconnu du serveur
- Le champ name de la section models ne correspond pas à un modèle présent dans ollama list. Recopiez le nom exact, suffixe compris, y compris celui de votre Modelfile dérivé si vous en avez créé un.
- L'agent oublie ce qu'il vient de lire
- Contexte trop court. Vérifiez avec ollama ps la valeur de contexte réellement chargée ; si elle vaut 4 096, votre Modelfile ou votre variable OLLAMA_CONTEXT_LENGTH n'ont pas été pris en compte.
- Réponses très lentes, GPU peu utilisé
- Une partie du modèle est sur le CPU. Réduisez le contexte, passez à une quantification plus légère, ou fermez les autres modèles chargés par Ollama (OLLAMA_MAX_LOADED_MODELS).
- La CLI exige une clé API alors que tout est local
- Comportement qui dépend de la version. Vérifiez que config.toml est bien à l'emplacement ~/.vibe/config.toml, qu'active_model pointe sur un alias existant, puis consultez la page « offline models » de la documentation pour la marche à suivre à jour.
#Pour aller plus loin
Vibe CLI est un bon choix si vous êtes attaché à l'écosystème Mistral et à Devstral. Si vous voulez comparer avant de vous installer, OpenCode joue dans la même catégorie avec davantage de fournisseurs supportés, et la question du modèle de code local se pose indépendamment de l'agent choisi.
Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.