Les dangers des systèmes legacy

« Si ça marche, il ne faut pas y toucher » (if it ain’t broke, don’t fix it). Cette phrase, vous l’avez sans doute déjà entendue, prononcée sur le ton de l’absolue vérité apodictique universelle, transcendantale et indiscutable, de la bouche de votre patron, de votre supérieur hiérarchique, ou de vos collègues de bureau. Le problème, c’est qu’à force de ne pas y toucher, les systèmes, prenant de l’âge, deviennent obsolètes et finissent par ne plus répondre aux normes informatiques, que ce soit au niveau du codage, de la sécurité ou de l’architecture. À présent, ces anciens logiciels, ces systèmes legacy, représentent un danger pour les grandes entreprises qui ne peuvent plus ni les maintenir ni s’en débarrasser aisément. Des bugs nouveaux ou longtemps cachés apparaissent : failles de sécurité, incompatibilité de systèmes, données incohérentes, threads en deadlocks... Que représente la menace des systèmes legacy ? Comment y faire face ? Quels sont les moyens et bonnes pratiques à mettre en place ? Nous allons tenter d’y répondre dans la suite de cet article [1].

1. Des systèmes obsolètes

Nous sommes en 2020, cela fait plus de 60 ans que nous sommes entrés dans l’âge informatique. Si les premiers ordinateurs pesaient des tonnes et remplissaient une pièce, comme l’IBM 704 à tubes à vide et carte perforée qui pouvait exécuter 40 000 instructions par secondes (1954) [2], aujourd’hui ils tiennent dans la poche, un processeur ARM Cortex-A75 de smartphone par exemple peut exécuter 3 000 000 d’instructions par seconde et par cœur [3]. Si on ajoute les processeurs graphiques, le stockage sur des mémoires de plusieurs gibioctets, des disques durs de plusieurs tébioctets, le tout interconnecté par des réseaux de plusieurs mébioctets par seconde, on se rend compte de l’explosion de la puissance du traitement de l’information, suivant la fameuse loi de Moore.

Les logiciels qui tournaient sur les premiers ordinateurs ne fonctionnent bien évidemment plus sur nos machines… bien évidemment ? Pas tout à fait. Pour d’obscures raisons, parfois économiques, parfois juste par ignorance, le plus souvent par conservatisme, certaines entreprises ont décidé de maintenir leurs anciens logiciels coûte que coûte au fil des années, faisant fi de toute évolution technologique. « On ne change pas les choses qui marchent », diront-ils. Ces logiciels qui tournaient sur les premiers mainframes IBM et leurs logiciels environnants, le middleware, sont encore utilisés de nos jours.

Empilement de lignes de code sur lignes de code, durant plus de quarante ans, ces monstrueux programmes monolithiques de centaines de milliers – si ce n’est pas de millions – de lignes de code datant d’une autre époque apparaissent aujourd’hui tels qu’ils sont : des monstres, des dinosaures, des horreurs cauchemardesques. Analyser la totalité de leur code vous brûlerait les yeux et la cervelle à coup sûr, mais si par miracle vous trouvez un analyseur de code assez robuste pour le faire, il vous listera des centaines de milliers d’erreurs de code, de tout type, parfois totalement farfelues, parfois réellement critiques, comme des erreurs logiques de tests conditionnels, des erreurs de pointeurs, des variables en vrac, d’énormes blocs de code copiés-collés des centaines de fois, des boucles while (true) de la mort du CPU, des tonnes de sleeps, de threads non sécurisés, de sémaphores qui s’entre-bloquent, des fuites de mémoire et j’en passe… bref, les pires erreurs de code et de design, à vous donner des sueurs froides pendant plusieurs semaines.

2. Des erreurs d’autrefois

Pourquoi tant d’erreurs ? Pour la simple raison que l’on ne codait pas il y a quarante ans comme on code aujourd’hui.

2.1 Un développement à l’ancienne

Tout d’abord, il n’y avait pas d’outils de développement comme les tests unitaires, les tests d’intégration, les analyseurs de code, les revues de code ; il fallait se contenter de tests fonctionnels. Du coup, l’important c’était le résultat, non la façon de coder. Des tas de boucles dans les fonctions hasardeuses n’étaient pas un problème si le résultat était correct, au moins durant les tests fonctionnels. La réduction de la complexité cyclomatique, l’optimisation de code, la factorisation (refactoring) restaient secondaires.

