IBM affirme que les dépenses en IA ont retardé les contrats liés aux mainframes, mais que l’impact est temporaire

IBM a subi une chute historique de son action après avoir reconnu que les dépenses en infrastructure d’IA avaient contribué à faire dérailler son deuxième trimestre. Pourtant, l’article de TechCrunch publié après les résultats présente un net revirement : IBM insiste sur le fait que les clients reportent leurs achats de mainframes, sans les abandonner.

Le PDG Arvind Krishna affirme que les grandes entreprises ont réorienté leurs capitaux vers les serveurs, le stockage et la mémoire au cours des dernières semaines de juin. Les acheteurs voulaient sécuriser leurs approvisionnements avant les hausses de prix anticipées. Les contrats de mainframes et de logiciels associés n’ont alors pas été conclus aux dates prévues par IBM.

Cette explication oppose directement deux interprétations. Les investisseurs y ont vu la preuve que les budgets IA cannibalisaient les activités historiques d’IBM. IBM y a vu une séquence d’achats temporaire au sein de budgets d’entreprise fixes, suivie de contrats différés qui pourraient encore être conclus.

La différence compte bien au-delà d’un seul trimestre. Les mainframes restent au cœur du traitement des transactions dans les banques, les compagnies aériennes, les réseaux de paiement et les administrations publiques. Si les dépenses en IA ne font que repousser les mises à niveau, IBM peut se redresser. Si l’IA modifie durablement les infrastructures qui reçoivent la priorité budgétaire, l’entreprise fait face à un problème plus profond.

L’avertissement d’IBM a transformé un trimestre faible en test de crédibilité

IBM ne s’est pas contentée de manquer les attentes. L’entreprise a averti les investisseurs en avance, imputé la situation à un changement tardif des dépenses des clients et reconnu que ses équipes n’avaient pas su réagir.

Le 14 juillet, Krishna a publié des résultats préliminaires du deuxième trimestre plus d’une semaine avant l’annonce de résultats initialement prévue par IBM. Le chiffre d’affaires a atteint 17,2 milliards de dollars, en hausse de 1 % sur un an. Les revenus de l’infrastructure ont reculé de 7 %, tandis que les logiciels ont progressé de 5 % et que le conseil est resté globalement stable.

Ces résultats sont inférieurs aux attentes de Wall Street. Les analystes interrogés par FactSet anticipaient un chiffre d’affaires de 17,86 milliards de dollars et un bénéfice ajusté de 3,01 dollars par action. IBM a publié un bénéfice ajusté de 2,93 dollars par action.

La réaction du marché a été sévère. L’action IBM a chuté d’environ 25 % le 14 juillet, enregistrant le plus fort recul quotidien de l’entreprise depuis plus d’un siècle. La vente massive a également alimenté l’inquiétude dans les sociétés de logiciels exposées aux budgets technologiques des entreprises.

La lettre aux investisseurs inhabituellement directe de Krishna a expliqué la cause immédiate. IBM s’attendait à une baisse des revenus de l’infrastructure, alors que le mainframe z17 entrait dans une comparaison annuelle plus difficile. Le recul réel a été plus marqué parce que d’importants contrats portant sur les systèmes Z et les logiciels de traitement des transactions n’ont pas été conclus.

Le calendrier a rendu l’avertissement plus dommageable. IBM avait présenté le lancement du z17 comme le meilleur démarrage d’un programme de mainframes de son histoire. Les investisseurs avaient donc des raisons d’espérer que le cycle produit soutiendrait les revenus, même si les comparaisons avec le début du lancement devenaient plus difficiles.

Au lieu de cela, IBM a reconnu que le comportement des clients avait rapidement évolué vers la fin du trimestre. Les entreprises ont réorienté leurs dépenses d’investissement, c’est-à-dire les fonds consacrés aux actifs à long terme, vers les serveurs, le stockage et la mémoire. Les contraintes d’approvisionnement et les hausses de prix attendues ont rendu ces achats plus urgents.

