Le MTTR est l’indicateur d’exploitation le plus cité et le moins défini. Deux équipes qui annoncent « quatre heures » parlent rarement de la même chose. Chez un opérateur d’infrastructure, ce chiffre finit souvent dans un rapport envoyé aux clients. Avant de chercher à le réduire, il faut le mesurer d’une façon qu’un client hébergé ou un responsable d’exploitation puisse vérifier.
Un sigle, quatre définitions
| Lecture | Ce qu’on mesure | Fin de l’horloge |
|---|---|---|
| Mean time to respond | Le délai avant que quelqu’un commence à agir | Prise en charge |
| Mean time to recover | Le délai avant que le service soit à nouveau rendu | Rétablissement du service |
| Mean time to repair | Le délai avant que le composant soit réparé | Remise en état du composant |
| Mean time to resolve | Le délai avant que la cause soit traitée et le dossier clos | Clôture du ticket |
Pour un même incident, ces quatre durées peuvent aller de dix minutes à trois semaines. Aucune n’est fausse. Ce qui est faux, c’est de ne pas écrire laquelle on utilise.
Recommandation : retenez recover comme indicateur principal, parce que c’est celui que vivent les utilisateurs, et suivez respond à côté, parce qu’il révèle les problèmes d’organisation. Gardez resolve pour la gestion des problèmes, pas pour le pilotage quotidien.
Les deux bornes à fixer par écrit
Le départ. Trois candidats : le début réel de l’impact, la détection par la supervision, le signalement par un utilisateur. Le début réel est souvent inconnu au moment des faits. Choisissez la détection comme borne de référence, et notez l’écart avec le début réel quand vous le découvrez : cet écart est votre temps de détection, un indicateur à part entière.
L’arrivée. Le service est-il rétabli quand la supervision repasse au vert, quand l’équipe le déclare, ou quand un utilisateur le confirme ? Choisissez une règle et appliquez-la toujours la même. La supervision au vert est la plus objective, à condition qu’elle mesure le service et non le serveur.
Écrivez ces deux règles dans une page que tout le monde peut lire. Le jour où un chiffre sera contesté, cette page sera votre seule défense.
Pourquoi la moyenne ment
Les durées d’incident ne se répartissent pas autour d’une valeur centrale. La plupart se règlent vite ; quelques-unes durent des jours. Sur un trimestre, un seul incident de 72 heures suffit à multiplier la moyenne par plus de dix et à masquer vingt incidents réglés en vingt minutes. À l’inverse, un trimestre calme donne une moyenne flatteuse qui ne prépare à rien.
Remplacez la moyenne par deux chiffres :
- la médiane, qui montre l’incident typique ;
- le 90e centile, qui montre à quoi ressemblent vos mauvais jours.
Le rapport « Incident Metrics in SRE » de Štěpán Davidovič, publié par Google, arrive à la même conclusion par simulation. Des métriques fondées sur la moyenne, MTTR compris, il écrit que « ces statistiques se prêtent mal à la prise de décision ou à l’analyse de tendance dans le contexte des incidents de production » (traduit de l’anglais).
Et segmentez par gravité. Un MTTR global mélange une imprimante et un cœur de réseau. Il ne sert à rien.
D’où viennent les horodatages
Un MTTR vérifiable repose sur des heures produites par des outils au moment des faits :
- l’alerte de supervision, pour la détection ;
- la prise en charge dans l’outil de suivi, pour la réponse ;
- le retour au vert de la supervision, pour le rétablissement ;
- la clôture du ticket, pour la résolution.
Si l’un de ces événements n’est pas horodaté automatiquement, le chiffre correspondant est une estimation. Il faut le dire. Vérifiez aussi que la supervision et l’outil de suivi partagent la même référence de temps, à la seconde près. Sinon, corrigez cela avant tout le reste : c’est la cause la plus fréquente d’un MTTR négatif dans un tableau de bord.
Décomposer avant d’améliorer
Un temps de rétablissement est une somme. Mesurez les morceaux :
| Étape | Du | Au | Ce qui l’allonge |
|---|---|---|---|
| Détection | Début de l’impact | Alerte | Supervision qui mesure les serveurs et pas les services |
| Réponse | Alerte | Prise en charge | Alerte sans propriétaire, astreinte mal routée |
| Diagnostic | Prise en charge | Cause identifiée | Inventaire périmé, dépendances inconnues |
| Correction | Cause identifiée | Action terminée | Accès manquants, changement non préparé |
| Vérification | Action terminée | Service confirmé | Pas de contrôle de service, retour au vert supposé |
Dans beaucoup d’exploitations, le morceau le plus long n’est pas la correction. C’est le diagnostic : trouver ce qui est touché, ce qui en dépend et qui doit intervenir. Ce temps-là ne se réduit pas avec des techniciens plus rapides. Il se réduit avec un inventaire que l’exploitation tient à jour.
Le MTTR que voient vos clients
Pour un hébergeur, un opérateur de datacenters ou un opérateur réseau, le MTTR ne reste pas dans l’équipe. Il apparaît dans les rapports de niveau de service, et il est lu par des clients qui ont vécu l’incident de leur côté.
Trois règles évitent la plupart des désaccords :
- la même définition que le contrat, écrite dans le rapport lui-même, pas seulement en annexe ;
- un chiffre par client ou par service, car un MTTR global du parc ne dit rien au client dont la baie est restée hors service six heures ;
- chaque durée rattachée à ses horodatages, pour qu’un client qui conteste puisse retrouver l’alerte, la prise en charge et le retour au vert.
C’est aussi ce qui rend la revue d’incident utile : une chronologie sourcée ligne par ligne sert à la fois au rapport client et à la recherche de cause. Voir comment rédiger un post-mortem à partir des traces.
En résumé
Un MTTR défendable, c’est : une définition écrite (laquelle des quatre), deux bornes fixées (détection, service rétabli), des horodatages d’outils, une médiane et un 90e centile par gravité, et une décomposition par étape. Tout le reste est une impression chiffrée.
Une fois ces horodatages en place, reconstituer la chronologie d’un incident devient un travail répétitif qu’un script fait en grande partie. C’est un circuit que Hopwise Labs inscrit dans vos outils, avec votre accord avant tout envoi.
Questions fréquentes
MTTR signifie quoi, exactement ?
Le sigle recouvre quatre lectures : mean time to repair (réparer le composant), to recover (rétablir le service), to resolve (traiter la cause, ticket clos), to respond (commencer à agir). Elles donnent des chiffres très différents pour le même incident. La seule erreur est de ne pas dire laquelle on utilise.
Quelle est la bonne valeur de MTTR ?
Il n’y en a pas. Un MTTR se compare à lui-même dans le temps, par niveau de gravité, et à l’engagement pris envers les utilisateurs. Un chiffre isolé, sans définition ni périmètre, ne dit rien.
Pourquoi utiliser la médiane plutôt que la moyenne ?
Parce que la distribution des durées d’incident a une longue traîne : la plupart se règlent vite, quelques-uns durent des jours. Un seul incident long fait grimper la moyenne du trimestre et masque le fonctionnement normal. La médiane montre l’incident typique, le 90e centile montre les mauvais jours.
Peut-on inscrire un MTTR dans un engagement de service ?
Oui, à condition que le contrat dise laquelle des quatre définitions s’applique, où commence et où s’arrête l’horloge, et pour quelles gravités. Sans ces trois précisions, l’engagement se renégocie à chaque incident.
Peut-on calculer le MTTR sans outil de ticketing ?
On peut le reconstituer une fois, pas le mesurer durablement. La mesure demande des horodatages produits par les outils au moment des faits : alerte de supervision, prise en charge, rétablissement, clôture. Sans eux, on mesure des souvenirs.