99,9 %, 99,99 %, « 11 nines » — les chiffres des SLA cloud sont partout, mais leur signification pratique est mal comprise. Disponibilité et durabilité ne désignent pas la même chose : la disponibilité mesure la probabilité que votre service réponde, la durabilité mesure la probabilité de perdre une donnée. Un bucket S3 affiche 99,9 % de disponibilité mais 99,999999999 % de durabilité (11 nines), et la différence n’est pas un détail marketing. Cette page décode les chiffres, explique les crédits SLA et leurs limites pratiques, liste ce qui n’est pas couvert par les contrats, et défend une opinion : un SLA n’est jamais une assurance, c’est une promesse contractuelle limitée qu’il faut savoir lire.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- La distinction disponibilité vs durabilité et leur formule mathématique
- Comment se traduisent 99,9 %, 99,99 %, « 11 nines » en heures d’indisponibilité ou de perte
- Les SLA réels par service AWS, Azure, GCP, Outscale (extraits clés)
- Le mécanisme des crédits SLA et leurs limites pratiques
- Ce qui n’est pas dans le SLA et qui devrait inquiéter
Prérequis : avoir compris les régions et zones de disponibilité. Si besoin, lisez d’abord Régions et zones de disponibilité.
1. Définitions précises
Section intitulée « 1. Définitions précises »Disponibilité (Availability)
Section intitulée « Disponibilité (Availability) »Définition : pourcentage de temps pendant lequel un service est opérationnel et accessible sur une période donnée (mois, trimestre, année).
Formule :
Disponibilité = Temps opérationnel / Temps totalUne disponibilité de 99,9 % mensuelle signifie que sur les 30 × 24 = 720 heures du mois, le service peut être indisponible maximum 0,1 % × 720 = 0,72 heure, soit ~43 minutes.
Durabilité (Durability)
Section intitulée « Durabilité (Durability) »Définition : probabilité qu’une donnée stockée ne soit pas perdue sur une période donnée (typiquement annuelle).
Formule :
Durabilité = Probabilité de conservation des données / AnUne durabilité de 99,999999999 % (11 nines) signifie que sur 10 milliards d’objets stockés pendant 1 an, on en perd statistiquement 1 seul (par défaillance matérielle, corruption silencieuse, etc.).
Pourquoi cette distinction matter
Section intitulée « Pourquoi cette distinction matter »| Aspect | Disponibilité | Durabilité |
|---|---|---|
| Mesure | Service répond | Données préservées |
| Échelle de temps | Mensuelle | Annuelle |
| Si problème | Le service est inaccessible temporairement | Les données sont perdues définitivement |
| Solution | Redondance multi-AZ, failover | Réplication, backup, versioning |
| Niveau typique | 99,9 % à 99,999 % | 99,999999999 % (11 nines) |
Un service peut avoir une excellente durabilité (les données sont en sécurité) et une disponibilité moyenne (parfois inaccessible) — c’est le cas de S3, qui peut être brièvement indisponible pendant une panne mais ne perd quasiment jamais de données.
2. La table des 9 — convertir les chiffres
Section intitulée « 2. La table des 9 — convertir les chiffres »Les SLA s’expriment en pourcentages, mais leur signification opérationnelle est plus parlante en heures d’indisponibilité par an ou par mois.
Disponibilité mensuelle / annuelle
Section intitulée « Disponibilité mensuelle / annuelle »| SLA | Indispo / mois | Indispo / an |
|---|---|---|
| 99 % | 7h 12min | 87h 36min (3 j 15h) |
| 99,5 % | 3h 36min | 43h 48min (1 j 19h) |
| 99,9 % (« three nines ») | 43min 12s | 8h 45min |
| 99,95 % | 21min 36s | 4h 22min |
| 99,99 % (« four nines ») | 4min 19s | 52min 36s |
| 99,995 % | 2min 9s | 26min 17s |
| 99,999 % (« five nines ») | 25,9s | 5min 15s |
Lecture pratique : passer de 99,9 % à 99,99 % divise l’indisponibilité par 10. Passer de 99,99 % à 99,999 % la divise encore par 10. Mais chaque pas vers le haut coûte exponentiellement plus cher en infrastructure (multi-AZ, multi-région, active-active) et en complexité opérationnelle.
Durabilité — les « nines » du stockage
Section intitulée « Durabilité — les « nines » du stockage »| Durabilité | Pertes statistiques |
|---|---|
| 99,9 % (3 nines) | 1 objet sur 1 000 perdu / an |
| 99,99 % (4 nines) | 1 objet sur 10 000 / an |
| 99,999 % (5 nines) | 1 objet sur 100 000 / an |
| 99,99999999 % (10 nines) | 1 objet sur 10 milliards / an |
| 99,999999999 % (11 nines) | 1 objet sur 100 milliards / an — standard S3 / Cloud Storage |
Lecture pratique : à 11 nines, sur un bucket de 1 milliard d’objets, vous perdez statistiquement 0,01 objet par an. C’est en pratique négligeable comparé à la probabilité que vous-même supprimiez un objet par erreur.
3. SLA réels par service principal
Section intitulée « 3. SLA réels par service principal »Voici les engagements officiels de disponibilité sur les services les plus utilisés en 2026. Ces chiffres sont extraits des SLA contractuels publics des fournisseurs.
| Service | Disponibilité | Durabilité (si stockage) |
|---|---|---|
| AWS EC2 (single instance) | 99,5 % | – |
| AWS EC2 (multi-AZ) | 99,99 % | – |
| AWS S3 Standard | 99,9 % | 99,999999999 % (11 nines) |
| AWS RDS Multi-AZ | 99,95 % | 11 nines (snapshots) |
| Azure VM (single AZ) | 99,9 % | – |
| Azure VM (multi-AZ) | 99,99 % | – |
| Azure Blob Storage LRS | 99,9 % | 11 nines |
| GCP Compute Engine (multi-AZ) | 99,99 % | – |
| GCP Cloud Storage | 99,9 % | 11 nines |
| GCP Spanner | 99,999 % (5 nines) | 11 nines |
| Outscale FCU (multi-subregion) | 99,99 % | – |
Ces chiffres ne sont pas des promesses opérationnelles — ce sont des engagements contractuels au-dessous desquels vous avez droit à un crédit SLA. La disponibilité réelle observée est généralement supérieure (le fournisseur a intérêt à dépasser son engagement), mais elle peut aussi être inférieure sans que vous ne soyez prévenu.
4. Crédits SLA — ce qu’on récupère vraiment
Section intitulée « 4. Crédits SLA — ce qu’on récupère vraiment »Quand le fournisseur rate son SLA, il vous doit un crédit SLA. Ce mécanisme est généralement mal compris — voici les règles réelles.
Le mécanisme
Section intitulée « Le mécanisme »Si la disponibilité mensuelle réelle tombe sous le seuil contractuel, vous avez droit à un crédit sur votre facture du mois suivant. Le crédit est typiquement :
- 10 % de la facture du service concerné si disponibilité < 99,9 % mais ≥ 99 %.
- 25 % si disponibilité < 99 % mais ≥ 95 %.
- 100 % si disponibilité < 95 % (très rare en pratique).
Les conditions cachées
Section intitulée « Les conditions cachées »Trois conditions limitent fortement la portée des crédits SLA en pratique.
Condition 1 — Demande explicite obligatoire. Le crédit n’est jamais automatique. Vous devez ouvrir un ticket dans un délai limité (typiquement 30 jours après la fin du mois concerné), avec preuve documentée de l’indisponibilité (timestamps, logs, captures CloudWatch). Si vous ne réclamez pas, vous ne recevez rien.
Condition 2 — Crédit appliqué sur le service concerné, pas la facture totale. Si EC2 tombe pendant 4 heures et que vous payez 100 € d’EC2 + 1 000 € de RDS dans le mois, le crédit est de 10 € (10 % des 100 € EC2), pas 110 € (10 % du total).
Condition 3 — Plafond de cumul mensuel. Le crédit cumulé ne peut généralement pas dépasser 100 % de la facture du mois sur le service concerné. Donc même si plusieurs services tombent simultanément, vous ne recevez jamais plus que ce que vous avez payé.
Le ratio « impact réel vs crédit reçu »
Section intitulée « Le ratio « impact réel vs crédit reçu » »C’est le point le plus important. Si votre application e-commerce fait 10 000 €/heure de chiffre d’affaires et qu’une panne EC2 de 4 heures tombe vendredi soir, vous perdez 40 000 € de revenus. Le crédit SLA reçu sera de l’ordre de 10–25 € (10 à 25 % de votre facture EC2 mensuelle).
Le SLA n’est pas une assurance — c’est un engagement de qualité de service symbolique, pas une compensation économique des dégâts subis. Cette nuance est centrale.
5. Ce qui n’est pas couvert par le SLA
Section intitulée « 5. Ce qui n’est pas couvert par le SLA »Cinq catégories d’incidents ne déclenchent jamais de crédit SLA, même si elles vous mettent à genoux opérationnellement.
Maintenance planifiée. Le fournisseur annonce typiquement 7 à 30 jours à l’avance qu’il va couper un service pour maintenance. Cette indisponibilité n’est pas comptée dans le SLA — c’est à vous de prévoir le contournement.
Cas de force majeure. Catastrophes naturelles, guerre, pandémie, événements politiques majeurs sont systématiquement exclus. Le contrat AWS, Azure, GCP, Outscale contient tous une clause force majeure qui exonère le fournisseur en cas d’événement extraordinaire.
Votre application. Si votre code applicatif a un bug qui rend votre service inaccessible, ce n’est pas un problème du fournisseur. La VM tournait, le SLA était tenu, c’est votre code qui a planté. La frontière de responsabilité est posée dans Responsabilité partagée.
Votre négligence. Si vous oubliez de payer votre facture cloud et que le fournisseur suspend votre compte, l’indisponibilité qui en résulte n’est pas couverte. De même si vous configurez mal votre VPC, supprimez accidentellement un load balancer, ou révoquez les credentials d’un service critique.
Les attaques DDoS dépassant la capacité protectrice. La plupart des fournisseurs incluent une protection DDoS de base, mais pour les attaques massives (au-delà de plusieurs Tbps), seules les offres premium (AWS Shield Advanced, Azure DDoS Protection Standard) couvrent réellement. Sinon, c’est à vos frais.
6. Comment lire un SLA correctement
Section intitulée « 6. Comment lire un SLA correctement »Voici les questions à poser systématiquement avant de signer un contrat cloud avec engagement de service.
📊 Quel est le périmètre exact ?
Question : le SLA s’applique à quel service précisément ? Une instance unique, un cluster multi-AZ, ou un service managé complet ?
Pourquoi c’est important : EC2 single-instance c’est 99,5 %, EC2 multi-AZ c’est 99,99 %. La différence est massive — 4 heures par mois vs 4 minutes.
🔍 Quelle est la définition d'« indisponible » ?
Question : à partir de quel seuil le service est-il considéré indisponible ? 100 % d’erreurs sur 5 minutes ? 50 % d’erreurs sur 30 minutes ?
Pourquoi c’est important : un service avec 30 % d’erreurs intermittentes peut techniquement « respecter » le SLA sans être réellement utilisable.
🎯 Comment réclamer le crédit ?
Question : quel est le délai de réclamation ? Quels documents fournir ? Auprès de qui ?
Pourquoi c’est important : sans procédure documentée à l’avance, vous oubliez de réclamer et vous perdez vos droits.
💰 Quel est le plafond de crédit ?
Question : le crédit maximum est-il 100 % de la facture du service ou de la facture totale ? Y a-t-il un plafond annuel cumulé ?
Pourquoi c’est important : le plafond limite l’effet réel des crédits sur votre TCO.
7. Comment lire un SLA et en tirer une décision
Section intitulée « 7. Comment lire un SLA et en tirer une décision »Un SLA (Service Level Agreement) mesure l’engagement contractuel du fournisseur sur la disponibilité ou la durabilité d’un service. Il n’est pas une garantie absolue de fonctionnement, et les compensations qu’il prévoit ne couvrent pas la perte économique d’une panne. Comprendre comment le lire évite plusieurs erreurs courantes.
Distinguer le SLA fournisseur et le SLA cible interne. Le SLA affiché par le fournisseur s’applique au service tel qu’il est livré : une instance unique à 99,5 %, un service multi-AZ à 99,99 %, un service multi-région à 99,999 %. Si l’application a besoin d’une disponibilité supérieure à celle d’une instance simple, c’est l’architecture déployée par l’équipe qui doit la fournir. Architecturer pour le SLA cible interne consiste à choisir multi-AZ, multi-région, redondance applicative — selon le niveau visé.
Comprendre la portée des crédits SLA. Quand un SLA est manqué, le fournisseur octroie généralement un crédit sous forme d’avoir sur la facture du service concerné, plafonné à 10–25 % de cette facture. Ce crédit compense rarement la perte économique réelle d’une panne (chiffre d’affaires perdu, communication client, traitement manuel). Pour les activités sensibles à la disponibilité, la couverture financière passe plutôt par une assurance perte d’exploitation souscrite auprès d’un assureur classique — c’est ce mécanisme qui prend en charge le coût économique d’une indisponibilité.
Anticiper la maintenance planifiée. La maintenance annoncée par le fournisseur est généralement exclue du SLA : elle ne compte pas comme une indisponibilité au sens contractuel. Pourtant, une maintenance qui coupe une zone pendant plusieurs heures a, du point de vue applicatif, le même effet qu’une panne. Mettre en place des runbooks pour les maintenances annoncées (bascule trafic, vérifications, rollback) est aussi important que le plan DR pour les pannes inattendues. Ce sujet est détaillé dans Résilience cloud : HA, DR, chaos engineering.
Lire les exclusions avant de signer. La section « exclusions » d’un SLA précise les cas où l’engagement ne s’applique pas : maintenance planifiée, force majeure, défaut applicatif côté client, dépassement de quota, attaque DDoS hors offre premium. Ces exclusions définissent en réalité le périmètre effectif de l’engagement, et leur lecture attentive change souvent l’évaluation faite à partir du seul pourcentage affiché.
À retenir
Section intitulée « À retenir »- Disponibilité = service répond ; durabilité = données préservées. Les deux sont distinctes et complémentaires.
- 99,9 % = ~43 min d’indisponibilité par mois ; 99,99 % = ~4 min ; 99,999 % = 25 secondes.
- La durabilité 11 nines (S3, Cloud Storage) signifie 1 objet perdu sur 100 milliards par an — négligeable en pratique.
- Les crédits SLA sont symboliques — typiquement 10–25 % de la facture du service, plafonnés, à réclamer activement.
- Cinq catégories ne sont pas couvertes : maintenance planifiée, force majeure, votre application, votre négligence, DDoS hors offre premium.
- Le SLA n’est pas une assurance — architecturer pour son besoin réel, assurer son activité par contrat séparé si critique.