Newtech
Z + Arm : le processeur mutant d’IBM qui va terrifier les géants du Cloud… et piéger les DSI
Par Laurent Delattre, publié le 26 août 2026
En dévoilant un futur processeur capable d’exécuter nativement les jeux d’instructions IBM Z et Arm sur les mêmes cœurs, IBM ne se contente pas d’ajouter une architecture en vogue à ses mainframes. Il tente de supprimer l’une des dernières frontières qui séparent encore le SI historique du reste de l’informatique moderne. Pour les DSI, la promesse est considérable : rapprocher applications cloud-native, outils de cybersécurité et piles IA des données critiques sans les porter sur l’ancestrale architecture s390x. Mais cette ouverture pourrait aussi rendre le mainframe… encore plus difficile à quitter.
Le mainframe a un problème d’image. Mais ce n’est probablement plus son principal problème technique. Depuis des années, IBM démontre que ses Z n’ont rien de machines figées dans les années 1970 : chiffrement généralisé, chiffrement post-quantique, Linux, Kubernetes, accélération matérielle de l’IA des processeurs Telum, accélérateurs Spyre, partitionnement extrêmement sophistiqué…
Le problème est ailleurs. Pour faire fonctionner sur IBM Z un logiciel moderne qui n’existe que pour x86 ou Arm, encore faut-il que son éditeur accepte de le compiler, le tester, le certifier et le maintenir pour l’architecture s390x. C’est une sorte de taxe invisible du mainframe. Une taxe qui ne porte pas forcément sur les grandes applications métier mais sur tout ce qui s’épanoui autour : agents de sécurité, observabilité, middleware, bases de données, outils DevOps, runtimes IA, composants open source ou simples images de conteneurs.
IBM a confirmé à Hot Chips 2026 une façon assez radicale de supprimer cette taxe : apprendre au mainframe à parler le langage machine des applications Cloud natives et IA.
Un processeur véritablement bilingue
Le futur processeur, encore sans nom, sera gravé en 2 nm et comportera onze cœurs fonctionnant à plus de 5,7 GHz. Il intégrera également accélération IA, traitements cryptographiques, compression, capacités dédiées aux entrées-sorties et une imposante hiérarchie de cache.
Mais sa caractéristique essentielle réside dans une nouvelle architecture duale combinant « Z » et « Arm ».
Plutôt que de placer des quelques cœurs Arm à côté des cœurs Z traditionnels, IBM a choisi d’enrichir chacun des onze cœurs de ce nouveau processeur de sorte qu’ils puissent nativement exécuter les instructions Z et les instructions Arm. Il ne s’agit ni d’émulation ni de traduction binaire. Le processeur change de mode lorsque l’hyperviseur lui confie une machine virtuelle utilisant l’une ou l’autre architecture. C’est à la fois sacrément malin et un petit exploit technologique. IBM évoque une commutation à l’échelle de la nanoseconde, suffisamment courte pour que son coût soit, selon ses ingénieurs, pratiquement imperceptible à l’échelle d’une VM.
Il est important néanmoins de bien comprendre qu’un même cœur ne mélange pas en permanence instructions Arm et Z dans un même programme. Dans le scénario présenté, z/OS reste dans sa partition tandis que des environnements KVM ou OpenShift Virtualization peuvent accueillir côte à côte du Linux pour Z et du Linux Arm. Le cœur exécute alternativement leurs instructions selon les workloads qui lui sont présentés.
L’annonce est technologiquement spectaculaire mais elle change aussi profondément la donne pour les DSI qui appuient encore lourdement leur héritage applicatif sur les mainframes.
IBM inverse ainsi la dette technique
Pendant des décennies, la modernisation du mainframe a consisté à rapprocher progressivement le monde moderne du Z.
L’arrivée de Linux sur l’architecture Z a ouvert une première brèche. Java une autre. Puis les conteneurs, Kubernetes et OpenShift, tous « z-ifiés », ont considérablement réduit l’écart culturel et opérationnel avec les plateformes distribuées.
La barrière du processeur subsistait pourtant. Notamment parce que les images de conteneurs restent liées à leur architecture. Une application disponible en arm64 ou amd64 n’est pas automatiquement disponible en s390x. IBM et Red Hat savent déjà gérer des environnements OpenShift multi-architectures, mais chaque binaire doit encore exister pour la cible sur laquelle il s’exécute.
Avec son futur processeur, IBM change de méthode. Les DSI ne vont plus se demander « Comment porter cette application moderne sur le mainframe ? ». Ils ne vont plus, non plus, se demander « Comment porter cette application mainframe sur une architecture cloud ? ». Ils sauront faire fonctionner l’univers applicatif Arm (Cloud, IA, etc.) sur le mainframe ! IBM affirme en effet viser la compatibilité binaire avec les logiciels Linux Arm existants. À terme, un logiciel certifié pour Red Hat Enterprise Linux sur Arm pourrait donc théoriquement tourner sur IBM Z sans recompilation spécifique pour s390x.
Pour un DSI, cela peut représenter beaucoup plus qu’un gain de temps de développement. C’est potentiellement la disparition de centaines de petites exceptions qui rendent aujourd’hui certains projets LinuxONE difficiles à justifier.
Le mainframe ne veut plus seulement héberger le cœur du SI
Le scénario qui intéresse IBM est assez limpide. Prenons une banque. Son système transactionnel et ses données critiques résident encore sur Z pour plus de 80% des transactions. Mais ses outils d’observabilité, une partie de son dispositif antifraude, ses services IA, ses bases vectorielles ou certains microservices ont été installés ailleurs parce que les composants nécessaires n’existaient tout simplement pas sur s390x.
Il en résulte une complexité architecturale liée à la multiplication des infrastructures, des flux réseau, des copies de données et des frontières de sécurité.
Avec Arm directement dans Z, IBM espère pouvoir faire revenir ces workloads autour de la donnée, sans réinventer la roue. La modernisation pourrait alors ne plus signifier « sortir les données du mainframe pour construire quelque chose de moderne autour », mais « rapprocher le moderne de là où se trouvent déjà les données ».
L’équation devient particulièrement séduisante pour les DSI lorsque l’on parle d’IA. Les accélérateurs intégrés descendants de Telum restent adaptés aux inférences ultra-rapides intégrées à une transaction – typiquement la détection de fraude –, tandis qu’IBM prépare également une nouvelle génération de son accélérateur Spyre pour des modèles beaucoup plus lourds. Autour de ces accélérateurs, l’écosystème Arm peut apporter les serveurs d’inférence, frameworks, runtimes agentiques, bases vectorielles et bibliothèques dont les versions Arm arrivent généralement bien avant leurs éventuelles déclinaisons s390x.
Autrement dit, IBM ne cherche pas seulement à faire entrer Arm dans le mainframe, il cherche surtout et avant tout à faire entrer l’écosystème logiciel de l’IA moderne dans son périmètre mainframe.
Une étrange forme de « reverse cloud »
Certains voient même déjà dans cette annonce un retournement assez savoureux de l’histoire du cloud. Pendant quinze ans, la stratégie dominante consistait à rapprocher progressivement les applications historiques du modèle technologique des hyperscalers. Cette fois, IBM emprunte exactement le chemin inverse.
Arm est devenu une architecture majeure du cloud, adoptée notamment par AWS, Google et Microsoft et omniprésente dans les nouvelles infrastructures IA. Arm revendique désormais un écosystème dépassant les 22 millions de développeurs… qu’IBM récupère en un claquement de doigt pour l’amener dans le mainframe.
Le Z pourrait donc devenir un curieux point de convergence entre deux extrêmes de l’informatique : le monde hyper-régulé, extrêmement consolidé et transactionnel du mainframe, et celui beaucoup plus mouvant du cloud-native et de l’IA.
Pour certaines entreprises, la perspective mérite au minimum d’être étudiée.
Mais « il tourne » ne signifie pas « il est supporté »
L’annonce est enthousiasmante, à n’en pas douter, mais il faut aussi refroidir l’enthousiasme. Une architecture capable d’exécuter un binaire Arm ne suffira pas à rendre magiquement l’intégralité du catalogue logiciel Arm exploitable en production.
Il faudra que les distributions Linux soient certifiées. Que les éditeurs déclarent officiellement leurs produits supportés. Que leurs modèles de licences reconnaissent cette nouvelle configuration. Que leurs agents de sécurité et leurs mécanismes de haute disponibilité soient validés. Que les performances soient documentées. Sur tous ces points, IBM reste encore largement silencieux.
Matt Kimball, analyste chez Moor Insights & Strategy, résume parfaitement le problème : « la capacité matérielle et le support d’un éditeur sont deux choses différentes. Et les entreprises achètent surtout la seconde ». Le coût logiciel pourrait ainsi notamment réserver quelques surprises.
Que signifie une licence « par cœur » lorsqu’un cœur physique peut alternativement exécuter des workloads Z et Arm ? Comment Oracle, les spécialistes de l’observabilité, les éditeurs de sécurité ou les fournisseurs de middleware comptabiliseront-ils cette capacité ? Le futur processeur d’IBM risque de mettre certains vieux modèles de licensing face à une architecture qu’ils n’avaient absolument pas prévue.
Pour les DSI, ce sujet pourrait peser davantage dans les business cases que les performances du processeur lui-même.
Une ouverture qui… renforce le verrouillage
Un autre paradoxe mérite également d’être pointé du doigt, n’en déplaise à IBM. L’éditeur présente Arm comme une ouverture. Et techniquement, c’en est incontestablement une. Un logiciel compilé pour une architecture largement répandue devient plus portable qu’un logiciel spécifiquement adapté à s390x. Pour une DSI, cela réduit une partie du verrouillage technologique.
Pour autant, cette même facilité pourrait simultanément renforcer… le verrouillage autour du mainframe. Car une fois les applications Arm rapprochées du système transactionnel, les données centralisées sur Z, l’IA exécutée localement et la sécurité intégrée à cet ensemble, l’intérêt économique et opérationnel de déplacer ces workloads ailleurs devrait mécaniquement diminuer.
Avec sa nouvelle architecture duale, IBM réduit le lock-in logiciel mais augmente l’attractivité du lock-in infrastructurel. Ce n’est pas nécessairement une mauvaise affaire pour les DSI et leurs entreprises. Une plateforme extrêmement intégrée peut être préférable à une architecture distribuée devenue incontrôlable. Mais ce choix devra être conscient et raisonné. Portabilité du code ne signifie pas automatiquement réversibilité du système.
Plus ouvert… donc plus exposé ?
Enfin, dernier bémol, faire bénéficier les applications Arm des mécanismes de fiabilité, de chiffrement et de détection de panne d’IBM Z ne transforme pas automatiquement les millions de composants du monde Linux Arm en logiciels « mainframe grade ».
L’un des avantages historiques du Z vient précisément de son environnement fortement contrôlé et peu commun. En ouvrant la porte à un écosystème logiciel beaucoup plus vaste, IBM augmente aussi mécaniquement le nombre de composants, de dépendances, d’images de conteneurs et donc de vulnérabilités potentielles susceptibles d’atterrir dans l’environnement.
Pour les RSSI et les DSI, il faudra plus que jamais distinguer la sécurité de la plateforme de la sécurité de ce que l’on décide d’y installer. Le futur Z pourrait être extraordinairement robuste tout en exécutant un conteneur vulnérable téléchargé depuis un registre mal gouverné.
Bienvenue dans un cloud-native revu à la sauce mainframe.
Bien sûr pour les DSI, il est encore trop tôt pour chercher à bâtir dès aujourd’hui des business cases précis. Le futur processeur n’a pour l’instant ni date commerciale officielle ni prix. IBM parle des prochaines générations de Z et LinuxONE, et l’entreprise prévient elle-même que cette feuille de route peut encore évoluer.
En revanche, l’annonce est suffisamment importante pour modifier certaines réflexions d’architecture et commencer à cartographier les applications Arm qui auraient du sens à basculer sur une exécution mainframe.
Finalement, le plus intéressant dans ce processeur n’est finalement pas qu’il sache exécuter deux jeux d’instructions. C’est plutôt qu’il pourrait faire disparaître une frontière intellectuelle vieille de plusieurs décennies. On opposait encore volontiers le mainframe, d’un côté, et l’informatique moderne, de l’autre. Avec son architecture duale, IBM veut rendre cette distinction beaucoup moins pertinente.
Et paradoxalement, la plus grande innovation du prochain mainframe pourrait précisément être de faire en sorte que les développeurs aient de moins en moins besoin de savoir que leurs apps s’exécuteront sur un mainframe.
À LIRE AUSSI :
À LIRE AUSSI :
À LIRE AUSSI :
