Échec du retour sur investissement de la modernisation du cloud : le déficit d’observabilité que personne n’avait anticipé

Les entreprises mondiales devraient dépenser plus de mille milliards de dollars en services de cloud public en 2026. La justification de ces dépenses repose sur des projections allant de convaincantes à extraordinaires : une étude d’IDC révèle un retour sur investissement de 334 % sur trois ans et un délai de récupération de dix mois pour les organisations qui mènent efficacement leur modernisation. Les benchmarks d’AWS font état d’une croissance du chiffre d’affaires de 43 % et d’une réduction des dépenses informatiques de 33 % pour des charges de travail entièrement modernisées. Ces chiffres sont concrets. Ils représentent des résultats atteignables. Le problème est que la plupart des organisations ne les atteignent pas.

Les données de PwC révèlent que 54 % des entreprises constatent une faible valeur ajoutée de leurs investissements dans le cloud, malgré une adoption croissante. Flexera observe que 84 % des organisations placent la visibilité des coûts au premier plan, mais que seulement 38 % suivent activement le retour sur investissement du cloud au sein de leurs différentes unités opérationnelles. Gartner indique que les budgets cloud dépassent les prévisions de 17 % en moyenne. L'écart entre les promesses de la modernisation cloud et la réalité vécue par les organisations n'est pas dû à un échec technologique, mais à un manque de visibilité, et ce, bien avant la migration des premières charges de travail.

La vérité dérangeante sur l'échec de la modernisation du cloud

Les entreprises investissent des milliards dans la migration vers le cloud, mais beaucoup n'atteignent pas le retour sur investissement promis. Transférer les charges de travail vers le cloud sans se préoccuper de la visibilité opérationnelle, de l'explosion des coûts et de la fragmentation des outils ne fait qu'aggraver le problème. L'expression « aggraver le problème » mérite réflexion. La migration vers le cloud ne neutralise pas la dette technique, et celle-ci ne disparaît pas dans le cloud ; elle se transforme simplement.

Ce schéma d'échec est récurrent dans tous les secteurs. Les équipes adoptent Kubernetes et une architecture orientée services sans disposer de l'observabilité, de la maturité CI/CD ni de l'alignement nécessaires. Résultat : un monolithe distribué complexe à mettre en œuvre, sans aucun avantage. Une organisation qui migre un monolithe existant sans comprendre sa structure interne, ses dépendances et ses flux de données ne gagne pas en flexibilité cloud. Elle se retrouve avec des factures cloud élevées et les mêmes problèmes architecturaux qu'elle cherchait à fuir.

L'enseignement le plus important tiré des échecs de programmes est que ces échecs sont principalement d'ordre organisationnel, et non technique. La technologie fonctionne. Ce sont souvent les structures organisationnelles, les systèmes d'incitation et les processus décisionnels qui dysfonctionnent. Un manque de clarté dans la définition des responsabilités, des indicateurs clés de performance (KPI) inadéquats et des équipes dépourvues de l'autorité ou des compétences nécessaires à l'exécution : tels sont les modes de défaillance qui ressortent des analyses post-mortem. Mais derrière chaque échec organisationnel se cache un manque d'information : la migration a été planifiée sans une connaissance précise des éléments concernés.

Qu’est-ce que le fossé d’observabilité réellement ?

L'observabilité dans le contexte du cloud désigne la capacité à comprendre l'état interne d'un système à partir de ses données de télémétrie, afin de répondre aux questions « que se passe-t-il et pourquoi ? ». L'observabilité se distingue de la surveillance. La surveillance vous alerte sur la disponibilité d'un service, tandis que l'observabilité vous fournit la cause de la défaillance, le service défaillant initial et la chaîne de dépendances entre les services impliqués au moment de la panne.

Le problème d'observabilité dans les programmes de modernisation du cloud ne concerne pas principalement la télémétrie d'exécution, les métriques, les journaux et les traces après le déploiement de l'application. Il s'agit plutôt d'un problème plus ancien et plus lourd de conséquences : l'absence de visibilité structurelle sur l'application avant le début de la migration.

Ce déficit d'observabilité initial comporte trois dimensions :

Ce que contient réellement l'application. La documentation décrit la fonction initiale du système. Le code source, quant à lui, reflète quinze années de modifications, de solutions de contournement et de décisions non documentées, qu'aucun schéma d'architecture ne représente. Un plan de migration basé sur la documentation est un plan de migration basé sur une carte incomplète.

