Patch management : pourquoi les entreprises françaises laissent leurs failles ouvertes trop longtemps

Patch management : pourquoi les entreprises françaises laissent leurs failles ouvertes trop longtemps

Une faille critique identifiée un lundi matin. Un patch disponible le mardi. Et pourtant, trois semaines plus tard, des milliers de systèmes tournent encore avec la vulnérabilité ouverte. Ce scénario, tout DSI qui se respecte connaît. Ce qui est plus difficile à admettre, c'est qu'il concerne encore aujourd'hui la grande majorité des entreprises françaises — y compris celles qui pensaient avoir réglé le problème.

Le chiffre qui dérange

Selon les données remontées par l'ANSSI et consolidées dans plusieurs rapports sectoriels ces derniers mois, plus des trois quarts des organisations françaises dépassent les délais recommandés pour corriger des vulnérabilités classifiées comme critiques. Ce n'est pas un chiffre sorti d'un livre blanc commercial : il ressort d'audits réels, d'incidents analysés après coup, et de constats terrain qui reviennent de manière récurrente dans les bilans de cybersécurité publiés depuis 2024.

La norme implicite dans le secteur — corroborer par les recommandations du NIST et de l'ANSSI — est d'appliquer un patch critique sous 72 heures, voire 24 heures pour les vulnérabilités activement exploitées dans la nature. La réalité opérationnelle, elle, ressemble davantage à des cycles de deux à quatre semaines, quand ce n'est pas plusieurs mois pour les systèmes legacy ou les environnements industriels.

Pourquoi un tel écart ? Ce n'est pas de la négligence. C'est de la complexité.

Ce qui se passe vraiment dans les DSI

Quand on parle de patch management avec des responsables IT de PME ou d'ETI — pas les grandes entreprises qui ont des équipes dédiées, mais ceux qui gèrent 200 à 2 000 postes avec des équipes réduites — le tableau est souvent le même.

Premièrement, la volumétrie est devenue ingérable manuellement. Un environnement Windows standard reçoit des dizaines de correctifs chaque mois, auxquels s'ajoutent les mises à jour des applications tierces, des équipements réseau, des solutions de sécurité elles-mêmes. Patch Tuesday est devenu une journée redoutée autant qu'attendue.

Deuxièmement, le risque de régression freine tout. Personne n'a oublié le chaos provoqué par certaines mises à jour Windows qui ont cassé des environnements de production. Pour un DSI d'ETI qui n'a pas de plan de rollback testé, appliquer un patch critique sur un ERP en production le vendredi soir, c'est jouer à la roulette russe. Alors on attend le week-end suivant. Puis celui d'après.

Troisièmement, la visibilité est partielle. Savoir exactement quels actifs sont exposés à quelle vulnérabilité suppose un inventaire précis et à jour. Or, dans beaucoup d'organisations, cet inventaire est incomplet, obsolète, ou réparti entre plusieurs outils qui ne se parlent pas.

Le résultat : on patch ce qu'on voit, quand on peut, en espérant que les actifs oubliés ne soient pas dans le viseur d'un attaquant.

2026 : le contexte a changé, les conséquences aussi

Ce qui était un risque gérable il y a cinq ans est devenu une exposition sérieuse. Plusieurs évolutions convergent pour rendre le statu quo intenable.

La directive NIS2, dont la transposition française est en cours d'application concrète depuis 2025, impose des obligations de gestion des vulnérabilités aux entités essentielles et importantes. Ne pas être en mesure de démontrer un processus de patch management structuré n'est plus seulement un risque opérationnel — c'est potentiellement une non-conformité exposant à des sanctions. Les premières mises en demeure commencent à tomber en Europe, et les autorités nationales, dont l'ANSSI en France, affûtent leurs capacités de contrôle.

Par ailleurs, les délais d'exploitation des failles se sont drastiquement réduits. Les groupes cybercriminels — et pas seulement les acteurs étatiques — disposent désormais de pipelines quasi-industriels pour développer et déployer des exploits en quelques heures après la publication d'un CVE critique. La fenêtre de tolérance qui existait autrefois n'existe plus.

Enfin, les cyberattaques ciblant les PME et ETI françaises ont connu une hausse documentée ces deux dernières années. Les attaquants ont compris que ces entreprises sont souvent moins bien protégées que les grandes, mais potentiellement aussi intéressantes — soit comme cible directe, soit comme point d'entrée vers leurs donneurs d'ordre.

La question de la souveraineté : légitime mais pas magique

