Ressources
SLA SaaS : quel taux de disponibilité financer avant de le promettre ?
Avant de signer un SLA SaaS, choisissez le parcours, la mesure et le budget d'indisponibilité à financer, avec le coût marginal de trois options.
L'équipe CTN Solutions · publié le · 15 min de lecture
Faits vérifiés sur les sources primaires le
Imaginons qu'un client demande 99,95 % de disponibilité dans le contrat. Pendant le même mois, la connexion de vos utilisateurs tombe pendant 95 minutes à deux heures du matin, quand personne ne se connecte. Selon ce que vous mesurez, cet incident consomme 0 % du budget ou une part importante du budget. Dans le même temps, un devis de redondance promet davantage de disponibilité sans dire quel parcours il protège.
Avant d'écrire un pourcentage dans un contrat, trois questions se tranchent dans cet ordre : quels parcours doivent fonctionner, ce que le pourcentage mesure réellement, et combien coûte chaque niveau supplémentaire, parcours par parcours.
Trois sigles reviennent. Le SLI (indicateur de niveau de service) est la mesure, par exemple la part de connexions réussies. Le SLO (objectif de niveau de service) est la cible interne fixée sur cette mesure. Le SLA (accord de niveau de service) est l'engagement envers le client, avec ses conséquences si l'objectif n'est pas atteint. Un SLA ne devrait pas être plus exigeant que le SLO interne qui le justifie.
Nommer les parcours avant de choisir un pourcentage
Exemple : un éditeur de logiciel de gestion pour des PME compte trois parcours. Une connexion interactive, un export généré en différé et une clôture mensuelle n'ont ni la même population, ni la même fenêtre d'usage, ni le même coût d'échec : une cible unique protège mal les trois.
Le tableau les décrit avant tout chiffrage. Les chiffres sont des hypothèses à remplacer par les vôtres.
| Parcours | Utilisateurs | Fenêtre utile | Événement réussi | Conséquence d'un échec : bas / central / haut |
|---|---|---|---|---|
| Connexion interactive | 4 000 comptes, 1 200 en pointe | jours ouvrés de 7 h à 20 h | authentification et page en moins de 2 secondes | une minute perdue / un appel au support, 30 minutes / une formation client interrompue |
| Export différé | 350 comptes | 24 h/24 | export téléchargeable en moins de 30 minutes | attente d'une heure / rattrapage par le support / échéance client manquée |
| Clôture mensuelle | 60 clients entreprises | 3 jours par mois, 72 heures | traitement terminé et contrôles validés avant 6 h le troisième jour | reprise le jour même / demi-journée de retard / clôture client manquée |
Le parcours décide donc de la mesure. La connexion se mesure en tentatives réussies, puisque chaque tentative compte. La clôture ne tourne que trois jours par mois : une mesure faite chaque minute ne la décrit pas.
Ce que le pourcentage mesure réellement
Deux familles de mesure coexistent. La disponibilité temporelle compte les minutes pendant lesquelles le service ne répond pas. La disponibilité par requêtes compte les opérations réussies sur le total des opérations : Google SRE la décrit comme le nombre d'événements satisfaisants divisé par le nombre total d'événements. Les deux se déclarent avant le contrat, parce qu'elles ne donnent pas le même verdict.
La différence se voit sur une nuit. Une simulation d'un mois de 30 jours complets donne : 380 600 tentatives de connexion, réparties sur les jours ouvrés, et quatre incidents. Le premier, une panne totale de 95 minutes à deux heures du matin, n'a touché aucune tentative. Il consomme donc 0 % du budget d'un objectif de 99,5 % mesuré par requêtes. Mesuré en temps, il consomme 44 % du même objectif, soit 95 des 216 minutes tolérées sur le mois.
Consommation du budget sur le mois, par méthode de mesure
Le graphique suit la consommation cumulée d'un objectif de 99,5 % sur cinq jours du mois, selon qu'on compte les requêtes ou les minutes.
Schéma défilable horizontalement ; sa version textuelle complète suit.
Lire le schéma sous forme textuelle
- Axe horizontal : cinq jours du mois de 30 jours (jours 3, 9, 16, 23 et 30).
- Jour 3, panne totale de 95 minutes la nuit : 0 % du budget par requêtes, 44,0 % en temps.
- Jour 9 : 23,1 % par requêtes, 49,5 % en temps.
- Jour 16 : 45,2 % par requêtes, 49,5 % en temps.
- Jour 23 : 78,0 % par requêtes, 61,1 % en temps.
- Jour 30 : 78,0 % par requêtes, 61,1 % en temps.
- Ligne brune : budget par requêtes ; ligne bleue : budget en temps. Budget de référence : 1 903 échecs par requêtes et 216 minutes de panne totale.
La suite du mois confirme l'écart. Le jour 16, un incident de 40 minutes avec 30 % d'échecs représente 420 échecs : la mesure par requêtes le compte, la mesure en panne totale l'ignore. Au jour 30, la consommation atteint 78 % du budget par requêtes et 61 % du budget temporel. Deux définitions du même service donnent deux verdicts sur le même mois.
Trois autres choix se fixent avant le contrat : la fenêtre (mois calendaire ou fenêtre glissante), les exclusions de maintenance et le point d'observation. Une sonde synthétique, les journaux du répartiteur de charge et la métrique d'âge d'une file ne voient pas les mêmes défaillances. La qualité de la mesure fait donc partie du SLI, comme le détaille Des alertes qui sonnent pour rien : un socle d'observabilité pour une scale-up sans SRE.
Pour la clôture mensuelle, l'unité pertinente n'est ni la requête ni la minute de panne, mais l'exécution attendue : le traitement a-t-il abouti dans la fenêtre convenue ? Le même raisonnement vaut pour tout traitement qui ne tourne qu'à certaines dates.
Budget d'indisponibilité et chaîne de dépendances
Un pourcentage se traduit d'abord en minutes. Sur 30 jours complets, soit 43 200 minutes, 99,9 % laisse 43,2 minutes d'indisponibilité, 99,95 % en laisse 21,6 et 99,99 % en laisse 4,32. Si l'engagement ne porte que sur les heures ouvrées, soit 22 jours de 11 heures ou 14 520 minutes, la même cible à 99,9 % laisse 14,52 minutes. Pour une mesure par requêtes, 99,9 % de succès sur un million d'opérations autorise 1 000 échecs.
| Niveau | 30 jours 24 h/24 (43 200 minutes) | Heures ouvrées (14 520 minutes) | Échecs pour 1 000 000 opérations |
|---|---|---|---|
| 99,5 % | 216 minutes | 72,6 minutes | 5 000 |
| 99,9 % | 43,2 minutes | 14,52 minutes | 1 000 |
| 99,95 % | 21,6 minutes | 7,26 minutes | 500 |
| 99,99 % | 4,32 minutes | 1,452 minute | 100 |
Minutes d'indisponibilité tolérées sur 30 jours complets
Le graphique compare les minutes tolérées sur 30 jours complets pour quatre niveaux de disponibilité.
Schéma défilable horizontalement ; sa version textuelle complète suit.
Lire le schéma sous forme textuelle
- Niveau 99,5 % : 216 minutes sur 30 jours complets.
- Niveau 99,9 % : 43,2 minutes.
- Niveau 99,95 % : 21,6 minutes.
- Niveau 99,99 % : 4,32 minutes.
- Heures ouvrées (14 520 minutes) : 72,6, 14,52, 7,26 et 1,452 minute pour les mêmes niveaux, dans le tableau ci-dessus.
Ces budgets ne disent rien de la durée d'un incident : 43 minutes peuvent être consommées par une seule panne, ou par cent incidents de 26 secondes. Le budget se lit donc avec la mesure choisie au chapitre précédent.
Une dépendance dure multiplie les disponibilités. Une connexion traverse un DNS, un répartiteur de charge, une application, une base de données et un fournisseur d'identité, dont la fiabilité se traite dans Keycloak en haute disponibilité sur Kubernetes : caches, sessions, tests de panne et restauration. Si chaque maillon est disponible à la valeur indiquée, et si la panne d'un seul bloque la connexion, la disponibilité de la chaîne vaut le produit de ses maillons.
De la disponibilité de chaque maillon à la chaîne
Le schéma enchaîne les cinq dépendances d'une connexion et donne la disponibilité résultante.
Schéma défilable horizontalement ; sa version textuelle complète suit.
Lire le schéma sous forme textuelle
- DNS : 99,99 %, soit 4,32 minutes par mois.
- Répartiteur de charge : 99,99 %, soit 4,32 minutes par mois.
- Application : 99,9 %, soit 43,2 minutes par mois.
- Base de données : 99,95 %, soit 21,6 minutes par mois.
- Fournisseur d'identité : 99,9 %, soit 43,2 minutes par mois.
- Chaîne de bout en bout : 99,73 %, soit environ 116,5 minutes par mois, si chaque maillon tombe indépendamment et si la panne d'un seul bloque la connexion.
La chaîne tombe à 99,73 %, soit environ 116,5 minutes par mois. Doubler l'application ne la fait passer qu'à 99,83 %, soit 73,5 minutes : les autres maillons fixent le plafond. Avant de payer une redondance, il faut donc chercher le maillon qui pèse le plus dans le budget. La base de données a sa propre logique de bascule, traitée dans PostgreSQL sur Kubernetes en haute disponibilité : topologies, bascule, RPO et tests de panne, et la reprise après sinistre est un autre sujet, traité dans Plan de reprise d'activité dans le cloud : un PRA n'est pas une politique de sauvegarde.
La redondance suppose des pannes indépendantes. Deux nœuds applicatifs à 99,9 % chacun, indépendants, donnent 99,9999 %, soit 0,04 minute par mois. Si 10 % de leurs pannes frappent les deux nœuds en même temps, à cause d'un déploiement défectueux, d'une configuration commune ou d'une même zone, la paire tombe à 99,9899 %, soit 4,35 minutes par mois. L'indisponibilité devient alors environ cent fois celle que la formule annonce. Le modèle utilise un facteur de cause commune de 10 %.
Indisponibilité mensuelle selon la configuration
Le graphique compare la chaîne actuelle et la même chaîne avec une application doublée, selon l'hypothèse de causes communes.
Schéma défilable horizontalement ; sa version textuelle complète suit.
Lire le schéma sous forme textuelle
- Chaîne en série, un exemplaire de chaque composant : 99,73 %, soit 116,5 minutes par mois.
- Application doublée, pannes indépendantes : 99,83 %, soit 73,5 minutes par mois.
- Application doublée, dont 10 % des pannes touchent les deux nœuds à la fois : 99,82 %, soit 77,8 minutes par mois.
Les fournisseurs publient aussi des engagements, mais chacun a son périmètre :
- Amazon RDS en Multi-AZ : les crédits de service commencent lorsque la disponibilité mensuelle passe sous 99,95 %. La disponibilité y est calculée par intervalles d'une minute, et les exclusions couvrent notamment une capacité d'entrées-sorties insuffisante pour la charge.
- Amazon EKS, plan de contrôle standard : au moins 99,95 % par mois, mesuré par intervalles de 5 minutes. Le périmètre est le plan de contrôle exploité par AWS. Les instances EC2 rattachées au cluster relèvent d'un autre engagement, et vos charges de travail ne sont pas couvertes.
- Amazon EC2 : 99,99 % au niveau de la région seulement lorsque les instances sont réparties sur deux zones de disponibilité ou plus. Une instance isolée relève d'un engagement de 99,5 %. La page porte la date de mise à jour du 25 mai 2022.
Un engagement fournisseur est un crédit sur sa facture, calculé sur son périmètre. Ce n'est ni la disponibilité de votre service, ni une indemnisation de vos clients. Il ne couvre ni votre code, ni vos données, ni votre réseau, ni vos fournisseurs tiers.
Le coût marginal de trois options, parcours par parcours
Chiffrage fondé sur vos données
Trois options sont chiffrées pour chaque parcours. L'option A garde l'objectif actuel et améliore la mesure : une sonde synthétique, un SLI tiré des journaux et un suivi mensuel. L'option B renforce le parcours ciblé : un second nœud ou un second worker dans une autre zone, une base Multi-AZ partagée par les trois parcours et du trafic entre zones. Pour la clôture, elle se limite à un worker de secours allumé 72 heures par mois. L'option C ajoute une seconde région en secours à chaud, commune aux trois parcours.
Les tarifs sont les prix de liste AWS de la région Paris, en dollars. Une instance m6i.large coûte 0,112 USD de l'heure (fichier publié le 7 novembre 2026), une base PostgreSQL db.m6i.large en Multi-AZ 0,412 USD de l'heure (publié le 29 octobre 2026) et un répartiteur de charge 0,02646 USD de l'heure (publié le 5 novembre 2026). La conversion à 0,92 euro le dollar et un taux horaire d'ingénierie de 95 euros sont des paramètres du modèle. Les heures d'ingénierie et d'exploitation sont des hypothèses.
| Parcours | Option A | Option B | Option C |
|---|---|---|---|
| Connexion interactive | 380,00 | 749,80 | 911,73 |
| Export différé | 253,33 | 620,37 | 911,73 |
| Clôture mensuelle | 427,50 | 519,98 | 911,73 |
Les montants sont en euros par mois, part allouée : un composant partagé est réparti entre les parcours qui l'utilisent.
Coût mensuel alloué du parcours connexion
Le graphique montre le coût mensuel alloué des trois options pour le parcours de connexion.
Schéma défilable horizontalement ; sa version textuelle complète suit.
Lire le schéma sous forme textuelle
- Option A, mesurer mieux : 380,00 euros par mois.
- Option B, renforcer le parcours : 749,80 euros par mois, dont 137,57 euros d'infrastructure et 612,22 euros d'ingénierie et d'exploitation (montants arrondis).
- Option C, seconde région : 911,73 euros par mois, dont 109,51 euros d'infrastructure et 802,22 euros d'ingénierie et d'exploitation.
Dans chaque cas, les heures pèsent davantage que l'infrastructure. Pour la connexion, l'option B coûte 137,57 euros d'infrastructure et 612,22 euros d'ingénierie et d'exploitation (montants arrondis). L'option C coûte 109,51 euros d'infrastructure et 802,22 euros d'ingénierie. Sur la facture, la région de secours est visible ; dans l'agenda de l'équipe, ce sont les heures de conception, de tests et de bascule qui pèsent.
Le partage change le total. Si les trois parcours finançaient ensemble l'option C, le coût serait de 2 735 euros par mois. Si chacun la comptait seul, la somme atteindrait 8 206 euros : une seconde région ne se paie qu'une fois. Le même principe vaut pour la base Multi-AZ, partagée entre les trois parcours.
Décider sans promettre : trois issues, dont « information insuffisante »
La règle compare le coût mensuel d'une option au budget qu'elle permet de regagner, valorisé en euros. Le budget regagné est l'écart entre le budget d'échecs à l'objectif actuel et le budget à l'objectif visé, si celui-ci est tenu. Le seuil d'utilisation qui en découle est la part du budget regagné qu'il faut réellement consommer pour que l'option se rembourse.
Pour la connexion, l'option B coûte 749,80 euros par mois et regagne 1 522 échecs par mois. Si un échec coûte 3 euros (scénario central), il faut consommer 16 % de ce gain pour rembourser l'option. Au scénario bas, où un échec coûte 0,50 euro, il faudrait en consommer 99 % : sans consommer la quasi-totalité du gain, l'option ne s'amortit pas. Au scénario haut, où un échec coûte 20 euros, 2 % suffisent.
La règle ajoute une condition de qualité. Si la mesure d'un parcours est évaluée sous 0,6 sur 1, aucune option autre que A ne peut être décidée : la réponse est « information insuffisante ». Dans l'exemple, la connexion est notée 0,7, l'export 0,4 et la clôture 0,5. Quand la mesure manque, le premier euro va à la mesure, pour un coût de 253 à 428 euros par mois selon le parcours.
Le tableau suivant applique la règle à l'exemple, en supposant que 50 % du budget regagné soit réellement consommé.
| Parcours | Option | Scénario bas | Scénario central | Scénario haut |
|---|---|---|---|---|
| Connexion interactive | A : mesurer mieux | financer | financer | financer |
| Connexion interactive | B : renforcer le parcours | refuser | financer | financer |
| Connexion interactive | C : seconde région | refuser | financer | financer |
| Export différé | A : mesurer mieux | financer | financer | financer |
| Export différé | B : renforcer le parcours | information insuffisante | information insuffisante | information insuffisante |
| Export différé | C : seconde région | information insuffisante | information insuffisante | information insuffisante |
| Clôture mensuelle | A : mesurer mieux | financer | financer | financer |
| Clôture mensuelle | B : renforcer le parcours | information insuffisante | information insuffisante | information insuffisante |
| Clôture mensuelle | C : seconde région | information insuffisante | information insuffisante | information insuffisante |
« Information insuffisante » est une issue légitime : elle évite de signer une cible que personne ne sait mesurer.
La décision a une date de révision et des déclencheurs : un nouveau segment de clients, un pic d'usage, un fournisseur critique moins fiable, un incident sur le parcours ou un coût qui dépasse le gain attendu. L'objectif interne reste plus prudent que la promesse commerciale. Le partage des responsabilités avec l'exploitant est traité dans Externaliser l'exploitation cloud et Kubernetes : que confier, à qui et avec quel contrat. Un hébergement spécifique accordé à un grand compte pose une question de contribution plutôt que de fiabilité : il est traité dans Hébergement sur mesure : faut-il accepter ce client SaaS ?.
Périmètre du droit
Pour convenir des objectifs et du périmètre d'exploitation de votre plateforme, voir le périmètre convenu pour l'exploitation de la plateforme.
Sources officielles et limites de lecture
Faits datés
Les pages officielles citées ont été lues le .
Les tarifs sont des prix de liste publiés aux dates indiquées, hors remise, hors taxe et hors facture. Les instances sont comptées sur 730 heures par mois et les budgets sur des mois de 30 jours complets.
Le modèle à cause commune traite une part identique de pannes simultanées sur une paire de nœuds ; il ne couvre ni les causes qui touchent toute la chaîne, ni le DNS ni le fournisseur d'identité. Les pannes de la seconde région, les erreurs humaines pendant une bascule et les coûts de compte, de support et de supervision ne sont pas chiffrés.
Les pages SLA d'Amazon RDS, d'Amazon EKS et d'Amazon EC2 portent respectivement les dates du 22 janvier 2024, du 20 mars 2026 et du 25 mai 2022. La formule régionale d'EC2 doit être relue sur la page en vigueur avant toute reprise.
Sources
- Google SRE, chapitre « Service Level Objectives » : https://sre.google/sre-book/service-level-objectives/, consulté le 9 novembre 2026.
- Google SRE, chapitre « Embracing Risk » : https://sre.google/sre-book/embracing-risk/, consulté le 9 novembre 2026.
- Google SRE Workbook, chapitre « Implementing SLOs » : https://sre.google/workbook/implementing-slos/, consulté le 9 novembre 2026.
- AWS Well-Architected, pilier Fiabilité, « Availability » : https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html, consulté le 9 novembre 2026.
- Amazon RDS, contrat de niveau de service, dernière mise à jour du 22 janvier 2024 : https://aws.amazon.com/rds/sla/, consulté le 9 novembre 2026.
- Amazon EKS, contrat de niveau de service, mise à jour du 20 mars 2026 : https://aws.amazon.com/eks/sla/, consulté le 9 novembre 2026.
- Amazon EC2, contrat de niveau de service, mise à jour du 25 mai 2022 : https://aws.amazon.com/ec2/sla/, consulté le 9 novembre 2026.
- AWS Price List API, index des offres : https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/index.json, consulté le 9 novembre 2026.