Modernisation du mainframe à l’ère agentique : avec Transform et Kiro, AWS revoit sa méthode

« Reimagine » : les effets de l’IA générative et agentique sur la modernisation du mainframe

L’IA générative et agentique ferait apparaître un quatrième modèle, nommé « reimagine ». « Dans ce cas-là, les métiers réclament beaucoup plus de flexibilité, de nouveaux services et produits pour leurs clients », indique Mohamadou Yacoubou.

À la manière de Watson Code Assistant for Z, AWS Transform permet une analyse du code, de réaliser une évaluation des applications existantes pour identifier les dépendances entre elles et construire un plan de migration.

« À partir de là, nous créons ce que nous appelons des macroservices. Ce n’est pas la cible finale (les microservices), mais nous reconstruisons l’expérience utilisateur », poursuit-il. « Une fois que nous avons stabilisé cet ensemble, nous continuons de les découper pour obtenir des microservices hébergés sur AWS ».

Dans le détail, l’analyse du code est déterministe. « Nous ne nous appuyons pas sur un LLM, nous souhaitons quelque chose de sûr, exact et reproductible », précise Yann Kindelberger, Principal Solution Architect Mainframe Modernisation chez AWS. « Les activités qui se reposent sur cette analyse de code peuvent être propulsées par un LLM ».

Outre le code, l’analyse porte sur les modalités d’accès aux données (en écriture, en lecture, les deux, en mise à jour) au sein des tables DB2 Z/OS et les VSAM, par exemple.

Cette analyse de données tient en deux grandes étapes. D’abord, le data lineage, permet d’établir la cartographie des accès aux données par les programmes. Ensuite, la constitution d’un dictionnaire de données doit créer une vision métier de l’ensemble des champs qui accèdent aux données. « Nous partons des copybooks COBOL qui définissent les structures de données », détaille l’expert.

« Une autre étape consiste en l’analyse d’activités du mainframe. Elle s’appuie sur les enregistrements SMF pour savoir quels sont les programmes qui consomment le plus de MIPS [de ressources CPU, N.D.L.R], et plus important encore ceux qui ne sont jamais exécutés ».

Par ailleurs, Transform peut servir à rétrodocumenter les programmes au sein du mainframe, mais aussi à extraire les logiques métiers au sein du code Cobol ou PL/1. Un LLM peut être sollicité à la marge.

« Etrangler » plus rapidement le mainframe

Même si les clients d’AWS seraient de plus en plus intéressés par la démarche « reimagine », « Rares sont les clients qui choisissent l'approche big bang pour transformer 50 millions, 100 millions de lignes de code », souligne Yann Kindelberger.

« Nous optons souvent pour une logique d’étranglement du mainframe : il s’agit de décomposer le monolithe applicatif en différents domaines, puis de migrer par domaine ».

« Pour chacun des domaines métiers, AWS Transform identifie les programmes, les fonctionnalités clés, les statements COBOL associés et la vue du flux applicatif du programme, ainsi que les règles métiers extraites ». Ces extractions sont formatées en XML ou en JSON.

Évidemment, AWS met l’accent sur l’approche reimagine. Celle-ci se mène en deux grandes phases : « le reverse engineering et le forward engineering ».

Le reverse engineering correspond à la phase d’analyse du code, des schémas de données et des logiques métiers évoquées plus haut. Concernant le forward engineering, AWS mise sur son framework agentique Kiro. Ce n’est toutefois pas obligatoire.

« Kiro fournit d’excellents résultats lors de la phase de forward engineering, mais si vous utilisez Claude Code ou GitHub Copilot, cela fonctionne également », assure Yann Kindelberger.

Mais qu’est-ce que le forward engineering ? Certains nomment cette approche le « Spec Driven Development ». C’est le fait de générer des spécifications à partir des logiques métiers extraites par Transform pour ensuite en générer le code applicatif.    

 « Dans les prompts, nous spécifions à Kiro de respecter l’approche Domain Driven Design qui lui permet, à partir de la logique métier d’identifier les “bounded contexts” pour ensuite spécifier la documentation des microservices cibles », précise le spécialiste de la modernisation mainframe.

Avant de générer le code, une vérification humaine s’impose, juge le fournisseur.

« Nous avons toujours un humain dans la boucle qui permet de valider ou non les recommandations de spécifications des agents IA. Ce n’est pas du pilotage automatique », martèle Mohamadou Yacoubou.

Les spécifications peuvent être modifiées manuellement ou à l’aide de Kiro, avant de générer des tâches, puis, enfin, le code source de l’application.

AWS dit ne pas imposer de langage de programmation cible. Les applications peuvent être « réimaginées » (générées et compilées) en Java/JavaScript, en .NET, en Python, etc., en s’appuyant sur les frameworks de choix de l’entreprise.

Intégration, « dual run », vérifications manuelles : les enjeux majeurs demeurent

« [Kiro] peut aussi générer l’infrastructure as code et les scripts d’intégration de données, avant de les déployer sur AWS », explique Yann Kindelberger.

Et c’est sans doute là, lors du déploiement, que la véritable complexité se joue. L’approche d’AWS implique une cohabitation des applications hébergées sur le mainframe et d’autres qui ont déjà été migrées puis transformées sur AWS. D’où la nécessaire mise en place d’une architecture d’intégration de données et des applications. Cela est vrai pour les quatre modèles de migration évoqués plus haut. « La génération de code n’est pas la plus compliquée. L’intégration est beaucoup plus importante », évoque Yann Kindelberger.

Lors de l’événement reInvent 2025, certains clients ont témoigné de l’adoption de Transform et de Kiro. C’est le cas de Dankse Bank, une banque danoise (40 à 50 000 MIPS) qui a migré une application en « dual run » (dans le cloud et sur le mainframe). Une première phase de test a été menée pendant trois semaines, avant de prévoir le futur décommissionnement du programme existant. La banque brésilienne Itaú Unibanco (300 000 MIPS) avait lancé la migration d’une dizaine d’applications avant la disponibilité des outils d’AWS. Elle aurait pris le train en marche.

Pour autant, le gain de temps lors de ce procédé, Yann Kindelberger, l’observe principalement au moment de la rétro-ingénierie. « Nous gagnons des journées entières avec le reverse engineering. Cela permet de diviser par 4 ou 5 le temps nécessaire à l’élaboration du plan de migration », affirme-t-il auprès du MagIT. « Le forward engineering réclame davantage d’effort, du fait des validations humaines ».

Il ne faut donc pas s’espérer à transformer un programme en huit semaines, comme le promettait Anthropic dans un PDF qui a enflammé la bourse. En revanche, là où un projet de conversion des applications mainframe vers le cloud dure en moyenne cinq ans, l’expert s’attend – en prenant en compte les évolutions des outils agentiques – que ce laps de temps soit divisé par deux. Une estimation à vérifier ultérieurement auprès des entreprises intéressées.

D’autant que certaines sociétés préfèrent maintenir des services ou des algorithmes sur leur mainframe. S’il reste difficile à gérer, si les compétences sont de plus en plus rares, le mainframe IBM est doté de capacités de traitement idéales pour certaines charges de travail. N’en déplaise à AWS et consorts.