Comment les composants s'interconnectent. Les dépendances entre modules, services et systèmes déterminent la séquence de migration, les risques et l'étendue réelle de tout changement envisagé. Les organisations qui appréhendent le potentiel du cloud par le biais d'initiatives cloisonnées, plutôt que par une transformation globale de leur portefeuille, voient les gains issus des nouveaux déploiements annulés par les dépenses d'exploitation courantes des systèmes inchangés. Une évaluation cloisonnée engendre une compréhension cloisonnée et des migrations qui ne découvrent les dépendances entre composants qu'en cours d'exécution, au moment où cette découverte est la plus coûteuse.

Quels seront les effets réels de la migration ? Sans modèle de dépendance structurelle, l’évaluation d’impact se limite à une estimation. Or, cette estimation aboutit à des plans de migration dont la portée est incertaine. C’est précisément dans ces zones d’incertitude que les projections de retour sur investissement du cloud échouent.

Où se creuse le fossé : avant, pendant et après la migration

Avant la migration : l'illusion de l'évaluation

La plupart des programmes de migration vers le cloud débutent par une phase d'évaluation. Les 90 premiers jours sont consacrés à cette évaluation : inventaire du parc de données, évaluation de la préparation à l'IA, définition d'une base de référence pour les opérations financières et analyse des écarts de gouvernance. Cette approche semble systématique. En pratique, l'évaluation reste presque toujours superficielle en ce qui concerne le code applicatif.

Les outils de découverte d'infrastructure recensent les serveurs. Les outils d'analyse de portefeuille produisent des scores de complexité. Cependant, l'analyse structurelle proprement dite du code applicatif (quelles fonctions existent, comment elles s'appellent entre elles, quels composants partagent des données via des fichiers ou des bases de données plutôt que des API explicites, quel code est obsolète et peut être exclu du périmètre d'analyse) est rarement effectuée, car les outils nécessaires à cette analyse pour les portefeuilles de langages d'entreprise ne font pas partie des solutions standard des fournisseurs de migration.

Absence d'observabilité dès le départ. Les tableaux de bord de santé des pipelines, de qualité des données et de coûts ajoutés après la mise en production coûtent trois fois plus cher que leur intégration dès le départ. Le même principe s'applique à l'observabilité structurelle du portefeuille d'applications : le coût de la découverte de la complexité architecturale après le début de la migration est bien supérieur au coût de cette découverte avant.

Lors de la migration : le problème de la découverte des dépendances

Le moment le plus coûteux d'un programme de migration vers le cloud survient lorsqu'une dépendance inconnue avant la migration est découverte en cours d'exécution. L'équipe s'est engagée sur un calendrier précis. L'infrastructure est en place. Les contrats avec les prestataires de migration sont signés. Et puis, un copybook COBOL partagé, utilisé par 300 programmes, un schéma de base de données partagé auquel 12 services accèdent, ou un traitement par lots alimentant six clients en aval via une interface de fichiers, surgit comme une complication imprévue.

Sans une observabilité unifiée et une automatisation intelligente, la modernisation du cloud déplace souvent ces problèmes vers un environnement distribué plus complexe au lieu de les résoudre. Le monolithe se fragmente en microservices. Les dépendances implicites entre ses composants deviennent des appels réseau entre services distribués. Le problème d'observabilité n'est pas éliminé ; il est distribué, ce qui le rend plus difficile à appréhender.

Après la migration : l'effondrement de la visibilité des coûts

84 % des entreprises considèrent la gestion des dépenses liées au cloud comme leur principal défi, leurs budgets dépassant les prévisions de 17 %. Parallèlement, 69 % des responsables informatiques signalent des dépassements budgétaires dans leurs dépenses cloud.

Les dépassements de coûts liés au cloud sont directement imputables au manque d'observabilité avant la migration. Les charges de travail initialement considérées comme de simples candidates à une migration « lift-and-shift » nécessitent en réalité une refactorisation. Les applications jugées de petite taille engendrent des coûts de transfert de données importants, car leurs flux de données amont et aval n'ont pas été cartographiés lors de l'évaluation. Le code mort migré en même temps que le code en production s'exécute dans des conteneurs facturés à la milliseconde. Mesurer la disponibilité du système plutôt que les résultats commerciaux conduit les équipes à optimiser des résultats inappropriés.

