Toute migration mainframe commence par quelqu’un qui cherche des outils de migration mainframe, et la démonstration fournisseur qui suit paraît remarquablement convaincante. Quelques milliers de lignes de COBOL entrent, du Java lisible sort, la suite de tests passe, et la présentation promet soixante-dix ou quatre-vingts pour cent d’automatisation. La démonstration est en général honnête. Elle tourne aussi, en général, sur du code qui ne se comporte en rien comme le vôtre.

Ce guide décrit les catégories d’outillage qui existent réellement, ce que chacune fait vraiment bien, et les endroits précis où chacune tend à échouer sur des charges réelles. Il est écrit pour les personnes qui doivent signer le dossier d’investissement, pas pour le champion du fournisseur à l’intérieur de l’organisation.

La position honnête : les outils de migration mainframe abattent beaucoup de travail utile, en particulier en analyse, en déplacement de données et en traduction mécanique. Ce qu’ils ne savent pas faire, c’est comprendre vos règles métier. La conversion automatisée produit de façon fiable du code qui s’exécute ; elle ne produit pas du code que votre équipe aura envie de maintenir, et c’est en comblant cet écart que part l’essentiel du budget.

Les quatre catégories d’outils de migration mainframe

Le marché paraît encombré jusqu’à ce qu’on le trie selon ce que les produits font réellement. Presque tout tombe dans l’un de quatre groupes, et un vrai programme utilise des outils d’au moins trois d’entre eux.

Les outils de découverte et d’analyse lisent votre patrimoine de sources et vous disent ce que vous avez. Ils analysent le COBOL, le JCL, les copybooks et les définitions de base de données, puis construisent des graphes d’appel, des cartes de lignage de données et des arbres de dépendances. C’est la catégorie la moins spectaculaire et la plus régulièrement utile, parce que personne dans votre organisation n’a une vue complète d’un système qui s’accumule depuis quarante ans.

Les plateformes de réhébergement et d’émulation font tourner des charges mainframe compilées sur du matériel standard ou des instances cloud. Votre COBOL reste du COBOL, votre JCL reste du JCL, et une couche de compatibilité fournit les services d’exécution que le mainframe assurait auparavant.

Les outils de traduction automatisée convertissent le code source du COBOL vers Java, C# ou une autre cible moderne. C’est la catégorie qui enthousiasme le plus les acheteurs et celle qui déçoit le plus souvent, pour les raisons exposées plus bas.

Les outils de migration de données déplacent les données elles-mêmes : fichiers VSAM, jeux de données séquentiels et tables DB2 vers du stockage relationnel ou cloud natif. Ils gèrent la conversion de jeux de caractères, les champs décimaux condensés et les mises en page d’enregistrements que les produits ETL généralistes ne savent tout simplement pas analyser.

Les grands fournisseurs cloud empaquettent chacun plusieurs de ces briques, et les éditeurs spécialisés se sont fortement consolidés par acquisitions ces dernières années. Avant de signer un contrat de support pluriannuel, vérifiez à qui appartient aujourd’hui le produit et quel engagement porte sa feuille de route, car la propriété change plus souvent que la technologie sur ce marché.

Ce que les outils d’analyse réussissent vraiment

Si vous n’achetez qu’une catégorie, achetez celle-là. L’outillage de découverte répond à des questions qui demanderaient sinon plusieurs mois de travail manuel à une équipe de prestataires.

Un bon produit d’analyse vous dira quels programmes sont réellement appelés en production et lesquels sont morts depuis dix ans, comment une donnée circule d’un champ d’écran jusqu’à une table DB2 en traversant une demi-douzaine de programmes, quels copybooks sont partagés entre sous-systèmes, et où se trouve le code véritablement dangereux. Ce dernier résultat est celui qui change les plans. Tout patrimoine mainframe contient une poignée de programmes dont tout dépend, et ce sont rarement ceux que le métier imagine.

