Comment minimiser les risques liés à la migration mainframe : l’analyse indispensable avant toute migration

Les migrations mainframe échouent pour une raison prévisible. Non pas parce que l'architecture cloud cible est inadéquate, ni parce que les outils de conversion COBOL vers Java sont insuffisants, ni même par manque de motivation ou de budget. L'échec survient parce que l'équipe se lance dans la migration sans en connaître la nature, sans pouvoir justifier par des preuves concrètes le fonctionnement de chaque programme, les interdépendances entre eux, le flux de données au sein du système et les conséquences d'une modification. Le mode d'échec est presque toujours le même : une dépendance découverte en cours de migration et dont personne n'avait connaissance, une règle métier enfouie dans un copybook partagé par 400 programmes, un traitement par lots alimentant douze systèmes en aval via un fichier non documenté.

Le processus de migration d'un système mainframe exige une planification et une exécution rigoureuses afin de minimiser les risques et d'assurer la continuité des activités. Cette affirmation est vraie, mais incomplète. La planification essentielle ne réside ni dans la feuille de route, ni dans le choix du fournisseur, ni dans le calendrier des phases. Il s'agit plutôt de l'analyse structurelle effectuée en amont de toute décision, cette analyse qui révèle la composition et le fonctionnement réels du système, par opposition à sa documentation et à sa conception initiale. Ces deux descriptions divergent systématiquement dans tout environnement mainframe de grande envergure, souvent de manière significative, déterminant ainsi le succès ou l'échec de la migration.

Pourquoi les migrations mainframe échouent : le manque d'analyse

Les migrations mainframe n'échouent pas parce que le code est ancien, mais parce que personne ne comprend vraiment son fonctionnement avant qu'il ne soit trop tard. Logique cachée. Cas particuliers non documentés. Flux oubliés. Il ne s'agit pas de risques théoriques, mais de blocages concrets qui paralysent les projets, engendrent des problèmes de production et érodent insidieusement la confiance dans le plan de migration.

Le manque d'analyse présente une structure spécifique. Les organisations qui exploitent des systèmes mainframe depuis vingt ou trente ans ont accumulé des modifications jamais documentées, des dépendances apparues naturellement du fait du couplage des programmes via des fichiers partagés plutôt que des interfaces explicites, et une logique métier qui n'existe plus que dans l'esprit des développeurs désormais retraités. Les équipes qui traitent les données mainframe comme des fichiers standards font de mauvaises surprises lors de la migration lorsqu'elles réalisent que ces « données » incluent des décennies de logique métier disséminée dans des instructions conditionnelles et des noms de conditions complexes.

Il existe quatre lacunes de connaissances spécifiques qui font dérailler les migrations. Chacune d'elles peut être comblée par une technique d'analyse. Aucune ne peut être résolue par la seule revue de la documentation ou les entretiens avec les développeurs.

Écart 1 : Inventaire de programmes inconnu. Les entreprises constatent régulièrement que leur nombre réel de programmes est bien supérieur à celui documenté. Programmes écrits pour des besoins métiers spécifiques, programmes de test devenus programmes de production, programmes utilitaires dont personne ne se souvient de la création : tous ces éléments se trouvent dans la bibliothèque de chargement et peuvent être appelés par des tâches JCL figurant dans les plannings de production.

Lacune 2 : Dépendances non documentées. Les mainframes alimentent des dizaines de systèmes via des réseaux complexes d’intergiciels tels que WebSphere, CICS Transaction Gateway, Enterprise Service Bus, ainsi que des utilitaires partagés, des planificateurs et des processus métier. L’erreur consiste à tarder à cartographier toutes ces connexions, notamment les flux de données en aval et les modèles de consommation.

Lacune 3 : Logique métier intégrée. Les programmes COBOL accumulent des règles métier au fil des décennies. Un calcul simple en 1985 a été modifié par douze développeurs depuis, chacun ajoutant une logique conditionnelle reflétant une modification de règle métier jamais documentée. Migrer le programme sans comprendre sa logique produit un système qui calcule des résultats différents de l’original, corrects du point de vue du code, mais incorrects du point de vue métier.

Lacune 4 : Couplage du format et du schéma des données. Les programmes qui partagent des données via des fichiers plutôt que des API sont couplés par des contrats de format de données qui n’existent nulle part ailleurs que dans leurs instructions FD et COPY. Toute modification de la structure d’un fichier partagé rend inutilisables tous les programmes qui y accèdent, y compris ceux inclus dans le périmètre de migration et ceux qui resteront sur le mainframe, ce qui entraîne une défaillance d’intégration silencieuse.

