Développer en local

Après avoir créé une application, exécutez mistral dev depuis son répertoire pour démarrer la stack locale. La commande démarre les modules de l'application déclarés dans mistral.json ainsi qu'une passerelle locale, puis affiche leur statut, leurs URL et leurs logs. Laissez la commande active pendant vos modifications — chaque module utilise sa commande de développement configurée, y compris le rechargement à chaud lorsque celle-ci le prend en charge. Appuyez sur Ctrl-C pour arrêter les processus démarrés par cette exécution.

cd my-app
mistral dev

cd my-app
mistral dev

Lorsque l'application comporte un frontend, dev l'ouvre dans votre navigateur une fois que tous les modules sont prêts ; passez --no-open pour ignorer cette étape. Cette ouverture est ignorée en CI, via SSH et sous Linux sans affichage ; ouvrez plutôt l'URL de la passerelle affichée dans le terminal. Les ports sont alloués automatiquement ; si un port demandé est occupé, la CLI indique le port de remplacement.

Renseignez les valeurs d'environnement requises par vos fonctionnalités sélectionnées avant de démarrer l'application. dev transmet le fichier .env de l'application à ses modules.

Les appels à l'API Mistral via la passerelle locale s'exécutent au nom de l'organisation et de l'espace de travail sélectionnés par mistral login. Si vous n'êtes pas connecté, dev utilise MISTRAL_API_KEY issu du shell qui l'exécute, ou apiKey de votre configuration CLI, et recherche l'organisation et l'espace de travail associés à la clé. Une clé présente uniquement dans le fichier .env de l'application n'est pas utilisée pour cela. dev affiche l'identité au démarrage.

Si l'organisation ne peut pas être résolue, les modules locaux peuvent toujours démarrer, mais les appels à l'API Mistral via /api échouent. Exécutez mistral login ou vérifiez la clé, puis relancez dev.

Utilisez les noms de modules de mistral.json, séparés par des virgules :

mistral dev --filter server
mistral dev --filter web,server

mistral dev --filter server
mistral dev --filter web,server

Ces exemples supposent que votre application déclare des modules web et server. Incluez le backend lorsque vous exécutez un frontend qui en a besoin ; --filter ne démarre pas automatiquement les modules exclus.

Dans un terminal interactif, dev affiche une vue en temps réel du statut et des logs. Lorsque la sortie est redirigée, il écrit des lignes de log préfixées. Pour les scripts et les agents, utilisez un événement JSON par ligne :

mistral dev --json

mistral dev --json

Pour diagnostiquer un problème de passerelle, démarrez les modules sans elle et utilisez leurs URL individuelles :

mistral dev --no-gateway

mistral dev --no-gateway

Ce mode omet l'authentification de la passerelle et le proxy vers l'API Mistral. La CLI installée inclut la passerelle locale.

La capacité Postgres démarre une base locale dans Docker. Lancez Docker avant mistral dev. Complétez les paramètres d'environnement indiqués par vos capacités et consultez les logs si un service n'est pas prêt.

Une application générée est un simple dépôt — pas de runtime CLI, pas d'indirection de framework. Les modèles de fonctionnalités sont copiés tels quels, si bien que tout ce que contient l'application est du code source modifiable et que n'importe quel agent de codage (Vibe, Claude Code, Codex) peut y travailler directement. Utilisez la CLI pour les opérations dont elle a la charge — le scaffolding avec init, la modification de la sélection de fonctionnalités avec mistral apps capability add / remove / select, et la régénération du code de liaison généré pour les routes — et laissez l'agent modifier le code source obtenu. Consultez la section Mistral CLI pour l'ensemble des commandes disponibles et Mistral MCP pour connecter un agent à Mistral depuis la ligne de commande.