Dans ce contexte, les éditeurs de solutions de patch management souverains — c'est-à-dire hébergés en France ou en Europe, soumis au droit européen, sans transfert de données vers des juridictions tierces — reviennent régulièrement dans les discussions. C'est une préoccupation légitime, mais elle mérite d'être posée correctement.

Le patch management implique, par nature, de remonter des informations sensibles : l'inventaire exact de vos actifs, les versions logicielles déployées, les vulnérabilités connues présentes sur votre réseau. Confier ces données à une plateforme SaaS domiciliée aux États-Unis ou soumise au Cloud Act, c'est potentiellement exposer une cartographie précise de vos failles à des regards extérieurs. Ce n'est pas de la paranoïa : c'est une analyse de risque légitime, surtout pour des entreprises travaillant dans des secteurs sensibles — défense, énergie, santé, infrastructures critiques.

Deux acteurs français méritent d'être mentionnés dans cette conversation. Cyberwatch, éditeur français spécialisé dans la gestion des vulnérabilités et du patch management, s'est positionné sur ce créneau avec une approche orientée conformité et souveraineté des données. Tehtris, autre éditeur français dont la plateforme XDR intègre des capacités de détection et de réponse incluant la gestion des expositions, représente une approche plus large où le patch management s'inscrit dans une stratégie de sécurité unifiée.

Mais soyons clairs : la souveraineté ne résout pas les problèmes opérationnels décrits plus haut. Un outil souverain mal intégré, avec un inventaire incomplet, sans processus de test automatisé, ne vous sauvera pas plus qu'un outil américain dans les mêmes conditions. La souveraineté est un critère de sélection parmi d'autres — pas un label qualité en soi.

Ce que les DSI peuvent faire concrètement

Sans prétendre livrer une recette universelle — chaque environnement est différent — quelques orientations ressortent des pratiques qui fonctionnent dans les organisations de taille intermédiaire.

Segmenter par criticité, pas par calendrier. Le modèle « on patch tout le premier mardi du mois » est confortable mais dangereux. Les CVE critiques avec preuve d'exploitation publique (CVSS 9+, mention dans le catalogue KEV de la CISA) doivent déclencher un processus d'urgence distinct, avec des délais et des responsables clairement identifiés. Le reste peut suivre un rythme plus régulier.

Automatiser les tests de non-régression. Le frein principal au patching rapide, c'est la peur de casser quelque chose. La réponse n'est pas d'attendre plus longtemps — c'est de se donner la capacité de tester vite. Même un environnement de staging minimal, avec les applications critiques représentées, change radicalement le rapport au patch. Ce n'est pas un investissement optionnel : c'est une condition pour que le patch management fonctionne.

Traiter l'inventaire comme un actif de sécurité à part entière. On ne peut pas patcher ce qu'on ne voit pas. Un inventaire continu des actifs — pas une spreadsheet mise à jour deux fois par an — est le fondement de tout le reste. Les solutions de découverte réseau passive existent et sont accessibles même pour des budgets contraints.

Nommer un responsable, pas une équipe. Dans les organisations où le patch management dysfonctionne, il n'y a souvent personne qui soit personnellement responsable du délai de correction d'une vulnérabilité critique. L'accountability individuelle, même sans budget supplémentaire, change les comportements.

Documenter pour vous, pas pour l'auditeur. NIS2 vous demandera de prouver votre processus. Mais la documentation utile n'est pas celle qu'on écrit pour satisfaire un auditeur — c'est celle qui permet à votre équipe de réagir à 22h un vendredi soir sans avoir à appeler tout le monde. Les deux se rejoignent si on fait les choses dans le bon ordre.

Une question de maturité, pas de budget

Il serait trop facile de conclure que le problème du patch management se résout avec plus de budget. Les organisations qui gèrent bien ce sujet ne sont pas nécessairement celles qui ont les moyens les plus importants — ce sont celles qui ont décidé d'en faire une priorité opérationnelle concrète, avec des processus, des outils adaptés à leur contexte, et une culture où corriger vite est valorisé plutôt que perçu comme un risque.

La vraie question que devrait se poser un DSI en 2026 n'est pas « quel outil de patch management acheter ? » mais « si une vulnérabilité critique est publiée demain matin, combien de temps me faut-il pour confirmer que tous mes systèmes sont protégés ? ». Si la réponse dépasse 72 heures et que vous ne savez pas précisément pourquoi, vous avez votre agenda de travail.

Le 76% de la statistique de départ n'est pas une fatalité. C'est un symptôme d'organisations qui ont laissé la complexité prendre le dessus sur la discipline opérationnelle. La bonne nouvelle : c'est un problème d'organisation avant d'être un problème technologique. Et les problèmes d'organisation, ça se résout.