Logiciel pourri

La pourriture du logiciel ( pourriture des bits , pourriture du code , érosion du logiciel , dégradation du logiciel ou entropie du logiciel ) est la dégradation, la détérioration ou la perte d'utilisation ou de performance du logiciel au fil du temps.

Du point de vue de l'expérience utilisateur du logiciel, il s'agit d'une évolution de l'environnement d'exploitation, y compris du matériel. La première cause de perte objective de l'utilisation pratique du logiciel est la perte du système hôte en tant qu'environnement d'exploitation pratique.

Le Jargon File , un recueil de connaissances sur les hackers, définit la « pourriture des bits » comme une explication plaisante de la dégradation d'un logiciel au fil du temps, même si « rien n'a changé » ; l'idée derrière cela est presque comme si les bits qui composent le programme étaient soumis à une désintégration radioactive.

Plusieurs facteurs sont responsables de la dégradation d’un logiciel, notamment les changements dans l’environnement dans lequel il fonctionne, la dégradation de la compatibilité entre les parties du logiciel lui-même et l’apparition de bogues dans du code inutilisé ou rarement utilisé.

Lorsque des changements surviennent dans l'environnement du programme, en particulier des changements que le concepteur du programme n'avait pas anticipés, le logiciel peut ne plus fonctionner comme prévu à l'origine. Par exemple, de nombreux concepteurs de jeux informatiques des débuts utilisaient la vitesse d'horloge du processeur comme minuterie dans leurs jeux. Cependant, les horloges des processeurs plus récentes étaient plus rapides, de sorte que la vitesse de jeu augmentait en conséquence, rendant les jeux moins utilisables au fil du temps.

