Pourquoi une modernisation progressive peut être plus efficace

Une étape de modernisation plus réduite peut être la décision d’ingénierie la plus mature lorsqu’elle laisse un système utile, déployable, observable et exploitable en production. Aller plus loin vers une architecture cloud-native peut produire de moins bons résultats lorsque l’équipe et le modèle opérationnel ne peuvent pas prendre en charge ce qu’ils introduisent. Pour les CTO, la décision centrale consiste donc à déterminer quelle capacité ajouter ensuite tout en maintenant la cohérence de chaque état intermédiaire en production.

La modernisation commence par la contrainte

Cette décision compte parce que la plupart des travaux de modernisation en 2025 concernent des systèmes établis. Une cible typique est un monolithe back-end vieux de 10 à 20 ans exécuté sur .NET Framework 4.x sous Windows Server, traitant la paie ou les commandes sur une base de données qui n’a pas été restructurée depuis plus de dix ans. Le Konveyor State of Application Modernization Report (2024) a constaté que 59 % des budgets de modernisation sont consacrés aux applications et infrastructures legacy existantes.

Cette focalisation sur les systèmes existants change ce qui doit être considéré comme de la modernisation en 2025–2026. Konveyor a constaté que 68 % des organisations définissent la modernisation comme l’amélioration des pipelines CI/CD, tandis que la sécurité, la fiabilité et la scalabilité sont chacune des moteurs pour plus de 70 % d’entre elles. Ces priorités donnent aux CTO des raisons concrètes de financer la réduction des risques et la résilience même lorsque les frontières applicatives restent inchangées. Un plan de modernisation peut être substantiel tout en préservant l’architecture existante.

Au sein de ces environnements, les organisations doivent aussi décider par où commencer. Konveyor place les applications back-end cœur de métier en premier à 41 %, suivies des données et de l’analytics à 35 %. Pour un ancien système de paie ou de gestion des commandes, la question pratique est de savoir comment rendre la production plus sûre et les changements plus faciles sans créer plus de difficultés opérationnelles que l’équipe ne peut en absorber. Ce même critère change la manière dont une migration cloud doit être évaluée.

La migration cloud dépend de la capacité opérationnelle

Ce critère compte parce que DORA 2024 donne une raison d’évaluer la migration cloud selon la capacité opérationnelle plutôt que selon la quantité d’infrastructure déplacée. Les organisations qui utilisent une infrastructure cloud sans satisfaire aux cinq caractéristiques du cloud définies par le NIST affichent des performances organisationnelles en baisse par rapport aux organisations qui restent on-prem. Le changement incrémental a de la valeur lorsque l’état obtenu fonctionne de manière cohérente en production.

Les cinq caractéristiques du NIST expliquent ce constat : libre-service à la demande, accès réseau étendu, mutualisation des ressources, élasticité rapide et service mesuré. DORA a constaté qu’une infrastructure cloud flexible augmente directement la performance organisationnelle ; le bénéfice dépend donc de l’obtention de ces propriétés opérationnelles. Un compte cloud et des machines hébergées dans le cloud ne suffisent pas à les créer.

Prenons une équipe qui déplace ses machines virtuelles existantes vers AWS tout en conservant le processus opérationnel précédent. Sans auto-scaling, infrastructure as code ni provisioning automatisé, la capacité reste rigide et les changements d’infrastructure restent manuels. L’organisation paie désormais les coûts du cloud et travaille avec un plan de contrôle peu familier tout en conservant les limites qu’elle voulait supprimer. L’emplacement de l’infrastructure a changé, mais la capacité de l’équipe à l’exploiter ne s’est pas améliorée en conséquence.

Cet écart entre emplacement et capacité définit le rôle approprié du rehosting. Le rehosting déplace une application telle quelle vers une infrastructure cloud, ce qui peut être utile lorsqu’un bail de centre de données arrive à expiration, que l’infrastructure doit être consolidée ou qu’une échéance de conformité impose un déplacement. Sous ces contraintes, changer d’abord l’infrastructure peut constituer un état temporaire défendable, car cela résout le problème immédiat tout en limitant les changements applicatifs.

