Que signifie vraiment une disponibilité de « 99,9% » ? Cela semble presque parfait, mais cela cache un chiffre surprenant : plus de 43 minutes d'indisponibilité autorisée chaque mois. Et « 99,99% » ? À peine 4 minutes. Ce calculateur traduit un objectif SLA de disponibilité en ce qui compte vraiment : combien de temps d'arrêt (downtime) est autorisé sur une période donnée, combien vous en avez déjà consommé (l'error budget), la disponibilité effective atteinte et le coût économique du temps d'arrêt. Saisissez l'objectif SLA (par exemple 99,9%), la période en jours, le temps d'arrêt observé (avec l'éventuelle maintenance planifiée à exclure) et le coût par minute, et vous obtenez le budget de temps d'arrêt autorisé, la disponibilité effective, le pourcentage d'error budget consommé et le coût. Il est paramétrique et neutre vis-à-vis de la monnaie : il fonctionne avec n'importe quel objectif, n'importe quelle période et n'importe quelle monnaie. C'est un outil conçu pour les équipes techniques, SRE, DevOps, responsables de services cloud et quiconque doit comprendre, négocier ou respecter un engagement de disponibilité — un sujet universel dans l'ingénierie des systèmes modernes.

Qu'est-ce qu'un SLA de disponibilité

Un SLA (Service Level Agreement) est un accord sur le niveau de service, et dans le monde des systèmes IT le paramètre le plus courant est la disponibilité (uptime, availability) : le pourcentage de temps pendant lequel un service est opérationnel et joignable, sur une période donnée. Une disponibilité de 99,9% signifie que le service est disponible 99,9% du temps ; les 0,1% restants sont du temps d'arrêt (downtime), c'est-à-dire de l'indisponibilité. Les SLA de disponibilité s'expriment presque toujours en « neuf » : 99% (« deux neuf »), 99,9% (« trois neuf »), 99,99% (« quatre neuf »), 99,999% (« cinq neuf »). Plus de neuf, plus haute la disponibilité promise — et plus difficile et coûteuse à garantir. Un SLA peut être interne (un objectif qu'une équipe se fixe) ou contractuel (un engagement envers les clients, souvent avec des pénalités s'il n'est pas respecté). Le point crucial, et souvent sous-estimé, est qu'une petite différence en pourcentage correspond à une différence énorme en temps d'arrêt autorisé. Comprendre cette traduction — du pourcentage aux minutes réelles — est le premier pas pour gérer, négocier ou respecter un engagement de disponibilité de façon consciente.

Comment se calcule le temps d'arrêt autorisé

Le calcul de base est simple. Le temps d'arrêt autorisé (ou « error budget » en minutes) est la fraction de temps d'indisponibilité que le SLA autorise, appliquée à la durée de la période. D'abord on convertit la période en minutes : jours × 24 × 60. Puis on multiplie par la part de temps d'arrêt autorisée, soit un moins l'objectif divisé par 100. En formule : D_max = (1 − s/100) × P, où D_max est le temps d'arrêt autorisé, s l'objectif SLA en pourcentage, P les minutes totales de la période. Par exemple, avec un objectif de 99,9% sur 30 jours : P = 43 200 minutes, la part autorisée est 0,1% = 0,001, donc D_max = 43,2 minutes. Le calculateur fait exactement cela, puis compare le temps d'arrêt que vous avez effectivement observé avec ce budget, en calculant combien vous en avez consommé (l'error budget consommé), la disponibilité effective atteinte et le coût économique du temps d'arrêt. Vous pouvez aussi exclure la maintenance planifiée, que de nombreux SLA ne comptent pas. C'est l'outil pour passer de l'objectif abstrait aux chiffres concrets : combien de marge vous avez, si vous respectez l'engagement, et ce que vous coûte l'indisponibilité.

La mathématique des « neuf »

Le cœur de la disponibilité est une mathématique impitoyable : chaque chiffre « neuf » supplémentaire réduit le temps d'arrêt autorisé de dix fois. Le tableau montre combien de temps d'arrêt correspond aux objectifs les plus courants, sur base mensuelle (30 jours) et annuelle :

La progression est impressionnante. Passer de 99% à 99,9% réduit le temps d'arrêt annuel de plus de 3 jours à moins de 9 heures ; de 99,9% à 99,99%, de presque 9 heures à moins d'une heure ; de 99,99% à 99,999%, à un peu plus de 5 minutes par an. Mais il y a un revers de la médaille : chaque neuf supplémentaire coûte de façon disproportionnée. Passer de trois à quatre neuf requiert typiquement de la redondance, de l'automatisation, des systèmes de bascule, une surveillance avancée, des équipes d'astreinte — des investissements qui croissent bien plus vite que la réduction du temps d'arrêt. C'est pourquoi le choix de l'objectif n'est pas « plus de neuf est toujours mieux » : c'est un équilibre entre la valeur d'une disponibilité plus élevée et son coût croissant. Le calculateur vous aide à voir cette réalité en chiffres concrets pour votre période spécifique.

La décomposition du calcul

Le tableau montre la décomposition dans le cas par défaut — objectif SLA 99,9%, période 30 jours, temps d'arrêt total observé 25 minutes, maintenance planifiée exclue 5 minutes, coût 500 par minute :

Le tableau est clair. Avec un objectif de 99,9% sur 30 jours, vous avez un budget de 43,2 minutes de temps d'arrêt. Des 25 minutes observées, 5 étaient de la maintenance planifiée (exclue), donc 20 sont comptabilisées : 46% du budget. Vous êtes donc largement dans le SLA, avec une disponibilité effective de 99,954% et plus de la moitié du budget encore disponible. Le temps d'arrêt comptabilisé a coûté environ 10 000. Changez les paramètres avec vos chiffres : vous verrez tout de suite si vous respectez l'engagement et combien de marge il vous reste.

L'error budget : une façon différente de penser la fiabilité

Un des concepts les plus puissants introduits par l'ingénierie de la fiabilité (SRE, Site Reliability Engineering) est l'error budget. L'idée est contre-intuitive mais géniale : si l'objectif est 99,9%, alors les 0,1% de temps d'arrêt ne sont pas un échec à éviter à tout prix, mais un « budget » à dépenser. Ce budget d'indisponibilité peut être « dépensé » de façon productive : pour publier de nouvelles fonctionnalités (qui comportent du risque), faire de la maintenance, expérimenter, ou simplement absorber les imprévus. Tant que vous restez dans le budget, tout va bien. Cela change radicalement la perspective. Au lieu de traiter chaque minute de temps d'arrêt comme une catastrophe (ce qui conduirait à bloquer tout changement par peur), l'error budget crée un équilibre entre fiabilité et innovation. Si le budget se consomme trop vite, c'est le signal pour ralentir les déploiements et se concentrer sur la stabilité ; s'il ne se consomme presque jamais, peut-être « sur-investit »-on dans la fiabilité au détriment de la vitesse de développement. L'error budget devient ainsi un outil de gouvernance partagé entre ceux qui développent (veulent publier vite) et ceux qui opèrent (veulent la stabilité), alignant les incitations sur un nombre mesurable. Le calculateur montre justement combien d'error budget vous avez consommé : c'est la donnée clé pour ces décisions.

Disponibilité vs temps d'arrêt : la conversion

Disponibilité et temps d'arrêt sont les deux faces de la même médaille, mais les penser séparément aide à éviter les erreurs. La disponibilité est le pourcentage de temps pendant lequel le service fonctionne ; le temps d'arrêt est le temps (en minutes, heures, jours) pendant lequel il ne fonctionne pas. La relation est : temps d'arrêt = (1 − disponibilité%) × période. L'erreur la plus courante est de raisonner seulement en pourcentage, où les différences semblent petites (« 99,9% et 99,99% sont presque pareils »), alors qu'en termes de temps réel elles sont énormes (43 minutes contre 4 par mois, un facteur dix). Un autre point important est que la disponibilité doit toujours se référer à une période : 99,9% sur un mois et 99,9% sur un an autorisent des temps d'arrêt totaux très différents en valeur absolue. Et il y a la question de ce que l'on mesure : la disponibilité du serveur ? Du service perçu par l'utilisateur ? D'un seul composant ou de toute la chaîne ? Un service peut avoir les serveurs « up » mais être de fait inutilisable à cause d'un problème en aval. Le calculateur travaille sur le concept général de disponibilité du service sur la période que vous indiquez ; la définition précise de ce qui constitue un « temps d'arrêt » est, en pratique, un des points les plus importants (et discutés) de tout SLA.

Maintenance planifiée et exclusions

Un détail qui fait une grande différence est ce que le SLA exclut du comptage du temps d'arrêt. La plus courante est la maintenance planifiée : des fenêtres d'intervention communiquées à l'avance, pendant lesquelles le service peut être indisponible sans que cela compte comme une violation. De nombreux SLA prévoient ces fenêtres, typiquement aux heures de faible utilisation. D'autres exclusions fréquentes concernent : les causes de force majeure (événements exceptionnels hors du contrôle du fournisseur), les problèmes attribuables au client (par exemple des configurations erronées côté utilisateur), les interruptions de tiers (fournisseurs externes, connectivité), et les attaques ou événements de sécurité sous certaines conditions. La conséquence pratique est que le temps d'arrêt « réel » perçu et le temps d'arrêt « comptabilisé » aux fins du SLA peuvent différer, même beaucoup. Dans le calculateur, le champ « maintenance planifiée exclue » vous permet de soustraire cette part du temps d'arrêt total, pour calculer le temps d'arrêt effectivement comptabilisé. C'est un rappel important : quand on évalue ou négocie un SLA, les définitions et exclusions comptent autant que le pourcentage. Un SLA de 99,99% avec de nombreuses exclusions peut, en pratique, offrir moins qu'un de 99,9% avec peu d'exclusions. Lisez toujours les clauses avec attention.

Le coût du temps d'arrêt : l'impact sur l'activité

Derrière chaque minute de temps d'arrêt il y a un coût, et le quantifier est essentiel pour prendre des décisions rationnelles sur la fiabilité. Le coût du temps d'arrêt dépend du type de service, mais inclut typiquement : les revenus perdus (pour un e-commerce ou un service payant, chaque minute d'indisponibilité représente des ventes manquées), la productivité perdue (si le service est utilisé en interne, les employés ne peuvent pas travailler), les coûts de récupération et de réponse (l'équipe qui intervient, les heures supplémentaires, l'analyse post-incident), les éventuelles pénalités contractuelles envers les clients, et — souvent le plus insidieux — le dommage réputationnel et la perte de confiance. Certains services ont des coûts de temps d'arrêt énormes, où chaque minute vaut des milliers ou des dizaines de milliers ; d'autres sont plus tolérants. Connaître le coût par minute est crucial pour deux raisons. Premièrement : cela permet de justifier les investissements en fiabilité (si une minute de temps d'arrêt coûte X, combien vaut la réduction du temps d'arrêt attendu ?). Deuxièmement : cela aide à choisir le bon objectif, en équilibrant le coût d'une disponibilité plus élevée avec le coût du temps d'arrêt qui serait évité. Dans le calculateur, en saisissant le coût par minute, vous voyez l'impact économique du temps d'arrêt comptabilisé — une donnée concrète pour dialoguer avec le métier, pas seulement avec les techniciens. Ceci est une estimation paramétrique, pas un engagement contractuel.

SLA envers les clients : pénalités et crédits de service

Quand un SLA est contractuel — c'est-à-dire un engagement du fournisseur envers les clients — la violation a des conséquences économiques directes, typiquement sous forme de pénalités ou, plus souvent, de crédits de service (service credits). Le mécanisme classique fonctionne ainsi : si la disponibilité descend sous le seuil promis, le client a droit à un remboursement égal à un pourcentage de la redevance payée, croissant à mesure que la violation s'aggrave. Par exemple, un SLA pourrait prévoir un crédit de 10% de la redevance mensuelle si la disponibilité descend sous 99,9%, de 25% sous 99%, et ainsi de suite. Il est important de comprendre quelques aspects pratiques. Les crédits de service sont souvent le seul recours prévu (le client ne peut pas demander plus, sauf cas particuliers), et sont généralement limités à un pourcentage maximum de la redevance. Ils doivent en outre presque toujours être demandés activement par le client dans certains délais, non crédités automatiquement. Du point de vue du fournisseur, les crédits sont une incitation à respecter le SLA, mais couvrent rarement le dommage réel du client (qui peut être bien supérieur à la redevance). Du point de vue du client, un SLA avec des crédits généreux donne une garantie, mais doit être lu avec attention : le pourcentage promis, les exclusions, les limites et les procédures font la différence entre une protection réelle et une formelle. Le calculateur estime le temps d'arrêt et son coût technique ; la valeur des crédits dépend des clauses contractuelles spécifiques.

Les SLA dans le monde des services cloud

Les SLA de disponibilité sont omniprésents dans le monde des services cloud et numériques. Le tableau résume quelques niveaux typiques (indicatifs, chaque fournisseur a ses propres conditions) :

Dans le monde réel, les fournisseurs de services cloud (infrastructure, plateformes, logiciels) offrent des SLA différenciés par tier de service : plus on paie, plus haute est la disponibilité garantie. C'est un sujet universel et international : les mêmes logiques valent partout, car la mathématique de la disponibilité ne dépend pas du pays ou de la monnaie. Quelques observations pratiques. Les SLA les plus élevés (quatre ou cinq neuf) sont généralement réservés aux tiers premium et comportent des conditions plus strictes. De nombreux SLA se réfèrent à des composants individuels (par exemple le calcul, ou le stockage), tandis que la disponibilité de bout en bout perçue par l'utilisateur dépend de la chaîne de tous les composants — et, comme nous le verrons, les dépendances se multiplient, abaissant la disponibilité globale. Les définitions de « temps d'arrêt », les exclusions et les crédits varient beaucoup entre fournisseurs. Le calculateur est paramétrique justement pour s'adapter à n'importe quel SLA : saisissez l'objectif et la période du service qui vous intéresse, et obtenez une estimation concrète. Ceci est une estimation paramétrique, pas un engagement contractuel.

Combien de disponibilité faut-il vraiment : choisir l'objectif

Une des décisions les plus importantes, et le plus souvent mal prise, est le choix de l'objectif de disponibilité. L'instinct est de viser le maximum (« nous voulons cinq neuf ! »), mais c'est presque toujours la mauvaise approche. Le bon objectif dépend d'un équilibre entre la valeur d'une disponibilité plus élevée et son coût. Quelques questions directrices. Quel est le coût réel du temps d'arrêt pour ce service ? Un service interne de reporting et une plateforme de paiements ont des besoins très différents. Quelle est la tolérance des utilisateurs ? Certains services peuvent se permettre de brèves interruptions sans conséquences ; d'autres non. Quel est le coût pour ajouter un neuf ? Comme vu, il croît rapidement. Et, crucial, l'objectif promis est-il réaliste pour l'architecture actuelle ? Promettre une disponibilité que l'on ne peut pas tenir est contre-productif : cela génère des violations, des pénalités et une perte de confiance. La règle d'or du SRE est que la fiabilité devrait être « assez élevée » pour les utilisateurs, pas « maximale » dans l'absolu : au-delà d'un certain point, les utilisateurs ne perçoivent même pas l'amélioration, mais le coût continue de croître. Le calculateur aide à rendre ce choix concret : essayez différents objectifs et périodes, regardez le temps d'arrêt autorisé et le coût, et trouvez le bon point d'équilibre pour votre cas. Ceci est une estimation paramétrique, pas un engagement contractuel.

Limites du calcul

Ce calculateur fournit une estimation paramétrique de la relation entre objectif de disponibilité, temps d'arrêt autorisé, error budget et coût, pas un engagement contractuel ni une mesure officielle de la disponibilité. Le calcul suppose une définition « simple » du temps d'arrêt comme temps d'indisponibilité sur la période, alors qu'en pratique la définition du temps d'arrêt aux fins du SLA est souvent complexe : ce qui compte comme « down » (indisponibilité totale ? dégradation des performances ? erreurs sur une partie des requêtes ?), comment il se mesure (d'où, avec quelle granularité), et ce qui est exclu (maintenance, force majeure, tiers). Le modèle considère une seule exclusion (la maintenance planifiée), alors que les SLA réels en prévoient beaucoup. Il ne calcule pas les crédits de service effectifs (qui dépendent des clauses contractuelles), ne modélise pas la disponibilité cumulée de plusieurs composants en série ou en parallèle, ne considère pas la distribution temporelle du temps d'arrêt (une seule longue interruption et de nombreuses brèves ont des impacts différents même à minutes totales égales), ni le coût réel du temps d'arrêt (qui est ici une simple multiplication, alors qu'en réalité il varie avec le moment, la durée et le type de service). Utilisez le résultat pour comprendre la logique de la disponibilité — en particulier la mathématique des « neuf » et le concept d'error budget — et pour des estimations d'ordre de grandeur, mais pour des engagements contractuels et des mesures précises fiez-vous à des outils de surveillance dédiés et à une définition rigoureuse du SLA. Ceci n'est pas une garantie de service.

SLA, SLO et SLI : qui fait quoi

Dans le monde de la fiabilité des services, on utilise trois sigles qui se confondent facilement mais ont des rôles distincts : SLA, SLO et SLI. Le tableau les clarifie :

La relation entre les trois est hiérarchique et logique. Le SLI (Service Level Indicator) est la mesure : un nombre concret qui décrit le comportement du service, par exemple le pourcentage de requêtes servies correctement ou dans un certain temps. Le SLO (Service Level Objective) est l'objectif que l'équipe se fixe sur cet indicateur : « nous voulons que le SLI reste au-dessus de 99,95% ». C'est une cible interne, la référence pour l'error budget. Le SLA (Service Level Agreement) est l'engagement contractuel envers les clients, avec des conséquences (pénalités, crédits) s'il est violé. Une bonne pratique est de garder le SLO plus strict que le SLA : si vous vous engagez contractuellement à 99,9% (SLA) mais visez internement 99,95% (SLO), vous avez une marge de sécurité — quand vous dépassez l'objectif interne, vous avez encore de l'espace avant de violer l'engagement externe. Confondre ces concepts mène à des erreurs : promettre aux clients (SLA) le même niveau que l'on espère atteindre en interne (SLO) est risqué. Le calculateur travaille sur le concept général d'objectif de disponibilité ; vous pouvez l'utiliser aussi bien pour un SLO interne que pour un SLA contractuel. Ceci est une estimation paramétrique, pas un engagement contractuel.

Disponibilité cumulée : pourquoi les dépendances comptent

Un aspect contre-intuitif et crucial est que la disponibilité d'un service composé de plusieurs composants en série (où chacun doit fonctionner pour que l'ensemble fonctionne) est inférieure à celle des composants individuels : les disponibilités se multiplient. Le tableau montre l'effet, en supposant que chaque dépendance ait une disponibilité de 99,9% :

La mathématique est impitoyable : si votre service dépend de dix composants, chacun avec un excellent 99,9%, la disponibilité de bout en bout perçue par l'utilisateur descend à environ 99,0% — avec plus de 7 heures de temps d'arrêt par mois, un ordre de grandeur pire que le composant individuel. Cela explique un phénomène courant : un service peut utiliser des fournisseurs cloud promettant chacun une disponibilité très élevée, et malgré cela offrir à ses propres utilisateurs une disponibilité nettement inférieure, car la chaîne de dépendances multiplie les petits temps d'arrêt de chacun. Les contre-mesures sont l'opposé de la série : la redondance en parallèle (avoir des composants alternatifs qui se remplacent mutuellement) augmente la disponibilité au lieu de la réduire, car le système reste up tant qu'au moins un fonctionne. Concevoir pour la fiabilité signifie donc minimiser les dépendances critiques en série et ajouter de la redondance là où cela compte. Le calculateur estime la disponibilité d'un seul service ou composant ; pour la disponibilité cumulée d'une architecture complexe il faut modéliser la chaîne de dépendances. Ceci est une estimation paramétrique, pas un engagement contractuel.

Comment améliorer la disponibilité : redondance et résilience

Augmenter la disponibilité — c'est-à-dire ajouter des « neuf » — requiert des investissements en redondance et résilience, avec un coût croissant. Les leviers principaux. La redondance : éliminer les « single points of failure » en ayant des composants dupliqués (serveurs, bases de données, zones géographiques) qui prennent le relais en cas de panne. Le failover automatique : des mécanismes qui déplacent le trafic vers un composant sain sans intervention manuelle, réduisant drastiquement le temps de reprise. La surveillance et l'alerte : détecter les problèmes vite (idéalement avant les utilisateurs) pour intervenir immédiatement. L'automatisation de la réponse : des procédures automatiques qui gèrent les scénarios courants sans attente humaine. La réduction du rayon d'impact (blast radius) : concevoir le système de sorte qu'une panne dans une partie n'abatte pas l'ensemble. Les tests de résilience (y compris le « chaos engineering », qui introduit des pannes contrôlées pour vérifier la robustesse). Et, non des moindres, les processus : procédures de réponse aux incidents, équipes d'astreinte, analyse post-incident sans culpabilisation pour apprendre des erreurs. Le point clé est que chaque neuf supplémentaire coûte plus que le précédent : passer de 99,9% à 99,99% requiert typiquement un effort bien plus grand que de 99% à 99,9%. C'est pourquoi le choix de l'objectif doit se faire avec le coût du temps d'arrêt en main, comme le montre le calculateur. Ceci est une estimation paramétrique, pas un engagement contractuel.

Le rôle de la surveillance : mesurer la disponibilité réelle

Une disponibilité déclarée vaut peu sans une surveillance sérieuse qui la mesure. Et ici émergent des questions subtiles mais décisives : d'où mesure-t-on la disponibilité ? Un service peut apparaître « up » depuis le data center mais « down » pour un utilisateur dans une autre région, à cause d'un problème réseau. Que mesure-t-on exactement ? La simple joignabilité du serveur, ou le fait que le service réponde correctement et dans un temps raisonnable ? Un serveur qui répond mais avec des erreurs, ou très lentement, est techniquement « up » mais de fait inutilisable. À quelle fréquence échantillonne-t-on ? Un contrôle toutes les cinq minutes peut « rater » une interruption de deux minutes. C'est pourquoi la surveillance moderne combine plusieurs approches : contrôles externes depuis plusieurs localités (pour voir le service comme les utilisateurs le voient), surveillance interne des composants, et de plus en plus la mesure basée sur l'expérience réelle des utilisateurs (combien de requêtes réussissent, avec quelle latence). La mesure de la disponibilité est donc elle-même un choix de conception : définir le SLI (l'indicateur) de sorte qu'il capture ce qui compte pour les utilisateurs est la moitié du travail. Une disponibilité « de 99,9% » mal mesurée peut cacher une expérience utilisateur bien pire. Le calculateur travaille sur le temps d'arrêt que vous saisissez ; la qualité de cette donnée dépend de la qualité de votre surveillance. Ceci est une estimation paramétrique, pas un engagement contractuel.

Questions à poser avant de signer un SLA

Que vous soyez le fournisseur qui offre un SLA ou le client qui l'évalue, quelques questions sont essentielles. Quelle est la définition exacte de « temps d'arrêt » ? Indisponibilité totale, dégradation, erreurs sur une partie des requêtes ? C'est le point le plus important et le plus souvent ambigu. D'où et comment mesure-t-on la disponibilité, et à quelle fréquence ? Qu'est-ce qui est exclu du comptage — maintenance planifiée (avec combien de préavis ?), force majeure, problèmes de tiers, causes du client ? Sur quelle période le SLA est-il défini (mensuel, annuel) ? À pourcentage égal, une période plus courte est plus sévère. Quels sont les recours en cas de violation — crédits de service ? De quelle ampleur, avec quelles limites et comment les demander ? La disponibilité se réfère-t-elle au composant individuel ou au service de bout en bout ? Et, pour le client : le SLA couvre-t-il vraiment mon risque, ou les crédits sont-ils symboliques par rapport au dommage que je subirais ? Pour le fournisseur : l'objectif promis est-il réaliste pour mon architecture, ou m'expose-je à des violations continues ? Ces questions montrent qu'un SLA est bien plus que le seul pourcentage de disponibilité : les définitions, les exclusions et les recours font la différence entre une protection réelle et une de façade. Le calculateur vous aide à traduire le pourcentage en temps d'arrêt concret et à raisonner sur le coût ; pour l'évaluation contractuelle complète, lisez chaque clause avec attention. Ceci est une estimation paramétrique, pas un engagement contractuel.

Questions fréquentes

Combien de temps d'arrêt permet une disponibilité de 99,9% ?

Environ 43,2 minutes par mois (sur 30 jours) ou environ 8,77 heures par an. 99,9% (« trois neuf ») signifie que 0,1% du temps peut être de l'indisponibilité. Cela semble peu, mais traduit en minutes réelles c'est plus que beaucoup ne l'imaginent. Le calculateur convertit n'importe quel objectif SLA en temps d'arrêt autorisé pour la période que vous indiquez, montrant la mathématique des « neuf ».

Quelles données me faut-il pour utiliser le calculateur ?

Cinq valeurs : l'objectif SLA de disponibilité (%), la période en jours, le temps d'arrêt total observé en minutes, l'éventuelle maintenance planifiée à exclure et le coût du temps d'arrêt par minute. Le calculateur renvoie le temps d'arrêt autorisé (error budget), la disponibilité effective, le pourcentage d'error budget consommé et le coût du temps d'arrêt comptabilisé.

Comment se calcule le temps d'arrêt autorisé ?

On convertit la période en minutes (jours × 1440) et on multiplie par la part de temps d'arrêt autorisée, soit un moins l'objectif divisé par 100. En formule : D_max = (1 − s/100) × P, où s est l'objectif SLA et P les minutes de la période. Par exemple, 99,9% sur 30 jours : 43 200 × 0,001 = 43,2 minutes. Le calculateur fait cela et compare votre temps d'arrêt observé avec le budget.

Qu'est-ce que la mathématique des « neuf » ?

C'est le fait que chaque chiffre « neuf » supplémentaire de disponibilité réduit le temps d'arrêt autorisé de dix fois. 99% permet ~7,2 heures par mois, 99,9% ~43 minutes, 99,99% ~4 minutes, 99,999% ~26 secondes. De petites différences en pourcentage correspondent à des différences énormes en temps réel — et obtenir chaque neuf supplémentaire coûte de façon disproportionnée (redondance, automatisation, bascule).

Qu'est-ce que l'error budget ?

C'est un concept SRE (Site Reliability Engineering) : si l'objectif est 99,9%, les 0,1% de temps d'arrêt ne sont pas un échec à éviter à tout prix, mais un « budget » à dépenser. Vous pouvez le « dépenser » pour publier de nouvelles fonctionnalités, faire de la maintenance, absorber les imprévus. Tant que vous restez dans le budget, tout va bien. C'est un outil de gouvernance qui équilibre fiabilité et innovation : si vous le consommez trop vite, ralentissez les déploiements.

Le calcul dépend-il de la monnaie ?

Non. Le calculateur est neutre vis-à-vis de la monnaie : saisissez le coût du temps d'arrêt par minute dans votre monnaie et obtenez des résultats cohérents (le temps d'arrêt est en minutes, la disponibilité en pourcentage). C'est un sujet universel et international, car la mathématique de la disponibilité ne dépend pas du pays ou de la monnaie. Les mêmes logiques valent partout.

Qu'est-ce qu'un SLA exclut du comptage du temps d'arrêt ?

La plus courante est la maintenance planifiée (fenêtres communiquées à l'avance). Autres exclusions fréquentes : causes de force majeure, problèmes attribuables au client, interruptions de tiers (fournisseurs externes, connectivité), certains événements de sécurité. Le temps d'arrêt « réel » perçu et celui « comptabilisé » aux fins du SLA peuvent différer beaucoup. Dans le calculateur vous pouvez exclure la maintenance planifiée ; les autres exclusions dépendent du contrat.

Que sont les crédits de service (service credits) ?

Ce sont le recours typique quand un fournisseur viole un SLA contractuel : le client a droit à un remboursement égal à un pourcentage de la redevance, croissant à mesure que la violation s'aggrave. Ils sont souvent le seul recours prévu, limités à un maximum, et doivent généralement être demandés activement dans certains délais. Ils couvrent rarement le dommage réel du client. La valeur dépend des clauses spécifiques.

Pourquoi le coût du temps d'arrêt compte-t-il ?

Parce qu'il permet des décisions rationnelles. Connaître le coût par minute aide à justifier les investissements en fiabilité (si une minute coûte X, combien vaut la réduction du temps d'arrêt ?) et à choisir le bon objectif, en équilibrant le coût de plus de disponibilité avec le coût du temps d'arrêt évité. Le coût inclut revenus perdus, productivité, récupération, pénalités et dommage réputationnel.

99,99% est-il toujours meilleur que 99,9% ?

Pas nécessairement. Une disponibilité plus élevée est plus difficile et coûteuse à garantir : chaque neuf supplémentaire coûte de façon disproportionnée. Le bon objectif dépend du coût du temps d'arrêt, de la tolérance des utilisateurs et du coût d'ajouter un neuf. La règle SRE est que la fiabilité devrait être « assez élevée » pour les utilisateurs, pas « maximale » : au-delà d'un certain point les utilisateurs ne perçoivent pas l'amélioration mais le coût croît.

La disponibilité doit-elle se référer à une période ?

Oui, toujours. 99,9% sur un mois et 99,9% sur un an autorisent des temps d'arrêt totaux très différents en valeur absolue (43 minutes contre presque 9 heures). C'est pourquoi il est important de spécifier la période de référence. Dans le calculateur vous saisissez la période en jours, et obtenez le temps d'arrêt autorisé pour cette période spécifique. Vérifiez toujours sur quelle période est défini le SLA que vous évaluez.

Le résultat est-il fiable ?

C'est une estimation paramétrique de la logique de disponibilité, pas un engagement contractuel ni une mesure officielle. Il suppose une définition simple du temps d'arrêt et une seule exclusion (maintenance), alors que les SLA réels sont plus complexes (définition de « down », mesure, nombreuses exclusions, crédits, disponibilité cumulée de plusieurs composants). Utilisez-le pour comprendre la logique des « neuf » et de l'error budget et pour des estimations d'ordre de grandeur ; pour des engagements et des mesures précises utilisez des outils de surveillance.

Mis à jour en juillet 2026