Les changements dans l'environnement ne sont pas liés au concepteur du programme, mais à ses utilisateurs. Au départ, un utilisateur pouvait mettre le système en état de marche et le faire fonctionner sans problème pendant un certain temps. Mais, lorsque le système cesse de fonctionner correctement ou que les utilisateurs veulent accéder aux contrôles de configuration, ils ne peuvent pas répéter cette étape initiale en raison du contexte différent et de l'indisponibilité des informations (mot de passe perdu, instructions manquantes ou simplement interface utilisateur difficile à gérer qui a d'abord été configurée par essais et erreurs). L'architecte de l'information Jonas Söderström a appelé ce concept onceability et le définit comme « la qualité d'un système technique qui empêche un utilisateur de restaurer le système, une fois qu'il est tombé en panne ».

Les portions de code rarement utilisées, telles que les filtres de documents ou les interfaces conçues pour être utilisées par d'autres programmes, peuvent contenir des bogues qui passent inaperçus. Avec l'évolution des besoins des utilisateurs et d'autres facteurs externes, ce code peut être exécuté ultérieurement, exposant ainsi les bogues et rendant le logiciel moins fonctionnel.

La maintenance normale des logiciels et des systèmes peut également entraîner leur dégradation. En particulier, lorsqu'un programme contient plusieurs parties qui fonctionnent indépendamment les unes des autres, il faut négliger de prendre en compte les modifications apportées à l'une des parties et qui peuvent affecter les autres.

Dans certains cas, cela peut prendre la forme de bibliothèques utilisées par le logiciel qui sont modifiées d'une manière qui affecte négativement le logiciel. Si l'ancienne version d'une bibliothèque qui fonctionnait auparavant avec le logiciel ne peut plus être utilisée en raison de conflits avec d'autres logiciels ou de failles de sécurité trouvées dans l'ancienne version, il se peut qu'il n'existe plus de version viable d'une bibliothèque nécessaire au programme.

Les logiciels commerciaux modernes se connectent souvent à un serveur en ligne pour vérifier la licence et accéder aux informations. Si le service en ligne qui alimente le logiciel est arrêté, il peut cesser de fonctionner.

Depuis la fin des années 2010, la plupart des sites Web utilisent des connexions HTTPS sécurisées . Cependant, cela nécessite des clés de chiffrement appelées certificats racines qui ont des dates d'expiration. Une fois les certificats expirés, l'appareil perd la connectivité à la plupart des sites Web, à moins que les clés ne soient continuellement mises à jour.

Un autre problème est qu'en mars 2021, les anciennes normes de chiffrement TLS 1.0 et TLS 1.1 ont été abandonnées . Cela signifie que les systèmes d'exploitation, les navigateurs et autres logiciels en ligne qui ne prennent pas en charge au moins TLS 1.2 ne peuvent pas se connecter à la plupart des sites Web, même pour télécharger des correctifs ou mettre à jour le navigateur, si ceux-ci sont disponibles. C'est ce que l'on appelle parfois « l'apocalypse TLS ».

Les produits qui ne peuvent pas se connecter à la plupart des sites Web incluent les PowerMac, les anciens systèmes Unix et les versions de Microsoft Windows antérieures à Server 2008/Windows 7 (du moins sans l'utilisation d'un navigateur tiers). Le navigateur Internet Explorer 8 dans Server 2008/Windows 7 prend en charge TLS 1.2, mais il est désactivé par défaut.

La pourriture logicielle est généralement classée comme étant soit « pourriture dormante » soit « pourriture active ».

Les logiciels qui ne sont pas utilisés à ce moment-là deviennent progressivement inutilisables à mesure que le reste de l'application évolue. Les changements dans les besoins des utilisateurs et dans l'environnement logiciel contribuent également à cette détérioration.

Les logiciels qui sont continuellement modifiés peuvent perdre leur intégrité au fil du temps si les processus d'atténuation appropriés ne sont pas appliqués de manière cohérente. Cependant, de nombreux logiciels nécessitent des modifications continues pour répondre aux nouvelles exigences et corriger les bogues, et il est rarement pratique de les réorganiser à chaque fois qu'une modification est apportée. Cela crée ce qui est essentiellement un processus d'évolution pour le programme, l'amenant à s'éloigner de la conception technique d'origine. En conséquence de cela et d'un environnement changeant, les hypothèses formulées par les concepteurs d'origine peuvent être invalidées, introduisant ainsi des bogues.

En pratique, l'ajout de nouvelles fonctionnalités peut être prioritaire sur la mise à jour de la documentation . Sans documentation, il est toutefois possible de perdre des connaissances spécifiques relatives à certaines parties du programme. Dans une certaine mesure, ce problème peut être atténué en suivant les meilleures pratiques actuelles en matière de conventions de codage .

Le déclin des logiciels actifs ralentit une fois qu'une application approche de la fin de sa vie commerciale et que le développement cesse. Les utilisateurs apprennent souvent à contourner les bugs logiciels restants et le comportement du logiciel devient cohérent car rien ne change.

De nombreux programmes fondateurs des débuts de la recherche en IA ont souffert d’une dégradation logicielle irréparable. Par exemple, le programme SHRDLU original (un programme de compréhension du langage naturel) ne peut pas être exécuté sur un ordinateur ou un simulateur informatique moderne, car il a été développé à une époque où LISP et PLANNER étaient encore en phase de développement et utilise donc des macros et des bibliothèques logicielles non standard qui n’existent plus aujourd’hui.

Supposons qu'un administrateur crée un forum à l'aide d'un logiciel de forum open source , puis le modifie considérablement en ajoutant de nouvelles fonctionnalités et options. Ce processus nécessite des modifications importantes du code existant et des écarts par rapport aux fonctionnalités d'origine de ce logiciel.

À partir de là, il existe plusieurs façons dont la pourriture du logiciel peut affecter le système :

• L'administrateur peut accidentellement effectuer des modifications qui entrent en conflit avec les autres ou avec le logiciel d'origine, ce qui entraîne un comportement inattendu du forum ou son arrêt complet. Cela le place dans une très mauvaise position : comme il s'est tellement éloigné du code d'origine, il lui sera difficile d'obtenir un support technique et une assistance pour relancer le forum.
• Une faille de sécurité peut être découverte dans le code source d'origine du forum, ce qui nécessite un correctif de sécurité. Cependant, comme l'administrateur a modifié le code de manière très importante, le correctif peut ne pas être directement applicable à son code, ce qui oblige l'administrateur à réécrire la mise à jour.
• L'administrateur qui a effectué les modifications pourrait quitter son poste, laissant le nouvel administrateur avec un forum alambiqué et fortement modifié, sans documentation complète. Sans une compréhension complète des modifications, il est difficile pour le nouvel administrateur d'effectuer des changements sans introduire des conflits et des bugs. De plus, la documentation du système d'origine peut ne plus être disponible, ou pire encore, être trompeuse en raison de différences subtiles dans les exigences fonctionnelles.

Supposons qu'un webmaster installe la dernière version de MediaWiki , le logiciel qui fait fonctionner les wikis tels que Wikipédia, puis n'applique jamais aucune mise à jour. Au fil du temps, l'hébergeur Web est susceptible de mettre à jour ses versions du langage de programmation (comme PHP ) et de la base de données (comme MariaDB ) sans consulter le webmaster. Après un certain temps, cela finira par casser les sites Web complexes qui n'ont pas été mis à jour, car les dernières versions de PHP et MariaDB auront des modifications radicales car elles rendent obsolètes certaines fonctions intégrées , ce qui interrompt la compatibilité ascendante et provoque des erreurs fatales . D'autres problèmes peuvent survenir avec un logiciel de site Web non mis à jour, notamment les vulnérabilités de sécurité et le spam .

Le refactoring est un moyen de résoudre le problème de la pourriture des logiciels. Il est décrit comme le processus de réécriture du code existant pour améliorer sa structure sans affecter son comportement externe. Cela comprend la suppression du code mort et la réécriture des sections qui ont été largement modifiées et qui ne fonctionnent plus efficacement. Il faut veiller à ne pas modifier le comportement externe du logiciel, car cela pourrait introduire des incompatibilités et contribuer ainsi à la pourriture du logiciel. Certains principes de conception à prendre en compte en matière de refactoring sont le maintien de la structure hiérarchique du code et la mise en œuvre de l'abstraction pour simplifier et généraliser les structures de code.