Microsoft vient de publier 973 correctifs de sécurité en un seul Patch Tuesday. C'est un record absolu. C'est aussi une absurdité opérationnelle que personne ne veut nommer clairement : patcher 973 CVEs en 30 jours, sur des environnements de production hétérogènes, avec des équipes IT sous-staffées, c'est impossible. Et prétendre le contraire, c'est mentir à ses dirigeants.

Le mythe du patch complet : d'où vient cette injonction impossible ?

Depuis la directive BOD 22-01 de la CISA américaine et les obligations NIS2 en Europe, la pression réglementaire sur la gestion des correctifs s'est considérablement intensifiée. L'idée implicite véhiculée par ces textes — et répercutée par les auditeurs, les assureurs cyber et les DSI — est qu'une organisation correctement gérée devrait être capable de patcher l'ensemble de ses vulnérabilités dans les délais imposés. En théorie, c'est un objectif raisonnable. En pratique, en 2026, c'est devenu structurellement inatteignable pour la quasi-totalité des organisations.

Les chiffres sont éloquents. En 2020, Microsoft publiait en moyenne 110 CVEs par Patch Tuesday. En 2023, ce chiffre était monté à 280. En 2025, il dépassait régulièrement 600. Aujourd'hui, avec 973 CVEs en septembre 2026 dont 113 critiques, nous avons atteint un niveau où même les grandes DSI avec des équipes dédiées peinent à absorber le flux. Pour une ETI avec 2 ou 3 ingénieurs système, la question n'est plus "comment on patch tout ?" mais "comment on ne se fait pas auditer sur ce qu'on n'a pas patché ?"

L'augmentation du volume n'est pas accidentelle. Elle reflète plusieurs tendances convergentes : l'explosion de la surface logicielle (plus de dépendances, plus de composants tiers, plus de services cloud), la professionnalisation de la recherche en vulnérabilités (bug bounty massif, IA assistée à l'analyse de code), et l'intégration croissante dans les bulletins mensuels de correctifs "out-of-band" qui auraient autrefois été publiés séparément. Microsoft a aussi changé sa politique de communication : des CVEs jadis regroupées dans des correctifs cumulatifs sont maintenant individually tracked et comptabilisées, gonflant mécaniquement les statistiques.

Le résultat concret : selon une étude de Senserva publiée en août 2026, le délai médian de déploiement d'un correctif en entreprise est de 21 jours après publication — et pour les équipements réseau périphériques (routeurs, VPN, firewalls), ce délai monte à 47 jours. Dans ce contexte, la fenêtre d'exploitation est largement ouverte avant que le patch soit en place sur la majorité des systèmes.

La réalité du risque : toutes les CVEs ne se valent pas

Le premier réflexe, compréhensible mais faux, est de prioriser par score CVSS. Un CVSS 9.8, c'est critique, donc à patcher en urgence. Un CVSS 4.5, c'est moyen, donc on verra. Ce raisonnement est séduisant par sa simplicité — et dangereux dans la pratique pour deux raisons fondamentales.

Premièrement, le score CVSS mesure la sévérité potentielle d'une vulnérabilité dans des conditions idéales d'exploitation, pas la probabilité que cette vulnérabilité soit réellement exploitée dans votre contexte. Une CVE CVSS 9.8 dans un composant que personne n'utilise activement, sans PoC public et sans acteurs motivés, représente un risque réel proche de zéro à court terme. Inversement, une CVE CVSS 6.5 avec un exploit public fonctionnel, activement utilisée dans des ransomwares ciblant votre secteur, est une menace immédiate que le score seul ne permet pas d'identifier.

Deuxièmement, le score CVSS ne prend pas en compte votre contexte. Une CVE dans Exchange Server représente un risque élevé si vous opérez Exchange en auto-hébergement exposé à internet, et un risque nul si vous êtes 100 % Microsoft 365 cloud. CVE-2025-25249 dans Fortinet FortiOS, notée CVSS 7.3 seulement, est activement exploitée et déploie un RAT persistant — son EPSS est monté à 0,85 après publication du rapport SOCRadar, là où son CVSS seul n'aurait pas déclenché de réponse d'urgence dans de nombreuses organisations.

Les données empiriques le confirment. Le Qualys Threat Research Unit analyse chaque Patch Tuesday les CVEs qui se retrouvent effectivement exploitées dans les 30 jours suivant leur publication. Le résultat constant sur 2024-2026 : entre 3 % et 7 % des CVEs publiées chaque mois sont effectivement utilisées dans des attaques réelles. Autrement dit, si vous concentrez votre énergie sur les bonnes CVEs, vous couvrez l'essentiel du risque réel en ne traitant que 5 % du volume total.

KEV + EPSS : la méthode de priorisation qui change tout

