En bref. Un logiciel en fin de support ne reçoit plus de correctifs de sécurité. Chaque faille découverte reste exploitable indéfiniment. Trois options existent — migrer, remplacer ou isoler — et l’attentisme n’en fait pas partie.
La fin de support est une échéance connue des années à l’avance, et pourtant régulièrement subie. La raison est presque toujours la même : une application métier qui ne fonctionne que sur l’ancienne version, et dont l’éditeur n’a pas suivi.
Pourquoi c’est un risque réel
Tant qu’un logiciel est supporté, les vulnérabilités découvertes sont corrigées. Après, elles s’accumulent :
- Les vulnérabilités publiées le sont pour tous, y compris pour les attaquants, avec les preuves de concept associées.
- Les outils d’attaque automatisés intègrent rapidement ces failles ; il n’est plus nécessaire d’être ciblé pour être touché.
- Les logiciels de sécurité cessent eux aussi de supporter les systèmes obsolètes : l’antivirus finit par ne plus se mettre à jour.
- Les assureurs et donneurs d’ordre s’y intéressent : un audit de sécurité relève systématiquement ce point.
La conséquence pratique est qu’un poste obsolète devient le point d’entrée par lequel une compromission se propage au reste du réseau — c’est l’un des scénarios les plus fréquents dans les incidents que nous traitons, aux côtés de l’attaque par rançongiciel.
Les trois options
| Option | Quand la retenir | Point de vigilance |
|---|---|---|
| Migrer vers la version supportée | L’éditeur propose une version compatible | Tester les applications métier avant |
| Remplacer le logiciel | L’éditeur a disparu ou n’évolue plus | Reprise des données, formation, coût |
| Isoler et encadrer | Aucune alternative à court terme | Mesure temporaire, jamais définitive |
L’isolement, solution d’attente et non de confort
Lorsqu’une application métier impose de conserver un système obsolète, l’isolement permet de gagner du temps. Il suppose des mesures cumulatives :
- Cloisonnement réseau : la machine est placée sur un segment séparé, sans accès Internet ni accès au reste du réseau au-delà du strict nécessaire.
- Suppression de la messagerie et de la navigation sur ce poste : les deux principaux vecteurs d’infection.
- Comptes dédiés, sans droits d’administration ailleurs sur le réseau.
- Sauvegarde renforcée, avec une copie hors ligne — voir la sauvegarde immuable.
- Virtualisation de la machine, qui permet de la restaurer rapidement et de la figer — voir la virtualisation des serveurs.
- Échéance écrite : sans date de sortie, l’isolement devient définitif et le risque s’installe.
Anticiper : le tableau des échéances
La bonne pratique tient en un tableau tenu à jour, adossé à l’inventaire du parc informatique. Pour chaque système et application significative : version en place, date de fin de support annoncée, dépendance métier, option retenue et date cible. Ce tableau se relit deux fois par an et alimente directement le budget informatique.
Il permet surtout d’éviter la situation la plus coûteuse : découvrir simultanément que le système, l’application métier et le matériel arrivent tous en fin de vie la même année.
Le cas des applications métier
C’est presque toujours le point bloquant. Quatre questions à poser à l’éditeur, par écrit :
- Quelles versions de système sont officiellement supportées, et jusqu’à quand ?
- Une version compatible avec le système supporté est-elle disponible, et à quel coût ?
- Quelles sont les modalités d’export complet des données en cas de changement de solution ?
- Quel est l’engagement de l’éditeur sur les correctifs de sécurité de sa propre application ?
Une réponse évasive à la dernière question est en soi un signal : elle indique qu’il faut préparer un remplacement, même si l’application fonctionne aujourd’hui parfaitement.
Le matériel suit souvent le même chemin
Une migration de système bute fréquemment sur du matériel trop ancien pour la nouvelle version. Il est donc rationnel de synchroniser les deux calendriers — celui des versions logicielles et celui du renouvellement du parc — plutôt que de les traiter séparément. Ce point est développé dans nos articles sur le renouvellement du parc informatique et sur l’optimisation du budget informatique.
Des alertes et des recommandations sur les vulnérabilités sont publiées par l’ANSSI.
Questions fréquentes
Peut-on payer pour prolonger le support ?
Certains éditeurs proposent des programmes de support étendu, payants et à durée limitée. C’est une solution de transition acceptable, à condition d’avoir fixé la date de sortie.
Un poste obsolète mais sans accès Internet est-il sûr ?
Il est moins exposé, pas sûr. Une clé USB, un fichier partagé ou une machine voisine compromise suffisent à l’atteindre. L’isolement réduit le risque sans l’annuler.
Comment savoir si un logiciel est encore supporté ?
Les éditeurs publient un cycle de vie officiel. Pour les applications métier, la question doit être posée par écrit et la réponse conservée : elle engage.
La fin de support engage-t-elle la responsabilité de l’entreprise ?
Elle peut le faire indirectement : maintenir un système non corrigé, alors qu’il traite des données personnelles, s’accorde mal avec l’obligation de sécurité adaptée au risque.
Conclusion
La fin de support ne se gère pas dans l’urgence : elle se planifie sur un tableau à deux colonnes, version et date, relu deux fois par an. C’est l’un des rares sujets informatiques où l’anticipation coûte réellement moins cher que la réaction.