Selon IBM, les préoccupations de cybersécurité ont également détourné l’attention des clients. Toutefois, Krishna n’a pas présenté les conditions externes comme une défense complète. Il a écrit qu’IBM avait « failli », n’avait pas su s’adapter assez rapidement et avait laissé de nombreux contrats importants dépasser les délais prévus.

Cet aveu a fait passer le sujet d’un recul ordinaire du cycle produit à une question d’exécution. La pression sur l’offre peut expliquer pourquoi les clients ont réordonné leurs achats. Elle n’explique pas entièrement pourquoi IBM n’a pas anticipé l’ampleur du phénomène ni protégé suffisamment de contrats pour atteindre les attentes.

Les résultats trimestriels définitifs ont confirmé un chiffre d’affaires de 17,162 milliards de dollars. L’infrastructure a généré 3,835 milliards de dollars, en baisse de 7,4 % sur un an. Sa marge bénéficiaire sectorielle a également reculé de 23,3 % à 21,8 %.

Les logiciels sont restés le plus grand segment, avec 7,761 milliards de dollars de chiffre d’affaires et une croissance de 5,1 %. Le conseil a contribué à hauteur de 5,327 milliards de dollars, en hausse de seulement 0,2 %. Ces chiffres montrent pourquoi le manque à gagner lié aux mainframes importait malgré le portefeuille plus large d’IBM.

Le matériel de mainframe soutient un écosystème économique plus vaste. Les clients achètent également des logiciels d’exploitation, des outils de traitement des transactions, du support et des services de conseil autour de ces systèmes. Le report d’une machine peut donc freiner plusieurs sources de revenus liées.

Le contrecoup observé par TechCrunch n’était pas l’affirmation que les mainframes avaient soudainement cessé de fonctionner. C’était un avertissement : le cycle produit le plus fiable d’IBM s’était heurté à une catégorie de dépenses d’infrastructure devenue plus urgente.

Pourquoi l’infrastructure IA est passée devant les mainframes d’IBM

L’IA n’a pas remplacé le mainframe au cours du trimestre. Elle a changé les achats matériels que les clients jugeaient impossibles à différer.

Les budgets technologiques des entreprises ne sont pas infiniment flexibles. Les grandes organisations planifient leurs dépenses d’investissement annuelles, mais peuvent réordonner leurs achats lorsque la disponibilité et les prix évoluent. C’est ce qu’IBM affirme avoir observé à la fin juin.

Les clients ont donné la priorité aux serveurs polyvalents, aux systèmes de stockage et à la mémoire nécessaires aux projets d’IA. La mémoire était particulièrement importante, car les systèmes d’IA modernes consomment de grandes quantités de mémoire à large bande passante et de mémoire conventionnelle pour les charges de travail d’entraînement, d’inférence et de traitement des données.

L’inférence est le processus qui consiste à exécuter un modèle d’IA entraîné afin de produire une réponse ou une prédiction. Lorsque les entreprises font passer les applications d’IA de l’expérimentation à la production, l’inférence génère une demande durable en serveurs, accélérateurs, réseaux, stockage et mémoire.

Les mises à niveau de mainframes suivent un calendrier différent. Les entreprises les planifient généralement avec soin, car elles prennent en charge des charges de travail sensibles et à fort volume. Une banque ne peut pas déplacer à la légère le traitement des paiements d’une architecture à une autre simplement parce qu’un nouveau serveur IA est disponible.

Cette stabilité rend aussi un contrat de mainframe plus facile à reporter. Un client peut continuer à utiliser sa capacité existante pendant un trimestre supplémentaire tout en sécurisant aujourd’hui du matériel IA rare. La charge de travail demeure, mais le bon de commande est décalé.

Les propres résultats d’IBM étayent une partie de cette explication. L’infrastructure distribuée, notamment les systèmes Power et le stockage, a progressé de 37 % au cours du trimestre. IBM a indiqué que cette activité avait terminé juin avec un carnet de commandes d’environ 500 millions de dollars.

Le contraste au sein d’IBM est révélateur. Les clients achetaient toujours de l’infrastructure, mais privilégiaient les produits correspondant à des contraintes immédiates de capacité. La demande n’a pas disparu du marché. Elle s’est déplacée entre catégories.

