La modernisation des applications est le processus de mise à jour de vos applications existantes (infrastructure, architecture, code ou couche de données) pour qu'elles fonctionnent avec des technologies modernes et des outils pilotés par l'IA. La modernisation de votre portefeuille d'applications implique généralement des corrections rapides ainsi que des refontes plus approfondies, et peut être effectuée par étapes.
Principaux points à retenir
- La modernisation de vos applications existantes est un processus flexible : vous pouvez utiliser le cadre des 7 R pour décider ce qu’il faut mettre à jour, ce qu’il faut laisser tel quel et ce qu’il faut abandonner.
- Les R du cadre des 7 R (retain pour conserver, retire pour supprimer, rehost pour renouveler l’hébergement, replatform pour changer de plate-forme, refactor pour remanier, rearchitect pour modifier l’architecture et rebuild pour reconstruire) peuvent être combinés pour répondre à vos besoins technologiques et commerciaux.
- Vous n’avez pas besoin de tout moderniser simultanément : la mise à niveau d’un élément technologique à la fois est moins risquée que d’essayer de remplacer un système entier en une seule fois.
- Une base de données existante est souvent négligée dans la modernisation des applications, mais elle peut causer des goulots d'étranglement si elle n'est pas modernisée avec le reste du système.
- L’IA change la vitesse à laquelle la modernisation peut se produire : de nouveaux outils peuvent désormais réécrire le code existant et générer des tests par eux-mêmes, ce qui raccourcit considérablement les délais de modernisation.
- La modernisation ne concerne pas uniquement la technologie, elle nécessite également une direction, des objectifs mesurables et une feuille de route qui permet de rester sur la bonne voie.
Sommaire
- Qu'est-ce que la modernisation des applications ?
- Pourquoi devez-vous moderniser vos applications existantes ?
- Comment évaluez-vous les applications héritées ?
- Que sont les 7 R de la modernisation ?
- La modernisation des applications est une stratégie globale
- Quelles stratégies de modernisation des applications sont les plus efficaces ?
- Pourquoi les bases de données doivent être incluses dans les plans de modernisation des applications
- Comment l'IA transforme-t-elle la modernisation des applications ?
- De quels outils et services avez-vous besoin pour la modernisation ?
- Comment établir une feuille de route de modernisation des applications ?
- Votre liste de contrôle du retour sur investissement de la modernisation
- Quelles sont vos prochaines étapes pour la modernisation des applications ?
- Ressources connexes
Qu'est-ce que la modernisation des applications ?
La modernisation des applications est le processus de mise à jour des applications héritées existantes pour qu’elles fonctionnent avec la technologie moderne, l’infrastructure et les exigences métier actuelles. Cela ne signifie pas nécessairement le remplacement d’un système entier. Au lieu de cela, la modernisation des applications comprend généralement la mise à niveau de la plate-forme, de l’architecture, du code ou de la couche de données, souvent par étapes. Les correctifs courants incluent le déplacement d’une application vers le cloud tel quel, la division d’une grande application en services indépendants plus petits ou la suppression des applications qui ne valent pas la peine d’être conservées.
La raison pour laquelle la modernisation des applications est devenue urgente pour tant d'organisations est que les systèmes hérités qui font fonctionner leurs activités ont été conçus pour une époque différente : ils fonctionnent toujours, mais ils ne peuvent pas suivre le rythme des besoins des entreprises modernes. Pour la plupart des entreprises, la modernisation des applications ne se limite pas à un projet informatique : c'est un élément fondamental d'une transformation numérique plus vaste.
Cas pratique : où commencent souvent les problèmes de modernisation des applications
Kai est la vice-présidente de l’ingénierie d’une banque régionale pesant 40 milliards de dollars US dotée d’une solide base de vente au détail et d’une division de gestion de patrimoine en pleine croissance. La plate-forme de la banque a été déployée en 2003 et fonctionne toujours. Les clients effectuent des transactions et il n’y a aucun problème système évident.
Cependant, ce n’est pas parce que les applications de la banque fonctionnent aujourd’hui qu'elles prendront en charge ce que la banque a prévu pour un avenir proche, comme de nouvelles fonctionnalités mobiles, la détection automatisée des fraudes et une expérience client plus connectée.
La majeure partie de la pression à la modernisation se concentre sur la couche de données. Une plate-forme créée en 2003 avec une structure relationnelle rigide enregistre bien les transactions, mais elle peine à gérer les données non structurées et à haut volume dont dépendent les charges de travail d’IA comme la détection des fraudes. Cette inadéquation est souvent ce qui pousse les équipes à moderniser en premier lieu, et c’est là qu’un modèle documentaire souple comme MongoDB a tendance à s’adapter, puisqu’il est conçu pour traiter divers types de données et évoluer à mesure que la demande augmente.
Pourquoi devez-vous moderniser vos applications existantes ?
La modernisation des applications est l’une des catégories de dépenses technologiques des entreprises qui connaît la croissance la plus rapide : le marché mondial des services de modernisation devrait passer de 19,82 milliards de dollars en 2024 à 39,62 milliards de dollars d’ici 2029, selon MarketsandMarkets.
De nombreuses entreprises commencent à moderniser leurs applications existantes lorsque le coût de leur maintien en activité dépasse celui de leur transformation. Ce coût ne se limite pas à des montants financiers : il se traduit par des risques en matière de sécurité, des performances ralenties et l’insatisfaction des clients.
Vous trouverez ci-dessous des raisons courantes pour lesquelles vous pourriez vouloir moderniser :
La concurrence évolue plus vite que vous : les entreprises plus récentes de votre secteur n’ont pas autant de problèmes actuels que vous, ce qui signifie qu’elles peuvent lancer de nouvelles fonctionnalités plus rapidement, et vos clients commencent à remarquer que vous ne suivez pas le rythme.
Les coûts de maintenance grignotent votre budget: Des études sectorielles suggèrent que les organisations consacrent 60 % à 80 % de leur budget informatique au simple maintien en état de leurs anciens systèmes. Les recherches de McKinsey ont montré que la modernisation peut réduire les coûts d'infrastructure informatique de 50 %. La modernisation n’est pas gratuite, mais l’inaction a également un coût ; protéger vos investissements existants implique souvent de les moderniser.
Vos systèmes ne peuvent pas gérer les charges de travail modernes : vos anciennes applications ont probablement été conçues pour gérer un nombre d’utilisateurs, de transactions et de données moins important que ce que génèrent les entreprises modernes. Des ralentissements ou des plantages peuvent apparaître lorsque le trafic augmente ou que les volumes de données augmentent.
La sécurité devient plus difficile à gérer : les acteurs malveillants adorent les applications existantes car elles sont plus faciles à pirater. Beaucoup ne peuvent pas prendre en charge les outils de sécurité modernes et ne proposent plus de correctifs.
Vous ne pouvez pas embaucher (ou garder) les ingénieurs dont vous avez besoin : de nombreux ingénieurs ne souhaitent pas travailler avec des technologies obsolètes, ils partiront donc en emportant avec eux toutes leurs précieuses connaissances. Trouver leur remplaçant peut s’avérer difficile.
Vous ne pouvez pas ajouter de nouvelles fonctionnalités : tous les outils modernes (agents d’IA, apprentissage automatique, données en temps réel et automatisation) sont presque impossibles à ajouter aux applications existantes car elles n’ont pas été conçues pour les prendre en charge.
La plupart des entreprises ne sont pas confrontées à une seule de ces pressions, mais à plusieurs simultanément. C’est généralement ce qui fait basculer la décision de modernisation d’« un jour » à « maintenant ».
CONSEIL TECHNIQUE : qu’est-ce que la dette technique ?
Vous avez peut-être entendu l'expression « dette technique », mais que signifie-t-elle ? La dette technique est l’impact cumulé de la non-modernisation de votre code, de votre architecture ou de votre infrastructure. Chaque raccourci que vous avez utilisé pour maintenir votre système obsolète en état de marche vous a permis de gagner du temps sur le moment, mais a probablement compliqué les mises à niveau futures. Avec le temps, ces solutions de contournement rendent chaque modification supplémentaire plus lente, plus risquée et plus coûteuse.
Cas d’utilisation : Qu’est-ce qui motive Kai à moderniser ?
Pour Kai, les pressions liées à la modernisation se manifestent simultanément à plusieurs endroits :
Un fournisseur principal a récemment annoncé la fin de l’assistance pour l’une des plate-formes sous-jacentes de la banque.
Deux entreprises fintech régionales lancent des fonctionnalités mobiles que les clients de la banque réclament déjà.
Les ingénieurs en interne se plaignent d’avoir à maintenir un système vieux de plus de 20 ans.
Le dernier audit de sécurité de la banque a signalé le système existant comme un risque croissant car le cadre sous-jacent ne peut plus être corrigé.
Comme de nombreuses entreprises dans sa situation, Kai doit déterminer par où commencer.
Comment évaluez-vous les applications héritées ?
Avant de décider ce qu'il faut moderniser et comment, vous devez comprendre le coût du maintien en activité de vos applications actuelles. Les trois étapes ci-dessous peuvent vous aider à faire le point sur votre technologie actuelle et à vous engager sur la voie de la modernisation.
Étape 1 : réalisez l'inventaire
Pour avoir une vision d’ensemble, il est important de faire l’inventaire de ce dont vous disposez. Dressez la liste de toutes les applications utilisées par votre organisation ainsi que des systèmes dont elles dépendent. Interrogez les ingénieurs et les administrateurs système : ils vous aideront à localiser les anciennes applications, à découvrir les intégrations oubliées et à identifier les dépendances non documentées.
Étape 2 : évaluez votre dette technique
Un audit de dette technique examine l’état du code de l’application, l’ancienneté des cadres sous-jacents, sa capacité à rester protégé contre les menaces modernes et ses performances sous les charges de travail actuelles. Vous ne réaliserez probablement pas cette évaluation personnellement, mais votre équipe d’ingénierie s’en chargera. Cependant, vous devrez suffisamment comprendre leurs conclusions pour orienter la prochaine étape.
Étape 3 : Décider de ce qui mérite d'être modernisé
Une fois que vous aurez terminé votre inventaire et votre audit de la dette technique, l’étape suivante consistera à décider quelles applications méritent d’être mises à jour, lesquelles peuvent attendre et lesquelles doivent être supprimées. Pour ce faire, posez-vous deux questions sur chaque application : quelle est sa valeur pour votre entreprise et à quel point est-elle difficile à moderniser ?
Une fois que vous aurez répondu aux deux questions pour chaque application, vous saurez plus clairement quoi faire ensuite.
Si l'application est :
Précieuse et facile à mettre à jour, procédez à la modernisation.
Précieuse mais difficile à mettre à jour, découvrez ce qui est nécessaire et établissez un plan de modernisation.
Peu utile, demandez à votre équipe si ces applications sont toujours nécessaires. Si elles sont faciles à mettre à jour, modernisez-les lorsque vous en avez le temps. Si elles sont difficiles à mettre à jour, vous pouvez choisir de les supprimer.
ANALYSE APPROFONDIE : qu’est-ce qui est inclus dans un inventaire de modernisation ?
Un inventaire de modernisation inclut bien plus que de simples applications. Il se compose du code source, des dépendances d’exécution, des points d’intégration (API, transferts de fichiers, files d’attente de messages), des schémas de base de données, des travaux planifiés, des configurations d’infrastructure, des outils de surveillance et des personnes de votre entreprise qui savent comment tout fonctionne.
Cas pratique : ce que Kai découvre lorsqu’elle examine les choses de plus près
L’inventaire de Kai révèle 47 applications au sein des unités commerciales de la banque : 20 n’ont pas de propriétaire actuel car les personnes qui les maintenaient sont parties, 12 s’exécutent dans des cadres qui ne reçoivent plus de correctifs de sécurité, 8 chevauchent d’autres systèmes et 5 n’ont pas été utilisées depuis plus d’un an, mais la banque paie toujours des frais d’infrastructure. Maintenant que Kai y voit plus clair, elle peut commencer à décider ce qu’il faut moderniser en priorité et ce qu’il faut abandonner en suivant les 7 R de la modernisation.
Que sont les 7 R de la modernisation des applications ?
Les « 7 R » constituent un cadre de modernisation populaire que les entreprises utilisent pour évaluer leur portefeuille d’applications. Chaque décision de modernisation, d’une petite correction à une recréation complète, peut être alignée sur l’une de ces sept actions :
Retain (conserver) : prenez une décision explicite de laisser certaines applications telles quelles parce qu'elles fonctionnent toujours, ou parce que le coût de la modernisation ne justifiera pas le coût.
Retire (supprimer) : mettez définitivement hors service certaines applications parce qu’elles font doublon avec d’autres systèmes ou ne sont plus utilisées.
Rehost (renouveler l’hébergement) : déplacez l’application vers le cloud telle quelle, avec un minimum de modifications. Souvent appelé « lift and shift » (migration), le renouvellement de l’hébergement est rapide lorsque vous devez abandonner rapidement du matériel vieillissant. Une fois migrée, l’application fonctionne toujours de la même manière. Elle s’exécute simplement sur une infrastructure cloud, ce qui signifie que tous ses problèmes initiaux (c.-à-d. les limites de mise à l’échelle, la dette technique) l’accompagnent également.
Replatform (changer de plate-forme) : déplacez l’application dans le cloud, mais remplacez des composants spécifiques par des versions modernes et natives du cloud. Par exemple, vous pouvez remplacer une base de données autogérée par un service cloud géré tout en laissant les autres composants inchangés : l’application fonctionne toujours de la même manière du point de vue de l’utilisateur, mais sa modernisation réduit votre charge de maintenance.
Refactor (remanier) : nettoyez le code désordonné ou obsolète grâce au remaniement. Cela facilite la maintenance de l’application et réduit les risques, sans pour autant ajouter de nouvelles fonctionnalités.
Rearchitect (modifier l’architecture) : repensez la structure de l’application de manière significative, par exemple en divisant une grande application en éléments plus petits et indépendants (parfois appelés microservices), ou en changeant la façon dont l’application stocke et traite les données. Modifier l’architecture prend du temps et comporte des risques, car cela touche de nombreuses parties de l’architecture d’origine. C’est cependant souvent le seul moyen d’ajouter des fonctionnalités telles que les données en temps réel, l’intégration de l’IA ou la mise à l’échelle à la demande.
Rebuild (reconstruire) : créez une nouvelle application à partir de zéro, en ne conservant que les règles et les processus de l’ancien système qui sont encore utiles. La reconstruction est l’option la plus coûteuse, mais elle peut s’avérer nécessaire si votre application existante est trop obsolète pour être sauvée ou si le métier a tellement changé que le système d’origine ne fonctionne plus.
La modernisation des applications est une stratégie globale, et non une simple décision
La plupart des entreprises utilisent une modernisation incrémentielle, appliquant plusieurs des 7 R par incréments gérables en fonction de leurs besoins au lieu d’essayer de tout refondre en une seule fois.
Pour qu’une modernisation incrémentielle fonctionne, deux conditions doivent être réunies : un alignement entre vos objectifs de modernisation et vos objectifs métier, ainsi qu’une gouvernance appropriée des décisions (c’est-à-dire des indicateurs clés de performance, des structures de responsabilité et des critères de réussite clairs). L’étape suivante consiste à s’assurer que chaque décision fait progresser l’entreprise, souvent vers le cloud.
Le cadre de modernisation des applications prend tout son sens lorsque vous le voyez appliqué à un portefeuille réel : voyons comment Kai utilise les 7 R à la banque.
Cas pratique : comment Kai utilise-t-elle les 7 R de la modernisation des applications ?
Kai trie ses 47 applications par valeur et par effort, en alignant chacune d’entre elles sur l’un des 7 R. Sa première série de décisions en utilise quatre : supprimer, renouveler l’hébergement, modifier l’architecture et reconstruire.
Kai supprime l’outil d’établissement de rapports existant de la banque et le remplace par une plate-forme de renseignement économique moderne.
Elle renouvelle l’hébergement du système de notification client dans le cloud, une victoire rapide qui le préserve sans avoir à le reconstruire.
La plate-forme bancaire centrale est refondue car l’architecture d’origine ne peut plus prendre en charge les fonctionnalités mobiles ou la vue client unifiée souhaitée par l’équipe de planification.
L'application de détection de la fraude est reconstruite à partir de zéro car elle est tellement obsolète qu'elle ne peut plus recevoir de correctifs de sécurité, ce qui constitue un risque sérieux pour la banque.
Kai n’effectue pas ces mises à niveau de modernisation l'une après l’autre : elle les exécute en parallèle, avec différentes équipes responsables de différentes applications.
Quelles stratégies de modernisation des applications fonctionnent le mieux ?
Trois stratégies de modernisation des applications qui apparaissent le plus souvent dans les plans de modernisation incluent la migration vers le cloud, le passage du monolithe aux microservices, ainsi que l’adoption du cloud et du cloud hybride. Aucune de ces approches n’est un R unique issu du cadre ci-dessus : il s’agit de modèles qui combinent plusieurs R en fonction de la situation.
La migration vers le cloud est le point de départ le plus courant pour la modernisation des applications
Pour la plupart des entreprises, les migrations cloud prennent des années, pas des semaines, et c’est volontaire. Pour accélérer l’adoption du cloud, vous pouvez commencer par le renouvellement de l’hébergement cloud parce que vous devez cesser d’utiliser l'ancien matériel immédiatement, et retarder la modification de l’architecture cloud jusqu’à ce que vous puissiez évaluer vos applications actuelles plus en détail.
La conteneurisation est souvent utilisée pour les migrations par étapes. Les conteneurs englobent une application avec tout ce dont elle a besoin pour fonctionner. Vous pouvez ainsi l’exécuter sur votre infrastructure existante aujourd’hui, et dans le cloud le mois prochain. Cette portabilité vous permet de décider quand migrer au lieu d’être contraint de respecter un calendrier préétabli.
Lorsque vous migrez vos applications vers le cloud, vos dépenses y migrent également. Les achats importants d’infrastructures initiales sont remplacés par des coûts d’exploitation mensuels, ce qui permet généralement de réaliser des économies au fil du temps. Cependant, les applications existantes sur site peuvent rencontrer des problèmes de performance lors de la mise en œuvre du cloud. Les économies de coûts ne doivent donc pas être le seul moteur de votre décision de passer au cloud.
Les microservices sont le moyen le plus courant de décomposer un monolithe
De nombreuses applications existantes sont des monolithes : des applications tout-en-un où chaque fonctionnalité se trouve dans la même base de code. À mesure que les entreprises se développent, les monolithes deviennent difficiles à modifier, car tout ce qu’ils contiennent est interconnecté. La mise à jour d’une partie de l’application peut en casser une autre qui ne lui est pas liée.
Le contraire d’un monolithe est une architecture de microservices, où la même application est construite comme un ensemble de petits services indépendants qui fonctionnent ensemble. Chaque microservice (comme les comptes clients ou le traitement des paiements) possède son propre pipeline de déploiement et peut être mis à jour sans affecter les autres services.
La méthode la plus courante pour moderniser un monolithe consiste à utiliser des microservices via le modèle « strangler » :
Le monolithe reste intact tandis que de nouveaux microservices sont construits à ses côtés.
À mesure que chaque nouveau service est mis en ligne, il prend en charge une partie des tâches du monolithe.
À terme, tout le travail est transféré vers les microservices et le monolithe est retiré.
À partir de là, les microservices travaillent de concert pour fournir la même application, simplement sous forme de morceaux plus petits et plus flexibles.
Le nom « strangler » vient du figuier étrangleur, qui pousse autour de son hôte jusqu’à ce que l’hôte disparaisse.
Le cloud hybride est le choix le plus pratique pour la plupart des projets de modernisation d'applications d'entreprise
La plupart des grandes entreprises ne migrent pas tout vers le cloud : elles privilégient une approche hybride combinant services de cloud public et infrastructure sur site.
Les clouds hybrides sont généralement utilisés pour trois raisons principales :
Réglementations : certains secteurs exigent que certaines données restent sur une infrastructure privée. Les prestataires de soins de santé, par exemple, doivent souvent conserver les dossiers des patients dans des systèmes privés pour se conformer à la loi HIPAA. Les banques peuvent avoir besoin de conserver les données financières des clients dans des pays spécifiques pour se conformer aux lois locales.
Performances : certaines applications doivent être physiquement proches des personnes ou des systèmes qui les utilisent. Par exemple, les logiciels de ligne de production d’une usine peuvent devoir s’exécuter sur du matériel local afin de pouvoir réagir instantanément aux changements d’équipement. Tout retard dû à un cloud public distant pourrait perturber les activités.
Coût : certains travaux s’exécutent simplement à moindre coût sur le matériel que vous possédez déjà. Une entreprise ayant déjà investi dans son propre centre de données peut constater que les travaux de traitement par lots, comme les rapports financiers nocturnes, coûtent moins cher à exécuter sur une infrastructure existante que sur le cloud public.
Pourquoi les bases de données doivent être incluses dans les plans de modernisation des applications
La plupart des cadres de modernisation, dont les 7 R, se concentrent sur l’application : où elle s’exécute, comment le code est structuré et comment les équipes publient de nouvelles versions, et non sur la base de données existante. Cependant, ignorer une base de données vieille de 20 ans peut bloquer même le meilleur plan de modernisation, car la base de données n’a tout simplement pas été conçue pour ce dont vos applications modernisées auront besoin.
Une modernisation complète exige également la modernisation de la couche de données. Des outils tels que MongoDB Relational Migrator aident les équipes à abandonner les schémas relationnels rigides pour des modèles basés sur des documents plus souples qui s’alignent sur le fonctionnement actuel du métier.
Cas pratique : comment Kai découvre-t-elle le goulot d’étranglement de la base de données de la banque ?
Lorsque l’équipe de Kai commence à planifier la modification de l’architecture des services bancaires de base, elle suppose que le plus gros travail concerne le code de l’application, mais elle découvre rapidement que la base de données est elle-même un monolithe : une base de données relationnelle de 2 400 tableaux avec 800 procédures stockées qui contiennent une logique métier critique. Sans modification de l’architecture de la base de données parallèlement aux applications, l’équipe de Kai ne peut fournir aucune des capacités sur lesquelles la banque compte.
Kai n’est pas la seule à effectuer ce genre de découverte. Intellect Design, une entreprise internationale de technologie financière, a rencontré le même problème : une logique métier clé enfermée dans des centaines de procédures stockées SQL, avec des retards de traitement par lots qui limitaient les capacités de la plate-forme. Après avoir modernisé à la fois la couche de données et l’application grâce à MongoDB, Intellect Design a réduit ses temps de flux de travail d’intégration de 85 %, la preuve que la base de données fait partie intégrante d’une modernisation complète.
Comment l'IA transforme-t-elle la modernisation des applications ?
Jusqu’à récemment, le processus de modernisation signifiait des mois ou des années de travail manuel : les ingénieurs devaient lire le code existant, le réécrire ligne par ligne et effectuer des tests pour s’assurer que tout fonctionnait. L’IA a changé la donne.
Quatre domaines où l’IA fait la plus grande différence :
Transformation de code : les agents d’IA peuvent lire des bases de code vieillissantes (y compris des langages anciens comme le COBOL) et produire des équivalents modernes à des vitesses qui n’étaient pas possibles il y a deux ans.
Génération de tests: l’IA peut analyser le comportement d’une application existante et générer les tests nécessaires pour confirmer que la version modernisée peut effectuer le même travail.
Extraction de la logique métier: les applications héritées contiennent des années de règles métier enfouies dans leur code — comme la façon dont les taux d’intérêt sont calculés ou dont les transactions sont signalées pour examen. L’IA peut lire l’ancien code, trouver ces règles et les extraire sous forme d’éléments distincts et réutilisables, afin que les règles subsistent tandis que le reste de l’application est reconstruit.
Création de boucles de rétroaction : les applications modernisées peuvent collecter des données sur leurs performances en temps réel, notamment pour savoir si les décisions de l’IA sont correctes ou incorrectes. Ces données sont réinjectées dans l’IA, ce qui l’aide à s’améliorer au fil du temps. La plupart des applications existantes ne peuvent pas le faire, tandis que les applications modernisées sont conçues pour cela.
La plate-forme de modernisation des applications (AMP) de MongoDB associe des capacités d’IA à une méthodologie éprouvée et à une expertise technique. Pour les entreprises disposant d’applications existantes importantes, AMP peut réduire les délais de modernisation de deux à trois fois.
Par exemple, Bendigo et Adelaide Bank ont utilisé des outils d’IA pour réduire l’exécution des cas de test d’application de 80 heures à 5 minutes. La plupart des entreprises obtiennent les meilleurs résultats en testant les fonctionnalités d’IA de manière incrémentielle : en commençant par une seule application ou un seul flux de travail, en tirant des enseignements des résultats, puis en effectuant une mise à l’échelle.
De quels outils et services avez-vous besoin pour la modernisation ?
Le choix des outils et des services de modernisation des applications implique généralement deux décisions parallèles : quels outils utiliser et quels services activer.
Les outils qui comptent le plus dans la modernisation
Observabilité et surveillance : suivez les performances des applications afin de détecter les problèmes rapidement et de vérifier que les versions modernisées fonctionnent mieux que celles qu’elles ont remplacées.
Pipelines CI/CD (intégration et déploiement continus) : automatisez le test et le déploiement des modifications de code afin que les équipes puissent livrer les mises à jour quotidiennement ou chaque semaine au lieu de trimestriellement.
Automatisation des tests : exécutez les tests automatiquement lors de la modification du code, avec des options basées sur l’IA qui peuvent générer des tests en étudiant le comportement actuel de l’application existante.
Accélérateurs de migration : analysez le code existant, cartographiez les dépendances et convertissez l’ancien code en équivalents modernes, en compressant parfois des mois de travail manuel en quelques jours.
Les services qui comptent le plus dans la modernisation
Partenaires de conseil : faites appel à une expertise externe en modernisation, commençant généralement par une évaluation et se poursuivant jusqu’à la mise en œuvre.
Fournisseurs de plate-formes avec services intégrés : proposent la plate-forme de modernisation accompagnée d’ingénieurs pour vous aider à l’utiliser (MongoDB AMP).
Approches hybrides : combinez des plate-formes et des consultants externes avec l’ingénierie interne, ce qui vous permet de contrôler les parties du travail gérées en interne et celles qui sont externalisées.
Gestion du changement et formation : préparez les ingénieurs, les responsables et les utilisateurs finaux aux nouveaux outils et flux de travail, car la modernisation peut échouer si les personnes ne savent pas utiliser ce qui a été créé.
Services gérés ou autogérés ?
En plus de choisir des outils et des services, la plupart des entreprises doivent également choisir entre des services gérés ou des services autogérés. Les services gérés sont plus rapides à configurer et plus faciles à maintenir, mais vous avez moins de contrôle et risquez de devenir trop dépendant du fournisseur. Les options autogérées vous offrent plus de contrôle, mais vous devez ensuite tout gérer : correctifs, mise à l’échelle, sécurité et reprise d’activité.
Les grandes entreprises avec plusieurs unités commerciales définissent souvent un Centre d’Excellence(une petite équipe transverse) pour définir des normes et gérer leur approche.
Comment établir une feuille de route de modernisation des applications ?
Une feuille de route de modernisation est une stratégie séquencée qui définit ce qui est modernisé, dans quel ordre et comment vous en mesurerez la réussite.
La plupart des feuilles de route réussies partagent quatre actions clés :
Jalons par étapes : planifiez un déploiement de 12 à 36 mois, décomposé en livrables trimestriels.
KPI et indicateurs de succès: Suivez la vitesse de livraison, le coût, les performances et la satisfaction des développeurs.
Un projet pilote : commencez par un petit projet capable de générer des gains rapides.
Un rythme de version itératif : Livrez chaque trimestre plutôt que de promettre un résultat parfait dans trois ans.
Votre liste de contrôle du retour sur investissement de la modernisation
Cas pratique : où en est le plan de Kai ?
Six mois après le début de sa feuille de route de 18 mois, le système de notification de Kai a été déployé, le modèle « strangler » sur les services bancaires de base est en cours, et la reconstruction du système de détection des fraudes est active. Tout comme Lombard Odier, qui a réduit les tests de régression de trois jours à trois heures grâce à MongoDB, Kai commence à constater les rendements composés de la modernisation.
Quelles sont vos prochaines étapes pour la modernisation des applications ?
Que vous soyez au début de votre parcours de modernisation des applications ou déjà en train de le parcourir, la voie à suivre est plus simple qu’il n’y paraît.
Faites le point sur ce que vous avez : même une présentation informelle de vos applications, de vos dépendances et des ingénieurs qui les maintiennent suffit pour commencer.
Choisissez un projet pilote : sélectionnez une application suffisamment importante pour être pertinente, mais assez petite pour être terminée rapidement, afin de prouver que votre approche fonctionne avant de passer à la mise à l’échelle.
Ne négligez pas votre couche de données : les efforts de modernisation peuvent piétiner lorsque la base de données est traitée comme une réflexion après coup plutôt que comme une partie intégrante du projet.
Créez une liste de contrôle d’évaluation avant de parler aux fournisseurs : dressez d’abord une liste des éléments indispensables, afin que les présentations des fournisseurs ne finissent pas par façonner vos exigences.
Une stratégie de modernisation des applications réussie demande du temps, une harmonisation entre les équipes et une réévaluation constante. Cependant les principes en sont simples : faites le point sur ce que vous possédez, donnez la priorité à ce qui compte, modernisez par étapes et veillez à ce que chaque décision soit liée à la valeur métier. La plupart des entreprises trouvent qu’il est plus facile de commencer une fois qu’elles ont compris que le chemin se construit une décision à la fois.
Découvrez les solutions de modernisation des applications MongoDB →
Ressources connexes
Modernisez vos applications existantes grâce à AMP : découvrez comment la plate-forme de modernisation des applications de MongoDB transforme les applications obsolètes en systèmes souples et prêts pour l’IA.
MongoDB Relational Migrator : découvrez comment passer de schémas relationnels rigides à des modèles souples basés sur des documents sans perturber votre activité.
Qu’est-ce qu’une base de données documentaire ? — Découvrez comment fonctionnent les bases de données documentaires et pourquoi elles sont mieux adaptées au fonctionnement des entreprises modernes.
MongoDB Atlas— Découvrez la plateforme de base de données cloud qui alimente les applications modernes prêtes pour l’IA.
Comment Intellect Design a accéléré la modernisation de ses systèmes existants de 200 % : découvrez comment une entreprise internationale de technologie financière a modernisé sa plate-forme de gestion de patrimoine grâce à MongoDB et à l’IA générative.