MTTR et MTTE : la fenêtre entre l'alerte et la compromission

60 à 150 jours pour corriger. Quelques jours pour qu'un exploit soit disponible. Entre les deux, votre organisation est exposée, souvent sans le savoir.

Il est 11h un mardi matin. Votre outil de gestion des vulnérabilités vient de remonter une alerte critique : CVSS 9.6 (indice de sévérité sur 10), un équipement exposé dans votre périmètre est concerné. Vous ouvrez un ticket, qualifiez la sévérité, assignez l'équipe réseau. Procédure habituelle, exécutée correctement.

Ce que vous ignorez à cet instant : l'attaquant qui scrute les nouvelles publications CVE dispose déjà d'un exploit fonctionnel depuis plusieurs jours. Il attendait ce bulletin pour identifier les cibles. Dans la grande majorité des organisations, c'est dans cet intervalle entre la détection et la remédiation effective que se concentrent les compromissions les plus évitables.

Deux chiffres vont définir ce qui se passe ensuite. Votre MTTR, c'est-à-dire combien de temps il vous faudra pour corriger. Et le MTTE de l'attaquant, c'est-à-dire combien de temps il lui a fallu pour avoir un exploit. La différence entre les deux, c'est votre fenêtre d'exposition réelle.

C'est une course dont vous ne voyez jamais l'adversaire. Vous savez que vous devez parcourir une certaine distance pour corriger la faille. Ce que vous ne savez pas, c'est à quelle distance derrière vous se trouve l'attaquant, ni s'il a déjà pris une longueur d'avance avant même le coup de départ officiel.

À retenir

• MTTR moyen : 60 à 150 jours pour corriger une vulnérabilité critique

• MTTE : souvent négatif sur les CVE critiques, l'exploit existe avant le patch

• Fenêtre d'exposition = MTTD + MTTR. Si elle dépasse le MTTE, vous êtes exposé par construction

• NIS2 et DORA imposent une notification sous 24-72h : le MTTR devient un indicateur réglementaire

• Combiner visibilité continue, priorisation contextuelle et re-scan post-remédiation divise le MTTR par 3

Avant de continuer ce mardi matin, posons les bases. Ces acronymes désignent des réalités très différentes et comptent parmi les indicateurs clés de performance les plus suivis en gestion des vulnérabilités. La confusion entre eux fausse souvent les reportings.

MTTR. Le MTTR mesure le temps moyen nécessaire entre la détection d'une vulnérabilité et sa correction confirmée. L'horloge démarre à la détection, pas au triage. Le calcul du MTTR se fait ainsi : temps total des délais de remédiation ÷ nombre de réparations effectuées. À segmenter impérativement par criticité, un MTTR agrégé ne dit rien sur votre exposition réelle, et masque souvent un processus de résolution qui fonctionne bien sur certains actifs et mal sur d'autres.

MTTE. C'est la métrique de l'attaquant. Selon les données Pixee (analyse de 100 000+ PRs de remédiation, 2025), sur les CVE critiques ce délai est souvent négatif : des exploits circulent avant le patch officiel. Le rapport Mandiant M-Trends 2026 confirme la tendance à l'échelle macro : le MTTE moyen est désormais estimé à -7 jours, contre 63 jours en 2018. Si votre MTTR dépasse votre MTTE, vous êtes exposé par construction.

La plupart des programmes de gestion des vulnérabilités suivent le MTTR sans jamais le confronter au MTTE. C'est l'angle mort le plus commun du secteur : on mesure sa propre vitesse de correction sans jamais la comparer à la vitesse réelle de la menace. Un MTTR de 30 jours peut sembler correct isolément. Confronté à un MTTE de -7 jours sur la même CVE, il révèle une fenêtre d'exposition de 37 jours pendant laquelle l'exploit existait déjà.

"Le MTTR seul ne dit rien. C'est sa confrontation avec le MTTE qui révèle votre exposition réelle. On a construit toute la logique de priorisation de Patrowl autour de cet écart, pas autour du MTTR pris isolément.", explique Vladimir Kolla, cofondateur et CTO de Patrowl.

