J’ai rejoint Mutual-IT au sein des Mutualités Libres en janvier dernier. Un constat s’est rapidement imposé : le développement local s’effectue actuellement sur des environnements souvent purement Windows, alors que les environnements de test et de production tournent sous Linux. Cet écart entre le poste de travail et la cible finale est une source classique d’erreurs lors des déploiements, sans compter que le code des développeurs tourne directement dans l’environnement windows et donc est sujet aux mêmes règles de sécurité à peu de choses près que les agents et utilisateurs classiques, empêchant toute forme de recherche, d’essais, de tests pour modifier et faire évoluer les méthodes de travail.
La plus grande friction est sans doute la friction liée au déploiement, au fait que ça tourne en local mais en pas en ITT, UAT, PRD, souvent pour des raisons de configurations, réglage mémoire, cas limites non testable, accès aux configurations et aux environnement verrouillés.
Pour illustrer comment réduire cette friction et tendre vers une approche déclarative d’infrastructure as code, qui permettra d’avoir l’environnement en local le plus proche possible de la production et donc de réduire aux maximum les frictions, j’ai mis en place un showcase technique disponible sur GitLab : https://gitlab.com/mloz/docker-showcase.
L’idée est de s’approcher le plus possible de la réalité et de simuler une architecture hexagonale modulaire dans différents container. Le projet est organisé en quatre stacks indépendantes :
- Une base de données PostgreSQL 15.
- Une API développée avec FastAPI et Python 3.11.
- Un serveur de rendu côté serveur (SSR) avec Node.js 20.
- Un reverse proxy Nginx qui sert de point d’entrée unique et gère la mise en cache des réponses de l’API.
L’intérêt technique réside dans l’utilisation d’un réseau externe commun nommé showcase-net. Cette approche permet de découpler totalement les couches : seul le proxy expose un port vers la machine hôte. L’API et le frontend sont isolés et ne communiquent qu’en interne via le réseau Docker. Pour moi, cette configuration est intéressante car elle évite la pollution des ports locaux et reproduit plus fidèlement un environnement de production Linux, peu importe l’OS du développeur.
Cette démarche s’inspire de bonnes pratiques que mon équipe a mis en place lors de mon précédent emploi à la RTBF, notamment en ce qui concerne l’isolation rigoureuse des pipelines CI/CD et la simplification des cycles de développement et de déploiement. L’objectif est d’assurer que le code qui tourne sur le poste du développeur soit identique à celui qui sera déployé.
Pour construire ce projet, j’ai utilisé une chaîne d’outils basée sur l’IA locale. Le modèle Gemma-4-31b a été exécuté via LMStudio, intégré à VSCodium grâce à l’extension Cline. J’avais précédemment testé l’intégration entre LMStudio et Continue, mais l’expérience s’est révélée instable (erreurs fréquentes dans l’interprétation de certains tags et une dégradation rapide de la qualité des réponses après quelques prompts, rendant l’outil difficilement utilisable pour des sessions de travail prolongées). Le couple VSCodium + Cline s’est montré beaucoup plus robuste et précis et stable.
Cette architecture n’est pas une proposition éducative pragmatique et par l’exemple pour faciliter l’onboarding et harmoniser les environnements de travail chez Mutual-IT. L’idée est qu’un simple script shell puisse installer l’ensemble de l’infrastructure sans aucune installation préalable sur le système hôte, hormis Docker ou Podman.
C’est une base de réflexion que je vais partager avec mes collègues pour ouvrir la discussion et définir ensemble les standards qui nous conviennent le mieux. Éventuellement en faire un atelier avec des branches précises type, step-01, step-02 … pour avoir des retours et une base commune de compréhension des modèles utilisant les containers pour le développement local.
Et vous comment partagez-vous vos idées, vos nouveaux concepts auprès de vos collègues ?