Quelles applications faut-il moderniser en priorité

La rationalisation des applications échoue lorsqu’un classement devient un plan d’arrêt. Les architectes d’entreprise et les CTO peuvent inventorier les applications, les évaluer, les placer sur une matrice et cibler le quartile inférieur pour le retrait ; c’est le « 20 % facile ». Le problème plus difficile commence lorsque des incitations organisationnelles ou une dépendance non documentée rendent dangereux, dans l’exécution, un classement pourtant défendable.

La rationalisation est le processus récurrent qui consiste à inventorier le parc applicatif, à évaluer la criticité métier, le coût et le risque technique, puis à décider quoi conserver, dans quoi investir, quoi migrer ou retirer. Son résultat est une décision de portefeuille sur les applications à conserver, supprimer ou consolider, et sur les domaines où l’investissement de modernisation doit porter. La planification de mise en œuvre commence une fois ces choix de portefeuille arrêtés.

Cette séquence distingue la rationalisation de la modernisation. La rationalisation demande si un système doit exister et s’il mérite un investissement supplémentaire ; la modernisation détermine comment faire évoluer les systèmes qui restent. La rationalisation agit donc comme un filtre à l’échelle du portefeuille, la modernisation intervenant ensuite pour l’ensemble conservé.

Rendre ce filtre fiable exige trois décisions distinctes. Le scoring établit ce qui mérite d’être conservé, modifié ou supprimé ; des preuves opérationnelles indépendantes établissent si ces scores sont dignes de confiance ; la structure des dépendances établit à quel moment une migration ou un retrait est sûr. Lorsque ces questions sont fondues dans un seul classement, une recommandation de portefeuille sensée peut se transformer en mauvaise décision de production.

Cinq facteurs établissent ce qui mérite d’être conservé, modifié ou supprimé

Le scoring vient d’abord comme jugement de portefeuille, car la télémétrie opérationnelle et les cartes de dépendances ne peuvent pas, à elles seules, décider si une application mérite un investissement. Un modèle utile sépare cinq dimensions : la criticité métier, le coût d’exploitation, le coût du changement, le risque technique et le rayon d’impact. Chacune répond à une question différente, de sorte que les désaccords peuvent être rattachés à des preuves précises au lieu d’être compressés dans un seul jugement composite.

Les deux dimensions de coût conduisent à des décisions d’investissement différentes, car elles proviennent de travaux différents. Le coût d’exploitation apparaît dans les dépenses d’infrastructure, les licences et le support, tandis que le coût du changement apparaît en heures d’ingénierie dès qu’une modification, même mineure, est nécessaire. Une application peut être « coûteuse » à maintenir en fonctionnement, tandis qu’une autre peut être « coûteuse à modifier » parce que chaque changement consomme de l’effort d’ingénierie.

La même séparation compte entre criticité métier, risque technique et rayon d’impact. La dépendance au chiffre d’affaires ou à la conformité établit à quel point un système est « important », tandis que l’ancienneté, la concentration des connaissances, la dette de correctifs et le comportement de livraison peuvent le rendre « important et fragile ». Le rayon d’impact mesure l’effet sur les autres systèmes ; ainsi, une application qui paraît mineure prise isolément peut avoir une importance majeure dans le portefeuille lorsque de nombreux systèmes en dépendent.

La matrice familière coût contre « valeur » métier compresse ces distinctions en deux axes. Le risque technique et le rayon d’impact n’y ont pas de place naturelle ; ils ont donc tendance à disparaître ou à être absorbés dans la valeur, tandis qu’un seul axe de coût masque la différence entre dépense d’exploitation et effort d’ingénierie. Une évaluation à cinq facteurs préserve la base de chaque jugement contesté et peut modifier la décision d’investissement avant même que le séquencement ne commence.

Cette résolution supplémentaire compte dans les deux sens. Une application peu coûteuse peut malgré tout être un mauvais investissement si elle duplique un autre système dont le rayon d’impact est plus faible. À l’inverse, une application à faible valeur autonome peut prendre une importance de portefeuille très différente une fois son risque technique et ses dépendances aval rendus visibles.