Le MTTR reste un indicateur clé pour mesurer l'efficacité d'un programme de remédiation, mais seul, c'est un indicateur de performance incomplet : il ne dit rien sur la vitesse de l'attaquant en face.

Votre ticket est ouvert, l'alerte qualifiée, votre équipe réseau notifiée. Ce que les données terrain montrent en parallèle est inconfortable.

Selon le rapport Mandiant M-Trends 2026, le délai entre accès initial d'un attaquant et cession à un autre groupe de menaces est passé de plus de 8 heures en 2022 à 22 secondes en 2025. L'industrialisation de l'exploitation n'a plus rien d'artisanal.

Au moment où vous ouvrez votre ticket ce mardi matin, la CVE a été publiée ce matin, mais l'exploit associé circule depuis plusieurs jours dans des canaux offensifs privés. Votre processus de qualification, d'assignation et de correction prendra entre 3 et 4 semaines sur une vulnérabilité critique, ce qui est courant même dans des équipes bien structurées.

Résultat : 28 à 35 jours d'exposition nette sur une faille pour laquelle un attaquant dispose déjà d'un vecteur documenté. Ce n'est pas une défaillance de vos équipes. C'est l'inadéquation structurelle entre un processus conçu pour un rythme hebdomadaire et une menace qui opère en temps réel.

"Le MTTR n'est pas qu'un indicateur de vitesse. C'est un indicateur de risque financier. Chaque jour supplémentaire d'exposition sur une CVE critique avec exploit public, c'est une fenêtre ouverte que quelqu'un peut décider d'utiliser.", explique Florent Montel, cofondateur de Patrowl.

Ce scénario s'est reproduit dans des centaines d'organisations en février 2024. Il illustre exactement la mécanique MTTR / MTTE dans un contexte réel, et reste un cas d'école sur la façon dont les failles de sécurité critiques se transforment en incident de sécurité grandeur réelle.

J−7. Des exploits fonctionnels circulent dans des canaux offensifs privés. Votre organisation n'en sait rien. La faille existe dans vos systèmes.

J0, le 8 février. Fortinet publie le bulletin. CVE-2024-21762, CVSS 9.6, exécution de code à distance sans authentification. Fortinet confirme des exploitations actives en production au moment de la publication. Certaines organisations sont déjà compromises avant de recevoir la première alerte.

J+1. Exploits publics sur GitHub. La CISA (agence américaine de cybersécurité) ajoute la CVE à sa liste KEV (Known Exploited Vulnerabilities, failles activement exploitées). Pour les entités fédérales américaines : 14 jours légaux pour corriger. Pour tout le monde : le chrono tourne.

J+3 à J+7, MTTD estimé : 3 à 7 jours. Les organisations avec scans hebdomadaires découvrent maintenant trois appliances FortiOS non inventoriées exposées sur internet. Celles avec surveillance continue l'ont su dans les heures suivant J0.

J+7 à J+45, MTTR constaté : 21 à 45 jours. Triage, assignation réseau, préproduction, change management, déploiement progressif. Les équipes font leur travail correctement. Mais chaque étape prend du temps. Certaines grandes structures dépassent 60 jours.

Fenêtre d'exposition réelle : 24 à 52 jours sur une vulnérabilité avec exploit public depuis J+1. Les causes profondes restent les mêmes dans la majorité des incidents documentés : des appliances FortiOS non inventoriées, absentes des scans habituels, détectées tardivement, ou pas du tout avant la compromission. Quand l'appliance tombe en panne ou doit être isolée en urgence, c'est tout un service informatique qui se retrouve dépendant d'un correctif appliqué dans la précipitation.

Impact technique : exécution de code à distance sans authentification sur l'appliance FortiOS, ce qui donne à l'attaquant un accès complet au pare-feu ou au VPN concerné, point d'entrée habituel vers le reste du réseau interne.

