IBM a surpris les marchés en publiant une mise à jour préliminaire de ses résultats du deuxième trimestre, avant la publication complète attendue le 22 juillet. Le message est clair : les revenus devraient être inférieurs aux attentes de Wall Street, alors même que les entreprises réorientent une partie de leurs budgets informatiques vers l’infrastructure nécessaire aux projets d’intelligence artificielle.
Selon les chiffres communiqués, IBM anticipe un chiffre d’affaires trimestriel de 17,2 milliards de dollars, en hausse de 1 % sur un an, et un bénéfice dilué non-GAAP par action de 2,93 dollars, en progression de 5 %. Ces résultats restent toutefois sous les prévisions des analystes FactSet, qui tablaient sur 17,86 milliards de dollars de revenus et 3,01 dollars de bénéfice par action, d’après l’Associated Press.
La réaction des investisseurs a été brutale, avec une forte baisse du titre IBM. Mais au-delà de la sanction boursière, l’avertissement lancé par Arvind Krishna, PDG d’IBM, illustre un mouvement plus large : les budgets IT des grandes entreprises se déplacent rapidement vers les serveurs, le stockage, la mémoire et les composants nécessaires à l’IA, parfois au détriment des logiciels d’entreprise traditionnels.
Pourquoi l’alerte d’IBM dépasse le simple cas financier
IBM occupe une place particulière dans l’informatique d’entreprise. Le groupe vend des logiciels, des services d’infrastructure, des solutions de sécurité, d’analyse de données et du middleware, c’est-à-dire les briques logicielles qui permettent à des applications, bases de données et plateformes hétérogènes de communiquer entre elles.
Ces produits logiciels sont généralement très rentables. Ils constituent une partie importante de la valeur générée par les grands fournisseurs B2B. Or, la montée en puissance de l’IA générative modifie les arbitrages budgétaires : de nombreux clients consacrent désormais leurs dépenses d’investissement à la capacité matérielle nécessaire pour entraîner, héberger ou exploiter des modèles d’IA.
Dans sa communication, Arvind Krishna indique que, dans les dernières semaines de juin, certains clients ont déplacé leurs dépenses trimestrielles vers l’achat de serveurs, stockage et mémoire, afin de sécuriser des infrastructures sous tension avant de possibles hausses de prix. Ce changement de comportement a retardé plusieurs contrats importants attendus par IBM.
Le dirigeant reconnaît aussi une erreur d’anticipation. IBM n’aurait pas mesuré assez vite l’ampleur de cette repriorisation des budgets. Sa formule, traduite en substance, est révélatrice : l’entreprise n’a pas su s’adapter et agir assez rapidement, et plusieurs grands accords n’ont pas été finalisés dans les délais prévus.
Le boom de l’IA pousse les entreprises vers le matériel
Le cœur du problème n’est pas que les entreprises dépensent moins en technologie. Elles dépensent différemment. L’IA générative exige des infrastructures coûteuses : GPU, serveurs spécialisés, systèmes de stockage rapides, mémoire abondante, réseaux performants et capacités de refroidissement adaptées.
Dans ce contexte, les directions informatiques peuvent être tentées de retarder certains achats logiciels pour sécuriser d’abord les fondations matérielles. L’objectif est pragmatique : disposer de la capacité nécessaire pour lancer des projets IA internes, tester des cas d’usage à grande échelle ou construire des environnements de production capables d’absorber des charges de travail intensives.
Ce basculement crée une tension pour les fournisseurs historiques comme IBM. Les logiciels d’intégration, de gouvernance ou d’automatisation restent essentiels, mais ils deviennent parfois secondaires dans l’ordre des priorités budgétaires immédiates.
Un arbitrage qui touche aussi les équipes techniques
Pour les développeurs, les architectes et les équipes plateforme, cette redistribution des budgets n’est pas une abstraction financière. Elle peut se traduire très concrètement par moins d’outils commerciaux disponibles, moins de licences middleware et davantage de travail d’intégration réalisé en interne.
Lorsqu’une entreprise choisit de reporter l’achat d’une solution prête à l’emploi, les équipes doivent souvent compenser avec des assemblages maison. Cela peut impliquer :
- la création d’API personnalisées pour connecter des systèmes historiques à de nouveaux environnements IA ;
- la mise en place de pipelines de données pour alimenter des bases vectorielles ou des systèmes de génération augmentée par récupération, aussi appelée RAG ;
- l’utilisation d’outils open source comme Apache Kafka, Envoy ou d’autres briques d’intégration ;
- la maintenance de connecteurs spécifiques entre applications internes, bases de données anciennes et plateformes cloud modernes ;
- la construction de portails développeurs internes pour standardiser les usages et éviter la fragmentation.
Autrement dit, la facture logicielle économisée à court terme peut se transformer en charge opérationnelle supplémentaire pour les équipes techniques.
Moins de middleware, plus de bricolage interne
Le middleware est souvent invisible pour les décideurs non techniques, mais il joue un rôle central dans les systèmes d’information complexes. Il relie les applications, orchestre les flux, sécurise les échanges et évite que chaque équipe reconstruise les mêmes intégrations.
Si les budgets middleware sont gelés ou réduits, les organisations risquent de multiplier les solutions ponctuelles. Dans un projet IA, cela peut devenir critique. Un assistant interne, un moteur de recherche augmenté par IA ou un agent métier a besoin d’accéder à des données fiables, souvent réparties entre ERP, CRM, bases SQL, mainframes, data lakes et documents non structurés.
Sans outils d’intégration robustes, les développeurs doivent construire eux-mêmes les passerelles. Cela peut fonctionner dans une phase de prototype, mais devient plus délicat en production, où la sécurité, la traçabilité, la latence, la conformité et la résilience sont indispensables.
Exemple concret : connecter un mainframe à une application RAG
Imaginons une grande entreprise qui souhaite créer un assistant IA capable de répondre à des questions métiers à partir de données stockées dans un système historique. Si elle ne finance pas les solutions d’intégration prévues, l’équipe technique devra peut-être :
- extraire les données depuis le système legacy ;
- les transformer dans un format exploitable ;
- les indexer dans une base vectorielle ;
- mettre en place une couche de contrôle des accès ;
- développer une API pour l’application IA ;
- surveiller la fraîcheur, la qualité et la sécurité des données.
Ce travail est possible, mais il consomme du temps, de l’expertise et de la capacité d’ingénierie. Il ajoute aussi une dette technique si les solutions sont conçues dans l’urgence pour répondre à une pression business immédiate.
Les plateformes internes vont devenir encore plus stratégiques
La situation décrite par IBM renforce l’importance des équipes plateforme. Quand les budgets logiciels se resserrent, les entreprises cherchent souvent à rationaliser leurs outils internes, à standardiser les pratiques et à accélérer la livraison des projets.
C’est là que les Internal Developer Portals, les chaînes CI/CD, les catalogues de services, les modèles d’infrastructure as code et les “golden paths” deviennent essentiels. Ils permettent aux développeurs de construire plus vite sans réinventer à chaque fois les mêmes briques techniques.
Dans le contexte de l’IA, ces plateformes internes peuvent proposer des composants réutilisables :
- des modèles validés pour déployer une API connectée à un modèle de langage ;
- des connecteurs approuvés vers les bases de données internes ;
- des garde-fous de sécurité et de conformité ;
- des pipelines standards pour indexer des documents dans une base vectorielle ;
- des tableaux de bord pour suivre les coûts d’inférence, la latence et les erreurs.
Le risque, toutefois, est de demander à ces équipes de compenser à la fois la complexité croissante de l’IA et la réduction des achats logiciels externes. Sans priorisation claire, elles peuvent devenir un goulot d’étranglement.
Après l’infrastructure, la pression sur les applications IA va monter
L’avertissement d’IBM peut aussi être lu comme un signal de phase. Beaucoup d’entreprises sont encore en train de bâtir l’infrastructure de base pour l’IA : capacité de calcul, stockage, réseau, sécurité, gouvernance des données. Cette étape est coûteuse, mais elle ne suffit pas à créer de la valeur métier.
Une fois les investissements matériels réalisés, les directions générales attendront des résultats tangibles : automatisation de processus, assistants métiers, analyse documentaire, support client augmenté, génération de code, workflows agentiques ou nouveaux produits intégrant de l’IA.
La prochaine pression se déplacera donc vers les équipes chargées de transformer cette infrastructure en services utiles. Elles devront prouver que les dépenses en compute et en matériel se traduisent par des gains opérationnels, une meilleure productivité ou de nouvelles sources de revenus.
Ce que les DSI et équipes tech doivent retenir
Le cas IBM ne signifie pas que les logiciels d’entreprise n’ont plus d’avenir. Il montre plutôt que le calendrier d’achat change. À court terme, les entreprises peuvent privilégier le matériel et reporter certains contrats logiciels. À moyen terme, elles auront besoin de couches d’intégration, de supervision, de sécurité et d’automatisation pour exploiter réellement leur infrastructure IA.
Pour les responsables techniques, plusieurs actions deviennent prioritaires :
- cartographier les dépendances critiques entre systèmes historiques, données internes et futurs services IA ;
- identifier les intégrations à risque qui ne doivent pas être bricolées sans gouvernance ;
- standardiser les architectures RAG et les pipelines de données réutilisables ;
- évaluer le coût réel du “build” interne face aux solutions commerciales ;
- documenter les choix techniques pour éviter l’accumulation de dette invisible ;
- mettre en place un suivi des coûts IA, notamment sur l’inférence, le stockage et les transferts de données.
Le bon arbitrage ne consiste pas toujours à acheter une solution complète ni à tout construire en interne. Il s’agit plutôt de décider quelles briques sont stratégiques, quelles briques peuvent être externalisées et quelles intégrations doivent rester sous contrôle direct de l’entreprise.
Un signal d’alerte pour tout l’écosystème de l’IA d’entreprise
La contre-performance annoncée par IBM met en lumière une dynamique qui dépasse un seul fournisseur. L’IA transforme la manière dont les grandes organisations dépensent leur budget IT. Les gagnants immédiats sont souvent les vendeurs de matériel, de mémoire, de serveurs et d’infrastructure cloud. Les fournisseurs de logiciels d’entreprise doivent, eux, démontrer rapidement comment leurs produits accélèrent la mise en production de cas d’usage IA.
Pour les développeurs et les équipes plateforme, l’enjeu est plus opérationnel : ils devront intégrer de nouvelles infrastructures IA tout en composant avec des budgets logiciels parfois plus serrés. Cela signifie plus de responsabilités, plus de décisions d’architecture et une nécessité accrue de construire des fondations réutilisables.
IBM a reconnu ne pas avoir réagi assez vite à ce changement de priorités. D’autres acteurs pourraient être confrontés au même phénomène si les entreprises continuent de consacrer leurs dépenses à la construction de l’infrastructure IA avant de revenir vers les logiciels qui permettront d’en tirer toute la valeur.
Source : The New Stack.