Gartner a fourni en 2015 un vocabulaire de résultat largement utilisé avec le modèle TIME : « Tolerate, Invest, Migrate, or Eliminate ». TIME désigne la classification atteinte par un exercice de rationalisation, tandis que les cinq facteurs fournissent les preuves permettant d’y parvenir. Une fois l’analyse terminée, l’attribution de la classification TIME peut être traitée comme une étape d’environ cinq minutes plutôt que comme le travail analytique principal.

Le modèle de scoring établit le jugement de portefeuille, mais sa qualité dépend des preuves qui le sous-tendent. Un scoring à cinq facteurs exige une triangulation des données tenant compte des incitations, un séquencement fondé sur les dépendances et une gouvernance récurrente autour de celui-ci. Le premier problème, après avoir défini les facteurs, est de savoir si l’on peut croire les informations qui les alimentent.

Les personnes qui connaissent le mieux une application peuvent aussi avoir intérêt à la préserver

Il devient difficile de faire confiance à ces preuves lorsque leur source d’information la plus forte a un intérêt dans le résultat. Les responsables d’application connaissent en détail l’historique des incidents et des escalades, mais ils savent aussi qu’une évaluation faible peut conduire au retrait. Le budget, les effectifs, la continuité de l’équipe et les incitations de carrière peuvent donc influencer les autoévaluations de criticité, de coût du changement et de rayon d’impact, sans qu’il soit nécessaire de supposer une malhonnêteté délibérée.

La criticité rend cette incitation concrète, car un score élevé renforce l’argument en faveur du maintien du budget et des effectifs, ainsi que de la cohésion de l’équipe. Les enquêtes et les enregistrements de propriété dans la CMDB peuvent alors encoder ce jugement comme donnée de portefeuille. Le score obtenu paraît précis, même lorsque le comportement en production raconte une autre histoire.

Comme une plateforme de portefeuille ne peut pas supprimer ces incitations, un scoring crédible a besoin de preuves que le responsable ne peut pas contrôler unilatéralement. La criticité métier doit être vérifiée par rapport à l’historique des incidents ; le coût d’exploitation par rapport aux données financières, aux enregistrements CMDB et à l’usage réel ; le coût du changement par rapport au temps de cycle des tickets ; le risque technique par rapport à l’analyse statique et aux connaissances actuelles de l’équipe ; et le rayon d’impact par rapport aux dépendances cartographiées. La connaissance du responsable reste un apport important, tandis que ces enregistrements indépendants rendent le jugement vérifiable.

Le comportement opérationnel ajoute un autre contrôle croisé lorsque les affirmations du responsable portent sur l’activité de production. Le taux d’échec des changements, le volume de tickets et la responsabilité réelle d’astreinte révèlent différentes parties de l’empreinte d’un système ; les déclarations pertinentes auto-rapportées doivent donc être triangulées avec l’activité d’astreinte et de tickets avant d’être acceptées. Le volume de tickets indique l’usage réel et les points de douleur, tandis que les données d’astreinte identifient qui porte la responsabilité opérationnelle lorsqu’une panne de production survient.

Les enregistrements d’astreinte peuvent révéler un problème de propriété qu’une CMDB ne voit pas. La personne ou l’équipe qui reçoit les incidents peut différer du propriétaire nominal, révélant de la shadow AI : des systèmes de production dont personne n’accepte formellement la responsabilité parce que le système n’a jamais été autorisé à exister. Réconcilier la propriété nominale avec la responsabilité réelle d’astreinte change la personne dont les preuves doivent entrer dans la décision de portefeuille et corrige l’enregistrement de propriété.

Une fois la propriété établie, le comportement de livraison peut tester les affirmations sur la criticité ou la stabilité. Une rotation d’astreinte calme combinée à un taux d’échec des changements stable sur plusieurs trimestres peut contredire l’évaluation de forte criticité d’un responsable. Une hausse du taux d’échec des changements et une rotation d’astreinte qui s’alourdit pointent dans l’autre direction, signalant un risque technique croissant, quelle que soit la stabilité déclarée de l’application par son responsable.

Le taux d’échec des changements dispose aussi d’une base de recherche plus large comme signal opérationnel. Le programme de recherche DevOps Research and Assessment (DORA), à travers ses recherches Accelerate, l’identifie comme l’une des quatre métriques clés qui distinguent une performance d’élite en livraison logicielle d’une faible performance. IBM, citant le framework DORA en 2024, donne le benchmark suivant :

