964 CVEs en un seul Patch Tuesday. Microsoft a battu son propre record en septembre 2026. Et personne ne semble vraiment s'alarmer. C'est précisément ça, le problème.

L'inflation des CVEs : chronologie d'une dégradation silencieuse

En 2015, un Patch Tuesday "chargé" représentait 50 à 60 CVEs. En 2020, la moyenne mensuelle était d'environ 110 vulnérabilités. En 2023, elle avoisinait 70 — une apparente amélioration qui masquait en réalité une pause avant une reprise explosive. En 2026, nous voilà avec des mois dépassant régulièrement 400, 500, et maintenant presque 1 000 CVEs en un seul cycle.

Cette inflation n'est pas linéaire. Elle est exponentielle sur certaines périodes, avec des pics qui correspondent à des changements structurels dans l'industrie du logiciel. Permettez-moi d'identifier les quatre moteurs principaux de cette dynamique, parce que les comprendre est indispensable pour y répondre intelligemment.

Premier moteur : la complexification du logiciel. Windows 11 contient aujourd'hui environ 50 millions de lignes de code. Azure Active Directory, avec ses dépendances, c'est plusieurs fois plus. Chaque ligne de code est une opportunité de vulnérabilité potentielle. Et la surface d'attaque ne fait qu'augmenter avec chaque nouvelle fonctionnalité, chaque nouvelle API, chaque nouvelle intégration tierce. Microsoft a publié en 2025 plus de 300 nouvelles fonctionnalités dans ses produits cloud et on-premise. Ces 300 fonctionnalités sont autant de nouveaux vecteurs d'attaque potentiels — et pour chacun d'eux, personne n'a fait une revue de sécurité exhaustive avant la mise en production, parce que le rythme de déploiement ne le permet pas.

Deuxième moteur : l'industrialisation de la recherche en sécurité offensive. Les programmes de bug bounty de Microsoft ont versé plus de 60 millions de dollars en 2025. Pour les chercheurs en sécurité, trouver une vulnérabilité dans Windows ou Azure est une activité économiquement rationnelle et potentiellement très lucrative. Par ailleurs, les outils d'analyse automatisée alimentés par l'IA — fuzzing intelligent, analyse de code statique par LLM, génération automatique de PoC — ont considérablement réduit le coût de découverte d'une vulnérabilité. Ce qui prenait des semaines à un chercheur chevronné il y a cinq ans prend maintenant quelques heures à un outil automatisé correctement configuré et accessible à des prix très raisonnables en SaaS.

Troisième moteur : le code généré par l'IA. En 2026, une part significative du code produit dans les grandes entreprises technologiques est généré ou assisté par des LLMs. Or, ces modèles reproduisent les patterns vulnérables présents dans leurs données d'entraînement — et internet est saturé de code insécure. Les études publiées par Stanford et NYU entre 2024 et 2026 montrent que le code généré par des LLMs contient entre 40% et 60% de plus de vulnérabilités de sécurité que le code humain pour des tâches équivalentes, notamment des buffer overflows, des injections SQL et des gestions d'erreurs défaillantes. Cette tendance n'est pas encore pleinement reflétée dans les statistiques CVEs actuelles, mais elle le sera dans les deux à trois prochaines années, quand le code généré aujourd'hui entrera dans les phases de maintenance et d'audit.

Quatrième moteur : la régulation. NIS2, DORA, le Cyber Resilience Act européen — tous imposent aux éditeurs logiciels une obligation de divulgation et de correction des vulnérabilités dans des délais contraints. Cette pression réglementaire pousse les éditeurs à être plus exhaustifs dans leurs bulletins de sécurité, en incluant des CVEs qui auraient pu être silencieusement corrigés dans le cadre d'autres mises à jour. C'est, paradoxalement, une bonne nouvelle sur le plan de la transparence et de la responsabilisation des éditeurs, mais cela contribue mécaniquement à l'inflation des statistiques.