Il existe deux outils publics, gratuits et maintenus, qui permettent de faire cette priorisation de manière rigoureuse et défendable devant un auditeur ou un assureur cyber. Ensemble, ils forment la méthode KEV + EPSS — et si vous ne l'utilisez pas encore, c'est votre première action après la lecture de cet article.

Le catalogue KEV de la CISA (Known Exploited Vulnerabilities) est une liste officielle des CVEs pour lesquelles la CISA a une preuve d'exploitation dans la nature. Ce n'est pas une liste théorique : chaque ajout correspond à une exploitation réelle documentée. Le catalogue est public, mis à jour en continu et disponible en JSON via l'API CISA. En septembre 2026, il contient plus de 1 200 entrées. Sur les 973 CVEs du Patch Tuesday de ce mois, une vingtaine figurent ou seront ajoutées au KEV dans les jours suivants — c'est votre liste de patch d'urgence, point final.

Le score EPSS (Exploit Prediction Scoring System), développé par Cyentia Institute et publié via le NVD et le FIRST, modélise la probabilité qu'une CVE donnée soit exploitée dans les 30 prochains jours, basée sur des dizaines de features : mentions dans des forums underground, disponibilité de PoC, comportements observés dans des honeypots, similarités avec des CVEs historiquement exploitées. Le score va de 0 à 1 — un EPSS de 0,85 signifie 85 % de probabilité d'exploitation dans le mois. Les données EPSS sont disponibles gratuitement via l'API du FIRST et sont mises à jour quotidiennement.

La méthode concrète : chaque Patch Tuesday, vous croisez automatiquement (via un script Python de 20 lignes ou un outil comme Nucleus, Kenna Security, ou Tenable.io) les CVEs publiées avec le KEV et l'EPSS. Le résultat donne trois catégories :

  • Zone rouge — patch sous 24-48h : CVE présente dans le KEV ET/OU EPSS supérieur à 0,70. Sur 973 CVEs en septembre 2026, environ 15-25 relèvent de cette catégorie. Ce sont CVE-2026-81963, CVE-2026-85880, CVE-2026-55007, CVE-2026-69465.
  • Zone orange — patch sous 7-14 jours : CVE non dans le KEV mais EPSS entre 0,30 et 0,70, ou CVSS supérieur ou égal à 9 sur un composant exposé à internet. Environ 50-80 CVEs par mois.
  • Zone verte — patch dans le cycle mensuel habituel : Tout le reste. 85 % du volume, le risque d'exploitation réelle à court terme est proche de zéro.

Cette méthode est défendable devant n'importe quel auditeur : vous pouvez documenter en 10 minutes pourquoi vous avez priorisé telle CVE et pas telle autre, avec des données publiques vérifiables. C'est infiniment plus solide qu'un tableau de suivi Excel basé sur le CVSS brut.

Le facteur contextuel : votre inventaire décide tout

La méthode KEV + EPSS est nécessaire mais non suffisante. Elle vous dit quelles CVEs sont à haut risque dans l'absolu — elle ne sait pas si vous avez le composant concerné dans votre SI. L'étape indispensable est la corrélation avec votre inventaire des actifs (CMDB, ou a minima un scan Nessus/Tenable hebdomadaire).

Exemple concret : CVE-2026-55007, RCE dans Exchange Server via e-mail Visio. CVSS 9.8, dans le KEV, EPSS 0,91. Patch ultra-prioritaire — si vous avez Exchange Server on-premises. Si vous êtes 100 % Microsoft 365 Exchange Online, cette CVE ne vous concerne pas. Sans inventaire fiable, vous allez perdre du temps à patcher des composants que vous n'avez pas, ou pire, négliger des systèmes vulnérables parce qu'ils ne figurent pas dans votre CMDB.

En pratique, j'observe trois niveaux de maturité en termes d'inventaire :

  • Niveau 1 — PME sans DSI dédiée : Inventaire absent ou Excel non maintenu. Solution : déployer un scanner léger (Nessus Essentials, OpenVAS) hebdomadairement sur le réseau interne. Imparfait, mais infiniment mieux que rien.
  • Niveau 2 — ETI avec DSI : CMDB partielle, souvent limitée aux serveurs et ignorant les équipements réseau et endpoints non-Windows. Solution : étendre la couverture scanner aux VLANs réseau et aux postes de travail, et automatiser la corrélation avec le NVD via une plateforme comme Tenable.sc ou Qualys VMDR.
  • Niveau 3 — grande organisation avec RSSI : CMDB complète mais peu couplée au processus de patch management. Solution : intégration API entre CMDB et outil de VM (Vulnerability Management) pour une corrélation automatique CVE → actif → propriétaire → ticket ITSM.

Le problème des équipements réseau : l'angle mort du patch management

