L’obsolescence IT avec les mots de tous les jours

Retenons la définition suivante : est obsolescent ce qui n’est plus en mesure de rendre le service attendu, quelle qu’en soit la cause. Une voiture qui a entièrement brûlé est obsolète, tout comme un grille-pain qui a pris un court-circuit.

Il existe au moins cinq causes d’obsolescence :

• la panne non réparable ou dont les coûts de réparation sont supérieurs au coût du remplacement total. Si la Peugeot 205 de tonton s’est aplatie contre un arbre, c’est direction la casse ;
• la perte de performance de l’objet due à l’usure (par exemple un frigo qui ne fait plus assez de froid), pour autant que cela soit non réparable (cas précédent) et sans pour autant que cela soit une panne ;
• la perte de performance due à l’élévation des standards. Certes le poste de télévision à tube cathodique de mamie en noir et blanc avec trois chaînes fonctionne encore, mais qui en voudrait à la maison ?
• l’absence de pièces, que ce soient des pièces détachées ou des consommables. La magnifique imprimante laser achetée il y a quinze ans et qui fonctionne du tonnerre… Mais les cartouches d’encre ne sont plus produites par personne ;
• et dernier cas, l’impossibilité d’utiliser l’objet dans un contexte technique qui évolue en permanence. Par exemple, j’ai conservé une disquette 5p1/4 dans mon sac, je vous souhaite bon courage pour lire ce qu’il y a dessus (lecteur quasi introuvable, PC antédiluvien pour faire fonctionner le lecteur, etc.) ; c’est l’obsolescence technique à proprement parler.

Tout le monde est capable de trouver, dans sa vie courante, des exemples concernant les quatre premiers cas, le dernier est un peu plus piégeux. En effet, vous pouvez stricto sensu avoir sur une table un PC en parfait état matériel de fonctionnement (le modèle existe encore, les pièces détachées aussi, etc.) mais qui fonctionne sous Windows 8, qui lui est obsolète. W8 est obsolète car plus maintenu par l’éditeur (Microsoft), et le piège subtil c’est que pour autant les logiciels qui tournent sur ce PC peuvent parfaitement fonctionner (bureautique, navigateur Web, etc.) voire, pire, le PC en question ne montrer aucun signe d’essoufflement.

Mais cela ne va pas durer. A un moment, il va se trouver que l’antivirus (par exemple) ne sera plus maintenu par l’éditeur qui vous forcera à migrer vers la version suivante… Qui elle ne fonctionne pas sur W8, de sorte que vous allez rapidement vous retrouver avec un PC qui n’est plus protégé contre les malwares.

Fondamentalement, un PC n’est rien de plus que du matériel (cartes électroniques, mémoire, CPU, etc.) sur lequel est installé un OS : Windows, OS, Linux, etc. Sur lequel sont installés des « logiciels techniques » (middleware) : antivirus essentiellement, mais aussi client DB sur lequel sont installés des logiciels métier : bureautique, etc.

Qu’un seul de ces composant soit obsolète et c’est tout qui est obsolète. Et surtout, le changement (planifié ou forcé) d’une des couches implique souvent le changement de tout l’édifice.

La (très) mauvaise nouvelle, c’est que tout cela fonctionne comme un château de cartes. Dès qu’une des couches devient obsolète, c’est le début des ennuis. Par exemple, un PC sous W8 sur lequel fonctionne un logiciel métier lambda : vous voulez mettre à jour l’OS (passage en W11 ou ultérieur) mais il faut aussi mettre à jour l’antivirus (la version que vous avez ne tourne pas sur W11). Mais il faut aussi mettre à jour le logiciel métier (qui ne tourne que sur W8) mais vous réalisez que l’éditeur n’existe plus. Il faut donc aussi changer le logiciel métier. Ce cas est très fréquent et d’autant plus pénalisant qu’il n’a pas été anticipé.

Une des causes des incidents et attaques malwares que subissent les entreprises (et pas seulement les hôpitaux) est la présence de couches techniques notoirement trouées sur le plan de la cybersécurité car justement obsolètes, genre NETBIOS (grand classique sur les gros réseaux informatiques).

