Du code à la production sans rupture

Dans beaucoup d'administrations publiques belges, la mise en production reste un événement. Une opération à risque qui mobilise plusieurs équipes, demande des fenêtres de maintenance et bloque parfois un service le temps que tout retombe en place. Les développeurs livrent leur code, et puis ils attendent.

Ce mur entre développement et production coûte cher. Pas seulement en délais, mais en confiance : à force de redouter chaque mise en production, on en fait moins, et on perd la capacité de livrer en continu.

Nous avons accompagné une grande institution publique fédérale belge dans la modernisation complète de sa chaîne de déploiement. À l'arrivée : 98 % des applications migrées sur la nouvelle plateforme, zéro downtime en production, et des équipes de développement réellement autonomes du code à la prod. Ce billet revient sur ce que nous avons fait, et surtout sur les choix qui ont permis d'y arriver sans Big Bang.

*Source des résultats cités : 5th floor, case client "Du code à la production, en toute autonomie", 2026.Pour plus d'informations, contactez-nous via sales@5thfloor.be.

Télécharger le PDF

Le point de départ : silos, déploiements manuels, applications JBoss

L'institution comptait plusieurs milliers de collaborateurs et des dizaines d'applications métier. Sur le papier, une organisation IT solide. En pratique, cinq freins structurels remontaient à chaque mise en production :

• Une séparation stricte entre les développeurs et l'équipe chargée des mises en production. Le code passait de l'un à l'autre, avec des délais et des priorités différents à chaque étape.
• Des déploiements manuels, lents et propices aux erreurs.
• Aucune garantie que ce qui avait été validé en test correspondait exactement à ce qui partait en production.
• Un socle JBoss vieillissant, difficile à faire évoluer.
• Aucun filet en cas de problème : un retour arrière était une opération à part entière, sans automatisation.

C'est un schéma que nous croisons régulièrement dans le secteur public. Pas parce que les équipes manquent de compétences, mais parce que l'organisation et l'outillage n'ont pas suivi la complexité croissante du parc applicatif.

Pourquoi nous n'avons pas tout réécrit

La tentation, face à une situation comme celle-ci, c'est le projet de rénovation totale. On gèle l'existant, on lance une grande migration en parallèle, et on bascule tout d'un coup. Le fameux Big Bang.

Sur le papier, c'est séduisant. En pratique, ça échoue souvent. Lors du webinaire EU AI Week 2026 animé par notre cofondateur Gilles Stragier le 19 mars 2026, les chiffres cités sur les projets de réécriture en Big Bang étaient parlants : environ 70 % de dépassements de budget ou de délais, 17 % d'annulations en cours de route.

Note de transparence : ces ordres de grandeur ont été cités lors de notre webinaire interne. Pour publication externe, je recommande de remonter à la source primaire (Standish Group / CHAOS Report ou équivalent) avant de les chiffrer plus précisément.

Nous avons donc fait un choix différent : migrer application par application, construire la nouvelle chaîne sur les outils que les équipes utilisaient déjà, et garder la production active tout au long du chantier. Une transition, pas une transformation.

La plateforme : conteneurisation, OpenShift, Helm

Concrètement, voici ce qui a été mis en place :

• Une conteneurisation Docker des applications. Une image construite une seule fois, déployée à l'identique partout. Plus de dérive entre les environnements de test et de production.

• Une orchestration via OpenShift, retenue pour son alignement avec les exigences de sécurité du secteur public et sa fiabilité à grande échelle.

• Des Helm Charts sur mesure. Chaque nouvelle application hérite automatiquement du monitoring (Grafana), des logs centralisés (Kibana) et de la sécurisation (Keycloak). Plus besoin de tout reconfigurer manuellement à chaque projet.

• Un mécanisme de zéro downtime. La nouvelle version monte en arrière-plan, et le basculement ne s'effectue qu'une fois le déploiement validé. Si quelque chose se passe mal, la version courante reste active. Aucun utilisateur ne voit rien.

• Une bibliothèque de scripts réutilisables intégrée dans Bamboo et Bitbucket, les outils que les équipes connaissaient déjà. Pipelines templates, promotion d'images entre environnements, déploiement automatisé.

• Environnements de test éphémères. Chaque session de test automatisé s'exécute dans son propre environnement, créé à la volée et détruit après utilisation, sans interférence entre les équipes. Ce que les tests valident est exactement ce qui est déployé en production.

Et un point souvent négligé : les migrations de base de données et les configurations de sécurité sont appliquées automatiquement depuis l'application elle-même, sans aucune intervention humaine.

Les résultats chiffrés

Sur le périmètre couvert par cette plateforme, voici ce qu'elle produit aujourd'hui :

Ces résultats appartiennent à un projet spécifique, dans un contexte spécifique. Leur reproduction ailleurs nécessite d'évaluer le contexte de chaque organisation. Voir la section “ À qui s'adresse ceci ? ” ci-dessous.

Ce qui a vraiment fait la différence (et ce n'était pas la technologie)

Si je devais garder trois choses de ce projet, aucune d'entre elles ne serait technique.

Premièrement, le choix de bâtir sur l'existant plutôt que d'imposer une nouvelle stack. Bamboo et Bitbucket étaient déjà en place. Plutôt que de les remplacer, nous les avons étendus. Les développeurs n’ont pas eu à tout réapprendre, ce qui a évité la résistance classique des projets de transformation.

Puis, la co-construction. Chaque brique de la plateforme (pipelines, Helm Charts, scripts de déploiement) a été construite avec les équipes de développement, pas pour elles. La différence se voit dans l'usage quotidien : les équipes s'approprient ce qu'elles ont aidé à concevoir.

Enfin, l'autonomie comme objectif quotidien, non comme livrable final. D'ici la fin du projet, les développeurs testent, construisent et déploient eux-mêmes. Les garde-fous automatiques (tests, rollback, monitoring) prennent le relais des contrôles humains. Le mur entre le développement et la production a disparu, et personne n'a perdu son rôle. L'équipe historiquement responsable des déploiements a vu son travail évoluer vers l'expertise de la plateforme et le coaching, plutôt que vers l'exécution répétitive.

C'est pour qui ?

Cette approche fonctionne lorsque certaines conditions sont réunies. Une équipe informatique interne suffisamment importante pour s'approprier la plateforme. Une volonté de la direction d'investir dans l'autonomie de l'équipe, pas seulement de la déclarer. Des outils existants qui peuvent être améliorés plutôt que jetés.

Si le contexte est très différent (équipe informatique minimale, forte dépendance vis-à-vis d'un seul intégrateur, portefeuille d'applications réparti entre plusieurs fournisseurs sans gouvernance partagée), la même recette ne s'applique pas telle quelle. Il faut s'adapter, commencer parfois par d'autres axes de travail (gouvernance, structuration d'équipe) avant la modernisation technique.

C'est aussi pourquoi on parle de transition plutôt que de transformation : un mouvement progressif, ancré dans la réalité de chaque organisation.

FAQ

Aller plus loin

Ce projet fait partie de notre approche Mission IT , l'un des trois piliers de 5th floor avec L4F (analyse et pilotage du portefeuille d'applications par l'IA) et transformation organisationnelle et culturelle.

5th floor est un partenaire de la transformation numérique des institutions publiques belges depuis 2017, et certifié B Corp depuis 2025 (score de 89,5, évaluation publique disponible).

Si vous vous reconnaissez dans cette publication (un mur entre le développement et la production, des déploiements qui effraient, ou l'envie de moderniser sans savoir par où commencer), contactez-nous. Une heure d'échange suffit souvent pour dégrossir les premières pistes.