La limite est l’interprétation. Un graphe de dépendances de quarante mille nœuds, c’est de la donnée, pas de la compréhension. Il faut toujours que quelqu’un regarde la sortie, la regroupe en capacités métier et décide de ce qui bouge en premier. Les outils qui promettent de déduire automatiquement les règles métier produisent quelque chose de plus proche d’une paraphrase du code que d’une description de l’intention, et les deux divergent précisément là où le code contient un défaut auquel l’activité s’est discrètement adaptée.

Menez l’analyse avant de vous engager sur une approche. Notre guide de la stratégie de modernisation mainframe explique comment ces constats devraient orienter le choix entre rewrite, refactor et replatform.

Les plateformes de réhébergement : rapides, réelles, et pas une modernisation

Le réhébergement est l’option la plus prévisible du marché, et il est chroniquement sous-vendu pour cette raison.

La proposition est simple. Votre COBOL est recompilé ou interprété sur une plateforme qui émule les services d’exécution du mainframe, si bien que le traitement transactionnel, l’ordonnancement des batchs, la gestion des fichiers et le contrôle des travaux continuent de se comporter comme avant. Comme les sources changent à peine, la charge de test est bien plus faible que sur n’importe quelle autre voie, et les projets s’achèvent en mois plutôt qu’en années.

L’économie est réelle et elle vient du modèle matériel et de licence plutôt que du logiciel. Les organisations rapportent fréquemment des réductions substantielles de coûts d’exploitation annuels après avoir quitté le mainframe physique, ce qui suffit souvent à financer la phase suivante.

Ce que le réhébergement ne fait pas, c’est traiter la raison pour laquelle la plupart des conseils d’administration approuvent ces programmes. Après un réhébergement réussi, vous avez toujours une base de code COBOL, vous avez toujours besoin de développeurs COBOL, et votre capacité à les recruter n’a pas progressé. Rien dans l’application n’est devenu plus facile à modifier. Le réhébergement vous achète du temps et de la trésorerie, ce qui a une vraie valeur, mais il devrait être décrit honnêtement comme un changement de plateforme et non comme une modernisation.

Il introduit aussi une nouvelle dépendance. Vous avez échangé l’environnement d’exécution d’IBM contre la couche de compatibilité d’un éditeur, et votre production repose désormais sur le maintien de ce support. Vu le rythme de consolidation de ce marché, c’est un risque à inscrire dans le dossier d’investissement.

La traduction automatisée : là où vivent les vrais ennuis

La conversion COBOL automatisée fonctionne. Ce n’est pas le problème. Le problème, c’est à quoi ressemble la sortie et ce qu’elle coûte à vivre au quotidien.

Les moteurs de traduction sont généralement fidèles. Ils préservent le comportement, y compris celui que personne n’a voulu, parce que la fidélité est le seul objectif de conception défendable. Un outil ne peut pas savoir qu’une particularité d’arrondi dans un calcul de prime est un défaut que les actuaires compensent depuis 1997, alors il la reproduit exactement. C’est le bon choix, et cela signifie que votre nouveau système Java hérite de toutes les bizarreries accumulées par l’ancien.

La sortie est aussi façonnée par l’entrée. Du COBOL écrit avec des chaînes de GOTO, des enchaînements PERFORM THRU, des instructions ALTER et des paragraphes que l’on entre par plusieurs endroits ne se décompose pas en méthodes propres, parce qu’il n’y a pas de décomposition propre à trouver. Ce qui en sort est du Java ou du C# qui suit le flux de contrôle du COBOL, reprend ses noms de variables et se lit souvent plus difficilement que l’original. Les praticiens appellent cela du JOBOL, et il est tout à fait possible de réussir une migration et de se retrouver avec une base de code que personne ne sait maintenir, dans aucune des deux langues.

Quelques constructions précises coûtent bien plus cher que les autres, et il vaut la peine de les repérer tôt car ce sont elles qui pilotent l’estimation de l’effort manuel.

Les cinq constructions qui pilotent l’effort manuel