Ces fourchettes laissent encore de la place au jugement spécifique à l’application, mais elles donnent aux équipes une mesure observable indépendamment pour contester une évaluation de faible risque lorsque les échecs de livraison continuent d’augmenter. L’activité de tickets et d’astreinte fournit le même contrôle lorsqu’elle diverge de l’importance revendiquée. Chaque écart donne à l’équipe portefeuille une question concrète à examiner, au lieu de l’obliger à accepter une autoévaluation telle quelle.

Cette triangulation peut commencer avec les outils existants plutôt qu’avec une nouvelle plateforme de portefeuille. Même un tableur peut croiser les scores auto-déclarés, les rotations d’astreinte, le volume de tickets et les informations CMDB existantes, et mettre en évidence l’écart « en un après-midi ». Le changement de procédure est ce qui compte : la connaissance du responsable reste nécessaire, tandis que des preuves hors de son contrôle contribuent aussi à l’évaluation de l’application.

Des preuves plus crédibles améliorent le score, mais elles ne peuvent toujours pas déterminer l’ordre dans lequel une organisation doit agir. Un candidat au retrait correctement identifié peut rester dangereux à retirer parce que d’autres systèmes de production en dépendent. Le rayon d’impact change alors de rôle : il contribue au jugement de portefeuille pendant le scoring et devient une contrainte forte de séquencement pendant l’exécution.

Les dépendances peuvent renverser le bon score et déterminer l’ordre de retrait

Ce problème de séquencement apparaît de manière répétée dans les missions de replatforming en entreprise. Prenons un système à faible criticité métier et à coût du changement élevé : son score pointe vers un retrait, mais la cartographie révèle que six services aval l’appellent chaque jour. Le jugement sur le système pris isolément peut rester valide, tandis que le calendrier proposé devient dangereux.

Une application d’apparence plus modeste peut créer la même contrainte par un mécanisme différent. Un système à faible criticité et faible coût peut se trouver en amont de six autres via une authentification partagée ou un traitement batch non documenté ; ses consommateurs portent donc des conséquences que son rôle métier direct ne révèle pas. La relation de dépendance modifie l’ordre sûr des travaux, même lorsque le score propre de l’application est exact.

Un service d’identité en amont renforce encore la contrainte. Une application à faible valeur et à coût élevé semble être un candidat évident au retrait jusqu’à ce que le graphe de dépendances montre qu’elle fournit des services d’identité à une douzaine d’applications à chaque requête. Son score peut toujours plaider pour une élimination à terme, tandis que sa position en production signifie qu’elle sera déplacée en dernier, ou restera peut-être en place.

Le traitement batch peut masquer le même type de couplage, car la relation peut n’apparaître qu’à intervalles planifiés. L’application au profil apparemment le plus mauvais en criticité métier et en coût du changement peut malgré tout être invoquée chaque nuit par trois autres systèmes. Un classement ordonné de la « pire » application à la « meilleure » ne peut pas montrer si ces trois appelants ont déjà migré.

Le middleware legacy ajoute un autre risque : des données d’inventaire manquantes. Un service peut obtenir un score fort en faveur de l’élimination sur les autres dimensions, tandis que la cartographie des dépendances révèle des appelants aval jamais documentés dans la CMDB. Couper ce middleware avant que des remplacements n’existent pour ces consommateurs les casserait, même si le jugement d’élimination lui-même était juste.

Ensemble, ces cas montrent les deux fonctions remplies par le rayon d’impact. Pendant le scoring, il influence la décision de conserver, d’investir, de migrer ou d’éliminer un système en révélant l’effet de sa disparition. Pendant l’exécution, la même information de dépendance contraint le calendrier, car les consommateurs doivent migrer avant qu’un fournisseur fortement sollicité puisse disparaître en toute sécurité.

La règle opérationnelle qui en résulte est simple : le scoring détermine ce qui doit être retiré ; la structure des dépendances détermine quand cela peut être retiré. Un classement de retrait s’efface devant le graphe pendant l’exécution, car le classement exprime une préférence de portefeuille tandis que le graphe exprime des contraintes de production. Les dépendances peuvent rendre prématurée une action de retrait par ailleurs correcte, même si elles ne peuvent pas, à elles seules, établir qu’un système mérite un investissement.

