mise : le gestionnaire de versions polyvalent et rapide

mise (prononcé “MEEZ ahn plahs”) fait tout ce que fait asdf, mais en mieux. Écrit en Rust, mise installe vos outils de développement (Node.js, Python, Go, Terraform…), gère vos variables d’environnement par projet, et exécute des tasks — le tout avec une seule commande. Compatible avec les fichiers .tool-versions d’asdf, mise offre des performances 10x supérieures, une meilleure sécurité supply chain, et des fonctionnalités absentes d’asdf comme les backends npm/pipx et la gestion d’environnements.

# Installer mise et Node.js 22
curl https://mise.run | sh
~/.local/bin/mise use -g node@22
node --version
# v22.13.1

Version utilisée dans ce guide : mise 2026.1.7

Ce que vous allez apprendre

Comprendre les avantages de mise vs asdf (performance, sécurité, fonctionnalités)
Installer mise sur Linux, macOS et Windows
Gérer vos outils avec les backends (core, aqua, npm, pipx, github)
Configurer des environnements par projet avec mise.toml
Créer et exécuter des tasks pour automatiser votre workflow
Migrer depuis asdf en conservant vos fichiers .tool-versions

Pourquoi choisir mise plutôt qu’asdf ?

Critère	mise	asdf
Performance	~5ms au changement de répertoire	~120ms par appel via shim
Langage	Rust (binaire unique)	Bash / Go (0.16+)
Windows	✅ Supporté	❌ Non supporté
Sécurité	Backends vérifiés (Cosign, SLSA)	Plugins tiers non vérifiés
Tasks	✅ Intégrés	❌ Absent
Environnements	✅ Variables par projet	❌ Absent
Backends	core, aqua, npm, pipx, cargo, github	Plugins uniquement

Fonctionnement de mise

Architecture mise : CLI, dev tools, environnements, tasks et backends

mise est organisé autour de quatre piliers :

Pilier	Description	Configuration
Dev Tools	Gestion des versions d’outils	`[tools]`
Environments	Variables d’environnement par projet	`[env]`
Tasks	Scripts automatisés	`[tasks]`
Backends	Sources d’installation (core, aqua, npm…)	Automatique

Où sont stockées les données ?

~/.local/share/mise/
├── installs/           # Outils installés
│   ├── node/
│   │   └── 22.13.1/
│   └── python/
│       └── 3.12.8/
├── shims/              # Shims (optionnel)
└── plugins/            # Plugins asdf (legacy)

~/.config/mise/
└── config.toml         # Configuration globale

Installation de mise

Installer mise
Fenêtre de terminal
```
curl https://mise.run | sh
```
Le binaire est installé dans ~/.local/bin/mise.

Activer mise dans votre shell (Bash)

echo 'eval "$(~/.local/bin/mise activate bash)"' >> ~/.bashrc
source ~/.bashrc

Activer mise dans votre shell (Zsh)

echo 'eval "$(~/.local/bin/mise activate zsh)"' >> ~/.zshrc
source ~/.zshrc

Vérifier l’installation
Fenêtre de terminal
```
mise --version
mise doctor
```

brew install mise
echo 'eval "$(mise activate zsh)"' >> ~/.zshrc
source ~/.zshrc

# Via winget
winget install jdx.mise

# Ou via scoop
scoop install mise

Commandes essentielles

Installer et utiliser des outils

# Installer un outil (ajoute à mise.toml)
mise use node@22
mise use python@3.12

# Installer globalement (pour tout le système)
mise use -g node@22

# Installer sans modifier mise.toml
mise install node@22

# Exécuter une commande avec un outil spécifique
mise exec node@20 -- node -v

# Raccourci pour mise exec
mise x python@3.11 -- python --version

Lister et mettre à jour

# Lister les outils installés
mise list

# Voir les versions disponibles
mise list-all node | tail -10

# Mettre à jour tous les outils
mise upgrade

# Mettre à jour et bumper les versions dans mise.toml
mise upgrade --bump

Configuration actuelle

# Voir la configuration active
mise current

# Voir les fichiers de config chargés
mise config

# Voir les détails d'un outil
mise tool node

Configuration avec mise.toml

Le fichier mise.toml remplace .tool-versions avec plus de fonctionnalités :

# Versions d'outils
[tools]
node = "22"
python = "3.12"
terraform = "1.9"

