MTTD : pourquoi le temps que vous mettez à voir l'incident vous expose

Les ingénieurs SRE pilotent leur fiabilité avec un tableau de bord d'acronymes : SLO, SLI, MTTR, MTBF. Parmi eux, le MTTD (Mean Time To Detect, temps moyen de détection) est souvent traité comme une simple métrique d'observabilité. C'est une erreur d'appréciation. Le MTTD n'est pas qu'un indicateur de performance : c'est un facteur direct d'exposition juridique et financière.

La logique est implacable. Un incident commence à un instant T0. Tant qu'il n'est pas détecté, il continue de produire des dégâts : transactions perdues, données corrompues, ou pire, intrusion qui exfiltre des données. Chaque minute de retard de détection est une minute de préjudice supplémentaire. Le MTTD est le multiplicateur du dommage.

Et quand un client cherche à établir votre responsabilité, la première question de son expert sera : combien de temps a-t-il fallu pour détecter l'incident, et ce délai était-il conforme aux règles de l'art ? Un MTTD anormalement élevé devient un indice de manquement à votre obligation de moyens.

Il faut bien distinguer deux phases souvent confondues. Le MTTR (Mean Time To Repair) mesure votre capacité à réparer une fois l'incident connu : c'est la partie visible, celle dont on est fier quand elle est basse. Le MTTD, lui, mesure votre capacité à savoir qu'un problème existe. Un MTTR excellent ne sert à rien si le MTTD est mauvais : vous réparez vite, mais vous avez laissé l'incident saigner pendant des heures avant de le voir. Or, dans un contentieux, c'est ce temps aveugle qui sera scruté, parce qu'il révèle un trou dans votre dispositif d'observabilité, c'est-à-dire dans le cœur même de votre prestation.

Tous les incidents non détectés ne se valent pas. Selon ce que le monitoring rate, l'exposition diffère radicalement.

Scénario 1 : downtime non détecté

Une fuite mémoire dégrade progressivement un service. Le monitoring, mal calibré, ne déclenche pas d'alerte avant le crash complet. Résultat : plusieurs heures de service dégradé puis indisponible. Le préjudice est un downtime classique, lourd mais borné.

Scénario 2 : corruption silencieuse

Un bug propage des données erronées sans déclencher d'erreur visible. Le monitoring ne surveille que la disponibilité, pas l'intégrité. Quand la corruption est découverte, elle a contaminé des jours de données. Le préjudice est plus insidieux : restauration complexe et perte de confiance.

Scénario 3 : intrusion non détectée

Le pire. Un monitoring de disponibilité ne voit pas une exfiltration de données en cours. Un attaquant a un accès prolongé. Quand l'intrusion est détectée — souvent par un tiers — des milliers de données personnelles ont fuité. On bascule alors du préjudice technique au sinistre cyber et à la violation RGPD.

En droit de la responsabilité, l'ingénieur SRE doit mettre en œuvre les moyens qu'un professionnel diligent aurait déployés. L'observabilité n'est plus une option : c'est le cœur du métier. Un monitoring qui ne couvre que la disponibilité, en ignorant l'intégrité et la sécurité, peut être qualifié de défaillant au regard de l'état de l'art.

Dans le scénario d'intrusion, l'enjeu se durcit encore. Le RGPD impose au responsable de traitement de notifier toute violation de données à la CNIL dans les 72 heures après en avoir pris connaissance. Or, on ne peut pas notifier ce qu'on n'a pas détecté. Un MTTD de plusieurs semaines sur une intrusion signifie :

• une violation RGPD prolongée et aggravée ;
• un risque de sanction de la CNIL pour le client ;
• une mise en cause directe du prestataire SRE dont le monitoring a failli.

On ne reproche pas à un SRE qu'un incident survienne. On lui reproche de ne pas l'avoir vu venir alors que les moyens existaient.

Le délai de détection est ainsi devenu, dans les contentieux numériques, un point d'examen central de la diligence professionnelle.

La détection tardive expose à deux familles de préjudices qui appellent deux garanties différentes.

Le préjudice business : la RC Pro

Pour les scénarios de downtime et de corruption, c'est l'assurance RC Pro qui intervient. Elle couvre les dommages immatériels (perte de CA, restauration, pénalités SLA) résultant d'un monitoring défaillant ou d'un incident raté, ainsi que vos frais de défense.

Le préjudice sécurité : la garantie cyber

Le scénario d'intrusion non détectée déborde le cadre classique. Les frais de notification RGPD, l'expertise forensique, la gestion de crise, les éventuelles réclamations de personnes dont les données ont fuité relèvent d'une assurance cyber. C'est précisément pourquoi un ingénieur SRE a tout intérêt à coupler RC Pro et option cyber : un même incident de détection tardive peut basculer du registre business au registre sécurité.

Cette double couverture reflète la réalité du métier : le SRE est à la fois garant de la performance et sentinelle de la sécurité. La frontière entre les deux est floue dans la pratique quotidienne — une même sonde mal configurée peut rater aussi bien une fuite mémoire qu'une exfiltration — mais elle est nette dans les polices d'assurance. Souscrire l'une sans l'autre, c'est laisser ouvert tout un pan de votre exposition.

Un exemple concret de cette zone grise : un pic de trafic sortant inhabituel. Pour un monitoring de performance, c'est peut-être une simple anomalie de charge à investiguer. Pour un dispositif de sécurité, c'est le signal potentiel d'une exfiltration en cours. Le même événement, deux lectures, deux régimes de responsabilité et deux garanties. C'est pourquoi le couplage n'est pas un luxe mais la traduction assurantielle exacte de ce que recouvre le métier de SRE. Découvrez les garanties adaptées à votre profil sur la page assurance ingénieur SRE.

Réduire le MTTD protège vos clients et, accessoirement, votre responsabilité. Quelques principes structurants :

• Monitorer l'intégrité, pas seulement la disponibilité : des contrôles de cohérence des données détectent les corruptions silencieuses.
• Instrumenter la sécurité : détection d'anomalies, alertes sur les accès inhabituels, surveillance des volumes de sortie pour repérer une exfiltration.
• Alertes actionnables : trop d'alertes tuent l'alerte. Un système d'astreinte noyé sous le bruit augmente le MTTD réel.
• Tester les chaînes d'alerte via le chaos engineering : une alerte qui ne part pas le jour J est pire que pas d'alerte.

Mais aussi rigoureux soit votre dispositif, le risque zéro n'existe pas. Une sonde tombe, une alerte se perd, un signal faible passe inaperçu. C'est la part irréductible que l'assurance prend en charge. Un ingénieur SRE qui optimise son MTTD et s'assure correctement aborde son astreinte l'esprit tranquille : il a fait le maximum côté technique, et il est couvert pour le reste.

Pour résumer la logique d'ensemble : le MTTD est le multiplicateur du dommage, la nature de l'incident manqué détermine quel régime de responsabilité s'applique, et la combinaison RC Pro + cyber couvre l'éventail complet des conséquences. Un SRE qui intègre ces trois niveaux de lecture ne voit plus le MTTD comme une simple ligne de dashboard, mais comme un véritable indicateur de son exposition. C'est cette grille de lecture, autant que les sondes et les alertes, qui distingue un professionnel pleinement conscient de son risque d'un technicien qui se croit à l'abri jusqu'au jour du litige.