L’argument de XDA ce mois-ci est que la mise à niveau VS Code la plus intelligente n’est pas une autre extension d’autocomplétion, mais les dev containers. Le raisonnement tient la route. Un dev container est un environnement Linux délimité par un dossier, défini par un fichier devcontainer.json, avec votre runtime de langage, paquets système et extensions d’éditeur tous épinglés. Ouvrez le dossier dans un éditeur supporté et l’outillage réconcilie le conteneur à partir de ce fichier, de sorte qu’un clone frais atteint un état fonctionnel sans une page de configuration manuelle. Nous avons testé huit applications pour exécuter des dev containers sur Windows, macOS et Linux, choisies pour la façon dont elles gèrent la spécification devcontainer.json réelle et ce qui se passe quand un coéquipier sur un autre OS ouvre le même dossier.
Ce qu’il faut rechercher dans une application de dev container
Tous les outils de conteneurs ne comprennent pas la spécification des dev containers, et ceux qui la comprennent fonctionnent sur des runtimes très différents.
- Support des spécifications.
devcontainers/clilit.devcontainer/devcontainer.json, résout les features, transmet les ports et monte votre workspace. Recherchez des outils qui appellent cet CLI ou l’intègrent, pas des outils qui exécutentdocker runet espèrent le mieux. - Runtime. Docker Engine reste le standard par défaut. Podman est le remplaçant qui fonctionne sans privilèges. Colima et Lima sont les options macOS qui évitent les conditions de licence de Docker Desktop.
- Kubernetes et cloud. Certains outils peuvent exécuter le même
devcontainer.jsonsur un cluster K8s ou une VM distante, pas seulement votre laptop. C’est important quand la machine sur laquelle vous gardez les dev containers n’est pas celle que vous avez sous les yeux. - Couplage d’éditeur. VS Code et JetBrains Gateway ouvrent tous deux un dossier dans un dev container nativement. Cursor et Windsurf héritent de cela de la base VS Code. Les utilisateurs de Vim et Emacs ont besoin d’un outil orienté CLI.
- Performance sur macOS et Windows. Les bind mounts à travers la limite de l’hôte sont la partie la plus lente de n’importe quel flux de travail de conteneur. Recherchez VirtioFS, l’ajustement gRPC-FUSE ou une couche de synchronisation du système de fichiers.
Comparaison rapide
| Application | Meilleur pour | Plateformes | Plan gratuit | Prix initial | Caractéristique phare |
|---|---|---|---|---|---|
| Docker Desktop | Runtime par défaut, utilisateurs GUI | Windows, macOS, Linux | Gratuit pour usage personnel / petite entreprise | Niveau Entreprise par siège/mois | Couverture d’outils la plus large |
| Podman Desktop | Remplaçant Docker sans privilèges | Windows, macOS, Linux | Gratuit, open source | Gratuit | Fonctionne sans privilèges par défaut |
| DevPod | Même conteneur sur laptop, K8s ou cloud | Windows, macOS, Linux | Gratuit, open source | Loft Pro pour les équipes | Modèle de fournisseur pour dev cloud |
| OrbStack | Docker plus rapide sur macOS | macOS | Gratuit pour usage personnel | Niveau payant pour commercial | VirtioFS, faible empreinte RAM |
| Rancher Desktop | Docker plus vrai K8s local | Windows, macOS, Linux | Gratuit, open source | Gratuit | k3s intégré |
| Colima | Docker léger sans GUI sur macOS/Linux | macOS, Linux | Gratuit, open source | Gratuit | Pas de GUI, frais généraux bas |
| Distrobox | Bureaux Linux containerisés | Linux | Gratuit, open source | Gratuit | Exécute les applications GUI à partir de conteneurs |
| GitHub Codespaces | Dev containers hébergés en cloud | Web, VS Code, JetBrains | Heures mensuelles gratuites | Par heure après quota | Le même devcontainer.json dans le cloud |
Les applications
1. Docker Desktop — Meilleur pour le runtime par défaut avec l’écosystème le plus large
Docker Desktop est toujours ce que la spécification des dev containers suppose dès le premier jour. Installez-le, installez l’extension Dev Containers dans VS Code, et “Reopen in Container” fonctionne sans configuration. Il regroupe Docker Engine, Kubernetes et le plugin compose, et gère la VM Linux sur Windows et macOS pour que vous ne touchiez jamais WSL ou une instance Lima directement.
Où il fait défaut : Les termes d’abonnement mordent pour les organisations plus grandes. Tout ce qui dépasse 250 employés ou 10 millions de dollars de chiffre d’affaires nécessite un siège Entreprise. L’utilisation de startup et personnelle reste toujours gratuite, mais lisez la licence avant de la déployer sur une flotte.
Tarification :
- Gratuit : Personnel, éducation, petite entreprise, open source non commercial
- Payant : Sièges Pro, Team et Entreprise facturés par utilisateur par mois
Plateformes : Windows, macOS, Linux
Télécharger : docker.com/products/docker-desktop
Conclusion : Si vous choisissez un outil et passez à autre chose, installez Docker Desktop et arrêtez de lire. Le reste de la liste est pour quand la licence ou l’empreinte RAM le rend inadapté.
2. Podman Desktop — Meilleur pour un remplaçant sans privilèges et sans licence
Podman Desktop est l’interface graphique sponsorisée par Red Hat au-dessus de Podman, et gère maintenant devcontainer.json via l’extension VS Code Dev Containers en exposant un socket compatible avec Docker. Vous obtenez un runtime OCI qui fonctionne sans privilèges par défaut, pas de démon en arrière-plan, et une licence Apache 2.0 permissive.
Où elle fait défaut : La parité Compose est proche mais pas identique à celle de Docker. La sémantique du montage de volume sur macOS reste en retard par rapport à Docker Desktop pour les workspaces très volumineux. Les rapports de bug sur les dev containers avec des couches de features lourdes continuent d’apparaître occasionnellement.
Tarification :
- Gratuit : Ensemble complet de fonctionnalités, open source
- Payant : Aucun
Plateformes : Windows, macOS, Linux
Télécharger : podman-desktop.io
Conclusion : Podman Desktop est l’échange direct quand la licence de Docker Desktop est un problème, et c’est le bon choix quand votre équipe exécute déjà Podman sur les serveurs.
3. DevPod — Meilleur pour le même conteneur sur laptop, K8s et cloud
DevPod par Loft Labs traite les fournisseurs comme des modules enfichables. Le même devcontainer.json que vous ouvrez sur Docker Desktop peut démarrer sur un cluster Kubernetes, un hôte SSH, une nouvelle instance EC2 ou un Loft Vcluster, avec le workspace synchronisé. Il réutilise en interne devcontainers/cli de Microsoft, de sorte que la conformité aux spécifications est par construction, non par traduction.
Où il fait défaut : L’écosystème des fournisseurs est inégal. Les fournisseurs AWS, GCP, Azure et K8s de première partie sont solides. Les fournisseurs communautaires varient. L’interface utilisateur de bureau est fonctionnelle plutôt que polie.
Tarification :
- Gratuit : Client open source complet, tous les fournisseurs
- Payant : Loft Enterprise pour la gestion centralisée de l’équipe
Plateformes : Windows, macOS, Linux, CLI
Télécharger : devpod.sh
Conclusion : DevPod est le choix quand “dev container sur mon laptop” doit devenir “dev container dans le cluster” sans réécrire le fichier.
4. OrbStack — Meilleur pour Docker plus rapide sur macOS
OrbStack est un remplaçant de Docker à partir de zéro pour les Mac Apple Silicon. Le démarrage à froid prend quelques secondes, l’inactivité RAM se situe bien en dessous de Docker Desktop, et VirtioFS est la valeur par défaut pour les bind mounts, ce qui est le gain de performance unique le plus important pour les dev containers qui montent les grands monorepos. Il exécute également des VM Linux complètes à côté des conteneurs pour que vous puissiez accéder à un shell sans wrapper de conteneur.
Où il fait défaut : macOS uniquement. L’utilisation commerciale est payante. L’absence de versions pour Windows et Linux signifie que ce ne peut jamais être le seul outil de dev container de votre équipe.
Tarification :
- Gratuit : Personnel, utilisation non commerciale
- Payant : Niveau Pro pour utilisation commerciale, facturé par siège par mois
Plateformes : macOS
Télécharger : orbstack.dev
Conclusion : OrbStack est la première installation appropriée sur un Mac personnel. Sur un Mac professionnel, tenez compte du niveau commercial dans la décision.
5. Rancher Desktop — Meilleur pour un vrai K8s local plus dev containers
Rancher Desktop par SUSE expédie Docker ou containerd en tant que runtime et k3s en tant que vrai cluster Kubernetes à nœud unique. Cette combinaison est inhabituelle. Les extensions de dev containers le traitent comme un socket compatible avec Docker, et une fois que votre workflow requiert un K8s local pour tester les manifests, Rancher Desktop couvre les deux surfaces à partir d’une seule installation.
Où elle fait défaut : Plus de pièces mobiles qu’un runtime de conteneur simple. Le premier lancement est lent pendant que la VM Linux démarre. La documentation sur le changement entre les runtimes Docker et containerd est mince.
Tarification :
- Gratuit : Open source complet
- Payant : SUSE Rancher pour l’orchestration à l’échelle, non requis pour l’utilisation locale
Plateformes : Windows, macOS, Linux
Télécharger : rancherdesktop.io
Conclusion : Rancher Desktop est le choix quand votre journée de travail alterne entre “reopen in container” et kubectl apply.
6. Colima — Meilleur pour Docker léger sans GUI sur macOS ou Linux
Colima est une fine CLI au-dessus de Lima qui démarre une VM Linux avec Docker ou containerd à l’intérieur. Pas d’icône de barre d’état, pas de demandes de mise à jour, pas de licence. Vous exécutez colima start, pointez la CLI de Docker sur son socket, et l’extension Dev Containers de VS Code ouvre les dossiers dans les conteneurs sans différence perceptible par rapport à Docker Desktop.
Où elle fait défaut : Pas de GUI. Le support Kubernetes existe mais est un meilleur effort. Les performances de partage de volume sont acceptables, pas les plus rapides de la liste.
Tarification :
- Gratuit : Entièrement open source
- Payant : Aucun
Plateformes : macOS, Linux
Télécharger : github.com/abiosoft/colima
Conclusion : Colima est le remplaçant orienté terminal de Docker Desktop sur les Mac. Choisissez-le si vous vivez déjà dans le shell.
7. Distrobox — Meilleur pour les bureaux Linux containerisés
Distrobox enveloppe Podman ou Docker pour exécuter les distributions Linux complètes en tant que conteneurs étroitement intégrés. Ce n’est pas un runner de spécification de dev containers strict, mais il aborde le même problème sous un autre angle : un environnement Debian, Fedora ou Arch par projet sur n’importe quel hôte Linux, avec accès à votre répertoire personnel et à votre GPU. Combinez-le avec devcontainers/cli et vous avez à la fois des environnements pilotés par spécification et des environnements gratuits par projet.
Où il fait défaut : Linux uniquement. N’est pas un drop-in pour devcontainer.json par lui-même, il complète donc plutôt que de remplacer les autres choix.
Tarification :
- Gratuit : Entièrement open source
- Payant : Aucun
Plateformes : Linux
Télécharger : distrobox.it
Conclusion : Distrobox est la réponse sur les distributions Linux immuables comme Silverblue et Bazzite, où les paquets système sont verrouillés et les conteneurs par projet deviennent le flux de travail par défaut.
8. GitHub Codespaces — Meilleur pour le même dev container dans le cloud
GitHub Codespaces prend votre devcontainer.json de repo et démarre une VM hébergée qui s’ouvre dans le navigateur, VS Code ou JetBrains Gateway. Le passage d’un dev container local à un Codespace est un mouvement en un clic car le fichier est déjà là. L’avantage est qu’un laptop 16 Go peut piloter un Codespace 32 Go, et un nouvel embauché code en moins de deux minutes.
Où elle fait défaut : Coût de sortie et de calcul après épuisement des heures gratuites. La latence des frappes est bonne sur une connexion solide et douloureuse sur le Wi-Fi de l’hôtel. Certains réseaux bloquent le protocole de tunneling.
Tarification :
- Gratuit : Heures core mensuelles pour les comptes personnels sur GitHub Free
- Payant : Facturation à l’heure au-delà du quota, plus stockage par Go par mois
Plateformes : Web, VS Code, JetBrains Gateway
Télécharger : github.com/features/codespaces
Conclusion : Codespaces est la solution de secours quand le laptop n’est pas la machine pour exécuter le conteneur. Même fichier, hôte différent.
Comment choisir le bon
- Si vous voulez l’installation la plus simple et êtes à l’aise avec la licence : Docker Desktop. C’est le standard que la spécification suppose.
- Si les conditions de Docker Desktop sont un problème ou que vous voulez sans privilèges : Podman Desktop.
- Si vous êtes sur Apple Silicon et le coût n’est pas une contrainte : OrbStack pour personnel, Podman Desktop pour laptop de travail avec préoccupations de licence.
- Si votre équipe exécute tout sur Kubernetes : Rancher Desktop, ou DevPod pointant vers votre cluster.
- Si vous passez la journée dans le terminal : Colima.
- Si vous êtes sur Silverblue, Bazzite ou un autre Linux immuable : Distrobox plus CLI de dev containers.
- Si vous brûlez le matériel qui ne peut pas suivre : GitHub Codespaces.
FAQ
Qu’est-ce qu’un dev container ? Un environnement de développement délimité par dossier défini par un fichier .devcontainer/devcontainer.json qui épingle le runtime, les paquets système et les extensions d’éditeur. Ouvrez le dossier dans un éditeur supporté et l’outil réconcilie le conteneur à partir de ce fichier.
Ai-je besoin de Docker Desktop pour utiliser les dev containers ? Non. La CLI des dev containers fonctionne avec n’importe quel socket compatible avec Docker. Podman, Colima, Rancher Desktop et OrbStack en exposent tous un.
Puis-je utiliser les dev containers sans VS Code ? Oui. devcontainers/cli lit le même fichier et ouvre un shell dans le conteneur. JetBrains Gateway supporte aussi la spécification.
Y a-t-il un coût de licence pour les dev containers eux-mêmes ? Non. La spécification et la CLI de référence sont open source sous licence MIT. Le coût provient du runtime et de toute exécution hébergée.
Comment un dev container se compare-t-il à un environnement virtuel ? Un venv ou un dossier node_modules épingle l’écosystème du langage. Un dev container épingle aussi le système d’exploitation, ce qui résout le bug “cela fonctionne sur ma machine” entre coéquipiers.
Les dev containers peuvent-ils utiliser une GPU ? Oui, sur les hôtes Linux et sur Windows avec WSL2 et le passthrough CUDA. Ajoutez les features appropriées et le bloc hostRequirements au devcontainer.json et exposez le dispositif GPU au conteneur.