Pourquoi les pourcentages d'uptime trompent les utilisateurs (et comment mieux les présenter)

Ce que dit la source

L'article dénonce une faille de communication : les status pages publient des chiffres d'uptime (98%, 99.72%, 99.9%) qui semblent tous similaires au non-initié, alors qu'ils représentent des écarts massifs. Jason Gorman a montré que progresser de 90% à 99% est aussi difficile que d'atteindre 90%, et que passer à 99.9% demande à nouveau le même effort (relation logarithmique, pas linéaire). L'auteur observe que GitHub, CI, Slack et d'autres services majeurs tombent régulièrement en panne, rendant les status pages omniprésentes pour tous les utilisateurs, pas seulement les infra teams. Il argue que quand l'audience s'élargit au-delà des ingénieurs infra, le format des pourcentages devient contre-productif : personne ne comprend que 99.9% et 99.99% diffèrent d'un facteur 10, et que cette non-linéarité est précisément ce qu'il faut saisir. Sa solution : adjoindre aux pourcentages une durée concrète ("12 heures affectées en 30 jours") pour que chacun puisse évaluer l'impact réel sans algèbre mentale.

• >Le problème est surtout communicationnel : les infrastructes anciennes (électricité, télécoms) visent trois à cinq nines par contrat SLA, mais les ingénieurs comprennent intuitivement ces paliers tandis que le grand public non.
• >GitHub Actions affiche 98.31% d'uptime en 2026, mais l'impact est amplifié parce que ces pannes surviennent généralement en heures de travail, pas la nuit ou le week-end, multipliant le coût pour les entreprises dépendantes.
• >Plusieurs commentateurs soulignent que la formulation "12 heures d'indisponibilité" serait elle-même trompeuse si elle cache que ces heures chevauchent systématiquement les pics d'activité : 1.5 jour ouvré de downtime peut valoir 7% d'une activité concentrée.
• >Le calcul même de l'uptime est devenu opaque : les fournisseurs de cloud ne mettent jamais à jour leurs SLA officiels après des pannes majeures, créant une cascade de contrats non-fiables en cascade (mon service dépend de trois services ayant chacun trois nines, mais aucun d'eux n'assure réellement ce chiffre).
• >Les companies contournent les pourcentages en reclassant les pannes en "perturbation partielle affectant certaines régions" plutôt qu'en indisponibilité totale, conservant ainsi des scores officiels de 99.99% malgré des impacts clients réels majeurs.
• >Les métriques de la distribution électrique (SAIDI, SAIFI, CAIDI) offrent une approche plus riche : durée moyenne d'interruption par client/an, nombre d'interruptions, temps de rétablissement, mais exigent une régulation pour être adoptées.
• >Statistiquement, beaucoup d'équipes ne justifient probablement pas l'investissement pour atteindre quatre ou cinq nines si trois nines suffisent à leur modèle économique : l'argument du coût est valide, mais GitHub (ou tout service central) n'a pas ce luxe car une panne affecte indirectement des millions de développeurs.

• >Plusieurs commentateurs contestent que reformuler les chiffres suffit à résoudre le problème : la durée seule ("12 heures en 30 jours") cache que ces heures sont concentrées aux pics d'utilisation; une panne de 45 minutes en mid-day vaut plus qu'une panne programmée la nuit, ce que ni les pourcentages ni les heures d'indisponibilité ne capturent.
• >L'opacité des calculs d'uptime actuels est soulevée comme le vrai problème : AWS n'a jamais ajusté ses SLA officielles après des pannes majeures, d'autres services reclassent les pannes en "perturbation partielle" pour éviter que le pourcentage ne baisse, rendant les chiffres publiés illusoires.
• >Forte critiques que le but réel des status pages et des pourcentages est cosmétique : les entreprises ne veulent pas que le public comprenne la fiabilité réelle, car les chiffres ne feraient que sembler pires ; la non-linéarité des "nines" est une fonctionnalité pour obscurcir l'ampleur des problèmes.
• >Un commentateur expérimenté note que GitHub n'a probablement besoin que de deux ou trois nines pour son modèle d'affaires, mais que l'enjeu est la perception publique (c'est un produit Microsoft visant l'ingénierie) : il ne s'agit pas d'une question technique de nécessité, mais de réputation et d'inertie contractuelle.
• >Les métriques électriques (SAIDI, SAIFI, CAIDI) sont mentionnées comme supérieures mais n'ont jamais dépassé l'industrie de l'électricité, d'où le scepticisme sur la chance qu'une nouvelle formule soit adoptée.