Impact métier : accès direct au réseau de l'entreprise depuis l'extérieur, sans avoir besoin d'identifiants ni de complicité interne. Selon le rôle de l'appliance compromise, cela peut signifier l'arrêt du VPN pour tous les collaborateurs à distance, une interruption des services pour les équipes DevOps qui dépendent de cet accès, ou un point de pivot vers les serveurs de production. Une mise à jour appliquée 24 heures après la publication du bulletin Fortinet aurait évité un temps d'arrêt de plusieurs jours pour certaines des organisations touchées.

À 17h, vous constatez que le MTTR moyen sur les vulnérabilités critiques stagne à plus de 40 jours depuis plusieurs mois, malgré une équipe compétente et des processus documentés. Ce paradoxe est récurrent. Les organisations qui souffrent de MTTR élevés ne manquent pas de compétences techniques. Elles se heurtent à des contraintes structurelles que les scanners ne résolvent pas seuls. Même les équipes de sécurité les plus expérimentées peinent à maintenir un MTTR stable au cours d'une période donnée si la visibilité initiale fait défaut.

En résumé : le problème commence avant la remédiation. Il commence au niveau de la visibilité.

L'actif n'est pas dans l'inventaire. Un sous-domaine mis en prod il y a six mois, une instance cloud ouverte par un dev, une API tierce non référencée : votre scanner ne détecte que ce qu'il connaît. Cette vulnérabilité n'apparaîtra jamais dans votre historique. Le temps d'exposition commence avant même la détection.

Le ticket prioritaire n'est pas le bon. CVSS 9.8 en tête de liste. Votre équipe s'y attaque. Sauf que c'est un serveur interne jamais exposé. Pendant ce temps, le 7.2 sur votre API publique avec exploit connu attend. Sans contextualisation, vous traitez ce qui est rouge, pas ce qui est dangereux.

Le process mange le temps. Détection lundi, triage mardi, assignation mercredi, préproduction semaine suivante, changement la semaine d'après. Dans les grandes structures, cette chaîne représente 60 à 70 % du MTTR total. Ce n'est pas la technique qui bloque. Le processus de réparation lui-même est rarement le goulot d'étranglement : c'est la coordination entre gestion des incidents, équipes infra et équipes métier qui consomme le temps moyen de réparation.

Personne ne veut arrêter la prod. Patcher en urgence veut dire convaincre une équipe dev en plein sprint, passer un change management express, risquer une interruption de service. La sécurité perd souvent cet arbitrage. Réduire le bruit des fausses priorités aide à obtenir l'arbitrage sur les vraies urgences, mais aucun outil ne règle ce problème organisationnel à votre place.

"Ce qu'on voit systématiquement chez les clients avec un MTTR élevé, c'est pas un manque de compétence. C'est une liste de priorités mal calibrée parce que le contexte d'exposition réelle manque. Le CVSS brut, c'est un score de laboratoire. Ce qui compte c'est le CVSS + est-ce que l'actif est exposé + est-ce qu'il y a un exploit qui tourne.", résume Vladimir Kolla, cofondateur de Patrowl.

En résumé : le MTTR n'est plus seulement un KPI opérationnel. C'est ce que vous montrez à votre COMEX, vos auditeurs et vos régulateurs pour démontrer que vous maîtrisez votre posture de sécurité.

Chaque mois, les RSSI produisent des reportings destinés au COMEX, aux auditeurs, aux assureurs cyber ou aux régulateurs. Une question revient systématiquement : combien de vulnérabilités critiques restent ouvertes, depuis combien de temps et sur quels actifs ?

Pour y répondre correctement, il faut être capable d'expliquer quelles vulnérabilités critiques restent ouvertes, depuis combien de temps, sur quels actifs, pourquoi certaines remédiations ont été priorisées avant d'autres, et comment le niveau de risque évolue dans le temps. C'est précisément ce niveau de granularité que les régulateurs attendent désormais en matière de sécurité.

NIS2 impose aux entités essentielles et importantes de notifier l'ANSSI sous 24 heures puis de fournir un rapport intermédiaire sous 72 heures. DORA introduit des obligations comparables pour les acteurs financiers. Le MTTR devient un indicateur de conformité autant qu'un indicateur en matière de gestion des risques.