L’arithmétique décimale condensée vient en premier. Les champs COMP-3 du COBOL et sa sémantique décimale en virgule fixe ne se projettent pas sur le flottant, et tout outil qui l’autorise produira des résultats financiers différents du mainframe à la quatrième décimale. Les conversions correctes utilisent des types décimaux à précision arbitraire, plus lents, et qui doivent être appliqués de façon cohérente sur tous les chemins de calcul.

L’encodage des caractères vient en deuxième. La conversion d’EBCDIC vers ASCII est mécanique, mais la séquence de classement ne l’est pas, si bien que tout ce qui dépend de l’ordre de tri peut changer. Les états sortent dans un autre ordre, les contrôles de plage se comportent autrement, et les comparaisons de clés donnent des résultats corrects dans le nouveau système et faux face à l’ancien.

REDEFINES et les enregistrements à variantes viennent en troisième. Une même zone de stockage interprétée de plusieurs façons n’a pas d’équivalent naturel dans un langage fortement typé. Le code généré produit alors de la manipulation de tableaux d’octets enveloppée dans des accesseurs, ce qui fonctionne et se maintient très mal.

La sémantique transactionnelle vient en quatrième. La programmation pseudo-conversationnelle de CICS, où l’état est porté dans une zone de communication entre deux interactions d’écran, ne correspond à aucun motif web ou service moderne. L’émuler produit quelque chose d’étrange ; la reconcevoir correctement revient à réécrire la couche de présentation.

Les routines Assembleur viennent en cinquième et sont les plus régulièrement sous-estimées. Presque tout patrimoine ancien contient une poignée de modules Assembleur, écrits d’ordinaire par quelqu’un parti à la retraite depuis longtemps, qui font quelque chose de critique en performance ou de spécifique à la plateforme. Aucun outil ne les convertit. On les réécrit à la main, à partir du comportement observé, sous tests.

Si vous arbitrez entre langages cibles, nos guides détaillés sur la migration COBOL vers Java et la migration COBOL vers C# montrent comment ces constructions atterrissent dans chaque écosystème.

Les outils de migration de données et les détails qui mordent

Le déplacement des données reçoit moins d’attention que la conversion de code et provoque au moins autant de retards.

Les outils spécialisés méritent leur place ici parce que les formats de données mainframe sont réellement rétifs. Ils comprennent les mises en page de copybooks, les champs décimaux condensés et zonés, les surperforations de signe, les clauses OCCURS DEPENDING ON et le fait qu’un même fichier VSAM peut contenir plusieurs types d’enregistrements distingués par un octet en position douze. Les produits ETL généralistes ne le comprennent pas, et les équipes qui essaient de les y forcer finissent par reconstruire une version inférieure de la même capacité.

Le problème le plus dur est sémantique et non technique. Les fichiers mainframe encodent fréquemment du sens d’une manière qu’un schéma relationnel ne peut pas exprimer directement : des champs de remplissage détournés, des dates stockées en entiers à six chiffres avec une règle de fenêtrage, des indicateurs d’état dont les valeurs valides vivent dans un programme plutôt que dans une table de référence, et des clés en double que l’application tolère. Décider ce que chacun doit devenir dans le schéma cible est un travail d’analyse, et il ne s’automatise pas, parce que les réponses n’existent que dans la tête des gens.

Prévoyez la réconciliation dès le départ. Chaque jeu de données migré exige des comptages d’enregistrements, des totaux de contrôle et une comparaison champ à champ avec la source, exécutés de façon répétée et non une fois pour toutes. La plupart des programmes ont aussi besoin d’une période de fonctionnement en parallèle, où les deux systèmes traitent les mêmes entrées et où les sorties sont comparées octet par octet jusqu’à ce que les écarts soient éliminés ou expliqués. Ce banc de comparaison est un vrai logiciel avec son propre coût de développement, et il appartient au plan plutôt qu’à la provision pour aléas.

Choisir ses outils de migration mainframe sans le regretter

Quelques principes gardent ces décisions les pieds sur terre.

Exigez une preuve de concept sur votre pire code à vous, pas sur l’échantillon du fournisseur. Choisissez le module que tout le monde évite, celui avec l’appel Assembleur et le REDEFINES à sept niveaux, et demandez qu’il soit converti. Le résultat vous apprendra plus que n’importe quelle référence client.

