Un taux d’uptime de 99,9 % semble presque parfait, mais il autorise encore une interruption mesurable. Sur un mois de 30 jours, le budget théorique atteint environ 43 minutes, tandis qu’une année de 365 jours en permet près de 8 heures et 46 minutes.
Ces minutes ne pèsent pas toutes de la même façon : une panne nocturne d’un site vitrine n’a pas le même coût qu’une interruption pendant une vente importante. Pour juger la fiabilité d’un service en ligne, il faut donc traduire le pourcentage en temps d’arrêt, puis examiner les conditions du SLA.
A retenir :
- 99,9 % : environ 43 minutes d’arrêt sur un mois de 30 jours
- Fenêtre de calcul mensuelle ou annuelle déterminante pour le risque
- Maintenance planifiée parfois exclue du calcul contractuel
- Supervision indépendante utile pour vérifier la disponibilité réelle
99,9 % d’uptime : combien de minutes d’arrêt ?
Une fois le taux traduit en durée, son impact devient plus facile à comparer. Le calcul repose sur la période observée : le même pourcentage autorise davantage d’interruption sur une année que sur un mois.
Le budget de panne selon la disponibilité
Pour obtenir le temps d’arrêt autorisé, on calcule la part manquante jusqu’à 100 % et on l’applique à la durée considérée. À 99,9 %, cette part représente 0,1 % du temps total, soit 43 minutes et 12 secondes sur 30 jours.
Les valeurs du tableau sont des estimations théoriques, arrondies, en fonctionnement continu. Un contrat peut employer une autre période de calcul ou définir précisément les incidents pris en compte.
Durées d’arrêt selon le taux :
| Disponibilité | Arrêt sur 30 jours | Arrêt sur 365 jours |
|---|---|---|
| 99 % | 7 h 12 min | 3 j 15 h 36 min |
| 99,9 % | 43 min 12 s | 8 h 45 min 36 s |
| 99,95 % | 21 min 36 s | 4 h 22 min 48 s |
| 99,99 % | 4 min 19 s | 52 min 34 s |
| 99,999 % | 26 s | 5 min 15 s |
Chaque neuf supplémentaire divise approximativement par dix le budget d’indisponibilité, mais exige davantage de redondance, de contrôle des déploiements et de capacité d’intervention. Pour une petite boutique, ces investissements ne se justifient pas automatiquement : tout dépend du coût réel d’une panne.
Un même arrêt, des conséquences différentes
Le pourcentage ne dit ni quand la panne survient ni combien d’incidents composent le total. Quarante-trois minutes pendant une période calme peuvent avoir peu d’effet, alors qu’une interruption pendant un lancement peut bloquer commandes et paiements.
Pour estimer le besoin, une entreprise peut comparer le manque à gagner, les demandes d’assistance et les conséquences pour ses utilisateurs. Cette évaluation aide à choisir une cible cohérente plutôt qu’à rechercher le taux le plus élevé par réflexe.
Repères pour choisir une cible :
- Site vitrine : tolérance liée aux visites et aux demandes de contact
- Boutique en ligne : coût des commandes perdues pendant les périodes d’affluence
- Application métier : effet d’une interruption sur le travail des équipes
- Service critique : besoins de continuité et budget d’ingénierie associé
La durée maximale autorisée ne suffit donc pas à évaluer une promesse : il faut également savoir comment le fournisseur mesure et comptabilise les interruptions.
SLA et disponibilité : lire les conditions de mesure
Après le calcul, les clauses du SLA déterminent ce qui compte réellement comme panne. Deux offres affichant 99,9 % peuvent donc protéger différemment leurs clients selon la période retenue et les exclusions prévues.
Fenêtre de calcul et maintenance planifiée
Un objectif calculé chaque mois limite le budget d’arrêt à environ 43 minutes par mois de 30 jours. Une mesure annuelle permet près de 8 heures et 46 minutes au total, éventuellement concentrées dans un seul incident.
Selon les conditions du fournisseur, la maintenance planifiée peut être exclue du calcul. Il faut aussi vérifier si la mesure porte sur le réseau d’hébergement, le serveur, l’application ou le service complet visible par l’utilisateur.
Clauses à examiner dans un SLA :
- Période de mesure : mois civil, période glissante ou année contractuelle
- Maintenance : fenêtres exclues et modalités de notification
- Périmètre : infrastructure, application ou parcours utilisateur complet
- Compensation : procédure, délai de réclamation et forme des avoirs
SLI, SLO et SLA : trois notions distinctes
Le SLI désigne l’indicateur observé, par exemple la part de requêtes aboutissant correctement. Le SLO fixe la cible interne associée à cet indicateur, tandis que le SLA formalise une promesse contractuelle envers les clients.
Selon le cadre de fiabilité popularisé par Google SRE, distinguer ces notions aide les équipes à piloter leurs objectifs sans confondre mesure opérationnelle et engagement contractuel. Un SLO interne peut ainsi être plus exigeant que le SLA, afin de conserver une marge avant d’atteindre la limite promise.
Une lecture attentive du contrat conduit naturellement à une autre question : comment vérifier que les chiffres annoncés correspondent à l’expérience des visiteurs ?
Mesurer l’uptime réel et protéger la continuité de service
Les clauses décrivent la mesure contractuelle, mais une supervision externe révèle ce que rencontre réellement un visiteur. Elle permet aussi de distinguer une longue panne de plusieurs microcoupures, qui peuvent produire un total similaire tout en exigeant des corrections différentes.
Supervision indépendante et historique d’incidents
Un contrôle depuis l’extérieur vérifie une page ou un parcours accessible publiquement, puis horodate les indisponibilités observées. Selon les pratiques de supervision recommandées dans les opérations de site, confronter ces relevés aux données du fournisseur facilite l’analyse des écarts.
Une équipe peut alors comparer son propre historique au rapport du prestataire et conserver des éléments utiles pour une demande d’avoir prévue au contrat. Elle obtient également une base plus fiable pour informer ses clients après un incident.
Mesures utiles pour suivre un service :
- Disponibilité observée depuis un réseau extérieur
- Durée et heure de début de chaque incident
- Réponse des pages et fonctions essentielles
- Écart entre relevés internes et statut fournisseur
Réduire les pannes avant leur apparition
La continuité de service dépend aussi des causes évitables, notamment des déploiements risqués, des saturations et des vagues de requêtes automatisées. Des sauvegardes testées, une architecture redondante et des procédures de retour arrière réduisent l’impact de ces défaillances.
Les limites de débit et les protections contre les bots peuvent également préserver les connexions ou les paiements lors d’un trafic anormal. Selon les recommandations de sécurité opérationnelle des fournisseurs, ces contrôles doivent protéger les fonctions critiques sans bloquer les utilisateurs légitimes.
Pour une petite équipe, le meilleur point de départ reste concret : surveiller les parcours qui comptent, examiner chaque incident et relier les minutes perdues à leurs conséquences métier.
Comprendre son ordinateur comme un système, pas une boîte noire
Qu'il s'agisse de choisir un processeur, d'ajouter de la mémoire ou de sécuriser sa connexion réseau, chaque décision mérite d'être comprise plutôt que subie. Saisir les contraintes réelles de chaque composant permet d'en tirer des bénéfices concrets : performance, fiabilité et longévité de la machine.
Pour aller plus loin
- Vérifier l'adéquation entre vos usages réels et la configuration matérielle envisagée
- Comparer les technologies de stockage selon vitesse, fiabilité et coût
- Sécuriser l'accès et les sauvegardes de vos données sensibles
- Anticiper le refroidissement dès la conception d'une configuration
