Toute organisation utilisant des systèmes hérités est confrontée à la même tension fondamentale : ces systèmes sont trop précieux pour être abandonnés, trop coûteux à maintenir dans leur état actuel et trop risqués à remplacer d’un seul coup. Les mainframes COBOL traitent 95 % des transactions des distributeurs automatiques de billets dans le monde. Aux États-Unis, 80 % des budgets informatiques fédéraux sont consacrés à la maintenance de systèmes qui auraient dû être modernisés depuis longtemps. Les systèmes hérités ne sont pas en échec, ils sont performants, et c’est précisément ce qui les rend si difficiles à faire évoluer.
Le coût de l'inaction s'accumule. La dette technique augmente chaque année où la modernisation est reportée. Les failles de sécurité s'accumulent dans les bases de code qui ne sont plus mises à jour. L'intégration avec les systèmes modernes se complexifie à mesure que l'écart entre l'architecture existante et les modèles natifs du cloud se creuse. De plus, le nombre de développeurs maîtrisant les langages existants diminue avec le départ à la retraite de ceux qui les ont conçus. Les organisations qui réussissent leur modernisation ne sont pas celles qui attendent que la pression devienne insoutenable. Ce sont celles qui planifient méthodiquement, choisissent l'approche la plus adaptée à chaque système et procèdent par étapes plutôt que de miser tout leur programme sur une seule transition majeure.
Connaître l'intégralité de votre portefeuille Legacy
SMART TS XL identifie les éléments pouvant être mis hors service avant le verrouillage de votre périmètre de modernisation.
En savoir plusQu’est-ce que la modernisation des systèmes existants ?
La modernisation des systèmes existants consiste à transformer des systèmes logiciels obsolètes, souvent monolithiques, complexes à maintenir et difficiles à intégrer, en architectures modernes, agiles et évolutives. Il ne s'agit pas nécessairement d'un remplacement. La modernisation englobe un large éventail d'approches, allant de la migration du code existant vers une infrastructure cloud avec des modifications minimales, en passant par la refactorisation progressive, jusqu'à la refonte complète ou le remplacement par des solutions modernes.
La différence avec la simple maintenance : la maintenance assure le fonctionnement continu d’un système. La modernisation, quant à elle, modifie ses capacités fondamentales, son architecture ou son environnement d’exploitation afin d’en prolonger la durée de vie, de réduire les coûts d’exploitation, de permettre l’intégration avec des systèmes modernes ou de préparer l’organisation au développement futur de ses capacités, notamment pour les charges de travail liées à l’IA.
Pourquoi les systèmes existants ne peuvent pas attendre indéfiniment
Plusieurs facteurs convergents font que le coût du report sera plus élevé en 2026 qu'il ne l'était il y a trois ans :
Préparation à l'IA. Les charges de travail d'IA générative révèlent, quelques semaines seulement après le déploiement pilote, toutes les faiblesses d'un parc de données d'entreprise : sources fragmentées, sémantique incohérente, accès non contrôlé. Les organisations ne peuvent pas exécuter de flux de travail d'IA pertinents sur des systèmes hérités cloisonnés et non documentés. La modernisation est indispensable pour être performant à l'ère de l'IA.
Pénurie de talents. Trouver des développeurs pour COBOL, PL/I et Java (langage vieux de quinze ans) devient un véritable défi. L'âge moyen des développeurs COBOL se situe désormais autour de cinquante ans. Chaque année de report de la modernisation réduit la fenêtre d'opportunité pour la transmission des connaissances avant que le savoir-faire institutionnel ne disparaisse avec ceux qui le détiennent.
Exposition à la sécurité. Les systèmes anciens qui ne reçoivent plus les correctifs de sécurité des fournisseurs accumulent des CVE non corrigées. Plus un système fonctionne longtemps dans cet état, plus sa surface d'exposition aux vulnérabilités connues est importante.
Complexité de l'intégration. Les architectures modernes basées sur les API, les microservices et les plateformes cloud-native supposent des modèles de connectivité que les architectures monolithiques traditionnelles ne prennent pas en charge nativement. Chaque nouvelle solution de contournement pour l'intégration alourdit la dette technique et complique la modernisation finale.
Les 7 R : Le cadre fondamental pour les décisions de modernisation
Le cadre des 7 R, dérivé des 5 R originaux de Gartner et enrichi par les pratiques du secteur, offre aux organisations une méthode structurée pour décider de la stratégie à adopter pour chaque application de leur parc informatique. Le principe fondamental est qu'aucune approche unique ne convient à tous les systèmes. Un programme de modernisation de portefeuille applique des stratégies différentes à chaque système en fonction de sa complexité, de son importance pour l'activité et de sa valeur stratégique.
| de Marketing | Ce que cela veut dire | Quand l'utiliser | Chronologie typique | Niveau de risque |
|---|---|---|---|---|
| Prendre ma retraite | Mise hors service, le système n'est plus nécessaire | Systèmes redondants, inutilisés ou entièrement remplacés | Immédiat | Low |
| Conserver | Conserver tel quel avec des modifications minimales | Le système fonctionne, le coût de la modernisation dépasse les avantages | En cours | Low |
| Réhéberger | Migration vers le cloud sans modification du code | Charges de travail non critiques, gains rapides, réduction des coûts d'infrastructure | 1 – 3 mois | Low |
| Replateforme | Déplacez-vous en effectuant des changements de plateforme ciblés (par exemple, base de données gérée). | Couplage modéré, optimisation des performances spécifiques ou des coûts nécessaire | 2 – 6 mois | Moyenne |
| Refactoriser | Restructurer le code sans modifier le comportement externe | Réduction de la dette technique, amélioration de la maintenabilité, couverture des tests | 3 – 12 mois | Moyenne |
| Réarchitecte | Refonte pour une architecture native du cloud, des microservices ou une nouvelle architecture | Exigences importantes en matière d'évolutivité, changement stratégique de la plateforme | 12 – 24 mois | Haute |
| remplacer | Abandonnez le système personnalisé, adoptez le SaaS ou une alternative moderne. | Les fonctionnalités courantes sont mieux assurées par les produits existants. | 6 – 18 mois | Moyen-élevé |
La décision la plus importante dans tout programme de modernisation est d'appliquer rigoureusement ce cadre plutôt que d'opter pour une stratégie unique et généralisée. Les organisations qui migrent systématiquement leurs infrastructures cloud se retrouvent avec des factures supérieures à leurs coûts de centre de données initiaux, sans la flexibilité qui les justifie. Celles qui refondent l'ensemble de leurs systèmes se retrouvent avec des programmes pluriannuels dont la valeur ajoutée est trop lente pour maintenir l'adhésion des parties prenantes.
Les huit approches de modernisation en détail
1. Réhébergement (Lift-and-Shift)
Le rehosting permet de transférer une application vers le cloud ou une infrastructure moderne sans modifier son code source. L'application s'exécute sur une plateforme différente, mais son fonctionnement reste identique. C'est la solution la plus rapide pour migrer vers le cloud, la moins risquée et la moins invasive.
Idéal pour : les applications non critiques dont l’objectif principal est la réduction des coûts d’infrastructure, la consolidation des centres de données ou la préparation à une modernisation future. Le rehosting est souvent utilisé dans un premier temps : migrer le système vers une infrastructure cloud, puis procéder à une refactorisation progressive.
Ce que cette solution ne résout pas : la dette technique, les problèmes de maintenabilité, la complexité d’intégration ni les limitations architecturales. Le système s’exécute dans le cloud, mais son architecture reste inchangée. Un monolithe coûteux à maintenir sur site le reste même après migration.
2. Replatforming
La migration de plateforme consiste à adapter la plateforme ou l'environnement d'exécution pour tirer parti des services cloud, sans restructurer l'architecture de l'application. La migration d'une base de données autogérée vers un service de base de données cloud, ou d'un serveur d'applications autogéré vers une plateforme de conteneurs gérée, sont des exemples typiques de migration de plateforme.
Idéal pour : Les applications dont certains composants ont des équivalents natifs du cloud clairement définis, ce qui réduit les frais d'exploitation, et pour lesquelles le coût et le risque d'une refonte complète ne sont pas justifiés par les avantages commerciaux.
3. Refactorisation
La refactorisation restructure le code existant afin d'en améliorer la qualité interne sans en modifier le comportement externe. Elle permet de réduire la dette technique, d'améliorer la testabilité, de diminuer la complexité et de rendre le code plus facile à comprendre et à étendre. Il ne s'agit pas d'une migration de plateforme : le système continue de fonctionner dans le même environnement.
La refactorisation est l'approche la plus appropriée lorsque : la fonctionnalité principale du système est fiable et toujours nécessaire, mais que sa structure interne rend toute modification lente et risquée. Un programme COBOL, riche de plusieurs décennies de logique conditionnelle accumulée, qui remplit correctement une fonction métier critique mais exige plusieurs jours d'analyse approfondie avant toute modification, est un candidat idéal pour la refactorisation.
4. Réarchitecture
La réarchitecture consiste à repenser la structure fondamentale de l'application, en décomposant un monolithe en microservices, en passant d'une communication synchrone à une communication événementielle et en implémentant des modèles CQRS ou d'event sourcing. C'est la stratégie qui demande le plus d'efforts et offre le meilleur retour sur investissement lorsqu'elle est bien menée, mais la plus risquée lorsqu'elle est mal menée.
Le principal écueil à surveiller est l’« anti-modèle monolithique distribué » : les équipes implémentent de nouveaux services sans découpler la couche de données, ce qui crée la complexité opérationnelle des microservices combinée au couplage fort d’un monolithe. Ce modèle fonctionne lorsque les limites des données sont clairement définies avant l’extraction des services.
Idéal pour : Les systèmes où les exigences d'évolutivité, de résilience ou de flexibilité architecturale ne peuvent être satisfaites dans la structure existante, et où l'organisation possède la maturité technique nécessaire pour exploiter des systèmes distribués.
5. Le motif du figuier étrangleur
Le modèle Strangler Fig est une approche de modernisation dans laquelle les fonctionnalités existantes d'un système hérité sont progressivement remplacées par de nouvelles applications et de nouveaux services jusqu'à ce que le nouveau système remplace finalement toutes les parties anciennes ou clés du système hérité.
Au lieu de remplacer un système existant d'un seul coup, les nouvelles fonctionnalités sont développées en parallèle, remplaçant progressivement l'ancien système par des composants modernes. Une couche proxy ou façade achemine les requêtes, les envoyant initialement toutes vers l'ancien système, puis progressivement vers les nouveaux composants une fois validés. L'ancien système est ainsi progressivement mis hors service jusqu'à sa désactivation en toute sécurité.
La voie la plus risquée : la migration radicale. La construction d’un système de remplacement complet de manière isolée, suivie d’une migration globale en une seule fois, présente un taux d’échec élevé avéré à l’échelle de l’entreprise.
Pourquoi la méthode Strangler Fig est désormais recommandée par défaut pour les systèmes critiques : elle élimine le principal facteur d’échec des modernisations de systèmes existants, la migration brutale. Chaque nouveau composant est validé en production avant l’intégration du suivant. La restauration est toujours possible car le système existant reste opérationnel. La continuité d’activité est ainsi assurée.
Application concrète : Un établissement financier qui remplace son système bancaire central extrait la fonction de consultation de compte comme premier nouveau service. Ce nouveau service gère les requêtes, tandis que l’ancien système prend en charge le reste. Une fois le service stabilisé, la fonction suivante, l’initiation de transactions, est extraite. Ce processus se poursuit jusqu’à la mise hors service complète de l’ancien système central, avec une validation continue à chaque étape.
6. Encapsulation d'API
L'encapsulation d'API crée une couche API moderne autour d'un système existant sans modifier son code interne. Les utilisateurs externes interagissent avec cette API moderne ; celle-ci traduit les requêtes vers l'interface native du système existant et transforme les réponses dans des formats modernes. Le système existant devient ainsi un détail d'implémentation interne masqué par une interface épurée.
Idéal pour : les systèmes qui doivent rester en place indéfiniment (en raison d’exigences réglementaires, de coûts ou de complexité) mais qui doivent s’intégrer aux modèles modernes. L’encapsulation d’API permet à de nombreuses organisations de rendre les programmes COBOL accessibles aux applications web et mobiles modernes sans modifier le code COBOL.
Limites : Les limitations, les performances, l’évolutivité et la maintenabilité du système sous-jacent ne sont pas prises en compte. L’encapsulation d’API améliore l’intégration sans pour autant améliorer le système qu’elle encapsule.
7. Reconstruire à partir de zéro
La refonte consiste à remplacer l'implémentation existante par une nouvelle, conçue selon une architecture, un langage et une plateforme modernes. Elle est appropriée lorsque le système existant est véritablement irréparable et que les besoins métiers sont suffisamment bien définis pour permettre de spécifier une solution de remplacement avec assurance.
Le risque : chaque organisation ayant tenté une refonte complète d’un système critique a constaté que le système existant contenait une logique métier non documentée que le nouveau système ne reproduisait pas. La migration informatique de la banque britannique TSB en 2018 a privé d’accès à leurs comptes 1.9 million de clients pendant des semaines. Le projet de dossier virtuel du FBI a été abandonné après 170 millions de dollars d’investissement. Le remplacement du système de paie de Queensland Health a entraîné des erreurs de paiement (sous-paiement ou surpaiement) pendant des mois pour 35 000 employés d’hôpitaux. Dans chaque cas, la complexité du système existant, ses règles métier intégrées, ses cas particuliers et son comportement opérationnel dans des conditions jamais explicitement spécifiées ont dépassé les connaissances de l’équipe de remplacement avant le début du projet.
8. Modernisation assistée par l'IA
La modernisation assistée par l'IA utilise de grands modèles de langage et des outils d'IA spécialisés pour accélérer les phases les plus laborieuses de la modernisation des systèmes existants : compréhension du code, génération de documentation, traduction du code et génération de tests.
Les outils de traduction COBOL vers Java utilisent des modèles de langages optimisés pour les deux langages afin de produire des traductions initiales des programmes COBOL, lesquelles sont ensuite examinées et améliorées par des ingénieurs. La traduction élimine la majeure partie du travail de conversion mécanique, mais ne dispense pas de la compréhension humaine du fonctionnement attendu du code traduit.
La génération automatisée de documentation analyse le code existant afin de produire une documentation structurée décrivant le fonctionnement de chaque programme, les règles métier qu'il applique, les données qu'il lit et écrit, ainsi que les conditions de ses branchements. Cette documentation est indispensable aux ingénieurs pour valider le code traduit et permet à l'organisation de préserver le savoir-faire lorsque les experts COBOL prennent leur retraite.
La génération de tests utilise l'IA pour produire des tests unitaires pour les programmes existants, en se basant sur l'analyse de leur comportement d'entrée/sortie, créant ainsi la couverture de test qui n'a jamais été écrite lors du développement initial et qui est nécessaire avant que toute refactorisation puisse être effectuée en toute sécurité.
La principale limite de la modernisation assistée par l'IA : les outils d'IA accélèrent la conversion du code, mais ne dispensent pas de comprendre la logique métier sous-jacente. Un programme correctement traduit reste un échec si, malgré une traduction correcte, les règles métier ont été mal interprétées. Les outils d'IA réduisent le coût du travail mécanique, mais pas celui de la compréhension.
Choisir la bonne approche : un cadre de décision
La bonne approche de modernisation pour tout système dépend de quatre facteurs évalués conjointement : la criticité pour l’entreprise, la complexité technique, la valeur stratégique, ainsi que le budget et le calendrier disponibles.
| Profil du système | Approche recommandée |
|---|---|
| Faible criticité commerciale, faible complexité | Retraite ou réhébergement |
| Criticité élevée pour l'entreprise, faible complexité, facteur de coût d'infrastructure | Réhéberger ou changer de plateforme |
| Criticité élevée, complexité modérée, dette technique comme principal problème | Refactoriser progressivement |
| Criticité élevée, complexité élevée, mission critique, exigence de zéro interruption de service | Motif Figue étrangleuse |
| Système étroitement couplé à une plateforme obsolète | Refonte de la plateforme ou réarchitecture |
| Fonctionnalités standard disponibles en mode SaaS | remplacer |
| Au-delà de la réparation économique, des exigences bien comprises | Reconstruire (avec une extrême prudence) |
| Portefeuille important de langages COBOL ou de langages hérités | Traduction assistée par IA + validation humaine |
L’erreur la plus fréquente : appliquer la même approche à tous les systèmes du portefeuille, car elle est plus simple à expliquer aux parties prenantes. Un programme de modernisation qui remplace systématiquement tous les systèmes, sans tenir compte de leurs caractéristiques, produira des résultats allant d’un coût approprié (pour certains systèmes) à un coût inutile (pour les systèmes qui auraient dû être mis hors service), voire à une simplification excessive dangereuse (pour les systèmes qui nécessitaient une refonte architecturale).
Défis liés à la modernisation des systèmes existants : quels sont les obstacles à la réussite des programmes ?
Comprendre pourquoi les programmes de modernisation échouent est aussi important que de comprendre les approches disponibles. Les échecs sont récurrents :
Logique métier non documentée. Les systèmes existants contiennent des règles métier qui n'existent nulle part ailleurs que dans le comportement du code. Un programme COBOL modifié par douze développeurs sur une période de trente ans intègre des décisions jamais documentées et qu'aucun membre actuel de l'équipe ne comprend pleinement. Toute approche de modernisation qui n'extrait et ne documente pas cette logique avant de modifier le système risque de produire un nouveau système dont le comportement diffère de l'ancien, et ce, de manières qui ne sont découvertes qu'en cas de conséquences métier.
Tentatives de migration radicale. Les organisations qui échouent le plus lamentablement lors de leur modernisation sont celles qui tentent de remplacer l'intégralité d'un système d'un seul coup, avec une migration à une date précise. Tous les échecs majeurs de modernisation bien documentés – TSB Bank, FBI VCF, Queensland Health – présentent ce même schéma. La modernisation progressive, avec une validation continue à chaque étape, est l'approche qui porte ses fruits.
Dérive des objectifs et découvertes en cours d'exécution. L'équipe de modernisation découvre une complexité invisible lors de la planification. Un système qui semblait être une application délimitée partage en réalité des données avec vingt autres systèmes via des interfaces de fichiers non documentées. Une fonction apparemment simple implémente une règle métier qui a nécessité trois mois de négociations réglementaires et qui n'est documentée nulle part. La solution ? Une analyse structurelle en amont de la planification, et non une planification sans analyse structurelle.
Risque de concentration des connaissances. Les personnes qui maîtrisent le mieux le système existant sont souvent celles qui approchent le plus de la retraite. Lorsqu'elles partent avant que leurs connaissances ne soient transférées et documentées, l'équipe de modernisation travaille avec une compréhension incomplète du fonctionnement du système.
Mesurer les mauvais indicateurs. Les équipes qui évaluent le succès de la modernisation en fonction du pourcentage de migration de code ou du respect des délais, plutôt qu'en fonction des résultats commerciaux, de la réduction des coûts, de la fiabilité des services ou du délai de mise en service des fonctionnalités, privilégient l'activité aux résultats.
L’évaluation qui doit précéder toute décision d’approche
Avant de choisir une approche de modernisation, il est primordial pour toute organisation de bien comprendre son système existant. Une évaluation se limitant à l'analyse de la documentation et aux entretiens avec les développeurs est insuffisante pour deux raisons : la documentation est incomplète et obsolète, et les connaissances des développeurs sont dispersées, hétérogènes et concentrées entre les mains de personnes souvent indisponibles ou proches de la retraite.
Une évaluation structurelle, qui consiste à analyser le code source de chaque application concernée et à construire un modèle de dépendances à partir de ce que fait réellement le code, fournit la base de preuves pour chaque décision ultérieure :
Inventaire des programmes. Nombre de programmes existants, y compris ceux qui ne sont pas documentés. Dans les environnements système anciens de grande envergure, le nombre réel dépasse généralement de 20 à 30 % le nombre documenté.
Cartographie des dépendances. Quels programmes appellent quels autres, lesquels partagent des données via des fichiers ou des bases de données, quelles tâches JCL invoquent quels programmes et dans quel ordre. La structure des dépendances détermine l'ordre de migration : les composants à forte dépendance, dont dépendent de nombreux autres, migrent en dernier.
Identification du code mort. Les programmes qui ne sont jamais appelés par aucun chemin d'exécution en production peuvent être totalement exclus du périmètre de modernisation. Dans les portefeuilles de systèmes existants classiques, le code mort représente 10 à 25 % du total, une réduction significative du périmètre réalisable dès la phase d'évaluation.
Classification de la complexité. Quels programmes présentent la complexité cyclomatique la plus élevée, le plus grand nombre de dépendances au copybook, le plus grand nombre d'appelants et le plus grand nombre d'interactions avec la base de données ? Ce sont les programmes qui nécessiteront le plus d'efforts et comporteront le plus de risques ; il convient donc de les aborder en dernier, une fois que l'équipe aura acquis de l'expérience sur des composants moins complexes.
Extraction de la logique métier : décisions mises en œuvre par chaque programme, conditions de branchement, calculs effectués. Cette documentation constitue le cahier des charges par rapport auquel le système modernisé doit être validé.
Comment SMART TS XL Soutient la modernisation des systèmes existants
L'évaluation structurelle décrite ci-dessus est précisément ce que SMART TS XL Il automatise le processus. En analysant simultanément chaque programme COBOL, flux de travaux JCL, copybook, module PL/I, programme RPG, schéma SQL et composant associé, il construit le modèle de dépendance complet qui permet une planification de la modernisation fondée sur des preuves plutôt que sur des hypothèses.
L' analyse de modernisation des systèmes existants produit un inventaire complet des programmes, y compris ceux non documentés, avec une évaluation préliminaire de la complexité de chaque composant. La cartographie des dépendances applicatives construit le graphe de dépendances interlangages qui détermine la séquence de migration : quels composants peuvent être modernisés en priorité car ils ne dépendent d'aucun autre composant, et lesquels doivent attendre que leurs dépendances soient prêtes.
La capacité d'analyse d'impact permet d'évaluer les risques liés à chaque modification proposée avant son exécution : lorsque l'équipe propose de moderniser un copybook COBOL utilisé par 300 programmes, l'analyse d'impact recense chacun de ces 300 programmes, définit la portée de l'effort de validation et met en évidence les dépendances présentant le risque le plus élevé avant que la modification ne soit effectuée.
L' analyse statique du code permet d'identifier le code mort, les programmes et les paragraphes sans aucune référence entrante depuis un chemin d'exécution en production, ce qui permet de les exclure du périmètre de modernisation avant toute conversion. Pour les organisations migrant vers le cloud, ne pas migrer le code mort représente l'une des sources de réduction des coûts les plus directes et réalisables lors de la phase d'évaluation.
La fonction de recherche d'entreprise permet d'interroger le modèle structurel tout au long d'un programme de modernisation pluriannuel : trouvez en quelques secondes chaque programme qui lit un ensemble de données spécifique, chaque copybook qui définit un champ spécifique, chaque tâche JCL qui invoque un programme spécifique, sur des millions de lignes de code dans n'importe quelle combinaison de langages.
SMART TS XL's visualisation du code produit les diagrammes de dépendance et les organigrammes de programme qui rendent la structure du système non documentée lisible pour toute l'équipe de modernisation, y compris les ingénieurs qui n'ont jamais vu de COBOL et qui doivent comprendre ce que font réellement les programmes qu'ils remplacent.
Modernisation progressive : le principe à la base de tout programme réussi
Le constat le plus constant, tant pour les programmes de modernisation réussis que pour ceux qui échouent, est le rôle de l'approche progressive. Meilleure pratique : la modernisation progressive, utilisant le modèle « étrangleur » ou des feuilles de route modulaires, réduit les risques en migrant les charges de travail domaine par domaine ou capacité.
L'approche progressive n'est pas de la timidité. C'est reconnaître que la compréhension d'un système complexe existant s'affine tout au long du processus de modernisation, et qu'un programme structuré pour intégrer cette compréhension croissante à chaque étape permettra de prendre de meilleures décisions qu'un programme qui concentre toutes les décisions dans une phase de planification qui précède nécessairement une compréhension complète.
Les programmes de modernisation qui atteignent le retour sur investissement escompté sont ceux qui définissent le succès par étapes, chaque étape fournissant des composants validés et prêts pour la production, plutôt qu'au niveau du programme global, où le succès n'est défini qu'à la mise en service finale. Chaque étape renforce la confiance au sein de l'organisation, met en lumière les complexités d'intégration avant qu'elles ne deviennent des obstacles et démontre que l'approche choisie est efficace dans le contexte spécifique des systèmes et des contraintes de cette organisation.