2.2 Un environnement qui a évolué

Ensuite, l’environnement matériel n’était pas le même. Les débits réseau, quand il y avait du réseau, étaient très limités (300 caractères par seconde, ou bauds, pour les premiers modems en 1972), de même, comme on l’a vu, les capacités en mémoire, disque dur et CPU [4]. De ce fait, ces programmes n’étaient pas prévus pour tourner en multi-threads à plus de 100 Mio par seconde sur des processeurs 64 bits. Et si dans certains cas, ils étaient en multi-threads, c’était souvent plus un traitement itératif que parallèle, attendant qu’un thread se termine pour passer à un autre qui était en attente. Utilisez ce même programme avec des centaines de threads sur les architectures d’aujourd’hui, vous aurez toutes les chances de le faire entrer dans des boucles non prévues par le système et d’interbloquer les threads au bout de quelques minutes.

L’aspect matériel est très important, car les contraintes étaient différentes. Il y a trente ans, la mémoire était alignée sur 8 ou 16 bits, alors qu’elle est alignée sur 64 bits aujourd’hui, ce qui peut engendrer des erreurs d’adresse mémoire et des incompatibilités entre bibliothèques. Les processeurs n’avaient pas les mêmes capacités ni les mêmes jeux d’instructions. Aujourd’hui, le chiffrement AES peut être accéléré par le processeur, par exemple [5]. Par ailleurs, le chiffrement d’il y a trente ans, le DES, est totalement obsolète et peut être craqué très rapidement.

2.3 Des normes de sécurité différentes

