Le problème que Docker résout
Résumé : entre 2005 et 2013, installer une application sur trois machines différentes donnait trois résultats différents. Cette incohérence coûtait des millions d'heures perdues chaque année à l'industrie du logiciel. Docker a résolu ce problème avec une id ée simple : emballer l'application ET son environnement dans une boîte scellée. Cette leçon décrit le problème d'origine.
1. La phrase la plus détestée du développement logiciel
Vous êtes développeur·se. Votre application fonctionne parfaitement sur votre poste. Vous poussez le code, votre collègue le récupère, il essaie de le lancer.
Erreur.
Vous vérifiez. Sur votre machine, tout marche. Sur la sienne, tout casse. Vous prononcez alors la phrase la plus détestée de tout le développement logiciel :
« Bizarre… ça marche sur ma machine. »
Cette scène s'est jouée des milliards de fois entre les années 2000 et 2013, dans toutes les équipes techniques du monde. Elle coûtait des heures de débogage, des retards de livraison, des tensions dans les équipes, et des week-ends ruinés à réparer une production qui refusait de démarrer.
Chaque cause de divergence est banale. Prise séparément, chacune est facile à corriger. Mais elles se combinent, s'accumulent, et transforment une simple mise en production en enquête criminelle.
2. Les cinq sources d'incohérence les plus fréquentes
Décortiquons les vraies causes du « ça marche sur ma machine ».
2.1 · Les versions qui divergent
Votre application utilise Node.js 20. Votre collègue a installé Node.js 18. Le serveur de production tourne sous Node.js 16. Chaque version a ses propres API, ses propres bugs, ses propres subtilités.
Résultat : le même code produit trois comportements différents. Un test passe chez vous, échoue chez le collègue, plante en production.
2.2 · Les bibliothèques système invisibles
Votre application dépend de la bibliothèque libpq pour parler à PostgreSQL, de libjpeg pour manipuler les images, de openssl pour le chiffrement. Ces bibliothèques sont installées silencieusement sur votre poste, souvent depuis des années. Vous avez oublié qu'elles étaient là.
Sur la machine du collègue, elles manquent. Sur le serveur, la version diffère. Message d'erreur cryptique : error while loading shared libraries: libpq.so.5: cannot open shared object file.
2.3 · Les fichiers de configuration oubliés
Votre application lit un fichier .env avec la clé d'API Stripe, l'URL de la base de données, le secret JWT. Ce fichier est dans votre répertoire de projet, mais il est exclu de Git (bonne pratique de sécurité). Le collègue récupère le code sans le fichier.
L'application démarre… puis plante dès qu'elle essaie de lire une variable qui n'existe pas.
2.4 · L'ordre d'installation
Votre application a besoin de PostgreSQL, Redis, ImageMagick et Node.js, dans un ordre précis, avec des versions précises, et certaines dépendances doivent être installées avant d'autres. Vous l'avez fait il y a 6 mois, vous ne vous souvenez plus des étapes. Aucun document ne les liste.
Le nouveau membre de l'équipe passe deux jours à reconstituer l'ordre correct.
2.5 · Les différences d'OS
Votre équipe utilise Windows, macOS et Linux — un mélange devenu normal dans les entreprises modernes. Chaque OS a ses spécificités : chemins de fichiers avec \ ou /, encodage de fin de ligne (CRLF sur Windows, LF sur Linux), permissions différentes, outils système absents.
Un script Bash qui marche sur macOS peut planter sur Windows — et vice-versa avec PowerShell.
3. Le coût économique invisible
Ce chaos avait un coût énorme, invisible dans les budgets mais bien réel dans les délais.
Une étude de Puppet Labs en 2013 estimait que les équipes techniques passaient entre 40 % et 50 % de leur temps à combattre des problèmes d'environnement plutôt qu'à écrire du code utile.
4. Les tentatives de solution avant Docker
Le problème était connu, et la communauté avait essayé plusieurs approches — chacune apportant un progrès mais aucune ne résolvant vraiment tout.
Les machines virtuelles étaient la solution la plus proche du besoin : chaque VM contenait un environnement complet et reproductible. Mais le coût était prohibitif : plusieurs gigaoctets par VM, plusieurs minutes de démarrage, impossible d'en lancer 20 sur un poste développeur.
Il fallait une révolution.
5. Mars 2013 : la présentation qui a tout changé
Le 15 mars 2013, à la conférence PyCon à Santa Clara (Californie), Solomon Hykes, jeune ingénieur français fondateur d'une petite startup nommée dotCloud, monte sur scène pour une présentation lightning de 5 minutes.
Il présente Docker, un outil qui reprend les meilleures idées des machines virtuelles (isolation, reproductibilité), mais basé sur une technologie du noyau Linux appelée les namespaces — qui permet d'obtenir l'isolation sans le poids d'un OS complet.
Une salle en effervescence. En quelques mois, Docker devient le projet open source à la croissance la plus rapide de l'histoire de GitHub. En 2 ans, 83 % des grandes entreprises l'adoptent. En 2026, Docker (et ses cousins) fait tourner des dizaines de milliards de conteneurs par jour dans le monde.
6. Ce que Docker a rendu possible
Cette « boîte scellée » a débloqué des choses qui étaient techniquement possibles avant, mais économiquement irréalistes.
En 13 ans, Docker n'a pas juste résolu un problème technique — il a transformé la façon même dont on conçoit, déploie et exploite les logiciels modernes. Sans Docker, le mouvement DevOps, l'essor du cloud, et l'architecture microservices n'auraient jamais atteint leur maturité actuelle.
Retenir en 30 secondes
- Avant Docker, le même code produisait des comportements différents selon la machine où il tournait — le fameux « ça marche sur ma machine ».
- Les cinq sources d'incohérence : versions divergentes, bibliothèques système, fichiers de config oubliés, ordre d'installation, différences d'OS.
- Le coût cumulé approchait 40 à 50 % du temps des équipes techniques.
- Les solutions avant 2013 (docs, VM, Ansible, scripts) étaient toutes imparfaites.
- Docker (mars 2013) a apporté la boîte scellée légère : reproductibilité des VM sans leur poids.
Suivant : Qu'est-ce que Docker ? Définition, analogie, histoire →