Le logiciel est un produit périssable

Lorsqu'on lance en production une nouvelle application ou un nouveau site web pour un client  après une phase de réalisation plus ou moins douloureuse (le développement n'est pas un long fleuve tranquille…), c'est souvent le bonheur. Tout le monde est content. Tout le monde se congratule, et ça semble être la fin d'une belle histoire.

Sauf que le client ignore (ou oubli) souvent que le logiciel est une denrée périssable.
Même si on n'en connait pas toujours sa date limite de consommation, il finira irrémédiablement par être périmé est devenir inutilisable même s'il répond à un besoin qui, lui, continue à exister.

Pourquoi tant de haine ?

En effet, même si le logiciel a été écrit sans le moindre bug ou vice caché qui pourrait apparaître dans des cas d'usages particuliers, il vit dans un monde technologique qui évolue rapidement.

Les systèmes d'exploitations changent, Windows comme MacOS ont par exemple arrêté (ou limité) récemment le support des applications 32 bits ce qui a rendu obsolètes de nombreux logiciels/outils que vous aviez peut-être l'habitude d'utiliser.

Pour des raisons de sécurité, Apple et Google limitent à chaque version d'iOS et d'Android les possibilités des API système par exemple celles qui touchent aux périphériques ou permettent des requêtes distantes. De ce fait, les applications mobiles peuvent à un moment donné devenir incompatibles avec les dernières versions d'iOS ou d'Android parce qu'elles utilisent une API devenue restreinte.

Un site web s'appuyant sur des API externes peut soudainement s'arrêter de fonctionner car celles-ci ont évoluées. Combien de fois Twitter ou Facebook ont fait évoluer leurs APIs rendant caduques des outils ou sites s'appuyant sur celles-ci ?

Les normes évoluent également, les navigateurs peuvent par exemple arrêter le support de certaines fonctionnalités qui ont été déclarées obsolètes car remplacées par d'autres fonctionnalités. Cela peut provoquer des dysfonctionnement sur certains sites. L'arrêt récent de la technologie Flash en est un bon exemple.

C'est l'horreur pour tout le monde

Pour les développeurs, le casse tête est terrible: une application se construit en combinant de multiples librairies, frameworks et API qui évoluent différemment. Pour corriger un bug, ils peuvent avoir à mettre à jour une librairie qui va devenir incompatible avec une autre librairie utilisée ailleurs. Changer à un seul endroit peut déclencher un réaction en chaîne qui nécessite un (gros) travail de mise à jour de toute l'application. Et je ne parle pas d'un changement d'une version de framework (type Angular) qui peut parfois nécessiter un véritable travail de réécriture.

(Crédit: Stocklib)

Pour le client, ces obsolescences et les impacts qu'elles ont sur le coût de mise à jour des applications sont d'autant plus préjudiciables que, du point de vue de l'utilisateur, elles se font souvent sans gain notable. Il est nécessaire de modifier des applications sans avoir aucune nouvelle fonctionnalité dans la nouvelle version. Qui est prêt à payer pour avoir ce qu'il a déjà ?

Pour les directions informatiques c'est aussi un casse tête. Il faut essayer de maintenir des applications sur des systèmes obsolètes, utilisant des applications obsolètes tout en garantissant la solidité du SI (notamment en terme de sécurité) et en préparant l'évolution des applications. Pensez au temps qu'il a fallu pour se débarrasser d'Internet Explorer ou de Windows XP tout simplement parce ces outils étaient indispensables au fonctionnement de certaines applications !

Que faire ?

La première chose est déjà de prendre conscience que logiciel est périssable et de savoir qu'il y a nécessairement à intervalle régulier une charge de maintenance à prévoir pour les applications, même sans faire évoluer le fonctionnel.

Il faut aussi choisir avec soin les composants utilisés pour lancer le développement d'une application. Démarrer un nouveau développement avec une technologie qui vient de sortir peut être risqué tant qu'elle n'est pas stabilisée mais de la même manière utiliser une technologie éprouvée mais en fin de vie peut présenter un vrai risque.  C'était par exemple l'une des réflexions de l'article "Quelle technologie pour développer son app mobile ?"

On peut aussi limiter l'impact de l'obsolescence, en s'appuyant sur des frameworks ou des systèmes ayant un support garanti pendant plusieurs années. Ubuntu par exemple sort une version de son système tous les 6 mois mais une version LTS (Long Time Support) seulement tous les 2 ans mais dont il garanti le support pendant 5 ans.

Le numérique est porté par l'innovation. Même sans parler d'obsolescence programmée par des concepteurs malveillants, on ne peut ralentir cette marche en avant perpétuelle qui va rendre obsolètes vos applications tôt ou tard. L'important est de le savoir et de l'anticiper.

Et vous, avez-vous déjà dépassé la date de péremption de vos applications ?

(Crédit image d'entête: Stocklib)