Qu'est-ce que l'uptime et pourquoi il compte
· 5 min de lecture
L'uptime est le pourcentage de temps ou le site est disponible. 99 % vaut plus de trois jours de panne par an; visez 99,9 % avec alerte rapide.
Définition : ce que l'on mesure exactement
L'uptime est le rapport entre le temps pendant lequel le service répond comme prévu (typiquement HTTP 200, contenu contenant un mot-clé) et le temps total de mesure. Exprimé en pourcentage, le plus souvent sur une période de 30 ou 365 jours.
L'inverse est le downtime - le temps où le service ne répond pas, renvoie 5xx ou prend plus de temps que le timeout fixé. Cela inclut aussi la maintenance planifiée, sauf si vous l'excluez explicitement du calcul (ce que vous devriez communiquer dans le SLA).
Le tableau des "neufs" : combien de temps chaque décimale représente
| Uptime | Downtime autorisé / an | Mois | Jour |
|---|---|---|---|
| 99 % | 3 jours 15 h | 7 h 18 min | 14 min |
| 99,5 % | 1 jour 19 h | 3 h 39 min | 7 min |
| 99,9 % (three nines) | 8 h 45 min | 43 min | 1 min 26 s |
| 99,95 % | 4 h 22 min | 21 min | 43 s |
| 99,99 % (four nines) | 52 min | 4 min 22 s | 8,6 s |
| 99,999 % (five nines) | 5 min 15 s | 26 s | 0,86 s |
Chaque neuf supplémentaire multiplie les coûts d'infrastructure. Five nines (99,999 %) est le domaine des fournisseurs globaux avec redondance active inter-continentale - pour la plupart des applications métier, 99,9 % est le bon objectif.
Quel uptime vous faut-il vraiment
- Site marketing (entreprise, portfolio) : 99 % suffisent. Un visiteur arrivé pendant une panne réessaiera plus tard.
- App SaaS avec client desktop : 99,9 % est le minimum. Les clients paient pour un travail qu'ils ne peuvent pas faire pendant le downtime.
- E-commerce, passerelle de paiement, service temps réel : 99,95 % et plus. Chaque minute = pertes directes.
- Infrastructure (API utilisée par d'autres) : Au moins 99,99 %. Votre SLA plafonne le SLA de vos clients.
Comment l'uptime est mesuré
Le service de monitoring appelle périodiquement votre endpoint (typiquement HTTP GET, mais aussi socket TCP, ping ICMP ou résolution DNS). Chaque vérification a un résultat binaire : up ou down.
Un intervalle courant est de 1-5 minutes. Plus c'est court, plus vite vous attrapez une panne, mais plus vous recevez d'alertes faux positifs (un glitch réseau local, un redémarrage rapide lors d'un deploy). La solution est la vérification multi-région : une panne n'est confirmée que lorsque N régions la signalent, pas une seule.
Sources les plus fréquentes de "neufs perdus"
- Certificat SSL/TLS expiré. Le navigateur bloque la page. Sans monitoring, vous le savez lundi matin quand le téléphone sonne.
- Expiration du domaine. Tout le DNS cesse de fonctionner. Email, web et page de statut - tout tombe en même temps.
- Worker de base de données planté. Le site renvoie 500 ou part en timeout pour une partie des requêtes. Un ping classique passe peut-être quand même, alors que l'application est cassée.
- DDoS ou flooding. Serveur saturé, le temps de réponse grimpe au-dessus de la limite et le monitoring signale une panne.
- Deploy raté. Une nouvelle version a un bug qui casse un chemin. Sans tests d'intégration, vous le découvrez quand les clients commencent à se plaindre.
Conclusion
L'uptime n'est pas un chiffre marketing - c'est la mesure de la confiance que vous pouvez accorder à votre propre infrastructure. 99,9 % d'uptime n'est pas un luxe, c'est une exigence standard pour tout service qui génère du chiffre d'affaires ou a des clients payants.
L'étape un est de mesurer. Sans monitoring externe, techniquement vous ne savez pas quel uptime vous avez - vous l'estimez seulement.
Commencez à mesurer l'uptime de vos services
ePulz.io suit vos endpoints à des intervalles à partir d'1 minute depuis plusieurs régions. 7 jours gratuits.
Essayez ePulz.io gratuitement - 7 jours sans carte de crédit.
Créer un compte