Nos actualités
200 Instances Jenkins sur le Cloud : Comment les offrir sans se ruiner !
Après vous avoir montré comment gérer plus de 200 instances Jenkins comme une seule grâce à FluxCD (article à retrouver dans nos actualités) , now it's time to learn comment les déployer sur le Cloud sans exploser les coûts💸!!
Chez Bpifrance, chaque jour compte.
Notre mission est de financer les entreprises françaises, et notre vélocité technique est l'un des moyens pour y parvenir. Chaque jour gagné pour lancer un nouveau service a un impact.
Pourtant, il y a trois ans, le point de départ de tout projet était un frein majeur. Le délai moyen pour qu'un développeur obtienne un socle technique de base – repository, instance CI/CD, outils qualité – était de 48 heures.
Deux jours d'attente, rythmés par des tickets et des processus manuels interminables. Cette friction n'était pas qu'une simple frustration. Elle était la porte ouverte aux contournements : projets démarrés sans gestion de version, utilisation de dépôts GitHub personnels hors de notre gouvernance, ou encore "cannibalisation" de la CI/CD d'un autre projet. Un risque de sécurité majeur et une dette technique en devenir. Le "run" généré pour notre équipe CI/CD était tout aussi pénalisant. Avec un minimum de 60 nouveaux projets par an, et près d'une heure de travail manuel par demande, c'était plus de 60 heures-homme – quasiment deux semaines de travail – perdues chaque année en tâches répétitives. Pour les équipes de développement, le bilan était encore plus lourd : plus de 120 jours cumulés (60 projets x 48h) passés à attendre au lieu de produire de la valeur.
Nous avons alors transformé ce problème en un OKR (Objective and Key Results) ambitieux : "Une équipe doit pouvoir obtenir l'environnement CICD de son projet en moins de 15 minutes"
Voici comment nous y sommes parvenus, non pas avec un projet pharaonique, mais avec une méthode pragmatique et une obsession pour la valeur livrée.
“In God they trust, all others must bring data.”
Avant de coder, nous avons cartographié le processus existant avec une Value Stream Mapping (VSM).
L'atelier a notamment mis en lumière une étape de validation manuelle dont l'intention était légitime: "Nous ne voulons pas que n'importe qui puisse demander n'importe quoi."
Cependant, ce que la VSM a révélé, c'est que ce contrôle manuel était validé à 100% dans la pratique, il n'apportait donc pas plus de sécurité, juste du délai.
Plutôt que de le supprimer aveuglément, nous l'avons remplacé par des contrôles automatisés, plus intelligents et plus robustes :
- Une vérification via API que le code projet demandé correspond bien à une application existante dans notre référentiel
- Un renforcement du RBAC (Role-Based Access Control) pour s'assurer qu'un demandeur ne peut agir que sur le périmètre des applications sur lesquelles il est habilité à travailler.
La VSM nous a permis de passer d'une sécurité basée sur une intervention humaine faillible à une gouvernance intégrée, automatisée et bien plus fiable. La donnée avait parlé.
“Talk is cheap. Show me the code.”
Plutôt que de débattre pendant des mois de l'architecture de l'API parfaite, nous avons décidé d'agir. Pour tester notre hypothèse – "si on leur donne un outil simple, les équipes l'utiliseront" – nous avons délibérément choisi la vitesse et le pragmatisme en combinant no-code et automatisation existante :
- Un formulaire Microsoft Forms pour sa simplicité et le SSO intégré
- Un Job Jenkins paramétré déclenché par un simple webhook.
Cette approche a, sans surprise, fait grincer quelques dents. Les objections étaient vives et pertinentes : "Ce n'est pas une vraie API", "Ce n'est pas l'état de l'art", "Ce n'est pas robuste". Et c'était vrai. Mais notre conviction était que la vitesse d'apprentissage primait sur la perfection technique à cet instant T. C'était une dette technique calculée. Un prêt que nous contractions en toute conscience pour acheter de la certitude rapidement.
Lors du premier lancement, nous avons même ajouté une notification dans notre canal Teams : "XX a demandé une forge pour le projet ZZZ". Nous étions tous en train de surveiller le processus. Trente minutes plus tard, la première instance était provisionnée. Victoire.
Bien sûr, ce MVP avait les défauts de ses qualités : la chaîne était un "fire-and-forget" sans reprise sur erreur, et il a fallu communiquer et re-communiquer le lien du formulaire, qui se perdait facilement. Mais il fonctionnait. Mieux encore : il a inspiré. Une autre équipe "socle", orchestration de container sur kubernetes, voyant la puissance de l'approche, a répliqué le modèle, créant ainsi de la valeur rapidement pour les clients.
“Make it work, make it right, make it fast.”
Le succès du MVP nous a donné l'envie, le mandat et le ROI pour passer à l'étape "make it right". Nous avons remplacé le bricolage initial par une architecture conçue pour la résilience, l'évolutivité et une véritable expérience développeur.
- Une façade API REST : Nous avons exposé une API claire, documentée avec une interface Swagger UI. N'importe qui peut désormais interagir avec le service, soit via un formulaire, soit en ligne de commande, sans friction.
- Un Événement Kafka ProjectCreationRequested : L'API publie un événement et répond instantanément. La demande est dans le système, sécurisée, auditable et prête à être consommée en asynchrone.
- Des Consumers Spécialisés et Idempotents : En coulisses, des services autonomes et résilients consomment l'événement pour provisionner tous les assets : création du repo Git, des groupes de sécurité, d'une instance Jenkins dédiée au projet, des dépôts Artifactory, des projets Sonar, et envoi de l'e-mail récapitulatif.
Cette nouvelle architecture, plus performante, nous a aussi permis d'optimiser nos scripts. Nous avons progressivement réduit le temps de traitement pour finalement atteindre et tenir notre objectif initial de 15 minutes.
Pourrions-nous encore optimiser ce temps ? Certainement.
Allons-nous le faire ? Non.
La raison est simple : le ratio investissement/gain n'est plus en notre faveur à ce stade. Nous préférons réinvestir cette énergie là où la douleur est la plus forte. C'est aussi ça, le pragmatisme.
“The future is already here – it's just not evenly distributed.”
Aujourd'hui, l'onboarding projet est un non-sujet. Un self-service disponible 24/7 qui a libéré des centaines d'heures et renforcé notre gouvernance. Qui pourrait résister?!
Cette transformation, menée par notre équipe CI/CD, a confirmé la solidité de nos choix stratégiques, techniques et organisationnels :
- Mesurez la douleur pour justifier l'action. La frustration est un signal. Des données comme celles issues d'une VSM la transforment en un business case
- Osez la dette technique calculée. Un MVP "imparfait" qui apporte une réponse en quelques jours vaut mille fois mieux qu'une solution parfaite qui n'arrive jamais. C'est le chemin le plus court vers la connaissance
- Le pragmatisme est contagieux. Une solution simple qui fonctionne inspire bien plus qu'une présentation théorique. Partagez vos prototypes, même "sales" et acceptez les feedbacks !
- L'excellence architecturale est la récompense d'un succès prouvé. On industrialise et on rend propre une fois que la valeur est confirmée et que l'adoption est là.
Au final, nous n'avons pas seulement livré un outil, nous avons aidé à distribuer un peu plus largement cette culture où les équipes sont habilitées à résoudre leurs propres problèmes en faisant preuve d’autonomie intelligente, toujours guidée par la force du groupe.
Si cette façon de penser la technologie – orientée valeur, pragmatique et sans concession sur la qualité finale – vous parle, nous avons certainement des défis passionnants à vous proposer. Jetez un œil à nos opportunités !
Technologies associées