Parce que les dépendances peuvent invalider une séquence d’exécution, les équipes doivent faire remonter tôt les couplages évidents plutôt que d’attendre que chaque score soit perfectionné. Tirez un graphe de dépendances pour les vingt principales applications par volume de tickets et utilisez-le pour identifier quelles discussions de portefeuille exigent une attention prioritaire. Le volume élevé de tickets donne à cette analyse précoce un ensemble de départ fondé sur la production ; le scoring complet détermine toujours le résultat de portefeuille.

Cette analyse précoce dépend aussi d’un inventaire crédible. Extrayez le parc depuis la CMDB, puis réconciliez ces enregistrements avec ce qui tourne réellement en production avant de rationaliser l’ensemble visible. Les entrées CMDB et la réalité de production peuvent diverger, et les appelants non documentés sont précisément les dépendances les plus susceptibles de faire échouer un plan d’arrêt.

Une fois le parc visible évalué et cartographié, le graphe complet peut fournir l’ordre de retrait. Retirez d’abord les nœuds feuilles, c’est-à-dire les applications dont rien d’autre ne dépend, puis progressez vers l’intérieur du graphe. Les applications au rayon d’impact large restent jusqu’à ce que leurs consommateurs aient migré ailleurs, quelle que soit la place de ces applications dans le classement des scores.

Cet ordonnancement explique pourquoi le score ne peut pas servir de plan de projet. Un modèle à cinq facteurs peut établir que le service d’identité en amont ou le middleware legacy doit, à terme, disparaître, tandis que le graphe de dépendances planifie les migrations des consommateurs nécessaires pour rendre ce résultat sûr. Les deux artefacts répondent à des questions différentes, en préservant à la fois la justification de portefeuille et la contrainte de production.

La rationalisation doit rester active après la première décision de retrait

Même une séquence initiale sûre se dégrade à mesure que le parc évolue. La propriété passe d’une équipe à l’autre, les dépendances changent, le comportement de livraison évolue et les applications gagnent ou perdent en importance opérationnelle ; ainsi, une matrice de scoring du T1 peut devenir une « fiction au T3 ». La rationalisation fonctionne mieux comme cycle de gouvernance trimestriel que comme audit ponctuel.

Chaque actualisation trimestrielle doit revisiter le taux d’échec des changements, le volume de tickets et la charge d’astreinte à l’aide des signaux d’ingénierie déjà utilisés pour tester l’évaluation initiale. Ces mesures montrent si la production continue d’étayer le jugement antérieur. Lorsqu’un signal change de manière significative, l’équipe doit rouvrir le facteur qui en dépendait au lieu de reconduire automatiquement la classification précédente.

L’astreinte est particulièrement utile comme signal d’alerte précoce peu coûteux, car sa signification a déjà été liée à la responsabilité opérationnelle. Si une application évaluée comme critique pour le métier se retrouve avec une rotation d’astreinte calme, sa criticité mérite une réévaluation ; si l’astreinte augmente pour un système classé Tolerate ou Eliminate, les hypothèses sous-jacentes sur le risque technique ou le rayon d’impact peuvent être erronées. Cette revue peut détecter la dérive avant qu’un retrait planifié ne transforme un jugement obsolète en incident.

Le même cycle de preuves se poursuit après le déclassement. Une hausse du taux d’échec des changements après un retrait peut indiquer que le graphe de dépendances a manqué un appelant ou une autre relation aval. Une assurance qualité rigoureuse après déclassement peut détecter cette casse, et le résultat en production devient alors une preuve pour la revue trimestrielle suivante.

Arrêtez la rationalisation là où le problème de décision s’arrête

La gouvernance récurrente a une limite basse pratique, car les petits parcs lisibles peuvent souvent être inspectés directement. En dessous d’environ 20 applications, un parc peut être suffisamment clair pour ne pas nécessiter un scoring de portefeuille à cinq facteurs, une cadence trimestrielle de rationalisation et un graphe de dépendances formellement construit. Un CTO responsable de 15 applications sait peut-être déjà lesquelles posent problème, laquelle personne ne sait expliquer et laquelle la finance utilise fortement.

Pour un tel parc, une session de cadrage ciblée peut correspondre à l’échelle de la décision. Réunissez les responsables, identifiez les trois ou quatre systèmes contestés et décidez si chacun doit être conservé, retiré ou replatformé. Une mécanique de gouvernance ajoutée par simple formalisme apporte peu lorsque les personnes concernées peuvent déjà porter et examiner directement l’ensemble de la décision.