C’est le mécanisme qui sous-tend l’argument d’IBM selon lequel la perturbation est temporaire. L’infrastructure IA reçoit la priorité parce qu’un accès retardé peut ralentir un nouveau projet ou exposer l’acheteur à des coûts plus élevés pour les composants. Une modernisation de mainframe peut parfois attendre sans perturber les opérations en cours.

L’argument devient moins rassurant lorsqu’on l’observe sur plusieurs cycles budgétaires. Si le matériel IA absorbe à répétition la première part du capital annuel, les retards supposément temporaires d’IBM peuvent se reproduire. Les reports répétés finissent par se comporter comme une demande plus faible, même lorsque les clients conservent toutes leurs charges de travail existantes sur mainframe.

IBM doit donc démontrer davantage que la poursuite de l’utilisation des mainframes. Elle doit montrer que cette utilisation se traduit par une croissance rapide des capacités et des revenus logiciels. Les systèmes installés peuvent rester essentiels alors que les ventes de nouveaux systèmes déçoivent.

Cette distinction aide à expliquer l’intense réaction des investisseurs. Les mainframes génèrent souvent des revenus cycliques, avec une forte croissance après le lancement d’une nouvelle génération puis un recul à mesure que ce cycle mûrit. Les investisseurs s’attendent à ces schémas. Ils réagissent plus fortement lorsqu’un lancement phare sous-performe parce que les clients ont trouvé une destination plus urgente pour leurs capitaux.

Le z17 a été présenté comme un mainframe conçu pour l’ère de l’IA. Il comprend des capacités permettant d’exécuter des modèles d’IA parallèlement aux charges de travail transactionnelles, ce qui permet aux organisations d’évaluer les données sans déplacer chaque enregistrement vers un autre environnement.

Cette conception devrait placer IBM du côté gagnant des dépenses en IA. Pourtant, le deuxième trimestre a révélé une fracture budgétaire entre l’infrastructure achetée spécifiquement pour développer l’IA et l’infrastructure commercialisée comme capable d’ajouter l’IA à des charges de travail établies.

Les deux catégories résolvent des problèmes différents. Les systèmes fortement équipés en GPU ciblent l’entraînement des modèles et l’inférence à grande échelle. Les mainframes ciblent le traitement sécurisé des transactions, la disponibilité et le contrôle centralisé, avec une IA intégrée à ces opérations existantes.

Le défi d’IBM consiste à rendre ce cas d’usage combiné urgent. Si les clients considèrent l’IA sur mainframe comme utile mais non essentielle, elle continuera de perdre les arbitrages de calendrier face aux serveurs et à la mémoire rares.

TechCrunch après le krach : IBM affirme que le mainframe est retardé, pas condamné

La défense d’IBM repose sur les données de capacité des clients et les contrats différés, et non sur l’affirmation que le trimestre était secrètement solide.

Lors de la conférence téléphonique sur les résultats du 22 juillet, Krishna a rejeté l’idée que les clients se détournaient des mainframes. Il a déclaré qu’IBM ne voyait aucun signe d’abandon de la plateforme par les clients. L’entreprise a plutôt présenté le manque à gagner comme un problème de calendrier concentré sur de gros contrats d’investissement.

IBM a indiqué que les performances du z17 restaient proches de 130 % de celles du programme z16 comparable. « Programme à programme » compare les ventes ou la capacité installée au même stade de cycles produit successifs.

L’entreprise a également affirmé que les clients représentant 85 % des MIPS installés avaient maintenu ou augmenté leur capacité. Les MIPS, ou millions d’instructions par seconde, constituent une mesure traditionnelle utilisée pour décrire la capacité de traitement des mainframes.

Ces chiffres étayent l’argument selon lequel les charges de travail essentielles restent en place. Ils correspondent également à la durabilité historique des mainframes. Les organisations continuent de les utiliser parce que remplacer des systèmes de transaction profondément intégrés comporte des risques opérationnels, de sécurité et de conformité.

