MTTR : la métrique qui sauve vos nuits

On ne peut pas empêcher toutes les pannes — mais on peut apprendre à s'en remettre vite. Tour d'horizon du MTTR : ce qu'il mesure, comment le calculer honnêtement, comment le réduire, et pourquoi il ne faut surtout pas en faire un KPI aveugle.

Il est 3 heures du matin, une alerte se déclenche, et la seule question qui compte n’est pas « pourquoi ça a cassé ? » mais « dans combien de temps est-ce réparé ? ». Vouloir empêcher toutes les pannes est une illusion : les systèmes complexes finissent toujours par tomber. La vraie mesure de maturité d’une équipe n’est donc pas sa capacité à ne jamais échouer, mais sa capacité à se rétablir vite. C’est ce que mesure le MTTR — à condition de savoir le lire.

Cet article se lit à deux niveaux. Le fil principal suffit pour découvrir le sujet ; les encarts « Pour aller plus loin » ajoutent la profondeur utile à qui pratique déjà l’exploitation au quotidien.

I. Le vrai problème : on ne peut pas tout empêcher  

Pendant longtemps, la fiabilité s’est pensée comme l’absence de panne : plus un système tombe rarement, meilleur il est. Cette vision a une limite fatale — elle suppose qu’on puisse tout prévoir. Au-delà d’une certaine complexité, les modes de défaillance deviennent innombrables, et la prochaine panne viendra d’un endroit que personne n’avait anticipé.

D’où un changement de perspective, au cœur de la culture SRE : puisqu’on ne peut pas éliminer les pannes, il faut optimiser la récupération. Comparez deux services sur une année :

• Service A : tombe 1 fois, mais reste à terre 8 heures. Indisponibilité : 8 h.
• Service B : tombe 12 fois, mais se répare en 5 minutes. Indisponibilité : 1 h.

Du point de vue de l’utilisateur, le service B — pourtant douze fois plus « fragile » — est huit fois plus fiable. C’est ce déplacement du regard, de l’évitement vers le rétablissement, que le MTTR met en chiffres.

Pour aller plus loin. C’est aussi le fondement des error budgets : un SLO (Service Level Objective) de 99,9 % accorde ~43 min d’indisponibilité par mois. Tant que le budget n’est pas épuisé, on privilégie la vélocité ; quand il l’est, on gèle les livraisons et on investit la fiabilité. Le MTTR devient alors le levier qui permet de « tenir » le budget malgré des incidents plus fréquents.

II. MTTR, c’est quoi exactement ?  

MTTR signifie Mean Time To Recovery (temps moyen de rétablissement). C’est le temps moyen entre le début d’un incident et le retour à la normale du service.

Le MTTR ne vit pas seul. Il fait partie d’une famille de métriques qui suivent la chronologie d’un incident :

 panne          détection      prise en charge     service rétabli     cause corrigée
   │                │                 │                   │                   │
   └── MTTD ────────┤                 │                   │                   │
                    └──── MTTA ───────┤                   │                   │
                                      └──── diagnostic ───┴──── réparation ───┘
   └──────────────────────── MTTR (rétablissement) ──────────────────────────┘

La distinction clé : le MTBF mesure la fréquence des pannes (à quel point on les évite), le MTTR mesure la rapidité de récupération (à quel point on les encaisse). Ensemble, ils décrivent la fiabilité réelle — mais le MTTR est celui sur lequel on a le plus de prise à court terme.

Pour aller plus loin. Le « R » de MTTR est piégeux : selon les équipes il désigne Recovery, Repair, Resolve ou Respond — et ce ne sont pas les mêmes bornes. Distinguez surtout le rétablissement du service (le client ne subit plus rien — souvent un rollback ou un contournement) de la résolution de la cause racine (le vrai correctif, parfois des jours plus tard). Mesurer l’un en croyant mesurer l’autre fausse tout. Fixez la convention à l’avance : la plupart des équipes matures pilotent le temps de mitigation (service rétabli), pas la résolution complète.

III. Comment le calculer (et pourquoi la moyenne ment)  

Le calcul de base est simple :

MTTR = temps d'indisponibilité total / nombre d'incidents

Sur un mois avec 4 incidents pour 2 heures d’indisponibilité au total, le MTTR est de 30 minutes.

Mais voici le piège, et il est majeur : la moyenne ment. Prenons sept incidents, en minutes :

5, 6, 7, 8, 10, 12, 240

• Moyenne (MTTR) : 288 / 7 ≈ 41 minutes
• Médiane : 8 minutes

