Combien de temps faut-il, en moyenne, à une entreprise pour appliquer un correctif à une vulnérabilité critique ?

L'édition 2026 du rapport Verizon DBIR mesure une médiane de 43 jours jusqu'à la remédiation complète d'une vulnérabilité du catalogue CISA des vulnérabilités activement exploitées, contre 32 jours auparavant. Seules 26 % sont entièrement corrigées, contre 38 %, et au jour 7 entre 60 % et 70 % sont encore ouvertes, quelle que soit la taille ou la maturité de l'organisation. Si chez vous cela prend moins d'un mois, vous êtes déjà au-dessus de la moyenne — ce qui dit plus sur la moyenne que sur vous.

Comment je décide quelle vulnérabilité corriger en premier quand j'en ai cinquante ?

Pas selon le score de sévérité seul, parce qu'il décrit à quel point ce serait grave si, pas à quel point c'est probable. Combinez cinq critères : la sévérité, la probabilité d'exploitation, la présence sur la liste CISA des vulnérabilités activement exploitées, l'exposition réelle du service et sa criticité pour l'activité. Le contexte qui rend la sélection possible, c'est que seuls environ 0,5 % des CVE publiés arrivent dans le catalogue KEV et qu'au plus 6 % environ sont un jour exploités — la liste de celles qui comptent est bien plus courte que la liste du scan.

Que faire si j'ai une vulnérabilité sur un serveur et que je ne peux pas appliquer le correctif maintenant ?

Assumez la fenêtre explicitement, par écrit, et mettez quelque chose à sa place jusqu'au correctif : restreignez l'accès au service concerné aux seules sources qui en ont besoin, mettez de la supervision dessus et fixez une date de retour. La différence entre une fenêtre assumée et une fenêtre oubliée, c'est que la première a un propriétaire et une date. Traitez en priorité les équipements de périmètre : dans l'enquête Sophos 2026, 21 % des causes racines se sont produites sur le pare-feu et 38 % sur des applications et systèmes exposés.

Une IA peut-elle appliquer seule des correctifs sur mon serveur de production ?

Elle peut rédiger le plan, elle ne devrait pas l'exécuter, et dans notre cas elle ne l'exécute à aucun niveau commercial. Le plan rédigé par le modèle passe par un validateur déterministe qui le refuse s'il n'est pas sûr — le modèle rédige, le validateur décide — la commande rm n'est pas dans la liste des binaires autorisés, et l'application exige deux confirmations explicites au téléphone, avec un bouton qui meurt si le plan est régénéré. Un fournisseur qui vous promet une application entièrement automatique en production vous promet en réalité un incident que vous n'avez pas autorisé.

Ce que coûte une vulnérabilité non corrigée

En 2025, le DNSC, l'autorité roumaine de cybersécurité, a informé 2 020 institutions publiques et opérateurs de services essentiels de plus de 43 000 vulnérabilités exploitables trouvées sur leur infrastructure informatique exposée publiquement, en recommandant de les corriger d'urgence. Pour la plupart de ces organisations, une vulnérabilité non corrigée n'est pas un risque inconnu. C'est une ligne dans un courriel que quelqu'un a déjà reçu, avec le produit, l'adresse et le correctif déjà disponible.

Ce qui arrive quand cette ligne reste une ligne figure dans le même rapport. Aaylex ONE SA, le groupe agroalimentaire derrière la marque CocoRico — plus de 2 000 salariés, 36 sites dans neuf départements — a été frappé par le rançongiciel Akira, avec des effets sur la comptabilité, la production, les opérations et les serveurs de fichiers ; le DNSC a récupéré ensuite plus de 66 % des données. L'accès initial s'est très probablement fait par l'exploitation de CVE-2020-3259, dans l'interface web des équipements Cisco ASA et Firepower Threat Defense. Les quatre premiers chiffres de cet identifiant sont l'année de publication.

Combien de temps dure la fenêtre et ce que coûte une vulnérabilité non corrigée

Le constat est déjà établi, et nous l'avons écrit séparément, dans l'article sur les serveurs exposés à Internet : l'édition 2026 du Verizon DBIR, construite sur plus d'un milliard d'enregistrements de détection, mesure une médiane de 43 jours jusqu'à la remédiation complète d'une vulnérabilité du catalogue CISA des vulnérabilités activement exploitées, contre 32 auparavant, et seulement 26 % entièrement corrigées, contre 38 %. Nous ne reprenons pas le constat ici. Nous faisons le calcul.

