Pourquoi les DSI ne peuvent plus se payer le luxe du big bang
Les directions des systèmes d’information font face à un paradoxe brutal : la modernisation du legacy est devenue vitale alors que les enveloppes de build se contractent. Les projets de réécriture complète d’un système legacy ou d’une application legacy ne passent plus les comités d’investissement, alors même que la dette technique explose et que les métiers exigent une transformation digitale mesurable. Dans ce contexte, la modernisation progressive du SI n’est plus un slogan de cabinet, mais un art d’arbitrer chaque euro entre continuité de service, réduction des coûts de maintenance et sécurisation des données critiques.
Les chiffres publiés par IT For Business sur la pression budgétaire confirment ce mouvement, et les DSI de groupes comme BNP Paribas, La Poste ou Schneider Electric ont déjà acté que la migration cloud ne justifie plus un projet big bang sur leurs applications critiques. La stratégie de modernisation bascule vers des patterns incrémentaux où le système legacy reste en production, tandis que l’on modernise application par application, domaine par domaine, en contrôlant les risques opérationnels et les risques de sécurité. Cette approche suppose une discipline technique forte sur le code, les tests automatisés, la migration des données et la gouvernance de la dette technique, bien au-delà des slides de consultants.
Le premier choix structurant pour un DSI aguerri consiste à renoncer explicitement au fantasme de l’ancien système remplacé en une seule nuit, afin de privilégier une modernisation progressive articulée autour de trois patterns : strangler fig, side by side et anti corruption layer. Chacun de ces modèles d’architecture répond à un compromis différent entre risque, coûts de maintenance, complexité d’intégration et exigences métier, ce qui impose une analyse fine de chaque système legacy et de chaque application legacy. La question n’est donc plus « faut-il moderniser application par application » mais « dans quel ordre, avec quel pattern, et avec quel niveau de tests automatisés pour garantir la continuité de service ».
Strangler fig : moderniser les applications legacy par étouffement contrôlé
Le pattern strangler fig consiste à entourer progressivement un système legacy par de nouveaux services, jusqu’à ce que l’ancien système puisse être retiré sans rupture de continuité de service. Concrètement, une couche d’API façade expose les capacités du système legacy, puis de nouveaux microservices cloud native reprennent morceau par morceau le périmètre fonctionnel, en s’appuyant sur un refactoring maîtrisé du code et sur une migration des données progressive. Ce mode de modernisation applicative est particulièrement adapté aux applications legacy très couplées, où la dette technique et les risques de régression rendent tout big bang suicidaire.
Chez un assureur français comme MAIF, ce type de stratégie de modernisation a été utilisé pour moderniser des applications critiques de gestion de contrats, en isolant d’abord le système legacy via une anti corruption layer, puis en appliquant un strangler fig sur les parcours digitaux à plus forte valeur métier. Entre 2018 et 2021, un programme de trois ans a ainsi permis de migrer environ 40 % des parcours de souscription vers une architecture cloud native, avec une réduction mesurée de 25 % des coûts de maintenance sur le périmètre ciblé et une baisse de 30 % des incidents majeurs liés aux régressions (indicateurs internes de disponibilité et de MTTR). La gestion de projet a reposé sur des tests automatisés systématiques, une gouvernance de la dette technique outillée et une migration des données par domaines fonctionnels, ce qui a permis de réduire les coûts de maintenance sans interrompre l’activité. Pour un DSI, l’enjeu n’est pas seulement technique ; il s’agit de négocier avec les métiers un calendrier de modernisation qui aligne les releases applicatives sur les jalons de transformation digitale et sur les contraintes de sécurité.
Le strangler fig devient particulièrement puissant lorsqu’il est combiné à une stratégie de migration cloud sélective, où seules certaines applications legacy sont réhébergées, réarchitecturées ou réécrites en cloud native. Les organisations matures, observées par des cabinets comme Wavestone ou Gartner, rapatrient parfois des charges plutôt que de poursuivre une migration cloud massive, afin de mieux maîtriser les risques de souveraineté et de dépendance fournisseur. Dans ce contexte, la cartographie des dépendances entre systèmes legacy, flux de données et services cloud est un prérequis, et l’analyse de la souveraineté et des dépendances d’hébergement devient un outil de pilotage, pas une simple lecture de veille.
Étapes concrètes pour un strangler fig maîtrisé : 1) cartographier les fonctionnalités de l’application legacy et identifier les parcours métier prioritaires ; 2) définir une API façade et les contrats d’interface, puis mettre en place des tests automatisés de non-régression sur ces points d’accès ; 3) sélectionner un premier domaine fonctionnel à extraire, avec des critères de succès chiffrés (taux d’erreur, temps de réponse, incidents de production) ; 4) migrer progressivement les données associées, en prévoyant des mécanismes de synchronisation et de rollback ; 5) planifier le décommissionnement partiel de modules legacy au fur et à mesure des bascules, avec des jalons datés et validés en comité de pilotage.
Side by side : faire cohabiter ancien système et nouveau socle sans dérive éternelle
Le pattern side by side consiste à faire tourner en parallèle un ancien système et un nouveau socle applicatif, en orchestrant finement la répartition de charge et la migration des utilisateurs. Cette approche de modernisation incrémentale est souvent choisie pour les applications critiques à fort volume, où l’on veut mesurer en production la performance, la sécurité et la robustesse du nouveau logiciel avant de couper le système legacy. Elle permet aussi de tester des choix d’architecture cloud native, de valider des hypothèses de coûts de maintenance et de vérifier la qualité de la migration des données sur des segments limités.
Le piège classique de ce pattern réside dans la coexistence éternelle, où l’organisation maintient deux systèmes en parallèle, doublant la dette technique et les risques de sécurité sans jamais finaliser la migration. Pour l’éviter, la gestion de projet doit imposer des jalons de bascule irréversibles, assortis de critères objectifs basés sur des tests automatisés, des indicateurs de performance métier et des audits de sécurité alignés sur des référentiels comme NIST ou ISO 27001. Les DSI qui réussissent ce pattern, comme on l’a vu chez certains acteurs industriels allemands accompagnés par Forrester, fixent dès le départ une date de décommissionnement de l’application legacy et conditionnent les budgets de run à l’atteinte de ces jalons.
Le side by side est particulièrement pertinent lorsqu’il s’agit de migration cloud d’un système de front office, par exemple une application de vente en ligne, où l’on peut router progressivement le trafic vers le nouveau système via des mécanismes de feature flags ou de canary releases. Dans ce cas, la stratégie de modernisation doit intégrer des plans de tests de charge, des scénarios de rollback et une surveillance renforcée de la sécurité des accès, en s’appuyant sur des pratiques d’observabilité avancées. Les DSI peuvent utilement compléter cette approche par une réflexion sur la gestion des identités et des accès, en s’appuyant sur des retours d’expérience concrets sur l’optimisation de la gestion des accès pour les responsables informatiques.
Checklist opérationnelle pour un side by side réussi : 1) définir un plan de répartition progressive du trafic (par segment client, canal ou région) et les métriques de comparaison entre ancien et nouveau système ; 2) mettre en place des tests automatisés de bout en bout couvrant les scénarios critiques avant chaque montée en charge ; 3) documenter des critères de bascule définitive (stabilité sur plusieurs cycles de facturation, absence d’incidents majeurs, conformité sécurité) ; 4) prévoir un plan de retour arrière limité dans le temps, avec des responsabilités claires ; 5) inscrire dans la feuille de route une date ferme de décommissionnement et les étapes de réduction des capacités de l’application legacy.
Anti corruption layer : isoler le système legacy sans le sacraliser
L’anti corruption layer est un pattern d’architecture qui interpose une couche de traduction entre un système legacy et les nouveaux services, afin de protéger ces derniers des modèles de données et des choix techniques hérités. Cette couche permet de moderniser application par application sans propager la dette technique, en imposant des contrats d’API clairs, des schémas de données maîtrisés et des règles de sécurité homogènes. Dans une démarche de modernisation du système d’information, l’anti corruption layer devient le garde-fou qui évite de reconstruire un nouveau monolithe autour d’un ancien système mal compris.
Les DSI qui pilotent des transformations digitales complexes, comme ceux de grands distributeurs français ou de banques mutualistes, utilisent ce pattern pour encapsuler des systèmes legacy de core banking, de supply chain ou de facturation, tout en lançant des projets cloud native sur des domaines périphériques. La stratégie de modernisation s’appuie alors sur un refactoring progressif du code, sur des tests automatisés de bout en bout et sur une migration des données orchestrée par domaines, afin de limiter les risques sur les applications critiques. Pour sécuriser ces trajectoires, beaucoup s’appuient sur les recommandations de Gartner et de la FinOps Foundation, en combinant optimisation des coûts de la migration cloud et maîtrise des risques opérationnels.
Le rôle du DSI consiste alors à arbitrer entre ce qui doit rester dans le système legacy encapsulé et ce qui doit être extrait vers des services cloud native, en tenant compte des coûts de maintenance, des contraintes de conformité et des exigences de performance métier. Une trajectoire réaliste de modernisation impose d’accepter que certains logiciels restent sur site, tout en industrialisant la migration cloud des composants à plus forte valeur ajoutée, avec des plans de tests automatisés rigoureux. Pour approfondir ces enjeux de transition sécurisée et efficace, les retours d’expérience détaillés sur la migration vers le cloud et la sécurisation des trajectoires offrent un cadre opérationnel utile aux équipes d’architecture.
Mettre en œuvre une anti corruption layer efficace : 1) identifier les domaines métier à protéger des modèles hérités et définir un langage de données cible ; 2) concevoir la couche d’isolation (mapping, transformations, règles de sécurité) et la couvrir par des tests automatisés unitaires et d’intégration ; 3) mesurer l’impact de performance et ajuster l’architecture (cache, file d’événements, découpage des services) ; 4) planifier la réduction progressive des accès directs au système legacy, jusqu’à les interdire pour les nouveaux développements ; 5) suivre des indicateurs de complexité et de coûts de maintenance de la couche pour éviter qu’elle ne devienne un nouveau point de fragilité.
Chiffrer la dette, prioriser les risques, assumer les renoncements
La modernisation du SI n’a de sens que si la dette technique est objectivée, chiffrée et reliée à des risques métier concrets, plutôt qu’à des discours abstraits sur l’innovation. Les DSI qui réussissent à moderniser des applications legacy sans explosion budgétaire commencent par cartographier les systèmes legacy, les flux de données et les applications critiques, puis par évaluer les coûts de maintenance et les risques de sécurité associés. Cette approche permet de choisir rationnellement entre strangler fig, side by side ou anti corruption layer pour chaque périmètre, en alignant les décisions d’architecture sur les priorités métier et non sur les modes technologiques.
Les études de Wavestone et de Forrester montrent que les organisations qui combinent refactoring ciblé, migration des données progressive et tests automatisés systématiques réduisent significativement les incidents de production liés aux projets de modernisation. Dans ces trajectoires, la gestion de projet ne se limite pas à un Gantt ; elle intègre des indicateurs de continuité de service, de sécurité et de performance métier, suivis au même niveau que les coûts de la migration cloud. Les DSI qui assument des renoncements explicites, par exemple en décidant de ne pas moderniser certaines applications legacy à faible valeur, libèrent des marges de manœuvre pour concentrer les équipes sur les systèmes à fort impact.
Au fond, la modernisation legacy n’est pas un concours de pureté architecturale, mais un exercice de hiérarchisation des risques et de transformation digitale pragmatique, où chaque pattern est un outil au service d’un compromis assumé. Le strangler fig protège les parcours métier à forte exposition, le side by side sécurise les bascules à haut volume, l’anti corruption layer préserve les nouveaux services de la toxicité du passé. Ce n’est pas le TCO sur slide qui mesure le succès, mais le ticket d’incident du lundi matin qui ne s’ouvre plus.
Chiffres clés sur la modernisation des systèmes legacy
- Selon Gartner, plus de 60 % des budgets applicatifs restent consacrés au run et à la maintenance des systèmes legacy, ce qui limite mécaniquement la capacité d’investissement dans les projets de modernisation (Gartner, « IT Key Metrics Data 2023 », publié en décembre 2022, panel de grandes entreprises nord-américaines et européennes).
- Une étude Forrester sur les transformations applicatives a montré qu’une approche progressive de type strangler fig réduit en moyenne de 30 % les incidents majeurs en production par rapport à une migration big bang équivalente (Forrester, « Modernizing Legacy Applications: Incremental vs. Big Bang », 2021, enquête auprès d’environ 200 DSI et responsables applicatifs).
- D’après des analyses publiées par Wavestone, les organisations qui industrialisent les tests automatisés dans leurs programmes de modernisation legacy divisent par deux le temps moyen de détection des régressions critiques (Wavestone, « Modernisation des systèmes legacy : retours d’expérience », livre blanc 2022, synthèse de cas clients multisecteurs).
- Les retours d’expérience de grands groupes européens indiquent qu’une migration cloud sélective, ciblant 20 à 30 % des applications à plus forte valeur, permet de capter l’essentiel des gains de performance sans supporter les risques d’une migration massive (synthèse de cas clients présentés lors de conférences Wavestone et Gartner entre 2020 et 2023, principalement dans la banque, l’assurance et l’industrie).