Le résultat net de ces quatre moteurs, c'est un Patch Tuesday qui ne ressemble plus à grand-chose de ce pour quoi il a été conçu en 2003 : une mise à jour mensuelle gérée, prévisible, applicable par une équipe IT standard en quelques jours. Aujourd'hui, un Patch Tuesday record devient un événement de crise pour les équipes sécurité sous-dimensionnées. Et les équipes sous-dimensionnées, c'est la majorité des organisations, en France comme ailleurs.

Le Patch Tuesday comme signal d'attaque pour les APT

Voici quelque chose que la plupart des guides de "bonnes pratiques" n'abordent pas franchement : le Patch Tuesday est un outil d'attaque pour les groupes APT les plus sophistiqués. Cette réalité est documentée, et elle devrait fondamentalement changer la façon dont les RSSI pensent leur processus de gestion des vulnérabilités.

Le raisonnement est simple. Quand Microsoft publie ses 964 CVEs un mardi, les détails techniques de ces vulnérabilités — ou suffisamment de détails pour les reverse-engineer depuis les patches binaires — deviennent disponibles publiquement. Les chercheurs en sécurité publient des analyses, des proof-of-concepts, des détails techniques dans les heures suivant la publication. L'accélération récente de ce phénomène est mesurée et documentée : le temps moyen entre la publication d'un CVE et la disponibilité d'un exploit fonctionnel dans la nature est passé de 15 jours en 2020 à moins de 48 heures en 2026 pour les vulnérabilités critiques avec des détails techniques publics.

De leur côté, les grandes organisations ont besoin en moyenne de 21 à 30 jours pour déployer un Patch Tuesday complet en production, en tenant compte des phases de test de régression, des fenêtres de maintenance, des contraintes opérationnelles et de la priorisation dans une file d'attente IT déjà longue. Dans les organisations avec des systèmes legacy nombreux ou des contraintes OT importantes, ce délai dépasse souvent 45 à 60 jours.

La fenêtre d'exposition est donc structurellement garantie : 48 heures pour un exploit disponible, 21 à 60 jours pour le patch déployé. Ce sont entre 19 et 58 jours d'exposition calculée, annoncée à l'avance, et parfaitement prévisible pour n'importe quel acteur qui lit le Patch Tuesday avec des lunettes offensives.

Les groupes APT comme Volt Typhoon (Chine), Fancy Bear/APT28 (Russie) ou des groupes nord-coréens comme Lazarus Group ont documentairement utilisé cette fenêtre de manière systématique. Ils disposent de ressources pour reverser les patches binaires Microsoft avant même que les premières grandes organisations aient terminé leur cycle de déploiement. La chaîne opérationnelle est rodée depuis des années : patch publié le mardi, reverse engineering le mercredi, développement d'exploit le jeudi-vendredi, exploitation des premières cibles non patchées le lundi suivant.

C'est exactement ce qu'on a observé avec les deux zero-days de septembre 2026 — CVE-2026-81963 et CVE-2026-85880 : la CISA a confirmé leur exploitation active le jour même de leur publication par Microsoft, ce qui signifie que ces failles étaient connues et weaponisées par des attaquants avant que le correctif soit publiquement disponible. Les zero-days ne tombent pas du ciel — ils sont le résultat d'une recherche offensive systématique alimentée par une économie souterraine de l'exploit très bien organisée et très rentable.

Pour un RSSI, cela signifie une chose concrète : la stratégie "je patche dans mon cycle mensuel habituel" est structurellement défaillante pour les vulnérabilités critiques avec exploitation active confirmée. Il faut des processus différenciés — des cycles d'urgence 24h, 48h, 72h selon la criticité et le contexte d'exploitation — et la capacité organisationnelle de les activer sans perturber l'ensemble des opérations IT. C'est une question de maturité des processus, pas de moyens technologiques.

La dette technique : l'ennemi invisible du patch management