Les consultants à cravate vont vous expliquer qu’il « suffit » d’arrêter NETBIOS sur votre réseau, mais vous avez encore des vieilles applications qui utilisent ce protocole, vieilles applications dont l’éditeur a disparu depuis des lustres. Donc le changement est un projet énorme. Dans cet exemple, c’est la couche applicative qui impose ses contraintes à celle du bas (réseau) mais dans d’autres cas c’est l’inverse.

Une DSI consomme une énergie très importante de sorte que chacune de ces couches reste dans le domaine du fonctionnement « normal », c’est-à-dire en dehors de sa zone d’obsolescence. Dit autrement, l’obsolescence est un processus continu (une couche « en état de fonctionnement » à un instant t sera obsolescente quelques mois/années plus tard) très complexe à mesurer et anticiper car cela touche tous les composants du SI, qui sont tous interconnectés les uns aux autres et pour lesquels l’obsolescence d’un seul entraîne par effet domino des changements techniques en cascade, certains simples et d’autres complexes voire très coûteux.

Les autres (très) mauvaises nouvelles sont :

• le niveau d’obsolescence se pilote/mesure, et réaliser cette mesure cela consomme du temps (des journées hommes) et parfois de l’argent (des outils automatisables) pour quelque chose qui peut sembler « luxueux » dans les plans de charge (« on verra plus tard ! ») ;
• son anticipation réclame des budgets très difficiles à expliquer pour les raisons évoquées ci-dessus ;
• quand elle arrive, c’est trop tard (un peu comme dans une course de fond, si vous ne vous hydratez pas avant d’avoir soif, la sensation de soif arrive alors que vous êtes déjà en perte de performance).

Parmi les conseils de base qu’il faut retenir :

• toute DSI doit produire régulièrement (fréquence idéale semestrielle) un indicateur global d’obsolescence et un plan chiffré de mise à jour ;
• toute prise de poste d’un manager dans une DSI doit en priorité mesurer cette obsolescence qui sont autant de cadavres dans les placards (laissé par son prédécesseur, qui lui-même en a pris une partie de son prédécesseur) ;
• retarder le traitement de l’obsolescence est une des pires idées qui soit, et ne consiste qu’à déplacer la dette dans le temps, la facture finale en sera d’autant plus salée (un de mes confrères utilise l’expression « se faire rattraper par la patrouille »);
• effet « kiss cool » : un degré élevé l’obsolescence va bloquer les projets IT. Les nouveaux logiciels acquis réclament d’être installés sur des OS maintenus, donc avec des anti-malwares maintenus (moteur et signature), du matériel maintenu, etc. Ce n’est pas juste une question d’argent, un taux élevé signifie de facto le blocage de projets ;
• les contraintes réglementaires croissantes (NIS entre autres) impliquent que la mise « sous le tapis » de ce sujet va devenir, sur le plan managérial, intenable et juridiquement risqué.

Un SI n’est jamais totalement à jour (ou 0 % obsolescent). Il y a toujours une fraction des équipements (matériels ou logiciels) qui sont obsolescents et ce n’est pas une anomalie. Il n’existe à ma connaissance aucune étude fixant le niveau « idéal » à ne pas dépasser. Mais l’expérience montre qu’en dessous de 5% la DSI est plutôt à jour, et qu’au-dessus de 10 à 15% il est possible de prévoir des gros ennuis. Ces chiffres sont bien entendu généraux et varient selon que l’on parle du parc PC, du parc des serveurs, des bornes wifi, des systèmes SCADA, etc. Ce sujet réclamerait à lui seul un guide cyber dédié.

Cependant, ne pas avoir de processus formalisé de traitement de l’obsolescence et ne pas disposer de leviers auprès d’une DG pour alerter sur un niveau anormalement élevé afin de déclencher des actions (et des budgets) doit alerter absolument tous les managers. Il y a d’ailleurs fort à parier que ces indicateurs soient inclus dans les prochains plans HN/Ségur et qu’ils fassent l’objet d’un focus des commissaires aux comptes et/ou de l’Anssi.