Une grande banque, par exemple, peut exécuter les mises à jour de comptes, les autorisations de cartes, les contrôles antifraude et les processus de règlement au moyen d’applications de mainframe. Déplacer ces systèmes exige davantage que de réécrire un ancien code COBOL. L’organisation doit préserver l’intégrité des données, la disponibilité, les contrôles d’audit et les liens avec des centaines de services en aval.

Les outils de programmation IA peuvent réduire une partie du travail de modernisation. Ils peuvent documenter d’anciennes applications, expliquer un code peu familier et aider à traduire certains composants. Ils n’effacent pas le risque institutionnel lié au remplacement de systèmes qui gèrent des transactions critiques à chaque seconde.

La position d’IBM repose donc sur une solide base technique. Les mainframes sont difficiles à remplacer parce qu’ils sont intégrés aux processus opérationnels, et pas seulement aux centres de données. Le coût d’un échec peut dépasser toute économie attendue d’une migration.

Toutefois, la persistance technique ne garantit pas un cycle matériel fluide. Les clients peuvent conserver leurs charges de travail sur les systèmes IBM tout en prolongeant la durée de vie des équipements, en utilisant une capacité de réserve, en négociant plus fermement ou en déplaçant des applications incrémentales ailleurs.

Cet écart entre l’utilisation installée et les nouvelles dépenses constitue la tension centrale. Les chiffres d’IBM montrent que la plateforme reste active. Ils n’établissent pas encore que chaque achat retardé reviendra à son échelle initiale.

Krishna a présenté un indicateur à court terme lors de la discussion sur les résultats. Il a déclaré qu’environ un tiers des gros contrats qui n’avaient pas été conclus au deuxième trimestre l’avaient déjà été au cours du troisième trimestre.

Cela constitue un élément probant en faveur d’un problème de calendrier. Ce n’est pas un rétablissement complet. Les deux tiers n’étaient pas encore conclus lorsqu’il s’est exprimé, et IBM n’a pas promis que tous se concrétiseraient sans modification de volume, de calendrier ou de conditions.

L’analyse de TechCrunch après les résultats souligne cette distinction. L’IA n’a pas détruit la demande pour le travail effectué par les mainframes. Elle a révélé que même les systèmes essentiels doivent rivaliser pour obtenir une approbation au sein de budgets d’entreprise limités.

IBM a également abaissé ses prévisions de croissance annuelle du chiffre d’affaires à taux de change constants, désormais comprises entre 4 % et 5 %. Auparavant, l’entreprise prévoyait une croissance supérieure à 5 %. Une révision à la baisse des prévisions est difficilement conciliable avec l’idée que chaque contrat manqué n’a été décalé que de quelques semaines.

La direction peut considérer que l’activité sous-jacente reste saine tout en reconnaissant que l’opportunité de chiffre d’affaires de l’année s’est affaiblie. Ces deux affirmations peuvent être vraies. La plateforme peut perdurer, mais IBM doit tout de même exécuter selon le calendrier suivi par les investisseurs.

Le véritable enjeu est la priorité budgétaire, pas les mainframes face à l’IA

L’adversaire d’IBM n’est ni un modèle d’IA ni un autre fournisseur de mainframes. C’est l’urgence associée à chaque achat concurrent d’infrastructure d’IA.

Présenter l’histoire comme une opposition entre l’IA et les mainframes crée un faux choix technique. Les grandes entreprises ont besoin à la fois de systèmes transactionnels et de capacités d’IA. Le conflit immédiat survient lorsque les responsables financiers et technologiques décident quel achat sera financé en premier.

Les projets d’IA attirent désormais l’attention des conseils d’administration, des directeurs généraux, des équipes de sécurité et des responsables d’unités opérationnelles. De nombreuses organisations craignent de prendre du retard sur leurs concurrents ou de perdre l’accès à des composants dont l’offre est limitée. Cette pression accroît le coût perçu de l’attente.

Les mises à niveau des mainframes reposent sur une justification différente. Elles protègent souvent la résilience, la capacité et l’efficacité de systèmes qui génèrent déjà de la valeur métier. Leurs bénéfices peuvent sembler progressifs face à une nouvelle initiative d’IA promettant l’automatisation ou une nouvelle ligne de produits.