# Variables d'environnement
[env]
NODE_ENV = "development"
DATABASE_URL = "postgres://localhost/mydb"

# Tasks (scripts)
[tasks.dev]
run = "npm run dev"
description = "Démarre le serveur de développement"

[tasks.test]
run = "npm test"
depends = ["lint"]

[tasks.lint]
run = "npm run lint"

Hiérarchie des fichiers de configuration :

projet/
├── mise.local.toml      # Surcharges locales (git-ignored)
├── mise.toml            # Config partagée avec l'équipe
└── backend/
    └── mise.toml        # Config spécifique au sous-dossier

Backends : d’où viennent les outils ?

mise peut installer des outils depuis 17 backends différents. Chaque backend est un gestionnaire de paquets ou un écosystème que mise sait utiliser.

Vue d’ensemble des backends

Backend	Usage	Exemple
core	Outils intégrés (node, python, go…)	`mise use node@22`
aqua	Registry aqua (2200+ outils vérifiés)	`mise use aqua:hashicorp/terraform`
github	Binaires GitHub Releases	`mise use github:BurntSushi/ripgrep`
gitlab	Binaires GitLab Releases	`mise use gitlab:gitlab-org/cli`
npm	Paquets npm globaux	`mise use npm:prettier@3`
pipx	Paquets Python CLI (isolés)	`mise use pipx:black`
cargo	Crates Rust (compilation)	`mise use cargo:ripgrep`
go	Paquets Go (compilation)	`mise use go:github.com/go-task/task`
gem	Gems Ruby	`mise use gem:rails`
asdf	Plugins asdf (legacy)	`mise use asdf:ruby@3.3`
vfox	Plugins vfox	`mise use vfox:mise-plugins/vfox-php`
http	Téléchargement direct	`mise use http:dart`

Le backend aqua : sécurité intégrée

Aqua est le backend recommandé pour la plupart des outils CLI. Il offre :

2200+ outils disponibles sans plugins
Vérification automatique des signatures (Cosign, SLSA, minisign)
Attestations GitHub pour prouver l’origine du build
Support Windows natif
Registre intégré dans le binaire mise (pas de téléchargement)

Qu’est-ce qu’aqua ?

Aqua est un projet open source créé par Shunsuke Suzuki. C’est un gestionnaire de versions déclaratif écrit en Go, avec un focus fort sur la sécurité et la reproductibilité.

Le cœur d’aqua est son Standard Registry (aquaproj/aqua-registry) : un dépôt contenant 2200+ définitions d’outils sous forme de fichiers YAML. Chaque définition décrit :

L’URL de téléchargement pour chaque OS/architecture
Le checksum SHA256 attendu
Les méthodes de vérification cryptographique (Cosign, SLSA, minisign)
Les binaires à exposer sur le PATH

Exemple de définition (simplifié) :

packages:
  - type: github_release
    repo_owner: hashicorp
    repo_name: terraform
    asset: terraform_{{.Version}}_{{.OS}}_{{.Arch}}.zip
    checksum:
      type: github_release
      asset: terraform_{{.Version}}_SHA256SUMS

Comment mise utilise aqua (sans installer le CLI)

mise n’utilise pas le CLI aqua. Le registre aqua est compilé directement dans le binaire mise à chaque release (“baked-in registry”). mise a sa propre implémentation en Rust qui sait lire ces définitions YAML.

# Voir les backends disponibles
mise backends ls
# aqua, asdf, cargo, conda, core, dotnet, forgejo, gem, github,
# gitlab, go, npm, pipx, spm, http, s3, ubi, vfox

# Voir les sources disponibles pour un outil
mise registry kubectl
# aqua:kubernetes/kubernetes/kubectl asdf:asdf-community/asdf-kubectl

mise registry terraform
# aqua:hashicorp/terraform asdf:mise-plugins/mise-hashicorp vfox:mise-plugins/vfox-terraform

Quand vous faites mise use terraform, mise :

Cherche terraform dans son registre interne
Trouve aqua:hashicorp/terraform comme backend préféré
Télécharge le binaire depuis GitHub Releases
Vérifie le checksum SHA256
Si configuré, vérifie les signatures Cosign/SLSA/GitHub Attestations

# Vérifier les outils aqua disponibles (2203 outils)
mise doctor 2>&1 | grep "baked in"
# aqua:
#   baked in registry tools: 2203

Pourquoi aqua plutôt que les plugins asdf ?

