-- Mes preuves --

InnotechFusion qui était une étude de cas d’entrainement, imposait la Dockerisation du frontend et du backend dans un délai très court. Deux Dockerfiles à écrire : un pour l'application Angular, un pour le backend Spring Boot. L'image Angular devait produire un build de production et le servir via un serveur web léger. L'image Spring Boot devait packager le JAR et exposer l'API sur le bon port. La pipeline CI/CD GitLab configurée pour ce projet automatisait le build des images et validait que le projet se construisait proprement à chaque push. Le fichier README documentait la procédure de déploiement pour qu'un tiers puisse récupérer le projet et le lancer sans friction. Projet réalisé seul, de A à Z, en conditions d'examen, livré dans les délais. ShopWise était une étude de cas d’examen a poussé la pratique Docker un cran plus loin. En plus des deux Dockerfiles pour le frontend Angular et le backend Spring Boot, un fichier docker-compose.yml devait orchestrer l'ensemble des services : le frontend, le backend, et la base de données MySQL. Les trois conteneurs devaient communiquer entre eux dans un réseau Docker isolé, avec les bonnes variables d'environnement pour que le backend trouve la base de données au démarrage. La pipeline GitHub Actions configurée pour ce projet automatisait le build Maven, l'exécution des tests avec génération des rapports de couverture téléchargeables, et le push des images Docker sur DockerHub. Chaque étape de la pipeline était liée à son contexte : les tests ne bloquaient pas le build si les couvertures étaient atteintes, les images n'étaient poussées que si les tests passaient. Développé seul, en conditions d’examen. PMT qui était une étude de cas d’examen a été le projet sur lequel la chaîne d'industrialisation a été la plus complète. Dockerfile backend, Dockerfile frontend, docker-compose.yml pour l'orchestration locale, pipeline GitHub Actions couvrant le build, les tests unitaires et d'intégration, la génération des rapports de couverture, et le push des images sur DockerHub. La documentation de déploiement dans le README permettait à n'importe quel développeur de cloner le projet et de le lancer en une commande. Ce projet a aussi mis en lumière un enjeu important de la conteneurisation : l'ordre de démarrage des services. Le backend Spring Boot ne doit pas tenter de se connecter à MySQL avant que la base de données soit prête à accepter des connexions. Gérer cette dépendance proprement dans le docker-compose.yml, avec des healthchecks ou des stratégies de retry, est un détail qui fait la différence entre un docker-compose qui fonctionne et un qui échoue aléatoirement. Développé seul, de bout en bout, en conditions d’examen.

-- Autocritique --

Docker est la compétence sur laquelle la progression a été la plus visible d'un projet à l'autre. Les premiers Dockerfiles étaient fonctionnels mais peu optimisés : des images lourdes parce que le build context n'était pas bien délimité, des layers mal ordonnés qui invalidaient le cache à chaque modification du code source. Ces erreurs sont classiques chez un junior, elles s'apprennent en les faisant. Ce qui est maîtrisé aujourd'hui : écrire des Dockerfiles pour des applications Angular et Spring Boot, orchestrer plusieurs services avec Docker Compose, configurer une pipeline CI/CD qui pousse des images sur DockerHub. Ces éléments ont été mis en œuvre sur les trois projets d'examen, livrés et validés. Ce qui reste à travailler : l'optimisation des images. Un Dockerfile multi-stage bien conçu peut diviser par cinq ou dix la taille d'une image de production. Sur les projets académiques, la taille des images n'était pas une contrainte évaluée. En production, ça impacte directement les temps de déploiement, les coûts de stockage et la surface d'attaque de l'application. C'est un sujet qui mérite plus d'attention que ce qui lui a été accordé jusqu’ici. Kubernetes est la prochaine étape logique après Docker Compose, et le niveau actuel dessus est nul. C'est honnête. Orchestrer des conteneurs en production sur un cluster, gérer des rolling updates, des health checks, des secrets : c'est un univers à part entière qui nécessite un apprentissage dédié. Docker est solide. Ce qui se passe après Docker, c'est encore un chantier.

-- Évolution --

L'optimisation des Dockerfiles est le premier chantier concret. Comprendre et appliquer le multi-stage build systématiquement, construire des images de production légères qui ne contiennent que ce qui est strictement nécessaire, ordonner les layers pour exploiter le cache Docker au maximum : ce sont des pratiques qui s'apprennent vite et qui changent réellement la qualité des livrables. Kubernetes arrive juste après. Pas pour maîtriser l'ensemble de l'écosystème d'un coup, mais pour comprendre les concepts fondamentaux : pods, services, deployments, configmaps, secrets. Savoir déployer une application conteneurisée sur un cluster k3s ou un environnement cloud managé comme GKE ou EKS est une compétence qui devient progressivement indispensable pour tout développeur qui touche à la production. Dans le cadre du projet de société de développement logiciel, Docker sera au cœur de chaque livraison. Chaque application développée sera conteneurisée dès le début, pas en fin de projet. La conteneurisation ne sera pas une étape d'industrialisation ajoutée à la fin, elle fera partie de l'architecture dès la première ligne de code. C'est une discipline que ces projets d'examen ont installée, et qu'il n'est pas question de perdre.

-- Projets liés --