Modernisation Mainframe : Rewrite, Refactor Ou Replatform

La modernisation mainframe est rarement une décision unique. C’est un choix entre plusieurs stratégies distinctes, chacune avec un profil de coût, de calendrier et de risque très différent, et la bonne réponse dépend de vos objectifs métier plutôt que d’une préférence technologique. Choisir « tout réécrire » quand un replatform suffirait, ou un « lift and shift » quand le vrai problème est un code non maintenable, c’est ainsi que les programmes de modernisation gaspillent des millions.

Ce guide compare les principales stratégies de modernisation, quand chacune a du sens, et comment choisir.

TL;DR

• Les principales stratégies sont rehost, replatform, refactor, rearchitect/rewrite, replace et retire ; la plupart sont généralement regroupées en rehost, replatform et refactor/rewrite
• Le rehosting est le plus rapide et le moins cher mais change le moins de choses ; le rewrite offre le résultat le plus moderne au coût et au risque les plus élevés
• Le bon choix dépend des moteurs métier : réduction des coûts, agilité, risque, disponibilité des compétences et état du code existant
• La plupart des grands programmes au Royaume-Uni mélangent les stratégies sur l’ensemble du parc plutôt que d’appliquer une seule approche à tout

Pourquoi moderniser le mainframe

Les moteurs sont cohérents d’une entreprise britannique à l’autre : le vivier de compétences COBOL et mainframe part à la retraite, les coûts d’exploitation du mainframe sont élevés, les systèmes sont difficiles à modifier rapidement, et leur intégration avec les plateformes modernes de cloud, de données et d’IA est ardue. Ne rien faire comporte son propre risque croissant à mesure que l’expertise disparaît. La question n’est généralement pas de savoir s’il faut moderniser, mais comment.

Les stratégies de modernisation mainframe

Les cadres du secteur listent six ou sept options ; en pratique, elles se regroupent en quelques choix significatifs.

Rehost (« Lift and Shift »)

Déplacer l’application existante, largement inchangée, vers une nouvelle infrastructure, par exemple en émulant l’environnement mainframe sur le cloud ou du matériel standard. Le code COBOL reste globalement tel quel.

• Avantages : Option la plus rapide et la moins coûteuse ; faible risque de livraison ; sortie immédiate des coûts de matériel et de licences mainframe.
• Inconvénients : Ne change presque rien au code. Vous avez toujours du COBOL, toujours le problème de compétences, et gagnez peu d’agilité. C’est un levier de coût, pas une modernisation du logiciel lui-même.
• Idéal pour : Les organisations qui doivent quitter rapidement le matériel mainframe et différer une modernisation plus profonde.

Replatform

Passer à une nouvelle plateforme avec quelques ajustements, par exemple recompiler le COBOL pour qu’il s’exécute sous Linux ou dans le cloud, ou migrer la base de données de DB2 vers un équivalent moderne, sans réécrire la logique métier.

• Avantages : Bénéfices significatifs en matière d’infrastructure et de coûts pour un effort modéré ; conserve une logique métier éprouvée ; risque plus faible qu’un rewrite.
• Inconvénients : L’application reste fondamentalement l’ancienne application ; les gains d’agilité sont limités et le problème de compétences au niveau du code persiste.
• Idéal pour : Les organisations souhaitant des bénéfices cloud et de coûts tout en préservant une logique fonctionnelle et en limitant le risque.

Refactor

Restructurer et améliorer le code existant, et souvent le convertir vers un langage moderne, sans changer son comportement externe. C’est là que s’inscrit la conversion automatisée de COBOL vers un langage moderne, produisant un code maintenable dans un langage disposant d’un vivier de développeurs sain.

• Avantages : Résout le problème de compétences en passant à un langage courant ; améliore la maintenabilité ; préserve le comportement ; peut se faire de façon incrémentale.
• Inconvénients : Plus d’effort qu’un rehost ou un replatform ; nécessite des tests de parité des sorties rigoureux ; la conversion automatisée requiert encore un travail humain sur l’accès aux données et la précision.
• Idéal pour : Les systèmes dont la logique est saine mais dont le langage et la structure constituent le fardeau. C’est le cas idéal pour la plupart des modernisations COBOL.

Rearchitect / Rewrite

Reconstruire le système, en repensant son architecture (par exemple vers des services ou une conception cloud-native) et en réimplémentant la logique métier sur une pile moderne.

