Aucun filet en cas de probl\u00e8me : un retour arri\u00e8re \u00e9tait une op\u00e9ration \u00e0 part enti\u00e8re, sans automatisation.<\/li>\n<\/ul>\n\n\n\nC'est un sch\u00e9ma que nous croisons r\u00e9guli\u00e8rement dans le secteur public. Pas parce que les \u00e9quipes manquent de comp\u00e9tences, mais parce que l'organisation et l'outillage n'ont pas suivi la complexit\u00e9 croissante du parc applicatif.<\/p>\n\n\n\n
Pourquoi nous n'avons pas tout r\u00e9\u00e9crit<\/h2>\n\n\n\n La tentation, face \u00e0 une situation comme celle-ci, c'est le projet de r\u00e9novation totale. On g\u00e8le l'existant, on lance une grande migration en parall\u00e8le, et on bascule tout d'un coup. Le fameux Big Bang.<\/p>\n\n\n\n
Sur le papier, c'est s\u00e9duisant. En pratique, \u00e7a \u00e9choue souvent. Lors du webinaire EU AI Week 2026 anim\u00e9 par notre cofondateur Gilles Stragier le 19 mars 2026, les chiffres cit\u00e9s sur les projets de r\u00e9\u00e9criture en Big Bang \u00e9taient parlants : environ 70 % de d\u00e9passements de budget ou de d\u00e9lais, 17 % d'annulations en cours de route.<\/p>\n\n\n\n
Note de transparence : ces ordres de grandeur ont \u00e9t\u00e9 cit\u00e9s lors de notre webinaire interne. Pour publication externe, je recommande de remonter \u00e0 la source primaire (Standish Group \/ CHAOS Report ou \u00e9quivalent) avant de les chiffrer plus pr\u00e9cis\u00e9ment.<\/em><\/p>\n\n\n\nNous avons donc fait un choix diff\u00e9rent : migrer application par application, construire la nouvelle cha\u00eene sur les outils que les \u00e9quipes utilisaient d\u00e9j\u00e0, et garder la production active tout au long du chantier. Une transition, pas une transformation.<\/p>\n\n\n\n
La plateforme : conteneurisation, OpenShift, Helm<\/h2>\n\n\n\n Concr\u00e8tement, voici ce qui a \u00e9t\u00e9 mis en place :<\/p>\n\n\n\n
\nUne conteneurisation Docker des applications.<\/strong> Une image construite une seule fois, d\u00e9ploy\u00e9e \u00e0 l'identique partout. Plus de d\u00e9rive entre les environnements de test et de production.<\/li>\n<\/ul>\n\n\n\n\nUne orchestration via OpenShift,<\/strong> retenue pour son alignement avec les exigences de s\u00e9curit\u00e9 du secteur public et sa fiabilit\u00e9 \u00e0 grande \u00e9chelle.<\/li>\n<\/ul>\n\n\n\n\nDes Helm Charts sur mesure.<\/strong> Chaque nouvelle application h\u00e9rite automatiquement du monitoring (Grafana), des logs centralis\u00e9s (Kibana) et de la s\u00e9curisation (Keycloak). Plus besoin de tout reconfigurer manuellement \u00e0 chaque projet.<\/li>\n<\/ul>\n\n\n\n\nUn m\u00e9canisme de z\u00e9ro downtime.<\/strong> La nouvelle version monte en arri\u00e8re-plan, et le basculement ne s'effectue qu'une fois le d\u00e9ploiement valid\u00e9. Si quelque chose se passe mal, la version courante reste active. Aucun utilisateur ne voit rien.<\/li>\n<\/ul>\n\n\n\n\nUne biblioth\u00e8que de scripts r\u00e9utilisables int\u00e9gr\u00e9e dans Bamboo et Bitbucket,<\/strong> les outils que les \u00e9quipes connaissaient d\u00e9j\u00e0. Pipelines templates, promotion d'images entre environnements, d\u00e9ploiement automatis\u00e9.<\/li>\n<\/ul>\n\n\n\n\nEnvironnements de test \u00e9ph\u00e9m\u00e8res.<\/strong> Chaque session de test automatis\u00e9 s'ex\u00e9cute dans son propre environnement, cr\u00e9\u00e9 \u00e0 la vol\u00e9e et d\u00e9truit apr\u00e8s utilisation, sans interf\u00e9rence entre les \u00e9quipes. Ce que les tests valident est exactement ce qui est d\u00e9ploy\u00e9 en production.<\/li>\n<\/ul>\n\n\n\nEt un point souvent n\u00e9glig\u00e9 : les migrations de base de donn\u00e9es et les configurations de s\u00e9curit\u00e9 sont appliqu\u00e9es automatiquement depuis l'application elle-m\u00eame, sans aucune intervention humaine.<\/p>\n\n\n\n
Les r\u00e9sultats chiffr\u00e9s<\/h2>\n\n\n\n Sur le p\u00e9rim\u00e8tre couvert par cette plateforme, voici ce qu'elle produit aujourd'hui : <\/p>\n\n\n\n98%<\/strong><\/td>100%<\/strong><\/td>0<\/strong><\/td> Retour arri\u00e8re<\/strong><\/td><\/tr>d'applications s'ex\u00e9cutent sur la nouvelle plateforme, y compris les applications JBoss existantes, conteneuris\u00e9es dans un second temps.<\/td> des applications b\u00e9n\u00e9ficient automatiquement du monitoring, de la s\u00e9curit\u00e9 et des migrations de bases de donn\u00e9es gr\u00e2ce aux Helm Charts.<\/td> les temps d'arr\u00eat lors des d\u00e9ploiements de production.<\/td> en cas d'\u00e9chec, sans intervention manuelle.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nCes r\u00e9sultats appartiennent \u00e0 un projet sp\u00e9cifique, dans un contexte sp\u00e9cifique. Leur reproduction ailleurs n\u00e9cessite d'\u00e9valuer le contexte de chaque organisation. Voir la section \u201c \u00c0 qui s'adresse ceci ? \u201d ci-dessous.<\/p>\n\n\n\n
Ce qui a vraiment fait la diff\u00e9rence (et ce n'\u00e9tait pas la technologie)<\/h2>\n\n\n\n Si je devais garder trois choses de ce projet, aucune d'entre elles ne serait technique.<\/p>\n\n\n\n
Premi\u00e8rement, le choix de b\u00e2tir sur l'existant plut\u00f4t que d'imposer une nouvelle stack.<\/strong> Bamboo et Bitbucket \u00e9taient d\u00e9j\u00e0 en place. Plut\u00f4t que de les remplacer, nous les avons \u00e9tendus. Les d\u00e9veloppeurs n\u2019ont pas eu \u00e0 tout r\u00e9apprendre, ce qui a \u00e9vit\u00e9 la r\u00e9sistance classique des projets de transformation.<\/p>\n\n\n\nPuis, la co-construction.<\/strong> Chaque brique de la plateforme (pipelines, Helm Charts, scripts de d\u00e9ploiement) a \u00e9t\u00e9 construite avec les \u00e9quipes de d\u00e9veloppement, pas pour elles. La diff\u00e9rence se voit dans l'usage quotidien : les \u00e9quipes s'approprient ce qu'elles ont aid\u00e9 \u00e0 concevoir.<\/p>\n\n\n\nEnfin, l'autonomie comme objectif quotidien, non comme livrable final.<\/strong> D'ici la fin du projet, les d\u00e9veloppeurs testent, construisent et d\u00e9ploient eux-m\u00eames. Les garde-fous automatiques (tests, rollback, monitoring) prennent le relais des contr\u00f4les humains. Le mur entre le d\u00e9veloppement et la production a disparu, et personne n'a perdu son r\u00f4le. L'\u00e9quipe historiquement responsable des d\u00e9ploiements a vu son travail \u00e9voluer vers l'expertise de la plateforme et le coaching, plut\u00f4t que vers l'ex\u00e9cution r\u00e9p\u00e9titive.<\/p>\n\n\n\nC'est pour qui ?<\/h2>\n\n\n\n Cette approche fonctionne lorsque certaines conditions sont r\u00e9unies. Une \u00e9quipe informatique interne suffisamment importante pour s'approprier la plateforme. Une volont\u00e9 de la direction d'investir dans l'autonomie de l'\u00e9quipe, pas seulement de la d\u00e9clarer. Des outils existants qui peuvent \u00eatre am\u00e9lior\u00e9s plut\u00f4t que jet\u00e9s.<\/p>\n\n\n\n
Si le contexte est tr\u00e8s diff\u00e9rent (\u00e9quipe informatique minimale, forte d\u00e9pendance vis-\u00e0-vis d'un seul int\u00e9grateur, portefeuille d'applications r\u00e9parti entre plusieurs fournisseurs sans gouvernance partag\u00e9e), la m\u00eame recette ne s'applique pas telle quelle. Il faut s'adapter, commencer parfois par d'autres axes de travail (gouvernance, structuration d'\u00e9quipe) avant la modernisation technique.<\/p>\n\n\n\n
C'est aussi pourquoi on parle de transition plut\u00f4t que de transformation : un mouvement progressif, ancr\u00e9 dans la r\u00e9alit\u00e9 de chaque organisation.<\/p>\n\n\n\n
![](\"https:\/\/www.5thfloor.be\/wp-content\/uploads\/2025\/10\/download-btn.svg\")
![](\"data:image\/svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%2036%2036%22%3E%3C%2Fsvg%3E\")