Pourquoi j'ai quitté Devbox pour mise
Je suis du genre à vouloir que mon poste de travail soit reproductible. Pas par obsession, mais par pragmatisme : quand on change de machine, qu'on reinstalle un OS ou qu'un collègue rejoint le projet, je veux perdre le moins de temps possible à "reconfigurer tout ça". Ma stratégie depuis quelques années : mettre un maximum d'outils dans une configuration globale, versionnée, que je peux appliquer en quelques minutes n'importe où.
Pendant un moment, Devbox semblait être la réponse idéale à ce problème. Et puis j'ai basculé vers mise. Voilà pourquoi.
Devbox, ça commence bien
Devbox repose sur Nix, ce qui est à la fois sa grande force et son talon d'Achille. La promesse est séduisante : des environnements parfaitement reproductibles, isolés du système, avec des dépendances qui ne se marchent jamais dessus. Sur le papier, c'est exactement ce qu'on veut.
Et au départ, ça tient la route. On déclare ses outils dans un devbox.json, on lance devbox shell, et on obtient un environnement propre. Le devbox global permet même de gérer une configuration commune à tous les projets — exactement ce que je cherchais.
Problème n°1 : les paquets à la traîne
Le catalogue de Nix est immense, mais il a un défaut de taille : les paquets ne sont pas toujours à jour. Nix fonctionne par "canaux" (channels) qui sont mis à jour avec un certain décalage. Pour les outils qui suivent des cycles de release rapides, c'est problématique.
L'exemple concret qui m'a le plus frappé : Claude Code. L'outil sort des mises à jour régulièrement — parfois plusieurs par semaine — et les nouvelles versions apportent des fonctionnalités ou des correctifs qu'on veut rapidement. Avec Devbox, je me retrouvais souvent en retard, à attendre que le paquet soit disponible dans le canal Nix, ou à jongler avec des overrides pas toujours agréables à maintenir.
Avec mise, le problème disparaît. mise upgrade claude-code et c'est réglé. Ou mieux, mise upgrade tout court pour mettre à jour l'ensemble de la config globale en une passe.
Problème n°2 : l'interopérabilité, le vrai point noir
Celui-là, c'est le plus rédhibitoire. Et c'est difficile à anticiper quand on commence à utiliser Devbox.
Nix fonctionne dans son propre monde. Il installe ses bibliothèques, ses dépendances, ses locales dans des chemins qui lui appartiennent — et ça ne correspond pas forcément à ce que le reste du système attend. Sur Ubuntu 24, j'ai commencé à rencontrer des erreurs liées aux locales, aux chemins de bibliothèques partagées, à des binaires Nix qui ne se comportaient pas comme attendu dans un contexte non-Nix.
La solution ? Ajouter des paquets Devbox comme glibcLocales, configurer manuellement des variables d'environnement pour que les locales soient correctement reconnues, bidouiller les chemins... Je ne peux pas dire avec certitude si c'est systématique sur toutes les distributions Linux — peut-être que c'est spécifique à Ubuntu 24, ou à certaines combinaisons de paquets. Mais ce que je sais, c'est que j'ai passé plus de temps à faire fonctionner Devbox qu'à travailler avec Devbox.
Et c'est là le vrai signal. Quand un outil devient lui-même un problème à gérer, c'est qu'il n'est pas le bon outil pour votre contexte.
Le task runner : présent, mais limité
Devbox a bien un task runner, via devbox run. Mais il reste assez basique comparé à ce que mise propose.
Pas de dépendances entre tâches. Pas de sources/outputs pour éviter les rebuilds inutiles. Pas d'exécution parallèle. Pas de mode watch. Pas de tâches dans d'autres langages que le shell. En pratique, ça voulait dire maintenir un Makefile en parallèle pour les projets un peu complexes — ce qui annule une partie de l'intérêt d'avoir un outil unifié.
Le task runner de mise, lui, est une vraie alternative au Makefile. Les tâches ont des dépendances, des répertoires de travail, des descriptions, et peuvent s'enchaîner ou s'exécuter en parallèle. C'est un différenciateur réel.
Devbox installe un OS dans votre OS
C'est un peu caricatural, mais pas tant que ça. Nix a besoin de son propre store (/nix/store), qui peut facilement atteindre plusieurs gigaoctets. Chaque environnement Devbox tire ses propres dépendances, qui s'accumulent. Sur une machine de développement qui tourne depuis quelques mois, le store Nix peut occuper une place considérable — sans que ce soit forcément visible au premier coup d'œil.
mise, de son côté, installe les binaires dans ~/.local/share/mise/installs/. C'est simple, localisé, et nettement moins gourmand. La différence n'est pas anodine quand on travaille sur un laptop avec un SSD de taille raisonnable.
La migration, ou plutôt la découverte
J'avais croisé mise plusieurs fois dans ma veille technologique. Je l'avais regardé de loin, en me disant "c'est asdf en mieux, sympa" — sans vraiment m'y attarder. À l'époque, j'avais déjà Devbox en place, ça fonctionnait à peu près, et changer d'outil a un coût.
Et puis les problèmes se sont accumulés. Les paquets en retard. Les conflits de locales. Le temps passé à déboguer plutôt qu'à produire. J'ai fini par essayer mise sérieusement, et la prise en main a été étonnamment rapide. La configuration globale dans ~/.config/mise/config.toml fait exactement ce que je voulais faire avec devbox global. Les outils s'installent vite, les versions sont récentes, et ça ne se bat pas avec le reste du système.
La migration elle-même a été progressive : j'ai commencé par basculer les outils globaux, puis projet par projet. Aucun choc, aucune rupture.
Ce que j'ai gardé comme enseignement
Devbox n'est pas un mauvais outil. Pour des cas où l'isolation Nix est vraiment nécessaire — reproductibilité absolue des dépendances système, équipes mixtes avec des OS très différents, environnements ultra-contraints — il garde sa pertinence. La promesse de Nix est réelle.
Mais pour l'usage que j'en avais — gérer ma config globale d'outils, avoir un task runner fiable, rester à jour sans friction — mise est simplement plus adapté. Moins de magie noire, moins de surface de problèmes, et finalement plus de liberté pour faire ce pour quoi il est fait.
Parfois le meilleur outil n'est pas le plus ambitieux. C'est celui qui disparaît derrière votre travail.