Cette asymétrie affecte IBM même si sa technologie tient ses promesses. Une plateforme éprouvée peut perdre sa priorité budgétaire face à un projet spéculatif lorsque la direction considère ce dernier comme stratégiquement urgent.

Les fournisseurs d’infrastructure concurrents profitent de cette urgence. Les systèmes centrés sur Nvidia captent les dépenses consacrées au calcul accéléré. Les fournisseurs de cloud hyperscale offrent un accès aux modèles et à l’infrastructure d’IA sans exiger que chaque client possède le matériel sous-jacent.

Les fournisseurs de serveurs, de stockage, de réseaux et de mémoire en bénéficient également lorsque les entreprises construisent des environnements d’IA privés. IBM participe à certaines parties de ce marché, mais l’économie de ses mainframes reste exposée lorsque les acheteurs dissocient la capacité d’IA de l’infrastructure transactionnelle.

IBM a tenté de relier ces deux mondes. Le z17 prend en charge le traitement d’IA embarqué, tandis que watsonx fournit des outils pour créer, gouverner et déployer l’IA. Le logiciel de cloud hybride de Red Hat aide les organisations à exécuter des charges de travail dans des environnements privés et publics.

L’idée stratégique est cohérente : les entreprises devraient gérer l’IA aux côtés des systèmes et des données auxquels elles font déjà confiance. Pourtant, les acheteurs n’acquièrent pas toujours la technologie comme une architecture intégrée. Les responsables des budgets peuvent financer aujourd’hui un cluster d’IA urgent et réexaminer plus tard la capacité mainframe.

Le conseil devrait aider IBM à combler cette fracture. Ses conseillers peuvent relier les plans d’IA aux applications existantes, aux exigences de gouvernance et aux données opérationnelles. Toutefois, le chiffre d’affaires du conseil n’a progressé que de 0,2 % sur le trimestre, ce qui limite les preuves d’une forte accélération généralisée des déploiements.

Les logiciels ont montré davantage d’élan. Le chiffre d’affaires de Red Hat a augmenté de 11 %, tandis que les actifs récemment acquis de HashiCorp et Confluent ont affiché de solides performances, selon IBM. Ces activités s’alignent sur l’infrastructure hybride, le déploiement d’applications et la circulation des données en temps réel.

Cette performance offre à IBM plusieurs moyens de bénéficier des dépenses d’entreprise liées à l’IA. Elle complique aussi le récit. L’entreprise peut progresser grâce à Red Hat ou aux logiciels de données tout en subissant des retards dans les ventes de mainframes et de traitement transactionnel.

Les investisseurs doivent évaluer la composition, et pas seulement l’exposition totale à l’IA. Le transfert de revenus d’une pile établie à forte marge vers d’autres produits peut modifier la rentabilité, le calendrier des ventes et les relations clients.

Le conflit des dépenses touche aussi les responsables technologiques qui gèrent les systèmes existants. Ils doivent décider s’il faut moderniser près du mainframe, déplacer certaines charges de travail ou créer des services d’IA qui accèdent aux données établies via des interfaces contrôlées.

Cette décision exige un historique clair des choix d’architecture, des affirmations des fournisseurs, des contraintes de sécurité et des dépendances opérationnelles. Une base de connaissances techniques consultable peut aider les équipes à comparer ces éléments sans dissocier les décisions de leurs documents sources.

Néanmoins, la documentation ne peut pas résoudre l’arbitrage d’investissement. IBM doit démontrer que la mise à niveau de sa plateforme fait progresser les objectifs d’IA dès maintenant, plutôt que de simplement préserver une infrastructure que les clients jugent déjà indispensable.

Ce que l’explication d’IBM ne prouve toujours pas

Le récit d’un retard temporaire est plausible, mais un seul trimestre de suivi ne peut établir que les dépenses d’IA ont laissé inchangée l’économie à long terme d’IBM.