Aspect	Plugins asdf	Registre aqua
Format	Scripts shell	YAML déclaratif
Exécution de code	Oui (dangereux)	Non
Vérification checksums	Rare	Systématique
Signatures cryptographiques	Non	Cosign, SLSA, minisign
Maintenance	Fragmentée (1 repo/plugin)	Centralisée (186 contributeurs)

Exemples pratiques avec vrais outputs

# Installer ripgrep via aqua (vérification automatique)
mise use -g ripgrep
# mise ripgrep@15.1.0  ✓ installed

# Installer kubectl via aqua
mise use -g kubectl
# mise kubectl@1.35.0  checksum kubectl
# mise kubectl@1.35.0  extract kubectl
# mise kubectl@1.35.0 ✓ installed

# CLI npm sans polluer node_modules
mise use -g npm:prettier@3
mise use -g npm:@anthropic-ai/claude-code

# Outils Python CLI isolés avec pipx
mise use -g pipx:black
mise use -g pipx:ansible

# Binaires depuis GitHub (quand pas dans aqua)
mise use -g github:junegunn/fzf
mise use -g github:sharkdp/bat

# GitLab CLI depuis GitLab
mise use -g gitlab:gitlab-org/cli

Priorité des backends

Quand un outil est disponible dans plusieurs backends, mise utilise une priorité :

aqua — préféré pour la sécurité et les performances
github / gitlab — pour les outils non disponibles dans aqua
asdf — uniquement si nécessaire (plugins tiers non vérifiés)

Vous pouvez forcer un backend spécifique :

# Forcer le backend aqua
mise use aqua:hashicorp/terraform

# Forcer le backend asdf (si plugin spécifique nécessaire)
mise use asdf:ruby@3.3

Configuration de la vérification aqua

Par défaut, mise active la vérification de checksums. Vous pouvez renforcer la sécurité en activant les vérifications cryptographiques :

[settings.aqua]
# Vérification Cosign (signatures sigstore)
cosign = true

# Vérification SLSA (provenance des builds)
slsa = true

# Attestations GitHub Actions
github_attestations = true

Ou par variables d’environnement (utile en CI/CD) :

export MISE_AQUA_COSIGN=true
export MISE_AQUA_SLSA=true
export MISE_AQUA_GITHUB_ATTESTATIONS=true

Gestion des environnements

mise peut définir des variables d’environnement par projet :

[env]
# Variables simples
NODE_ENV = "development"
PORT = "3000"

# Charger depuis un fichier .env
_.file = ".env"

# Variables conditionnelles par environnement
[env.production]
NODE_ENV = "production"
DEBUG = "false"

Environnements multiples :

# Créer un fichier mise.production.toml
# Activer avec MISE_ENV
MISE_ENV=production mise exec -- node server.js

Tasks : automatiser votre workflow

Les tasks de mise remplacent les scripts npm, Makefile, ou just avec des avantages uniques :

Exécution parallèle par défaut (4 jobs simultanés)
Skip automatique si les fichiers n’ont pas changé (sources/outputs)
Watch mode intégré pour rebuild automatique
Dépendances entre tasks avec exécution intelligente
Scripts en fichiers avec coloration syntaxique dans l’éditeur

Syntaxe de base

Deux façons de définir des tasks : en TOML (simple) ou en fichiers (complexe).

TOML (mise.toml)
Fichiers (mise-tasks/)

# Syntaxe courte pour les tasks simples
[tasks]
build = "cargo build"
test = "cargo test"
lint = "cargo clippy"

# Syntaxe détaillée avec options
[tasks.dev]
run = "npm run dev"
description = "Lance le serveur de développement"

[tasks.build]
run = "cargo build"
description = "Compile le projet"
alias = "b"  # mise run b
sources = ["Cargo.toml", "src/**/*.rs"]
outputs = ["target/debug/mycli"]

#!/usr/bin/env bash
#MISE description="Build the CLI"
#MISE alias="b"
#MISE sources=["Cargo.toml", "src/**/*.rs"]
#MISE outputs=["target/debug/mycli"]

cargo build

Rendez le fichier exécutable : chmod +x mise-tasks/build

Cas d’usage : workflow de développement complet

[tools]
node = "22"
python = "3.12"

[env]
NODE_ENV = "development"

# === TASKS DE BUILD ===
[tasks.build]
description = "Build l'application"
run = "npm run build"
sources = ["src/**/*.ts", "package.json"]
outputs = ["dist/**"]

