MTTR

MTTR : Durée moyenne de rétablissement après un incident, indicateur qui reflète la qualité de l’outillage et de l’organisation d’astreinte.

Cette entrée du glossaire relève de la famille « Technique ». Elle donne la définition, sa traduction en exigences, et les erreurs vues le plus souvent sur des projets réels.

Pourquoi MTTR compte sur un projet mobile

MTTR se manifeste quand le réseau est mauvais, quand la charge monte ou quand l’application tourne en arrière-plan. Ce sont exactement les moments qu’une recette en salle de réunion ne reproduit pas.

Ce que le mot recouvre exactement dépend du projet. Ce qui suit vaut pour la plupart des applications mobiles françaises, et sert de point de départ à la discussion.

Ce que ça devient dans un cahier des charges

Un cahier des charges sérieux relie « MTTR » à un critère de recette : une phrase que l’on peut cocher ou refuser, pas une intention.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les intégrations tierces, nommées, avec leur documentation et leurs limites d’appel.
• La sauvegarde des données : fréquence, durée de rétention, restauration réellement testée.
• La supervision : quelles alertes, vers qui, sous quel délai d’intervention.
• Le sort des données à la fin du contrat, format d’export compris.

Une exigence bien écrite tient en trois lignes et se refuse en une. Si elle ne peut pas être refusée à la recette, elle n’est pas encore écrite.

Le modèle de cahier des charges du guide reprend ces rubriques dans l’ordre attendu par une agence, et la grille de lecture des devis montre à quoi ressemble un chiffrage comparable.

Les contrôles à prévoir

Le contrôle de « MTTR » demande d’aller voir derrière l’écran : journaux, mesures, comportement en panne.

• Couper le réseau en pleine utilisation et regarder ce que l’application affiche.
• Tester sur une connexion lente, pas seulement sur le Wi-Fi du bureau.
• Lire les journaux d’erreurs de la première semaine de production.

Ce qui n’est pas vérifié à la recette ne sera pas vérifié du tout : le jour de la mise en ligne, plus personne n’a le temps.

Les pièges à éviter

Les mêmes causes reviennent d’un projet à l’autre, quel que soit le prestataire et quelle que soit la taille du budget.

• Recetter uniquement sur le Wi-Fi du bureau, puis découvrir le comportement réel en mobilité.
• Oublier le mode dégradé : ce que l’application affiche quand le serveur ne répond pas.
• Laisser les intégrations tierces sans limite d’appel ni conduite à tenir en cas de panne du fournisseur.
• Sortir la supervision et les alertes du périmètre pour tenir le budget initial.
• Reprendre la formulation d’un autre projet sans vérifier qu’elle décrit bien celui-ci.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• API REST
• Webhook
• Notification push
• Lien profond
• Feature flag

Questions fréquentes

MTTR : de quoi parle-t-on exactement ?

Durée moyenne de rétablissement après un incident, indicateur qui reflète la qualité de l’outillage et de l’organisation d’astreinte. Cette définition suffit pour une discussion de cadrage. Pour un contrat, il faut y ajouter ce que le terme recouvre exactement sur votre application.

Qui vérifie que c’est bien fait ?

Le client, à la recette, avec un critère écrit à l’avance. À défaut, personne : ces sujets ne se voient pas à l’écran, et un utilisateur ne signale que leurs conséquences.

Par où commencer quand le sujet est nouveau ?

Par les parcours et les règles de gestion, pas par les outils. Le guide du cahier des charges donne l’ordre dans lequel poser les questions à une agence.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.