Utiliser les Dev Containers pour le développement local

Vous avez probablement vécu cette situation : un nouveau développeur rejoint votre équipe, et deux jours plus tard, il se bat encore avec des conflits de versions Node, des dépendances manquantes et des variables d’environnement qui fonctionnent sur toutes les machines sauf la sienne. Pendant ce temps, votre projet reste inexploité.

Les Dev Containers résolvent ce problème en encapsulant l’intégralité de votre environnement de développement — runtime, outils, extensions et configuration — dans un conteneur qui fonctionne de manière identique sur chaque machine. Cet article explique comment les Dev Containers créent des environnements de développement reproductibles pour les équipes frontend sans nécessiter une expertise approfondie de Docker.

Ce que font réellement les Dev Containers

Les Dev Containers sont des conteneurs Docker configurés spécifiquement pour le travail de développement. Contrairement aux conteneurs de production qui exécutent votre application, les Dev Containers exécutent l’intégralité de votre environnement de développement. Votre éditeur se connecte au conteneur, et tous vos outils s’exécutent à l’intérieur.

L’idée clé est simple : au lieu de documenter les étapes de configuration en espérant que tout le monde les suive correctement, vous définissez votre environnement par code. Lorsqu’un développeur ouvre votre projet, il obtient exactement la même version de Node, les mêmes outils de linting et les mêmes extensions d’éditeur que tout le monde.

Cette approche du développement local conteneurisé élimine complètement le problème du « ça marche sur ma machine ». Votre fichier devcontainer.json devient la source unique de vérité pour la manière de développer sur votre projet.

Concepts fondamentaux à comprendre

Le fichier devcontainer.json

Toute configuration de Dev Container commence par un fichier devcontainer.json, généralement stocké dans un dossier .devcontainer à la racine de votre projet. Ce fichier indique à votre éditeur comment construire ou récupérer le conteneur et ce qu’il faut configurer à l’intérieur.

Une configuration minimale pour un projet frontend ressemble à ceci :

{
  "name": "Frontend Dev Environment",
  "image": "mcr.microsoft.com/devcontainers/typescript-node:20",
  "forwardPorts": [3000],
  "customizations": {
    "vscode": {
      "extensions": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode"]
    }
  }
}

Cette configuration récupère une image Node 20 pré-construite avec support TypeScript, redirige le port 3000 pour que vous puissiez accéder à votre serveur de développement depuis le navigateur hôte, et installe automatiquement les extensions ESLint et Prettier dans VS Code.

Images vs. Dockerfiles

Vous avez deux options pour définir la base de votre conteneur. Utiliser une image pré-construite (comme dans l’exemple ci-dessus) est plus simple et plus rapide — le conteneur démarre rapidement car il n’y a rien à construire. Utiliser un Dockerfile vous donne un contrôle total mais ajoute du temps de construction.

Pour la plupart des projets frontend, les images pré-construites du dépôt d’images Dev Container de Microsoft fonctionnent bien. Vous pouvez les étendre avec des Features — des ajouts modulaires qui installent des outils spécifiques sans nécessiter de Dockerfiles personnalisés.

Docker Compose pour les configurations complexes

Lorsque votre frontend nécessite des services backend pendant le développement — une base de données, un serveur API ou un cache Redis — l’intégration Docker Compose vous permet de définir des environnements multi-conteneurs. Votre devcontainer.json référence le fichier Compose, et tous les services démarrent ensemble.

{
  "name": "Full Stack Dev Environment",
  "dockerComposeFile": "docker-compose.yml",
  "service": "app",
  "workspaceFolder": "/workspace"
}

Dans cette configuration, la propriété service spécifie à quel conteneur du fichier Compose votre éditeur doit se connecter, tandis que les services restants (bases de données, caches, APIs) s’exécutent à côté.

Variables d’environnement : containerEnv vs. remoteEnv

Cette distinction est importante et source de confusion. containerEnv définit les variables au démarrage du conteneur — elles sont disponibles pour tous les processus. remoteEnv définit les variables uniquement pour les processus que votre éditeur lance. Utilisez containerEnv pour les variables dont vos outils de build ont besoin et remoteEnv pour les paramètres spécifiques à l’éditeur.

{
  "containerEnv": {
    "NODE_ENV": "development",
    "API_URL": "http://localhost:4000"
  },
  "remoteEnv": {
    "EDITOR_THEME": "dark"
  }
}

De même, containerUser détermine qui possède les processus dans le conteneur, tandis que remoteUser contrôle avec quel utilisateur votre éditeur se connecte. Se tromper sur ces paramètres provoque des erreurs de permissions qui frustrent les développeurs. Dans la plupart des cas, définir remoteUser sur "node" (pour les images basées sur Node) évite les problèmes de propriété root avec les fichiers générés.

Ce que les Dev Containers ne garantissent pas

L’installation des extensions et les paramètres de l’espace de travail ne sont pas parfaitement reproductibles d’une reconstruction à l’autre. Les extensions se mettent à jour, et certains paramètres dépendent de l’état local. Les configurations intégrées aux images peuvent également changer lorsque vous reconstruisez avec des images de base mises à jour.

Acceptez que les Dev Containers offrent de la cohérence, pas de l’immutabilité. Fixez les versions de vos images (par exemple, utilisez un digest SHA spécifique ou un tag daté plutôt que latest) et testez périodiquement votre configuration.

Compromis à considérer

Les Dev Containers ajoutent du temps de démarrage — les conteneurs doivent être construits ou récupérés avant de pouvoir travailler. Ils consomment de l’espace disque pour les images. Et votre équipe a besoin d’une familiarité de base avec les concepts Docker, même si elle n’écrit jamais de Dockerfiles.

Pour les équipes où l’intégration prend des jours et où la dérive d’environnement cause des problèmes réguliers, ces coûts sont négligeables. Pour les développeurs solo sur des projets simples, ils peuvent ne pas en valoir la peine.

Workflows émergents à surveiller

Les équipes intègrent de plus en plus des assistants de codage IA et des services de type agent via la configuration Dev Container. Le conteneur devient non seulement votre environnement de développement, mais aussi l’environnement où les outils automatisés opèrent sur votre code. Ce modèle évolue rapidement, mais la fondation — définir votre environnement par code — reste stable.

Démarrer

VS Code offre l’expérience Dev Container la plus fluide. Installez Docker Desktop, ajoutez l’extension Dev Containers, et exécutez Dev Containers: Add Dev Container Configuration Files depuis la palette de commandes. Choisissez un template correspondant à votre stack, et vous travaillez dans un conteneur en quelques minutes.

D’autres éditeurs supportent également les Dev Containers. Les IDE JetBrains (comme IntelliJ et WebStorm) offrent un support Dev Container intégré, et le Dev Container CLI open-source vous permet d’utiliser les Dev Containers depuis n’importe quel terminal ou pipeline CI.

Conclusion

L’investissement dans la configuration d’un Dev Container est rentabilisé dès la première fois qu’un nouveau coéquipier commence à contribuer le premier jour au lieu du troisième. En définissant votre environnement de développement par code dans un seul fichier devcontainer.json, vous remplacez une documentation de configuration fragile par une configuration reproductible et partageable. Les compromis — temps de démarrage, espace disque et compréhension de base des conteneurs — sont modestes comparés aux heures perdues à déboguer la dérive d’environnement. Commencez avec une image pré-construite, ajoutez les extensions sur lesquelles votre équipe s’appuie, et itérez à partir de là.

FAQ

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.