[tasks."build:watch"]
description = "Build en mode watch"
run = "npm run build -- --watch"

# === TASKS DE TEST ===
[tasks.test]
description = "Lance les tests unitaires"
run = "npm test"
depends = ["lint"]  # lint avant test
env = { NODE_ENV = "test" }

[tasks."test:e2e"]
description = "Lance les tests end-to-end"
run = ["npm run build", "./scripts/test-e2e.sh"]
depends = ["build"]

[tasks."test:coverage"]
run = "npm test -- --coverage"

# === TASKS DE QUALITÉ ===
[tasks.lint]
description = "Vérifie le code avec ESLint"
run = "eslint src/"
sources = ["src/**/*.ts", ".eslintrc.*"]

[tasks."lint:fix"]
run = "eslint src/ --fix"

[tasks.format]
run = "prettier --write src/"

# === TASK COMBINÉE ===
[tasks.ci]
description = "Pipeline CI complet"
depends = ["lint", "test", "build"]

# === DÉPLOIEMENT ===
[tasks.deploy]
description = "Déploie en production"
confirm = "Êtes-vous sûr de vouloir déployer ?"
run = """
npm run build
rsync -avz dist/ server:/var/www/
"""
depends = ["test"]

Exécution des tasks

# Exécuter une task
mise run build
mise run test

# Raccourci (si pas de conflit avec une commande mise)
mise build
mise test

# Exécuter plusieurs tasks en parallèle
mise run lint test build

# Passer des arguments (passés à la dernière commande)
mise run build --release

# Séparer les arguments entre tasks
mise run build --release ::: test --verbose

# Mode watch (relance sur changement)
mise watch build

# Lister les tasks disponibles
mise tasks
# Name           Description                   Source
# build          Build l'application           mise.toml
# test           Lance les tests unitaires     mise.toml
# lint           Vérifie le code avec ESLint   mise.toml
# ci             Pipeline CI complet           mise.toml

Cas d’usage : exécution conditionnelle

Le système sources/outputs évite les rebuilds inutiles :

[tasks.build]
run = "cargo build"
sources = ["Cargo.toml", "src/**/*.rs"]
outputs = ["target/debug/mycli"]

Si target/debug/mycli est plus récent que tous les fichiers sources, la task est skippée. Particulièrement utile en CI/CD pour économiser du temps.

Cas d’usage : tasks en Python ou Node.js

Les tasks peuvent utiliser n’importe quel interpréteur via shebang :

Python
Node.js

[tools]
python = "3.12"

[tasks.migrate]
description = "Exécute les migrations Django"
run = '''
#!/usr/bin/env python
import subprocess
subprocess.run(["python", "manage.py", "migrate"])
print("Migrations terminées !")
'''

[tools]
node = "22"

[tasks.seed]
description = "Seed la base de données"
run = '''
#!/usr/bin/env node
const { seedDatabase } = require('./scripts/seed');
seedDatabase().then(() => console.log('Done!'));
'''

Cas d’usage : monorepo avec groupes de tasks

Organisez les tasks par préfixe pour les monorepos :

# Frontend
[tasks."frontend:dev"]
run = "cd frontend && npm run dev"

[tasks."frontend:build"]
run = "cd frontend && npm run build"

[tasks."frontend:test"]
run = "cd frontend && npm test"

# Backend
[tasks."backend:dev"]
run = "cd backend && cargo run"

[tasks."backend:build"]
run = "cd backend && cargo build --release"

[tasks."backend:test"]
run = "cd backend && cargo test"

# Exécuter tous les tests avec wildcard
[tasks.test]
depends = ["*:test"]  # frontend:test + backend:test

# Ou avec pattern plus précis
[tasks."lint:all"]
depends = ["lint:*"]  # lint:eslint + lint:clippy + ...

# Exécuter un groupe
mise run frontend:dev
mise run backend:test

# Exécuter tous les tests (wildcard)
mise run test

Cas d’usage : scripts externes et distants

# Script local dans un fichier séparé
[tasks.release]
description = "Créer une release"
file = "scripts/release.sh"
confirm = "Créer une nouvelle release ?"

# Script distant (avec cache)
[tasks.setup]
description = "Configure l'environnement de dev"
file = "https://raw.githubusercontent.com/mon-org/scripts/main/setup.sh"