La médiane cache la partie qui compte. Les analyses sur les mêmes données montrent qu'au jour 7, entre 60 % et 70 % des vulnérabilités activement exploitées sont encore ouvertes — quelle que soit l'année, le volume ou la maturité de l'organisation ; même au sommet de leur performance, les organisations en corrigent 30-40 % la première semaine. Au jour 28, 35 % des cas étaient encore ouverts en 2025, contre 27 % en 2024. Et le volume augmente : dans le cas médian, 50 % de vulnérabilités critiques en plus que l'année précédente. L'arriéré s'accumule aussi : dans une mesure distincte, de Cyentia et Veracode, 82 % des organisations portent des vulnérabilités connues non résolues depuis plus d'un an.

La durée a un prix, et il existe un chiffre où la durée est la seule variable. L'IBM Cost of a Data Breach Report 2026 montre que les compromissions identifiées et contenues en plus de 200 jours ont coûté en moyenne 5,65 millions de dollars, contre 4,32 millions pour celles résolues plus vite — une différence d'environ 1,33 million, et l'écart entre les deux groupes s'est élargi par rapport à l'année précédente, il ne s'est pas réduit.

Les chiffres en millions sonnent comme une multinationale américaine, et à juste titre. Le plus proche d'une entreprise de taille moyenne vient de l'enquête Sophos The State of Ransomware 2026, auprès de 2 158 responsables informatiques dans 17 pays, dans des entreprises de 100 à 5 000 salariés frappées par un rançongiciel : les organisations réalisant moins de 50 millions de dollars de chiffre d'affaires ont reçu des demandes de rançon médianes d'environ 140 000 dollars, celles au-delà de 5 milliards, 5,7 millions. Les attaquants calibrent la demande sur la capacité de paiement perçue. Le coût moyen de récupération, hors rançon, s'est élevé à 1 700 200 dollars — un ordre de grandeur pour cette population, pas une facture qu'une entreprise de 60 personnes doit attendre.

Plus facile à ressentir que l'argent : la probabilité. Dans la même enquête, 41 % des attaques ont été arrêtées avant le chiffrement — mais les entreprises de 3 001 à 5 000 salariés y parviennent dans 46 % des cas, et celles de 100 à 250 salariés dans seulement 34 %. Le rapport n'explique pas ces douze points d'écart, mais ils traduisent la fenêtre d'argent en probabilité : plus quelqu'un regarde tard, plus souvent l'attaque va jusqu'au chiffrement. Et la cause racine se trouve exactement là où est la fenêtre : applications et systèmes exposés 38 %, pare-feu 21 %.

Où la fenêtre se perd, concrètement, dans une entreprise qui n'est pas négligente :

La notification arrive sur une adresse générique, d'où elle est transmise « au service informatique » sans délai et sans personne pour confirmer qu'elle a été appliquée.
Le correctif exige une fenêtre de maintenance, la fenêtre exige l'accord de quelqu'un aux opérations, et l'accord est reporté au week-end suivant — pendant trois week-ends.
L'équipement vulnérable est en bordure du réseau et c'est le fournisseur d'accès ou l'intégrateur qui l'administre, donc personne dans l'entreprise ne s'en sent propriétaire.
On corrige celles au score élevé, parce qu'un score élevé s'explique plus facilement à la direction, tandis que celle qui est réellement exploitée reste en onzième position.

Pourquoi la fenêtre ne se ferme pas en recrutant plus vite

Le réflexe normal, devant ces chiffres, est de conclure qu'il vous manque une personne. Les données ne soutiennent pas cette conclusion. Le Cyentia Institute a modélisé, sur environ 300 organisations, le taux mensuel de fermeture des vulnérabilités face au taux d'ouverture, et a trouvé quelque chose d'une stabilité inconfortable : une organisation type a la capacité de corriger environ 1 vulnérabilité sur 10 par mois dans son environnement, et cela semble valable pour les grandes entreprises, les petites et tout ce qui se trouve entre les deux. La capacité de remédiation se comporte comme un plafond, pas comme une fonction linéaire du nombre de personnes dans l'équipe.

L'enquête Sophos montre la même chose dans l'autre sens. Le manque de personnel ou de capacité est massivement invoqué par les entreprises de 100 à 250 salariés, ce qui ne surprend personne ; la partie inattendue, c'est que quatre organisations sur dix comptant 3 001 à 5 000 salariés l'invoquent à un taux inférieur de seulement 3 %. Les ressources ne deviennent pas nécessairement plus faciles avec la taille. Et la cause opérationnelle la plus citée, pour la deuxième année consécutive, reste « les lacunes de sécurité, connues ou inconnues », à 62 %, devant le manque de personnel ou de compétences, à 58 %.

