Avouons-le : gérer les versions de langages est l’enfer. nvm pour Node, pyenv pour Python, rbenv pour Ruby, sdkman pour Java, goenv pour Go… Chaque outil a sa syntaxe, ses bugs, ses fichiers de config éparpillés. Et puis un jour, vous clonez un projet qui utilise tous ces langages, et vous passez 45 minutes à installer les bonnes versions. Mise (prononcé « mise en place ») résout ce problème définitivement. Un seul binaire, un seul fichier de config, 200+ langages. Voici comment l’adopter en 30 minutes.

Qu’est-ce que Mise ?

Mise est un gestionnaire de versions universel écrit en Rust par Jeff Dickey (ex-ingénieur Heroku). Sorti en 2023 comme fork de asdf, il est devenu en trois ans le standard de fait pour la gestion de versions en local, dépassant asdf en téléchargements mensuels (2,8 millions en mai 2026 selon crates.io).

Ce qui distingue Mise de ses concurrents :

  • Un seul fichier de config : .mise.toml ou .config/mise/config.toml. Plus besoin de .nvmrc, .python-version, .ruby-version, .tool-versions — un fichier pour tout.
  • Installation automatique : Mise détecte les outils requis dans un projet et les installe automatiquement quand vous entrez dans le dossier.
  • Performance native : écrit en Rust, Mise résout les dépendances et télécharge les binaires en parallèle. L’installation de 5 langages prend 12 secondes là où asdf met 2 minutes.
  • Shims dynamiques : les shims de Mise sont 8 fois plus rapides que ceux d’asdf grâce à un cache intelligent et à une résolution paresseuse.
  • Pas de plugin system fragile : contrairement à asdf qui dépend de plugins Bash maintenus par la communauté, Mise compile les outils directement depuis leur source officielle via un backend unifié.

En juin 2026, Mise supporte 215 langages et outils, de Node.js 24 à PHP 8.4, en passant par Bun, Deno, Terraform, kubectl, et même ffmpeg.

Installation de Mise

macOS et Linux

# Via Homebrew (recommandé)
brew install mise

# Via le script d'installation officiel
curl https://mise.run | sh

# Via cargo (si vous avez Rust)
cargo install mise

# Activation dans le shell — ajoutez ceci à votre .zshrc ou .bashrc
eval "$(mise activate zsh)"  # ou bash, fish

# Vérification
mise --version
# mise 2026.6.0 (linux-x64, rust 1.85)

Windows

# Via Scoop
scoop install mise

# Via winget
winget install jdx.mise

# Activation — ajouter à $PROFILE
mise activate pwsh | Out-String | Invoke-Expression

Premiers pas : installer des langages

La syntaxe de Mise est volontairement minimaliste :

# Installer une version spécifique
mise use node@22
mise use python@3.12
mise use go@1.23

# Installer la dernière version stable
mise use node@latest

# Lister les versions disponibles d'un outil
mise ls-remote node

# Lister ce qui est installé localement
mise list
# node    22.12.0  (active)
# python  3.12.3   (active)
# go      1.23.1   (active)

# Définir une version globale (pour tous les projets)
mise use -g node@22

# Voir la version utilisée dans le dossier courant
mise current
# node    22.12.0
# python  3.12.3

Le fichier .mise.toml : le cœur du système

Quand vous lancez mise use node@22 dans un dossier, Mise crée (ou modifie) un fichier .mise.toml. Ce fichier est la source unique de vérité pour toutes les versions de votre projet :

# .mise.toml — Exemple pour un projet full-stack JavaScript + Python
[tools]
node = "22"
  python = "3.12"
  bun = "2"
  postgres = "17"      # Mise gère aussi les bases de données !
  redis = "7"
  terraform = "1.9"
  kubectl = "1.31"

[env]
# Variables d'environnement spécifiques au projet
NODE_ENV = "development"
DATABASE_URL = "postgresql://localhost:5432/monprojet"

[settings]
# Options de comportement
always_keep_download = true   # Garde les archives pour usage hors-ligne
verbose = false

[tasks]
# Tâches spécifiques au projet (comme un Makefile, mais en mieux)
"dev" = "bun run dev"
"test" = "bun test --coverage"
"lint" = "bun run lint && ruff check ."
"db:setup" = "createdb monprojet && bun run db:migrate"
"deploy:staging" = "fly deploy --app monprojet-staging"

Committez ce fichier dans votre repo. Quand un nouveau développeur clone le projet et tape mise install, toutes les versions exactes sont installées automatiquement. Fini le onboarding à 15 étapes.

Installation automatique au cd

La killer feature de Mise : l’installation automatique quand vous entrez dans un dossier. Activez-la :

# Dans ~/.config/mise/config.toml
[settings]
activate_aggressive = true

Résultat : quand vous faites cd ~/projets/mon-saas, Mise :

  1. Lit le .mise.toml du dossier
  2. Compare avec les versions installées
  3. Installe automatiquement ce qui manque
  4. Active les bonnes versions dans votre shell

Vous pouvez aussi utiliser l’auto-switching passif (sans installation auto) avec mise activate dans votre shell. Quand vous changez de dossier, les versions changent, point. Pas de nvm use à taper.

Mise vs asdf : pourquoi migrer maintenant

Si vous utilisez asdf, voici les différences concrètes :

