Suivi des SLA : comment mesurer et présenter un uptime à 99,9 %

« Nous garantissons 99,9 % d’uptime. » C’est une promesse que la plupart des entreprises SaaS font. Mais combien peuvent réellement le prouver ? Le suivi des SLA transforme cette promesse marketing en engagement mesurable et vérifiable.

Comprendre les SLA d’uptime

Que signifie réellement « 99,9 % d’uptime » ?

Les chiffres impressionnent, mais l’écart entre chaque « neuf » est important :

| SLA | Indisponibilité annuelle | Indisponibilité mensuelle |
|-----|--------------------------|----------------------------|
| 99 % | 3 jours, 15 heures | 7 h 18 min |
| 99,5 % | 1 jour, 19 heures | 3 h 39 min |
| 99,9 % | 8 h 46 min | 43 min 50 s |
| 99,95 % | 4 h 23 min | 21 min 55 s |
| 99,99 % | 52 min 36 s | 4 min 23 s |

À 99,9 %, vous avez moins de 44 minutes d’indisponibilité autorisée par mois. Cela inclut la maintenance planifiée, les pannes inattendues et les dégradations partielles. C’est un budget serré.

SLA vs SLO vs SLI

Ces termes sont souvent confondus :

• SLI (Service Level Indicator) — La métrique mesurée : pourcentage d’uptime, temps de réponse, taux d’erreur.
• SLO (Service Level Objective) — Votre objectif interne : « L’API doit être disponible 99,95 % du temps. »
• SLA (Service Level Agreement) — L’engagement contractuel avec conséquences financières : « Si l’uptime passe sous 99,9 %, les clients reçoivent des crédits de service. »

Votre SLO doit être plus strict que votre SLA. Si votre SLA promet 99,9 %, votre cible interne devrait être 99,95 % ou plus. Vous gardez ainsi une marge avant que les violations de SLA ne déclenchent des pénalités financières.

Comment mesurer l’uptime

La formule de base

```
Uptime % = ((Minutes totales − Minutes d’indisponibilité) / Minutes totales) × 100
```

Pour un mois de 30 jours (43 200 minutes) :

• 20 minutes d’indisponibilité = 99,954 % d’uptime
• 44 minutes d’indisponibilité = 99,898 % d’uptime (violation du SLA à 99,9 %)
• 120 minutes d’indisponibilité = 99,722 % d’uptime

Qu’est-ce qui compte comme indisponibilité ?

C’est là que ça se complique. Votre SLA doit définir clairement :

Compte généralement comme indisponibilité :

• Indisponibilité complète du service (erreurs 5xx, timeouts)
• Dégradation sévère des performances (temps de réponse > 10× la normale)
• Échecs d’authentification empêchant l’accès
• Perte ou corruption de données

Exclut généralement :

• Fenêtres de maintenance planifiée (avec préavis)
• Cas de force majeure (catastrophes naturelles, pannes internet majeures)
• Problèmes causés par le client (appels API mal configurés)
• Dépendances tierces hors de votre contrôle

Documentez ces définitions dans votre SLA. L’ambiguïté ne profite à personne.

Monitoring pour la conformité SLA

Pour suivre l’uptime avec précision aux fins de SLA :

Vérifiez souvent : des intervalles de 1 minute ou 30 secondes donnent des mesures d’indisponibilité précises. Un intervalle de 5 minutes signifie que vos mesures ne sont précises qu’à ±5 minutes près — ce qui compte lorsque votre budget mensuel est de 44 minutes.

Surveillez depuis plusieurs emplacements : une panne qui n’affecte que les utilisateurs européens reste une panne. Le monitoring multi-régions permet de repérer les problèmes localisés.

Suivez l’uptime par composant : votre SLA peut couvrir le service global, mais le suivi par composant aide à identifier les maillons faibles : « Notre API était à 99,99 % d’uptime, mais le système de livraison des webhooks n’a atteint que 99,7 %. »

