En ces mois d'octobre et novembre 2025, le CERT-FR a publié de nombreux avis de sécurité, signalant des vulnérabilités sur de nombreux composants logiciels utilisés dans le monde des entreprises (et au-delà).
Pêle-mêle, ces avis de sécurité pointaient des composants fondamentaux de l'infrastructure informatique des entreprises :
- Firewalls et couche réseau : Cisco, Juniper, Palo-Alto, Fortinet...
- Systèmes d'exploitation : Windows, IBM AIX, noyaux Linux de la grande famille Red Hat (RHEL, CentOS, Rocky, AlmaLinux...), de la famille Debian/Ubuntu, de SUSE...
- Moteurs de bases de données : Oracle, MySQL,...
- Navigateurs web,
- Suites bureautiques,
- Serveurs d'applications,
- Machines virtuelles Java,
- Outils collaboratifs DevOps,
- Cloud...
Pas une un catégorie de logiciels, ou presque, qui n'ait eu son lot de vulnérabilités exposées !
Pis encore, certains composants ont vu s'enchainer les avis de sécurité d'une semaine à l'autre ! À peine avait-on digéré l'avis de vulnérabilité du 10 octobre sur les différentes famille Linux qu'un autre était publié le 17, et encore un autre le 24 octobre, et un dernier pour finir le 31 !
En parallèle, les éditeurs de logiciels ou les distributeurs tels que Red Hat ne chôment pas : leurs équipent ne relâchent pas le rythme et les correctifs affluent.
Difficile pour un RSSI/CISO* (et son équipe), difficile pour une équipe d'ingénieur·es système, de savoir sur quel pied danser quand on doit gérer et veiller à la sécurité des systèmes d'information !
Faut-il systématiquement appliquer les tout derniers patchs ? Dès leur parution ? Quel que soit le rythme de publication ?
Forcément, ça pousse à la réflexion...
Et parfois, les réponses ne sont pas toujours de bonne foi !
Le mythe de la production ininterruptible
Peu d'organisations sont prêtes à couper la production de valeur de leurs applications et serveurs informatiques plusieurs fois par mois. À juste titre.
Et donc, sur un composant comme le système d'exploitation, il peut sembler difficile de suivre un rythme soutenu de mises à jour puisque chaque patch du noyau Linux réclame son reboot et donc un arrêt de production, ne serait-ce que pour quelques minutes (dans les meilleurs des cas).
Et pourtant, la production d'une plateforme informatique est toujours susceptible d'être interrompue.
La seule vraie question qui vaille est de savoir comment (et par qui) :
N'est-il pas préférable de redémarrer volontairement et sous-contrôle un serveur plutôt que de courir le risque d'un reboot impromptu et non maîtrisé, au milieu de la nuit ou d'un weekend, causé par une saturation, une défaillance ou un bug pour lequel un correctif a pourtant été publié ?
Aucun système de redondance qui porte sur un seul serveur n'est parfait au point d'assurer une continuité de service absolue.
Si la production d'une application est critique au point de devoir rester disponible continuellement, alors les impératifs de mise à jour de sécurité de chacun des composants qui concourent à cette production doivent avoir été pris en compte lors de la conception de l'architecture.
Ce genre de designs a un coût. Et un design conçu à l'économie se bâtit en fait aux dépens de la sécurité.
Un jour, mauvais, arrive le moment où ce serveur critique subit un méchant bug, une étourderie innocente mais dévastatrice, atteint la fatidique limite d'une fuite mémoire, ou bien alors est victime d'une malveillance crasse. Il est trop tard pour se morfondre et regretter de n'avoir pas trouvé le quart d'heure mensuel ou trimestriel nécessaire.
La fable de la plateforme qui n'a pas besoin de changer
Chaque ingénieur·e système, pour peu qu'elle ou il ait au moins quelques mois d'ancienneté, a croisé dans sa carrière un serveur de production qui héberge un système d'exploitation et des applications obsolètes.
Pas juste un serveur qui fait tourner un OS (operating system) sans le tout dernier patch publié. Non.
Une machine vraiment obsolète. Un de ces serveurs qui exécutent une version du système pour laquelle plus personne ne distribue de mise à jour depuis des années : une partition PowerPC qui exécute AIX 5.3† et héberge une base de données Oracle 10.2, un serveur x86 physique qui fait tourner une application Linux-Apache-MySQL-PHP sur base de RHEL 4, une application web hébergée dans un serveur Apache Tomcat sur Java 1.6 le tout hébergé sur une VM (virtual machine) RHEL 6.
... en 2025 !
Certains ont réussi à se persuader que "on ne change pas une équipe qui gagne" est une maxime qui s'applique aux applications informatiques et aux serveurs qui les hébergent.
Mais la vérité, qu'on le veuille ou non, est qu'il y a toujours quelque chose qui change : le temps passe et avec lui des changements s'opèrent inexorablement. Les disques durs se remplissent et se rapprochent du jour de leur fin de vie. Les bandes de sauvegarde se dégradent. Les appétits de performances s'aiguisent. Les usages et les règles du métier évoluent. Les fabricants de matériel arrêtent leurs gammes de produits... Les pirates améliorent leurs attaques, changent de cibles...
Chacun de ces petits changements involontaires et inexorables est un risque d'arrêt incontrôlé, parfois définitif.
En fin de compte, l'important c'est de savoir si c'est l'organisation qui anticipe, choisit et surtout maîtrise les changements ou bien elle les subit.
À torts et responsabilités partagés ?
À la fin des fins, la responsabilité du maintient à jour d'une plateforme informatique revient toujours à son propriétaire au sein des équipes métier, celui qu'on appelle l'asset owner (le propriétaire de l'actif informatique).
C'est le propriétaire métier du serveur, ou de l'application, qui connait le mieux les enjeux de disponibilité, d'intégrité et de confidentialité auxquels sont soumis ses données et ses traitement, mais aussi la règlementation et, d'une manière générale, toutes les contraintes qui pèsent sur la plateforme.
Seul le propriétaire métier connait la valeur commerciale et financière de la production informatique.
Même si la décision finale d'appliquer ou de retenir une mise à jour appartient à l'équipe métier propriétaire de l'application et/ou du serveur, les ingénieur·es systèmes et les ingénieur·es en charge des couches applicatives ont un devoir de vigilance et de conseil.
Le RSSI/CISO (et son équipe) doivent de leur côté définir les processus et le cadre afin que chacun connaisse précisément ce qui est acceptable pour l'organisation, et les obligations qui pèsent sur chacun.
Et notamment, la sensibilisation à l'évaluation des risques liés à l'obsolescence doit permettre aux propriétaires métier des plateformes et aux équipes d'ingénierie de déterminer le coût réel de la sécurité mais aussi et surtout le coût du défaut ou du manque de sécurité.
Le véritable coût de l'insécurité
Les comptables sont des gens plutôt sérieux, du moins dans leur travail.
On peut raisonnablement s'appuyer sur leur travail et sur leurs méthodes pour parvenir à évaluer non seulement ce que coûte la sécurité informatique mais aussi les coûts qui se cachent derrière l'obsolescence des matériels et des logiciels.
Quelles conséquences ?
Imaginons quelques rapides scénarios entre désagréments et petites catastrophes:
Le chant du cygne
Un disque dur d'un vieux serveur pilotant une chaine de production dans une PMI rend les armes. Le temps de retrouver un disque compatible et de restaurer le système, l'application et ses données, plusieurs jours de production sont perdus.
Cette PMI a perdu de l'argent et ses clients ont commencé à regarder de près les catalogues des concurrents.
Perte de confiance
Le portail client d'une PME (commande, livraison, facturation) tourne sur une application web en place depuis des années. Les clients de la PME renouvellent leurs postes de travail. Les clients n'arrivent plus à se connecter car le portail web de la PME n'est pas compatible avec les normes de sécurité SSL/TLS 1.2 et supérieures. La PME doit investir dans un équipement de sécurité supplémentaire.
Cette PME a perdu la confiance d'une partie de ses clients : l'obsolescence de son portail web est dévoilée et entame son image de marque.
Fuite de données des employés
Une entreprise utilise une application web pour la saisie des plannings, des demandes de congés, des heures supplémentaires, des astreintes... de ses salariés. Lors de l'envoi d'un justificatif pour une note de frais par un salarié, le document trop volumineux provoque un bug et le salarié accède pendant quelques heures à l'intégralité des données de l'application.
La direction de cette entreprise se retrouve confrontée à un mouvement social déclenché par la fuite de données personnelles de ses employés. Elle s'expose également à une amende au titre du RGPD.
Comment évaluer, comptabiliser ?
L'obsolescence des serveurs et des applications informatiques est la source potentielle de coûts supplémentaires et/ou de pertes commerciales.
Le coût de chaque risque lié à la non-application des mise-à-jour de sécurité ou lié à l'obsolescence forte des matériels/logiciels doit être évalué. Et pour cela, une bonne pratique consiste à multiplier les coûts/pertes que subirait l'organisation par la probabilité que le risque se réalise.
Par exemple:
- Chaîne de production industrielle dépendant d'un serveur obsolète :
- Probabilité de crash du disque dur du serveur pilotant la chaine : P l'année N, 100xP l'année N+2
- Coût total de l'arrêt de production de la chaîne pendant une semaine : C1
- Coût d'une diminution des commandes annuelles de 25% suite à l'arrêt de production : C2
- Coût du risque : (C1+C2)xP l'année N, (C1+C2)x100xP l'année N+2
- Mouvement social suite à une fuite de données des employés :
- Probabilité de fuite de données en raison d'un bug dans l'application RH : P,
- Coût total de la période de grève : G,
- Coût de l'amende au titre de RGPD : A,
- Coût du risque : (G+A)xP
La littérature dédiée à la gestion des risques en matière de technologies de l'information est riche de méthodologies et d'approches pour l'identification et l'évaluation rationnelle et objective de ces risques. L'ensemble de normes ISO-IEC 27000 définit notamment les standards pour un système de management de la sécurité de l'information.
Il existe plusieurs cabinets et entreprises spécialisés capables d'encadrer au mieux cette démarche et d'accompagner les organisations pour identifier chaque risque, évaluer sa probabilité et ses conséquences.
Pour les comptables, une fois les risques identifiés et caractérisés (notamment la probabilité de réalisation, les conséquences financières/commerciales), l'éthique, la raison et la prudence commandent d'immobiliser des "provisions pour risque" au passif du bilan de l'entreprise (ou de l'organisation), en France dans un compte de classe 1518 du Plan Comptable Général. Cette obligation relève de la responsabilité de la direction de l'organisation.
Pour la plupart des secteurs d'activité c'est tout simplement une obligation légale ou réglementaire.
Les montants immobilisés — d'autant plus importants que le risque est fort soit en terme de probabilité soit en terme de conséquences, voire les deux — serviront à compenser les conséquences lorsque le risque se réalise. En attendant, cet argent est indisponible pour l'organisation, elle ne peut pas l'utiliser pour investir, pour croître.
Et en fin de compte(s) ?
Il peut sembler tentant d'ignorer tous ces patchs, toutes ces mises à jour dont la publication peut parfois donner le tournis et dont le travail de mise en œuvre peut finir par évoquer le supplice de Sisyphe.
Et pourtant...
- Quel risque fait-on courir à un système d'information en retardant l'application d'un correctif de sécurité pour éviter d'enchaîner les indisponibilité de production ?
- Comment apprécier correctement ce risque particulier au regard du risque qu'un agent malveillant exploite effectivement une vulnérabilité connue de tous alors même qu'elle est corrigée (ou atténuée) par un patch publié mais en attente d'être appliqué ?
- Quels sont les véritables risques à appliquer les correctifs de sécurité ? Entre l'impact des indisponibilités à répétition et les possibles incompatibilités avec les applications hébergées sur les serveurs.
- Est-il raisonnable, et rationnel, en 2025, de garder un serveur non patché depuis des mois, voire bien plus, au motif que sa production est critique pour l'organisation ?
- Est-il acceptable, en 2025, de continuer à héberger des applications importantes ou vitales sur des machines dont le système d'exploitation est devenu obsolète depuis des années ? Un système pour lequel plus aucun support ne publie de correctifs de sécurité depuis bien longtemps, mais pour lequel les forums de hackers regorgent de récits et de tutoriels pour en exploiter les brèches...
- Est-il sensé de continuer à utiliser dans sa chaîne de valeur une application dont l'éditeur a depuis longtemps mis la clef sous la porte ? Et pour laquelle plus aucune évolution ni maintenance n'est possible.
Au final, une production vitale, critique... mérite toujours un système d'exploitation et toute une couche logicielle réellement à jour. Elle mérite une plateforme débarrassée des vulnérabilités les plus anciennes et les plus connues, et pour lesquelles les méthodes d'exploitation sont clairement expliquées depuis des mois et des années sur presque tous les forums de hackers ?
Seule une analyse critique et rationnelle des risques et des menaces qui pèsent réellement, spécifiquement, sur une organisation peut apporter des réponses rationnelles et véritablement utiles.
Mais dans tous les cas, en 2025, que l'on soit RSSI/CISO ou ingénieur·e système, ne pas se poser la question est une faute.
Et, une fois les questions posées, et les réponses propres à l'organisation apportées,
une fois que l'organisation a choisi en conscience et rationnellement, assumant clairement et sincèrement chacun des risques traités,
une fois que sont en place à la fois les processus qui permettent de surveiller ces risques et les processus qui permettent de réviser et actualiser fréquemment et régulièrement les réponses apportées,
alors l'organisation ne subit plus la multitude des rythmes de publication de mises à jour, elle les suit, elle les "monitore" mais surtout elle définit ses propres rythmes, en maîtrise.
Chez LHQG, nous sommes des TechOps spécialisés dans les écosystèmes de serveurs Linux, avec une sensibilité importante à la sécurité des systèmes d'information. Nous pouvons vous aider à sensibiliser vos équipes ainsi qu'à reprendre la maîtrise sur vos rythmes de mise à jour.
* Abréviations:
- RSSI, responsable de la sécurité des systèmes d'information,
- CISO, chief information security officer,
- RHEL, Red Hat Enterprise Linux,
† Dates de fin de vie:
- AIX 5.3, fin de vie en avril 2016,
- Oracle DB 10.2, fin de support étendu en juillet 2015,
- RHEL 4, fin de support étendu en mars 2017,
- Java 1.6, fin de support étendu juin 2017,
- RHEL 6, fin de support étendu en juin 2024.
