Dans de nombreuses institutions publiques belges, le déploiement continu est techniquement possible, mais les mises en production restent rares. La raison en est rarement le pipeline. C'est plutôt la crainte de mettre une fonctionnalité à la disposition des utilisateurs avant qu'elle ne soit prête. Lorsque la livraison du code et son activation ne font qu'un, chaque mise en production comporte un risque qui n'a rien à voir avec le code.
Nous avons collaboré avec une grande institution publique fédérale belge afin de dissocier ces deux actions : déployer le code en continu, et décider séparément du moment de son activation. Pour ce faire, nous avons eu recours aux « feature flags », adoptés progressivement plutôt que de manière obligatoire. Aujourd’hui, 15 de ses 17 équipes techniques les utilisent en production.
Télécharger le fichier PDFLe point de départ
L'institution disposait déjà d'une infrastructure CI/CD moderne. Le principal obstacle était d'ordre opérationnel : comment effectuer plusieurs déploiements par jour sans exposer des fonctionnalités inachevées ou instables ? Le projet concernait 17 équipes techniques, plusieurs milliers d'agents en aval et une plateforme Java/Angular sur OpenShift.
Les mêmes problèmes se posaient à chaque mise en production. Les équipes hésitaient à déployer, de peur 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 des travaux en cours, ni aucun filet de sécurité permettant de pratiquer le développement basé sur la branche principale. Le déploiement et la mise en production étaient toujours indissociables.
Ce que nous avons fait
Plutôt que de déployer l'outil auprès de 17 équipes d'un seul coup, nous avons commencé par une équipe pilote, la version gratuite et un peu de temps. L'équipe pilote a mis en œuvre les « feature flags » en production, a recueilli les résultats, puis les a partagés en interne. D'autres équipes ont demandé à utiliser l'outil, au lieu de se le voir imposer par la hiérarchie.
Concrètement :
- Flagsmith a été retenu parmi plusieurs solutions, en réponse à des critères bien définis : conformité à la norme OpenFeature (absence 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'environnement OpenShift du client.
- Une démonstration de faisabilité en production sur la version gratuite à partir de juillet 2022, suivie par la version entreprise sur l'environnement OpenShift du client en janvier 2025, une fois que la demande se sera concrétisée.
- Authentification unique (SSO) via Keycloak existant, sans identité parallèle à gérer.
- Gouvernance centralisée : une vue d'ensemble unifiée permettant de savoir qui active quoi, pour qui et quand.
Le code est désormais déployé en production en continu. L'activation a lieu dès qu'une fonctionnalité est prête pour les utilisateurs auxquels elle est destinée, et peut être désactivée immédiatement en cas de problème.
Les chiffres
| 88% | environ 2 ans | Déployer ≠ activer |
|---|---|---|
| Parmi ces équipes (15 sur 17), certaines utilisent des « feature flags » en production. | pour que l'adoption se généralise à partir d'une seule équipe pilote, sans plan imposé par la hiérarchie. | Le déploiement et l'activation constituent désormais deux décisions distinctes. |
Ces chiffres s'inscrivent dans le cadre d'un projet précis, dans un contexte précis.
Ce qui a fait la différence
Ce n'est pas l'outil en lui-même, 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 déjà 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 aux résultats concrets : le projet pilote a démontré la valeur de l’outil, et les autres équipes ont demandé à suivre. Le signe le plus évident est le passage de la version gratuite à la version entreprise payante, déployée sur l’infrastructure du 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 : il s’agit d’une évolution progressive ancrée dans la réalité de chaque organisation, et non d’un simple changement radical. Cette approche convient aux organisations disposant déjà d’une base CI/CD et dont les dirigeants sont prêts à laisser l’adoption de cette méthode se développer au fur et à mesure des résultats concrets. Lorsque ce n’est pas le cas, il faut s’adapter.
Aller plus loin
Ce projet s'inscrit dans le cadre de notre approche « Mission informatique », aux côtés de L4F (analyse et pilotage du portefeuille d'applications grâce à l'IA) et de la transition organisationnelle. Depuis 2017, 5th floor accompagne la transformation numérique des institutions publiques belges et est certifiée B Corp depuis 2025.
Si les lancements vous semblent risqués, ou si la crainte de vous exposer trop tôt freine votre rythme de développement, n’hésitez pas à nous contacter. Une conversation d’une heure suffit souvent pour définir les premières étapes.
