Qu'est-ce que le délai moyen de détection (MTTD) ?
Le délai moyen de détection (MTTD, de l'anglais Mean Time to Detect) est une métrique des opérations de sécurité qui mesure le temps moyen entre le moment où une activité malveillante ou anormale commence dans un environnement et le moment où l'équipe de sécurité la détecte. C'est l'un des indicateurs clés de performance (KPI) les plus suivis dans un centre opérationnel de sécurité (SOC), car il quantifie la durée pendant laquelle une menace peut opérer sans être détectée : la fenêtre de présence de l'attaquant (dwell time). Un MTTD plus faible signifie que les menaces sont repérées plus rapidement, réduisant le temps dont dispose un adversaire pour élever ses privilèges, se déplacer latéralement ou exfiltrer des données. Un MTTD élevé signale des angles morts dans la visibilité, des détections bruyantes ou des analystes débordés. Le MTTD se lit presque toujours aux côtés de son pendant côté réponse, le délai moyen de réponse (MTTR, Mean Time to Respond). Bien que le concept soit né dans l'ingénierie de fiabilité IT, où il mesurait la rapidité avec laquelle les équipes remarquaient des pannes et des indisponibilités, le MTTD est devenu une métrique centrale de la sécurité. Cette page explique ce qu'il mesure, comment le calculer, pourquoi sa définition est plus complexe qu'il n'y paraît, sa relation avec le MTTR et les autres métriques temporelles d'un SOC, et les leviers pratiques pour le réduire.
Ce qu'il faut retenir
- Le MTTD mesure la vitesse de détection. C'est le temps moyen entre le début d'une activité malveillante ou anormale et la prise de conscience de l'équipe, un proxy direct du temps de présence de l'attaquant.
- La formule est simple ; les données d'entrée ne le sont pas. Le MTTD correspond au temps de détection total divisé par le nombre d'incidents, mais déterminer le vrai moment de début de l'activité et ce qui compte comme « détecté » fait l'objet de désaccords.
- Le MTTD n'est pas le MTTR. Le MTTD couvre la phase de détection ; le MTTR couvre la réponse et la remédiation. Un MTTD faible associé à un MTTR élevé signale un goulot d'étranglement dans la réponse, pas dans la détection.
- Un MTTD plus faible réduit le coût d'une violation. Le délai de détection est directement corrélé aux dommages ; les études sectorielles associent systématiquement une détection plus rapide à un coût d'incident plus faible et un rayon d'impact plus petit.
- La visibilité, la qualité de la détection et le renseignement le font baisser. Une télémétrie large, des détections bien paramétrées mappées à MITRE ATT&CK, du renseignement sur les menaces natif et l'automatisation sont les leviers qui réduisent durablement le MTTD.
Ce que le MTTD mesure réellement
Dans son essence, le MTTD est une mesure de la visibilité et de la capacité de détection. Il reflète l'efficacité avec laquelle les outils, processus et personnes d'une organisation peuvent remarquer que quelque chose ne va pas. Pour cette raison, le MTTD se lit mieux en agrégat, sur l'ensemble d'une fonction ou de l'organisation et dans le temps, plutôt que comme un chiffre isolé. Les tendances comptent plus que le chiffre d'un seul mois.
La métrique apparaît dans deux contextes étroitement liés. En cybersécurité, le MTTD est le temps écoulé entre le début d'une activité malveillante (accès non autorisé, déploiement d'un malware, violation de politique) et le moment où les outils de sécurité ou les analystes l'identifient. En opérations IT et ingénierie de fiabilité des sites, la même métrique mesure la rapidité avec laquelle les équipes remarquent une dégradation de service ou une panne. Dans les deux cas, le message est identique : plus la détection tarde, plus les dommages s'accumulent.
Le MTTD a aussi des limites claires. Il ne mesure pas la gravité d'une menace, la résilience de l'environnement, ni la rapidité à résoudre le problème une fois détecté. Ces questions appartiennent à d'autres métriques. Le MTTD répond à une seule chose : combien de temps la menace est-elle restée invisible ?
Comment calculer le MTTD
La formule standard est simple. Pour chaque incident, on soustrait l'heure de début de l'activité de l'heure de détection, on somme ces durées sur tous les incidents d'une période, puis on divise par le nombre d'incidents :
MTTD = (Σ temps de détection par incident) ÷ nombre d'incidents
Un exemple rapide : si un SOC enquête sur trois tentatives d'abus d'identifiants non détectées pendant 5, 11 et 9 minutes respectivement, le MTTD est (5 + 11 + 9) / 3 = 8,33 minutes. Sur un ensemble plus large d'incidents, le calcul est identique, avec simplement plus de points de données.
Pour calculer cela avec précision, les équipes s'appuient sur les journaux d'événements des terminaux, du réseau, des identités et du cloud ; les règles de détection ou les alertes automatisées liées aux activités suspectes ; la reconstruction de la chronologie lors des investigations ; et les horodatages normalisés qui harmonisent les différentes sources de journaux.
Deux ajustements sont courants. D'abord, beaucoup d'équipes éliminent les valeurs extrêmes pour qu'une seule détection très lente ne fausse pas la moyenne. Ensuite, le MTTD est souvent segmenté par gravité d'incident ou classe d'attaque, car la fenêtre de détection acceptable pour un précurseur critique de ransomware est très différente de celle d'une violation mineure de politique, et une moyenne mélangée peut masquer un écart dangereux.
Pourquoi la définition du MTTD est plus complexe qu'il n'y paraît
L'arithmétique est triviale, mais les données d'entrée ne le sont pas, et c'est là que de nombreux rapports MTTD perdent silencieusement leur crédibilité.
La première ambiguïté est l'heure de début de l'activité. Déterminer quand l'activité malveillante a véritablement commencé nécessite une analyse rétrospective, et la plupart des organisations ne disposent de ce niveau de détail forensique que pour les incidents qu'elles ont approfondis. Pour tout le reste, l'heure de début est une estimation. La seconde ambiguïté est ce qui compte comme « détecté ». La détection peut signifier la première alerte déclenchée, l'alerte qui a effectivement conduit à une investigation, ou le moment où un incident a été formellement déclaré. Chaque définition produit un chiffre différent, et les organisations ne documentent souvent pas celle qu'elles utilisent.
La bonne réponse n'est pas d'abandonner le MTTD, mais de le définir explicitement et de l'appliquer de façon cohérente. Parce que la métrique oriente les décisions d'investissement, les arguments de dotation et les évaluations de fournisseurs, une définition instable fragilise toutes les décisions qui s'y appuient. Choisissez une définition de « détecté », documentez-la et maintenez-la stable pour que la courbe de tendance ait un sens.
MTTD vs MTTR, MTTC et MTTA
Le MTTD appartient à une famille de métriques temporelles d'un SOC, chacune mesurant un moment différent du cycle de vie d'un incident. Les reporter séparément, plutôt que comme un seul chiffre combiné, révèle où le temps est réellement perdu.
La relation entre le MTTD et le MTTR est celle qui compte le plus en pratique. Le MTTD couvre le temps qu'un attaquant passe sans être détecté ; le MTTR couvre le temps que l'équipe passe à réagir une fois la menace visible. Ils ont généralement des causes profondes différentes : réduire le MTTD nécessite une meilleure logique de détection, une télémétrie plus large et un triage plus rapide, tandis que réduire le MTTR nécessite de meilleurs workflows de réponse, un confinement automatisé et des transferts d'incidents propres. Un SOC peut afficher un excellent MTTD et un mauvais MTTR, ou l'inverse, c'est précisément pourquoi les mélanger masque le vrai goulot d'étranglement.
Pourquoi le MTTD compte pour la sécurité et l'entreprise
L'argument pour faire baisser le MTTD est fondamentalement une question de limitation des dommages. Chaque heure pendant laquelle une menace reste non détectée est une heure dont dispose un adversaire pour voler des identifiants, se déplacer entre systèmes, désactiver des sauvegardes, exfiltrer des données ou déployer un rançongiciel. Le délai de détection est directement corrélé au coût d'une violation : les études sectorielles, dont l'analyse annuelle du coût des violations de données d'IBM, ont constamment constaté que les incidents identifiés et contenus rapidement coûtent substantiellement moins cher que ceux qui durent des semaines ou des mois. Le chiffre souvent cité selon lequel les organisations peuvent mettre environ 200 jours à détecter une violation souligne l'ampleur de cette fenêtre quand la détection est faible.
Le MTTD sert également de référence pour la maturité du SOC et de pont vers le conseil d'administration. Un MTTD constamment bas suggère une ingestion de télémétrie fluide, des détections précises et un triage efficace ; un MTTD croissant expose des angles morts architecturaux, des lacunes de compétences ou des mauvaises configurations d'outils. En tant que chiffre unique et quantifiable, le MTTD donne aux RSSI un moyen de communiquer les performances de détection aux dirigeants et d'apporter la preuve de conformité à des cadres comme le RGPD, HIPAA, PCI DSS et NIS2, dont plusieurs exigent une détection et une divulgation rapides des incidents.
Comment réduire le MTTD
Faire baisser le MTTD est rarement une question d'achat de plus de surveillance ; il s'agit d'obtenir plus de signal, et un signal plus exploitable, de l'environnement. Les leviers les plus efficaces sont :
- Élargir la visibilité et la télémétrie : La couverture des terminaux manquante, les journaux cloud limités ou les signaux d'identité non surveillés créent des angles morts que les attaquants exploitent. Une journalisation complète et bien gérée sur les terminaux, le réseau, le cloud et les identités est la fondation d'un MTTD bas.
- Améliorer la qualité de la détection : Les règles génériques et par défaut manquent les comportements avancés. Des détections personnalisées basées sur les comportements, alignées sur MITRE ATT&CK et les techniques adversariales connues, détectent les schémas d'attaque réels plus tôt et réduisent le bruit qui noie les vrais signaux.
- Exploiter le renseignement sur les menaces : Alimenter les pipelines de détection avec des indicateurs de compromission (IoC) de haute fidélité donne aux outils une longueur d'avance sur les menaces connues, de sorte qu'un artefact observé ailleurs déclenche une alerte dès sa réapparition dans l'environnement.
- Réduire les faux positifs : La fatigue d'alerte est l'un des principaux facteurs cachés de la lenteur de détection. Le paramétrage des règles de corrélation, l'application d'un scoring d'alerte basé sur le risque et la suppression des schémas bénins connus font remonter les vraies menaces plus rapidement.
- Automatiser le triage et la corrélation : L'automatisation et l'analytique qui corrèlent les signaux entre sources compriment le temps entre le déclenchement d'une alerte et sa reconnaissance par un analyste comme réelle, souvent la plus grande partie du MTTD.
Un mot de prudence : le MTTD peut être manipulé. Parce que la vitesse est facile à manipuler, les équipes évaluées grossièrement peuvent apprendre à enregistrer un accusé de réception symbolique tôt pour produire un chiffre bas. L'objectif est une véritable qualité de détection, alors associez le MTTD à des métriques de couverture et de faux positifs plutôt que de traiter la seule vitesse brute comme cible.
Éclairage expert : La vitesse de détection est une fonction du renseignement et de la couverture, pas seulement des outils
Le MTTD est plafonné par deux choses qui fonctionnent ensemble : la part de l'environnement que vous pouvez réellement voir, et la qualité de vos détections pour reconnaître les comportements malveillants dans cette télémétrie. Améliorer l'un sans l'autre et le MTTD reste obstinément élevé. Une télémétrie large avec des détections faibles noie les analystes sous le bruit ; des détections précises sur une télémétrie partielle manquent tout ce qu'elles n'ont jamais ingéré. Ces deux leviers doivent avancer ensemble.
C'est là que l'approche de Sekoia est pertinente. La plateforme AI SOC Sekoia unifie SIEM, XDR, SOAR et cyber threat intelligence natif dans un seul environnement, et cette combinaison correspond directement aux deux leviers du MTTD. Côté couverture, la plateforme ingère et corrèle la télémétrie des terminaux, du réseau, du cloud et des identités pour que les signaux ne restent pas isolés dans des outils déconnectés. Côté qualité de détection, le contenu est rédigé et maintenu par l'équipe Threat Detection & Research (TDR) interne de Sekoia, mappé à MITRE ATT&CK et continuellement informé par le renseignement natif sur les menaces, de sorte que les artefacts malveillants connus et les techniques adversariales sont reconnus rapidement plutôt qu'après coup. L'analytique comportementale fait remonter l'activité subtile que les règles basées sur les signatures manquent, et l'automatisation compresse le délai de triage entre le déclenchement d'une alerte et sa confirmation par un analyste. En tant qu'éditeur européen avec une posture de souveraineté des données, Sekoia apporte cette profondeur de détection sans obliger les équipes à confier leurs données à une boîte noire.
Quand un fournisseur promet un MTTD plus bas, demandez comment. Une réponse crédible parle de l'étendue de la télémétrie, de l'ingénierie de détection, du renseignement natif et de l'automatisation du triage ensemble, pas d'un seul chiffre sur un tableau de bord. La vitesse de détection se gagne sur l'ensemble du pipeline.