Demandez précisément comment l’outil traite l’arithmétique décimale et l’ordre de tri, et demandez à voir le code produit plutôt qu’un résumé. Si le fournisseur ne peut pas vous montrer du code lisible à partir d’une entrée laide, tenez pour acquis que l’estimation de reprise manuelle est plus grande qu’annoncée.

Traitez les pourcentages d’automatisation comme une mesure de lignes, pas d’effort. Un outil qui convertit quatre-vingt-dix pour cent des instructions peut vous laisser les dix pour cent qui contiennent tout le risque, et ces dix pour cent consomment couramment plus de la moitié du calendrier.

Enfin, budgétez ce qu’aucun outil ne touche : le harnais de tests, la réconciliation, le fonctionnement en parallèle, les procédures d’exploitation et la reformation. Notre guide des coûts et délais de migration COBOL expose comment ces postes se répartissent habituellement sur un programme.

Prenez un avis indépendant avant de vous engager

Mecanik intervient sur les programmes de migration de mainframe hérité et de migration COBOL en tant qu’ingénieurs et non en tant que revendeur d’outils, ce qui veut dire qu’aucune commission ne dépend de la plateforme que vous choisirez. Nous menons la découverte, convertissons à la main et par l’outil un module réellement difficile, et vous montrons la différence avant que quiconque signe quoi que ce soit.

Si votre patrimoine est plus petit ou si votre question porte davantage sur le langage cible que sur l’outillage, nos pages de service de modernisation COBOL expliquent comment nous cadrons ce travail. Dans les deux cas, le premier pas utile est une courte conversation sur ce que contient réellement votre base de code, parce que la réponse à la question des outils en dépend entièrement.

Articles en relation: Migration COBOL vers Python , Migration COBOL vers Go : guide pour l’entreprise UK et Migration COBOL vers Rust - Guide entreprise UK ., Modernisation COBOL : bien choisir son prestataire

Questions fréquentes

Les outils de migration mainframe peuvent-ils automatiser tout le projet ? Non. La traduction automatisée convertit en général la grande majorité des instructions, mais le reste contient des modules Assembleur, de la gestion d’état transactionnel, des structures d’enregistrements à variantes et des règles métier non documentées qui exigent du travail manuel. Les tests, la réconciliation et le fonctionnement en parallèle ne dépendent pas non plus du niveau d’automatisation atteint.

Vaut-il mieux réhéberger ou convertir le code automatiquement ? Ce sont deux problèmes différents. Le réhébergement sort rapidement la charge du matériel mainframe et réduit les coûts d’exploitation, mais vous laisse du COBOL. La conversion de code change le langage et le vivier de recrutement, à un coût et un risque nettement supérieurs. Beaucoup d’organisations réhébergent d’abord pour financer ensuite une conversion par étapes.

Pourquoi le code COBOL converti est-il si illisible ? Les moteurs de traduction préservent fidèlement le comportement, y compris le flux de contrôle, le nommage et les structures de données du COBOL. Du code bâti sur des chaînes de GOTO et des zones de stockage partagées n’a pas d’équivalent propre en Java ou en C#, donc la sortie reflète la structure d’origine. Obtenir du code maintenable demande un refactoring humain après la conversion.

Quels problèmes de données les outils de migration mainframe manquent-ils ? Ils traitent bien la conversion de format mais ne peuvent pas résoudre le sens. Champs de remplissage détournés, dates à six chiffres avec règle de fenêtrage, codes d’état définis seulement dans un programme et clés en double tolérées demandent tous des décisions humaines avant de concevoir correctement un schéma cible.

Comment valider qu’un système migré se comporte à l’identique ? Faites tourner les deux systèmes sur les mêmes entrées de production pendant une période définie et comparez les sorties champ par champ, en vous appuyant sur des comptages d’enregistrements et des totaux de contrôle pour chaque jeu de données migré. Construisez ce banc de comparaison comme un livrable à part entière, car les écarts se découvrent en continu et non d’un seul coup.