L'indice de maintenabilité (IM) est l'une des métriques composites les plus utilisées pour mesurer la qualité logicielle. Il synthétise trois propriétés structurelles du code (taille, complexité et volume) en un score numérique unique qui prédit la difficulté de modification du code. Pour les langages modernes, la formule, les seuils et les outils sont bien établis. En COBOL, la situation est plus complexe : la plupart des équipes appliquent la formule générique sans adaptation ou abandonnent toute mesure quantitative, car les scores ne reflètent pas l'expérience réelle des développeurs.
Les deux approches produisent des résultats trompeurs. Appliquer la formule standard de l'indice de performance (MI) au COBOL sans comprendre le comportement de ses composants dans son contexte syntaxique génère des scores systématiquement biaisés, donnant l'impression que des programmes de haute qualité sont marginaux et que des programmes de faible qualité sont acceptables. L'abandon total de la mesure prive les décisions de modernisation des fondements quantitatifs nécessaires pour les justifier auprès des parties prenantes et pour prioriser les actions correctives au sein d'un portefeuille de milliers de programmes.
Obtenez une vue d'ensemble complète des indicateurs COBOL
SMART TS XL classe simultanément tous les programmes COBOL selon leur complexité, leur nombre d'entrées et la profondeur de leurs dépendances JCL.
En savoir plusLa bonne approche consiste à comprendre ce que mesure spécifiquement la formule MI en COBOL, ses biais de surestimation et de sous-estimation de la qualité, les indicateurs complémentaires qui corrigent ses lacunes propres au COBOL, et comment calibrer les seuils en fonction de votre portefeuille réel plutôt que par rapport à des benchmarks génériques issus de bases de code de langages modernes. Ce guide aborde ces quatre points, offrant le niveau de détail technique nécessaire à la mise en œuvre d'un programme MI pour COBOL et les conseils pratiques indispensables à son utilisation pour les décisions de modernisation.
Un dernier point avant d'aborder les aspects techniques : l'indice de maintenabilité (IM) vise à offrir une vision globale de la charge de maintenance relative des différentes sections d'un projet en combinant plusieurs indicateurs. Cette vision globale est précieuse pour les portefeuilles COBOL précisément parce qu'aucun indicateur ne peut, à lui seul, en donner une image complète. L'IM est un point de départ, certes, mais pas une solution définitive. C'est néanmoins un excellent point de départ.
Pourquoi la mesure de la maintenabilité est plus importante pour COBOL que pour les langages modernes
Mesurer la maintenabilité d'un code Java ou Python vieux de deux ans, bien testé et maintenu par l'équipe qui l'a développé, fournit des informations utiles mais est rarement urgent. Le code est lisible par ses auteurs. La logique est documentée ou déductible des tests. Le coût des modifications est limité par le niveau de familiarité de l'équipe avec le code.
Les portefeuilles COBOL dans les industries réglementées diffèrent de trois manières qui font de la mesure quantitative de la maintenabilité non pas une pratique de qualité, mais une nécessité opérationnelle.
Le déficit de connaissances. La plupart des applications COBOL contiennent une logique métier jamais documentée formellement. Les traitements par lots écrits il y a des décennies encodent des règles oubliées. Les développeurs capables de lire le code couramment et d'estimer précisément le coût des modifications partent à la retraite. Ceux qui restent n'ont qu'une connaissance partielle du portefeuille de projets. Sans indicateurs quantitatifs, l'estimation du coût des modifications dépend entièrement du développeur interrogé, et la variabilité de ces estimations est telle que la planification des projets devient aléatoire.
Le problème de l'échelle. Un portefeuille COBOL typique contient des milliers de programmes, dont beaucoup n'ont pas été modifiés depuis des années. Aucune équipe ne peut évaluer manuellement des milliers de programmes avant le lancement d'un programme de modernisation. Des indicateurs calculables automatiquement sur l'ensemble du portefeuille en quelques heures permettent de remplacer des semaines d'analyse manuelle.
L'exigence d'une analyse de rentabilité. Les programmes de modernisation nécessitent une justification des investissements. Les dirigeants qui approuvent des budgets de modernisation de plusieurs millions de dollars souhaitent des preuves quantitatives que l'investissement est justifié. Les scores d'indicateurs de modernisation, les ratios de dette technique dérivés de ces indicateurs et les estimations des coûts de changement qui font référence aux seuils d'indicateurs de modernisation fournissent ces preuves sous une forme pouvant être présentée aux parties prenantes non techniques.
La formule MI et ses composants spécifiques à COBOL
La formule la plus couramment utilisée pour calculer l'indice de maintenabilité est :
MI = 171 - 5.2 × ln(Halstead Volume) - 0.23 × (Cyclomatic Complexity) - 16.2 × ln(Lines of Code)La variante bornée de Microsoft, utilisée par la plupart des outils commerciaux, associe cela à une échelle de 0 à 100 :
MI (bounded) = max(0, (171 - 5.2 × ln(HV) - 0.23 × CC - 16.2 × ln(LOC)) × 100 / 171)Chaque composant présente des considérations spécifiques liées à COBOL.
Lignes de code en COBOL
Les fichiers source COBOL comportent quatre divisions : IDENTIFICATION, ENVIRONMENT, DATA et PROCEDURE. La division IDENTIFICATION identifie le programme. La division ENVIRONMENT décrit son environnement d'exécution. La division DATA définit ses structures de données. Seule la division PROCEDURE contient les instructions exécutables.
La question de la mesure : LOC doit-il compter toutes les lignes dans les quatre divisions, ou seulement les instructions de la division PROCEDURE ?
Pour les besoins de l'analyse de la maintenance (MI), le comptage de toutes les lignes (y compris les déclarations de données) augmente considérablement le nombre de lignes de code (LOC) sans pour autant accroître la complexité d'exécution. Un programme COBOL comportant 400 lignes de division de données (DATA DIVISION) définissant la structure des enregistrements et 100 lignes de division de procédures (PROCEDURE DIVISION) présente des caractéristiques de maintenabilité différentes de celles d'un programme comportant 100 lignes de division de données (DATA DIVISION) et 400 lignes de division de procédures (PROCEDURE DIVISION), mais le calcul brut du nombre de lignes de code (LOC) les traite de la même manière.
Bonne pratique : pour le calcul de l’indice de complexité (MI) en COBOL, utilisez le nombre d’instructions de la division PROCEDURE (en excluant les lignes vides, les lignes de commentaires et les en-têtes de division/section/paragraphe) plutôt que le nombre total de lignes du code source. Vous obtiendrez ainsi des valeurs de LOC plus représentatives de la complexité de l’exécutable.
Le problème des membres COPY : les instructions COPY incluent les membres externes du code source lors de la compilation. Une instruction COPY qui se développe en 200 lignes de définitions de données ajoute une ligne au fichier source, mais 200 lignes au programme compilé. Certains outils comptent les lignes de code logiques (après expansion de la copie) ; d’autres comptent les lignes de code source physiques. La différence peut être considérable pour les programmes utilisant intensivement COPY.
Attention : si votre outil MI compte les lignes de code source physiques, les programmes utilisant beaucoup la fonction COPY apparaîtront plus petits et plus faciles à maintenir qu’ils ne le sont réellement. Vérifiez toujours si le nombre de lignes de code (LOC) dans votre outil correspond à l’expansion avant ou après copie.
Complexité cyclomatique en COBOL
La complexité cyclomatique est une mesure de la qualité du code qui évalue sa compréhensibilité et sa maintenabilité en quantifiant le nombre de chemins d'exécution indépendants. En COBOL, les structures de décision qui créent ces chemins indépendants incluent :
| Construction COBOL | Impact de la complexité cyclomatique |
|---|---|
IF ... END-IF | +1 par IF |
IF ... ELSE ... END-IF | +1 par condition SI (sinon n'ajoute pas de chemin supplémentaire) |
EVALUATE ... WHEN | +1 par clause WHEN |
PERFORM UNTIL condition | +1 par condition JUSQU'À |
PERFORM VARYING ... WITH TEST BEFORE/AFTER | +1 par VARIABLE |
AT END clause sur LIRE | +1 |
ON EXCEPTION / NOT ON EXCEPTION | +1 par gestionnaire d'exceptions |
ON OVERFLOW / NOT ON OVERFLOW | +1 par gestionnaire de débordement |
ON SIZE ERROR | +1 par gestionnaire d'erreurs de taille |
Le point aveugle des niveaux 88 : les noms de conditions de niveau 88 en COBOL créent des conditions logiques qui apparaissent dans les instructions IF et EVALUATE, mais sont définies dans la DATA DIVISION. Un programme comportant vingt conditions de niveau 88, chacune référencée dans plusieurs structures de décision, présente une complexité comportementale bien supérieure à ce que suggère le nombre d'instructions de la PROCEDURE DIVISION. La complexité cyclomatique comptabilise les points de décision, mais ne peut pas saisir les relations sémantiques entre les noms de niveaux 88 et la logique qui les teste.
PERFORMER À TRAVERS LA COMPLEXE IMPLICITE : PERFORM SECTION-A THRU SECTION-Z exécute tous les paragraphes compris entre la SECTION A et la SECTION Z. Le nombre de paragraphes et les structures de décision qu'ils contiennent font partie intégrante de la complexité effective de l'instruction PERFORM, mais le CC calculé au niveau de l'instruction traite PERFORM THRU comme un chemin unique, peu importe ce qui se trouve entre les deux.
Volume Halstead en COBOL
Le volume de Halstead est une mesure de la taille et de la complexité d'un programme, basée sur le nombre d'opérateurs et d'opérandes. En COBOL :
Les opérateurs sont des verbes et des mots clés COBOL : MOVE, ADD, SUBTRACT, MULTIPLY, DIVIDE, COMPUTE, IF, PERFORM, READ, WRITE, OPEN, CLOSE, CALL, GO TO, EVALUATE, WHEN, etc.
Les opérandes sont des noms de données, des littéraux et des constantes figuratives : éléments de données définis dans la DATA DIVISION, littéraux numériques et de chaîne, et constantes figuratives COBOL (SPACES, ZEROS, HIGH-VALUES, LOW-VALUES).
Le facteur verbosité : Le COBOL est nettement plus verbeux que les langages modernes pour une logique équivalente. Une expression Java. total = quantity * unitPrice * (1 - discount) Il s'agit d'une ligne comportant quatre opérateurs et quatre opérandes. L'équivalent en COBOL :
Cobol
COMPUTE WS-TOTAL = WS-QUANTITY * WS-UNIT-PRICE
* (1 - WS-DISCOUNT)En termes d'opérateurs et d'opérandes, cela reste globalement équivalent. Cependant, prenons l'exemple d'un calcul plus complexe qui, en Java, pourrait tenir sur trois lignes. En COBOL, il pourrait en nécessiter cinq, voire plus, en raison de l'absence de chaînage d'expressions et de l'obligation d'utiliser des zones de stockage intermédiaires. Le volume de Halstead sera donc proportionnellement plus élevé pour COBOL que pour Java, car COBOL exprime le même calcul avec davantage de jetons de langage.
Conséquence pratique : les programmes COBOL auront un volume de Halstead supérieur à celui des programmes en langage moderne de logique équivalente. Un volume de Halstead plus élevé réduit l’indice de verbosité (MI). Par conséquent, les programmes COBOL obtiendront systématiquement un score MI inférieur à celui des programmes en langage moderne de complexité équivalente, non pas parce qu’ils sont plus difficiles à maintenir, mais parce que le COBOL est syntaxiquement plus verbeux.
Les limites de Standard MI pour COBOL : quatre angles morts
Même correctement calculée, la formule standard de l'indice de maintenance (MI) omet quatre dimensions de la maintenabilité du COBOL qui ont un impact significatif sur le coût réel des modifications.
1. COPIE Couplage des membres
Un copybook COBOL inclus par 300 programmes constitue une dépendance de maintenance qui affecte l'ensemble de ces 300 programmes dès qu'une modification y est apportée. Ce couplage n'apparaît dans aucun composant de la formule MI. Un programme incluant vingt copybooks présente 300 dépendances implicites que MI considère comme équivalentes à un programme sans copybook.
Métrique supplémentaire : Nombre de dépendances des membres de copie, soit le nombre d’instructions COPY uniques dans la DATA DIVISION d’un programme. Les programmes présentant un couplage COPY élevé nécessitent une analyse d’impact avant toute modification afin de déterminer quels autres programmes partagent les mêmes définitions de copybook.
2. Fan-In (Nombre d'appels)
Un sous-programme COBOL appelé par 150 autres programmes représente une cible de modification à haut risque, quel que soit son score MI. Un sous-programme facile à maintenir (MI = 85) appelé par 150 programmes est plus difficile à modifier en toute sécurité qu'un utilitaire difficile à maintenir (MI = 45) qui n'est appelé par aucun programme. La formule MI ne tient pas compte de la fréquence d'utilisation d'un programme.
Métrique supplémentaire : Fan-in, le nombre de programmes distincts qui appellent un programme donné via CALL ou dispatch dynamique. Le Fan-in est le principal facteur de risque lié aux modifications pour les sous-programmes, indépendamment de leur complexité interne.
3. Profondeur de dépendance JCL
Un programme COBOL appelé par un travail JCL ayant quinze dépendances en aval (travail s'exécutant après lui et dépendant de sa sortie) présente un risque opérationnel totalement extérieur au champ d'application de l'indice de gestion des messages (MI). Un programme avec un MI de 55 exécuté de manière autonome est moins risqué à modifier qu'un programme avec un MI de 80 situé au centre d'une chaîne de dépendances de traitement par lots complexe.
Métrique supplémentaire : profondeur des dépendances JCL, correspondant à la profondeur de la chaîne de dépendances en aval dans le réseau de tâches JCL. Les programmes présentant une profondeur de dépendances JCL élevée nécessitent un périmètre de test plus étendu pour toute modification, indépendamment de leur score MI interne.
4. Inflation du code mort
Les paragraphes et sections morts, c'est-à-dire le code COBOL défini mais jamais exécuté, augmentent le nombre de lignes de code et le volume Halstead sans pour autant alourdir la maintenance du code actif. Un programme contenant 600 lignes de code mort et 200 lignes de code actif se voit attribuer une métrique de maintenance qui le pénalise pour le code mort, alors même que ce dernier est sans incidence sur le coût de maintenance.
Métrique supplémentaire : Pourcentage de code mort, soit la proportion d’instructions PROCEDURE DIVISION inaccessibles depuis n’importe quel chemin d’exécution en production. Un pourcentage élevé de code mort indique une surestimation significative du nombre de lignes de code (LOC) et du volume de Halstead calculés par MI.
Suite complète de métriques COBOL
Aucun indicateur unique ne permet de mesurer la maintenabilité du COBOL. L'ensemble des indicateurs suivants, utilisés conjointement, offre une vision complète :
| Métrique | Ce qu'il mesure | Note spécifique à COBOL | Utilisation principale |
|---|---|---|---|
| Indice de maintenabilité | Facilité d'entretien globale (composite) | Appliquer aux déclarations de la DIVISION DES PROCÉDURES; vérifier le traitement des COPIES | Score de qualité de base ; classement du portefeuille |
| Complexité cyclomatique | Nombre de chemins d'exécution indépendants | Inclure ÉVALUER QUAND, EXÉCUTER JUSQU'À, À LA FIN, SUR EXCEPTION | Effort de modification par programme ; estimation du nombre de cas de test |
| Volume Halstead | Charge de calcul (opérateurs + opérandes) | Attendez-vous à des valeurs plus élevées que celles des programmes de langues modernes équivalents. | Partie de MI ; comparaison inter-programmes au sein du portefeuille COBOL |
| COPIE Nombre de membres | Couplage des dépendances par le biais de définitions partagées | Les programmes comptant plus de 15 membres COPY nécessitent une analyse d'impact avant toute modification. | Modification de la classification des risques |
| Fan-In (Appelé par) | Combien de programmes portent ce nom ? | Principal facteur de risque de changement pour les sous-programmes | Séquençage des migrations ; seuil d’autorisation de modification |
| Code mort % | Pourcentage de codes de procédure inaccessibles | Augmenter le LOC/HV s'il n'est pas exclu ; exclure du périmètre de conversion | Réduction du périmètre de modernisation |
| Profondeur de dépendance JCL | profondeur de la chaîne de traitement par lots en aval | Ne peut être calculé à partir du seul code source COBOL ; nécessite une analyse JCL | Risque lié aux changements opérationnels ; périmètre des tests |
| Profondeur d'exécution imbriquée | Niveau d'imbrication maximal des appels PERFORM | Un imbrication profonde indique une complexité structurelle non prise en compte par CC | Priorité de refactorisation |
Calibrage des seuils pour COBOL
Les seuils d'interruption standard sont dérivés des bases de code des langages modernes et ne s'appliquent pas directement à COBOL. Le tableau ci-dessous compare les seuils standard avec leurs équivalents adaptés à COBOL et explique la justification de ces ajustements.
| Plage de points | Interprétation standard | Interprétation COBOL | Raisonnement |
|---|---|---|---|
| 85-100 | Facile d'entretien | Hautement maintenable (cohérent) | Les meilleurs programmes COBOL obtiennent un score dans cette fourchette, une structure propre et une taille appropriée. |
| 65-84 | Modérément maintenable | Maintenance modérée, examiner le couplage COPY et l'entrée en éventail | Le seuil standard est respecté, mais les indicateurs complémentaires sont plus importants ici. |
| 50-64 | Mauvais, une refonte est nécessaire | Marginal, évaluer en contexte | De nombreux programmes COBOL bien structurés obtiennent de bons résultats ici uniquement grâce à leur verbosité ; utilisez CC et fan-in pour distinguer les véritables problèmes des artefacts syntaxiques. |
| 25-49 | Très mauvais | Mauvaise qualité, probablement élevée en CC et/ou en LOC. | Les programmes de cette taille indiquent de manière fiable des problèmes structurels, et pas seulement une verbosité excessive du COBOL. |
| 0-24 | Refonte majeure et critique | Critique, priorité absolue pour la remise en état ou la mise hors service | Conformément à l'interprétation standard |
Recommandations clés pour l'étalonnage : Exécutez l'analyse de la verbosité (MI) sur l'ensemble de votre portefeuille COBOL avant de définir des seuils spécifiques à chaque programme. Calculez la médiane et l'écart interquartile du portefeuille. Fixez votre seuil d'« attention requise » au 25e percentile de votre propre portefeuille, c'est-à-dire aux programmes du quartile inférieur de votre base de code spécifique, et non aux programmes dont le score est inférieur à un seuil dérivé des programmes Java. Cette approche s'auto-étalonne et tient compte de l'effet de verbosité systématique du COBOL.
Utiliser l'intelligence artificielle pour les décisions de modernisation
Les scores MI prennent toute leur valeur lorsqu'ils éclairent des décisions opérationnelles précises. Voici leurs principales applications.
Séquencement des vagues de migration. Les programmes présentant un score MI élevé (bien maintenus et peu complexes) sont les candidats idéaux pour les premières vagues de migration. Ils sont plus faciles à valider, moins susceptibles de contenir des cas limites non documentés et présentent un risque moindre de comportements inattendus dans l'environnement migré. Les programmes avec un score MI faible devraient être migrés ultérieurement, une fois que l'équipe aura acquis de l'expérience et de la confiance, et après une extraction approfondie de la logique métier.
Priorisation de la maintenance. Les programmes dont l'indice de maintenance (MI) est inférieur au 25e percentile et qui présentent également un fort degré d'interconnexion (appelés par de nombreux programmes) ou une forte dépendance au JCL constituent la combinaison la plus à risque : des programmes structurellement complexes dont dépendent de nombreux autres programmes. Ce sont les programmes les plus susceptibles de générer des défauts liés aux modifications et les plus coûteux à corriger. Ils devraient être les premières cibles d'un programme de réduction de la dette technique.
Décisions de développement ou d'achat. Pour évaluer l'opportunité de maintenir un programme COBOL à long terme ou de le remplacer par une solution SaaS ou une alternative moderne, le score MI et l'historique des coûts de modification fournissent la base quantitative du calcul. Un programme avec un score MI de 30, modifié quinze fois au cours des trois dernières années (chaque modification ayant pris beaucoup plus de temps que prévu), présente un coût de maintenance documenté, comparable au coût de remplacement.
Seuil d'autorisation des modifications. Certaines organisations utilisent les scores MI pour déterminer le niveau d'autorisation des modifications requis. Les programmes dont le score MI est inférieur à un certain seuil nécessitent un examen plus rigoureux, des tests indépendants et une validation supplémentaire avant leur mise en production. Ceci permet de mettre en place un processus de contrôle des modifications axé sur la qualité, sans exiger une évaluation manuelle de chaque modification.
Le principal inconvénient de l'information marketing (IM) est qu'elle ne permet pas de prédire l'impact d'un changement sur l'activité. Un programme dont l'IM est de 85 et qui effectue des calculs de fonds propres réglementaires requiert au moins autant de tests et de validation qu'un programme dont l'IM est de 40 et qui se contente d'une fonction de reporting à faible enjeu. L'IM mesure l'effort requis pour le changement, et non ses conséquences. Or, ces deux dimensions sont indispensables à une évaluation complète des risques.
Comment SMART TS XL Établit et suit les indicateurs de maintenabilité COBOL
Calculer l'indice de performance (MI) d'un programme COBOL unique est simple. En revanche, le calculer avec précision pour un portefeuille de milliers de programmes, en tenant compte de l'expansion des commandes COPY, en identifiant le code mort et en complétant le MI avec les métriques supplémentaires qu'il ne prend pas en compte, nécessite une analyse automatisée à grande échelle.
SMART TS XL's analyse de code statique Ce système calcule simultanément l'ensemble des métriques COBOL décrites dans ce guide pour l'ensemble du portefeuille. L'indice MI est calculé à partir du nombre d'instructions PROCEDURE DIVISION plutôt que du nombre total de lignes sources, l'expansion COPY étant effectuée avant l'analyse afin de garantir l'attribution correcte des définitions de données partagées. La complexité cyclomatique prend en compte les clauses EVALUATE WHEN, les conditions PERFORM UNTIL et les branches de gestion des exceptions, et non uniquement les instructions IF. Le volume de Halstead est calculé à partir des verbes COBOL et des opérandes de données de la PROCEDURE DIVISION.
Crucialement, SMART TS XL complète l'IM avec les indicateurs que la formule ne prend pas en compte. cartographie des dépendances des applications Il produit les valeurs de fan-in, c'est-à-dire le nombre d'appels, pour chaque programme du portefeuille, identifiant ainsi les programmes à haut risque indépendamment de leur score MI. Extension JCL Cette fonctionnalité fournit la profondeur de dépendance JCL pour chaque programme, reliant l'analyse MI au niveau COBOL au contexte de risque opérationnel que seule l'analyse JCL peut révéler.
L'identification du code mort à partir de la capacité d'analyse d'impact signale les paragraphes et les sections sans chemins d'exécution entrants, permettant l'exclusion du code mort du calcul MI et fournissant la mesure du pourcentage de code mort qui détermine si le faible score MI d'un programme reflète une complexité réelle ou un nombre de lignes de code gonflé.
La fonction de recherche d'entreprise permet d'interroger l'ensemble des données de métriques : trouvez, en une seule requête portant sur des millions de lignes de COBOL, tous les programmes dont l'indice de maintenance (MI) est inférieur à 40 et le fan-in supérieur à 20, triés par profondeur de dépendance JCL, ainsi que les cibles de correction prioritaires du portefeuille. Cet inventaire de métriques interrogeable constitue la base des applications de priorisation de la maintenance, de séquencement des migrations et d'autorisation des modifications décrites précédemment.
Enfin, l'indice MI, suivi dans le temps et recalculé après chaque cycle de changement significatif, indique si le programme s'améliore ou se dégrade. SMART TS XLL'analyse est effectuée sur la source actuelle plutôt que sur des instantanés mis en cache, garantissant ainsi que les indicateurs reflètent l'état réel du code source au moment de chaque analyse plutôt qu'une évaluation ponctuelle qui devient obsolète.
Des indicateurs adaptés au langage
L'indice de maintenabilité (MI) est une mesure pertinente et précieuse pour les portefeuilles COBOL, à condition de bien comprendre comment les caractéristiques syntaxiques de COBOL interagissent avec ses composants. Appliquer des seuils génériques aux programmes COBOL produit des résultats trompeurs. Compléter le MI avec les mesures qu'il ne prend pas en compte (couplage COPY, fan-in, profondeur des dépendances JCL, pourcentage de code mort) permet d'obtenir une image plus fidèle de l'expérience réelle des développeurs travaillant sur un portefeuille COBOL.
Les organisations qui utilisent efficacement ces indicateurs sont celles qui les considèrent comme un point de départ pour une réflexion éclairée, et non comme un jugement définitif sur la qualité d'un programme. Un score MI est un signal. Ce signal mérite d'être pris en compte : il indique systématiquement les programmes coûteux et risqués à modifier, et qu'il convient d'identifier avant toute modernisation. Toutefois, les indicateurs MI ne peuvent se substituer au jugement d'un développeur qui analyse le code, ni à l'analyse structurelle qui révèle les dépendances et la logique métier qu'aucun indicateur unique ne peut appréhender.