Il y a une réalité que les RSSI connaissent bien mais qu'il est difficile d'énoncer clairement dans les comités de direction : une partie significative des systèmes d'information d'entreprise ne peut tout simplement pas être patchée dans des délais raisonnables. Ce n'est pas un aveu de faiblesse — c'est le résultat structurel de décennies de dette technique accumulée dans la quasi-totalité des organisations.

Les systèmes legacy constituent le premier problème. Combien d'organisations françaises font encore tourner des serveurs Windows Server 2012 hors support, des applications métier critiques écrites en Visual Basic 6, ou des bases de données Oracle 11g ? Beaucoup plus qu'elles ne l'admettent publiquement — l'enquête annuelle de Gartner sur les SI européens estimait en 2025 que plus de 35% des applications business-critical des entreprises de taille intermédiaire tournaient sur des systèmes pour lesquels les éditeurs ne publient plus de patches de sécurité. Ces systèmes ne peuvent pas recevoir les mises à jour parce que le fournisseur ne les publie plus, parce que l'application métier qui tourne dessus n'est pas compatible avec les nouvelles versions, ou parce que le coût de migration est jugé prohibitif par les décideurs financiers.

Les systèmes industriels (OT/ICS) constituent le second angle mort majeur. Un automate Siemens S7 dans une ligne de production ne se patche pas comme un serveur Windows dans un datacenter. Les contraintes de disponibilité — certaines lignes de production tournent 24h/24, 365 jours par an sans possibilité d'arrêt planifié — les certifications réglementaires des logiciels embarqués (qui se perdent à la mise à jour) et l'absence de fenêtres de maintenance acceptables rendent le patch management classique inapplicable sur une large partie du parc OT. Or, la convergence IT/OT promue par l'industrie 4.0 et l'IIoT expose ces systèmes à des vecteurs d'attaque IT classiques — une combinaison explosive dont les conséquences potentielles dépassent largement le périmètre numérique.

Les applications SaaS tiers constituent le troisième angle mort. Une organisation moyenne de 1 000 salariés utilise en 2026 entre 150 et 200 applications SaaS différentes, selon les études récentes de Gartner et Productiv. Chacune de ces applications est une surface d'attaque potentielle dont la gestion des vulnérabilités dépend entièrement du fournisseur. La récente vague de compromissions via des fournisseurs SaaS tiers — JFrog Artifactory avec CVE-2026-82329, LiteLLM, PaperCut NG/MF avec CVE-2026-82078 — démontre que la dépendance aux SaaS a déplacé le risque de vulnérabilité sans le supprimer. Elle l'a simplement rendu moins visible et moins contrôlable depuis les équipes de sécurité internes.

La dette technique n'est pas un problème technique. C'est un problème de gouvernance et d'arbitrage des risques sur le long terme. Les RSSI qui présentent leur Patch Tuesday comme "99% des patches déployés dans les délais" mesurent souvent le périmètre patché dans leur outil de patch management, pas le périmètre total réel du SI. Ce qui conduit à des tableaux de bord flatteurs qui masquent une exposition significative dans les angles morts non inventoriés.

Les faux semblants du patching rapide

La pression pour "patcher vite" peut engendrer des problèmes presque aussi graves que les vulnérabilités elles-mêmes, si elle n'est pas encadrée par des processus rigoureux. Voici quelques réalités de terrain que les vendeurs de solutions de patch management préfèrent ne pas trop souligner dans leurs argumentaires commerciaux.

La régression applicative est un risque réel et documenté. En août 2026, un patch Microsoft pour une faille Exchange a provoqué une régression sur les connecteurs tiers dans plusieurs milliers d'organisations. Certaines ont dû choisir entre maintenir la vulnérabilité ou interrompre leur flux email pendant plusieurs heures, le temps de tester et déployer le patch correctif publié 6 jours plus tard. Ce n'est pas un cas isolé : les données historiques de Microsoft indiquent que 3 à 5% des patches déployés nécessitent une version corrigée dans les 30 jours suivant leur publication initiale. Sur 964 CVEs en un mois, statistiquement, 30 à 50 patches pourraient générer des régressions à surveiller.

