Les mainframes sont accompagnés depuis des décennies de prédictions annonçant leur disparition, mais une nouveauté apparemment mineure de Linux 7.2 raconte une histoire différente. L’architecture s390 a intégré le support de Rust dans le noyau, permettant ainsi à l’une des initiatives les plus récentes de Linux pour développer des composants bas niveau avec une sécurité de mémoire renforcée d’être également portée sur l’environnement sur lequel fonctionnent les systèmes IBM Z actuels.

Les clés de la modernisation du mainframe en 30 secondes

• Linux 7.2 intègre le support de Rust pour s390, l’architecture utilisée par les IBM Z modernes.
• Le nom s390 provient d’une famille de mainframes d’IBM des années 90, mais Linux continue de l’utiliser pour l’architecture actuelle.
• Une étude d’Accenture, citée par AWS, indique que 90 % des organisations interrogées poursuivent des démarches de modernisation vers le cloud, bien que seulement 19,5 % des charges de travail aient été transférées.
• AWS, IBM et Google utilisent déjà l’IA pour analyser, documenter et transformer les applications héritées.
• La tendance va vers des modernisations progressives où comprendre le logiciel existant est aussi essentiel que le migrer.

Le nom peut sembler confus. IBM System/390 est apparu en 1990, et cette famille de machines a ensuite laissé place à la zSeries et aux IBM Z actuels. Cependant, Linux continue d’appeler s390 cette architecture.

C’est pourquoi l’arrivée de Rust revêt un intérêt plus grand qu’il n’y paraît.

Le travail intégré dans le noyau configure s390 comme une architecture 64 bits capable d’exploiter l’infrastructure Rust de Linux, en intégrant les éléments spécifiques nécessaires pour la gestion des alertes et erreurs, branches statiques et la génération de bindings. Ce support a été développé par Jan Polensky d’IBM et intégré lors des modifications correspondant à Linux 7.2.

Cela ne signifie pas que Linux sur IBM Z sera réécrit en Rust, ni que l’immense volume de code en C existant sera abandonné. L’important, c’est que les nouveaux composants du noyau rédigés en Rust peuvent désormais commencer à prendre en charge cette architecture.

Rust progresse dans Linux depuis plusieurs années précisément parce qu’il permet d’éviter, par conception, certains types d’erreurs liés à la gestion de la mémoire. Son extension à s390 montre que le mainframe reste un élément intégré dans l’évolution technique du noyau, et non seulement une plateforme héritée à maintenir jusqu’à sa fin de vie.

90 % veulent moderniser, mais seulement 19,5 % des charges ont été transférées

La paradoxe du mainframe apparaît en observant ce qui se passe dans les grandes entreprises.

Une étude d’Accenture de 2025, réalisée auprès de 1000 dirigeants et publiée en juillet 2026 dans une analyse conjointe avec AWS, montre que 90 % des organisations utilisant des mainframes ont lancé des initiatives de migration vers le cloud.

Cependant, seulement 19,5 % de leurs charges de travail ont terminé cette transition.

La différence entre ces deux pourcentages illustre bien le problème.

Décider qu’une application doit être modernisée est relativement simple. En connaître véritablement le fonctionnement après 30 ou 40 ans de modifications peut être beaucoup plus complexe.

Une banque, une compagnie d’assurance ou une administration peuvent disposer d’applications COBOL opérant depuis des décennies, accumulant changements et évolutions. Une partie de leur logique est documentée, mais une autre réside exclusivement dans le code lui-même, dans des traitements batch, du JCL, des procédures, des bases de données ou des dépendances avec d’autres systèmes.

Même une application apparemment simple peut contenir des règles métier introduites il y a longtemps, dont l’auteur n’est plus dans l’organisation.

Recréer un logiciel sans comprendre ces dépendances présente un risque évident : le nouveau programme peut sembler correct d’un point de vue technique tout en se comportant différemment dans certains cas que le système original, appris à gérer au fil des décennies.

C’est là que l’intelligence artificielle trouve l’un de ses usages les plus discrets mais potentiellement les plus pratiques.

AWS, IBM et Google déploient l’IA pour le code hérité

Les principaux fournisseurs technologiques disposent déjà d’outils spécialement conçus pour ce défi.

AWS Transform for Mainframe a été lancé en disponibilité générale en mai 2025. Ce service utilise l’IA pour intervenir à différentes étapes d’une modernisation, depuis l’analyse et la planification initiale jusqu’à la génération de documentation et la refonte du code. AWS a également ajouté des outils pour analyser les dépendances et interroger la documentation générée à partir du code via l’IA.

