Qu’est-ce qu’une application obsolète ?
Une application obsolète se rencontre généralement lorsqu’elle contient des technologies qui ne sont plus au niveau, qui ne suivent pas les évolutions technologiques ou logicielles. L’application peut avoir des failles de sécurité, ne plus répondre au besoin utilisateur, poser des problématiques de maintenance. Voyons plus en détail les différentes définitions et terminologies données à une application obsolète.
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 en 2019 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. Il est donc important de vérifier le numéro de version de chaque technologie utilisée par l’application.
Synopsys partage dans son rapport “Open Source Security and Risk Analysis 2020“(OSSRA) que presque toutes applications auditées (au nombre de 1250) contenaient au moins un composant open source dans 91 % des cas avec des composants obsolètes depuis plus de quatre ans ou sans aucune activité de développement au cours des deux dernières années.
1. L’application est décriée au sein de l’entreprise
Le plus simple des indices d’obsolescence : l’application est décriée au sein de l’entreprise. On peut faire confiance aux utilisateurs pour nous dire qu’ils perdent du temps à cause de problèmes d’ergonomie, de fonctionnalités défectueuses, de double saisie… Ces problèmes sont autant de signes révélateurs qui indiquent qu’il faut y regarder de plus près.
Bien sûr, une application ne peut pas être parfaite et il y aura toujours des personnes qui ne sont pas entièrement satisfaites. Certaines remarques peuvent être futiles, mais il faut tout de même y prêter attention pour ne pas passer à côté d’un problème majeur.
2. L’application est critique et irremplaçable
A partir du moment où une application est critique pour le business, et par conséquent irremplaçable, il faut la surveiller de près et veiller à ce qu’elle ne devienne pas obsolète.
Quand on parle d’application “irremplaçable”, il n’est sans doute pas nécessaire de s’inquiéter pour un formulaire de demande de congés qui ne fonctionne pas correctement. Cela ne veut pas dire que ce genre de problème n’est pas important, il faut tout de même s’en occuper. Mais l’attention à y porter et l’évaluation de son obsolescence sont moins importantes que pour une application critique pour le business.
3. Des évolutions urgentes sont trop coûteuses ou trop complexes
Lorsque l’entreprise dispose d’une application métier utilisée au quotidien, il arrive assez fréquemment que des besoins d’évolution émergent, pour apporter un nouveau service par exemple. S’il s’agit d’une application web développée sur-mesure, c’est vers l’équipe technique chargée du développement ou de la maintenance de l’application que l’on va se tourner pour discuter des évolutions et les planifier.
La réponse de l’équipe technique sera un indice très révélateur du degré d’obsolescence de l’application. Dans le cas le plus favorable, la réponse sera positive : la demande d’évolution sera inscrite dans le plan de développement, la “road map”, et si l’évolution est urgente, elle sera placée en priorité sans trop de difficultés. A l’inverse, si les développeurs annoncent des délais importants, des risques de régression, des problèmes de tests et de documentation etc…, il est plus que probable que l’on se trouve à un stade avancé d’obsolescence.
4. Les technologies utilisées sont problématiques
Au fil du temps, il se peut que les technologies utilisées dans l’application finissent par poser problème. L’évolutivité de l’application est un des principaux problèmes que peut poser une application métier obsolète dans une entreprise.
Certaines applications métier ont été développées avec des langages anciens, sur lesquels les compétences sont devenues rares (Cobol, Pascal, Delphi, Fortran…).
Mais des applications récentes faisant appel à des technologies web tout autant récentes peuvent également être obsolètes. Quasiment toutes les “applications métier” (applications professionnelles) web sont développées avec des composants open-source. Or, le code source de 9 applications métier sur 10 contient des composants open source obsolètes ou laissés à l’abandon. (source : Synopsys).
L’ancienneté des technologies utilisées dans l’application est un critère d’obsolescence, mais il est à noter que les applications web les plus récentes font appel à des composants obsolètes, voire dangereux pour l’entreprise : il est essentiel d’en faire l’inventaire et de vérifier régulièrement les problèmes que chacun d’eux peut poser.
5. Il n’existe pas de tests automatisés
L’application n’a aucun test automatisé pour vérifier son bon fonctionnement ? Ce critère peut avoir l’air anodin, pourtant, il est très important : on peut dire à coup sûr qu’une application métier sans tests automatisés risque rapidement de devenir obsolète. On ne parle pas ici de tests unitaires (techniques) mais de tests fonctionnels automatisés.
Lorsque des modifications sont apportées à une application, il arrive assez fréquemment que les tests se limitent aux fonctionnalités directement impactées par ces modifications. Or, des composants ou des ensembles de code sont souvent communs à différentes parties de l’application. Au final, d’une façon ou d’une autre, il arrive régulièrement qu’une modification apportée à une fonctionnalité, par effet de bord, entraîne un dysfonctionnement d’autres fonctionnalités. Si l’ensemble de l’application n’est pas testé à l’issue des travaux de développement, des bugs apparaîtront en production.
Il est donc nécessaire de tester l’ensemble de l’application sur les fonctionnalités les plus critiques et les plus souvent utilisées. Face à l’importance du travail que représentent ces tests, la solution consiste à les automatiser, avec des outils et du code spécifiques. Au final, il est certain que si les tests ne sont pas automatisés alors ils ne seront pas correctement réalisés, ce qui entraînera des régressions et une accélération de l’obsolescence de l’application.
6. L’application a des problèmes importants de conception
L’obsolescence d’une application peut tout simplement être provoquée par sa conception en elle-même. Une application mal conçue au départ va devenir obsolète très rapidement.
Ce sera le cas par exemple lorsque le développement a été confié à quelqu’un qui n’avait pas les compétences nécessaires. Ce peut être un(e) stagiaire embauché(e) pour un projet de développement, mais sans l’encadrement technique adéquat. L’application a été mal pensée dans sa conception. En comparaison avec la construction d’une maison : soit les plans ont été mal réalisés, soit il n’y avait même pas de plan.
7. Les compétences techniques sont perdues
Il arrive que les développeurs de l’application ne soient plus dans l’entreprise ou chez le prestataire informatique chargé de l’application ; il se peut également que ce prestataire ait disparu ou que sa relation avec l’entreprise ait été rompue. Pourtant, les compétences requises à la maintenance de l’application sont très spécifiques. Dans ce cas, il est compliqué de maintenir durablement l’application en bon état de marche. Encore pire, dans certains cas, les développeurs n’ont pas laissé de documentation ni fonctionnelle ni technique pour accompagner l’application. Ou bien cette documentation a été réalisée au début du projet mais n’a pas été actualisée au fil des mises à jour de l’application, ce qui est très fréquent. La nouvelle équipe chargée de l’application va donc devoir réaliser une rétro-conception fonctionnelle et technique afin de comprendre comment elle est développée, situer le ou les problèmes et seulement à partir de là, voir si elle est en capacité de les régler.
Rediffusion de notre conférence sur les applications obsolètes
Conférence 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 ? Il y a des indices qui le montrent ?
Nous vous proposons d’évaluer vous-même votre application sous l’angle de son obsolescence. Complétez le questionnaire ne requiert pas de compétences techniques. Il ne vous demande que quelques minutes.
Evaluez l’obsolescence de votre application
Vous pouvez également bénéficier 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 cet article. Vous trouverez toutes nos infographies sur notre compte Pinterest Axiocode.
Comment savoir si une application est obsolète ?
