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 ?

asdf est l'outil historique de ce domaine et reste parfaitement fonctionnel : la question n'est donc pas de savoir s'il marche, mais ce que mise apporte en plus. Trois écarts pèsent vraiment dans une décision d'équipe : le coût d'activation à chaque changement de répertoire, le niveau de vérification des sources d'installation, et les fonctions absentes d'asdf qui obligent sinon à empiler d'autres outils.

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

mise n'est pas un empilement de fonctionnalités indépendantes : tout converge vers un fichier de configuration unique, que la CLI lit à chaque changement de répertoire. Le schéma montre les quatre briques et leur point de rencontre, le fichier mise.toml. Retenez surtout la distinction entre ce que vous déclarez (outils, variables, tasks) et ce qui va le chercher (les backends).

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

Une distinction gouverne toute la CLI : certaines commandes écrivent dans la configuration, d'autres se contentent d'agir sur le disque. mise use inscrit l'outil dans un mise.toml et l'installe ; mise install installe uniquement ce qui est déjà déclaré. Confondre les deux est la source d'erreur la plus fréquente au début.

Installer et utiliser des outils

Sans indication de version, mise prend la dernière stable. L'option -g (global) vise la configuration de votre compte plutôt que le projet courant :

# 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

mise upgrade installe les versions plus récentes compatibles avec ce que vous avez déclaré, sans toucher au fichier. L'option --bump va plus loin : elle réécrit les contraintes de mise.toml pour pointer sur ces nouvelles versions.

# 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

Comme plusieurs fichiers peuvent se superposer, il est fréquent de ne plus savoir quelle version s'applique réellement. Ces trois commandes répondent respectivement à : quelle version est active, quels fichiers ont été chargés, et d'où vient un outil donné.

# 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. Là où le format d'asdf ne sait exprimer que des couples outil/version, le TOML accueille trois sections distinctes dans un seul fichier versionné avec le code. Les deux formats coexistent sans conflit, mais un mise.toml présent l'emporte sur un .tool-versions du même répertoire :

# 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

Un backend est la source d'où provient un outil : une release GitHub, un paquet npm, un registre vérifié. Le préfixe devant le nom de l'outil (aqua:, npm:, pipx:) désigne explicitement le backend ; sans préfixe, mise choisit lui-même selon sa table de priorité.

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 ?

La différence tient en une ligne du tableau : un plugin asdf est un script shell exécuté sur votre machine au moment de l'installation, alors qu'une définition aqua est une donnée déclarative que mise interprète lui-même. Le premier peut faire n'importe quoi, le second ne peut décrire qu'un téléchargement et sa vérification.

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

Les commandes ci-dessous couvrent les quatre situations réelles : un outil présent dans aqua, un utilitaire distribué en paquet npm, un outil Python en ligne de commande isolé par pipx, et un binaire disponible uniquement en release GitHub. Les commentaires reproduisent la sortie observée.

# 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, ce qui lui permet de remplacer direnv. Les variables de la section [env] sont posées à l'entrée du répertoire et retirées à la sortie, sans laisser de trace dans les autres terminaux. Elles acceptent des valeurs littérales, le chargement d'un fichier .env existant, et des blocs conditionnels activés par la variable MISE_ENV :

[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

Une task est une commande du projet nommée et documentée dans mise.toml, que n'importe qui peut lancer sans connaître la ligne exacte à taper. Elle s'exécute avec les outils et les variables déjà déclarés dans le même fichier, donc dans le même environnement partout. 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). La forme TOML convient tant que la commande tient sur une ligne ; dès qu'il y a une vraie logique, un fichier dans mise-tasks/ est plus lisible et bénéficie de la coloration syntaxique de l'éditeur. Les métadonnées y sont portées par des commentaires #MISE, équivalents aux clés TOML.

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

Ce fichier montre l'intérêt réel du format : outils, variables et tâches d'un projet réunis au même endroit. Deux mécanismes structurent l'ensemble, depends qui déclenche une task avant une autre, et confirm qui exige une validation interactive sur les opérations irréversibles comme le déploiement.

