Deux sens partagent une seule formule. Partez d’un pourcentage de SLA et vous obtenez le temps d’arrêt qu’il autorise (c’est notre calculateur de disponibilité). Partez du temps d’indisponibilité que vous avez eu, comme le fait cette page, et vous obtenez le pourcentage de disponibilité qu’il a produit : (période − indisponibilité) ÷ période × 100. Nous ajoutons les deux chiffres qu’un tableur ne vous donnera jamais : ce que ça a coûté, et où sont passées les minutes.

Divisez l’indisponibilité par la période, puis multipliez par 100. Une panne de 43 min 48 s sur un mois de 30,42 jours : 2 628 s ÷ 2 628 000 s × 100 = 0,1 % d’indisponibilité — soit 99,9 % de disponibilité. Deux règles : additionnez chaque incident de la période (ne les moyennez pas), et mesurez de la première requête en échec jusqu’au rétablissement vérifié.

Deux à trois neufs, c’est la fourchette normale pour un service de production petit à moyen — de 43 minutes à 7 heures par mois. Trois neufs (43 min 48 s/mois), c’est l’objectif de référence : atteignable avec un bon hébergement, des retours arrière rapides et quelqu’un d’astreinte. Si votre mois dépasse 7 heures, le tableau des dégâts ci-dessus indique la note que vous obtenez réellement — et la section chronologie du résultat indique où récupérer des minutes en priorité.

Ignorez les chiffres spectaculaires au coût par minute des études menées auprès des grandes entreprises — elles font la moyenne entre une banque et une boulangerie. Votre plafond, c’est votre propre calcul : chiffre d’affaires par heure × heures d’indisponibilité, plus les personnes qui ont tout lâché, plus tout ce qui est contractuel. La section coût du résultat le calcule en direct avec vos chiffres. Deux réserves. Certains acheteurs interrompus reviennent plus tard, donc le chiffre d’affaires perdu est un plafond. Et certains coûts n’entrent jamais dans un tableur : la confiance, le SEO, le retard accumulé côté support.

Ils comptent selon ce que vous avez décidé — avant l’incident. Pratique courante : un chemin critique cassé (paiement, connexion) compte en totalité même si la page d’accueil s’affiche encore ; un mode dégradé mais fonctionnel compte à part ou pas du tout. Écrivez la définition et appliquez-la toujours de la même façon. Les litiges de SLA portent sur ce paragraphe, pas sur le calcul.

Le MTTR, c’est le temps moyen de rétablissement : indisponibilité totale ÷ nombre d’incidents. C’est votre meilleur levier, car le diviser par deux divise votre indisponibilité par deux sans empêcher un seul incident. Le MTBF, c’est le temps moyen entre pannes, autrement dit la fréquence des pannes. Il dépend de l’architecture et de la discipline de changement, pas de la vitesse de réaction. Ensemble, ils donnent la disponibilité : MTBF ÷ (MTBF + MTTR). Le RTO, c’est le MTTR que vous avez promis — la durée maximale qu’une panne peut tenir avant que le plan de reprise n’ait échoué. Testez-le avant qu’un incident ne s’en charge.

Attaquez le MTTR avant le MTBF — se rétablir plus vite coûte moins cher que tomber en panne moins souvent. Et dans le MTTR, attaquez d’abord la détection : c’est la seule phase qu’un outil peut réduire pour vous, directement. Dans notre exemple, la détection a pris 11 minutes et la correction 4. Des vérifications toutes les 30 secondes plafonnent à une demi-minute le silence avant le premier échec constaté — elles ne peuvent pas raccourcir l’envoi de l’alerte ni le temps que quelqu’un met à décrocher le téléphone, ce qui explique pourquoi la détection ne baisse ici que de quatre minutes, pas de onze. Le diagnostic se réduit avec des preuves (résultats depuis plusieurs points de contrôle, horodatages exacts) ; la correction elle-même se réduit avec des retours arrière répétés — cette partie ne dépend que de vous.

Vous ne pouvez pas calculer ce que vous n’avez pas remarqué — le redémarrage à 3 h du matin de notre registre de juin n’existe que parce que quelque chose surveillait. Une surveillance indépendante vous fournit ce dont ce calculateur a besoin : des heures de début et de fin exactes, depuis l’extérieur de votre propre infrastructure. Cela couvre chaque incident, y compris ceux dont personne n’était éveillé pour témoigner. Uptimia vérifie depuis 171+ points de contrôle dans 70+ pays — toutes les 60 secondes sur le forfait Basic, toutes les 30 à partir de Professional — et tient ce registre à votre place.