Excluez les fenêtres de maintenance : si votre SLA autorise la maintenance planifiée, assurez-vous que votre outil de monitoring prend en charge les fenêtres de maintenance pour que ces périodes ne comptent pas contre l’uptime.

Construire un rapport SLA

Métriques essentielles

Chaque rapport SLA devrait inclure :

1. Pourcentage d’uptime global — Le chiffre principal.
2. Nombre d’Incidents — Combien de fois le service est tombé.
3. Indisponibilité totale — Minutes ou heures d’indisponibilité agrégées.
4. Mean Time to Detect (MTTD) — Délai pour détecter chaque problème.
5. Mean Time to Recovery (MTTR) — Délai pour résoudre chaque problème.
6. Incident le plus long — Votre pire panne sur la période.
7. Comparaison de tendance — Comment cette période se compare aux précédentes.

Fréquence des rapports

• Mensuel : standard pour la plupart des accords SLA. Inclure les métriques ci-dessus plus une liste d’Incidents avec horodatages et descriptions.
• Trimestriel : format de revue business. Tendances, initiatives d’amélioration et plans d’investissement infrastructure.
• Annuel : vue stratégique pour la direction et les clients enterprise. Comparaisons année sur année et feuille de route fiabilité.

Rendre les rapports actionnables

Un rapport qui se limite à « 99,94 % d’uptime » est peu utile. Associez-le à :

• Détail des Incidents : ce qui s’est passé, comment c’était détecté, comment c’était corrigé, et ce qui est fait pour éviter la récidive.
• Suivi du error budget : si votre SLA est à 99,9 % et que vous avez utilisé 30 de vos 44 minutes d’indisponibilité autorisées ce mois-ci, l’équipe sait qu’elle doit être prudente sur les déploiements risqués.
• Analyse de tendance : l’uptime s’améliore ou se dégrade ? Les Incidents sont-ils plus ou moins fréquents ?

Stratégies pour maintenir un uptime élevé

Gestion du error budget

Le concept de « error budget » du cadre SRE de Google est puissant. Votre error budget est la différence entre 100 % et votre cible SLO.

Pour un SLO à 99,9 % sur 30 jours, votre error budget est de 43 minutes.

Tant que vous êtes dans le budget, vous pouvez aller vite — déployer souvent, expérimenter, prendre des risques calculés. Quand il reste peu de marge, ralentissez — figez les déploiements non critiques, augmentez les tests, concentrez-vous sur la fiabilité.

Investir aux bons endroits

Toutes les améliorations d’uptime ne se valent pas. Concentrez-vous sur :

1. Supprimer les points de défaillance uniques — La base sans réplica, le serveur sans basculement, le DNS sans secours.
2. Réduire le risque de déploiement — Blue-green, canary, rollbacks automatisés pour éviter les pannes liées aux mises en production.
3. Accélérer la détection — Une détection plus rapide signifie des pannes plus courtes. La différence entre 15 secondes et 5 minutes peut faire la différence entre conformité SLA et violation.
4. Automatiser la récupération — Systèmes auto-réparateurs qui redémarrent les processus, réacheminent le trafic et mettent à l’échelle automatiquement.

Utiliser un Status Page pour la transparence

Un Status Page public n’améliore pas directement l’uptime, mais transforme la perception de votre fiabilité :

• Communication proactive pendant les Incidents : confiance
• Historique des Incidents : votre bilan
• Notifications aux abonnés : clients informés
• Transparence : moins de tickets support

Conclusion

Le suivi des SLA ne se limite pas à la conformité contractuelle — c’est construire une culture de fiabilité. Lorsque vous mesurez l’uptime rigoureusement, le rendez compte de façon transparente et gérez votre error budget avec intention, vous créez une boucle d’amélioration continue.

Commencez par définir des cibles d’uptime claires, mettre en place un monitoring précis et rendre compte honnêtement. Les chiffres suivront.

Suivez votre SLA avec précision. Commencer le monitoring gratuitement — rapports d’uptime détaillés, suivi des Incidents et Status Pages inclus.