[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

Plusieurs tasks passées à la même commande s'exécutent en parallèle, pas dans l'ordre où vous les écrivez : si un enchaînement est nécessaire, il se déclare avec depends. Le séparateur ::: sert à répartir les arguments entre plusieurs tasks d'un même appel.

# 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

La clé file déporte le contenu de la task vers un script, local ou téléchargé par URL. La seconde forme est pratique pour partager une procédure d'installation entre plusieurs dépôts, mais elle fait exécuter du code distant : ne la pointez que vers un dépôt que vous contrôlez, et de préférence sur une référence figée.

# 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 : aucun fichier à convertir, aucun projet à modifier, et vos collègues restés sur asdf continuent de travailler sur le même dépôt. Le seul point délicat est la cohabitation dans le shell, car les shims d'asdf restent prioritaires dans le PATH tant qu'on ne les a pas retirés.

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

Cinq réglages qui font la différence entre un usage individuel et un usage d'équipe. Les deux premiers concernent la reproductibilité, les trois derniers le confort quotidien et la fiabilité en intégration continue.

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

Un hook enter déclenche une commande à chaque entrée dans le répertoire du projet. Combiné à --quiet, il installe silencieusement ce qui manque, ce qui évite au nouvel arrivant d'avoir à y penser :

[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

Ces quatre raccourcis couvrent l'essentiel de l'usage quotidien. Ajoutez-les au fichier de démarrage correspondant à votre shell :

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

GitHub Actions

L'action officielle installe mise puis lit le mise.toml du dépôt : les versions d'outils du pipeline sont donc exactement celles des postes de développement, sans les redéclarer dans le workflow. Épinglez l'action par empreinte de commit plutôt que par tag mouvant.

permissions: {}

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false
      - uses: jdx/mise-action@dad1bfd3df957f44999b559dd69dc1671cb4e9ea # v4.2.1
      - run: node -v  # Version depuis mise.toml

Éviter le rate limiting GitHub

Beaucoup de backends interrogent l'API GitHub pour lister les versions disponibles. Sans authentification, cette API limite les requêtes par adresse IP, ce qui provoque des échecs aléatoires sur les runners partagés. Un jeton, même sans aucune permission, relève nettement le quota :

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

Dépannage

La quasi-totalité des problèmes rencontrés avec mise se ramène à trois causes : le binaire absent du PATH, l'activation dans le shell qui n'a pas été faite, ou un fichier de configuration non approuvé. Commencez toujours par mise doctor, qui identifie les deux premières sans effort.

"mise: command not found"

Le paquet installe le binaire dans un répertoire que certaines distributions n'ajoutent pas au PATH des sessions non interactives :

# 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

Un mise.toml peut exécuter du code, mise exige donc une approbation explicite par répertoire. Si vous travaillez toujours dans la même arborescence, déclarez-la une fois pour toutes comme chemin de confiance :

# Faire confiance au répertoire
mise trust

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

Outil non trouvé après installation

Le PATH d'un shell déjà ouvert n'est pas mis à jour rétroactivement. Régénérer les shims ou relancer le shell suffit dans la quasi-totalité des cas :

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

# Ou recharger le shell
exec $SHELL

Vider le cache

mise conserve en cache les listes de versions et les scripts distants. Purger ce cache est sans risque pour les outils déjà installés, il force simplement une nouvelle interrogation des sources :

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

Cinq questions qui reviennent systématiquement avant d'adopter mise dans une équipe, sur son périmètre exact, sa cohabitation avec les outils existants et sa solidité en production.

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

mise ne couvre pas tout le terrain, et il coexiste avec plusieurs outils du même domaine. Les liens suivants situent chacun d'eux par rapport à lui : ceux qu'il remplace, ceux qui le complètent, et le contexte de sécurité dans lequel s'inscrit le choix d'un backend vérifié.

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.

Ressources

La documentation officielle est la seule référence à jour compte tenu du rythme de publication de mise. La page de comparaison avec asdf détaille les écarts de comportement que ce guide résume.