Le coût de l’IA sur le mainframe est aujourd’hui le poste qui augmente le plus vite dans la plupart des budgets IBM Z. Les charges de travail d’IA sur z/OS sont passées du pilote à la production : le PDG d’IBM a confirmé que les clients qui utilisent IBM watsonx Code Assistant for Z augmentent leur capacité MIPS trois fois plus vite que les autres.
Si vous êtes responsable mainframe, la vraie question est de savoir comment l’IA va changer vos coûts dans votre modèle de tarification IBM actuel, et si vous devez agir dès maintenant. Parlons-en.
L’IA sur le mainframe est déjà là
En un an, la question a changé. Il ne s’agit plus de savoir si les entreprises doivent déployer l’IA générative dans leurs environnements z/OS, mais comment gérer au mieux la capacité et le coût des charges de travail d’IA sur le mainframe.
Dans son enquête mainframe de septembre 2025, BMC indique que 65 % des organisations mainframe utilisent déjà l’IA générative dans leur environnement z/OS , pour l’analyse de code, la documentation, la détection de fraude, les charges de travail liées à l’expérience client ou l’automatisation des opérations. Autrement dit, la majorité du marché a déjà adopté l’IA générative.
Source : BMC Mainframe Survey 2025
La question est désormais : comment les responsables mainframe doivent-ils prévoir et budgéter les coûts et la capacité à mesure que l’adoption de l’IA progresse ?
Une capacité MIPS qui croît 3 fois plus vite
La déclaration la plus lourde de conséquences sur l’IA et le mainframe en 2026 est venue d’Arvind Krishna, PDG d’IBM, lors de la conférence sur les résultats du premier trimestre d’IBM, le 22 avril 2026 :
"Les clients qui ont déployé watsonx Code Assistant for Z augmentent leur capacité MIPS trois fois plus vite que ceux qui ne l’ont pas fait."
— Arvind Krishna, PDG d’IBM, conférence sur les résultats du 1er trimestre 2026
Le directeur financier Jim Kavanaugh a repris le même chiffre plus tard dans la même conférence, en parlant d’un « écart de 3x sur la croissance et la capacité ».
Cela ne veut pas dire que les charges de travail d’IA consomment plus de MIPS en valeur absolue. Cela veut dire que leur trajectoire de croissance est trois fois plus rapide que celle du reste du parc IBM Z installé.
Ce rythme de croissance se traduit en coûts de façon différente selon votre modèle de tarification IBM. Sous AWLC, où le coût logiciel suit le pic de facturation mensuel, une capacité qui croît 3 fois plus vite donne une facture mensuelle qui augmente chaque mois. Sous TFP, la consommation au-dessus de la baseline qui s’accumule sur les douze mois du contrat est régularisée en fin d’année. Elle se traduit aussi par une baseline TFP plus haute pour le contrat de l’année suivante, ce qui vous enferme dans un plancher de coûts plus élevé pour la période suivante.
Cette hausse des coûts se voit déjà dans les chiffres d’IBM : IBM annonce quatre trimestres consécutifs de croissance de plus de 100 % des nouveaux MIPS livrés sur la plateforme z17, la plus forte dynamique matérielle du mainframe depuis des années. La direction d’IBM relie explicitement cette croissance à l’adoption des charges de travail d’IA.
Source : IBM 1Q26 Earnings Call Transcript
Un troisième type de capacité de calcul arrive sur z/OS, et il est structurel
Lors de la même conférence, Arvind Krishna a souligné un changement structurel :
"L’IA ajoute un troisième type de capacité de calcul au mainframe."
— Arvind Krishna, PDG d’IBM
Historiquement, le mainframe avait deux types de capacité de calcul : les MIPS classiques (charges de travail transactionnelles) et les MIPS Linux (charges de travail Linux, plus diffuses). L’IA ajoute maintenant ce qu’il a appelé un « troisième type » de capacité de calcul.
L’exemple qu’il a donné parlera tout de suite à quiconque gère des charges de travail mainframe dans la banque ou l’assurance. Aujourd’hui, la détection de fraude sur carte bancaire applique quelques règles à un échantillon de transactions. Avec une capacité d’inférence suffisante sur la plateforme, les clients peuvent appliquer un modèle de 20 à 30 milliards de paramètres à chaque transaction, en quelques millisecondes. Selon IBM, un système z17 entièrement équipé peut traiter environ 450 milliards d’inférences par jour, sur le mainframe lui-même.
Ce que les responsables mainframe doivent comprendre, c’est qu’il ne s’agit pas d’une hausse ponctuelle. Les charges de travail d’IA ne remplacent pas la consommation mainframe existante : elles s’y ajoutent. IBM positionne explicitement le mainframe comme une destination pour l’inférence d’IA, et non comme une plateforme que les clients devraient quitter. Ce positionnement a des conséquences directes sur la trajectoire des coûts.
Ne comptez pas sur l’IA comme porte de sortie
À ce stade, une question se pose : si l’IA rend le mainframe plus cher, peut-elle aussi rendre enfin faisable la migration vers le cloud ?
En 2025 et 2026, de nombreux éditeurs et cabinets de conseil ont affirmé que la conversion de code par l’IA générative, la documentation automatisée et des délais raccourcis avaient changé l’économie de la sortie du mainframe. En avril 2026, Gartner a publié une note de recherche intitulée “Too Big to Fail: Why Mainframe Exit Projects Are Likely to Fail in the Age of Generative AI.” Sa prévision centrale : plus de 70 % des projets de sortie du mainframe lancés en 2026 n’apporteront pas les bénéfices attendus parce qu’ils surestiment les capacités de l’IA générative. Gartner en donne trois raisons :
- L’écart entre le discours et la réalité. Les promesses des éditeurs d’IA générative sur la conversion automatique de code dépassent ce qui est réellement livré, en particulier pour les langages non standard (Assembler, Easytrieve, CA Ideal, PL/1) et la logique métier non documentée, qui se trouvent à la périphérie de la plupart des applications mainframe.
- L’équivalence de performance et de débit n’est pas garantie. Le code converti par l’IA peut passer les tests fonctionnels et ne pas atteindre pour autant les garanties de performance, de débit et de résilience de son équivalent mainframe. Les écarts n’apparaissent en général que sous la charge de production.
- La complexité des données empêche une conversion en bloc. Dans la plupart des grandes entreprises, le volume et l’interdépendance des données transactionnelles du mainframe rendent une migration automatisée en une seule passe impossible, physiquement et financièrement.
Gartner prévoit aussi que d’ici 2030, 75 % des éditeurs présents sur le marché de la « sortie du mainframe » auront changé de modèle économique ou auront disparu. C’est un signe fort que la vague actuelle de migrations pilotées par l’IA a peu de chances de donner naissance à un secteur stable, capable d’accompagner les clients dans des programmes pluriannuels.
Avec du recul, deux choses apparaissent. L’IA rend les charges de travail mainframe plus chères. Dans le même temps, elle ne rend pas la sortie du mainframe moins chère ni plus sûre. La solution pratique est de maîtriser la courbe des coûts là où les charges de travail se trouvent réellement.
Source : AI-powered Mainframe Exits Are a Bubble Set to Pop — The Register
Où agir
L’IA fait monter la consommation mainframe, mais les mécanismes de coût, et donc la bonne façon d’agir, diffèrent nettement entre AWLC et TFP. Chaque modèle de tarification demande sa propre approche.
Pour les clients AWLC — Zetaly Automated Capacity (ZAC)
Sous AWLC, les MLC (frais de licence mensuels) sont calculés sur le pic de la moyenne glissante sur 4 heures (R4HA) de consommation de MSU de chaque mois : une seule période de forte demande fixe le coût du mois entier. La capacité des charges de travail d’IA, en pleine accélération, se traduit directement par des pics R4HA en hausse. C’est ainsi que le coût de l’IA sous AWLC arrive sur votre facture mensuelle. ZAC gère ce pic de facturation en temps réel. ZAC surveille en continu la consommation de MSU sur les LPAR (partitions logiques) et ajuste les limites de capacité définie et les réglages de soft capping selon la priorité des charges de travail et l’exposition de facturation du moment, pour éviter les pics R4HA. Cet ajustement suit la priorité des charges de travail : le travail le moins prioritaire est ajusté en premier, et les transactions critiques et les charges de travail soumises à des SLA ne sont jamais touchées. Sur plus de 30 déploiements en entreprise, les clients de ZAC obtiennent une baisse de 5 à 20 % de leurs MLC, sans aucun changement de leurs applications. Face à une IA en forte croissance dans un environnement AWLC, ZAC garde les coûts sous contrôle.
Pour les clients TFP — Zetaly Data Platform (ZDP) et ZSI
Sous TFP, les mécanismes de coût sont différents, et les coûts de l’IA s’additionnent de deux façons. Votre baseline TFP est calculée à partir des douze derniers mois de données SCRT. Toute consommation au-dessus de cette baseline s’accumule sur les douze mois du contrat et est régularisée en fin d’année. C’est le premier élément. Le second est structurel : la baseline du contrat de l’année suivante est calculée à partir de la consommation réelle de MSU de l’année en cours. Le dépassement dû à l’IA devient donc le plancher de coûts de la période suivante. La croissance des MSU liée à l’IA pèse deux fois sur la facture : une fois en régularisation de fin d’année, et une fois en hausse durable de la baseline.
Le problème pratique, pour tout responsable mainframe sous TFP, c’est que sans visibilité au niveau des charges de travail, vous ne voyez pas quelles charges de travail font dépasser la baseline : l’IA ou l’activité courante. Et on ne peut pas gérer ce que l’on ne voit pas. Les outils de surveillance natifs d’IBM apportent une partie de l’information, mais ils consomment eux-mêmes une quantité notable de MSU, qui s’ajoute à la baseline même que vous cherchez à maîtriser.
ZDP résout ce problème de visibilité au niveau des données. ZDP collecte en continu et quasi en temps réel les données d’exploitation du mainframe (enregistrements SMF, journaux système, DCOLLECT et journaux IMS) en utilisant moins de 0,2 % des ressources du mainframe. ZSI le résout au niveau de la lecture : ZSI produit des tableaux de bord et des rapports à partir des données ZDP, dont des rapports organisés par métier. Des publics non spécialistes dans l’entreprise (la finance, les responsables métier, voire le COMEX) peuvent ainsi lire la consommation mainframe et agir, sans qu’un spécialiste mainframe doive la leur traduire. Pour les clients TFP qui absorbent des charges d’IA croissantes, ZDP et ZSI font la différence entre découvrir le dépassement de fin d’année après coup et piloter la trajectoire qui y mène, au fil de l’eau.
Ce que vous pouvez faire pour commencer à réduire les coûts
Ce que « maîtriser la courbe des coûts de l’IA » veut dire concrètement dépend de votre modèle de tarification IBM. Si votre environnement est sous AWLC :
- Modélisez la trajectoire de vos coûts AWLC. Prenez votre baseline de consommation AWLC actuelle et appliquez-lui la courbe de croissance de capacité de 3x qu’IBM décrit aujourd’hui pour les clients qui utilisent watsonx (le volet capacité du coût de watsonx Code Assistant). Le coût obtenu sur dix-huit à vingt-quatre mois est la discussion à avoir avec la direction financière avant la montée en charge de l’IA.
- Demandez une simulation ZAC. Zetaly propose une simulation gratuite qui modélise votre potentiel d’optimisation à partir de votre baseline réelle : vos données, pas une estimation d’éditeur. C’est le meilleur moyen de voir comment maîtriser la hausse des coûts de l’IA dans votre propre environnement.
Si votre environnement est sous TFP, ou si IBM vous pousse vers le TFP :
- Obtenez tôt une visibilité sur la consommation IA sous TFP, charge de travail par charge de travail. Sous TFP, les charges de travail d’IA tendent à pousser la consommation au-dessus de la baseline sans prévenir. Vous devez savoir quelles charges de travail causent le dépassement, pour réduire la facture de fin d’année et éviter de figer une baseline gonflée pour l’année suivante.
- Choisissez votre approche d’observabilité en connaissance de cause. Les outils de surveillance natifs d’IBM ont une surcharge importante, qui entre directement dans le calcul de votre baseline TFP. ZDP collecte les mêmes données d’exploitation (SMF, DCOLLECT, journaux IMS) en utilisant moins de 0,2 % des ressources : la surveillance ne gonfle pas la baseline même que vous cherchez à maîtriser. ZSI met ensuite les données à disposition de la finance et des responsables métier, sous la forme dont ils ont réellement besoin.
L’IA devient un outil puissant sur le mainframe : elle vous permet d’en faire plus, et plus vite, que jamais. La discussion sur l’IA que les responsables mainframe doivent avoir en 2026 porte sur la trajectoire des coûts et la visibilité opérationnelle. C’est ce qui leur permettra de tirer le meilleur de cette transition tout en gardant les coûts sous contrôle.
Questions fréquentes
Qu’est-ce que le coût de l’IA sur mainframe, et comment l’IA fait-elle évoluer les coûts du mainframe IBM ?
En 2026, les charges de travail d’IA font monter la consommation mainframe plus vite que toute autre catégorie. Selon l’enquête mainframe 2025 de BMC, 65 % des organisations mainframe utilisent déjà l’IA générative dans leur environnement z/OS. Lors de la conférence sur les résultats du premier trimestre 2026, le PDG d’IBM a confirmé que les clients qui utilisent watsonx Code Assistant for Z augmentent leur capacité MIPS trois fois plus vite que les clients mainframe qui ne l’utilisent pas. L’impact sur les coûts dépend du modèle de tarification IBM. Sous AWLC, une croissance plus rapide des MIPS fait monter directement le pic de facturation mensuel en moyenne glissante sur 4 heures. Sous TFP, les charges de travail d’IA ajoutent une consommation de MSU au-dessus de la baseline du contrat. Cette consommation s’accumule sur les 12 mois et relève la baseline de l’année suivante.
Pourquoi la capacité MIPS du mainframe croît-elle trois fois plus vite chez les clients qui utilisent l’IA ?
Le 22 avril 2026, Arvind Krishna, PDG d’IBM, a déclaré que « les clients qui ont déployé watsonx Code Assistant for Z augmentent leur capacité MIPS trois fois plus vite que ceux qui ne l’ont pas fait ». La cause est structurelle : les charges de travail d’IA forment un troisième type de capacité de calcul sur le mainframe, à côté des MIPS transactionnels classiques et des MIPS Linux, et elles s’ajoutent aux charges existantes. Un changement typique lié à l’IA consiste à appliquer des modèles de 20 à 30 milliards de paramètres à chaque transaction, en ligne. Par exemple, une détection de fraude sur la totalité des transactions au lieu d’un échantillonnage statistique. Ces charges de travail n’existaient pas sur le mainframe il y a douze mois.
Les outils à base d’IA m’aideront-ils à quitter le mainframe ?
Probablement pas. En avril 2026, Gartner a publié une note de recherche intitulée « Too Big to Fail: Why Mainframe Exit Projects Are Likely to Fail in the Age of Generative AI ». Elle prévoit que plus de 70 % des projets de sortie du mainframe pilotés par l’IA et lancés en 2026 n’apporteront pas les bénéfices attendus. Trois raisons structurelles : les outils de conversion de code par l’IA générative n’ont pas résolu le problème des « composants exotiques » (Assembler, Easytrieve, CA Ideal, PL/1, logique métier non documentée) ; l’équivalence de performance et de débit entre le code converti et l’original mainframe n’est pas garantie et n’apparaît que sous la charge de production ; et le volume et l’interdépendance des données transactionnelles du mainframe rendent impossible une migration automatisée en bloc. Gartner prévoit aussi que 75 % des éditeurs présents sur le marché de la « sortie du mainframe » auront changé de modèle ou disparu d’ici 2030.
En quoi l’impact du coût de l’IA diffère-t-il entre clients AWLC et TFP ?
Sous AWLC, le coût logiciel est calculé sur le pic de la moyenne glissante sur 4 heures (R4HA) de consommation de MSU de chaque mois. Une croissance de capacité plus rapide, due à l’IA, fait monter directement ce pic de facturation mensuel, chaque mois. Sous TFP, les mécanismes de coût sont différents : toute consommation au-dessus de la baseline du contrat s’accumule sur les 12 mois, est régularisée en fin d’année, puis entre dans le calcul de la baseline de l’année suivante. La même croissance des charges d’IA produit donc une hausse mensuelle récurrente sous AWLC, et une régularisation de fin d’année plus une hausse durable de la baseline sous TFP. Les mécanismes diffèrent, mais l’ampleur de l’impact est comparable.
Comment maîtriser la hausse des coûts mainframe liée à l’IA ?
La bonne façon d’agir dépend du modèle de tarification IBM. Les clients AWLC peuvent réduire le pic de facturation R4HA avec des outils de gestion automatisée de la capacité. Zetaly Automated Capacity (ZAC) obtient une baisse de 5 à 20 % des MLC sur plus de 30 déploiements en entreprise, en gérant en temps réel la capacité définie des LPAR. Les clients TFP ont besoin d’une visibilité au niveau des charges de travail pour repérer celles qui font dépasser la baseline et agir avant la régularisation de fin d’année. Zetaly Data Platform (ZDP) fournit cette visibilité sous TFP en utilisant moins de 0,2 % des ressources du mainframe, et Zetaly Service Intelligence (ZSI) produit des tableaux de bord organisés par métier. Visibilité et gestion active sont indispensables dans les deux modèles de tarification.
Que sont les « MIPS IA » sur le mainframe IBM ?
« AI MIPS » (MIPS IA) est le terme employé par Arvind Krishna, PDG d’IBM, lors de la conférence sur les résultats du premier trimestre 2026, pour décrire une troisième catégorie de capacité de calcul mainframe, à côté des MIPS transactionnels classiques et des MIPS Linux. Les MIPS IA correspondent aux charges d’inférence qui tournent directement sur le mainframe : par exemple, une détection de fraude en temps réel qui applique de grands modèles de langage à chaque transaction. IBM indique qu’un système z17 entièrement équipé peut traiter environ 450 milliards d’inférences par jour. Le terme reflète le positionnement stratégique d’IBM : le mainframe comme plateforme d’inférence IA, et non comme un système dont il faudrait sortir les charges d’IA.
Sources et lectures complémentaires
BMC Mainframe Survey 2025 — enquête sectorielle sur les tendances du mainframe et l’adoption de l’IA générative (septembre 2025).
IBM 1Q26 Earnings Call Transcript — Arvind Krishna, PDG, et Jim Kavanaugh, directeur financier, 22 avril 2026. Source du chiffre de croissance de capacité MIPS de 3x et de l’idée d’un « troisième type de capacité de calcul ».
Gartner: AI-Powered Mainframe Exits Are a Bubble Set to Pop — The Register — résumé du rapport Gartner d’avril 2026 « Too Big to Fail: Why Mainframe Exit Projects Are Likely to Fail in the Age of Generative AI ». Le rapport original est payant.
Zetaly : migration du mainframe vers le cloud — avantages, inconvénients et ce qui se passe vraiment — guide complémentaire sur les stratégies de migration, les risques réels et le rôle du FinOps mainframe.
