Contexte et problème

Les pages d’état publiques affichent souvent des pourcentages d’uptime tels que 99.72 % ou 98.31 %. L’article de Jim Nielsen montre que ces valeurs sont difficiles à interpréter pour un public non‑infra, car la différence entre 99.9 % et 99.99 % représente un facteur dix de temps d’indisponibilité, alors que les deux nombres paraissent similaires.

Analyse mathématique des pourcentages

Sur une période de 30 jours (720 heures), chaque « nueve » supplémentaire réduit le temps d’arrêt d’un facteur dix. Ainsi :

# Calcul du temps d’indisponibilité à partir d’un pourcentage d’uptime
import math

def downtime_hours(uptime_percent, days=30):
    total_hours = days * 24
    return total_hours * (1 - uptime_percent/100)

print(downtime_hours(99.0))   # 7.2 h
print(downtime_hours(99.9))   # 0.72 h
print(downtime_hours(99.99))  # 0.072 h (4.3 min)

Le texte cite 12 heures d’indisponibilité sur 30 jours pour GitHub Actions (98.31 %). Le calcul confirme : 720 h × (1‑0.9831) ≈ 12.2 h. Cette conversion rend la signification du chiffre immédiatement perceptible.

Implications pour les utilisateurs et les équipes

Les équipes d’infrastructure utilisent naturellement les « nines » pour planifier la redondance et les budgets de SLO. Les utilisateurs finaux, en revanche, évaluent la qualité d’un service en fonction du temps réel d’indisponibilité qu’ils ont pu subir. Un affichage en heures ou minutes évite le besoin de comprendre la non‑linéarité des pourcentages proches de 100 %.

De plus, le format actuel ne indique pas la répartition temporelle des pannes : un incident de 12 heures consécutives a un impact très différent d’une série de petites interruptions réparties sur le mois, même si le pourcentage reste identique.

Propositions d’alternatives

Une solution consiste à afficher simultanément le pourcentage et le temps d’arrêt cumulé, par exemple : « GitHub Actions : 98.31 % uptime (12 h d’indisponibilité sur les 30 derniers jours) ». Cette double lecture conserve la métrique standard pour les équipes techniques tout en offrant une référence concrète aux non‑spécialistes.

Une autre approche consiste à publier le MTBF (Mean Time Between Failures) et le MTTR (Mean Time To Repair). Ces indicateurs décrivent la fréquence et la durée moyenne des incidents, ce qui aide à distinguer un service qui subit de fréquentes micro‑pannes d’un service qui connaît de rares pannes longues.

Enfin, les pages d’état pourraient inclure un graphique simple montrant le nombre d’heures d’indisponibilité par jour, rendant visible la concentration des incidents. Cette visualisation, combinée à des valeurs numériques, fournit une image plus complète sans introduire de jargon supplémentaire.