Les équipes de sécurité ne peuvent améliorer leur temps de réponse tant qu’elles ne se sont pas mises d’accord sur le moment où celle-ci commence et s’achève. Dans son analyse de 2026, Mandiant a constaté que l’intervalle médian entre l’accès initial et le transfert à un acteur secondaire était passé de plus de huit heures en 2022 à 22 secondes en 2025. Bien que ce chiffre mesure le transfert entre attaquants plutôt que le temps de réponse du SOC, il montre pourquoi le temps moyen de réponse (MTTR) devrait prendre en compte le délai décisionnel entre une détection hautement fiable et un confinement vérifié, et non pas simplement la rapidité avec laquelle un ticket est clôturé.
Qu'est-ce que le temps moyen de réponse ?
Le délai moyen de réponse, communément appelé MTTR, mesure le temps nécessaire à une équipe de sécurité pour passer de la détection d'une menace confirmée ou hautement probable à la maîtrise vérifiée du risque associé. Il est particulièrement utile lorsqu'il reflète le temps pendant lequel un attaquant peut encore agir, plutôt que la durée pendant laquelle un ticket reste ouvert.
Bien utilisé, le MTTR met en évidence les délais de prise de décision. Mal utilisé, il encourage la clôture rapide des tickets alors que la menace persiste.
Définissez la fréquence de réponse avant de la calculer
Il n'existe pas de formule universelle pour calculer le MTTR, car les équipes se basent sur des événements de début et de fin différents. Une définition utile doit être cohérente, vérifiable et liée à la réduction des risques.
Pour la plupart des rapports SOC, lancez le chronomètre lorsqu’un analyste qualifié ou un workflow de détection identifie un incident de sécurité présentant un niveau de confiance élevé et nécessitant une intervention. Arrêtez-le lorsque l’équipe vérifie que la voie d’attaque immédiate a été maîtrisée, par exemple en désactivant une identité compromise, en isolant un hôte, en bloquant une session malveillante ou en révoquant des identifiants exposés.
| Décision |
Définition recommandée |
Pourquoi est-ce important ? |
| Lancer l'événement |
Détection à haut niveau de confiance acceptée pour traitement |
Cela évite de pénaliser les équipes pour des alertes brutes et de mauvaise qualité. |
| Événement d'arrêt |
Confinement vérifié du risque actif |
Cette indicatrice vise à limiter les possibilités d'attaque. |
| Inclure |
Incidents confirmés et cas avérés ayant nécessité une intervention |
Donne tout son sens à la population. |
| Exclure, mais suivre séparément |
Alertes de test, doublons, faux positifs classés sans suite et dossiers en attente de décisions non liées à l'activité |
Empêche le bruit de fonctionnement d'altérer le chiffre. |
| Signaler également |
Médiane, P90, gravité, environnement et type d'action |
Montre un comportement typique et une fin de course difficile. |
N’utilisez pas la clôture définitive d’un ticket comme événement de fin, sauf si celle-ci correspond de manière fiable à une résolution vérifiée du problème. La clôture peut inclure la documentation, les travaux de remise en état, les enseignements tirés ou d’autres tâches qui doivent être évaluées séparément.
Comment calculer le MTTR ?
Pour une période de référence donnée :
MTTR = durée totale entre l'événement de départ choisi et la maîtrise vérifiée ÷ nombre d'incidents pris en compte
Par exemple, si 20 incidents pris en compte ont nécessité au total 100 heures entre leur détection par un intervenant qualifié et leur maîtrise vérifiée, le MTTR est de cinq heures. Le calcul est simple. La rigueur réside dans l'utilisation systématique des mêmes définitions d'événements, des mêmes règles d'inclusion et des mêmes sources de données à chaque fois.
Ne vous contentez pas d'indiquer la moyenne. Quelques incidents complexes peuvent la faire grimper en flèche, tandis qu'une moyenne apparemment satisfaisante peut masquer un groupe dangereux de dossiers qui traînent en longueur. Un tableau de bord pratique comprend :
- MTTR moyen, médian et P90.
- MTTR par niveau de gravité, type d'incident, environnement et unité opérationnelle.
- Pourcentage de cas s'inscrivant dans l'objectif de service défini par l'organisation.
- Temps consacré au triage, à l'analyse, à la validation, à l'exécution et à la vérification.
- Une liste des cas atypiques, avec la raison du retard.
Cette approche permet de transformer un chiffre clé en indication des points du processus qui nécessitent une attention particulière. Les équipes doivent replacer le MTTR dans un ensemble plus large d'indicateurs de cybersécurité afin que la rapidité d'intervention soit évaluée parallèlement à la détection, à l'enquête, à la correction et à la reprise.
MTTR et indicateurs de sécurité associés
Le MTTR est souvent utilisé de manière incohérente. Il convient de définir pour chaque indicateur une délimitation d'événement distincte afin que les dirigeants ne confondent pas une détection plus rapide avec une maîtrise plus rapide de la situation.
| Métrique |
Ce qu'il mesure |
Utilisation recommandée |
| Temps moyen de détection (MTTD) |
Compromission ou détection d'une activité suspecte |
Évaluer la visibilité et l'efficacité de la détection. |
| Durée moyenne d'investigation (MTTI) |
De la détection à une conclusion fondée sur des preuves |
Identifier les goulots d'étranglement dans les enquêtes. |
| Temps moyen de réponse (MTTR) |
Détection fiable pour un confinement vérifié |
Mesurer la rapidité avec laquelle le risque actif est maîtrisé. |
| Temps moyen de maîtrise de l'incident (MTTC) |
Une mesure spécifique au confinement, étroitement liée à ce dernier |
À utiliser lorsque l'événement d'arrêt est explicitement de type « confinement ». |
| Durée moyenne de la remise en état |
Maîtrise de la situation, élimination de la cause première et mise en place de mesures correctives durables |
Suivre l'évolution de la réduction des risques à long terme. |
| Durée moyenne de récupération |
Impact de l'incident sur le retour à la normale des opérations |
Suivre la reprise des activités et des services. |
Cette distinction reflète le cycle de vie décrit dans les recommandations du NIST en matière de réponse aux incidents, ainsi que les fonctions « Détection », « Réponse » et « Récupération » du Cadre de cybersécurité 2.0 du NIST. Elle permet également d’identifier le véritable problème. Un temps de réponse trop long peut être dû à une enquête trop lente, à un manque de clarté concernant les compétences en matière d’autorisation ou à un processus de confinement peu fiable.
Pour une vue d'ensemble du processus, consultez la section « Réponse aux incidents ». Pour en savoir plus sur la phase de collecte des preuves, consultez la section « Enquête sur les incidents ».
Pourquoi un bon MTTR n'est pas une valeur universelle
Un MTTR de deux heures n'est pas nécessairement meilleur qu'un MTTR de huit heures. Une équipe chargée de gérer une compromission d'identité vérifiée et de haute gravité peut avoir besoin de davantage de validation et de coordination qu'une équipe chargée de bloquer un domaine malveillant connu. La diversité des niveaux de gravité, la couverture télémétrique, les exigences en matière de contrôle des changements, les systèmes critiques pour l'activité et les définitions des incidents sont autant de facteurs qui influencent le résultat.
Comparez le MTTR au fil du temps au sein d'un même cadre de mesure. Segmentez les données avant de comparer les équipes ou les environnements. Examinez ensuite la queue de la distribution : c'est souvent au niveau du P90 que les autorisations manquantes, les procédures d'escalade floues ou les transferts manuels apparaissent.
La détection doit également être évaluée séparément. Mandiant a indiqué que la durée médiane de présence des menaces à l’échelle mondiale était passée de 11 à 14 jours en 2025, tandis que les entreprises avaient détecté pour la première fois des indices en interne dans 52 % de ses enquêtes, contre 43 % en 2024. Ces chiffres ne constituent pas des références en matière de réponse, mais ils montrent pourquoi un processus de confinement rapide ne peut pas compenser un déficit de détection.
Comment réduire le MTTR sans mettre en place une automatisation présentant des risques pour la sécurité
L'objectif est de réduire le temps dont dispose un attaquant pour agir, tout en conservant un bon discernement. Commencez par identifier l'étape qui prend le plus de temps.
- Mettez en place un processus de travail. Enregistrez les horodatages relatifs à la qualification, à la responsabilité, à l'enquête, à la validation, à l'action et à la vérification. Ne tirez pas de conclusions sur les retards en vous basant uniquement sur le statut du ticket. Des processus opérationnels SOC clairs permettent d'identifier plus facilement ces transferts de responsabilité et ces lacunes en matière de responsabilité.
- Donnez la priorité aux signaux d'attaque présentant un niveau de fiabilité élevé. Un contexte plus précis aide les analystes à identifier les cas nécessitant une intervention immédiate et réduit le temps consacré à la validation des alertes en double ou sans importance.
- Préautoriser les mesures de confinement proportionnées. Définir quelles mesures peuvent être prises immédiatement, qui est habilité à approuver les mesures ayant un impact plus important, et comment les joindre en dehors des heures de bureau.
- Automatisez les étapes limitées et réversibles. Enrichissez les cas, recueillez des informations contextuelles, créez des tickets ou restreignez temporairement une session lorsque le niveau de confiance et les mesures de sécurité sont suffisants. Soumettez les actions irréversibles ou susceptibles de perturber l'activité à un examen approprié.
- Examinez les cas atypiques. Chaque cas présentant un retard inhabituel doit permettre d'identifier une cause maîtrisable, telle que l'absence de données télémétriques, une ambiguïté quant à la responsabilité, une file d'attente d'approbation ou un transfert entre outils.
Pour obtenir des conseils de mise en œuvre une fois le modèle de mesure en place, consultez la section consacrée à l’automatisation de la réponse aux incidents. Les équipes qui souhaitent améliorer la hiérarchisation des priorités entre les différents domaines et le workflow de réponse peuvent également consulter le cas d’utilisation « Détection et réponse aux menaces » disponible sur Vectra AI.
Le point de vue de l'Vectra AI
Le MTTR s'améliore lorsque les intervenants sont en mesure de déterminer rapidement quels signaux indiquent une attaque en cours, où celle-ci se propage et quelles mesures il convient de prendre. L'« Vectra AI » aide les équipes de sécurité à coordonner la détection des menaces, les enquêtes et les interventions à travers les environnements réseau, d'identité et d'cloud , favorisant ainsi un processus d'intervention plus éclairé. Cet indicateur reste l'outil de gouvernance de l'équipe : il permet de définir ses limites, d'analyser ses valeurs aberrantes et de s'en servir pour améliorer la prise de décision plutôt que de se contenter d'accélérer la résolution des incidents.
