Les environnements Python avec Docker, ce n’est plus une option.
C’est obligatoire. Ou ça devrait l’être. Imaginez votre équipe : Slack qui s’affole dès 9 heures, des ModuleNotFoundError partout, et ce collègue sous Windows qui jure que son code est nickel. Ça vous parle ? Chez nous, c’était la routine pendant cinq mois. Humiliant.
L’histoire originale tape dans le mille. « Cinq mois de « Ça marche sur ma machine ». Cinq mois de friction au onboarding. Cinq mois d’heures perdues par l’équipe. » Aïe. Ce n’est pas une anecdote, c’est un crime contre la productivité. Et je sais, personne n’aime admettre qu’on a laissé pourrir ça. Mais la vérité qui pique : si en 2024 vous galérez encore avec des environnements locaux, c’est vous le problème.
Pourquoi les environnements Python locaux sont un fiasco total
La machine de chaque dev ? Un monstre de Frankenstein. Des années d’installations pip à moitié foireuses, de bidouilles PATH, de paquets fantômes d’outils mal désinstallés. Mac, Windows, Linux — chacun son calvaire unique. requirements.txt ? Mignon. Virtualenvs ? Pas mal, mais fragiles comme pas permis. Une petite mise à jour de version Python — de 3.10.4 à 3.10.11 — et vlan, apocalypse des dépréciations.
On a perdu une journée de prépa démo à cause de ça. Trois heures à debugger du vent. Pathétique.
Docker renverse la table. L’interpréteur ne vit plus sur votre laptop. Il vit dans le projet. Le Dockerfile le dicte : version Python, dépendances, base OS. Construit une fois, exécuté partout. Plus d’excuses.
Et les Dev Containers de VS Code ? Du génie pur. Tunnel direct dedans — terminal, debugger, IntelliSense, tout conteneurisé. On dirait du local. Ce n’en est pas. Brillant.
We had a requirements.txt. We had virtual environments. We had a well-intentioned README with setup instructions that were already six weeks out of date. What we did not have was any guarantee whatsoever that the Python interpreter running on my Windows machine was looking at the same world as the one running on my colleague’s MacBook or our third teammate’s Ubuntu workstation.
Pile poil. C’est le fantôme qui hante toutes les équipes.
Installation Docker pour Python : le tuto sans bla-bla
Pas de chichis. Voici ce qu’on a mis en place. À la racine du projet :
my-project/ ├── .devcontainer/ │ └── devcontainer.json ├── Dockerfile ├── requirements.txt └── main.py
D’abord le Dockerfile. Simple comme bonjour :
FROM python:3.14.3-slim
RUN apt-get update && apt-get install -y --no-install-recommends git curl && rm -rf /var/lib/apt/lists/*
WORKDIR /app
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
Image slim ? Malin — vire le superflu, télécharge plus vite même en connexion pourrie. WORKDIR /app ? Chemins prévisibles, fini les migraines de mapping. requirements.txt en premier ? Magie du cache en couches. Le code change ? Le rebuild saute le pip. De la pure efficacité.
Ensuite, devcontainer.json dans .devcontainer/. Ça branche VS Code :
{
"name": "Python Dev",
"dockerfile": "../Dockerfile",
"workspaceFolder": "/app",
"features": {
"ghcr.io/devcontainers/features/python:1": {
"version": "3.14.3"
}
}
}
Cliquez sur Reopen in Container. Et hop — VS Code renaît dans Docker. Vos extensions ? Elles persistent dehors. Le terminal ? Pur conteneur. Le debugger ? S’allume direct.
Ça a pris un après-midi. Ça a sauvé des mois.
Docker, c’est de trop pour votre équipe Python ?
Hors de question. Dev solo ? Faites-le quand même. Pourquoi ? Votre futur vous sera reconnaissant en 2027 quand vous dépoussiérerez le repo. Intégrer un freelance ? Il est opérationnel en minutes, pas en jours.
Mais voilà mon avis bien senti — ce que personne ne dit : c’est le moment « npm install » de Python, comme Node dans ses années sombres. Vous vous rappelez 2010 ? Les devs Node noyés dans l’enfer des shrinkwraps, versions qui s’entre-tuent comme des divorces ratés. Yarn a sauvé la moitié ; Docker sauve tout. Les guerres pipenv-poetry-cond
