Calcul disponibilité en STS
Calculez rapidement la disponibilité d’un service ou d’un système sur son Temps de Service, comparez votre résultat à des seuils SLA courants et visualisez immédiatement la part de temps réellement disponible par rapport aux interruptions planifiées et non planifiées.
Résultats
Renseignez les valeurs puis cliquez sur le bouton de calcul.
Guide expert du calcul de disponibilité en STS
Le calcul de disponibilité en STS est un indicateur central pour piloter la qualité opérationnelle d’un service numérique, d’une application métier, d’un réseau, d’une plateforme d’hébergement ou encore d’un équipement industriel connecté. En pratique, STS signifie ici Temps de Service, c’est-à-dire la plage pendant laquelle le service doit être effectivement rendu à l’utilisateur final. Cette notion est essentielle, car un système peut sembler très fiable sur une longue période calendaire, tout en affichant une performance insuffisante sur sa fenêtre réelle d’engagement.
Qu’est-ce que la disponibilité en STS ?
La disponibilité mesure la capacité d’un service à être utilisable lorsqu’il est attendu. Dans un contexte STS, on ne se contente pas de compter le temps total d’une année. On se concentre sur le temps pendant lequel le service doit être opérationnel selon l’engagement métier, contractuel ou technique. Pour un portail e-commerce, ce temps peut être de 24 h sur 24. Pour une application de gestion interne, le STS peut correspondre aux heures ouvrées. Pour un système critique, le STS peut être défini par un contrat de niveau de service précis.
La formule de base est simple :
La subtilité vient de la définition du temps d’indisponibilité. Certaines organisations excluent les arrêts de maintenance planifiée lorsqu’ils ont été annoncés et validés. D’autres les incluent dans le calcul, notamment lorsque l’expérience utilisateur subit réellement l’interruption. C’est pour cette raison que le calculateur ci-dessus propose deux modes.
Pourquoi le calcul de disponibilité est stratégique
Une disponibilité élevée réduit l’impact financier des interruptions, améliore la satisfaction utilisateur et protège la réputation d’une organisation. Plus un service est critique, plus quelques minutes de panne peuvent avoir des conséquences importantes. Dans un environnement numérique moderne, la disponibilité est suivie par les équipes d’exploitation, les responsables produits, la cybersécurité, les métiers et la direction générale.
La disponibilité n’est toutefois pas la même chose que la performance ou la sécurité. Un système peut être techniquement disponible, mais extrêmement lent. À l’inverse, il peut être inaccessible pour cause de protection de sécurité déclenchée après incident. Une bonne gouvernance consiste donc à analyser la disponibilité avec d’autres indicateurs comme le temps moyen de réparation, le temps moyen entre pannes, la latence, le taux d’erreur applicatif et l’impact utilisateur.
La différence entre temps calendaire et temps de service STS
L’erreur la plus fréquente consiste à utiliser la durée calendaire brute sans vérifier la fenêtre d’engagement. Imaginons une application RH utilisée uniquement du lundi au vendredi de 8 h à 18 h. Si vous calculez la disponibilité sur 8760 heures annuelles, vous diluez artificiellement la panne dans une plage où le service n’était pas attendu. Le calcul en STS corrige ce biais : on ne retient que la période réellement contractualisée ou opérationnelle.
Cette approche est particulièrement utile dans les cas suivants :
- applications métiers non utilisées 24 h sur 24 ;
- services soumis à des fenêtres d’ouverture ou de production ;
- contrats SLA qui précisent des horaires d’engagement ;
- infrastructures avec maintenances planifiées acceptées hors temps de service ;
- analyse d’un service critique dont la tolérance à l’arrêt varie selon les jours ou les heures.
Comment interpréter les pourcentages de disponibilité
Les fameux niveaux de disponibilité en “nines” sont souvent utilisés pour évaluer la maturité opérationnelle. Mais un pourcentage apparemment très proche d’un autre peut représenter un écart considérable en durée d’interruption. Passer de 99,9 % à 99,99 % ne signifie pas une amélioration marginale : on divise par dix l’indisponibilité tolérée.
| Niveau de disponibilité | Indisponibilité maximale par an | Indisponibilité maximale par mois | Lecture opérationnelle |
|---|---|---|---|
| 99,0 % | 87 h 36 min | 7 h 12 min | Acceptable pour des services non critiques ou internes |
| 99,5 % | 43 h 48 min | 3 h 36 min | Niveau intermédiaire pour des services avec tolérance modérée |
| 99,9 % | 8 h 45 min 36 s | 43 min 12 s | Référence fréquente pour des plateformes en production |
| 99,95 % | 4 h 22 min 48 s | 21 min 36 s | Exigence élevée pour services client ou B2B critiques |
| 99,99 % | 52 min 33,6 s | 4 min 19,2 s | Très forte résilience, supervision et redondance nécessaires |
| 99,999 % | 5 min 15,36 s | 25,92 s | Ultra critique, coûteux à atteindre et à maintenir |
Ces chiffres montrent pourquoi l’architecture, l’automatisation, les tests de reprise et la qualité du support jouent un rôle décisif. Chaque “neuf” supplémentaire devient plus difficile et plus coûteux à obtenir.
Les données à collecter pour un calcul fiable
Un bon calcul de disponibilité en STS repose sur des données propres. L’idéal est de croiser plusieurs sources : supervision technique, logs applicatifs, outil ITSM, système d’astreinte, observabilité et retours métiers. Il faut également normaliser la façon dont les incidents sont classés.
Les entrées minimales
- Le Temps de Service STS sur la période étudiée.
- Les indisponibilités planifiées comme les maintenances, migrations ou correctifs.
- Les indisponibilités non planifiées comme les pannes, erreurs humaines, incidents réseau ou problèmes cloud.
- Le mode de calcul selon votre politique SLA : maintenance incluse ou exclue.
- La granularité temporelle : semaine, mois, trimestre ou année.
Les causes fréquentes d’erreur
- double comptage d’un même incident sur plusieurs outils ;
- oublis d’incidents partiels touchant seulement une partie des utilisateurs ;
- mauvaise définition du début ou de la fin d’un incident ;
- absence de distinction entre service dégradé et service indisponible ;
- non prise en compte des dépendances tierces.
Exemple concret de calcul disponibilité en STS
Supposons un service disponible 24 h sur 24 sur une année, avec un STS de 8760 heures. Durant cette période, vous enregistrez 8 heures de maintenance planifiée et 3,5 heures d’incidents non planifiés.
- Mode 1, maintenance exclue du numérateur : disponibilité = ((8760 – 3,5) / 8760) x 100 = 99,960 % environ.
- Mode 2, toute indisponibilité incluse : disponibilité = ((8760 – 11,5) / 8760) x 100 = 99,869 % environ.
Le résultat varie de façon significative selon la politique de mesure. Cette différence est normale. Ce qui compte est d’adopter une règle cohérente, traçable et partagée entre l’IT, les métiers et les parties contractuelles.
Table de comparaison entre objectifs SLA et contraintes opérationnelles
| Objectif SLA | Downtime annuel toléré | Pratiques généralement nécessaires | Niveau de maturité attendu |
|---|---|---|---|
| 99,0 % | 87 h 36 min | Supervision de base, sauvegardes, support heures ouvrées | Initial à intermédiaire |
| 99,9 % | 8 h 45 min | Alerting temps réel, procédures d’incident, redondance minimale | Intermédiaire à avancé |
| 99,99 % | 52 min 33,6 s | Architecture tolérante aux pannes, runbooks, tests réguliers, SRE | Avancé |
| 99,999 % | 5 min 15,36 s | Multi-site, automatisation poussée, failover éprouvé, observabilité complète | Très avancé à critique |
Ces valeurs ne doivent pas être interprétées comme une simple cible marketing. Elles conditionnent directement les investissements en conception, exploitation, compétences et gestion du changement.
Bonnes pratiques pour améliorer la disponibilité
1. Réduire le MTTR
Le MTTR, ou temps moyen de réparation, influence fortement la disponibilité. Plus vous détectez, diagnostiquez et corrigez vite, plus l’indisponibilité cumulée diminue. Centralisez les journaux, automatisez les alertes et documentez des procédures standard de résolution.
2. Diminuer la fréquence des incidents
Réduire le nombre de pannes est tout aussi important que raccourcir leur durée. Cela passe par le capacity planning, les tests de charge, les revues de changement, les analyses de causes racines et la fiabilisation de la chaîne de déploiement.
3. Isoler les points de défaillance uniques
Un service peut être fragilisé par une base de données unique, un lien réseau non redondé ou un processus manuel critique. Cartographiez les dépendances, puis hiérarchisez les remédiations selon l’impact métier.
4. Professionnaliser la maintenance planifiée
Les maintenances doivent être annoncées, testées, limitées dans le temps et idéalement réalisées hors STS. Une maintenance bien préparée réduit le risque d’incident secondaire et évite de dégrader artificiellement votre indicateur.
5. Tester la reprise
Une procédure de reprise non testée n’est qu’une hypothèse. Planifiez des exercices de restauration, de bascule et de retour arrière. Plus vos tests sont réalistes, plus votre disponibilité réelle sera proche de la disponibilité théorique.
Cadres et ressources de référence
Pour aller plus loin, il est utile de s’appuyer sur des organismes de référence. Le NIST publie des travaux sur la résilience, la sécurité et les pratiques d’ingénierie des systèmes. La CISA diffuse des recommandations opérationnelles sur la résilience des infrastructures et la réponse aux incidents. Le Software Engineering Institute de Carnegie Mellon University met également à disposition des ressources utiles sur la fiabilité logicielle et l’amélioration des pratiques d’ingénierie.
Ces sources sont particulièrement précieuses lorsqu’il faut aligner vos indicateurs de disponibilité avec une démarche plus large de gestion des risques, de continuité d’activité et de sécurité opérationnelle.
Comment utiliser efficacement ce calculateur
Le calculateur de cette page vous aide à estimer rapidement votre disponibilité en STS. Commencez par sélectionner une période ou indiquez une durée personnalisée. Saisissez ensuite le Temps de Service concerné. Dans beaucoup de cas, ce temps correspond à la totalité de la période, mais vous pouvez aussi entrer une fenêtre d’engagement spécifique, par exemple les seules heures ouvrées annuelles.
Ajoutez ensuite les heures d’indisponibilité planifiée et non planifiée. Choisissez enfin si la maintenance doit être incluse ou non dans la mesure. Le résultat vous donnera :
- la disponibilité calculée en pourcentage ;
- le temps réellement disponible ;
- le temps total d’indisponibilité retenu ;
- l’écart positif ou négatif par rapport à un objectif SLA choisi ;
- une visualisation graphique claire des composantes du temps de service.
Cette démarche est particulièrement utile pour les tableaux de bord mensuels, les revues de service, les audits qualité, la préparation de contrats SLA ou l’analyse post-incident.
Conclusion
Le calcul de disponibilité en STS est plus qu’une formule. C’est un langage commun entre la technique et le métier. En cadrant correctement le Temps de Service, en classant les interruptions de façon cohérente et en comparant le résultat à des objectifs réalistes, vous obtenez un indicateur fiable pour piloter l’amélioration continue. Une disponibilité élevée ne s’improvise pas : elle résulte d’une architecture robuste, d’une exploitation disciplinée, d’une observabilité efficace et d’une culture d’apprentissage après incident.
Utilisez le calculateur ci-dessus pour modéliser vos scénarios, valider vos engagements et identifier le niveau de résilience réellement atteint par votre service.