Qu’est-ce qu’une application obsolète ou legacy ?
Selon la terminologie anglaise, une application “legacy” ou “héritée” évoque un système informatique ancien, d’une banque par exemple. Cela correspond à la définition de Gartner.
« Application qui peut être basée sur des technologies obsolètes, mais qui est essentielle aux opérations quotidiennes »
On peut aussi considérer qu’une application obsolète est une application qui coûte plus cher que ce qu’elle vaut. Sa maintenance demande des interventions régulières et la moindre évolution est chronophage. Voici donc une seconde définition :
« Application dont les coûts, en particulier de maintenance, dépassent sa valeur »
Même les applications les plus récentes peuvent être obsolètes. Il est possible de concevoir aujourd’hui une application qui sera tout de suite obsolète si l’on ne fait pas les bons choix techniques. Dans le domaine de la blockchain par exemple, qui est une technologie récente, Gartner disait l’an dernier que 90% des implémentations de blockchain devront être remplacées d’ici à 2021. Non seulement pour rester « compétitives », mais aussi sécurisées.
Synopsys partage dans son rapport “Open Source Security and Risk Analysis 2020 (OSSRA)” que presque toutes les bases de code auditées (au nombre de 1 250) contenaient au moins un composant open source. Cependant, 91 % des bases de code contenant des composants open source sont soit obsolètes de plus de quatre ans, soit n’ont connu aucune activité de développement au cours des deux dernières années.
5 critères pour mesurer l’obsolescence d’une application
Nous pouvons mesurer l’obsolescence d’une application métier par type de “dette”, de la plus critique à la moins critique :
1. La dette fonctionnelle
Le plus important des indicateurs d’obsolescence d’une application métier est la dette fonctionnelle. Elle mesure les écarts entre les fonctionnalités de l’application et les besoins des utilisateurs : l’application ne fait pas ou ne fait plus tout à fait ce qu’elle devrait, et cela pose problème au sein de l’entreprise.
Il est possible d’évaluer la dette fonctionnelle en demandant aux utilisateurs de répondre à une question simple du type “Sur une note de 1 à 10, comment diriez-vous que l’application répond à vos besoins ?”.
Pour aller plus loin, il est possible de demander aux utilisateurs de lister ce qui fait défaut dans l’application ou au contraire ce qui n’est plus utile. Si vous disposez de spécifications fonctionnelles à jour, cet exercice sera d’autant plus simple, rapide et pertinent ; vous pouvez par exemple comparer l’inventaire des cas d’utilisation de l’application existante à l’inventaire des fonctionnalités attendues par les différentes catégories d’utilisateurs.
La réalisation régulière de cet exercice, pour autant que des évolutions soient apportées à l’application entretemps, vous permettra de mesurer l’évolution de la dette fonctionnelle. A défaut d’évolution, il est certain que cette dette et par voie de conséquence l’obsolescence de l’application augmenteront au fil du temps.
2. La dette technologique
La dette technologique concerne les langages et les composants utilisés (notamment open source) lorsqu’ils ne font plus l’objet d’évolutions ni de maintenance. Lorsque les technologies utilisées posent problème, cela est un indice significatif d’obsolescence de l’application. Il s’agit de technologies anciennes, par exemple de vieux langages comme Cobol, Pascal, Delphi, Fortran, etc. Mais il s’agit également de technologies web récentes qui comportent des composants obsolètes.
A ce sujet, l’étude de Synopsys mentionnée en introduction montre que le code source de 9 applications métier sur 10 contient des composants open source obsolètes ou laissés à l’abandon. Dans 75% des cas, ce code open source contient des failles de sécurité connues. Ce taux est d’ailleurs en hausse et a pris 15 points en 1 an. Plus grave encore, dans 49% des cas, ce code source intègre des vulnérabilités à haut risque (taux en hausse de 10 points en un an), ce qui représente une menace importante pour l’entreprise.
Pour mesurer la dette technologique d’une application métier web, la première étape consiste à réaliser un inventaire des langages de développement, frameworks, composants, librairies, etc. La seconde étape consiste à associer à chaque élément recensé les informations qui permettront d’en mesurer l’obsolescence : fiabilité et pérennité de l’éditeur (un composant DevExpress posera moins de problèmes qu’un Bundle Symfony réalisé par un développeur seul), date de fin de maintenance ou maintenance à long terme (LTS) par exemple.
Pour qu’il soit complet, ce travail est fastidieux et quasiment impossible à tenir “à la main” du fait des dépendances entre de nombreux composants. Selon Gartner, les dépendances tierces représentent en moyenne 80% du code d’une application. L’aide d’un outil comme Dependency-track ou Sknyk est donc très utile.
3. La dette des tests
La dette des tests représente le manque de tests unitaires ou fonctionnels : sont-ils complets et correctement implémentés ?
Les tests unitaires permettent au développeur de vérifier qu’une partie spécifique de son code, indépendamment du reste de l’application, fonctionne correctement en toutes circonstances.
L’évaluation de la complétude des tests unitaires se fait par la mesure de couverture de code, avec des outils comme NCover pour déterminer le taux de code source qui est exécuté quand une suite de tests est lancée.
Les tests fonctionnels consistent à vérifier que l’application dans son ensemble, et non plus une partie du code, fonctionne correctement et conformément aux spécifications fonctionnelles. Pour toute application métier, il est indispensable de tester l’ensemble des fonctionnalités les plus critiques et les plus souvent utilisées avant la livraison d’une nouvelle version. Ces tests peuvent être faits manuellement en suivant un plan de tests, mais face à l’importance du travail que cela représente, la mise en place de tests fonctionnels automatisés s’impose, à l’aide d’outils mis en place par l’équipe de développement, comme Selenium par exemple.
La dette des tests fonctionnels s’apprécie en fonction de la complétude du plan de tests, de la fréquence de son exécution, de son degré d’automatisation et de la qualité des tests automatisés (lorsque le code des tests automatisés est à réécrire à la moindre évolution, ils n’apportent pas les bénéfices attendus)
4. La dette architecturale
L’architecture décrit la manière dont sont agencés les différents éléments d’une application et comment ils interagissent entre eux. La dette architecturale représente donc des choix de conception initiaux dépassés, qui constituent des freins aux évolutions de l’application, et par voie de conséquence au développement du service et de l’entreprise.
L’évaluation de la dette architecturale fait appel à une expertise technique avec pour but de mesurer à quel point la conception initiale de l’application est un frein aux évolutions de l’application par rapport à une architecture conforme aux standards actuels.
5. La dette technique
La dette technique représente les écarts par rapport aux bonnes pratiques et aux normes de programmation.
L’évaluation de la dette technique est réalisée par un audit quantitatif via un outillage spécialisé d’analyse de code, ce qui est le plus simple, et par un audit qualitatif via un système de revue de code réalisée par les développeurs entre eux.
La revue de code est un examen systématique du code source d’un logiciel. Il peut être comparé au processus ayant lieu dans un comité de lecture. L’objectif étant de trouver des bugs ou des vulnérabilités potentielles ou de corriger des erreurs de conception afin d’améliorer la qualité, la maintenabilité et la sécurité du logiciel. (Wikipédia)
Calcul de score d’obsolescence d’une application métier
Pour calculer le score d’obsolescence d’une application métier, nous attribuons d’abord un coefficient à chaque critère pour relativiser leur importance respective. Par exemple, le critère de dette fonctionnelle qui est à nos yeux le plus important a le coefficient 7 alors que la dette technique a le coefficient 3.
Ensuite, nous attribuons à l’application une note de 0 à 10 pour chaque critère : plus la note est élevée plus la dette et par voie de conséquence l’obsolescence de l’application est élevée.
Pour illustrer cet exercice, voici un exemple d’un de nos clients chez Axiocode. Une entreprise nous a confié une application développée il y a 4 ans, utilisant les langages Java (API) et EmberJS (front). L’application avait été développée par une équipe, en l’occurrence en offshore, puis maintenue successivement par deux autres équipes.
Nous avons calculé le score d’obsolescence de la façon suivante :
Tableau de score d’obsolescence
Dans cet exemple, l’application présente d’importants écarts entre ce qu’elle fait et ce qu’elle devrait faire. De nombreuses manipulations complexes sont nécessaires pour arriver au résultat voulu. La note de dette fonctionnelle est donc de 7/10. La dette technologique est encore plus élevée : elle reçoit la note de 8/10 car l’application est développée en front-end avec EmberJS, un framework ancien qui fait que pour modifier les écrans, il faut tout réécrire. La dette des tests est la plus élevée car en pratique il n’y a quasiment pas de tests, ni unitaires ni fonctionnels automatisés (9/10). La dette architecturale est moins importante car les choix de conception initiaux ne posent pas de problème majeur (5/10). Enfin, la dette technique obtient la note de 4/10 : même s’il n’y a pas de revue de code entre développeurs, le code produit respecte la plupart des normes de programmation.
La note finale atteint presque 7/10. En terme de score d’obsolescence, cela signifie qu’il est encore temps d’agir, mais qu’il faut le faire rapidement. C’est en l’occurrence ce qui a été décidé avec notre client : nous avons adopté une méthode évolutive qui consiste en un processus de modernisation systématique, étape par étape.
Nous estimons qu’à partir de 8/10, il est probablement trop tard pour reprendre le code source de l’application. C’est le remplacement pur et simple de l’application qu’il faudra alors le plus souvent envisager.
Cet exercice de mesure d’obsolescence permet de poser des notes sur les problèmes rencontrés avec l’application, de procéder avec méthode plutôt que se fier à des impressions. La bonne pratique serait de réaliser cette évaluation pour toutes les applications de l’entreprise au moins une fois par an. Cela permet d’anticiper et de prioriser les travaux informatiques qui permettront de prévenir l’obsolescence du patrimoine applicatif de l’entreprise.
Nous vous proposons d’évaluer vous-même votre application sous l’angle de son obsolescence. Le questionnaire ne requiert pas de compétences techniques. Il ne vous demande que quelques minutes.
Evaluez l’obsolescence de votre application
Rediffusion de notre conférence à ce sujet
présentée par Benoît Christiaens, Directeur des opérations et co-fondateur d’AxioCode / lors du salon Grand Est Numérique #GEN2020, le 10 septembre 2020.
Conclusion
Une application dans votre entreprise semble être obsolète ? Vous avez réalisé le tableau d’estimation d’obsolescence et obtenu une note supérieure à 5/10 ? Bénéficiez de notre service d’audit dédié aux applications métier web et mobiles pour obtenir une étude détaillée de votre application et une feuille de route.
Si vous souhaitez un accompagnement personnalisé pour la digitalisation de votre entreprise, la création d’une application mobile ou de votre propre application métier sur-mesure, réservez votre diagnostic gratuit avec l’un de nos experts.
Voici une infographie résumant les 5 critères pour mesurer l’obsolescence d’une application métier. Retrouvez toutes nos infographies sur notre compte Pinterest.