Les objectifs observés varient selon la criticité : vulnérabilités critiques entre 7 et 15 jours, élevées autour de 30 jours, moyennes jusqu'à 90 jours, faibles jusqu'à 180 jours. Ces repères restent insuffisants utilisés seuls. Une CVE CVSS 9.8 sur un serveur interne non exposé présente souvent un risque inférieur à une CVE 7.2 sur une API publique avec exploit documenté.

"En COMEX, la question qui revient c'est pas 'quel est notre MTTR'. C'est 'est-ce qu'on peut démontrer qu'on sait ce qu'on expose et qu'on le gère'. DORA et NIS2 ont rendu cette démonstration obligatoire avec des délais et des sanctions associés.", note Nicolas Mattiocco, cofondateur et CEO de Patrowl.

En fin de journée, votre dashboard affiche un MTTR de 28 jours, un chiffre qui semble satisfaisant au regard des benchmarks sectoriels. Dans beaucoup d'organisations, ce résultat est le produit de trois biais de calcul systématiques qui sous-estiment l'exposition réelle.

L'horloge démarre au triage, pas à la détection. Le scanner tourne le lundi à 2h, l'analyste voit la vulnérabilité le jeudi lors de sa revue hebdomadaire. Dans la plupart des outils, le délai de remédiation commence à l'ouverture du ticket, soit jeudi. Ces 3 jours disparaissent. Multipliez ce biais sur toutes vos vulnérabilités : votre MTTR réel est systématiquement sous-estimé.

Le ticket est fermé, la faille reste ouverte. Patch appliqué, ticket fermé, MTTR amélioré. Mais personne n'a vérifié que le patch a bien été déployé sur les trois instances, que la configuration post-patch est correcte. Quelques semaines plus tard, un pentest ou un attaquant trouve encore la faille. Le délai de remédiation se termine à la validation confirmée, pas à la fermeture du ticket.

Un seul chiffre pour tout. MTTR de 42 jours en COMEX. Ce qu'il ne dit pas : MTTR critique à 88 jours, MTTR faible à 8 jours. Calculez votre MTTR par niveau de criticité et par type d'actif. C'est le seul chiffre qui pilote quelque chose.

Reprenons la scène : même CVE critique, même score CVSS 9.6, même mardi à 11h. Mais cette fois avec une visibilité complète sur les actifs concernés.

Les organisations qui déploient Patrowl constatent en moyenne une division par trois de leur MTTR sur les vulnérabilités critiques exposées. Cette amélioration repose sur trois mécanismes, racontés dans le fil de ce mardi matin. Mettre en place ce dispositif ne vise pas seulement à réduire les délais de remédiation : c'est aussi un moyen direct d'améliorer le MTTR sans recruter une seule personne supplémentaire dans l'équipe de réponse aux incidents.

11h02, vous savez déjà que cet actif existe. L'EASM (External Attack Surface Management, cartographie continue de votre périmètre exposé) de Patrowl a déjà identifié les appliances FortiOS exposées, y compris celles qu'aucun inventaire ne référençait. Quand la CVE arrive, vous savez en quelques minutes si vous êtes concerné et où. MTTD : de 7 jours à quelques heures.

11h08, votre ticket prioritaire est le bon ticket. Patrowl croise exposition internet, valeur business de l'actif et existence d'un exploit documenté. La liste que voit votre analyste reflète votre risque réel, pas du CVSS brut. L'appliance FortiOS exposée sur internet passe en tête. Le serveur interne CVSS 9.8 jamais exposé descend dans la liste.

J+15, vous savez que le patch a vraiment été appliqué. Patrowl déclenche un re-scan automatique après chaque remédiation signalée. Si la faille est toujours présente, le ticket se rouvre. La boucle se ferme seulement quand c'est réellement corrigé, pas quand le ticket est fermé.

"Le re-scan post-remédiation, c'est souvent là qu'on trouve les surprises. Un patch déployé sur deux instances sur trois, une configuration post-patch incorrecte, un actif jumeau qu'on avait oublié. Sans validation externe automatique, ces cas restent ouverts sans que personne le sache.", complète Florent Montel, cofondateur de Patrowl.

