mise : le gestionnaire de versions polyvalent et rapide

mise (prononcé « MIZ », comme mise en place ; anciennement rtx) est un gestionnaire de versions d'outils de développement écrit en Rust. En une seule commande, il installe vos outils (Node.js, Python, Go, Terraform et 700+ autres), gère vos variables d'environnement par projet et exécute des tasks. Autrement dit, il remplace à lui seul asdf, nvm, pyenv, rbenv, tfenv et direnv. Compatible avec les fichiers .tool-versions d'asdf, il s'en distingue par une activation quasi instantanée (mise à jour du PATH sans shim), des backends vérifiés (Cosign, SLSA) et des fonctionnalités absentes d'asdf comme les tasks et la gestion d'environnements.

# Installer mise depuis le dépôt Debian/Ubuntu signé (extrepo vérifie la clé GPG)
sudo apt install -y extrepo && sudo extrepo enable mise
sudo apt update && sudo apt install -y mise
# Puis, une fois mise activé dans le shell :
mise use -g node@22
node --version
# v22.23.1

Version utilisée dans ce guide : mise 2026.7.0. mise suit un versionnement calendaire (AAAA.M.PATCH) avec des releases très fréquentes : épinglez la version en CI plutôt que de suivre la dernière en continu.

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

mise, c'est quoi ?

mise est un outil unique qui regroupe trois rôles habituellement tenus par trois logiciels séparés :

un gestionnaire de versions : il installe et fait cohabiter plusieurs versions de Node.js, Python, Go, Terraform, etc. (le rôle de nvm, pyenv, rbenv, tfenv ou asdf) ;
un gestionnaire d'environnement : il charge des variables d'environnement par projet (le rôle de direnv) ;
un lanceur de tâches (task runner) : il exécute les commandes du projet, des « scripts npm pour n'importe quel langage » (le rôle de make ou des scripts npm).

Tout tient dans un seul fichier mise.toml à la racine du projet : versions, variables et commandes, identiques en local, en conteneur et en CI. C'est le contrat unique du dépôt, ce qui en fait un excellent outil d'onboarding : un nouvel arrivant tape mise install et obtient le même environnement que l'équipe.

Né en 2023 sous le nom rtx, renommé mise en 2024, il est écrit en Rust par Jeff Dickey (jdx). Point important : il ne remplace pas un gestionnaire de paquets système comme apt, dnf ou Homebrew. Il gère des versions d'outils de développement et des utilitaires en ligne de commande, pas des bibliothèques système.

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

Installez mise depuis un dépôt de paquets signé de votre distribution, jamais par un script distant tiré de curl | sh. Le gestionnaire de paquets vérifie la signature du dépôt à chaque mise à jour : mise hérite de la même chaîne de confiance que le reste de votre système, sans exécuter un script inspecté à l'aveugle.

sudo apt install -y extrepo
sudo extrepo enable mise
sudo apt update
sudo apt install -y mise

extrepo récupère la définition officielle du dépôt mise et active sa clé GPG : les paquets sont ensuite authentifiés par APT comme n'importe quel paquet Debian.

sudo dnf install -y dnf-plugins-core
sudo dnf copr enable -y jdxcode/mise
sudo dnf install -y mise

Le dépôt COPR de l'auteur fournit des RPM signés, mis à jour à chaque release et vérifiés par DNF.

brew install mise

# Via winget
winget install jdx.mise

# Ou via scoop
scoop install mise

Une fois le paquet installé, activez mise dans votre shell pour qu'il gère le PATH automatiquement (remplacez bash par zsh selon votre shell), puis vérifiez l'installation :

echo 'eval "$(mise activate bash)"' >> ~/.bashrc
source ~/.bashrc
mise --version
mise doctor

mise doctor valide l'installation et signale toute activation manquante ou dépôt mal configuré.

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

Nettoyer les versions inutilisées (mise prune)

Au fil des montées de version, les anciennes versions d'outils s'accumulent et occupent de l'espace disque. La commande mise prune supprime les versions qui ne sont plus référencées par aucun mise.toml suivi. Listez d'abord ce qui peut partir, et passez systématiquement par --dry-run avant de supprimer pour de bon :

# Voir les versions devenues inutiles (sans rien supprimer)
mise ls --prunable

node       20.11.0
terraform  1.8.5
gh         2.87.3

# Simuler la suppression : --dry-run ne supprime rien
mise prune --dry-run

mise node@20.11.0 [dryrun]   uninstall
mise node@20.11.0 [dryrun]   remove ~/.local/share/mise/installs/node/20.11.0
mise node@20.11.0 [dryrun] ✓ done

Une fois la liste vérifiée, relancez sans --dry-run pour supprimer réellement. Repérez les outils en retard avec mise outdated, et mettez à jour mise lui-même avec mise self-update (installation par script) :