Le rehosting devient problématique lorsque l’organisation traite cet état temporaire comme la destination. Le déplacement modifie l’infrastructure sans apporter l’automatisation et l’élasticité qui rendent le cloud utile, laissant l’organisation exposée au mode d’échec identifié par DORA. Un état intermédiaire solide a deux exigences : il doit résoudre une contrainte métier ou opérationnelle actuelle, et l’équipe doit être capable de l’exploiter efficacement. Ces exigences s’appliquent tout aussi fortement aux conteneurs, aux plateformes et aux microservices.

Construire la base de delivery et d’exploitation avant de changer l’architecture

Parce que l’architecture ajoute des exigences d’exploitation, le premier écart de capacité à combler est souvent celui du delivery. CI/CD, infrastructure as code, gates de tests automatisés et déploiements automatisés établissent un chemin répétable entre un changement de code et la production. Si une release dépend encore d’une personne qui clique dans un assistant de déploiement ou utilise SSH pour copier des fichiers en production, répartir la même application entre plusieurs services multiplie ce processus fragile.

Ce chemin répétable a aussi besoin d’une infrastructure reproductible. Terraform et CloudFormation peuvent faire passer les changements d’infrastructure par un processus contrôlé en parallèle du delivery applicatif. Les gates de tests détectent les régressions avant le déploiement, tandis que l’automatisation supprime les étapes manuelles de release. Ensemble, ces capacités rendent les changements d’architecture ultérieurs gérables, car l’équipe peut modifier et restaurer les systèmes de manière cohérente.

Un delivery cohérent a besoin d’un équivalent côté exploitation. L’observabilité consiste à disposer de métriques, de logs et de traces qui permettent aux ingénieurs de comprendre un système en fonctionnement à travers ses composants. Avant toute décomposition, un test pratique de préparation consiste à vérifier si l’équipe peut identifier le service responsable d’un pic de latence en 60 secondes. Si trouver le composant responsable demande déjà une investigation importante, répartir l’exécution sur davantage de processus et de frontières réseau rendra le diagnostic en production plus difficile.

Cette charge de diagnostic compte parce que les organisations citent déjà la complexité comme leur principal défi de modernisation. Konveyor a constaté que la complexité est citée par 48 % au global et par 58 % des organisations aux premiers stades de la modernisation. La découverte des dépendances, la migration des données et la préservation de la stabilité deviennent toutes plus difficiles à mesure que davantage d’éléments mobiles sont introduits. L’architecture doit consommer de la maturité opérationnelle plutôt qu’être censée la créer.

La même dépendance s’applique au platform engineering. DORA 2024 a constaté que les plateformes internes pour développeurs peuvent améliorer la productivité et la performance organisationnelle, mais que des plateformes mal conçues peuvent réduire la stabilité des changements et le débit de déploiement. Une plateforme qui impose des workflows peu fiables ou des toolchains rigides peut devenir un autre goulot d’étranglement du delivery. Établir d’abord CI/CD et la conteneurisation donne au platform engineering des processus stables à standardiser et à améliorer.

Même avec cette base, l’ordonnancement variera selon les organisations. L’âge du système, la capacité de l’équipe et l’horizon de planification modifient la décision appropriée ; un plan sur 12 mois peut rationnellement produire une architecture différente d’un plan sur 36 mois pour la même application. La disponibilité des outils doit découler de cette décision, car les outils mettent en œuvre une approche plutôt qu’ils ne définissent le problème. La prochaine étape de modernisation doit d’abord répondre à une contrainte de charge de travail.

Choisir le plus petit changement d’architecture qui résout la contrainte actuelle

Une fois la base opérationnelle clarifiée, une décision au niveau de la charge de travail commence par demander ce qui doit réellement changer : l’infrastructure, le runtime et le déploiement, le code applicatif et le pipeline, ou l’architecture et les frontières entre équipes. Cela correspond au rehosting, au replatforming, au refactoring et à la décomposition. Chacun peut produire un état intermédiaire utile, car chacun traite une catégorie de problème différente.

