Un mainframe legacy n'est pas un risque parce qu'il est ancien. Son matériel et son système d'exploitation sont remplacés selon un cycle régulier. La seule partie ancienne est donc le code que votre entreprise a écrit depuis 50 ou 60 ans et qu'elle fait encore tourner chaque jour.
Ce code continue de fonctionner. En revanche, la connaissance qui l'entoure disparaît quand les experts partent à la retraite et quand les entreprises fusionnent. Peu d'entreprises ont encore une personne qui comprend l'ensemble du système. Cette perte de connaissance est le risque à gérer, et c'est un problème différent de l'âge de la plateforme.
Ce que « legacy » veut dire : les applications, pas la machine
Le mot « legacy » s'applique souvent à tout le mainframe, mais il ne convient qu'à une partie. Le matériel est remplacé, pas modernisé, et le système d'exploitation suit la même règle. Ni l'un ni l'autre ne correspond donc à ce que les clients mainframe appellent le legacy.
Le legacy, c'est le parc applicatif. Une entreprise qui écrit des programmes COBOL (Common Business-Oriented Language) depuis 50 ou 60 ans ne sait souvent plus combien de lignes de code elle possède. Pourtant, ces programmes sont son système d'information. En français, on traduit legacy par « héritage », et le mot décrit bien la situation. Un héritage est quelque chose que l'on a construit, qui fonctionne encore et que l'on garde parce qu'il a de la valeur.
C'est pourquoi on ne jette pas les systèmes legacy du mainframe pour les réécrire. Une réécriture complète coûte trop cher et n'est pas réaliste à cette échelle. Les entreprises retirent plutôt les parties qui n'ont plus de sens et construisent de nouveaux services sur la même base.
La tarification d'IBM montre elle-même que l'ancien et le nouveau travail partagent la même machine. En 2014, IBM a annoncé Mobile Workload Pricing for z/OS pour garder les nouvelles charges de travail sur la plateforme. Une transaction mobile commence dans une application sur un téléphone et se termine sur le mainframe. Avec cette tarification, IBM retire 60 % de la capacité processeur utilisée par les transactions mobiles des valeurs en MSU (million service units) qui fixent la facturation en sous-capacité (Value-4IT; Mainframe Watch Belgium). Autrement dit, IBM a rendu le nouveau travail moins cher à faire tourner à côté du legacy.
Vous pouvez voir les deux types de travail côte à côte dans Zetaly Automated Capacity (ZAC). Dans l'exemple client ci-dessous, une partition a une moyenne glissante sur quatre heures (R4HA) de 2 232 MSU, dont 1 709 MSU de travail legacy et 523 MSU de travail mobile.
Ce qui est récent sur un mainframe moderne
La plateforme sous le code legacy est récente. IBM a mis le z17 en disponibilité générale le 18 juin 2025, avec un processeur Telum II qui embarque sur la puce un accélérateur d'intelligence artificielle (IA) (IBM). Le système d'exploitation correspondant, z/OS 3.2, est en disponibilité générale depuis le 30 septembre 2025 (IBM).
La plupart des sites ne sont pas sur la dernière version, mais ils en sont proches. Une mise à niveau prend tant de temps que la version suivante est déjà sortie quand le projet se termine. C'est pourquoi certains sites restent sur une version plus ancienne, puis passent directement à la plus récente. Le travail de mise à niveau ne s'arrête jamais, et un site en retard l'est en général parce que ce travail ne peut pas aller plus vite.
Les logiciels autour du système d'exploitation suivent le même cycle. Ils comprennent la base de données Db2 et les moniteurs transactionnels CICS (Customer Information Control System) et IMS (Information Management System). Une application type est un programme COBOL qui tourne via CICS en temps réel ou en batch, et qui lit ou met à jour des données dans Db2. Quand un client utilise une application mobile, celle-ci appelle ces mêmes transactions et lit ces mêmes données. Le canal le plus récent de l'entreprise repose donc sur son code le plus ancien.
Ce qui vieillit mal sur un mainframe legacy : la connaissance
Le code continue de tourner, mais la connaissance nécessaire pour le modifier dure moins longtemps. Trois causes expliquent cette perte.
La première cause est le vieux code auquel personne n'ose toucher. Avant que des produits comme Db2 et CICS se généralisent, les développeurs écrivaient leurs propres équivalents en assembleur, un langage proche du code machine. Certains de ces programmes des années 1970 et 1980 tournent encore aujourd'hui, et chaque site mainframe en a. Ils sont critiques et ils fonctionnent, mais leur auteur est parti depuis longtemps sans documenter le code ni transmettre son savoir-faire. Avant l'an 2000, les entreprises ont revu leurs systèmes pour vérifier la gestion des dates. Ce nettoyage a supprimé beaucoup de ces programmes, mais pas tous.
La deuxième cause, ce sont les fusions. Par exemple, un groupe bancaire français faisait tourner environ 50 systèmes d'information distincts il y a 25 ans et n'en a plus qu'un aujourd'hui. Chaque regroupement a gardé comme base le système d'une ou deux entités et abandonné les autres. Une partie de l'histoire et de la connaissance est partie avec eux. Beaucoup des applications que personne ne sait expliquer aujourd'hui viennent de ces regroupements. Les équipes travaillent à les retirer, et leur nombre baisse avec le temps.
La troisième cause est la façon dont la connaissance est répartie. Les grands centres de données ont des architectes fonctionnels et des architectes techniques. Un architecte fonctionnel connaît un domaine en profondeur (par exemple, l'application de prêts dans une banque), mais ne sait pas décrire ses liens avec les paiements par carte ou les retraits d'espèces. Un architecte technique fournit les bases de données et les moniteurs transactionnels sur lesquels les développeurs construisent. Comme chacun connaît une partie, la plupart des entreprises n'ont personne capable de dessiner l'ensemble du système d'information.
Certains coûts du mainframe ne sont jamais remis en question non plus, car chaque entreprise a des applications qu'elle ne limitera pas. Une banque ne limite pas les applications qui rapportent du chiffre d'affaires (banque en ligne, retraits d'espèces, paiements interbancaires). Si ces applications ont besoin de plus de MSU, elles en reçoivent plus. De même, un constructeur automobile ne limite pas les applications qui gèrent l'approvisionnement des pièces en flux tendu, et une compagnie aérienne ne limite pas celles qui gèrent le temps passé au sol par un avion. La capacité que ces applications utilisent est donc rarement examinée.
La première étape pour combler ce manque de connaissance est de rendre le parc lisible. Zetaly Data Platform (ZDP) collecte les données opérationnelles que le mainframe produit déjà, et Zetaly Service Intelligence (ZSI) transforme ces données en tableaux de bord organisés par domaine métier. Chaque équipe voit ainsi ce que consomment ses charges de travail, sans spécialiste mainframe pour traduire. Les deux produits font partie de l'offre Observabilité Mainframe de Zetaly.
L'urbanisme mainframe applique les principes de l'urbanisme des villes à un environnement mainframe, pour le rendre plus modulaire et plus facile à faire évoluer.
La question des compétences
La perte de connaissance devient urgente quand un expert part à la retraite. Le départ lui-même peut se prévoir, et une entreprise qui n'a pas organisé la passation a échoué dans sa gestion prévisionnelle des emplois et des compétences. Le problème le plus difficile est de trouver à qui transmettre, et trop souvent une entreprise remplace un expert aux cheveux gris par un autre.
La situation s'améliore, mais lentement. Dans l'enquête 2025 de BMC auprès de plus de 1 000 professionnels du mainframe, 66 % des répondants appartenaient aux générations Y ou Z, contre 37 % en 2018 (BMC). Les jeunes arrivent donc. Ils ont pourtant besoin de temps, car un bon ingénieur système met cinq à six ans à devenir pleinement compétent sur une plateforme aussi large et aussi profonde. Rien ne raccourcit ce délai.
Les données raccourcissent une autre partie de l'apprentissage. Un mainframe enregistre son activité dans les enregistrements SMF (System Management Facilities), et les décoder est difficile, même pour un ingénieur qui a six ans d'expérience. Le décodage est aussi un travail à faible valeur pour cet ingénieur, car il s'apprend une fois et s'applique une fois. ZDP décode les enregistrements automatiquement, et l'ingénieur n'a donc pas à apprendre le décodage. Par exemple, une grande banque au Brésil avait recruté une quinzaine de jeunes ingénieurs système et leur avait demandé d'apprendre à décoder les enregistrements SMF. Ils n'en voyaient pas l'intérêt. Quand Zetaly leur a montré les données déjà décodées et lisibles, ils ont été stupéfaits.
La documentation aide moins que les données. Un document doit encore être lu et assimilé, et cette lecture prend un temps que l'entreprise n'a pas. Les données décodées, elles, suppriment un travail qui n'apporte rien au client. Elles ne remplacent pas pour autant les années dont un ingénieur a besoin pour comprendre le système.
Ce que coûte un mainframe legacy, et ce que coûte d'en sortir
Le vieillissement des compétences fait partie des raisons que les entreprises donnent pour quitter le mainframe (CIO). En sortir est possible aujourd'hui. Il y a vingt ans, les annonces de sortie du mainframe restaient surtout des discours, car aucune autre infrastructure ne pouvait supporter la charge. Cette infrastructure existe désormais, et certaines sorties réussissent. Par exemple, Deluxe Corporation indique avoir quitté en 12 mois environ un mainframe de plus de 50 ans, après une première tentative ratée (CIO).
Le coût et le temps ont toutefois remplacé la technologie comme obstacles. Les projets de sortie prennent du retard et dépassent leur budget (CIO), et 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 sont surestimées (Gartner). Certains échecs sont publics. En avril 2018, la banque TSB a migré les données de ses clients vers une nouvelle plateforme informatique. Une part importante de ses 5,2 millions de clients a été touchée, et les régulateurs ont infligé à la banque une amende de 48,65 millions de livres sterling (FCA).
Zetaly observe les mêmes retards chez ses clients. Deux d'entre eux ont annoncé leur sortie il y a environ six ans. À chaque échéance du contrat de maintenance, ils le renouvellent pour deux ou trois ans de plus. Leurs projets avancent, mais le legacy tourne toujours.
Le coût total de possession (TCO, total cost of ownership) explique une grande partie de cet écart entre le plan et le résultat. Une installation mainframe, c'est une ou deux machines et leurs baies de disques, alors que la même capacité sur des serveurs standard en demande des milliers. Un dossier d'investissement qui oublie une partie de ce coût aboutit donc à la mauvaise réponse. Les équipes informatiques calculent aujourd'hui le TCO avec plus de soin qu'il y a dix ans, et les sorties lancées sur le seul enthousiasme deviennent rares.
C'est pourquoi la décision de sortir se prend mieux charge de travail par charge de travail que pour toute la plateforme. Un bon responsable d'infrastructure place chaque application là où elle tourne le mieux. L'analytique et les données en lecture seule vont dans le cloud, les traitements intensifs et les très gros volumes batch restent sur le mainframe, et les applications web vont sous Linux ou Unix. Notre guide de migration du mainframe vers le cloud explique comment prendre cette décision.
Une sortie complète reste difficile à cause de la taille du legacy. Le volume de code est énorme, et une reconstruction demande quelqu'un qui comprend l'ensemble du système. La plupart des entreprises n'ont plus cette personne.
Le futur du mainframe est hybride
Comme chaque charge de travail va là où elle tourne le mieux, le centre de données devient un mélange de cloud privé, de cloud public, de mainframe et de conteneurs. Dans ce mélange, le mainframe garde les transactions lourdes et le batch, et confie le reste à la plateforme qui lui convient. Les logiciels doivent suivre la même logique. C'est pourquoi la plupart des logiciels Zetaly sont écrits en Java et tournent dans un conteneur, sous Linux ou sous Linux on IBM Z, là où vous le décidez. ZAC fait exception, car il gère la capacité sur le mainframe et tourne donc sur le mainframe.
L'IA fait partie de ce mélange hybride. Les clients de Zetaly utilisent déjà l'IA en production pour écrire du code et pour analyser la fraude sur les transactions. Ils l'utilisent aussi beaucoup dans les projets de conversion de code (par exemple de COBOL vers Java), et une partie du code converti tourne encore sur le mainframe. Pour leurs données techniques mainframe, les clients s'appuient en revanche toujours sur les statistiques, l'analyse de tendances et la détection d'anomalies. IBM a conçu le z17 pour que l'inférence d'IA puisse tourner sur le mainframe lui-même, avec une capacité annoncée de plus de 450 milliards d'opérations d'inférence par jour (IBM). Zetaly n'a pas encore de retour client sur cet usage, et la plupart des clients s'appuient sur des grands modèles de langage (LLM) existants. Notre article sur l'IA et le coût du mainframe présente l'effet sur votre facture.
L'informatique quantique en est encore à ses débuts. Zetaly s'attend à ce qu'elle rejoigne ce mélange à côté du mainframe. Elle prendrait les très gros calculs qu'elle peut finir en quelques secondes, pendant que le mainframe répartit le travail et reprend la main.
Décider ce que vous gardez sur votre mainframe legacy commence par savoir ce que coûte chaque charge de travail.
Questions fréquentes
Qu'est-ce qu'un mainframe legacy ?
Un mainframe legacy est un mainframe IBM qui fait tourner des applications qu'une entreprise a construites pendant des décennies, souvent en COBOL. Le mot « legacy » désigne ces applications. Le matériel et le système d'exploitation sont remplacés régulièrement. Les entreprises gardent les applications parce qu'elles font encore tourner l'activité chaque jour.
Les systèmes legacy du mainframe sont-ils encore utilisés ?
Oui. Dans l'enquête 2025 de BMC auprès de plus de 1 000 professionnels du mainframe, 97 % avaient une opinion positive de la plateforme (BMC). Les banques, les constructeurs et les compagnies aériennes gardent leurs systèmes legacy, car ces applications font le travail qui rapporte et celui qui ne peut pas s'arrêter.
Quel est le futur du mainframe ?
Le futur du mainframe est hybride. Les entreprises font tourner les transactions lourdes et les gros volumes batch sur le mainframe, l'analytique dans le cloud et les applications web sous Linux. Le z17 d'IBM, disponible depuis juin 2025, ajoute sur la puce un accélérateur d'inférence d'IA (IBM).
Le mainframe est-il obsolète ?
Non. IBM a sorti le mainframe z17 en juin 2025 (IBM) et le système d'exploitation z/OS 3.2 en septembre 2025 (IBM). La plateforme est récente. Ce qui vieillit, c'est la connaissance autour des applications. Le code n'est pas documenté, l'histoire se perd dans les fusions et les experts partent sans successeur.
Combien de temps peut-on garder notre mainframe ?
Aussi longtemps que les applications servent l'activité et que vous gardez la connaissance pour les exploiter. Le matériel et le système d'exploitation sont renouvelés régulièrement, et l'âge n'est donc pas la limite. La limite, c'est l'expertise. Préparez chaque passation des années à l'avance, car un ingénieur système a besoin de cinq à six ans pour devenir pleinement compétent.
Faut-il quitter un mainframe legacy ?
Décidez charge de travail par charge de travail. Les charges à la demande variable et au dossier d'investissement clair conviennent au cloud. Les gros volumes de transactions et de batch restent en général sur le mainframe. 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 (Gartner).
