Taux de disponibilité : comprendre les 99,9 % et ce qu'ils impliquent

Le taux de disponibilité (uptime) est souvent cité sans que ses implications concrètes soient comprises. 99,9 % de disponibilité, c'est environ 8,7 heures d'indisponibilité par an — soit potentiellement une nuit entière sans service. 99,99 %, c'est moins d'une heure par an.

Comprendre ces chiffres est nécessaire pour définir des SLAs réalistes et choisir les investissements d'infrastructure adaptés à votre tolérance au risque.

La réalité des niveaux de disponibilité

Référence rapide :

  • 99 % → 87,6 heures d'indisponibilité par an (3,6 jours)
  • 99,9 % → 8,7 heures par an
  • 99,95 % → 4,4 heures par an
  • 99,99 % → 52 minutes par an
  • 99,999 % → 5 minutes par an (5 nines, standard des télécoms)

Pour la plupart des applications SaaS B2B, un objectif de 99,9 % est réaliste et suffisant. Les 99,99 % nécessitent une architecture redondante avec basculement automatique, ce qui multiplie les coûts d'infrastructure.

Ce qui impacte la disponibilité

Déploiements : sans CI/CD avec déploiement zero-downtime, chaque déploiement est une fenêtre d'indisponibilité. La mise en place de blue-green deployments ou de rolling updates élimine ce point.

Dépendances tierces : si votre application dépend d'une API tierce qui tombe, votre taux de disponibilité en est affecté même si votre code est parfait. Une stratégie de dégradation gracieuse (fallback quand la dépendance est indisponible) améliore la résilience.

Base de données : une base de données sans réplication est un single point of failure. Un problème sur le serveur de base de données = indisponibilité totale.

Améliorer le taux de disponibilité

Par ordre de priorité et d'impact : mettre en place le monitoring de disponibilité (pour mesurer et être alerté), configurer les déploiements zero-downtime, répliquer la base de données (au minimum un réplicat en lecture pour le failover), et mettre en place un load balancer avec au moins deux instances applicatives.

Chaque étape améliore la disponibilité mais aussi la résilience générale de l'infrastructure. L'ordre est important : monitorer d'abord pour savoir où on en est, puis améliorer.

Mesure et reporting

Le taux de disponibilité est calculé sur une période donnée (mensuel, annuel). Dans l'offre Run, un rapport mensuel inclut le taux de disponibilité mesuré, les incidents qui ont affecté la disponibilité, leur durée, et les actions mises en place pour éviter la récurrence.

La transparence sur les incidents passés est plus valorisée que la promesse de disponibilité parfaite. Tous les prestataires ont des incidents : ce qui différencie les bons est leur façon de les gérer et d'en tirer des leçons.

Questions fréquentes

Comment mesurer le taux de disponibilité de mon application actuelle ?

Avec un outil de monitoring de disponibilité (Uptime Robot, Better Uptime, Pingdom). Un check toutes les 5 minutes depuis plusieurs localisations donne une mesure fiable. L'historique des incidents est disponible dans le dashboard.

Les maintenances planifiées sont-elles comptabilisées dans le taux de disponibilité ?

Selon la définition du SLA. Certains contrats excluent les maintenances planifiées (annoncées à l'avance) du calcul de disponibilité. D'autres les incluent. Ce point doit être explicite dans le contrat.

Quel taux de disponibilité exiger d'un hébergeur ?

Les hébergeurs cloud majeurs (AWS, OVH, Scaleway) garantissent 99,9 % à 99,99 % selon le service. La disponibilité de votre application dépend aussi de votre code et de votre architecture — un hébergeur à 99,99 % n'empêche pas votre application d'être indisponible à cause d'un bug de déploiement.

Améliorer la disponibilité de votre application

Décrivez votre contexte : nous revenons vers vous rapidement.

Votre besoin (optionnel)

Délai souhaité

Formulaire protégé par anti-spam. Réf. page : taux-disponibilite · run