La fatigue des équipes IT est une conséquence directe de l'inflation des CVEs. Quand un Patch Tuesday demande 3 à 5 jours de travail intensif tous les mois — triage, test, déploiement, vérification — sur une équipe déjà sollicitée par les projets d'infrastructure, le support utilisateurs et la gestion des incidents quotidiens, la pression s'accumule inexorablement. Cette fatigue crée des raccourcis : des patches déployés sans test suffisant, des exceptions de sécurité accordées trop facilement pour éviter des conflits avec les équipes métier, des systèmes mis à jour sur des bases moins fréquentes. C'est un cercle vicieux : plus il y a de CVEs, plus les équipes sont fatiguées, moins elles patchent efficacement, plus l'exposition augmente.

L'illusion du taux de déploiement à 100% est un autre écueil structurel. Les outils de patch management ne couvrent pas l'intégralité du périmètre réel. Les postes de travail non connectés au réseau corporate lors du déploiement, les systèmes dans des zones réseau isolées, les équipements BYOD, les hyperviseurs de virtualisation gérés séparément, les containers Docker et les environnements Kubernetes — la liste des angles morts est longue et souvent sous-estimée. Les tableaux de bord qui affichent "98% des assets patchés dans les délais" mesurent 98% des assets dans le périmètre de l'outil de patch management, pas 98% des assets réels du SI.

Enfin, la résilience vs la réactivité. Un patch déployé en urgence sur un système critique sans test adéquat peut provoquer une indisponibilité de service dont le coût opérationnel dépasse celui de l'exploitation hypothétique de la vulnérabilité. Il faut donc arbitrer avec discernement : la priorité d'un patch doit être évaluée en fonction de la probabilité réelle d'exploitation dans votre contexte spécifique, pas uniquement sur la base de son score CVSS théorique. Un CVSS 9.8 sur un service interne inaccessible depuis Internet et protégé par plusieurs couches d'authentification forte est moins urgent qu'un CVSS 7.0 sur un service exposé activement scanné par des botnets dans la nature.

Ce que les RSSI doivent changer maintenant

Après ce diagnostic, voici mes recommandations concrètes issues du terrain. Pas des généralités sur "l'importance de patcher", mais des évolutions de processus qui font réellement la différence dans les organisations qui gèrent intelligemment leur exposition aux vulnérabilités.

1. Segmenter les processus de patch management par criticité. Un seul processus mensuel ne suffit plus. Il vous faut au minimum quatre tracks opérationnels distincts : (a) track d'urgence 24-48h pour les zero-days avec exploitation confirmée et systèmes exposés ; (b) track critique de 72h à 7 jours pour les CVSS >= 9.0 avec vecteur réseau non authentifié ; (c) track standard 14-21 jours pour les critiques sans exploitation active confirmée ; (d) track planifié mensuel pour les importantes et les basses sévérités. Chaque track doit avoir son propre processus de test allégé adapté à la contrainte temps, ses propres responsables et ses propres critères de dérogation documentés et approuvés.

2. Mesurer l'exposition réelle, pas les métriques de déploiement. Le KPI de votre patch management ne devrait pas être "pourcentage de patches déployés dans les délais" — c'est une métrique de processus, pas une métrique de risque. La métrique pertinente est "temps moyen d'exposition sur les CVEs CVSS >= 8.0 avec vecteur réseau sur les assets Internet-facing". C'est plus difficile à mesurer et à présenter au COMEX, mais c'est ce qui prédit réellement votre probabilité d'être compromis dans les 90 prochains jours.