La première incertitude concerne les contrats retardés restants. La conclusion d’environ un tiers d’entre eux au cours du troisième trimestre étaye la version d’IBM. Elle laisse également une part substantielle non résolue.

Les achats importants des entreprises peuvent évoluer après un report. Les clients peuvent réduire la capacité, fractionner les commandes, exiger des conditions différentes ou reporter les décisions logicielles associées à une autre année budgétaire. Un contrat retardé n’est pas équivalent à un carnet de commandes contractuel.

La deuxième incertitude concerne la pression récurrente sur les composants. IBM a relié la perturbation de juin à une infrastructure dont l’offre était contrainte et à des hausses de prix anticipées. Si la disponibilité de la mémoire et des serveurs reste difficile, les clients pourraient continuer à prioriser ces achats.

Cela transformerait une séquence temporaire en schéma récurrent. Les mainframes continueraient de fonctionner, mais chaque nouveau cycle pourrait commencer derrière l’infrastructure d’IA dans la file d’attente des investissements.

La troisième incertitude concerne l’exécution d’IBM. Krishna a explicitement déclaré que l’entreprise n’avait pas su s’adapter assez rapidement. Cet aveu empêche la direction d’attribuer entièrement le manque à gagner à des conditions externes.

Les équipes commerciales devraient comprendre les cycles d’approbation des clients et les demandes budgétaires concurrentes. Les systèmes de prévision devraient identifier les grandes transactions exposées à des décalages de fin de trimestre. Les équipes produit devraient rendre suffisamment concrète la valeur du z17 pour l’IA afin de préserver l’urgence d’achat.

IBM affirme que le z17 reste en avance sur le cycle comparable du z16. Cette mesure mérite une interprétation prudente, car les programmes produits peuvent différer par le calendrier de lancement, la composition des capacités, la concentration des clients et la comptabilisation du chiffre d’affaires.

Le chiffre des MIPS installés mesure également l’activité de la plateforme plus directement que les nouveaux revenus. Les clients qui maintiennent leur capacité montrent leur attachement aux charges de travail. Ils ne démontrent pas nécessairement un enthousiasme pour l’accélération des achats de matériel.

Les reportages indépendants renforcent les deux aspects. La couverture des résultats préliminaires a documenté l’écart par rapport aux attentes des analystes ainsi que l’ampleur de la baisse initiale de l’action. Les résultats ultérieurs ont montré qu’IBM continuait d’enregistrer de la croissance dans les logiciels et plusieurs produits d’infrastructure distribuée.

Le marché a sans doute sanctionné davantage qu’un simple manque à gagner sur le matériel. L’avertissement d’IBM a soulevé des interrogations sur la possibilité que les dépenses d’investissement en IA évinceraient les logiciels et infrastructures d’entreprise établis. Des préoccupations similaires peuvent affecter tout fournisseur dont les produits rivalisent avec les projets d’IA pour des budgets fixes.

Toutefois, le cas d’IBM ne doit pas devenir une règle universelle. Ses résultats reflètent sa gamme de produits, son exécution commerciale, son cycle mainframe et sa base de clients. Une autre entreprise de logiciels pourrait être confrontée à des structures de renouvellement différentes ou à une moindre exposition aux achats d’investissement.

Il existe également un risque à traiter la réaction boursière comme un verdict technique. Les marchés réévaluent les attentes, pas les architectures. Une forte baisse indique que les résultats et les prévisions ont fortement divergé des hypothèses des investisseurs. Elle ne prouve pas que le mainframe a perdu son rôle opérationnel.

La conclusion la plus défendable est plus limitée. Les dépenses d’IA ont perturbé la séquence de contrats attendue par IBM, et IBM n’a pas réussi à absorber cette perturbation. L’entreprise a présenté des premiers éléments montrant le retour d’une demande retardée, mais le rétablissement reste incomplet.

Cette conclusion respecte la différence entre une explication crédible et un redressement vérifié. IBM n’a pas besoin de prouver que l’IA et les mainframes peuvent coexister. Ils coexistent déjà. Elle doit prouver que cette coexistence produit le calendrier de revenus et la croissance attendus par les investisseurs.