Un argument de plus, venu de Roumanie : dans son rapport 2025, le DNSC déclare un taux de pourvoi des postes de 17,69 %. L'autorité nationale fonctionne à moins d'un cinquième des postes prévus et a tout de même surveillé 317 000 enregistrements CVE, dont elle a analysé 121 en détail immédiatement après leur publication. Elle n'y est pas arrivée en recrutant davantage. Elle y est arrivée en sélectionnant.

Le problème n'est pas la charge de travail, c'est l'ordre

C'est ici que toute la discussion change. FIRST.org, l'organisme qui publie les scores EPSS, précise que le catalogue KEV de la CISA contient environ 0,5 % des CVE publiés, et que dans une fenêtre quelconque de 30 jours EPSS observe une activité d'exploitation sur environ 2,5-3 % d'entre eux. L'estimation la plus généreuse dit qu'au plus 6 % environ des CVE publiés sont un jour exploités dans la nature ; les jeux de données plus stricts indiquent 1-2 %. Sur 35 364 vulnérabilités publiées au premier semestre 2026, seules 85 étaient apparues dans le KEV au moment d'une analyse indépendante — avec la réserve légitime que le KEV a des mois de retard et n'enregistre que l'exploitation confirmée.

Lu avec le plafond de capacité, ce chiffre retourne le problème. Si vous corrigez de toute façon environ 10 % de votre inventaire par mois, et que parmi les vulnérabilités de cet inventaire seuls quelques pourcents seront un jour utilisés contre vous, alors vous n'avez pas un problème de charge de travail. Vous avez un problème de sélection. L'entreprise qui corrige 10 % par mois et choisit mal perd ; l'entreprise qui corrige exactement les mêmes 10 % et choisit bien est couverte. La différence entre les deux n'est pas un recrutement de plus.

Vous ne corrigez pas plus. Vous corrigez dans un autre ordre — et cet ordre doit être recalculé au rythme où change la liste de l'attaquant, pas au rythme du rapport trimestriel.

Ce rythme n'est pas généreux. VulnCheck a mesuré, sur 884 vulnérabilités entrées dans le KEV en 2025, que 28,96 % présentaient des preuves d'exploitation le jour de la publication du CVE ou avant ; au premier semestre 2026, 23,43 %. L'édition 2025 du DBIR mesurait, sur les données de 2024, une médiane de 5 jours jusqu'à l'exploitation de masse d'une vulnérabilité KEV et zéro jour pour celles de périmètre — un chiffre de l'édition précédente, sur une autre année, donc pas un chiffre dont on retranche quoi que ce soit. Pour près d'une vulnérabilité sur quatre, le chronomètre de l'attaquant démarre de toute façon avant le vôtre.

C'est pourquoi la priorisation sur un seul critère ne fonctionne pas. Le score de sévérité CVSS décrit à quel point ce serait grave si, pas à quel point c'est probable. La probabilité seule ne suffit pas davantage : en août 2026, sur 26 vulnérabilités ajoutées au catalogue KEV, 18 avaient un score EPSS inférieur à 1 %. Ce qui fonctionne, c'est une combinaison de cinq critères : la sévérité, la probabilité d'exploitation, la présence sur la liste d'exploitation confirmée, l'exposition réelle du service et sa criticité pour l'activité. D'où la situation qui effraie un auditeur et qui est pourtant correcte : une vulnérabilité de sévérité moyenne, activement exploitée, sur un service exposé à Internet, passe avant une vulnérabilité de sévérité quasi maximale que personne n'exploite, dans un service interne.

Le poids du vecteur « vulnérabilité » face aux autres est un sujet que les sources ne tranchent pas : le DBIR 2026 le place en premier, à 31 % des compromissions ; l'enquête Sophos le voit descendre de 32 % à 18 %, sous le courriel malveillant — mais elle demande aux victimes ce qu'elles croient être la cause, et une entreprise de 150 personnes reconnaît plus facilement un courriel qu'une vulnérabilité dont elle ignorait l'existence. Les chiffres ne sont pas comparables entre eux. Ce qui ne dépend pas de celui que vous choisissez : 59 % des demandes de rançon dans les attaques partant d'une vulnérabilité exploitée sur le pare-feu s'élèvent à un million de dollars ou plus, contre 48 % de l'ensemble des demandes. Un vecteur plus rare et plus coûteux n'est pas une raison de l'ignorer.