• Avantages : Offre le résultat le plus moderne, le plus agile et le plus maintenable ; élimine entièrement la dette technique accumulée.
• Inconvénients : Le coût le plus élevé, le calendrier le plus long et le plus grand risque ; réimplémenter des décennies de règles métier non documentées à partir de zéro est là où les grands programmes échouent.
• Idéal pour : Les systèmes réellement inadaptés, où l’entreprise a besoin de capacités que la conception actuelle ne peut pas prendre en charge.

Replace et Retire

Remplacer le système par un produit commercial sur étagère (COTS) ou un produit SaaS, ou le mettre entièrement hors service s’il n’est plus nécessaire.

• Avantages : Peut être le résultat le plus économique lorsqu’un produit adapté existe ou que la fonction est obsolète.
• Inconvénients : Les COTS correspondent rarement exactement à une logique sur mesure ; la migration et la conduite du changement sont importantes ; non viable pour des systèmes véritablement différenciants.
• Idéal pour : Les fonctions banalisées (par exemple la paie ou le grand livre) où un produit mature existe.

Comparer les stratégies

Comment choisir

Laissez les moteurs métier décider, pas la technologie :

• Le moteur principal est le coût et une sortie rapide du matériel : commencez par un rehost ou un replatform.
• Le moteur principal est la pénurie de compétences et la maintenabilité : refactor, généralement en convertissant le COBOL vers un langage courant.
• Le moteur principal est une nouvelle capacité que l’ancienne conception ne peut pas prendre en charge : rearchitect ou rewrite des parties qui en ont besoin.
• La fonction est banalisée : envisagez un replace.

En pratique, les grands parcs britanniques mélangent les approches : replatform des parties stables, refactor du code difficile à maintenir, rewrite de la poignée de systèmes nécessitant de nouvelles capacités, et retire de ce qui n’est plus utilisé. Si la voie choisie implique de convertir le COBOL vers un langage moderne, l’aperçu de la migration COBOL compare les langages cibles comme C#, Java, Python, Go, C++ et Rust, et le guide des coûts de la migration COBOL présente des budgets réalistes.

Le service Mecanik de migration de mainframe legacy couvre le démantèlement de l’infrastructure aux côtés de la migration du code, et le service de modernisation COBOL couvre le travail de refactor et de conversion au niveau du code.

Points clés à retenir

• La modernisation mainframe est un choix entre rehost, replatform, refactor, rewrite et replace/retire, chacun avec un profil coût-risque distinct.
• Le rehost est le plus rapide et le moins cher mais modernise le moins ; le rewrite est le plus transformateur mais le plus coûteux et le plus risqué.
• Le refactoring (souvent la conversion de COBOL vers un langage moderne) est le cas idéal lorsque la logique est saine mais que le langage et les compétences sont le problème.
• La plupart des grands programmes mélangent les stratégies sur l’ensemble du parc ; laissez les moteurs métier, et non les préférences technologiques, décider.

Foire aux questions (FAQ)

Quelle est la différence entre le rehosting et le refactoring d’une application mainframe ? Le rehosting (« lift and shift ») déplace l’application existante vers une nouvelle infrastructure avec un code largement inchangé, ce qui règle le coût du matériel mais pas le problème de code ou de compétences. Le refactoring restructure et convertit souvent le code vers un langage moderne tout en préservant le comportement, ce qui résout le problème de maintenabilité et de compétences.

Vaut-il mieux réécrire ou migrer le COBOL ? Cela dépend du système. Si la logique métier est saine mais que le langage est le fardeau, convertir (refactoring) le COBOL vers un langage moderne présente généralement moins de risque et de coût qu’un rewrite. Un rewrite complet n’est justifié que lorsque la conception actuelle ne peut pas prendre en charge les capacités dont l’entreprise a besoin.

Quelle stratégie de modernisation mainframe est la moins chère ? Le rehosting est généralement le moins cher et le plus rapide, mais il offre la modernisation la plus faible car l’application reste fondamentalement la même. Le replatforming ajoute un bénéfice modéré pour un coût modéré. Le rewriting est le plus coûteux.

Pouvons-nous moderniser un mainframe de façon incrémentale ? Oui. La modernisation incrémentale (strangler fig ) remplace ou convertit des parties du système une à une, réduisant le risque de bascule brutale. La plupart des grands programmes britanniques mélangent les stratégies et les déploient de façon incrémentale sur l’ensemble du parc.

Quel est le plus grand risque de la modernisation mainframe ? Réimplémenter des décennies de logique métier non documentée, en particulier lors d’un rewrite complet, et des tests de parité des sorties insuffisants. Les stratégies qui préservent une logique éprouvée (replatform, refactor) comportent moins de ce risque qu’un rewrite reconstruit de zéro.