La prochaine vulnérabilité critique ne touchera pas forcément un actif déjà présent dans votre inventaire.

Patrowl cartographie en continu les actifs exposés sur internet, identifie les vulnérabilités réellement exploitables et aide les équipes sécurité à prioriser les remédiations qui réduisent effectivement le risque.

Savez-vous en combien de temps vous détecteriez une CVE critique sur un actif hors inventaire ?

Ce mardi matin se reproduira. Une CVE critique tombera, un exploit sera disponible avant le patch, et vos équipes feront leur travail correctement dans un délai qui dépassera la fenêtre d'exploitation.

Ce qui change entre deux organisations dans cette situation, c'est rarement la compétence des équipes. C'est la visibilité sur ce qu'elles exposent vraiment, la précision de ce qu'elles traitent en premier, et la certitude que ce qui a été corrigé l'est vraiment.

Le MTTR est un symptôme. La cause, c'est l'écart entre votre périmètre réel et ce que vous pensez surveiller. Mettre en œuvre les meilleures pratiques en matière de cybersécurité ne suffit pas si cette visibilité de base manque.

Qu'est-ce que le MTTR en cybersécurité ?

Le MTTR (Mean Time to Remediate) mesure le temps moyen entre la détection d'une vulnérabilité et sa correction confirmée. En gestion des vulnérabilités, ce délai varie de 60 à 150 jours selon les organisations (Cymulate / Praetorian). C'est l'indicateur central de la vitesse opérationnelle d'un programme de sécurité, et un indicateur de conformité réglementaire sous NIS2 et DORA.

Comment calculer le MTTR ?

MTTR = total des délais de remédiation ÷ nombre de réparations effectuées sur une période. À calculer par criticité, pas en agrégé. L'horloge démarre à la détection initiale, pas à l'ouverture du ticket. La correction est validée par re-scan externe, pas par fermeture du ticket.

Comment réduire le MTTR sur les vulnérabilités critiques ?

Trois leviers : visibilité continue sur la surface d'attaque réelle (y compris actifs hors inventaire), priorisation contextuelle plutôt que CVSS brut, et re-scan automatique post-remédiation. Les organisations qui combinent ces trois points divisent leur MTTR par 3 sur les vulnérabilités critiques exposées, selon les données terrain Patrowl.

Quel MTTR cible pour les vulnérabilités critiques ?

CISA BOD 22-01 : 14 jours pour les KEV (Known Exploited Vulnerabilities, failles activement exploitées en production). NIS2 et DORA : notification sous 24-72h. Les organisations les plus réactives visent 7 à 15 jours sur les critiques avec exploit public disponible. Ces cibles doivent être définies par segment d'actifs et non en global.

Un MTTR plus bas est-il toujours meilleur ?

Non. Ce qui compte c'est le MTTR sur les vulnérabilités exposées avec un exploit disponible. Traiter en 2 jours les vulnérabilités faibles sur des actifs internes non exposés pendant que les critiques exposées attendent 90 jours donne un MTTR moyen présentable et une exposition réelle catastrophique.

Comment justifier un investissement sur la réduction du MTTR en COMEX ?

IBM Cost of a Data Breach 2025 : coût moyen 4,88M$. Les organisations sous 14 jours de MTTR critique réduisent ce coût de 30%. En France, NIS2 et DORA : un MTTR élevé augmente l'exposition aux sanctions réglementaires en cas d'incident non notifié dans les délais. La question n'est pas le coût de l'outil, c'est le coût de chaque jour supplémentaire d'exposition.

Mandiant M-Trends 2026 · Veracode State of Software Security 2025 · IBM Cost of a Data Breach Report 2025 · FIRST.org CVE forecast 2026 · CISA Binding Operational Directive 22-01 · Praetorian MTTR Benchmarks 2026 · Cymulate Threat Exposure Validation Impact Report 2025 · Pixee Platform Data 2025 · CESIN Baromètre 2024 · Directive NIS2 (UE 2022/2555) · Règlement DORA (UE 2022/2554) · Fortinet PSIRT FG-IR-24-015