Variables d’environnement dans les tasks

mise injecte automatiquement des variables utiles :

Variable	Description
`MISE_ORIGINAL_CWD`	Répertoire depuis lequel la commande a été lancée
`MISE_CONFIG_ROOT`	Répertoire contenant le `mise.toml`
`MISE_PROJECT_ROOT`	Racine du projet
`MISE_TASK_NAME`	Nom de la task en cours
`MISE_TASK_FILE`	Chemin complet vers le script de la task

Migrer depuis asdf

mise lit nativement les fichiers .tool-versions. La migration est transparente.

Installer mise

curl https://mise.run | sh
echo 'eval "$(~/.local/bin/mise activate zsh)"' >> ~/.zshrc
source ~/.zshrc

Vos fichiers .tool-versions fonctionnent immédiatement

cd mon-projet-asdf
mise install  # Installe tout depuis .tool-versions
mise current  # Vérifie les versions

mise convertit automatiquement les outils asdf vers les backends optimaux (aqua, github, gitlab) :

# Exemple de conversion automatique
mise ls
# Tool        Version  Source            Requested
# kubectl     1.35.0   ~/.tool-versions  1.35.0    # → aqua:kubernetes/kubernetes/kubectl
# glab        1.80.4   ~/.tool-versions  1.80.4    # → gitlab:gitlab-org/cli
# node        20.19.0  ~/.tool-versions  20.19.0   # → core:node

Désactiver asdf dans votre shell

Commentez les lignes asdf dans ~/.bashrc ou ~/.zshrc :
Fenêtre de terminal
```
# Avant
export PATH="${ASDF_DATA_DIR:-$HOME/.asdf}/shims:$PATH"

# Après
# DISABLED: export PATH="${ASDF_DATA_DIR:-$HOME/.asdf}/shims:$PATH"
```
Retirez asdf de la liste des plugins oh-my-zsh si présent.

Vérifier que mise fonctionne

mise doctor
# version: 2026.1.7 linux-x64
# activated: yes
# ...
# ✓ No problems found

Optionnel : convertir en mise.toml

# Créer mise.toml depuis les versions actuelles
mise use node@22 python@3.12 terraform@latest

Astuces et bonnes pratiques

Auto-installation à l’entrée d’un projet

[hooks]
enter = "mise install --quiet"

Lockfile pour la reproductibilité

# Créer un lockfile avec checksums
touch mise.lock
mise install
# mise.lock contient maintenant les versions exactes et checksums

Alias shell pratiques

# Dans ~/.bashrc ou ~/.zshrc
alias mx="mise exec --"
alias mr="mise run"
alias mi="mise install"
alias mu="mise use"

GitHub Actions

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: jdx/mise-action@v2
      - run: node -v  # Version depuis mise.toml

Éviter le rate limiting GitHub

# Définir un token GitHub
export MISE_GITHUB_TOKEN="ghp_..."
# Ou utiliser le lockfile (stocke les URLs)
touch mise.lock && mise install

Dépannage

”mise: command not found"

# Vérifier que mise est dans le PATH
echo $PATH | tr ':' '\n' | grep local

# Ajouter manuellement si nécessaire
export PATH="$HOME/.local/bin:$PATH"

"mise trust” demandé en boucle

# Faire confiance au répertoire
mise trust

# Ou ajouter à la config globale
mise settings trusted_config_paths "~/projets"

Outil non trouvé après installation

# Régénérer les shims
mise reshim

# Ou recharger le shell
exec $SHELL

Vider le cache

mise cache clear

À retenir

Action	Commande
Installer un outil	`mise use node@22`
Installer globalement	`mise use -g python@3.12`
Exécuter avec un outil	`mise exec node@20 -- node -v`
Lancer une task	`mise run test`
Voir la config	`mise config`
Mettre à jour tout	`mise upgrade --bump`

Points clés :

Plus rapide et plus sécurisé qu’asdf
mise.toml combine outils, environnements et tasks
Backends multiples : npm, pipx, cargo, github, aqua
Compatible avec .tool-versions d’asdf
Supporte Windows

Outils relatifs

asdf : le gestionnaire historique Si vous avez des projets existants avec asdf

direnv : variables d'environnement Alternative pour la gestion des variables par projet

Homebrew : paquets système Complément pour les outils non gérés par mise

Sécuriser la supply chain Bonnes pratiques de sécurité pour vos dépendances