Flexera indique que seulement 38 % des entreprises suivent activement le retour sur investissement du cloud au sein de leurs différentes unités opérationnelles. Or, il est impossible de suivre un retour sur investissement que l'on ne peut mesurer, et encore moins de le mesurer par rapport à une base de référence établie avec précision avant la migration.

L’observabilité structurelle dont les programmes de migration ont besoin

Combler le déficit d'observabilité exige une analyse différente de celle fournie par la découverte d'infrastructure. Il faut analyser le code source de chaque application concernée par la migration et construire un modèle structurel qui représente :

Inventaire complet. Chaque programme, fonction, module, copybook, schéma, flux de travaux et procédure, y compris ceux qui ne figurent pas dans la documentation, ce qui, dans les grands environnements d'entreprise, représente souvent 20 à 30 % du nombre réel.

Cartographie des dépendances interlangages. Comment un service Java se connecte à un programme COBOL qui lit des données d'une table DB2 alimentée par un traitement par lots JCL. Les dépendances qui transcendent les frontières des langages sont celles que les outils d'infrastructure ne peuvent pas détecter et qui engendrent les coûts de migration les plus élevés.

Identification du code mort. Les composants sans aucune référence entrante depuis un chemin d'exécution en production peuvent être entièrement exclus du périmètre de migration. La modernisation des systèmes existants en 2026 exige de passer de systèmes monolithiques rigides à des architectures modernes, agiles et évolutives. Or, migrer du code mort vers le cloud engendre des coûts d'infrastructure inutiles en production.

Classification de la complexité. Les composants complexes et fortement interdépendants sont les plus coûteux à migrer et les plus susceptibles d'entraîner des dépassements de coûts. Les identifier lors de l'évaluation, plutôt que de les découvrir en cours d'exécution, permet de distinguer un budget de migration intégrant une marge de sécurité adéquate d'un budget reposant sur des hypothèses optimistes.

Étendue des impacts pour toute modification proposée. Avant toute modification, refactorisation ou déplacement d'un composant, le modèle structurel répond à la question : quelles autres conséquences aura cette modification ? La réponse transforme les risques inconnus en une liste structurée et énumérable des composants nécessitant une validation.

Pourquoi l'écart d'observabilité est-il plus important pour les systèmes hérités et les systèmes mainframe ?

Les environnements cloud qui se développent par une migration rapide et non maîtrisée accumulent les risques liés aux lacunes entre les outils, les équipes et les responsabilités. Pour les organisations migrant des portefeuilles d'applications web modernes, ce fossé est important. Pour celles migrant des charges de travail mainframe (COBOL, JCL, PL/I, RPG), il est souvent déterminant.

Les applications mainframe accumulent une complexité qu'aucune analyse d'infrastructure ne peut révéler. Une logique métier imbriquée dans des blocs COBOL modifiés par une douzaine de développeurs sur une période de trente ans. Des flux de travaux JCL avec des chemins d'exécution conditionnels qui ne s'activent que sous certaines conditions métier. Des copybooks inclus simultanément par des centaines de programmes, où le simple renommage d'un champ affecte tous les programmes de la chaîne. Des ensembles de données servant de contrats de données implicites entre des programmes qui ne s'appellent jamais explicitement.

La plupart des échecs de modernisation sont du type « lift-and-shift ». Migrer vers une nouvelle plateforme sans repenser l'architecture ne fait que déplacer la dette technique. C'est particulièrement vrai pour les charges de travail mainframe. Convertir un programme COBOL en Java sans comprendre sa structure interne, ses dépendances et ses flux de données produit un code Java présentant les mêmes problèmes structurels que le COBOL, mais exécuté cette fois sur une infrastructure cloud facturée en continu.

L'observabilité structurelle qui comble cette lacune, pour les systèmes mainframe et les portefeuilles multilingues, nécessite des outils capables de comprendre simultanément chaque langage de l'environnement et de retracer les dépendances au-delà des frontières linguistiques qui créent les angles morts les plus dangereux.

Le lien avec FinOps : On ne peut gouverner ce qu’on ne voit pas

FinOps est une discipline de gestion financière qui responsabilise les équipes et les charges de travail en matière de dépenses cloud, remplaçant ainsi une facturation opaque par une gouvernance des coûts précise et exploitable. Chaque cadre FinOps, qu'il s'agisse de la gouvernance des balises, de la refacturation ou de l'optimisation de la capacité réservée, repose sur une connaissance précise des ressources exécutées et de leurs coûts.