IBM watsonx Code Assistant for Z suit une démarche similaire au sein de l’écosystème IBM. Il peut analyser des applications, expliquer du code en langage naturel, documenter la logique métier et participer à des processus de refactorisation. Parmi ses fonctionnalités, on trouve la génération de services Java à partir de COBOL et des tests JUnit pour vérifier l’équivalence sémantique entre les deux.

Google Cloud Mainframe Modernization exploite des modèles Gemini et des agents spécialisés pour l’ingénierie inverse, l’évaluation et la transformation des applications. Son Mainframe Assessment Tool peut extraire les règles d’affaires, documenter des applications, identifier des dépendances et générer des cas de test.

Google dispose aussi de Dual Run, un outil permettant d’exécuter en parallèle le trafic de production sur le mainframe et sur l’application modernisée, afin de comparer leurs résultats avant de procéder à la transition définitive.

Un point commun à toutes ces solutions : avant de transformer le code, il faut le comprendre.

L’IA peut accélérer précisément l’une des phases les plus exigeantes dans ce type de projets. Elle aide à explorer de vastes bases de code, générer de la documentation, reconstruire des dépendances, expliquer des programmes écrits dans des langages moins maîtrisés, et à extraire des règles métier à vérifier ensuite.

Ce n’est pas une solution magique pour convertir automatiquement plusieurs millions de lignes en COBOL en une architecture de microservices prête pour la production.

La modernisation peut aussi signifier conserver certains éléments du mainframe

Pendant longtemps, la modernisation a été associée à la migration : déménager une application du mainframe vers des serveurs distribués ou dans le cloud.

Mais les stratégies actuelles offrent davantage de possibilités.

Une organisation peut conserver certains processus sur IBM Z, exposer des fonctionnalités via des API, séparer des composants, déplacer des données précises, transférer certaines applications, ou en retirer d’autres. Il est aussi possible d’exécuter provisoirement l’ancien et le nouveau système en parallèle, jusqu’à ce que la preuve que les deux comportent de manière identique soit suffisamment établie.

Cette approche progressive réduit l’un des plus grands risques d’une migration majeure : tenter de remplacer en une seule fois un système qui a accumulé des décennies de logique métier.

La présence de Rust dans s390 vient renforcer cette vision. Tandis qu’une partie de l’industrie développe des outils d’intelligence artificielle pour comprendre et transformer les applications héritées, la communauté Linux continue d’intégrer de nouvelles technologies à l’architecture utilisée par les mainframes modernes.

Ce ne sont pas des démarches contradictoires.

Les organisations peuvent moderniser leurs applications sans abandonner immédiatement la plateforme sur laquelle elles fonctionnent. Elles peuvent aussi faire évoluer leur façon de développer le logiciel pour le mainframe.

Peut-être que c’est cette hybridation qui explique pourquoi la disparition du mainframe est annoncée depuis si longtemps sans jamais vraiment se produire. Beaucoup de ces systèmes hébergent des applications difficiles à remplacer, mais cela ne signifie pas que tout ce qui les entoure doit rester inchangé.

La question devient moins binaire : il ne s’agit plus simplement de conserver ou d’éteindre le mainframe. Moderniser, c’est aussi découvrir ce qui doit rester, ce qui peut être désolidarisé, ce qu’il est pertinent de transformer, et ce qui peut finalement être retiré. L’IA ne supprime pas ce travail, mais elle peut rendre le processus de compréhension du logiciel, étape préalable à toute décision, beaucoup plus gérable.

Questions fréquentes

Linux 7.2 intègre-t-il le support de Rust pour les mainframes ?

Oui. Parmi les changements apportés par Linux 7.2 figure l’activation de Rust pour l’architecture s390, utilisée par Linux sur les systèmes IBM Z modernes.

Pourquoi Linux continue-t-il d’appeler s390 l’architecture IBM Z ?

Le nom provient d’IBM System/390, mais Linux conserve la dénomination s390 pour l’architecture qui a évolué pour devenir les systèmes IBM Z actuels.

L’intelligence artificielle peut-elle transformer automatiquement du COBOL en applications modernes ?

Il existe des outils capables d’analyser, d’expliquer et de transformer le code, mais une modernisation à l’échelle de l’entreprise doit également valider dépendances, règles métier, comportement et équivalence fonctionnelle. IBM et Google, par exemple, proposent des outils intégrant la génération de tests et des mécanismes de validation.

Les entreprises abandonnent-elles rapidement leurs mainframes ?

Les données disponibles suggèrent un processus beaucoup plus progressif. La étude d’Accenture citée par AWS indique que 90 % des organisations développent des initiatives de migration vers le cloud, mais seulement 19,5 % des charges ont été effectivement transférées.