Les huit analyses indispensables avant la migration

Les analyses suivantes doivent être réalisées avant toute décision de migration et avant toute modification du code. Il ne s'agit pas d'étapes préliminaires à effectuer rapidement, mais des fondements sur lesquels repose toute décision ultérieure.

1. Inventaire complet du programme

La première analyse consiste en un recensement des programmes, flux de tâches, copybooks, procédures et définitions de données existants dans l'environnement. Il ne s'agit pas d'une revue de documentation, mais d'une analyse approfondie des bibliothèques de chargement, des bibliothèques sources et des bibliothèques de procédures afin d'établir un inventaire exhaustif.

L'inventaire doit recenser : chaque programme source avec son langage et sa taille approximative ; chaque copybook et les programmes qui l'incluent ; chaque procédure cataloguée et les tâches qui l'appellent ; chaque ensemble de données qui apparaît dans les instructions DD et les programmes qui le produisent ou le consomment ; chaque table, vue et procédure stockée DB2 référencée dans le SQL embarqué.

Dans la plupart des grands environnements mainframe, cet inventaire révèle des programmes inconnus de l'équipe de planification de la migration, parfois avec un écart de 20 à 30 % par rapport au nombre total. Les plans de migration basés sur des inventaires incomplets entraînent des dépassements de coûts lorsque les programmes manquants sont découverts en cours de projet.

2. Cartographie des dépendances dans toutes les langues

Une fois l'inventaire établi, la cartographie des dépendances permet de retracer les liens entre chaque composant. Cette cartographie constitue l'analyse préalable à la migration la plus cruciale, car elle définit le périmètre de chaque modification ultérieure.

Une cartographie complète des dépendances couvre :

• Appels de programme à programme: Appels, opérations, liens, attachements et appels dynamiques résolus à l'exécution
• invocations JCL vers programme: chaque instruction EXEC PGM= dans chaque flux de travaux JCL, y compris les appels PROC avec substitution de paramètres symboliques résolue
• chaînes d'inclusion de cahiers: quels programmes incluent quels copybooks, y compris les copybooks imbriqués inclus par d'autres copybooks
• Ensemble de données sur les relations producteur-consommateur: quels programmes écrivent dans quels ensembles de données, quels programmes lisent à partir de ces ensembles de données, et les dépendances séquentielles de la chaîne de tâches que cela crée
• Références de schéma DB2: quels programmes lisent ou écrivent dans quelles tables, quelles tables partagent un schéma avec quelles autres tables

Le résultat est un graphe orienté. Toute modification proposée à un nœud de ce graphe peut être analysée afin d'en évaluer l'impact en parcourant les arêtes et en recensant tous les autres nœuds qui en dépendent. Sans ce graphe, l'analyse d'impact relève de la conjecture.

Avant toute modification du code, une visibilité complète est primordiale. Se fier à une documentation obsolète est une erreur fatale ; les outils automatisés doivent cartographier automatiquement l’état actuel en analysant le JCL, le COBOL et le PL/I, et en recensant toutes les applications, les flux de données, les dépendances et les tâches cachées.

3. Extraction et documentation de la logique métier

Les programmes COBOL contiennent une logique métier qui n'existe nulle part ailleurs dans l'organisation. Il s'agit de l'analyse la plus négligée lors de la planification de la migration et celle qui engendre les échecs les plus coûteux après la migration.

L'extraction de la logique métier produit une documentation sur : les règles de décision encodées dans les structures IF/THEN/ELSE et EVALUATE ; les formules de calcul dans les instructions COMPUTE ; les règles de validation des données dans les paragraphes PROCEDURE DIVISION ; les chemins de gestion des erreurs et leur signification métier ; et la logique dépendante de la séquence où l'ordre des opérations importe pour l'exactitude du résultat.

Cette analyse ne nécessite pas la lecture manuelle de chaque ligne de chaque programme. Les outils d'analyse statique compatibles avec le COBOL peuvent identifier les structures de décision, extraire la logique conditionnelle et générer une documentation structurée des règles qu'elles encodent. Ce résultat remplit deux objectifs : il fournit à l'équipe de migration les spécifications nécessaires pour valider que le système migré produit des résultats corrects, et il offre à l'entreprise la première documentation systématique des règles métier qui, pendant des décennies, n'ont pu exister que dans le code.

4. Identification du code mort