Lorsque le runtime et le déploiement constituent la contrainte, le replatforming préserve la logique applicative tout en changeant la manière dont le système s’exécute et est déployé. Une équipe peut prendre un monolithe .NET Framework existant et l’exécuter dans des conteneurs Windows sur Amazon ECS ou Amazon EKS, obtenant ainsi une unité de déploiement plus cohérente et une voie plus simple vers un delivery automatisé. Pour un monolithe dont le comportement métier reste solide mais dont l’exploitation est pénible, cela peut supprimer l’obstacle immédiat sans exiger une réécriture du code.

Lorsque le code applicatif ou le pipeline de delivery devient la contrainte, le refactoring va plus loin. Une équipe peut migrer de .NET Framework vers .NET 6 ou .NET 8, produire des images de conteneurs Linux, gérer l’infrastructure via Terraform ou CloudFormation, et ajouter des tests et déploiements automatisés. Cela peut constituer un résultat de modernisation significatif tout en préservant une seule frontière applicative. Si la vraie difficulté réside toutefois dans le modèle de domaine, la mise à niveau du framework laissera ce problème structurel en place.

Lorsque le déploiement indépendant a une valeur organisationnelle concrète, la décomposition devient appropriée. Plusieurs équipes travaillant dans des domaines métier distincts peuvent avoir besoin de leurs propres cycles de release ; à ce moment-là, des domaines délimités peuvent devenir des microservices ou des fonctions serverless déployables indépendamment. Trois développeurs qui maintiennent un seul système n’obtiennent pas un tel avantage simplement en introduisant des microservices. Un monolithe bien structuré au service de deux équipes peut surpasser des microservices mal délimités au service de ces mêmes équipes.

Une fois la décomposition justifiée, le domain-driven design fournit un moyen de décider où la séparation doit se situer. Les équipes identifient des bounded contexts, c’est-à-dire des domaines métier dotés de modèles et de responsabilités cohérents, avant d’extraire des services. L’observabilité en production vérifie ensuite si ces frontières se comportent réellement de manière indépendante sous des charges de travail réelles. Une frontière de service qui semble propre dans le code mais exige de façon répétée des changements coordonnés en production a échoué à une partie importante de ce test.

Des frontières mal choisies peuvent au contraire créer un monolithe distribué, c’est-à-dire un système scindé en composants déployables séparément mais qui restent étroitement couplés en exploitation. Ces frontières ajoutent des appels réseau, de la découverte de services et du distributed tracing, tandis que les releases exigent toujours que les équipes coordonnent les changements entre services. L’organisation a acquis la complexité opérationnelle de la distribution sans gagner en delivery indépendant. CI/CD et l’observabilité sont des prérequis, car la distribution étend les défaillances et les dépendances que les ingénieurs doivent déployer, détecter et diagnostiquer.

Pour les systèmes qui nécessitent une extraction progressive, le pattern Strangler Fig permet de maintenir l’application legacy opérationnelle pendant que le trafic est progressivement déplacé vers de nouveaux services. De nouvelles capacités peuvent être placées dans de nouveaux services, les fonctions existantes peuvent être retirées de manière incrémentale, et l’ancienne application peut finir par disparaître à mesure que ses responsabilités diminuent. Le système de production reste utile tout au long du processus, de sorte que la décomposition progresse par états fonctionnels plutôt qu’en dépendant d’un unique basculement futur.

Les données peuvent nécessiter une séquence distincte, car coupler les déplacements de l’application et de la base de données crée un risque de migration supplémentaire. Une voie praticable consiste à laisser la base de données on-prem lors du déplacement initial de l’application, puis à séparer progressivement les schémas par domaine. Cela permet de valider indépendamment la migration de l’application et la restructuration de la base de données. Les schémas partagés de longue durée restent difficiles, mais cette difficulté n’impose pas que les deux changements aient lieu simultanément.

Le même test de charge de travail s’applique à l’architecture serverless. Des composants isolés avec traitement piloté par événements, pics d’activité, haut débit ou forte variation de trafic peuvent convenir à des fonctions serverless, car la capacité n’a pas besoin de rester provisionnée pendant les périodes calmes. La plateforme de collecte de fonds de Techstack utilise AWS Lambda pour le traitement à haut débit des dons, en absorbant les pics de dons sans maintenir de capacité inactive entre eux. Techstack vend des services technologiques et de modernisation ; l’entreprise a donc un intérêt commercial à présenter ses choix d’implémentation comme efficaces.