Trois signaux détermineront si le redressement d’IBM se maintient

Le prochain trimestre doit convertir l’explication d’IBM en résultats mesurables concernant les contrats retardés, la capacité mainframe et le portefeuille d’entreprise plus large.

Le premier signal est le taux de conclusion des grandes transactions reportées depuis le deuxième trimestre. IBM a indiqué qu’environ un tiers avait déjà été conclu. La prochaine mise à jour devra montrer si la majeure partie du reste a suivi, et si ces contrats ont conservé leur périmètre prévu.

Un taux de conclusion élevé renforcerait l’argument du calendrier. Des retards persistants suggéreraient que les clients reconsidèrent davantage que les seules dates des bons de commande.

Le deuxième signal est la performance du z17 par rapport au cycle du z16. IBM affirme que le z17 reste proche de 130 % d’un programme à l’autre. Les investisseurs devraient surveiller si cet avantage persiste après le trimestre volatil.

Une capacité installée stable ou en expansion soutiendrait l’affirmation d’IBM selon laquelle les clients restent engagés. Des ajouts de capacité plus lents affaibliraient le lien entre les charges de travail essentielles et les revenus des nouveaux systèmes.

Le troisième signal est la composition des revenus d’IBM. Le redressement des mainframes serait plus convaincant si les logiciels de traitement transactionnel s’amélioraient parallèlement à l’infrastructure. La poursuite de la vigueur de Red Hat, du stockage et de Power montrerait qu’IBM capte ailleurs les dépenses liées à l’IA.

Cette composition compte parce qu’IBM a abaissé ses prévisions annuelles de revenus. Quelques contrats récupérés pourraient corriger le calendrier trimestriel sans rétablir l’ancienne attente de croissance. Une amélioration durable exige des contributions des logiciels, de l’infrastructure et du conseil.

La question plus générale est de savoir si IBM peut faire du mainframe une partie du budget urgent de l’IA, plutôt que l’achat qui attend derrière lui. Cela exige des résultats clients précis, et non une nouvelle affirmation générale selon laquelle le z17 a été conçu pour l’IA.

Les entreprises devraient observer comment les clients d’IBM déploient l’IA à proximité de données transactionnelles réglementées. Parmi les exemples utiles figurent le filtrage des fraudes en temps réel, l’analyse des risques, les prévisions opérationnelles et le support automatisé des applications historiques.

La sécurité restera également centrale. Les organisations ont besoin d’un accès contrôlé aux dossiers sensibles, de pistes d’audit fiables et d’une gouvernance claire des résultats des modèles. Les mainframes disposent d’atouts dans ces environnements, mais IBM doit les traduire en projets dotés de budgets approuvés.

Le récit de TechCrunch après le trimestre sera finalement jugé sur les commandes, la capacité, la croissance des logiciels et les prévisions. Il ne sera pas tranché par l’ancienneté de COBOL ni par une nouvelle prédiction annonçant la disparition imminente des systèmes historiques.

IBM a survécu à plusieurs générations de technologies censées remplacer le mainframe. La survie n’est plus l’épreuve exigeante. La véritable épreuve consiste à savoir si IBM peut transformer une base installée durable en croissance, tandis que l’infrastructure d’IA absorbe une part croissante de l’attention des clients.

Pour les acheteurs d’entreprise, la réponse pratique consiste à suivre les risques créés par chaque investissement retardé. Quels achats d’IA sont réellement sensibles aux contraintes d’approvisionnement ? Quelles mises à niveau de mainframes protègent la capacité ou la conformité ? Quels projets dépendent de données partagées et doivent donc relever d’une même décision d’architecture ?

Gardez ces réponses ancrées dans les comptes rendus de réunion, les documents fournisseurs et les preuves opérationnelles. Un système de connaissances personnelles peut préserver le raisonnement à mesure que les hypothèses évoluent.

IBM affirme que le mainframe est retardé, pas en voie de disparition. Le prochain cycle de résultats devra démontrer que cette demande différée revient avant qu’une nouvelle vague de dépenses liées à l’IA ne le relègue au second plan.