Il y a un angle mort structurel dans la quasi-totalité des programmes de patch management que j'observe : les équipements réseau. Firewalls, VPN concentrators, switches managés, load balancers — ces équipements reçoivent rarement la même attention que les serveurs Windows ou Linux. Et pourtant, en 2026, ils sont devenus la surface d'attaque privilégiée des acteurs les plus sophistiqués.

Les raisons de cette négligence sont compréhensibles : mettre à jour un firewall en production nécessite une fenêtre de maintenance, implique un risque de régression de configuration, et demande des compétences spécifiques au vendor. En comparaison, déployer un patch Windows via WSUS ou Intune sur 500 postes est presque automatique. Résultat : les FortiGate, Cisco ASA, Palo Alto PA-Series et autres Juniper SRX de nombreuses organisations tournent sur des firmwares vieux de 12 à 36 mois.

L'exploitation de CVE-2025-25249 dans FortiOS via PivotC2 illustre exactement ce problème : le correctif existe depuis avril 2025, soit 17 mois. Les organisations exploitées aujourd'hui avaient donc 17 mois pour appliquer un patch critique sur leurs VPN Fortinet. Elles ne l'ont pas fait, pour des raisons opérationnelles compréhensibles mais dont les conséquences sont visibles aujourd'hui. La leçon : intégrez vos équipements réseau dans votre cycle de patch management avec la même rigueur que vos serveurs.

Ce que NIS2 et DORA changent concrètement

La directive NIS2, en vigueur dans l'UE depuis octobre 2024, et DORA pour le secteur financier depuis janvier 2025, introduisent des obligations de gestion des vulnérabilités qui changent le cadre réglementaire pour les organisations européennes.

NIS2 (article 21) impose des "mesures appropriées" de gestion des risques cyber, incluant explicitement la gestion des vulnérabilités et des correctifs. Le régulateur ne fixe pas de délais absolus contrairement à la CISA pour les agences fédérales américaines, mais exige une approche documentée et basée sur le risque. La méthode KEV + EPSS documentée et auditée constitue une base solide de conformité.

DORA (pour les entités financières) impose des délais plus stricts via les RTS sur la gestion des ICT risks : les vulnérabilités critiques doivent être corrigées dans les 72 heures après identification pour les actifs critiques, et dans les 10 jours pour les actifs non critiques. Ces délais sont cohérents avec la méthode décrite ici — à condition que l'inventaire des actifs critiques soit précis et à jour.

Le vrai changement introduit par NIS2 et DORA n'est pas les délais — c'est l'obligation de documentation. Un RSSI qui ne peut pas expliquer pourquoi il a priorisé telle CVE plutôt que telle autre s'expose à une sanction administrative. Inversement, un RSSI qui présente un tableau de bord KEV + EPSS croisé avec son inventaire, avec des justifications documentées pour chaque choix, est en excellente posture face à un régulateur ou un assureur.

Mon avis d'expert

Le plus grand problème dans la gestion des correctifs en 2026 n'est pas technique — c'est politique. La majorité des RSsI que je rencontre n'osent pas dire clairement à leur COMEX qu'il est impossible de patcher 973 CVEs par mois dans les délais théoriques. Ils absorbent la pression, bricolent des tableaux de bord rassurants, et prient pour que l'incident ne tombe pas sur une CVE non patchée. C'est une posture perdante sur tous les plans. La bonne démarche : présenter au COMEX la réalité chiffrée, proposer une méthode de priorisation explicite, et faire valider les arbitrages par la direction. Quand l'incident arrive — et il arrivera — vous pourrez démontrer que vous avez opéré selon une méthode rationnelle documentée, avec l'aval de la direction. C'est la différence entre un RSSI qui survit à un incident et celui qui en sort licencié.

Conclusion : patch less, patch better

La réponse à l'explosion du volume de CVEs n'est pas de courir plus vite — c'est de courir sur les bons rails. La méthode KEV + EPSS + inventaire contextuel permet de concentrer 80 % de l'effort de patch sur les 5 % de CVEs qui représentent 95 % du risque réel d'exploitation. C'est la définition d'une approche basée sur le risque — celle que NIS2, DORA et tous les référentiels sérieux prescrivent depuis des années.

973 CVEs ce mois-ci. Le mois prochain, peut-être 1 100. La tendance est structurelle et irréversible. Les équipes IT qui s'en sortiront ne sont pas celles qui patcheront le plus vite — ce sont celles qui auront construit un processus de priorisation rigoureux, documenté et supporté par leur direction. C'est le vrai enjeu opérationnel de la cybersécurité en 2026.

Besoin d'un regard expert sur votre sécurité ?

Discutons de votre contexte spécifique et construisons ensemble un processus de patch management adapté à vos contraintes et à votre exposition réelle.

Prendre contact