Aucun incident n’a duré 41 minutes. La moyenne décrit un incident qui n’existe pas, entièrement tirée par le cas à 240 minutes. C’est la règle plutôt que l’exception : les durées de rétablissement sont à queue lourde — beaucoup de cas courts, quelques monstres qui écrasent la moyenne.

Pour cette raison, ne regardez jamais le MTTR seul :

• Suivez la distribution : médiane et percentiles (p50, p90) racontent une histoire bien plus honnête que la moyenne.
• Regardez la tendance dans le temps, pas la valeur absolue : baisse-t-elle d’un trimestre à l’autre ?
• Méfiez-vous des petits volumes : avec 3 incidents, aucune moyenne ne veut dire quoi que ce soit.

Pour aller plus loin. Le rapport VOID (Verica Open Incident Database, Courtney Nash) a montré, sur des milliers d’incidents réels, que les durées suivent une distribution proche du log-normal, à très forte variance — au point que la moyenne et l’écart-type ne sont statistiquement pas des résumés valides. L’étude relève aussi une corrélation faible entre fréquence et durée des incidents. Conclusion pratique : traitez le MTTR comme un signal d’apprentissage interne (regardez la forme de la distribution et ses valeurs extrêmes), jamais comme un KPI de pilotage ou un engagement contractuel. Ce qui vous apprend le plus, ce ne sont pas les incidents médians — ce sont les queues.

IV. Décomposer le MTTR pour le comprendre  

Un MTTR n’est pas un bloc : c’est une chaîne d’étapes, et chacune est un levier distinct.

1. Détecter — le temps que le problème soit repéré (par le monitoring ou, au pire, par un client mécontent).
2. Alerter et prendre en charge — le temps qu’un humain soit prévenu et commence à agir.
3. Diagnostiquer — souvent la phase la plus longue : comprendre ce qui casse et pourquoi.
4. Réparer — appliquer le correctif ou le contournement.
5. Rétablir — vérifier que le service est réellement revenu à la normale.

L’intérêt est immense : cette décomposition transforme un chiffre flou en cibles précises. Un MTTR plombé par une détection tardive ne se soigne pas comme un MTTR plombé par des diagnostics interminables. Instrumentez chaque segment (horodatez détecté / pris en charge / mitigé / résolu dans votre outil d’incident) et vous saurez exactement où investir.

Pour aller plus loin. Dans la plupart des organisations, la phase dominante n’est pas la réparation mais le diagnostic — et son coût est directement corrélé à la qualité de l’observabilité et à la répartition de la connaissance opérationnelle. Un système où une seule personne sait lire les symptômes a un MTTR de diagnostic qui explose dès qu’elle est absente. Réduire le MTTR est donc autant un problème de transmission du savoir que de l’ usage des outils.

V. Les leviers pour réduire le MTTR  

Chaque étape de la chaîne a ses remèdes concrets :

• Réduire la détection → une observabilité solide (métriques, logs, traces via OpenTelemetry, tableaux de bord Grafana/Datadog) et surtout des alertes branchées sur les bons symptômes.
• Réduire la prise en charge → une astreinte outillée (PagerDuty, Opsgenie…), avec rotations saines et politique d’escalade sans ambiguïté.
• Réduire le diagnostic → des runbooks testés qui mènent d’un symptôme à des actions, des dashboards lisibles, du tracing distribué, et une connaissance opérationnelle partagée plutôt que concentrée.
• Réduire la réparation → l’automatisation de la récupération : rollback en un clic, déploiements canary/blue-green, feature flags et kill switches pour désactiver un composant fautif sans redéployer.
• Apprendre pour la prochaine fois → des postmortems sans blâme qui transforment chaque incident en garde-fou durable — donc en MTTR plus court la fois suivante.

Pour aller plus loin. Deux pratiques changent radicalement la donne. D’abord, alerter sur le burn rate d’un SLO (approche multi-fenêtre / multi-taux de Google) plutôt que sur des seuils statiques : moins de bruit, détection plus juste, donc MTTD plus bas. Ensuite, la livraison progressive (canary + rollback automatique déclenché par les métriques) : elle rend la réparation quasi instantanée et souvent sans intervention humaine — le meilleur MTTR est celui qu’un humain n’a même pas eu à gérer. Enfin, entraînez la chaîne à froid via des game days : un runbook jamais testé est une fiction.

Le meilleur moment pour réduire son MTTR, c’est quand tout va bien. Aucun de ces leviers ne s’improvise en pleine panne.

VI. MTTR et disponibilité : la formule qui relie tout  

Pourquoi tant d’attention au MTTR ? Parce qu’il pèse directement sur la disponibilité, au même titre que la fréquence des pannes :