Il n'est pas nécessaire de migrer l'ensemble des éléments du système mainframe. Les programmes jamais appelés par un flux de travaux, les paragraphes jamais exécutés par un chemin d'accès appelant, les membres du copybook jamais référencés : tous ces éléments représentent un effort de migration inutile.

L'identification du code mort analyse le graphe de dépendances pour repérer les composants sans aucune référence entrante provenant d'un flux de production. Ces composants peuvent être exclus du périmètre de la migration, ce qui réduit les coûts sans compromettre les fonctionnalités. Dans les environnements existants de grande envergure, le code mort représente généralement 10 à 25 % du total, une réduction significative du périmètre lorsqu'il est identifié systématiquement plutôt que découvert fortuitement.

L'analyse doit distinguer le code véritablement inactif (jamais accessible depuis un chemin d'exécution en production) du code rarement exécuté (accessible mais rarement déclenché). Ce dernier, comme les routines de fin d'année, les programmes de reporting réglementaire ou les procédures de reprise après sinistre, peut être critique malgré sa faible fréquence d'exécution. L'exclure de la migration aboutit à un système fonctionnant correctement 99 % du temps et tombant en panne précisément au moment où il est le plus nécessaire.

5. Classification de la complexité et des risques

Une fois l'inventaire des programmes et la cartographie des dépendances établis, chaque programme peut être classé selon sa complexité et le risque de migration. Cette classification détermine l'ordre de migration : les programmes à faible complexité et à faible dépendance sont migrés en premier ; les programmes à forte complexité et à forte dépendance sont migrés en dernier, après avoir fait l'objet de tests approfondis.

Métriques de complexité pour le risque de migration COBOL :

Facteur de complexité	À mesurer	Seuil de risque élevé
Complexité cyclomatique	Nombre de branches de décision par programme	Plus de 50 par programme
nombre de dépendances du copybook	Nombre de cahiers inclus	Plus de 20 cahiers
Appelé par nombre	Nombre de programmes qui appellent ce programme	Plus de 15 appelants
Références des ensembles de données	Nombre d'ensembles de données lus ou écrits	Plus de 30 ensembles de données
SQL intégré	Nombre d'instructions SQL	Plus de 100 déclarations
Appels EXEC CICS	Couplage du serveur de transactions	Toute dépendance à CICS
Appels dynamiques	Appels résolus lors de l'exécution	Tout appel dynamique
Appels de l'assembleur	Logique non-COBOL intégrée	Appel de tout assembleur

Les programmes obtenant des scores élevés sur plusieurs facteurs représentent les composantes de migration les plus risquées. Ils nécessitent une analyse approfondie, des ingénieurs en migration expérimentés et une couverture de tests exhaustive.

6. Analyse des dépendances entre la fenêtre de traitement par lots et la planification

Les traitements par lots sur mainframe s'exécutent dans des fenêtres planifiées avec des chaînes de dépendances complexes : le traitement B ne peut démarrer que lorsque le traitement A s'est terminé avec succès ; le traitement C ne s'exécute que le dernier jour ouvrable du mois ; le traitement D a une contrainte de durée d'exécution maximale qui affecte l'heure de démarrage du traitement E. Ces dépendances de planification font partie du comportement opérationnel du système et doivent être reproduites dans l'environnement cible.

Les documents d'analyse des fenêtres de traitement par lots comprennent : la chaîne d'exécution complète pour chaque exécution par lots de production ; les contraintes de temps sur chaque étape ; la logique d'exécution conditionnelle (ce qui se passe lorsqu'une étape échoue ou produit un code de retour non nul) ; les ensembles de données qui circulent entre les étapes ; et les déclencheurs et notifications externes que le système de traitement par lots produit.

Dans les cibles natives du cloud, cela se traduit par : la configuration équivalente du pipeline CI/CD ou de l'orchestration du flux de travail ; la configuration de la gestion des erreurs et des alertes ; la configuration de la surveillance et des SLA ; et l'intégration avec les systèmes en aval qui reçoivent les résultats par lots.

7. Évaluation de la qualité et du format des données

Les systèmes existants contiennent souvent des milliers de lignes de code écrites en COBOL, PL/I ou assembleur, dont une grande partie est mal documentée ou fortement couplée. Utilisez des outils d'analyse statique pour détecter la dette technique, le code redondant et les modules pouvant être modularisés ou supprimés.

