» T’as cloné. T’as suivi le README. T’as tout installé. Ouais… mais ça marche pas. » 

Encore un projet. Encore un onboarding. Encore une demi-journée de débogage d’environnement. 

Romain, développeur senior chez Elosi, en quête de sérénité, a dit stop. Il a mis tous ses projets dans des DevContainers. Il raconte. 

Assez de bricolage : un setup ISO pour tout le monde 

On a tous connu le fameux : 

• « Chez moi ça marche » 
• « Tas pas la bonne version de Docker »
• « Faut installer… » 

 

La réalité, c’est que faire marcher un projet sur plusieurs machines, OS, configurations et cerveaux différents… c’est jamais trivial. Et plus l’équipe grandit, plus ça devient une source de friction. 

 

Ce que je voulais, c’était simple : 

• Un environnement identique pour tout le monde 
• Facile à lancer, facile à comprendre 
• Zéro setup local : tu clones, tu ouvres, ça tourne. 

 

DevContainers : comment ça marche, concrétement ? 

Un DevContainer, c’est un environnement de développement Dockerisé. Tout est défini dans un fichier devcontainer.json (et parfois un Dockerfile ou docker-compose.yml), ce qui permet de : 

• Lancer automatiquement un container basé sur ce que tu as défini
• Monter ton code dans le container 
• Installer les extensions nécessaires 
• Configurer les variables d’environnement, les ports, les commandes post-install
• Et surtout… te faire oublier qu’il y a un container derrière 

Propre. Isolé. Reproductible. Et surtout : ça marche, partout, sans chouiner. 

Prérequis pour se lancer 

Avant de faire tourner tes DevContainers comme un chef : 

1. Installe l’extension Remote Containers dans VS code : code –install-extension ms-vscode-remote.remote-containers

   
   
2. Assure-toi que Docker est installé 
3. Et bien sûr, un éditeur à jour (ici on va prendre l’exemple de VS Code) à jour et un OS pas trop capricieux. 

 

3 cas d’usage concrets 

1. Le projet Python simple : zéro setup, zéro blabla 
Objectif : exécuter un script Python en un clic 

 

Tu veux juster tester un bout de code, montrer un exemple, ou filer un petit repo à quelqu’un sans qu’il ait à installer quoi que ce soit ? DevContainer = solution express. 

 

Arborescence : 

.
├── .devcontainer/
│   ├── devcontainer.json
│   └── Dockerfile
└── main.py
main.py :
print("Hello World from my DevContainer")
.devcontainer/Dockerfile :
FROM python:alpine
WORKDIR /workspace
.devcontainer/devcontainer.json :
{
  "name": "hello-python",
  "build": {
    "dockerfile": "Dockerfile"
  },
}

 

Une fois le dossier ouvert avec Remote Containers : 

• Tu ouvres un terminal dans VS Code 
• Tu lances : python main.py 

 

Et voilà : ton script s’exécute dans un environnement propre, sans pip install, sans venv, sans galère. 

 

Idéal pour : petits outils, démos, scripts partagés 

 

2. Le projet multi-service : Python + PostgreSQL 

Un projet plus réaliste avec deux services : un backend Python (FastAPI par exemple) et une base PostgreSQL. 

 

Arborescence : 

.
├── .devcontainer/
│   ├── devcontainer.json
│   └── docker-compose.yml
├── app/
│   └── main.py
│   └── requirements.txt
└── db/ (volume de la base)
docker-compose.yml :
services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - ../app:/workspace:cached
    command: sleep infinity
    network_mode: service:db

  db:
    image: postgres:latest
    restart: unless-stopped
    volumes:
      - postgres-data:/var/lib/postgresql/data
    environment:
      POSTGRES_USER: postgres
      POSTGRES_DB: postgres
      POSTGRES_PASSWORD: postgres

volumes:
  postgres-data:


devcontainer.json :
{
  "name": "fastapi-postgres",
  "dockerComposeFile": "docker-compose.yml",
  "service": "app",
  "shutdownAction": "stopCompose",
  "workspaceFolder": "/workspace"
}

 

 

main.py : 

from typing import Union

from fastapi import FastAPI

app = FastAPI()


@app.get("/")
def read_root():
    return {"Hello": "World"}

 

 

requirements.txt : 

fastapi==0.115.12
fastapi-cli==0.0.7

 

 

Et après ouverture ? 

1. Terminal –> python main.py si tu veux lancer le code 
2. Terminal –> fastapi dev main.py si tu veux le mode auto-reload (via fastapi-cli)
3. Tout est prêt, la base est accessible, FastAPI tourne sur http://localhost:8000 , sans rien installer en plus. 

 

Idéal pour : un vrai projet d’équipe, un onboarding clean, un dev backend sans friction. 

 

3. Le projet avancé : automatisation 

Là on sort l’artillerie lourde. L’objectif : 

• S’init automatiquement 
• Prêt à débugger 

 

Arborescence : 

.
├── .devcontainer/
│   ├── devcontainer.json
│   └── docker-compose.yml
├── app/
│   └── .vscode
│   │   └── launch.json
│   └── main.py
│   └── requirements.txt
└── db/ (volume de la base)

 

 

Devcontainer.json : 

{
  "name": "project-ultimate",
  "dockerComposeFile": "docker-compose.yml",
  "service": "app",
  "shutdownAction": "stopCompose",
  "workspaceFolder": "/workspace",
  "postCreateCommand": "pip install --user -r requirements.txt",
  "customizations": {
		"vscode": {
			"extensions": [
				"ms-python.python",
				"ms-python.vscode-pylance",
				"esbenp.prettier-vscode",
				"ms-python.black-formatter",
				"charliermarsh.ruff",
				"ms-python.debugpy"
			]
		}
	}
}

 

 

launch.json : 

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python Debugger: FastAPI",
            "type": "debugpy",
            "request": "launch",
            "module": "uvicorn",
            "args": [
                "main:app",
                "--reload"
            ],
            "jinja": true
        }
    ]
}

 

 

Résultat final 

1. Tu clones le repo
2. Tu ouvres le dossier avec « Reopen in Container » via VS Code 
3. Tu cliques sur « Start Debugging » dans le menu Run and Debug 

 

Et voilà : 

• Ton backend FastAPI tourne sur http://localhost:8000
• Avec hot reload
• Base de données déjà connectée
• Extensions prêtes

 

Bonus : idées d’amélioration (si tu veux aller plus loin) 

Tu veux pousser le DevContainer encore plus loin ? Voici quelques idées pour upgrader ton setup : 

• Ajouter un Makefile et centralise les commandes de dev courantes 
• Précharger des données de test dans la BDD
• Ajout d’outils de qualité (lint/format/type check)
• Multi-stage build ou build allégé
• Customisation VS Code encore plus poussée 
• Variables d’environnement
• … 

 

En conclusion : Le calme, c’est un .devcontainer bien fait 

Une fois que tu as mis les pieds dans un DevContainer, c’est comme un café bien chaud un lundi matin : tu ne peux plus t’en passer. 

• Moins de « ça ne marche pas chez moi »
• Moins de frustration sur les configs locales 
• Moins de juniors qui râlent (même si ça, c’est jamais garanti à 100%) 

 

Et surtout, je passe plus de temps à coder, moins à réparer l’environnement. 

 

Essaie sur ton prochain projet. Tu verras.