Gestion de l’obsolescence logicielle : véritable enjeu pour la DSI et le business

Prenons par exemple les 2 cas suivants qui peuvent plus particulièrement attirer l’attention au sein d’une direction informatique :

• Cas #1 : une faille de sécurité majeure est annoncée par un éditeur sur une version spécifique d’un logiciel qu’il supporte. Il publie en parallèle un correctif.
• Cas #2 : la communauté open source en charge de la librairie X annonce la fin de support de la version majeure 3.x dans M mois.

Dans les 2 cas, une série de questions se pose ; voici les principales :

1. La gestion de ce type de problématique est-elle l’objet de processus clairement définis, partagés et connus de tous au sein de la DSI ?
2. Notre système d’information est-il impacté (a-t-on la maîtrise complète du parc informatique) ?
3. La faille (cas #1) a-t-elle pu être exploitée ?
4. Sommes-nous en capacité d’appliquer le correctif (cas #1) ou de remplacer la version en fin de support (cas #2) dans un délai compatible avec nos engagements vis-à-vis du RSSI / des métiers ?
5. Quel est l’effort associé à la gestion de ce changement ?
6. Quelles sont les conséquences de ne rien faire ?

On peut qualifier l’obsolescence logicielle comme suit; une version de logiciel est obsolète si :

• L’entité qui en gérait le développement (éditeur, communauté) n’en assure plus la maintenance (corrective / évolutive).
• Une vulnérabilité nécessite le remplacement de cette version de logiciel.
• Cette version de logiciel est incompatible avec de nouveaux systèmes / hardware ou sort des standards de l’industrie.

• Risques de sécurité : les logiciels obsolètes peuvent exposer les organisations à des vulnérabilités de sécurité, les rendant ainsi vulnérables aux attaques cyber et aux fuites de données.
• Temps d’arrêt système : les logiciels obsolètes peuvent entraîner des crashes système, résultant en une perte de productivité et de revenus.
• Dette technique : la négligence de l’obsolescence logicielle peut entraîner une dette technique, rendant difficile la maintenance et la mise à jour des systèmes.
• Contraintes d’innovation : les logiciels obsolètes peuvent limiter l’innovation, rendant difficile l’intégration de nouvelles technologies et fonctionnalités.

Comme on le voit ici, l’obsolescence logicielle est « subie » car liée à des contraintes externes. En revanche, la dette technique qui en résulte peut être « choisie ». Il faut donc traiter la question suivante : quel niveau d’obsolescence votre organisation est-elle prête à accepter et donc quel volume de dette technique est-elle prête à devoir résorber ?

Plus la dette technique croît, plus il devient complexe et coûteux de s’y attaquer.

Finalement, l’enjeu majeur est ici de maintenir au plus bas la dette technique.

Pour ce faire, les organisations doivent adopter une approche proactive pour la gestion de l’obsolescence logicielle, autour des 4 axes suivants :

1. Mettre en place un inventaire détaillé des applications logicielles et réaliser une évaluation régulière pour anticiper l’obsolescence des composants.
2. Établir une feuille de route des mises à jour logicielles et les prioriser en fonction de la criticité métier et de l’exposition aux risques. Cela signifie dans les approches de développement Agile de réserver de la capacité de l’équipe sur chaque incrément (PI, sprint) pour traiter une partie de la dette technique.
3. Standardiser les composants logiciels et les versions pour en simplifier la maintenance et le support.
4. Surveiller en permanence le statut des versions de logiciels utilisées dans les applications pour détecter les signes d’obsolescence (montée de version, vulnérabilités…).

Le principal frein à cette approche est le financement de la gestion de cette dette technique car, à première vue, cela n’a pas de valeur métier, contrairement à l’implémentation de nouvelles fonctionnalités.

Elles s’établissent sur deux niveaux : la gestion de l’obsolescence et la gestion de la dette technique :

• Établir un cadre de gouvernance pour superviser la gestion de l’obsolescence logicielle.
• Collaborer avec les parties prenantes pour s’assurer que les mises à jour logicielles sont alignées sur les objectifs commerciaux.
• Investir dans la formation et le développement pour s’assurer que les équipes IT possèdent les compétences nécessaires pour gérer l’obsolescence logicielle.
• Exploiter les outils d’automatisation et s’appuyer sur les services managés des fournisseurs cloud pour simplifier les mises à jour logicielles et réduire l’effort manuel.

• Reconnaître que la dette technique est une partie naturelle du développement logiciel et accepter que cela doit être géré dans le cadre du cycle de développement logiciel.
• Identifier régulièrement la dette technique et la prioriser en fonction de la valeur métier, du risque et de la complexité.
• Maintenir un registre de la dette technique, incluant la description, la priorité et l’effort estimé requis pour résoudre chaque élément. Par exemple sous forme de stories techniques dans un back log.
• Réduire la dette technique régulièrement dans chaque cycle de développement, plutôt que de la laisser s’accumuler. Pour ce faire, allouer un pourcentage de la capacité de réalisation des équipes à cette activité.
• Utiliser un ratio dette-capital pour mesurer la quantité de dette technique par rapport à la taille et à la complexité globales du système.
• Communiquer la dette technique et son impact aux parties prenantes, notamment aux dirigeants, aux propriétaires de produits et aux équipes de développement.
• Utiliser l’automatisation et les outils pour identifier, suivre et résoudre la dette technique, tels que les outils d’analyse de code et les pipelines d’intégration continue.

Il existe des outils et des approches qui viennent en appui de ces bonnes pratiques :

• Outils de contrôle qualité du code
• Outils d’analyse (statique) de sécurité
• Automatisation et tests
• Software Bill Of Material (SBOM)
• Services Cloud
• Intelligence artificielle

Leurs apports feront l’objet de futures publications.