Les Dev Containers ne m'ont vraiment parlé que le jour où j'ai contribué à de l'open source

Je m’en souviens assez bien. J’avais cloné le dépôt Bitwarden server avec l’intention de soumettre une petite contribution. Serveur en .NET, une poignée de microservices, MSSQL, un serveur mail de test. Le genre de setup qui, habituellement, représente une journée de configuration avant d’écrire la première ligne utile.

Sauf que le dépôt avait un fichier .devcontainer.json. J’ai ouvert VS Code, cliqué sur “Reopen in Container”. Moins d’une heure plus tard, j’avais un environnement fonctionnel : les bons SDK installés, les variables d’environnement configurées, les extensions activées. J’ai pu me concentrer sur ce pour quoi j’étais venu.

C’est là que j’ai compris ce que les Dev Containers résolvent vraiment, et pourquoi je n’avais pas vu leur valeur jusqu’alors.

En résumé : les Dev Containers ne brillent pas sur les projets solos. Leur valeur est asymétrique, elle croît avec la complexité du projet et le nombre de personnes qui doivent y travailler. Le meilleur test pour les évaluer : arriver sur une codebase inconnue et mesurer le temps avant d’écrire la première ligne utile.

Ce qu’un Dev Container fait, en pratique

Un Dev Container, c’est un environnement de développement défini par du code et embarqué dans le dépôt. Un fichier .devcontainer/devcontainer.json décrit ce que doit contenir cet environnement : le runtime, les outils CLI, les extensions VS Code, les variables d’environnement, les ports à exposer.

VS Code lit ce fichier et construit un conteneur Docker local qui fait office de machine de développement. Le code reste sur la machine hôte, mais l’exécution, le linting et le débogage se passent dans le conteneur.

Le principe est formalisé par la spécification open source devcontainers.io, maintenue par Microsoft et la communauté. GitHub Codespaces utilise le même format : un Codespace n’est en réalité qu’un Dev Container hébergé dans le cloud.

{
  "name": "Mon projet",
  "image": "mcr.microsoft.com/devcontainers/typescript-node:20",
  "features": {
    "ghcr.io/devcontainers/features/git:1": {}
  },
  "customizations": {
    "vscode": {
      "extensions": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode"]
    }
  }
}

Le concept répond au problème classique du “ça marche sur ma machine”. Sauf que dans ce cas, toutes les machines partagent la même définition d’environnement, stockée dans le dépôt au même titre que le code.

Si vous voulez aller plus loin dans la configuration, le guide de Stéphane Robert couvre l’ensemble de la spec en détail : lifecycle hooks, features réutilisables, intégration Docker Compose multi-services et pipeline CI/CD.

Sur mes projets persos, un outil de plus pour pas grand-chose

Avant Bitwarden, j’avais bien essayé les Dev Containers. Sur deux ou trois projets personnels, j’avais créé le fichier de configuration, suivi la documentation, obtenu un résultat fonctionnel. Et pourtant, quelques semaines plus tard, je revenais à mon environnement local classique.

Pas parce que ça ne fonctionnait pas. Parce que le bénéfice n’était pas tangible dans ce contexte.

Quand on travaille seul sur un projet qu’on a soi-même initialisé, on est déjà l’environnement de référence. La version de Node installée sur la machine, c’est la version du projet. Les extensions de l’éditeur, c’est exactement ce qu’il faut. Il n’y a pas d’écart à combler, pas d’autre développeur pour qui standardiser l’expérience.

Le coût d’entrée (configurer le fichier, attendre la construction du conteneur, déboguer les premiers problèmes de montage de volumes) dépasse largement le bénéfice sur un side-project de quelques centaines de lignes. C’est parfaitement rationnel de ne pas l’utiliser dans ce contexte.

Ce que je n’avais pas anticipé, c’est que ce raisonnement ne tient plus dès qu’on change de contexte.

Qu’est-ce qui change quand on débarque sur une codebase inconnue ?

L’environnement est une précondition résolue, pas un problème à résoudre. C’est ce qui change quand un dépôt dispose d’un Dev Container. Sur Bitwarden : cloner, ouvrir dans le conteneur, attendre la construction, commencer à explorer le code. Rien d’autre.

Sans Dev Container, la même opération prend une heure minimum dans le meilleur des cas. La documentation de contribution de Bitwarden est remarquablement complète : il faut quand même configurer le mot de passe MSSQL, démarrer les bons conteneurs dans le bon ordre, vérifier que le service Identity répond sur le bon port. Une demi-journée si on tombe sur une incompatibilité de version.

Contribuer à un projet open source de taille réelle, c’est une expérience particulière : la codebase a une histoire, des conventions établies, des dépendances précises. L’équipe principale développe avec des versions spécifiques d’outils. La documentation de setup est souvent rédigée avec les meilleures intentions, mais elle a inévitablement du retard sur la réalité. Le Dev Container est la seule forme de documentation de setup qui ne ment pas.