3. Cartographier honnêtement les angles morts. Produire une liste exhaustive des systèmes qui ne peuvent pas être patchés selon votre cycle standard — legacy, OT, SaaS tiers non gérés, équipements spécialisés. Pour chacun, définir des compensations (segmentation réseau renforcée, monitoring comportemental accru, restrictions d'accès additionnelles) et une roadmap de remédiation à long terme avec coûts estimés. Présenter cette liste au COMEX chaque trimestre avec l'évolution du risque associé. La direction a besoin de voir cette réalité pour arbitrer les investissements en connaissance de cause.

4. Automatiser intelligemment. Les outils de patch management modernes permettent une priorisation basée sur l'exposition réelle, pas uniquement sur le CVSS théorique. Activez les fonctionnalités de scoring contextuel (Tenable.io, Qualys VMDR, Rapid7 InsightVM, Microsoft Defender Vulnerability Management), croisez avec vos données d'inventaire pour identifier les assets à forte exposition externe, et automatisez le déploiement sur les postes utilisateurs pour libérer les équipes pour les cas complexes nécessitant un jugement humain.

5. Étendre la responsabilité au-delà du périmètre traditionnel. En 2026, une part croissante de vos risques de vulnérabilités vient de composants que vous ne contrôlez pas directement — SaaS tiers, bibliothèques open source, code généré par IA, dépendances de chaîne logistique logicielle. La gestion des vulnérabilités doit s'étendre à ces périmètres : cartographie des dépendances SaaS critiques avec leurs SLA de sécurité, programme SCA (Software Composition Analysis) pour les dépendances open source dans vos pipelines de build, et revue de sécurité renforcée du code généré par IA avant mise en production.

Mon avis d'expert

964 CVEs en un mois n'est pas un accident ni une exception. C'est la nouvelle normalité d'un secteur logiciel qui a structurellement sous-investi dans la sécurité pendant des décennies, et qui commence maintenant à en payer le prix à grande échelle. Le Secure by Design promu par la CISA et la Commission européenne va dans le bon sens, mais ses effets ne se feront sentir que dans 5 à 10 ans, quand les pratiques de développement sécurisé seront suffisamment répandues pour faire une différence statistique sur le volume de CVEs. En attendant, les RSSI doivent accepter une réalité inconfortable : ils ne peuvent pas tout patcher, tout contrôler, tout sécuriser dans les délais théoriques. La stratégie doit évoluer d'un objectif impossible de risque zéro vers une gestion intelligente des priorités — patcher ce qui compte, compenser ce qui ne peut pas être patché, et être transparent avec sa direction sur ce qui reste exposé. Les organisations qui refusent cette réalité et continuent à présenter des tableaux de bord à 98% de conformité sans mesurer leur exposition réelle sont statistiquement les mêmes qui découvrent une compromission majeure six mois après qu'elle a eu lieu, avec un dwell time de plusieurs mois et des conséquences proportionnelles.

Conclusion

Le Patch Tuesday de septembre 2026 avec ses 964 CVEs est un symptôme, pas un événement. Il révèle une industrie logicielle qui a industrialisé la production de vulnérabilités aussi efficacement qu'elle a industrialisé la production de fonctionnalités, dans un contexte où la pression réglementaire et la sophistication des attaquants n'ont jamais été aussi élevées.

Les RSSI qui l'ont compris ont déjà fait évoluer leurs processus vers des modèles de gestion différenciée du risque, avec des tracks d'urgence, des métriques d'exposition réelle et une cartographie honnête de leurs angles morts. Ceux qui ne l'ont pas encore compris se retrouveront, statistiquement, du mauvais côté d'un incident dans les 24 mois qui viennent.

La bonne nouvelle ? Les outils, les méthodes et les frameworks existent pour gérer cette complexité de manière raisonnée et proportionnée. Ce n'est pas un problème insoluble — c'est un problème de maturité organisationnelle et d'investissement dans les processus de sécurité. C'est là que je passe l'essentiel de mon temps avec mes clients : pas à vendre des outils, mais à construire les processus qui permettent de les utiliser efficacement.

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

Discutons de votre contexte spécifique et de votre maturité en gestion des vulnérabilités.

Prendre contact