« Il fonctionne, on n’y touche pas. » C’est souvent la logique qui s’applique à un logiciel interne développé il y a plusieurs années. Tant qu’il n’y a pas d’incident, personne ne se pose de question sur ce qui tourne dessous. Or, l’absence d’incident visible ne veut pas dire absence de risque : ce sont précisément les risques d’un vieux logiciel qui passent le plus souvent inaperçus.
Pourquoi les risques d’un vieux logiciel restent invisibles
Un logiciel que personne n’a mis à jour depuis longtemps accumule en réalité plusieurs types de vulnérabilités, souvent invisibles au quotidien :
- des composants ou librairies obsolètes, dont plus personne ne corrige les failles de sécurité découvertes depuis
- des technologies dont l’éditeur a arrêté le support (fin de vie), donc plus aucun correctif possible
- des mots de passe, connexions ou protocoles qui ne respectent plus les standards actuels
- une infrastructure d’hébergement elle-même vieillissante, parfois plus vulnérable que l’application
Par ailleurs, le risque n’est pas uniquement une intrusion spectaculaire. C’est aussi la fuite de données, l’indisponibilité prolongée en cas de panne (parce que plus personne ne sait dépanner cette techno), ou une non-conformité réglementaire qui passe inaperçue jusqu’au jour d’un contrôle. Sur ce point, les recommandations de l’ANSSI rappellent d’ailleurs qu’un système non maintenu reste l’une des premières portes d’entrée pour une attaque.
Comment évaluer le niveau de risque réel
Avant de décider quoi que ce soit, un audit permet de répondre à des questions concrètes :
- Quelles technologies l’application utilise-t-elle, et son éditeur les maintient-il encore ?
- Quelles données l’application manipule-t-elle (données personnelles, financières, sensibles) ?
- Quel est le niveau d’exposition : l’application est-elle accessible depuis internet, ou uniquement en interne ?
- Existe-t-il des failles connues sur les composants identifiés ?
Ainsi, ce diagnostic évite deux excès : ignorer un vrai risque parce que « ça n’a jamais posé problème », ou migrer dans l’urgence et à grands frais un logiciel dont le risque réel est en fait limité.
Ce qu’on peut faire une fois le risque identifié
Selon le résultat de l’audit, plusieurs options existent, et migrer tout de suite vers une techno neuve n’est pas toujours la première :
- Planifier une migration progressive, module par module, plutôt qu’une refonte complète risquée
- Corriger les vulnérabilités critiques sans toucher au reste, pour réduire le risque immédiatement
- Isoler l’application (accès restreint, séparation réseau) le temps de préparer une évolution plus large
Comment Mahé Technologies vous accompagne sur ce sujet
Chez Mahé Technologies, on commence toujours par un audit technique honnête, avant de proposer quoi que ce soit. Concrètement, notre rôle est de vous donner une vision claire du risque réel, puis de piloter la remédiation adaptée à votre budget et à votre calendrier, qu’il s’agisse de corrections ciblées ou d’une migration planifiée.
Basés dans l’océan Indien, nous mobilisons une équipe qui suit votre application dans la durée, sur une timezone compatible avec la France, sans que vous ayez à gérer cela en interne.
En résumé, un vieux logiciel ne devient pas forcément un risque. Mais il ne peut pas non plus rester invisible dans votre stratégie IT indéfiniment.
Vous voulez une évaluation claire de votre exposition ? Demandez un audit.