Selon le State of Development Environments 2025 de Coder et SlashData (consulté le 2026-05-16), seulement 7 % des organisations peuvent provisionner un environnement de développement en moins d’une heure ; 21 % d’entre elles y consacrent plus de deux jours. Le Dev Container s’attaque directement à ce plancher : l’environnement ne se réinstalle pas, il se reconstruit à l’identique.

C’est exactement ce que j’évoquais dans mon analyse des stratégies IDE en entreprise : le premier jour, un développeur devrait écrire du code, pas passer des heures à comprendre pourquoi son terminal se comporte différemment de celui de son voisin. Les Dev Containers en sont le prolongement naturel à l’échelle d’une codebase complète.

Selon le rapport Docker State of App Development 2025 (consulté le 2026-05-16), 71 % des décideurs techniques estiment que l’onboarding d’un nouveau développeur prend au minimum deux mois. Les Dev Containers ne suppriment pas ce délai ; mais ils éliminent la partie la plus évitable : la configuration de l’environnement.

Pourquoi la valeur des Dev Containers est asymétrique

La valeur d’un Dev Container n’est pas proportionnelle à sa qualité de configuration. Elle est proportionnelle à l’écart entre l’environnement attendu et l’environnement disponible chez la personne qui arrive sur le projet.

Sur un projet solo où on est le seul développeur depuis le début : écart nul, valeur quasi nulle.

Sur un projet d’équipe avec des machines différentes (macOS, Windows, Linux) : écart significatif, valeur réelle.

Sur un dépôt open source où n’importe qui dans le monde peut vouloir contribuer, avec n’importe quelle configuration locale : écart maximal, valeur structurelle.

Des projets comme Supabase, NestJS ou Vite ont adopté les Dev Containers précisément pour cette raison : réduire la friction à l’entrée pour les contributeurs externes. Ce n’est pas un détail de confort ; c’est un levier de santé de l’écosystème.

Terminal à conteneurs — photo par Daniel Miksha / Unsplash

Selon ce même rapport Docker State of App Development 2025 (consulté le 2026-05-16), 64 % des développeurs utilisaient des environnements non-locaux comme setup principal en 2025, contre 36 % l’année précédente. Les Dev Containers en sont l’une des manifestations les plus concrètes : l’environnement devient quelque chose qu’on décrit, qu’on partage et qu’on reconstruit, pas quelque chose qu’on configure une fois et qu’on espère ne plus toucher.

Faut-il en mettre partout ?

Non. La réponse honnête, c’est que ça dépend du contexte.

Pour un side-project sur lequel vous travaillez seul, sans intention de le partager : le rapport coût/bénéfice ne justifie probablement pas l’investissement initial. L’environnement local est suffisant.

La question change dès qu’un des critères suivants s’applique.

Plusieurs développeurs sur le même dépôt : même deux. Le “ça marche chez moi” est un problème en puissance dès le premier onboarding.

Un projet open source : même modeste. Quelqu’un voudra peut-être contribuer un jour, et chaque heure éliminée du setup est une friction de moins entre une bonne intention et un PR soumis.

Soi-même dans six mois : c’est souvent le scénario oublié. Rouvrir un projet après une longue absence et retrouver un environnement prêt, c’est une forme de documentation qui ne ment pas.

Le signal d’alarme : se retrouver en train d’écrire une section “Installation” longue et fragile dans le README. C’est souvent le signe qu’un Dev Container résoudrait le problème structurellement plutôt que de le documenter. Le même réflexe vaut pour la stack de déploiement : quand les instructions de mise en production tiennent en un setup reproductible sur un VPS, on a franchi le même seuil de maturité.

Questions fréquentes

Les Dev Containers fonctionnent-ils avec d’autres éditeurs que VS Code ?

Oui. Le format .devcontainer.json est standardisé par la spécification open source devcontainers.io. JetBrains a ajouté le support dans IntelliJ et ses autres IDEs. GitHub Codespaces utilise le même format pour ses environnements cloud. L’adoption dépasse VS Code, même si c’est l’éditeur qui a popularisé le concept.

Un Dev Container remplace-t-il un environnement Docker Compose existant ?

Pas nécessairement ; les deux coexistent souvent. Docker Compose gère les services de l’application (base de données, cache, workers), le Dev Container définit l’environnement dans lequel le développeur travaille. Le fichier devcontainer.json peut référencer un docker-compose.yml existant pour démarrer les services associés à l’ouverture du conteneur.

Par où commencer si on veut ajouter un Dev Container à un projet existant ?

VS Code propose une commande “Dev Containers: Add Dev Container Configuration Files” dans la palette, qui génère une configuration de base selon le langage détecté. La bibliothèque de templates officielle couvre la plupart des stacks courants : Node, Python, .NET, Go, Rust. C’est un bon point de départ, à affiner selon les besoins du projet.

Les Dev Containers fonctionnent-ils dans les pipelines CI/CD ?

Oui. Un Dev Container n’est qu’une image Docker accompagnée d’un fichier de configuration : le même environnement peut être réutilisé dans GitHub Actions ou n’importe quel runner CI compatible Docker. L’avantage est la cohérence : les tests s’exécutent dans exactement le même runtime que l’environnement de développement local. La CLI devcontainers simplifie cette intégration pour la plupart des pipelines courants.