L'évaluation de la qualité des données examine les données réelles des jeux de données de production par rapport aux définitions de format des fichiers COBOL et des copybooks. Des divergences sont fréquentes : champs décimaux compactés contenant des séquences binaires invalides pour certains types d'enregistrements, champs de longueur variable dont l'indicateur de longueur est hors limites pour un sous-ensemble d'enregistrements, champs de caractères EBCDIC contenant des valeurs non affichables à certaines positions.

Ces anomalies doivent être identifiées et corrigées avant la migration, et non découvertes lors des tests de migration. Une migration de données portant sur 500 millions d'enregistrements et révélant ensuite que 0.1 % d'entre eux présentent des formats invalides constitue un défaut critique pour la production, présent dans les données sources et inconnu jusqu'à l'étape de validation.

8. Intégration et cartographie des systèmes externes

Votre traçabilité des données doit capturer tous les systèmes consommant des données mainframe, des outils de reporting aux intégrations partenaires, car les projets de modernisation ne peuvent pas être mis en production lorsque les équipes découvrent tardivement, au cours du développement, que la préservation de ces flux de données était essentielle mais non prévue.

Le mappage d'intégration identifie tous les systèmes extérieurs au mainframe qui reçoivent des données de celui-ci ou lui en envoient : les applications en aval qui consomment des sorties par lots via transfert de fichiers ; les interfaces en temps réel via MQ, CICS ou appels API ; les intégrations partenaires qui reposent sur des formats de fichiers et des calendriers de transmission spécifiques ; les systèmes de reporting qui interrogent directement les tables DB2 ; et les flux d'entrepôt de données qui ingèrent des données mainframe transformées.

Chaque point d'intégration représente un risque potentiel de basculement : un système migré produisant des données dans un format non attendu par un système en aval entraînera une défaillance silencieuse, potentiellement non détectée jusqu'à ce qu'un utilisateur en aval signale une anomalie. La cartographie des intégrations est l'analyse qui permet une planification de basculement exhaustive et non optimiste.

Choisir une stratégie de migration en fonction des résultats de l'analyse

L'analyse préalable à la migration ne se contente pas de réduire les risques ; elle détermine également la stratégie de migration la plus adaptée à chaque composant. Les équipes migrent les charges de travail mainframe de différentes manières, selon leur capacité à gérer le changement. Les résultats de l'analyse éclairent directement cette décision.

Résultats de l'analyse	Stratégie recommandée	Raisonnement
Faible complexité, peu de dépendances, pas d'appels dynamiques	Réhébergement (migration par transfert)	Risque minimal ; équivalence comportementale rapidement atteignable
Complexité modérée, logique métier bien documentée	Restructuration	Quelques modifications sont acceptables ; la logique est comprise.
graphe de dépendances dense et de grande complexité	figuier étrangleur phasé	Procéder par étapes ; conserver le mainframe pour le cœur du système tout en modernisant l’infrastructure environnante.
Programme partagé essentiel, plus de 100 appelants	API encapsulée	Présenter comme un service ; migrer les consommateurs sans modifier le programme
Programmes présentant des données invalides ou des problèmes de format	Correction des données en premier	La migration ne peut réussir que lorsque les données sont propres.
Code mort confirmé par analyse	Prendre ma retraite	Aucune migration nécessaire ; retirer du périmètre
Logique métier non documentée, aucun expert métier disponible	Une analyse approfondie est nécessaire.	La migration ne peut être effectuée en toute sécurité tant que la logique n'est pas extraite et documentée.

Construction de la séquence de migration à partir du graphe de dépendance

Une fois complété, le graphe de dépendances définit directement la séquence de migration. Les composants indépendants des autres composants du système central peuvent être migrés rapidement et indépendamment. Les composants dont dépendent de nombreux autres doivent être migrés en dernier, une fois que tous leurs dépendants sont prêts.

Une approche pratique de séquençage :

Phase 1 : Programmes utilitaires et traitements par lots autonomes. Programmes sans appelants ni jeux de données partagés. Ils peuvent être migrés de manière isolée, sans aucune coordination requise.

Phase 2 : Programmes terminaux dans l’arbre de dépendances. Programmes qui appellent d’autres programmes, mais qui ne sont pas appelés par beaucoup. Leur migration les retire du périmètre de dépendance des programmes restants.

Phase 3 : Programmes couplés aux données. Les groupes de programmes qui partagent des ensembles de données peuvent être migrés ensemble comme une unité, résolvant ainsi le contrat de format de données au sein du groupe migré.

