De nombreuses entreprises utilisent des applications qui remplissent des fonctions essentielles aux activités quotidiennes, mais dont le fonctionnement est sous-optimal en termes d’accessibilité et de rapidité d’exécution, ou qui s’exécutent sur une plateforme désuète. Heureusement, il y a plusieurs possibilités pour moderniser d’anciennes applications.
Table des matières
- Qu’est-ce qu’une ancienne application ?
- Exemple d’anciennes applications
- Les désavantages d’utiliser d’anciennes applications
- Problèmes causés par des applications obsolètes
- Anciennes applications et sécurité
- Résistance à la modernisation
- Les raisons de mettre à jours les anciennes applications
- Qu’est-ce que la dette technique ?
- Les méthodes pour moderniser les anciennes applications
- Anciennes applications et migration vers le nuage
- Anciennes applications et intégration
- Qu’est-ce que le réusinage ?
- Les considérations lors d’une mise à jour
- Faire le saut
Qu’est-ce qu’une ancienne application ?
Une ancienne application est définie comme une application généralement ancienne, qui remplit encore des fonctions cruciales pour l’entreprise, mais qui est condamnée à être remplacée à court ou à moyen terme. Bien souvent, elle a été conçue pour un système d’exploitation, un appareil ou un environnement qui est tombé en désuétude, et son fonctionnement est compromis en raison de limitations techniques souvent insurmontables.
Puisqu’elle est forcément le produit de technologies plus anciennes, elle peut être trop lente ou trop difficile d’utilisation. La méthode de travail pour laquelle elle a été créée est peut-être disparue. Elle peut être basée sur un langage ou un programme informatique désuet pour lequel la maintenance requiert une main-d’œuvre rare et dispendieuse.
Elle peut aussi être incompatible avec les logiciels plus modernes, ce qui empêche le partage des données et l’arrimage des systèmes. Enfin, elle peut simplement être victime de la fin de la période de service de son fabricant, ce qui la laisse vulnérable aux problèmes de sécurité informatique.
À noter toutefois que, si le terme « obsolescent » suggère que l’application est très vieille, ce n’est pas toujours le cas. Il s’agit parfois tout bonnement d’une application pour laquelle il n’y a pas de soutien technique, ou qui ne répond plus aux besoins évolutifs de l’entreprise.
Quelques exemples d’anciennes applications
Les anciennes applications existent sur plusieurs types de plateformes. Dans le cas des applications de bases de données, on peut nommer entre autres MS Access.
La mort de Microsoft Access, un logiciel de bases de données destiné aux petites et moyennes entreprises, est annoncée depuis près de 20 ans, y compris par Microsoft elle-même. Malgré cela, l’application offerte avec la suite MS Office continue son chemin, et Microsoft a confirmé le maintien du soutien technique au moins jusqu’en 2025.
Pourtant, elle est considérée comme obsolescente par plusieurs, car ce n’est pas une application infonuagique. Elle peut toutefois être adaptée aux besoins modernes avec l’ajout d’interfaces Web et la possibilité de la faire migrer sur le nuage.
SAP est une autre application qui tend vers l’obsolescence. Bien que performante, elle gagne à être suppléée par des interfaces pour Web et mobile pour en tirer tout le potentiel. À l’inverse, un classique de la gestion interne comme Lotus Notes, qui a près de 30 ans, devrait être remplacé entièrement tant son architecture est difficile à adapter aux réalités modernes.
Quels sont les désavantages de l’utilisation d’anciennes applications ?
Vous vous en doutez sûrement, en continuant à utiliser d’anciennes applications, votre entreprise peut s’exposer à différents problèmes.
Le moindre d’entre eux est le ralentissement relatif de vos opérations. L’évolution des ordinateurs promet constamment des temps d’exécution plus courts, mais vous ne pouvez pas en profiter si vos applications ne sont pas compatibles avec le matériel récent.
Il y a également le coût et le temps de maintenance catastrophiques liés à la gestion d’applications qui doivent être constamment surveillées, redémarrées, adaptées…
Quels sont les problèmes causés par des applications obsolètes ?
Par exemple, aux États-Unis, des problèmes dans le système de gestion du chômage, vieux de 40 ans, ont causé des retards dans les paiements pour 13 % des chômeurs. À l’agence qui gère les impôts, le Internal Revenue Service, les déclarations de revenus de 5 millions d’Américains n’ont pas pu être traitées à temps en raison d’une panne. La rareté des programmeurs COBOL, dans les deux cas, a retardé le rétablissement du service.
Du côté des banques, la Royal Bank of Scotland a vu ses services de connexion et de traitement des paiements connaître des ratés. Ses systèmes fonctionnent encore sur des ordinateurs centraux IBM des années 90.
Sans surprise, une étude[1] a démontré que le fait de garder d’anciennes applications dans des banques peut accaparer jusqu’à 78 % de leur budget de TI, et 70 % de ces banques affirment que ces systèmes constituent le goulot d’étranglement dans une optique de changement. De même, les directeurs des technologies de l’information interrogés affirment que de 40 à 60 % de leur temps est consacré à la gestion des anciennes applications.
Anciennes applications et problèmes de sécurité
Pire encore, il y a la question de la vulnérabilité au piratage.
S’il peut sembler sécuritaire d’utiliser de vieilles applications, en apparence trop obscures pour être piratées, ce n’est pas toujours le cas. Certaines d’entre elles ont arrêté de recevoir des mises à jour de sécurité, ou n’en ont littéralement jamais eu. De façon générale, plus un système est ancien, plus ses vulnérabilités ont pu être documentées.
Par exemple, en 2015, à cause de vulnérabilités informatiques de systèmes vieillissants, une intrusion au National Background Investigations Bureau a causé une fuite de données concernant des employés fédéraux et leur famille, ainsi que des détails sur leur habilitation de sécurité.
Plus de 22 millions de personnes ont été touchées et les conséquences précises de cette fuite ne sont toujours pas bien comprises. Théoriquement, des nations hostiles et connues pour leurs attaques informatiques, comme la Russie et la Chine, pourraient exploiter ces données à leur avantage sans vraiment pouvoir être arrêtées.
Pourquoi alors les entreprises résistent-elles à la modernisation de leurs anciennes applications ?
Il y a, entre autres, la peur de la défaillance. Les entreprises qui utilisent d’anciennes applications ne le font habituellement pas par choix, mais tout simplement parce que leur flux opérationnel a été développé autour d’une application précise. Tout changement, si nécessaire soit-il, devient alors un risque direct à la rentabilité immédiate.
Les coûts de la modernisation sont souvent inconnus sans une analyse approfondie, mais peuvent s’avérer astronomiques si la documentation n’est pas à jour ou que l’application concernée est particulièrement difficile à moderniser.
La modernisation des applications de l’entreprise dépend alors d’un savant calcul : quels sont les coûts et les risques liés au statu quo et au changement, et quel rythme de changement convient le mieux. Et à quelle vitesse le changement devrait-il se produire ?
Pourquoi les anciennes applications doivent-elles être modernisées ?
Puisque ces applications, par définition, ne peuvent plus être adaptées aux normes actuelles, il vous faut trouver des façons de les garder compatibles avec vos autres équipements alors que ceux-ci continuent d’évoluer.
Ces « solutions », obligatoirement temporaires et sous-optimales, contribuent à accroître ce que l’on appelle la « dette technique ».
Qu’est-ce que la dette technique ?
C’est la somme du temps et de l’argent que vous devrez « rembourser » un jour ou l’autre alors que vous repoussez le changement que vous devrez effectuer tôt ou tard. Plus succinctement : plus vous vous laissez dépasser, plus le retard à combler est important.
À cette dette s’ajoutent les risques de sécurité inhérents aux applications périmées. Une application récente jouit d’un soutien technique constant pour vous parer contre les menaces, ou simplement pour vous venir en aide.
Ainsi, choisir la stabilité n’est pas payant à long terme et vous devrez calculer rigoureusement le coût global des options qui se présentent à vous. La modernisation est inévitable, surtout quand son coût approche le coût de votre dette technique, mais vous pouvez choisir la méthode et le degré de modernisation qui vous conviendront.
Méthodes de modernisation des anciennes applications
La modernisation des anciennes applications permet de les rendre plus extensibles, de réduire leurs coûts d’entretien et de les rendre plus efficaces et performantes.
Il existe essentiellement trois façons de moderniser vos anciennes applications : l’extension, par laquelle vous ajoutez des fonctionnalités qui répondent à vos nouveaux besoins ; le réusinage, par lequel vous reconstruisez quelques composantes dans une logique de modularité et d’interopérabilité ; le remplacement, par lequel vous repartez de zéro pour développer une nouvelle application entièrement adaptée à vos besoins commerciaux.
Si votre application était une maison, l’extension se traduirait par le simple ajout de fenêtres et de portes. L’intérieur de votre maison est resté le même, mais il peut être vu et utilisé de plus de façons, par exemple sur le Web et sur votre mobile.
Le réusinage (refactoring) se compare à de la rénovation. Vous reconstruisez et réarrangez quelques éléments pour qu’ils deviennent plus performants, plus faciles d’utilisation, plus à la mode, plus simples d’entretien, plus accueillants… Bref : une remise à neuf, sans détruire la structure originale.
Le remplacement, évidemment, se compare à la construction d’une nouvelle maison, qui répond totalement à vos besoins. Le coût de chacune de ces options est à l’avenant.
Peut-on faire migrer les anciennes applications sur le nuage ?
Absolument. En fait, même le vénérable MS Access peut être transféré sur le nuage. Il faut toutefois vous assurer que les applications concernées puissent y fonctionner correctement.
Plusieurs méthodes existent pour faire migrer vos données sur le nuage :
- Le réhébergement (rehosting) : L’application entière est tout simplement copiée sur le nuage. Comme l’intégralité de vos données reste inchangée, tout fonctionne exactement comme avant, mais est hébergé sur des serveurs externes.
- L’approche par étapes : Vous placez uniquement sur le nuage les éléments que vous considérez comme essentiels, et gardez certaines composantes à l’interne.
- Le réusinage : Vous modifiez votre application pour tirer parti d’un maximum des avantages qu’offre le nuage.
Toutes les anciennes applications ne peuvent pas nécessairement être migrées aisément sur le nuage ; vous devrez vous interroger sur les particularités de la vôtre.
Fonctionnera-t-elle dans un environnement multiserveur ? Les données devront-elles être cryptées ? Votre code pourra-t-il recevoir et traiter le nombre accru de requêtes ? Vos réponses à ces questions dicteront votre choix.
Les anciennes applications peuvent-elles s’arrimer à des applications plus récentes ?
Certainement, c’est même l’un des objectifs principaux.
Si les anciennes applications, par définition, ne sont pas conçues pour interagir avec les plus récentes, il y a moyen de le faire, notamment par l’ajout d’applications tierces, comme des API, ou au moyen d’un service de plateforme d’intégration (IPaaS).
Ceux-ci permettent de « traduire » les différents langages de vos applications anciennes et modernes pour qu’elles se comprennent entre elles et interagissent de façon fluide.
Si vous n’avez que peu d’interactions de synchronisation à effectuer, vous pouvez également les programmer vous-même sans avoir recours à de tierces parties, mais cette solution n’est pas aisément applicable à grande échelle.
En quoi consiste le réusinage d’une ancienne application ?
À mi-chemin entre l’extension et le remplacement, le réusinage d’une application consiste à restructurer et à optimiser son code source sans changer ses fonctionnalités de base. C’est la solution à privilégier quand vous avez l’option de conserver ce qui est utile et de moderniser le reste à votre rythme.
Par exemple, le code peut être modifié pour le rendre plus lisible, moins complexe, plus facile à maintenir et à développer. Des modifications peuvent être apportées aux fonctionnalités pour optimiser leur exécution. Comme pour la méthode d’extension, aucune modification n’est apportée à la partie dorsale (back-end) de votre application.
Pour revenir à l’analogie de la rénovation d’une maison : des murs sont refaits ou abattus pour créer une nouvelle façon, optimisée, de profiter du même environnement.
Le réusinage d’une application peut mener à une meilleure rapidité d’exécution, à une réduction des coûts et de la durée de la maintenance, à une simplification de l’ajout de nouvelles fonctionnalités et à une meilleure expérience utilisateur
Quels facteurs devraient être pris en compte dans la modernisation des anciennes applications ?
La performance — est-ce que votre application comble actuellement les besoins de votre entreprise ?
L’application doit actuellement répondre à vos besoins, et être en mesure de le faire dans un avenir rapproché. Si ce n’est pas le cas, la simple modernisation n’est peut-être pas la solution souhaitée par rapport à un remplacement pur et simple. Une évaluation sommaire de vos besoins s’impose ici.
La compatibilité — votre application est-elle raisonnablement compatible avec des logiciels tiers ?
La modernisation implique généralement l’ajout de logiciels créés par des tiers pour implémenter les nouvelles fonctionnalités. Si le code de votre application est trop limité, cela pourrait s’avérer impossible.
Le coût — est-ce que le coût prévu de la modernisation en vaut la chandelle ?
Plusieurs méthodes de modernisation existent, du simple réhébergement à une refonte quasi totale de l’architecture de votre application. Une analyse des coûts de chaque option s’impose.
L’extensibilité — est-ce que votre application pourra répondre à une demande croissante ?
Dans sa forme modernisée, votre application pourrait-elle répondre adéquatement à la croissance que vous espérez ?
Le risque — vos données pourraient-elles être compromises pendant la modernisation ?
Une migration est un transfert de données de vos serveurs à ceux d’un tiers. Êtes-vous en mesure de gérer ce type de risque ? Des différentes méthodes de modernisation offertes, avez-vous déterminé celle qui correspond le mieux à votre tolérance au risque ?
L’échéancier — avez-vous le temps de vos ambitions ?
Une modernisation qui consiste en un simple réhébergement ne prend que très peu de temps en comparaison à un réusinage. Plus votre application est complexe et plus vos demandes sont élaborées, plus le délai de modernisation s’étire.
Et comme pour tout exercice de programmation, le temps requis peut être beaucoup plus long que prévu. Il est crucial ici de définir vos besoins le plus précisément possible.
Faire le saut
Si vous avez besoin d’aide pour vous retrouver parmi les innombrables options qui s’offrent à vous, n’hésitez pas à communiquer avec nous.
Nous avons plus de 20 ans d’expérience et offrons plusieurs plateformes pour effectuer la modernisation de vos applications, notamment OutSystems, Laravel et Claris.
Nous saurons vous accompagner dans vos démarches, quels que soient l’ampleur de votre projet ou le budget dont vous disposez.
Sources :
[1] https://www.slideshare.net/NTTDConsulting/dont-fear-modernizing-your-core-banking-innovation-in-the-digital-age-61089885
https://www.outsystems.com/glossary/what-is-legacy-system/
https://www.outsystems.com/use-cases/app-modernization/
https://www.outsystems.com/blog/posts/examples-legacy-systems/
https://www.outsystems.com/blog/posts/application-modernization-strategy/
https://www.outsystems.com/glossary/what-is-technical-debt/