Un système de gestion des commandes entièrement implémenté sous forme de fonctions Lambda présente une charge de travail différente et peut créer une complexité excessive. Le serverless est une option d’architecture sélective dont la valeur dépend du composant déplacé. La question pertinente est de savoir si les caractéristiques d’exécution et de trafic justifient des fonctions pour ce composant.

Après le choix d’architecture vient l’outillage. AWS App2Container et AWS Microservice Extractor peuvent aider les équipes à exécuter ces choix pour des charges de travail .NET, tout comme Amazon ECS, Amazon EKS et AWS Lambda peuvent héberger différentes architectures résultantes. AWS bénéficie commercialement lorsque les organisations adoptent ses outils de migration et ses services cloud ; ces produits doivent donc être évalués comme des implémentations d’une approche déjà choisie. Sélectionner l’outillage après avoir identifié la contrainte de charge de travail évite qu’un outil de migration pratique ne décide des frontières de service ou n’impose une décomposition que l’organisation ne peut pas encore exploiter.

Tipalti et Techstack montrent différents états intermédiaires utiles

Le mouvement plus large vers le changement incrémental apparaît dans un cas présenté en 2026 par l’AWS Architecture Blog à propos de Tipalti. AWS, qui bénéficie commercialement de l’adoption d’Amazon EKS et de ses autres services cloud, a décrit comment l’entreprise d’automatisation des paiements a déplacé un monolithe legacy .NET Framework 4.7 vers des images Windows Server 2019 Core exécutées sur Amazon EKS. Tipalti a utilisé cinq phases de migration et validé chaque phase, évitant une réécriture complète et des interruptions de production. Ce cas présente la conteneurisation incrémentale comme une alternative à une réécriture big bang.

L’unité de progression de Tipalti montre pourquoi cette approche peut être substantielle. Le monolithe existant pouvait être conteneurisé par étapes et testé comme système de production en fonctionnement avant tout changement supplémentaire, tandis que la décomposition pouvait attendre qu’il existe une raison de l’entreprendre. Un monolithe conteneurisé peut être un état de modernisation délibéré lorsqu’il améliore le déploiement et l’exploitation et qu’il peut être pris en charge de manière fiable. La distribution architecturale n’est qu’un choix ultérieur possible.

Un autre type d’état intermédiaire apparaît dans le travail client de Techstack. Un client disposait de plusieurs monolithes legacy assurant différentes fonctions métier, et les découper tous aurait demandé des années. Techstack a relié les systèmes en un seul écosystème à l’aide d’un pattern de menu à 9 points tout en laissant les monolithes sous-jacents intacts. Les utilisateurs ont bénéficié d’un point d’entrée unique, et le client a évité une réécriture sur plusieurs années.

Ce cas d’intégration illustre aussi le processus de décision déclaré par Techstack. L’approche de Techstack commence par l’évaluation du système, la sélection d’une approche charge de travail par charge de travail, une livraison incrémentale et l’introduction de l’observabilité dès le départ. En tant que prestataire de services technologiques et de modernisation, Techstack a un intérêt commercial à ce que les clients adoptent ce type d’approche de modernisation. Dans l’exemple client, cette séquence a amélioré l’expérience utilisateur unifiée avant que l’organisation ne s’engage à réécrire des systèmes fonctionnels.

Les deux cas partagent un même critère : le résultat intermédiaire en production est utile. Tipalti a modifié le runtime et le déploiement au moyen d’un effort de conteneurisation en cinq phases, tandis que Techstack a modifié l’intégration et le point d’entrée utilisateur tout en préservant plusieurs applications sous-jacentes. Leurs mécanismes diffèrent, mais chacun a produit un résultat exploitable avant un changement architectural plus profond.

L’IA peut accélérer les travaux de modernisation