L'ordre des opérations, si vous voulez raccourcir la fenêtre

Rien dans la liste suivante ne suppose un budget de grand groupe. Cela suppose seulement que les choses se font dans cet ordre, et non l'inverse.

1Faites l'inventaire de l'exposition réelle — ce qui répond effectivement à une requête venue de l'extérieur, pas ce que quelqu'un se rappelle. Sans lui, toute priorisation se fait sur une carte erronée.
2Décidez qui reçoit les notifications — de l'autorité nationale, du fournisseur de l'équipement de périmètre, de votre propre scan — et écrivez un délai de réponse. Une notification sans propriétaire et sans délai n'est pas une notification, c'est une archive.
3Priorisez sur les cinq critères, pas sur le score de sévérité, et recalculez souvent : le catalogue CISA des vulnérabilités activement exploitées a reçu 26 nouvelles entrées rien qu'en août 2026, donc un ordre établi trimestriellement est déjà périmé quand vous le lisez.
4Traitez le périmètre à part, et en premier. L'ENISA décrit l'activité des groupes soutenus par des États en 2025 précisément par l'exploitation soutenue de l'infrastructure de périmètre, et l'assureur Coalition, sur les sinistres qu'il a payés en 2024, montre 58 % des sinistres rançongiciel partis de la compromission d'un équipement de périmètre.
5Quand vous ne pouvez pas appliquer le correctif maintenant — et parfois vous ne pouvez pas — écrivez ce que vous mettez à sa place en attendant : accès restreint aux sources qui en ont besoin, supervision du service concerné, une date de retour. Une fenêtre assumée est autre chose qu'une fenêtre oubliée.
6Tenez un historique des décisions : ce qui a été corrigé, ce qui a été reporté, sur quelle base et par qui. C'est la seule chose qui transforme « nous n'avons pas eu le temps » en « nous avons priorisé, voici comment ».
7Si vous n'avez personne à mettre là-dessus chaque semaine, externalisez le jugement, pas seulement les outils — un partenaire en cybersécurité qui prend aussi la décision, pas seulement celui qui livre le rapport de scan.

Ce que fait un produit qui surveille le serveur en continu

La classe de produit qui correspond à ce problème n'est pas un antivirus et n'est pas un SIEM. C'est de la détection déterministe qui tourne en continu, à un coût quasi nul par événement, plus une couche de jugement fondée sur un modèle, appelée seulement pour ce qui franchit un seuil — les deux sur l'infrastructure du client. La détection en continu maintient la liste de priorités à jour ; la couche de jugement la rend lisible par quelqu'un qui n'est pas spécialiste. Ce qu'un modèle peut et ne peut pas faire en triage, nous l'avons traité dans l'article sur le triage des alertes de sécurité.

Sentinel, notre produit, est une illustration concrète de cette classe, et la façon la plus utile de le décrire dans un article passe par ce qu'il ne fait pas. La priorité de remédiation se calcule à partir de la sévérité, de la probabilité d'exploitation, de la présence sur la liste CISA des vulnérabilités activement exploitées, de l'exposition et de la criticité — exactement les cinq critères ci-dessus — et le plan de correction est rédigé commande par commande, avec sauvegarde, vérifications et étapes de retour arrière. Mais il ne l'applique pas seul, à aucun niveau commercial : au niveau de base, l'application des correctifs est explicitement exclue du service, au niveau administré les plans rédigés par le modèle sont vérifiés par nous avant d'arriver au client, et l'application exige deux confirmations explicites au téléphone, avec un bouton qui meurt si le plan est régénéré.

Pour le dire franchement, à tout acheteur : le produit ne ferme pas la fenêtre à votre place. Il la rend visible, la met dans le bon ordre et vous met la procédure en main ; la décision d'arrêter la production cinq minutes pour appliquer un correctif reste celle de l'entreprise. Les manques sont déclarés eux aussi : les journaux des conteneurs ne sont pas encore collectés, il n'existe pas de moniteur dédié d'intégrité des fichiers au-delà d'auditd, et l'installation sur Debian est couverte par des tests mais pas encore vérifiée sur un hôte Debian réel. Les trois niveaux commerciaux sont tarifés « sur demande », parce que cela dépend du nombre de machines et de la part de l'exploitation que vous reprenez.

Pour la personne technique qui évalue : ce qu'il faut demander avant de signer