# Lister les outils dont une version plus récente existe
mise outdated

node       22   22.13.1  22.18.0  ~/.config/mise/config.toml
terraform  1.9  1.9.8    1.13.1   mise.toml

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 19 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 la 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, pkgx, 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

Variables sensibles : redact et required

Un bloc [vars] définit des variables réutilisables. Depuis les versions 2026.x, une variable marquée redact = true est masquée ([redacted]) dans les sorties de mise config et les logs, et required fait échouer mise si elle manque. Pratique pour un secret d'équipe sans le fuiter en clair.

[vars]
api_token = { value = "{{ env.API_TOKEN }}", redact = true }

[env]
TOKEN = "{{ vars.api_token }}"

Avec cette configuration, mise config affiche TOKEN [redacted] au lieu de la valeur.

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 depuis le dépôt signé, comme décrit à la section Installation de mise, puis activez-le dans votre shell :
Fenêtre de terminal
```
echo 'eval "$(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.7.0 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é

Comme package-lock.json ou Cargo.lock, un lockfile fige les versions exactes réellement installées (avec checksums et URL, par plateforme), même si votre mise.toml reste lâche (node = "22"). C'est la clé de la reproductibilité en équipe et en CI.

# Activer le lockfile, puis le générer
mise settings lockfile=true
touch mise.lock
mise install

Le fichier mise.lock enregistre la version, la taille, le checksum (SHA256 ou Blake3) et l'URL pour chaque plateforme. Commitez mise.lock et gitignorez mise.local.lock. Pour des installs déterministes et hors ligne (aucun appel d'API), activez le mode strict, idéal en CI :

# Échoue si un outil n'a pas d'URL pré-résolue dans le lockfile
MISE_LOCKED=1 mise install

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

Maturité et points de vigilance

mise est mature et largement adopté, mais quelques points méritent une décision éclairée, surtout en entreprise.

Gouvernance. Le cœur de mise est développé par un seul mainteneur (jdx, passé à plein temps sur le projet en 2026). C'est un choix assumé pour limiter la surface d'exposition des clés de signature, mais cela implique un bus factor faible : gardez-le en tête pour un usage critique.

Modèle de confiance. Un mise.toml peut exécuter du code arbitraire (via [env], les hooks et les tasks). D'où mise trust, à exécuter en conscience. Plusieurs contournements du mécanisme ont été remontés puis corrigés : ne faites confiance qu'aux dépôts dont vous maîtrisez le contenu.

Hiérarchie de risque des backends. Pour la supply chain, préférez les backends vérifiables : aqua et ubi (binaires signés, checksums) en tête, les plugins mise-plugins (forks asdf relus) ensuite, et évitez les plugins asdf bruts qui exécutent du shell tiers non vérifié.

Rythme de releases. mise publie très fréquemment : épinglez la version et le mise.lock en CI plutôt que de suivre la dernière en continu. Pour un pipeline durci, il existe un fork StepSecurity de l'action jdx/mise-action.

À 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

Questions fréquentes

mise remplace-t-il asdf, nvm et pyenv ?

Oui. mise gère les versions de tous vos langages et outils depuis un seul binaire et remplace asdf, nvm, pyenv, rbenv et tfenv. Il lit même vos fichiers .tool-versions existants, donc la migration depuis asdf est transparente. Il ajoute en prime la gestion d'environnement (rôle de direnv) et un lanceur de tâches.

mise et uv sont-ils concurrents ?

Non, ils sont complémentaires. mise installe et épingle la version de Python (et d'autres outils), tandis qu'uv gère les paquets et le virtualenv du projet. mise n'installe pas de paquets Python ; uv n'est pas un gestionnaire de versions multi-langages. On les utilise ensemble : mise fournit le bon Python, uv gère les dépendances. Voir le guide uv.

Comment supprimer les anciennes versions installées ?

Avec mise prune. Listez d'abord les candidates avec mise ls --prunable, simulez avec mise prune --dry-run, puis relancez sans --dry-run pour supprimer réellement. mise ne garde que les versions encore référencées par vos mise.toml.

mise fonctionne-t-il sous Windows ?

Oui, contrairement à asdf. mise s'installe via winget ou scoop et tourne nativement sous Windows. Certains backends restent surtout éprouvés sous Linux et macOS : testez vos outils critiques avant de vous reposer dessus.

mise est-il prêt pour la production ?

Oui pour un usage d'équipe courant, à condition d'épingler les versions (via mise.lock), de faire confiance uniquement aux dépôts maîtrisés et de privilégier les backends aqua/ubi. Pour un contexte critique, pesez le bus factor du projet (voir « Maturité et points de vigilance »).

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

uv : packages et environnements Python Complémentaire de mise : mise gère la version de Python, uv les paquets.

pyenv : versions de Python L'outil historique que mise remplace pour gérer Python.