Dans de nombreuses institutions publiques belges, le déploiement continu est techniquement possible, mais les mises à jour restent rares. La raison n’est que rarement liée au pipeline. C’est plutôt la crainte d’exposer une fonctionnalité aux utilisateurs avant qu’elle ne soit prête. Lorsque la mise en production du code et son activation ne font qu’un, chaque mise à jour comporte un risque qui n’a rien à voir avec le code lui-même.
Nous avons travaillé avec une grande institution publique fédérale belge pour séparer ces deux actes : déployer du code en continu, décider séparément quand l'activer. Le levier était constitué de feature flags, adoptés progressivement plutôt qu'imposés. Aujourd'hui, 15 de ses 17 équipes techniques les utilisent en production.
Le point de départ
Les mêmes problèmes se posaient à chaque mise en production. Les équipes hésitaient à déployer par crainte d’exposer du code inachevé. Il n’existait aucun moyen de tester d’abord une fonctionnalité auprès d’un sous-ensemble d’utilisateurs, aucune vue d’ensemble de ce qui était en cours, ni aucun filet de sécurité permettant de pratiquer le développement basé sur le tronc (trunk-based development). Le déploiement et la mise en production étaient encore indissociables.
Les mêmes problèmes survenaient à chaque version. Les équipes hésitaient à déployer par crainte d'exposer du code inachevé. Il n'y avait aucun moyen de tester une fonctionnalité auprès d'un sous-ensemble d'utilisateurs au préalable, aucune vue centralisée de ce qui était en cours, et aucun filet de sécurité pour pratiquer le développement basé sur le tronc. Le déploiement et la mise en production étaient toujours liés.
Ce que nous avons fait
Plutôt que de déployer un outil auprès de 17 équipes d’un seul coup, nous avons commencé par une équipe pilote, la version gratuite et du temps. Le projet pilote a mis les indicateurs de fonctionnalité en œuvre en production, a recueilli les résultats, puis les a partagés en interne. Les autres équipes ont demandé à utiliser l’outil plutôt que de se le voir imposer par la hiérarchie.
Concrètement :
- Flagsmith, sélectionné sur une grille claire : conformité à la norme OpenFeature (pas de dépendance vis-à-vis d’un fournisseur), intégration native avec la pile Java / Angular, et possibilité de déploiement au sein de l’OpenShift du client.
- Une preuve de concept en production sur la version gratuite à partir de juillet 2022, suivie par la version entreprise dans l’OpenShift du client en janvier 2025, une fois la demande avérée.
- SSO via l’instance Keycloak existante, sans identité parallèle à gérer.
- Gouvernance centralisée : une vue unifiée de qui active quoi, pour qui et quand.
Le code est désormais déployé en production en continu. L’activation a lieu lorsqu’une fonctionnalité est prête, pour les utilisateurs auxquels elle est destinée, et peut être désactivée immédiatement si un problème survient.
Quelques chiffres
| 88% | Environ 2 ans | Déployer ≠ activer |
|---|---|---|
| des équipes (15 sur 17) utilisent des *feature flags* en production. | pour que l'adoption se propage à partir d'une seule équipe pilote, sans plan imposé par la direction. | le déploiement et l'activation sont désormais deux décisions distinctes. |
Ces chiffres concernent un projet spécifique dans un contexte particulier.
Ce qui a fait la différence
Ce n’est pas l’outil, mais la manière dont il a été mis en place. Nous nous sommes appuyés sur ce que les équipes utilisaient déjà : la norme ouverte, la pile existante, le Keycloak en place. Il n’y avait donc rien à réapprendre et aucune des résistances habituelles ne s’est manifestée. L’adoption s’est développée grâce à la preuve : le projet pilote a démontré la valeur ajoutée, et les autres équipes ont demandé à suivre. Le signe le plus évident est le passage de la version gratuite à la version entreprise payante sur l’infrastructure propre au client. Les équipes ne paient pas pour conserver un outil qu’elles ne faisaient que tolérer.
C’est pourquoi nous parlons de transition plutôt que de transformation : un mouvement progressif ancré dans la réalité de chaque organisation, et non un simple changement de mode de fonctionnement. Cette approche convient lorsqu’une base CI/CD est déjà en place et que la direction est disposée à laisser l’adoption se développer par la preuve. Lorsque ce n’est pas le cas, il faut s’adapter.
Aller plus loin
Ce projet s’inscrit dans notre approche « IT Mission », aux côtés de L4F (analyse et pilotage du portefeuille d’applications via l’IA) et de la transition organisationnelle. 5th floor accompagne la transformation numérique des institutions publiques belges depuis 2017 et est certifié B Corp depuis 2025.
Si les mises en production vous semblent risquées, ou si votre cadence est freinée par la crainte de vous exposer trop tôt, n’hésitez pas à nous contacter. Une conversation d’une heure suffit souvent pour définir les premières étapes.
