Guide de modernisation mainframe
Migration mainframe vers le cloud : décider avant de migrer
Pour certaines charges de travail mainframe, la migration est le bon choix. Pour d’autres, c’est une erreur coûteuse. La difficulté est de savoir dans quel cas vous êtes avant de dépenser de l’argent.
La migration du mainframe vers le cloud consiste à déplacer des charges de travail qui tournent aujourd’hui sur IBM Z (applications COBOL, traitements batch, traitement transactionnel) vers une infrastructure de cloud public. Pour les charges de travail qui s’y prêtent, elle peut réduire les coûts de calcul et accélérer les livraisons. Mais mal menée, elle peut entraîner des années de retard, coûter plus cher que le mainframe qu’elle remplace, et parfois échouer complètement. La décision doit se prendre charge de travail par charge de travail, et non au niveau de la plateforme. Elle doit commencer par établir ce que chaque charge de travail coûte réellement aujourd’hui.
Quand la migration a du sens
Bien menée et avec une charge de travail adaptée, la migration est très bénéfique. L’élasticité du cloud réduit vraiment les coûts de calcul quand la demande est irrégulière et variable. Les outils cloud natifs (conteneurs, livraison continue, DevOps) donnent une vitesse de mise en production que le mainframe n’a jamais pu atteindre. Vous avez aussi accès à un vivier de talents bien plus large que le nombre décroissant de développeurs COBOL. La migration est une voie de modernisation du mainframe, mais elle est loin d’être la seule. Seules les charges de travail à demande variable, avec une interface claire avec le reste des systèmes de l’entreprise et un dossier économique bien défini, se prêtent à la migration.
Ce que le dossier économique oublie en général
Les dossiers de migration peuvent paraître séduisants sur le papier et s’effondrer dans la réalité, parce que les problèmes difficiles n’apparaissent que plus tard. Les projets peuvent durer plus longtemps et coûter plus cher que prévu : les deux plateformes fonctionnent en parallèle pendant des mois, voire des années ; les composants exotiques (comme Assembler, Easytrieve et IMS) n’ont pas d’équivalent simple dans le cloud ; et dans une migration COBOL, le code vieux de plusieurs décennies contient des règles métier qui n’ont jamais été documentées nulle part. Dans les secteurs réglementés, la conformité ajoute encore des années. Les exemples les plus graves sont publics. Lors de la migration de TSB Bank en 2018, les services bancaires ont été perturbés pour une grande partie de ses 5,2 millions de clients, et la banque a reçu des amendes de 48,65 millions de livres sterling de la FCA et de la PRA (FCA). L’idée que l’IA générative rendrait désormais la migration facile est aussi largement exagérée : Gartner prévoit que plus de 70 % des projets de sortie du mainframe lancés en 2026 n’atteindront pas les bénéfices attendus, parce que les capacités des outils d’IA générative ont été surestimées (Gartner).
Par ailleurs, l’IA est aujourd’hui l’un des postes qui augmentent le plus vite dans de nombreux budgets mainframe, et IBM positionne la plateforme comme un lieu où faire tourner l’inférence d’IA, plutôt que comme une plateforme d’où sortir les charges d’IA. Voir notre article sur l’IA et le coût du mainframe.
Selon les sources, l’amende infligée à TSB s’élève à 48,65 millions de livres sterling au total (29,75 millions de la FCA et 18,9 millions de la PRA), comme l’indique fca.org.uk le 20 décembre 2022 ; par ailleurs, le communiqué de presse de Gartner du 18 juin 2026 indique que plus de 70 % des projets de sortie du mainframe échoueront parce que les capacités de l’IA générative ont été surestimées.
Obtenez la grille de décision complète pour la migration mainframe vers le cloud
Pour une vue plus détaillée de la migration du mainframe vers le cloud, téléchargez notre guide de migration. Il présente les quatre stratégies de migration et leurs compromis, des exemples réels de réussites et d’échecs, le modèle hybride qu’IBM développe aujourd’hui, et une grille d’évaluation charge de travail par charge de travail, à utiliser dans votre propre environnement. Téléchargez-le avant de monter votre dossier économique.
Télécharger le guide de migrationLe premier pas le plus judicieux : optimiser les coûts et l’usage
“Pour de nombreux clients mainframe, l’IA générative peut servir plus efficacement à moderniser sur place qu’à accélérer la sortie de la plateforme.”
— Alessandro Galimberti, VP Analyst, Gartner (juin 2026)
Ce que la plupart des plans de migration oublient, c’est que vous ne pouvez pas trancher sans savoir combien coûte chaque charge de travail et comment elle se comporte. De plus, le travail nécessaire pour réunir ces informations est souvent celui-là même qui rend la migration inutile. Avant de déplacer quoi que ce soit, établissez donc deux choses.
Maîtrise des coûts
Les frais de licence mensuels (MLC) sont en général le premier poste du budget d’exploitation du mainframe, et ils augmentent avec vos charges de travail (HCLTech). Aujourd’hui, un FinOps mainframe actif (gestion financière des opérations) aide à réduire cette facture grâce à Zetaly Automated Capacity (ZAC). ZAC gère le pic de facturation de la moyenne glissante sur 4 heures (R4HA) qui fixe votre facture mensuelle, et réduit en général les MLC de 5 à 20 %, sans changer les applications. Ces économies vous restent acquises, que vous migriez ou non, et elles financent la migration si vous décidez de la faire.
Visibilité sur l’usage
Vous devez pouvoir voir ce que chaque charge de travail utilise réellement, par application et par entité métier, pour décider lesquelles méritent d’être déplacées. Zetaly Data Platform (ZDP) collecte ces données d’exploitation en utilisant moins de 0,2 % des ressources du mainframe, et Zetaly Service Intelligence (ZSI) les transforme en tableaux de bord que chaque partie de l’entreprise peut comprendre sans qu’un spécialiste mainframe doive les interpréter.
L’optimisation des coûts mainframe consiste à réduire les coûts de la plateforme et à bien comprendre ce dont chaque charge de travail a besoin. Une fois que vous avez une baseline de coûts et une vision claire de l’usage, les décisions de migration ne reposent plus sur des suppositions. L’optimisation du mainframe se suffit à elle-même, car la solution habituelle est d’optimiser sur place et de ne déplacer que les charges de travail qui apportent un vrai retour.
Questions fréquentes
Que veut dire migrer du mainframe vers le cloud ?
Cela consiste à déplacer des charges de travail qui tournent aujourd’hui sur IBM Z, comme des applications COBOL, des traitements batch et du traitement transactionnel, vers une infrastructure de cloud public. La migration peut réduire les coûts et accélérer les livraisons pour certaines charges de travail. Mais pour les systèmes à haut débit ou très imbriqués, elle est souvent plus lente, plus chère et plus risquée que prévu.
Quitter le mainframe permet-il toujours de faire des économies ?
Le cloud est plus économique pour les charges de travail irrégulières et variables. Pour le traitement transactionnel à haut débit qui tourne presque en continu, l’économie du mainframe peut rester compétitive une fois pris en compte les sorties réseau, le stockage et le coût d’exploitation de l’infrastructure cloud. La vraie réponse dépend de la charge de travail, pas de la plateforme.
Combien de temps dure une migration mainframe ?
Les durées varient beaucoup. Réhéberger une seule application bien documentée peut prendre plusieurs mois. La migration d’un système bancaire central complet prend entre 18 mois et trois ans avec des moyens importants, et les projets de refactoring complexes durent en général plus longtemps que prévu. Prévoir le double de votre première estimation, ce n’est pas être pessimiste : c’est caler votre plan sur les faits observés.
Quelle est la cause la plus fréquente d’échec des migrations mainframe ?
Sous-estimer la complexité, en particulier celle de certains composants exotiques comme Assembler, Easytrieve et IMS, situés en périphérie de l’application principale. Ces problèmes ne sont alors repérés que tard, une fois les budgets et les calendriers fixés, et le planning glisse. Le meilleur moyen de limiter ce risque est de faire une évaluation approfondie dès le départ, avec une analyse automatisée du code.
Faut-il optimiser mon mainframe avant de migrer ?
Oui. Optimiser d’abord les coûts et l’usage vous donne la baseline de coûts par charge de travail dont vous avez besoin pour choisir quoi déplacer en priorité, et réduit votre facture pendant la phase de préparation, qui dure souvent plus longtemps que prévu. L’optimisation des coûts mainframe finance la migration et montre souvent que garder certaines charges de travail en place est le meilleur choix.
Qu’est-ce que le modèle hybride mainframe-cloud ?
Le modèle hybride garde le mainframe pour ce qu’il fait le mieux (transactions à haut débit, conservation des données réglementées, batch quasi continu) et déplace vers le cloud les charges de travail orientées client et analytiques, reliées par des API et des pipelines de données. Pour la plupart des grandes entreprises, c’est la stratégie mainframe-cloud définitive, et non une phase de transition. IBM conçoit directement ses offres pour ce modèle.
Sachez ce que coûte chaque charge de travail avant de décider quoi déplacer
L’erreur la plus courante dans la planification d’une migration est de construire un dossier économique sans données précises sur les coûts du mainframe. Obtenez le guide, établissez votre baseline et générez des économies pendant votre planification.