Calculateur de disponibilité
Saisissez un taux de disponibilité pour voir exactement le temps d'arrêt qu'il autorise, ou saisissez une panne déjà survenue pour voir quel niveau de SLA elle respecte encore.
Disponibilité → temps d'arrêt autorisé
- Par an
- 8 h 45 min 36 s
- Par mois
- 43 min 12 s
- Par semaine
- 10 min 5 s
- Par jour
- 1 min 26 s
Panne → disponibilité atteinte
Disponibilité atteinte
99,444%
Cela respecte encore un engagement de 99 %.
That outage breached a standard SLA level
A single slow recovery can consume an entire period's downtime budget, however well the rest of it ran. If that is a pattern rather than a one-off, the fix is usually architectural — and it is what we do.
Que signifie réellement un taux de disponibilité ?
Un taux de disponibilité est un engagement sur la proportion d'une fenêtre de mesure pendant laquelle un service sera accessible. Une disponibilité de 99,9 % signifie que le service peut être indisponible un dixième de pour cent de la fenêtre — ce qui paraît dérisoire jusqu'à ce qu'on le convertisse en temps réel et qu'on découvre qu'il autorise 43 minutes de panne chaque mois.
Le pourcentage seul est presque dénué de sens sans trois précisions supplémentaires : la durée de la fenêtre de mesure, ce qui compte comme une panne, et qui mesure. Un engagement de 99,9 % mesuré annuellement absorbe une seule panne de huit heures ; le même 99,9 % mesuré mensuellement non. C'est sur ce détail que se jouent la plupart des litiges de SLA, et il est presque toujours enfoui dans une section de définitions au lieu d'être indiqué à côté du chiffre.
Comment se calcule le temps d'arrêt autorisé
L'arithmétique est simple, et mieux vaut la voir que la croire : le temps d'arrêt autorisé n'est que la part de la fenêtre que l'engagement laisse ouverte.
-
Soustrayez le taux de disponibilité de 100 pour obtenir l'indisponibilité permise. Pour 99,9 %, cela donne 0,1 %.
-
Exprimez-le en fraction : 0,1 % devient 0,001.
-
Multipliez par la durée de la fenêtre de mesure en secondes. Un mois de 30 jours compte 2 592 000 secondes, donc 0,001 × 2 592 000 = 2 592 secondes.
-
Reconvertissez en unités lisibles : 2 592 secondes font 43 minutes et 12 secondes.
Ce calculateur utilise une année de 365 jours et un mois de 30 jours, la convention retenue par tous les grands fournisseurs cloud dans leurs propres SLA. Cela compte plus qu'il n'y paraît : une année de 365,25 jours décalerait le chiffre à 99,999 % d'environ huit secondes, et quiconque comparerait cette page au tableau SLA d'AWS ou d'Azure y verrait un écart et ne ferait confiance ni à l'un ni à l'autre.
Tableau de référence : disponibilité et temps d'arrêt
Les niveaux standards, convertis. La plupart des SLA commerciaux se situent entre 99,5 % et 99,99 % ; la ligne des cinq neuf figure ici surtout parce qu'elle est bien plus souvent citée que réellement contractualisée.
| Disponibilité | Par an | Par mois | Par semaine | Par jour |
|---|---|---|---|---|
| 90% | 36d 12h | 3d | 16h 48m | 2h 24m |
| 95% | 18d 6h | 1d 12h | 8h 24m | 1h 12m |
| 99% | 3d 15h 36m | 7h 12m | 1h 40m 48s | 14m 24s |
| 99.5% | 1d 19h 48m | 3h 36m | 50m 24s | 7m 12s |
| 99.9% | 8h 45m 36s | 43m 12s | 10m 5s | 1m 26s |
| 99.95% | 4h 22m 48s | 21m 36s | 5m 2s | 43s |
| 99.99% | 52m 34s | 4m 19s | 1m | 9s |
| 99.999% | 5m 15s | 26s | 6s | 1s |
Sur la base d'une année de 365 jours et d'un mois de 30 jours, conformément à la convention des SLA publiés par les fournisseurs cloud.
Pourquoi chaque neuf supplémentaire coûte tellement plus cher
Chaque neuf supplémentaire divise par dix le temps d'arrêt autorisé, et le coût pour l'atteindre est loin de suivre la même courbe. L'écart entre 99 % et 99,9 % relève surtout d'une exploitation compétente. L'écart entre 99,9 % et 99,99 % est généralement un changement d'architecture : redondance entre zones de disponibilité, bascule automatique, et suppression de chaque point de défaillance unique que vous tolériez jusqu'ici.
C'est le dernier neuf qui demande de la prudence. Passer de 99,99 % à 99,999 % ne laisse qu'environ cinq minutes de panne par an — moins qu'un seul redémarrage non planifié, et moins que ce que consomment la plupart des processus de déploiement. S'y engager signifie que chaque opération de maintenance courante doit se faire sans interruption, ce qui est une propriété de l'architecture et non quelque chose qu'une équipe d'exploitation peut promettre à force de rigueur.
Quel taux de disponibilité s'engager à tenir ?
Le bon niveau est celui où le coût du neuf suivant dépasse le coût du temps d'arrêt qu'il évite. Pour un système de reporting interne utilisé aux heures ouvrées, 99 % est souvent tout à fait raisonnable et personne ne perçoit la différence. Pour un parcours de paiement ou un tunnel d'achat, une heure de panne peut coûter davantage qu'une année entière de l'infrastructure nécessaire pour l'éviter.
Une approche pragmatique consiste à raisonner à rebours depuis la conséquence plutôt qu'en avant depuis l'ambition. Estimez ce qu'une heure d'indisponibilité coûte réellement — transactions perdues, personnel immobilisé, charge de support, pénalités contractuelles — et comparez-le à l'investissement d'ingénierie qu'exige chaque neuf supplémentaire. S'engager publiquement sur un niveau pour lequel on n'a pas conçu son architecture est pire que s'engager honnêtement sur un niveau inférieur : la première panne transforme un problème d'ingénierie en problème contractuel.
Comment améliorer la disponibilité
Améliorer la disponibilité consiste surtout à supprimer les points de défaillance uniques et à raccourcir le temps nécessaire pour détecter les défaillances restantes et s'en remettre. À peu près par ordre de rendement :
- Mesurez honnêtement, d'abord. Si vous ne pouvez pas dire quelle a été votre disponibilité le trimestre dernier, tout objectif reste un vœu. Des sondes synthétiques depuis l'extérieur de votre réseau sont le minimum : elles détectent les pannes que votre supervision interne ne voit pas, parce qu'elle est à l'intérieur de la défaillance.
- Éliminez les points de défaillance uniques que vous connaissez déjà. La plupart des équipes savent les nommer : l'unique serveur de base de données, l'étape de bascule manuelle, le certificat que quelqu'un renouvelle à la main.
- Raccourcissez le délai de détection. La durée de rétablissement est généralement dominée par le temps mis à s'apercevoir du problème, pas par le temps de correction, et alerter sur des symptômes ressentis par les utilisateurs vaut mieux qu'alerter sur des métriques serveur.
- Rendez la maintenance courante non perturbante. Dès lors que déploiements, migrations et correctifs exigent tous une interruption, votre maintenance planifiée entre en concurrence avec votre SLA sur le même budget de minutes.
La redondance mérite d'être ajoutée après cela, pas avant. Une infrastructure redondante dont la bascule est lente, ou qui n'a jamais été éprouvée par une panne réelle, tend à transformer les courtes pannes en longues plutôt qu'à les empêcher.
Exemple chiffré : un SLA mensuel de 99,9 %
Supposons que vous vous soyez engagé sur 99,9 % de disponibilité mesurée mensuellement, et qu'une bascule de base de données ait pris quatre heures un mardi après-midi.
43m 12s
Par mois
Un engagement mensuel de 99,9 % autorise 43m 12s de temps d'arrêt. Une panne de quatre heures représente environ cinq fois et demie ce budget, ce qui place le mois autour de 99,44 % — conforme à 99 %, mais en rupture avec 99,9 %.
Notez ce que cela implique pour le reste de la fenêtre : une seule panne de quatre heures épuise entièrement le budget mensuel, si bien que le SLA est rompu quelle que soit la perfection des 27 autres jours. Cette asymétrie explique pourquoi le travail sur la disponibilité se concentre sur le temps de rétablissement plutôt que sur la fréquence des pannes : un rétablissement lent coûte plus cher que plusieurs rapides.
Common questions
Que signifie réellement un taux de disponibilité ?
Un taux de disponibilité est un engagement sur la proportion d'une fenêtre de mesure pendant laquelle un service sera accessible. Une disponibilité de 99,9 % signifie que le service peut être indisponible un dixième de pour cent de la fenêtre — ce qui paraît dérisoire jusqu'à ce qu'on le convertisse en temps réel et qu'on découvre qu'il autorise 43 minutes de panne chaque mois.
Comment se calcule le temps d'arrêt autorisé
L'arithmétique est simple, et mieux vaut la voir que la croire : le temps d'arrêt autorisé n'est que la part de la fenêtre que l'engagement laisse ouverte.
Quel taux de disponibilité s'engager à tenir ?
Le bon niveau est celui où le coût du neuf suivant dépasse le coût du temps d'arrêt qu'il évite. Pour un système de reporting interne utilisé aux heures ouvrées, 99 % est souvent tout à fait raisonnable et personne ne perçoit la différence. Pour un parcours de paiement ou un tunnel d'achat, une heure de panne peut coûter davantage qu'une année entière de l'infrastructure nécessaire pour l'éviter.
Comment améliorer la disponibilité
Améliorer la disponibilité consiste surtout à supprimer les points de défaillance uniques et à raccourcir le temps nécessaire pour détecter les défaillances restantes et s'en remettre. À peu près par ordre de rendement :
À lire également
Cloud Cost Optimization Strategies: 10 Actionable Tactics
Explore 10 actionable cloud cost optimization strategies for mid-market and enterprise teams, covering rightsizing, autoscaling, FinOps, and observability.
What Is Infrastructure as Code: A Complete Guide for 2026
Learn what is infrastructure as code, how declarative and imperative approaches differ, and how to adopt IaC without losing control in 2026.
Business Continuity Best Practices: A 2026 Guide
Explore 10 business continuity best practices for software platforms. Learn to build resilient systems with tips on RTO/RPO, IaC, DR testing, and SRE.
Engagé sur un chiffre pour lequel votre architecture n'est pas prête ?
Ryware conçoit et exploite des systèmes à haute disponibilité pour des organisations où le temps d'arrêt se mesure en chiffre d'affaires perdu plutôt qu'en désagrément : une redondance éprouvée en conditions réelles de panne, une bascule qui aboutit sans intervention humaine, et une supervision qui s'en aperçoit avant vos clients.