Les organisations qui échouent en matière d'opérations financières sont celles qui n'ont pas établi d'inventaire structurel avant la migration. Elles ne peuvent pas étiqueter les ressources avec précision car elles ignorent à quelle charge de travail elles appartiennent. Elles ne peuvent pas imputer les coûts car la propriété des composants migrés n'a jamais été définie en fonction de la structure réelle des composants. Elles ne peuvent pas dimensionner correctement la capacité réservée car elles ignorent quelles charges de travail sont stables ou variables, ce qui nécessite de comprendre la fonction de la charge de travail, et pas seulement sa consommation de ressources.

L'élément manquant est une stratégie qui relie la budgétisation, l'observabilité et les activités de migration vers le cloud aux résultats concrets, tels que la croissance de l'entreprise, l'expérience utilisateur et le délai de mise sur le marché. Ce lien est impossible sans une base structurelle solide : un modèle précis du portefeuille d'applications avant même la rédaction du plan de migration.

Comment SMART TS XL Comble le déficit d'observabilité avant la migration

SMART TS XL Il fournit la couche d'observabilité structurelle requise pour l'évaluation de la migration vers le cloud, mais que les outils de découverte d'infrastructure ne peuvent pas produire. En analysant le code source de chaque application du portefeuille (COBOL, JCL, Java, Python, RPG, PL/I, SQL et langages modernes), il construit le modèle de dépendance unifié qui rend visible l'invisible avant le début de la migration.

L' analyse de modernisation des systèmes existants commence par un inventaire complet : tous les programmes, copybooks, schémas et flux de tâches de l'environnement, y compris les composants non documentés. Il s'agit du périmètre réel de la migration, établi à partir du code et non d'estimations.

Le mappage des dépendances applicatives retrace chaque relation entre les composants, au-delà des frontières des langages : du service Java qui appelle le programme COBOL qui lit les données de la table DB2 alimentée par le traitement par lots JCL. Ce graphe de dépendances interlangages sert de base à la séquence des vagues de migration : les composants sans dépendances en amont migrent en premier ; ceux dont dépendent de nombreux autres migrent en dernier, une fois leurs dépendances prêtes.

La fonctionnalité d'analyse d'impact transforme le graphe de dépendances en un plan de migration opérationnel : avant tout déplacement ou refactoring de composant, il convient d'énumérer tous les autres composants concernés, de définir le périmètre de la validation et d'identifier les composants présentant le risque de migration le plus élevé. Cette approche permet de passer d'une démarche informelle (« on verra bien ») à un programme structuré et fondé sur des données probantes, avec un périmètre défini à chaque étape.

La fonction de recherche d'entreprise permet d'interroger l'intégralité du modèle structurel tout au long du programme de migration : retrouvez en quelques secondes chaque utilisation d'une fonction spécifique, chaque programme lisant un ensemble de données particulier, chaque composant affecté par une modification de schéma, et ce, sur des millions de lignes de code dans n'importe quelle combinaison de langages. C'est cette fonction de recherche qui garantit la pertinence du modèle structurel pendant un programme de migration pluriannuel, au lieu de le réduire à un simple outil d'évaluation ponctuel voué à devenir obsolète.

Combler le fossé avant l'ouverture du budget

Les DSI les plus performants dans ce contexte ne sont pas forcément ceux qui disposent des budgets de modernisation les plus importants. Ce sont ceux qui savent évaluer le coût de l'inaction avec autant de précision que celui de l'action. Cette même précision s'applique à l'écart d'observabilité. La question n'est pas de savoir si l'analyse structurelle préalable à la migration a un coût en temps et en argent – ​​elle en a un. La question est de savoir si ce coût est inférieur à celui de la découverte de la complexité structurelle pendant l'exécution de la migration, ce qui, dans toutes les organisations ayant mené cette expérience, s'avère systématiquement être le cas.

Les entreprises qui façonneront la prochaine décennie ne sont pas celles qui ont déployé le plus de technologies, mais celles qui ont compris leur fonctionnement. Le retour sur investissement de la modernisation vers le cloud n'est pas avant tout une question de cloud, mais de connaissances. Connaissez-vous la composition de votre parc applicatif ? Savez-vous comment ses composants interagissent ? Savez-vous quel sera l'impact d'une modification sur l'un d'eux ? Les organisations capables de répondre à ces questions avant la migration sont celles dont les programmes de modernisation vers le cloud atteignent le retour sur investissement escompté. Les autres découvrent rapidement l'écart dans leurs factures cloud.