Enfin, les standards, les normes, ont évolué. Durant ces dernières décennies, les systèmes informatiques ont sans cesse été perfectionnés pour améliorer leur sécurité et leurs performances. De nouvelles recommandations et nouvelles normes ont été élaborées : norme ITIL pour les services IT, règles de codage MISRA, DO-178, HIC++ et autres incorporées dans les analyseurs statiques de code, nouvelles versions de langages certifiées ISO qui apportent aussi leurs lots d’améliorations et de nouvelles fonctionnalités (C18, C++17, Java SE 16, C# 9...), ou même de nouveaux langages souvent plus efficaces pour certaines tâches, comme TypeScript pour s’abstraire du JavaScript, ou Erlang pour la communication par exemple (cf. RabbitMQ). Sans oublier de nouvelles normes de chiffrement (AES, TLS) et de sécurité (ISO 27000). Toutes ces évolutions font défaut sur la plupart des systèmes legacy.

3. Un danger bien réel

En 2020, Internet compte plus de 4,5 milliards d’internautes, en particulier dû à l’explosion des smartphones. Leur nombre n’était que d’un milliard en 2005, année de lancement de YouTube, et juste 500 millions en 2001, année de lancement de Wikipédia [6].

De ce fait, le nombre d’attaques augmente également, surtout par messagerie (phishing), et plus encore durant l’épidémie de COVID : 812 millions d’attaques de malwares en 2018 contre 12 millions en 2009, 98 % des attaques par ingénierie sociale. Plus pernicieuses, plus ciblées, que ce soit depuis l’extérieur ou depuis l’intérieur des entreprises, utilisant des techniques de plus en plus perfectionnées, infiltrant les moindres failles de sécurité informatique et humaines, par messagerie notamment, avec des ransomwares qui chiffrent les disques durs, des portes dérobées (backdoors) qui donnent l’accès aux droits administrateur ou la prise de contrôle à distance, aucun service n’est à l’abri [7].

Les origines sont très diverses, allant du jeune boutonneux qui s’amuse avec un rootkit, comme Elliott Gunton, jusqu’aux groupes de hackers chevronnés, souvent politisés, comme les groupes Equation, les Shadow Brokers, Lizard Squad, SEA, CCC, NHCP, Tarh Andishan, Sofacy, The Dukes, The Lamberts, Lazarus, Turla, les Anonymous, et tant d’autres, en passant par des professionnels comme Evgeniy Bogachev ou Phineas Phisher... Quelques groupes ont été démantelés toutefois, comme LulzSec en 2012.

Parfois, ces attaques ne font aucun dégât, se contentant de récupérer des données sensibles, avec un spyware par exemple, mais il arrive qu’au contraire, elles occasionnent un maximum de dégâts en modifiant ou détruisant des données, en mettant des serveurs hors service, ou en prenant leur contrôle (C2, Command and Control), avec des attaques DoS (denial-of-service), des virus, des malwares, des bots, des chevaux de Troie (trojan), etc. Le cloud n’est pas exempt d’attaques, surtout si les entreprises profitent des offres IaaS (Infrastructure as a Service) pour y migrer leurs systèmes legacy [8] [9].

Attention toutefois, les incidents et pannes informatiques ne proviennent pas tous d’attaques de pirates, loin de là. La plupart du temps, il peut s’agir d’un bug de programme, d’une incompatibilité avec d’autres logiciels, ou d’une erreur de manipulation. C’est pourquoi les risques de défaillance sont à la fois externes et internes. Pour bien comprendre les dangers que représentent de tels systèmes aujourd’hui, voici une liste d’incidents graves dus à leur utilisation :- juin 1996, le vol 501 inaugural de la fusée Ariane 5 explose à la suite d’un bug dans son système de guidage inertiel, qui l’a fait dévier de 90° de sa trajectoire. En effet, le système avait été pris tel quel de l’ancienne fusée Ariane 4, sans même l’avoir testé sur Ariane 5, alors que les contraintes et paramètres ne sont pas les mêmes. 500 millions de dollars partis en fumée (la fusée et ses satellites embarqués) [10] ;

• décembre 1999, le monde panique face au changement de millénaire non anticipé par les anciens systèmes informatiques. Ce Y2K bug (Year 2000 bug) fit que de nombreux systèmes affichèrent un retour à l’année 1900 [11] ;
• décembre 2004, le directeur de la compagnie Comair Airline fut viré à la suite du bug de leur système legacy de planification. Ce bug avait généré l’annulation de tous les vols de la compagnie, du 25 et du 26 décembre 2004 [12] ;
• octobre 2011, la banque MF Global fit faillite après que son système legacy ait gelé tous les comptes de ses clients [13] ;
• juin 2012, RBS, the Royal Bank of Scotland, met à jour son système legacy et le fait crasher : un million de clients n’arrivent plus à payer avec leurs cartes ni à retirer de l’argent [14] ;
• janvier 2017, en Angleterre, dans le Yorkshire, le système legacy vieux de 35 ans des hôpitaux de Leeds laisse des milliers de patients en attente prolongée de leurs opérations et des résultats de tests [15] ;
• mai 2017, le ransomware WannaCry exploite une faille de Windows XP et de Windows Server 2003, qui ne sont plus supportés par Microsoft depuis 2014 et 2015 respectivement, et infecte des millions de machines dans le monde en chiffrant les disques durs [16] ;
• avril 2020, aux États-Unis, l’arrivée massive de personnes au chômage à la suite du COVID-19 met à mal les systèmes legacy des agences pour l’emploi [17].

Aussi l’un des meilleurs moyens de se protéger est de mettre à jour continuellement les logiciels, ainsi que le matériel ; chaque mise à jour apportant son lot de correctifs. Ces risques sont d’autant plus élevés avec le fait de maintenir des systèmes legacy, des logiciels de plus de vingt ans qui, de toute évidence, représentent des malwares selon les normes de sécurité actuelles. Aussi, les entreprises auront beau investir dans de nombreux outils de sécurité dernier cris, Zero Trust, SSO (Single Sign On), WAF (Web Application Firewall), VPN (Virtual Private Network), EDR (Endpoint Detection and Response) et autres, si en définitive leur système informatique se base sur un logiciel obsolète bourré de bugs et de failles de sécurité, c’est comme construire un château fort sur un marécage, ça ne tiendra pas, même au deuxième château, même au troisième (cf. « Monty Python and the Holy Grail »).

4. Que faire face à un système legacy?

Analyser les risques de ces systèmes legacy dans les grandes entreprises est un réel défi. Souvent, les équipes qui les maintiennent seront dans le déni, les audits faussés, et ces logiciels peuvent se trouver dans n’importe quel service, sur n’importe quel poste. Dans les plus anciennes entreprises, on ne parle pas d’un ou deux systèmes legacy, ça peut être toute une myriade, une constellation de systèmes legacy en tout genre, résultat de plusieurs décennies de bidouillages tous azimuts. Faites un audit des logiciels présents sur tous les postes et serveurs de l’entreprise (parfois ils peuvent être bien cachés, vérifiez la liste des services, des tâches planifiées, des exécutables). La situation ne s’améliorera pas sans une réelle prise de conscience de l’entreprise. Si vous êtes face à un tel système, voici quelques pistes pour vous aider.

4.1 Documentation

D’emblée, si vous y allez franco en disant que « c’est pas possible, c’est trop de la merde », l’équipe va vous tourner le dos, et vous allez vite vous retrouver sur un autre poste. Dans ce genre de situation, il faut rester prudent et diplomate. Un système qui est en place depuis plus de vingt ans, ce n’est pas pour rien, d’autres avant vous ont sûrement essayé de faire bouger les choses, mais ont échoué. Dans une grande entreprise, les rouages sont lents, l’inertie extrêmement forte, les décisions prennent du temps et n’aboutissent pas souvent. Vous ne pourrez rien faire les premiers jours. Aussi la première chose, c’est de gagner la confiance de l’équipe, de dialoguer avec eux pour avoir un maximum d’informations et de documentation.

Avant de s’attaquer au code, faites un état des lieux. Quel est le périmètre du système ? Est-ce qu’il est utilisé par d’autres logiciels, et comment ? Quels sont ses utilisateurs ? Sur quels serveurs ou postes est-il installé ? Comment fonctionne-t-il à l’usage ? Essayez de tracer le flux des données de bout en bout, et ses cas d’utilisation (démarrage de l’application, utilisation standard de l’application, déploiement d’une mise à jour, etc.).

Si le système est installé sur tous les serveurs et s’il est utilisé par tous les utilisateurs de l’entreprise, vous êtes dans une situation très délicate, mais pas de panique. Continuez votre étude du système, ça servira par la suite. Surtout, rédigez tout ce que vous faites, tenez un journal, mettez-y toutes les informations du jour.

Ne restez pas isolé dans une équipe qui peut vous mettre une chape de plomb à la moindre critique. Essayez de trouver du soutien dans d’autres équipes pour vous appuyer le moment venu : ingénieurs, architectes, développeurs chevronnés, ils vous donneront de bons conseils.

4.2 Tests du code, options de compilation, déploiement, diagrammes de séquence

Une fois que vous aurez une bonne compréhension du système, vous pourrez commencer à regarder le code. Attention, un code vieux de plus de vingt ou trente ans, ça froisse les sourcils, ça pique les yeux. Vous y trouverez certainement des blocs de plus de 10 000 lignes, bourrés de sauts conditionnels, de boucles infinies, d’events et de sémaphores, de threads, de sleeps, de variables et pointeurs non initialisés, de try/catch imbriqués, sans tests unitaires ou très peu, sans optimisation ni factorisation, bref, les pires erreurs que l’on puisse trouver dans du code. Il faut prendre un peu de recul, c’est du code préhistorique que vous observez.

Première chose à faire, c’est de voir comment il compile, ses options de compilation. Vous trouverez peut-être quelques joyeusetés, comme des tonnes de warnings passés à la trappe, des liens avec des bibliothèques inconnues ou obsolètes, du déploiement post-compilation, des alignements en mémoire fixes, etc.

Ensuite, il faut trouver les points d’entrée. Si c’est la fonction main pour un exécutable, ce n’est pas toujours évident pour une bibliothèque ou un service.

À partir de ces points d’entrées, vous pourrez commencer à parcourir le code. D’ailleurs, il contient sûrement de grosses parties de code mort ; partir d’un point d’entrée vous évitera de les parcourir inutilement. Les diagrammes de séquences UML (Unified Modeling Language) s’avéreront très utiles pour cette tâche. Si vous n’avez pas d’éditeurs UML sous la main, ou si vous n’avez pas l’habitude des diagrammes UML, c’est l’occasion d’en essayer un, ça vous servira toujours par la suite pour réaliser des diagrammes standards pour vos documents. Il existe de nombreux éditeurs UML sur le marché, comme Modelio, complet et gratuit, LucidChart online, www.websequencediagrams.com, www.draw.io, l’open-source ArgoUML, Enterprise Architect, un module UML sur la version pro de Visio, MagicDraw, StarUML, Gliffy et bien d’autres.

Inutile d’aller trop en profondeur dans le diagramme, modélisez juste les grandes lignes. Faites plusieurs petits diagrammes clairs, plutôt qu’un gros diagramme illisible. Privilégiez les formats d’export scalables (SVG, EMF et autres). Ajoutez-y quelques annotations pour aider à la compréhension (noms de fichiers et numéros de lignes, par exemple). Ces diagrammes vous seront utiles pour rédiger des rapports d’analyse et pour vous y retrouver dans le code.

S’il y a des tests unitaires, parcourez-les, ça peut aider à la compréhension du code. S’il n’y en a pas, essayez d’en écrire quelques-uns si c’est possible. Il se peut que le système legacy soit un exécutable monobloc sans découpage en composants, dans ce cas, cela doit apparaître en gros sur votre rapport d’analyse : le programme n’est pas découpé en bibliothèques de composants et l’on ne peut pas le tester avec des tests unitaires, ce qui est contraire aux normes actuelles de qualité du logiciel (DO-178, IEC 61508, IEC 62304, ISO 26262, EN 50128).

4.3 Analyses approfondies et rapports

À présent, il est temps de sortir l’artillerie lourde. Un système legacy, pour s’en défaire, il faut être très convaincant, parce que tous les proverbes de papy pour le garder encore quelques années vont refaire surface. Les fameux « ça fait quarante ans que ça marche, on ne voit pas pourquoi il faudrait le changer » ou les « c’est notre bébé, on peut encore le sauver, pensez à ceux qui ont travaillé dessus, c’est une valeur sentimentale», ou même « vous vous faites des idées, rien n’est parfait en informatique, vous voyez des bugs qui n’existent pas ». Vous aurez droit à tout, soyez prêt. Pour contrer toutes ces inepties, il n’y a rien de mieux qu’un rapport implacable, avec des faits, des diagrammes, des résultats d’analyse et de tests, sans fioritures. Soyez le plus exhaustif possible :

• résultats d’analyse des flux, pointez les problèmes d’optimisation, de technologies obsolètes, de sécurité ;
• résultats d’analyses de tests statiques, utilisez les analyseurs de codes du marché pour vous aider, comme CppDepend, SonarQube, Squore, Kiuwan et autres [18]. Indiquez les métriques obtenues et leurs significations (voir plus loin) ;
• résultats d’analyse de tests dynamiques, qui ont lieu durant le runtime du programme. Vérification de fuites de mémoire, d’erreurs de mémoire, de charge CPU, etc. ;
• résultats des tests ou de leurs absences (ce qui est tout aussi grave que des tests en erreur), du manque de couverture de code, de clarté, de conception, de documentation ;
• estimez la charge, la dette technique (technical dept) que ça prendrait de corriger tous les bugs et problèmes d’un tel système (certains outils comme les analyseurs de code cités précédemment vous le calculent, et c’est souvent en années) ;
• expliquez clairement les problèmes et les risques que ça pose de maintenir un tel système aujourd’hui (cf. paragraphes précédents et autres articles à propos des systèmes legacy). Aidez-vous des conseils des équipes de sécurité informatique de l’entreprise et d’autres personnes qualifiées ;
• vérifiez s’il n’y a pas d’autres solutions aujourd’hui proposé sur le marché, et par des entreprises renommées. Faites quelques propositions, sachant qu’une nouvelle solution doit d’abord être testée et évaluée (soyez bref, ce n’est pas le sujet de votre rapport) ;
• concluez comme il se doit, il faut que la conclusion pointe bien les problèmes que pose le système legacy, qu’il n’est plus maintenable, hors normes, bourré de bugs et de failles de sécurité, et qu’il est temps de le remplacer ;
• ajoutez-y quelques diagrammes explicites, quelques bugs historiques, une ou deux citations de rescapés, et ça devrait faire un bon rapport. Il doit faire au moins 50 pages.

Montrez ce rapport d’abord à votre supérieur direct et à vos proches collègues, pour avoir un premier retour. Organisez une petite réunion à ce sujet. S’ils ne sont pas intéressés, essayez de le montrer à quelqu’un de plus sensible à cette question, mais ne l’envoyez surtout pas à toute la boîte, ce serait très mal perçu et repris contre vous. Enregistrez-le dans la base des documents. Si votre rapport débouche sur des réunions techniques, une prise de conscience, et même un projet de remplacement, c’est gagné. Sinon au pire, il pourra toujours servir pour un autre développeur, ultérieurement.

Une erreur serait d’essayer de refaire un nouveau développement ou de tenter de maintenir ce système, surtout si l’entreprise n’est pas une entreprise de développement informatique. C’est parce que l’on pensait pouvoir réaliser n’importe quel logiciel, avec un ou deux développeurs ou passionnés, à une certaine époque, que nombre d’entreprises se retrouvent avec ces objets volants non identifiés, ces volatiles archaïques, encore sur les bras. La seule option valable et raisonnable, c’est de les décommissionner et de les remplacer par des logiciels réalisés et maintenus par des entreprises informatiques reconnues (et de ne pas les customiser par la suite).

4.4 À propos des métriques

Les métriques sont des indicateurs de qualité du logiciel. Il en existe un grand nombre, mais on retrouve souvent les mêmes, calculés par la plupart des analyseurs de code :

• la dette technique (Technical Dept), probablement l’indicateur le plus important pour les systèmes legacy. C’est le coût en développement pour mettre le code à jour et réduire le nombre de bugs. Généralement, plus les logiciels sont anciens, plus leur dette technique est élevée [19] ;
• la complexité cyclomatique (CC), qui représente le nombre de chemins à parcourir dans une fonction, ou une méthode. Plus ce nombre est élevé, plus le risque d’erreur est grand, et la maintenance difficile (difficulté de couvrir tous les tests notamment), ce qui reflète aussi une piètre optimisation. Pour un CC de 40, le risque d’erreur est de 50 % et passé 70, ce risque est de plus de 90 % [20].
• les métriques d’Halstead (Halstead complexity), qui se basent sur le nombre d’opérateurs, que l’on peut retrouver dans le calcul de maintenabilité ;
• la profondeur d’héritage, ou Depth of Inheritance Tree (DIT), surtout en programmation orientée objet, c’est le nombre de classes qui héritent les unes des autres, en cascade. Plus ce nombre est élevé, plus il sera difficile de modifier une classe sans casser le programme. Cela indique le manque de fluidité, de modularité et de souplesse de la conception, ainsi que la difficulté à maintenir et à faire évoluer le code ;
• les lignes de codes (LOC) indiquent le nombre de lignes à exécuter pour chaque fonction et méthode. En principe, une fonction ou une méthode ne doit pas dépasser cent lignes de code (RSPEC-138) ;
• les lignes de commentaires (ou lignes de commentaires par lignes de code) indiquent le nombre de commentaires par méthodes, par fonctions, par classes, voire par fichiers. En principe, chaque méthode, chaque classe, chaque fonction doivent avoir un en-tête commenté avec la signification des paramètres et des valeurs retournées. C’est utile pour les développeurs, pour les testeurs, et pour la génération de la documentation. Les fichiers doivent également avoir un en-tête indiquant leurs fonctionnalités, les auteurs et les révisions ;
• la couverture de code (code coverage), si c’est en place, indique le taux de lignes de code testées, couvert par les tests unitaires. Plus ce taux est élevé, plus on a des chances d’avoir un code fiable et avec peu de bugs. Cela oblige aussi à tester les nouveautés et les modifications. C’est surtout important pour les projets critiques. Certaines normes obligent une couverture de code de 80 %, 90 %, voire 100 % (DO‑178B) ;
• le nombre de paramètres par fonction, ou par méthode (Too Many Parameters code smell). Cela fait partie des règles de codages (coding conventions) : une fonction ou une méthode ne doit pas avoir plus de sept, cinq, voire quatre paramètres, sinon cela devient difficile à tester, à comprendre et ça peut sûrement être refactorisé et optimisé (RSPEC-107). Il existe un grand nombre d’autres règles de codage que l’on ne va pas lister ici, mais qui sont vérifiées par les analyseurs de codes.

Conclusion

Face à un système legacy vieux de plusieurs décennies, il n’y a pas trente-six solutions, il faut le décommissionner. Pour cela, il faudra réaliser des analyses poussées et rédiger des rapports clairs, précis et convaincants pour les décideurs. Un logiciel, comme tout produit, possède un cycle de vie d’une durée de quelques années, voire de quelques mois (cf. LTS, Long-term support, et STS, Short-term support). Passé ce délai, il devient obsolète et dangereux pour la sécurité de l’entreprise : il devient un système legacy.

Références

[1] Wikipédia, « Legacy System » : https://en.wikipedia.org/wiki/Legacy_system

[2] Wikipédia, « IBM 704 » : https://fr.wikipedia.org/wiki/IBM_704

[3] Wikipédia, « ARM Cortex-A75 » : https://en.wikipedia.org/wiki/ARM_Cortex-A75

[4] EMSI, « L’évolution des performances Réseau » :
http://www.emsi-histoireinformatique.fr/levolution-des-performances-reseau

[5] Wikipédia, « Jeu d'instructions AES » : https://fr.wikipedia.org/wiki/Jeu_d%27instructions_AES

[6] We are social, « Digital in 2020 » : https://wearesocial.com/digital-2020

[7] PurpleSec, « The ultimate list of cyber security statistics for 2019 » :
https://purplesec.us/resources/cyber-security-statistics

[8] Cisco, « Rapport annuel 2018 sur la cybersécurité » :
https://www.cisco.com/c/fr_ca/products/security/security-reports.html#~about-the-series

[9] WATTS S. et RAZA M., « Saas vs PaaS, vs IaaS » :
https://www.bmc.com/blogs/saas-vs-paas-vs-iaas-whats-the-difference-and-how-to-choose

[10] Wikipédia, « Vol 501 d'Ariane 5 » : https://fr.wikipedia.org/wiki/Vol_501_d%27Ariane_5

[11] Wikipédia, « Comair » : https://en.wikipedia.org/wiki/Comair

[12] Wikipédia, « Year 2000 problem » : https://en.wikipedia.org/wiki/Year_2000_problem

[13] Wikipédia, « MF Global » : https://en.wikipedia.org/wiki/MF_Global

[14] Reuters, « RBS admits decades of IT neglect... » :
https://uk.reuters.com/article/uk-rbs-technology/rbs-admits-decades-of-it-neglect-after-systems-crash-idUKBRE9B10YB20131203

[15] Evening Post, « 35-year old computer system blamed for Leeds hospital delays and cancellations » :
https://www.yorkshireeveningpost.co.uk/news/35-year-old-computer-system-blamed-leeds-hospital-delays-and-cancellations-606209

[16] Wikipédia, « WannaCry ransomeware attack » : https://en.wikipedia.org/wiki/WannaCry_ransomware_attack

[17] GCN, « Massive job losses crash state legacy unemployment insurance systems » :
https://gcn.com/articles/2020/04/06/legacy-ui-systems.aspx

[18] Wikipédia, « List of tools for static code analysis » :
https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

[19] Wikipédia, « Dette technique » : https://fr.wikipedia.org/wiki/Dette_technique

[20] INFOQ, « Cyclomatic Complexity Revisited » : https://www.infoq.com/news/2008/03/cyclomaticcomplexity/

Pour aller plus loin

Quelques recommandations et procédures à suivre face aux systèmes legacy :

• Cybersecurity & Infrastructure Security Agency, « Assessing Security Risk In Legacy Systems » :
  https://us-cert.cisa.gov/bsi/articles/best-practices/legacy-systems/assessing-security-risk-in-legacy-systems
• National Cyber Security Center, « Obsolete products » :
  https://www.ncsc.gov.uk/collection/mobile-device-guidance/managing-the-risks-from-obsolete-products
• Impact, « Legacy Systems In Digital Transformation: Risks and Challenges » :
  https://www.impactmybiz.com/blog/blog-legacy-systems-digital-transformation-risks-challenges/
• Cloud Tech, « The hidden dangers of legacy technology… » :
  https://cloudcomputing-news.net/news/2016/oct/10/hidden-dangers-legacy-technology-and-how-resolve-them/
• Nexus Software Systems, « Legacy Software Problems and How to Fix Them » :
  https://nexwebsites.com/blog/legacy_software_problems_and_how_to_fix_them/