L'ingénierie frontend moderne ne ressemble en rien à ce qu'elle était il y a dix ans. Vous ne vous contentez plus d'écrire du HTML et du CSS. Un projet typique est désormais livré avec un runtime Node.js spécifique, une version verrouillée du gestionnaire de paquets, un enchevêtrement d'outils de build et des pipelines de déploiement qui exigent que tout soit parfaitement aligné. Entre le premier npm install et le build de production final, de petites différences s'immiscent. Un collègue utilise Node 20. Vous utilisez Node 18. Un outil CLI global sur votre machine masque une dépendance manquante sur la sienne. Puis vient la phrase que personne ne veut entendre : « Ça marche sur ma machine. »
Docker trouve sa place dans votre boîte à outils frontend car il élimine cette incertitude. Il regroupe votre application avec le runtime exact, les bibliothèques système et les dépendances dont elle a besoin. Que vous codiez sur Windows, que vous livriez depuis macOS ou que vous déployiez sur une instance cloud Linux, le comportement reste identique.
Pourquoi les développeurs frontend devraient s'y intéresser
Les points de friction que Docker résout ne sont pas abstraits. Ils apparaissent à chaque sprint.
Les conflits de version font perdre un temps précieux. Un ancien projet client nécessite Node 18, votre projet personnel nécessite Node 20, et votre nouveau travail en startup exige Node 22. Sans conteneurs, vous gérez cela via des gestionnaires de versions. Cela fonctionne, jusqu'à ce que cela ne fonctionne plus. Un léger décalage de version npm peut modifier la manière dont les peer dependencies sont résolues, vous laissant avec un build cassé qui fonctionne pourtant parfaitement pour quelqu'un d'autre. Lorsqu'un framework annonce une nouvelle version, la boucle de rétroaction ne devrait pas consister en deux heures de réinstallations. Elle devrait se limiter à une modification de fichier et au redémarrage d'un conteneur.
Les paquets globaux sont une autre source de friction silencieuse. Vous avez peut-être l'Angular CLI, Expo ou Prisma installés globalement depuis six mois. Un nouveau développeur installe le même outil à neuf et obtient une version différente. Soudain, vos scripts de build affichent des avertissements qui n'apparaissent nulle part ailleurs. Docker règle ce problème en gardant tout au niveau du projet. Vous définissez la version de Node dans votre Dockerfile. Les dépendances s'installent à l'intérieur du conteneur, isolées de votre système d'exploitation hôte. Votre ordinateur peut être sous macOS, Windows ou Ubuntu ; l'application voit exactement le même environnement à chaque fois.
Les avantages pour l'onboarding sont difficiles à ignorer. Les nouvelles recrues n'ont pas besoin d'un fichier readme de trois pages couvrant les installations Homebrew, les alias nvm et les corrections de permissions globales. Elles installent Docker, clonent le dépôt et exécutent une seule commande. Une configuration qui prenait autrefois un après-midi se réduit à quelques minutes. Et lorsqu'elles changent de projet, rien ne subsiste. Pas d'outils globaux orphelins. Pas de gestionnaires de versions qui se battent pour la priorité du PATH. Leur machine locale reste propre.
Images et conteneurs : les bases
Si Docker est nouveau pour vous, la terminologie est plus simple qu'il n'y paraît. Une image Docker est un modèle. Elle contient votre code source, le runtime Node.js, votre lockfile et chaque dépendance requise pour exécuter l'application. Un conteneur est une instance active créée à partir de cette image. Considérez l'image comme une recette et le conteneur comme le plat lui-même. Vous pouvez cuisiner le même gâteau cent fois à partir d'une seule recette. Vous pouvez lancer des conteneurs identiques à partir d'une seule image sans vous soucier de ce qui est installé sur l'ordinateur hôte.
Un Dockerfile pratique
Regardons un point de départ concret. Si vous êtes