La même importance accordée à l’ordonnancement s’applique à la modernisation assistée par l’IA, car l’automatisation change la vitesse à laquelle les équipes peuvent effectuer le travail préparatoire. Konveyor 2024 a constaté que plus de 75 % des organisations utilisent l’IA dans la modernisation applicative, avec des usages pratiques incluant la cartographie des dépendances, l’identification de candidats au refactoring via l’analyse de code et la génération de tests. Ces tâches peuvent réduire le travail de découverte et de préparation autour d’une ancienne base de code.

Cette aide est particulièrement pertinente pour une grande application .NET Framework avec une faible couverture de tests. L’IA peut générer des tests de base autour des chemins critiques avant que les ingénieurs ne refactorisent le code, leur donnant davantage d’éléments sur les régressions à mesure que les changements avancent. Elle peut aussi mettre au jour des dépendances qui doivent être étudiées avant le déplacement de modules. Ces résultats améliorent les éléments factuels disponibles pour la prochaine décision d’ingénierie.

La décision elle-même dépend toujours des conséquences architecturales. Les ingénieurs doivent décider quelles capacités méritent d’être extraites, quand les données partagées doivent être séparées, et si la charge de travail d’un composant rend le serverless approprié. L’IA peut accélérer la découverte, l’analyse et la création de tests une fois que l’équipe comprend le travail qu’elle envisage. La justification architecturale continue de venir de la charge de travail, de l’équipe et des exigences opérationnelles.

Mesurer la modernisation à l’aune des progrès en production

Ces décisions d’architecture ne deviennent utiles que lorsque le rythme opérationnel expose suffisamment tôt leur valeur en production pour survivre aux contraintes organisationnelles. Une initiative de modernisation devrait mettre en production un composant modernisé et fonctionnel dans les trois mois ; des basculements prévus 18 mois plus tard ont peu de chances de survivre aux revues budgétaires. Une livraison trimestrielle donne aux dirigeants la preuve que l’investissement transforme un système en fonctionnement tout en laissant la possibilité d’ajuster l’étape suivante.

Ce rythme transforme la modernisation en un travail d’ingénierie continu avec des preuves répétées en production. Les équipes peuvent continuer à améliorer le CI/CD et l’observabilité et décomposer des parties d’un système à mesure que le déploiement indépendant devient utile, au lieu d’attendre un basculement propre sur deux ans. Chaque mise en production vérifie alors si l’organisation peut prendre en charge la capacité qu’elle a introduite dans des conditions d’exploitation réelles.

Les preuves en production doivent, au final, être reliées aux utilisateurs. DORA 2024 identifie l’orientation utilisateur comme le prédicteur le plus fort de la performance organisationnelle. Une livraison plus rapide des fonctionnalités, une meilleure fiabilité et une latence plus faible donnent aux équipes des résultats concrets sur lesquels juger les dépenses de modernisation et décider quel changement d’ingénierie doit venir ensuite.

En conclusion

Pour les dirigeants, le succès de la modernisation applicative ne doit pas être mesuré à l’aune de la distance parcourue par un système vers un idéal cloud-native. Il doit être mesuré selon la capacité de chaque investissement à améliorer l’aptitude de l’organisation à livrer, exploiter et faire évoluer ce système tout en produisant un résultat utile en production.

Cela fait de la modernisation une décision d’ordonnancement autant qu’une décision technologique. CI/CD, infrastructure as code, observabilité, conteneurisation, refactoring et décomposition résolvent chacun des contraintes différentes et introduisent des exigences d’exploitation différentes. La bonne étape suivante est la plus petite qui traite une contrainte significative sans créer une complexité que l’organisation ne peut pas encore prendre en charge.

Cette approche donne aussi à la direction des jalons d’investissement plus clairs. Plutôt que de financer une transformation sur plusieurs années dont la valeur dépend d’un basculement final, les dirigeants peuvent exiger des progrès mesurables en production en quelques mois et utiliser la fiabilité, la vitesse de delivery, les résultats utilisateurs et le coût d’exploitation pour décider de la suite. Certains systèmes pourront à terme justifier des architectures microservices ou serverless ; d’autres pourront créer davantage de valeur en restant des monolithes bien exploités.

L’objectif n’est pas de moderniser chaque système autant que possible. Il s’agit de construire les capacités dont l’entreprise a besoin, dans un ordre que l’organisation peut soutenir.