Si c'est vous qui vivrez avec le produit sur le serveur, les questions qui comptent ne portent pas sur le tableau de bord. Et elles méritent d'être posées à tout fournisseur de cette classe, pas seulement à nous.

Ce qu'il collecte, exactement. Chez nous, cinq types de sources sont listés publiquement — sshd, sudo et su, nginx, auditd, Suricata. Demandez la liste, pas un nombre : ce qui n'est pas sur la liste n'est pas surveillé.
À quelle fréquence il regarde et selon quelles règles. La détection tourne de façon déterministe toutes les 10 secondes, sur des seuils publiés : force brute SSH à 15 échecs en 60 secondes, énumération web à 200 chemins inexistants en 5 minutes. Un seuil que vous n'avez pas le droit de voir est un seuil que vous ne pouvez pas calibrer.
Comment les incidents sont comptés. La déduplication par empreinte fait de 400 tentatives venues d'une adresse un seul incident, pas 400. Sans elle, le premier week-end de scan automatisé entraîne votre équipe à ignorer les alertes.
Ce qu'il advient du plan rédigé par le modèle. Chez nous, il passe par un validateur déterministe qui le refuse s'il n'est pas sûr : le modèle rédige, le validateur décide. La commande rm n'est pas dans la liste des binaires autorisés, et la suppression passe par une opération unique limitée au répertoire de sauvegarde.
Comment sont traitées les lignes de journal. Elles sont écrites par l'attaquant, donc ce sont des données non fiables : elles arrivent au modèle avec des délimiteurs explicites, le transport qui lit les fichiers tourne en permission-mode plan, et un test plante IGNORE PREVIOUS INSTRUCTIONS dans un journal d'accès et vérifie que rien n'a été exécuté. Une injection réussie change une étiquette, pas le système.
Ce qui se passe quand le produit tombe. La règle de base nftables est policy accept, c'est donc une liste de refus, pas un pare-feu : si le processus meurt ou si la configuration est erronée, le trafic passe. Un produit de sécurité qui arrête votre activité par son propre échec est un problème nouveau.
Comment se met en route le blocage automatique. Chez nous il existe et il est testé, mais il est livré désactivé : les premières 72 heures montrent seulement ce qui aurait été bloqué. Qui active le blocage dès le premier jour sur un réseau qu'il n'a pas encore observé vous promet un incident de disponibilité.

Conclusion

La fenêtre entre le moment où vous apprenez que vous avez une vulnérabilité non corrigée et le moment où vous l'avez corrigée ne se ferme pas en travaillant plus, parce que le plafond de remédiation se mesure à peu près pareil dans une petite entreprise et dans une entreprise de quelques milliers de personnes. Elle se ferme en choisissant mieux, chaque semaine, dans un inventaire dont seuls quelques pourcents seront un jour utilisés contre vous — et ce choix demande quelque chose qui regarde votre serveur au rythme de l'attaquant, pas au rythme du rapport trimestriel. Si vous voulez qu'on regarde ensemble ce que vous avez exposé maintenant et dans quel ordre il faudrait le corriger, discutons 30 minutes, sans engagement.

Sources

DNSC — Rapport annuel d'activité 2025, approuvé par la décision CSAT n° 117 du 7 août 2026 (dnsc.ro)
Verizon — Data Breach Investigations Report 2026, plus d'un milliard d'enregistrements de détection, avec les analyses publiées par Tenable, Nucleus Security et Qualys ; édition 2025 du même rapport, via l'analyse GreyNoise
Cyentia Institute — « Patching, Fast and Slow » (cyentia.com) ; Cyentia / Veracode — 2026 State of Software Security
Sophos — The State of Ransomware 2026, 2 158 responsables informatiques, 17 pays, entreprises de 100 à 5 000 salariés (sophos.com)
IBM — Cost of a Data Breach Report 2026, recherche du Ponemon Institute (ibm.com/reports)
FIRST.org — FAQ EPSS et documentation EPSS (first.org/epss)
VulnCheck — State of Exploitation 2026 et 1H-2026 (vulncheck.com)
ENISA — Threat Landscape 2026, 8 257 incidents de 2025 (enisa.europa.eu)
Coalition — Cyber Threat Index 2025, sur les sinistres payés par l'assureur (coalitioninc.com)
Jerry Gamblin — CVE Mid-Year 2026 Check-In (jerrygamblin.com) ; isMalicious — analyse KEV et EPSS, août 2026 (ismalicious.com)
CryptoITData — Sentinel, documentation produit et limites déclarées publiquement (cryptoitdata.eu/sentinel)