Critère asdf Mise
Format config .tool-versions (lignes) .mise.toml (structuré)
Installation de 5 outils ~2 min 30 s ~12 s
Temps de résolution shim ~25 ms ~3 ms
Plugins 700+ plugins Bash 215 backends natifs Rust
Gestion variables d’env ❌ Non ✅ Oui, dans .mise.toml
Tâches projet ❌ Non ✅ Oui, comme Makefile
Installation auto au cd ❌ Non ✅ Oui
Résolution parallèle ❌ Séquentielle ✅ Parallèle (8 workers)

La migration est indolore :

# 1. Exporter la config asdf
asdf current > .tool-versions

# 2. Convertir en .mise.toml (automatique)
mise trust  # détecte et convertit les anciens .tool-versions

# 3. Désinstaller asdf (optionnel, mais recommandé pour éviter les conflits)
brew uninstall asdf
rm -rf ~/.asdf

# 4. Nettoyer votre shell rc
# Supprimez les lignes .asdf.sh et remplacez par :
eval "$(mise activate zsh)"

Cas pratique : monter un environnement full-stack en 5 minutes

Scénario : vous démarrez un projet Next.js + API Python avec PostgreSQL et Redis.

# 1. Créer le projet
mkdir mon-saas && cd mon-saas
git init

# 2. Initialiser Mise avec les outils requis
mise use node@22
mise use python@3.12
mise use postgres@17
mise use redis@7

# 3. Ajouter les variables d'environnement
mise set NODE_ENV=development
mise set DATABASE_URL=postgresql://localhost/mon_saas_dev

# 4. Ajouter des tâches pratiques
cat >> .mise.toml << 'EOF'
[tasks]
"setup" = "npm ci && pip install -r requirements.txt && createdb mon_saas_dev"
"dev" = "mise run setup && (npm run dev &) && python api/main.py"
"test" = "npm test && pytest"
"db:reset" = "dropdb mon_saas_dev && createdb mon_saas_dev && npm run db:migrate && npm run db:seed"
EOF

# 5. Vérifier
mise doctor
# ✅ mise 2026.6.0 — All checks passed
# ✅ 4 tools installed correctly
# ✅ Shell integration active

# 6. C'est prêt
mise run dev
# Lance Next.js sur :3000 et l'API FastAPI sur :8000

Ce .mise.toml est commité. Le développeur suivant fait git clone puis mise install && mise run setup et il a exactement le même environnement que vous. Pas de README à rallonge, pas de « ah oui il faut Python 3.11.2 exactement sinon ça casse ».

Tâches Mise : le Makefile moderne

Les [tasks] de Mise remplacent Makefile, npm scripts éparpillés, et justfile. Pourquoi c’est mieux :

  • Syntaxe TOML : indentée, lisible, pas de tab vs espace.
  • Héritage des variables d’environnement : les [env] sont automatiquement injectés dans les tâches.
  • Dépendances entre tâches : une tâche peut appeler mise run autre-tache.
  • Compatibilité cross-platform : Mise traduit automatiquement les chemins Windows ⇔ Unix.
  • Parallélisation : mise run [task1, task2] les exécute en parallèle.
# Exemple avancé : CI local avant push
[tasks]
"ci" = [
  "mise run lint",
  "mise run test",
  "mise run build",
]
"lint" = "bun run lint && ruff check . && shellcheck scripts/*.sh"
"test" = "bun test --coverage"
"build" = "bun run build && python -m build"
"deploy:preview" = "fly deploy --app mon-saas-preview"
"deploy:prod" = "mise run ci && fly deploy --app mon-saas"

Astuces avancées

1. Version management par dossier

# ~/.config/mise/config.toml — configuration globale
[tools]
node = "22"        # Version par défaut partout
python = "3.12"

# ~/projets/legacy/.mise.toml — surcharge locale
[tools]
node = "18"        # Ce projet legacy tourne sur Node 18

2. Plugins expérimentaux

# Mise supporte les plugins via son système de backends
mise plugin install cmake      # Plugin communautaire
mise use cmake@latest

3. Alias de versions

# Dans ~/.config/mise/config.toml
[alias]
node_lts = "22"
python_prod = "3.12"

# Puis :
mise use node@node_lts
mise use python@python_prod

4. Watch mode pour les tâches

# Relance les tests à chaque modification
mise watch test
# Équivalent à : nodemon --exec "bun test" mais géré par Mise

5. Nettoyage automatique

# Supprime les versions non utilisées depuis 30 jours
mise prune --dry-run  # Aperçu
mise prune            # Exécution

Limitations à connaître

  • Pas encore de GUI : tout se fait en CLI. Si vous préférez une interface graphique pour gérer les versions, Mise n’est pas pour vous.
  • Backends en développement : sur les 215 outils supportés, une trentaine de backends sont encore en « beta » (notamment Java via GraalVM, .NET SDK).
  • Windows : support expérimental : la version Windows fonctionne bien pour Node, Python, Go, mais certains backends Unix-only (comme postgres) ne sont pas disponibles.
  • Courbe d’apprentissage TOML : si votre équipe n’a jamais touché au TOML, prévoyez 10 minutes d’explication.

Conclusion

Mise fait partie de ces outils qui, une fois adoptés, deviennent invisibles tellement ils sont utiles. Vous ne pensez plus aux versions, elles sont juste… là. Bonnes. Au bon endroit. Pour tous les langages. C’est le genre d’outil qui donne envie de supprimer 5 autres outils juste pour le plaisir de faire le ménage.

En 2026, si vous gérez encore vos versions avec 4 outils différents, vous perdez du temps. Installez Mise (brew install mise), convertissez vos projets (mise trust), et profitez du temps gagné pour… coder.

Sources et références

W
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.