Du code à la mise en production sans interruption

Dans de nombreuses administrations publiques belges, la modernisation du pipeline de déploiement est encore considérée comme un événement ponctuel plutôt que comme une pratique continue. La mise en production reste une opération risquée qui mobilise plusieurs équipes, nécessite des fenêtres de maintenance et entraîne parfois l'interruption d'un service le temps que tout revienne à la normale. Les développeurs livrent leur code, puis ils attendent.

Ce fossé entre le développement et la production a un coût réel. Non seulement en termes de retards, mais aussi en termes de confiance : plus on redoute chaque mise en production, moins on en effectue, et plus il devient difficile d'assurer une livraison continue.

Nous avons collaboré avec une grande institution publique fédérale belge dans le cadre d’une modernisation complète de son pipeline de déploiement. Résultat : 98 % des applications ont été migrées vers la nouvelle plateforme, aucune interruption de service en production, et des équipes de développement véritablement autonomes, du code à la production. Cet article présente en détail ce que nous avons réalisé et, surtout, les choix qui nous ont permis d’y parvenir sans recourir à une approche « Big Bang ».

Source : 5th floor, étude de cas « Du code à la mise en production, en toute autonomie », 2026. Pour plus d'informations, contactez-nous à l'adresse sales@5thfloor.be.

Télécharger le fichier PDF

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

L'établissement comptait plusieurs milliers d'employés et disposait de dizaines d'applications métier. Sur le papier, une infrastructure informatique solide. Dans la pratique, cinq obstacles structurels se présentaient à chaque mise en production :

• Une séparation stricte entre les développeurs et l'équipe chargée des déploiements en production. Le code est transmis de l'une à l'autre, avec des délais et des priorités différents à chaque étape.
• Les déploiements manuels, lents et sources d'erreurs.
• Rien ne garantissait que ce qui avait été validé lors des tests correspondait exactement à ce qui avait été déployé en production.
• Une infrastructure JBoss vieillissante, difficile à faire évoluer.
• Il n'y avait aucun filet de sécurité en cas de problème : la restauration constituait une opération à part entière, sans aucune automatisation.

On observe régulièrement ce phénomène dans le secteur public. Non pas parce que les équipes manquent de compétences, mais parce que l'organisation et les outils n'ont pas su s'adapter à la complexité croissante du portefeuille d'applications.

Pourquoi nous n'avons pas tout réécrit

Face à une telle situation, la tentation est grande de se lancer dans un projet de refonte totale : geler le système existant, mener une migration massive en parallèle, puis effectuer la bascule d’un seul coup. Le fameux « Big Bang ».

Sur le papier, cela semble séduisant. Dans la pratique, cela échoue souvent. Comme l’a expliqué Gilles Stragier lors de son webinaire organisé dans le cadre de la Semaine européenne de l’IA 2026, le 19 mars 2026, les données du secteur concernant les projets de refonte radicale sont éloquentes: environ 70 % d’entre eux dépassent le budget ou les délais prévus, et 17 % sont annulés en cours de route.

Nous avons fait un choix différent : migrer application par application, mettre en place le nouveau pipeline en nous appuyant sur les outils que les équipes utilisaient déjà, et maintenir l'environnement de production opérationnel tout au long du processus. Une transition, pas une transformation.

La plateforme : conteneurisation, OpenShift, Helm

Voici les mesures qui ont été mises en place :

• Containerisation des applications avec Docker. Une image créée une seule fois, déployée de manière identique partout. Finies les divergences entre les environnements de test et de production.

• Orchestration via OpenShift, choisi pour sa conformité aux exigences de sécurité du secteur public et pour sa fiabilité à grande échelle.

• Charts Helm personnalisés. Chaque nouvelle application hérite automatiquement des fonctionnalités de surveillance (Grafana), de journalisation centralisée (Kibana) et de sécurité (Keycloak). Plus besoin de reconfiguration manuelle pour chaque projet.

• Un mécanisme sans interruption de service. La nouvelle version se lance en arrière-plan, et la bascule n'a lieu qu'une fois le déploiement validé. En cas de problème, la version actuelle reste active. Les utilisateurs ne remarquent rien.

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

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

Et un point qui passe souvent inaperçu : les migrations de bases de données et les configurations de sécurité sont appliquées automatiquement depuis l'application elle-même, sans aucune intervention humaine.

Les chiffres après la migration

Dans le cadre de cette plateforme, voici ce qu'elle produit aujourd'hui

Ces résultats s'inscrivent dans le cadre d'un projet spécifique, dans un contexte particulier. Pour les reproduire ailleurs, il est nécessaire d'évaluer le contexte propre à chaque organisation. Reportez-vous à la section « À qui s'adresse ce document ? » ci-dessous.

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

Tout d’abord, le choix de s’appuyer sur ce qui existait déjà plutôt que d’imposer une nouvelle pile technologique. Bamboo et Bitbucket étaient déjà en place. Au lieu de les remplacer, nous les avons étendus. Les développeurs n’ont pas eu à tout réapprendre, ce qui a permis d’éviter la résistance classique que suscitent les projets de transformation.

Ensuite, la co-construction. Chaque élément de la plateforme (pipelines, Helm Charts, scripts de déploiement) a été conçu avec les équipes de développement, et non pour elles. La différence se ressent au quotidien : les équipes s’approprient ce qu’elles ont contribué à concevoir.

Enfin, l’autonomie est un objectif quotidien, et non un résultat final. À la fin du projet, les développeurs testent, compilent et déploient eux-mêmes. Les mesures de sécurité automatiques (tests, restauration, surveillance) prennent le relais des contrôles humains. La barrière entre le développement et la production a disparu, et personne n’a perdu son rôle. L’équipe traditionnellement chargée des déploiements a vu son travail évoluer vers l’expertise en matière de plateforme et l’accompagnement, plutôt que vers des tâches répétitives.

À qui s'adresse ce produit ?

Cette approche fonctionne lorsque certaines conditions sont réunies. Une équipe informatique interne suffisamment importante pour prendre en charge la plateforme. La volonté de la direction d'investir dans l'autonomie de l'équipe, et pas seulement de la proclamer. Des outils existants pouvant être fait évoluer plutôt que d'être abandonnés.

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

C'est aussi pour cette raison que nous parlons de « transition » plutôt que de « transformation » : il s'agit d'un processus progressif, ancré dans la réalité de chaque organisation.

FAQ

Aller plus loin

Ce projet s'inscrit dans le cadre de notre approche « IT Mission », l'un des trois piliers d'5th floor , aux côtés de L4F (analyse et pilotage du portefeuille d'applications grâce à l'IA) et de la transformation organisationnelle et culturelle.

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

Si vous vous reconnaissez dans ce billet (un fossé entre le développement et la production, des déploiements qui font peur, ou l'envie de moderniser sans savoir par où commencer), n'hésitez pas à nous contacter. Une conversation d'une heure suffit souvent pour définir les premières pistes à suivre.