Le chiffre d’environ 20 reste une heuristique, car le couplage et l’ambiguïté de propriété comptent davantage que la taille brute du portefeuille. Un parc de 25 applications fortement couplées partageant une base de données peut nécessiter une rationalisation formelle davantage que 60 applications faiblement connectées avec une propriété claire et une valeur métier évidente. La lisibilité est le meilleur test : lorsque les décideurs voient déjà qui possède quoi et pourquoi cela compte, utilisez la session de cadrage.

Lorsque la rationalisation est justifiée, son point d’arrivée définit aussi l’endroit où la modernisation commence. Le processus sélectionne ce qui mérite un investissement et produit des décisions telles que conservé, supprimé ou consolidé ; la modernisation applique ensuite l’approche d’ingénierie appropriée aux systèmes sélectionnés pour le changement. Maintenir ces étapes séparées évite que l’effort d’ingénierie ne commence avant que le portefeuille n’ait établi si une application mérite cet effort.

Le vocabulaire des 6R appartient à ce versant de modernisation de la frontière. Des options comme rehost, refactor, rebuild et « le reste » répondent à la question de savoir comment une application doit évoluer une fois que Migrate ou Invest a été choisi. Un guide de modernisation des systèmes legacy peut prolonger la décision jusqu’à ces choix de mise en œuvre, tandis qu’un framework de CTO sur la manière de reconstruire des applications web legacy peut traiter la question plus étroite de savoir quand une reconstruction est préférable à un refactoring.

Cet ordre a une conséquence directe pour l’ingénierie. Une équipe qui commence d’abord par la mise en œuvre peut passer un trimestre à replatformer une application que la rationalisation aurait retirée, ou à simplifier une application dont l’issue de portefeuille est déjà la consolidation. « What Is Application Modernization? » couvre les choix ultérieurs de rehost, refactor et rebuild, qui deviennent pertinents une fois le parc conservé décidé.

Une évaluation retrait-ou-replatforming peut aussi révéler que la reconstruction est la bonne voie de modernisation. À ce stade, faire appel à un partenaire de développement expérimenté avant de cadrer la reconstruction est une manière de faire passer le travail sélectionné en mise en œuvre avec une justification de portefeuille déjà tranchée. La rationalisation atteint son point d’arrivée lorsque l’organisation sait quels systèmes méritent cet investissement et peut transmettre ces systèmes à la modernisation sans rouvrir la question de leur raison d’être.

Points clés à retenir pour les décideurs

• Séparer le scoring du séquencement : Évaluez les applications selon la criticité métier, le coût d’exploitation, le coût du changement, le risque technique et le rayon d’impact afin de décider ce qui mérite un investissement ou un retrait. Utilisez ces facteurs pour établir les priorités du portefeuille avant que la modernisation ne commence.
• Valider les évaluations des responsables avec des preuves de production : Les responsables d’application ont une connaissance précieuse et des incitations qui peuvent influencer leurs autoévaluations. Les équipes portefeuille peuvent tester ces évaluations par rapport à l’historique des incidents, aux données financières, au temps de cycle des tickets, aux taux d’échec des changements, à l’activité d’astreinte et à l’usage réel.
• Laisser les dépendances déterminer l’ordre de retrait : Un solide candidat au retrait peut encore soutenir des systèmes aval critiques. Les cartes de dépendances doivent gouverner l’exécution en déplaçant d’abord les consommateurs et en retirant les nœuds feuilles avant les fournisseurs fortement sollicités.
• Réévaluer le portefeuille à mesure que les conditions changent : Les revues trimestrielles peuvent revisiter les taux d’échec des changements, le volume de tickets, la charge d’astreinte, la propriété et les dépendances. Des changements significatifs doivent déclencher une réévaluation avant qu’une classification obsolète ne devienne un risque de production.
• Adapter la gouvernance à la complexité du portefeuille : Les petits parcs lisibles peuvent n’avoir besoin que d’une session de cadrage ciblée, tandis que les portefeuilles fortement couplés ou mal compris justifient un scoring formel et une cartographie des dépendances. Une fois que la rationalisation établit ce qui mérite un investissement, les équipes de modernisation peuvent décider comment le rehost, le refactor ou le rebuild.