Disponibilité = MTBF / (MTBF + MTTR)

On améliore donc sa disponibilité de deux façons : tomber moins souvent (MTBF ↑) ou se relever plus vite (MTTR ↓). Pour la plupart des équipes, réduire le MTTR est le levier le plus rapide et le moins coûteux — agir sur des pannes qu’on subit déjà est plus accessible qu’éliminer des pannes qu’on n’a pas encore vues.

Ce que « bien se relever » signifie en temps d’indisponibilité toléré :

Diviser son MTTR par deux, c’est diviser par deux le temps où les utilisateurs sont impactés — sans avoir à rendre le système parfait.

Pour aller plus loin. Cette formule est une simplification : elle suppose des pannes indépendantes et des durées régulières, ce qui, on l’a vu, est faux. En pratique, on ne pilote pas la disponibilité avec MTBF/(MTBF+MTTR) mais avec un SLO mesuré sur une fenêtre glissante (par ex. 99,9 % sur 28 jours) et son error budget. La formule reste un excellent outil de raisonnement ; ce n’est pas un instrument de mesure.

VII. Mesurer le MTTR sans se mentir  

• Confondre moyenne et réalité. La queue lourde rend la moyenne trompeuse : toujours croiser médiane et percentiles.
• Maquiller la métrique. Dès qu’un chiffre devient un objectif, on est tenté de le manipuler : clore un incident « techniquement résolu » alors que des utilisateurs sont encore impactés, ne compter que les « vraies » pannes, ou requalifier un incident en « dégradation ». Un MTTR embelli ne sauve aucune nuit.
• Optimiser le MTTR au détriment du reste. Rétablir vite en cachant la poussière sous le tapis (un redémarrage qui masque le bug) fait revenir la panne. Vitesse de récupération ne veut pas dire bâclage.
• En faire un KPI ou un SLA. C’est le piège du senior. Vu sa variance, le MTTR est un mauvais objectif contractuel et une cible facile à gamer (loi de Goodhart : « quand une mesure devient une cible, elle cesse d’être une bonne mesure »).

Pour aller plus loin. Alors, faut-il jeter le MTTR ? Non — mais changez son usage. Utilisez-le en interne, pour apprendre, en regardant la distribution et les incidents extrêmes, jamais comme KPI affiché ni engagement client. Et complétez-le par des mesures moins manipulables : le nombre d’incidents, le pourcentage d’incidents dépassant un seuil (p. ex. « 90 % rétablis en < 30 min »), et surtout l’impact réel — les user-minutes affectées, qui pondèrent la durée par le nombre d’utilisateurs touchés. Un incident de 4 h à 3 h du matin sur un service secondaire n’a pas le poids d’un incident de 10 min en pleine journée sur le paiement.

VIII. Par où commencer  

Si vous débutez sur le sujet :

1. Horodatez vos incidents (début, détection, prise en charge, rétablissement).
2. Calculez la médiane de rétablissement sur quelques mois — pas la moyenne.
3. Écrivez un premier runbook pour votre panne la plus fréquente.
4. Regardez laquelle des étapes (détecter / diagnostiquer / réparer) vous coûte le plus, et attaquez celle-là.

Si vous pilotez déjà l’exploitation :

1. Passez vos alertes en SLO burn rate pour faire baisser le MTTD.
2. Rendez le rollback trivial et, si possible, automatique (livraison progressive).
3. Suivez la distribution du MTTR et les user-minutes, pas une moyenne unique.
4. Éprouvez la chaîne complète par un game day trimestriel.

Conclusion  

Le MTTR acte un renversement salutaire : la fiabilité ne consiste pas à ne jamais tomber, mais à se relever vite. C’est une métrique humble — elle admet que les pannes arriveront — et profondément utile tant qu’on la lit correctement : en distribution plutôt qu’en moyenne, comme signal d’apprentissage plutôt que comme trophée.

Retenez l’essentiel : un bon MTTR ne se décrète pas en pleine panne, il se prépare à froid. Observabilité, runbooks, astreinte saine, rollback automatisé, postmortems : chaque brique posée quand tout va bien est une nuit de sommeil gagnée quand tout ira mal.

Useful links  

• Google SRE Book — Service Level Objectives
  Le cadre SRE de la fiabilité : SLI, SLO, error budgets et la place des métriques de récupération.

• Google SRE Workbook — Alerting on SLOs (burn rate)
  La méthode d’alerting multi-fenêtre / multi-burn-rate, levier direct de réduction du MTTD.

• Atlassian — Incident metrics: MTTR, MTBF, MTTA, MTTF
  Un panorama clair des métriques d’incident, leurs définitions et leurs différences.