Phase 4 : Programmes de services partagés. Les programmes comportant de nombreux appelants, les nœuds à forte dépendance dans le graphe de dépendance, ne sont migrés qu’après que tous les appelants ont été validés par rapport à l’implémentation migrée.

Phase 5 : Programmes transactionnels principaux. Les composants les plus à risque sont migrés en dernier, avec la couverture de tests la plus complète et le processus de basculement le plus contrôlé.

Cette séquence n'est pas une heuristique générale ; elle est dérivée du graphe de dépendances spécifique du système à migrer. Deux environnements mainframe ayant le même nombre de programmes auront des séquences de migration optimales totalement différentes, car leurs structures de dépendances diffèrent.

Comment SMART TS XL Produit l'analyse de pré-migration

SMART TS XL Ce système effectue automatiquement les huit analyses décrites dans cet article, en analysant le code source de chaque composant de l'environnement. Il ne s'appuie ni sur la documentation, ni sur des entretiens avec les développeurs, ni sur des diagrammes existants ; il dérive le modèle structurel directement du code. Ainsi, le modèle est précis même pour les programmes non documentés et les dépendances apparues involontairement.

L' analyse de modernisation des systèmes existants commence par un inventaire complet : chaque programme COBOL, flux de travaux JCL, copybook, procédure (PROC) et schéma SQL est catalogué avec son emplacement source, sa taille, sa version et un score de complexité préliminaire. La cartographie des dépendances applicatives construit le graphe de dépendances complet, en résolvant les paramètres symboliques JCL grâce à la fonctionnalité d'expansion JCL afin d'afficher les programmes réellement appelés plutôt que les références de modèles non résolues.

La fonctionnalité d'analyse d'impact permet d'interroger le graphe de dépendances : avant de migrer un composant, l'équipe peut déterminer les conséquences de sa suppression du système central et obtenir une liste structurée et détaillée de tous les composants dépendants nécessitant une validation ou une coordination. La fonctionnalité de recherche d'entreprise permet d'interroger simultanément l'inventaire complet, tous langages confondus, et de trouver en quelques secondes, au sein d'une base de code de plusieurs millions de lignes, chaque programme lisant un ensemble de données spécifique, chaque copybook définissant un champ spécifique, chaque instruction SQL référençant une colonne spécifique.

L'analyse préalable à la migration ne constitue pas un plan de projet. Elle fournit des éléments de preuve structurels : le graphe de dépendances, la classification de la complexité, l'inventaire du code mort, la documentation de la logique métier et le schéma d'intégration. Ensemble, ces éléments indiquent précisément à l'équipe de migration sur quoi elle travaille. C'est grâce à ces éléments que la migration peut faire toute la différence entre une migration qui découvre des surprises en production et une migration où ces surprises sont détectées lors de l'analyse, ce qui permet de réduire le temps de détection et de résolution à quelques semaines plutôt qu'à plusieurs mois.

L'analyse n'est pas une charge supplémentaire, c'est la migration.

L'objection la plus fréquente à une analyse préalable exhaustive de la migration concerne les délais : l'organisation s'est engagée sur une date de début, la pression de la direction est forte et consacrer six à huit semaines à l'analyse avant même de toucher au code est perçu comme un retard. Ce raisonnement inverse l'évaluation des risques. Une fois les règles identifiées et les flux cartographiés, le projet passe de la phase de spéculation à la phase d'ingénierie. Les outils d'automatisation rendent l'invisible visible, et c'est là l'essentiel.

Une migration entamée sans analyse complète ne démarre pas plus vite, elle démarre avec un périmètre inconnu. Ce périmètre inconnu engendre des imprévus dans les délais, des dépassements de budget et des incidents de production lorsque les dépendances non identifiées se révèlent. La phase d'analyse ne retarde pas la migration ; elle en est l'essence même. Chaque dépendance découverte lors de l'analyse plutôt que lors de la bascule représente un incident de production évité. Chaque programme identifié comme code mort avant la migration représente un effort gaspillé. Chaque règle métier documentée avant la conversion constitue un critère de validation vérifiable plutôt que conjectural.

Les organisations qui réussissent sont celles qui abordent la complexité de manière proactive, identifient les dépendances dès le départ, démocratisent le savoir, se concentrent sur la valeur ajoutée pour l'entreprise et s'alignent sur des objectifs clairs dès le premier jour. Il ne s'agit pas simplement de bonnes pratiques ; c'est ce qui distingue les projets de transformation qui génèrent un retour sur investissement mesurable de ceux qui finissent par servir d'exemples à ne pas suivre.