Le taux de disponibilité d'un hébergement est la part du temps pendant laquelle le service répond réellement : 99,9 % autorisent environ 8 h 46 min d'arrêt par an. Sa valeur dépend du SLA, de ce que le contrat mesure sur l'infrastructure, des incidents qu'il exclut et du sort des données en cas de panne.
- Chaque « neuf » ajouté divise par dix le temps d'indisponibilité toléré : de 3 jours et demi par an à 99 % jusqu'à 53 minutes à 99,99 %.
- Le chiffre n'a de sens qu'avec le SLA qui l'encadre : périmètre mesuré, exclusions, plage de service garanti, délai de rétablissement.
- Une surveillance externe donne au client son propre relevé des incidents, la seule preuve opposable au prestataire.
Comment se calcule le taux de disponibilité d'un service web ?
Le taux de disponibilité se calcule en divisant le temps pendant lequel le service fonctionne par la durée totale de la période observée, puis en multipliant par 100. La formule s'écrit : taux = (temps total - durée d'interruption) / temps total x 100. Sur un mois de 30 jours, soit 720 heures, un site internet resté indisponible 2 h affiche un taux de (720 - 2) / 720, soit 99,72 %.
Ce calcul paraît simple, mais trois paramètres le font varier d'un fournisseur à l'autre. La période de référence, d'abord : un engagement mensuel est plus exigeant qu'un engagement annuel, car une panne de 6 h reste diluée sur douze mois alors qu'elle fait plonger le taux d'un seul mois sous 99,2 %. La granularité de la mesure, ensuite : une sonde qui interroge le serveur toutes les cinq minutes ne voit pas une coupure de deux minutes, tandis qu'une vérification à la minute la compte. La définition de l'arrêt, enfin : certains contrats ne retiennent que les coupures de plus de quinze minutes consécutives.
Les ingénieurs d'exploitation utilisent une seconde formule, fondée sur deux moyennes. Le MTBF (temps moyen entre deux pannes) et le MTTR (temps moyen de réparation) donnent la disponibilité théorique : MTBF / (MTBF + MTTR). Une machine qui tombe en moyenne une fois toutes les 1 000 h et repart en 1 h atteint 1 000 / 1 001, soit 99,9 %. Cette écriture montre les deux leviers d'amélioration : espacer les pannes ou raccourcir la remise en service. Pour un petit site, réduire le MTTR coûte presque toujours moins cher que d'allonger le MTBF.
Du 99 % au 99,999 % : le temps d'arrêt réel derrière chaque palier
Un palier de disponibilité se traduit en minutes d'arrêt autorisées, et c'est cette traduction qui permet de comparer deux offres. Le tableau convertit les pourcentages les plus courants sur un an de 8 760 heures et sur un mois de 30 jours.
| Taux annoncé | Arrêt toléré par an | Arrêt toléré sur 30 jours | Usage typique |
|---|---|---|---|
| 99 % | 3 jours 15 h 36 min | 7 h 12 min | offres gratuites, sites personnels |
| 99,5 % | 43 h 48 min | 3 h 36 min | mutualisé d'entrée de gamme |
| 99,9 % | 8 h 45 min 36 s | 43 min 12 s | mutualisé courant, VPS |
| 99,95 % | 4 h 22 min 48 s | 21 min 36 s | cloud avec redondance |
| 99,99 % | 52 min 34 s | 4 min 19 s | plateformes multi-serveurs |
| 99,999 % | 5 min 15 s | 26 s | télécoms, systèmes critiques |
L'écart entre 99 % et 99,9 % paraît minuscule sur le papier ; il sépare pourtant un site qui peut rester hors ligne un week-end entier d'un site qui ne s'arrête que quelques minutes par mois. Au-delà de 99,99 %, le temps d'arrêt toléré devient inférieur à la durée d'une simple mise à jour logicielle redémarrée à la main : seule une architecture qui bascule seule sur une machine de secours tient ce rythme.
La colonne « usage typique » reste indicative. Rien n'empêche un hébergement mutualisé partagé entre plusieurs sites de faire mieux que son engagement pendant des mois, ni un serveur haut de gamme de connaître une journée noire. Le taux contractuel fixe un plancher en dessous duquel le fournisseur doit un dédommagement, pas une prévision du service rendu.
Pourquoi un point de disponibilité pèse sur le chiffre d'affaires
La disponibilité d'un site marchand se mesure en ventes perdues, et l'impact d'une heure d'arrêt dépend de l'heure à laquelle elle tombe. Une boutique qui réalise l'essentiel de ses commandes le soir et le dimanche subit bien plus une coupure de 20 h un dimanche que trois h de maintenance un mardi à 4 h du matin. Le calcul brut du taux ne fait pas cette différence ; le chiffre d'affaires, si.
Au-delà des ventes, l'indisponibilité touche la confiance. Un client qui tombe deux fois sur une page d'erreur pendant un paiement revient rarement, et un formulaire de contact muet fait perdre des demandes que personne ne voit passer. Pour une application métier utilisée par des équipes, chaque panne immobilise aussi des salariés, ce qui ajoute un coût de main-d'oeuvre au coût commercial.
Le référencement réagit plus lentement. Un robot qui rencontre ponctuellement une erreur 503 revient plus tard sans pénaliser la page ; des erreurs répétées sur plusieurs jours, en revanche, conduisent les moteurs à ralentir leur exploration, voire à retirer des URL de l'index. Pour Google, la régularité du service compte donc autant que la vitesse d'affichage.
Le SLA, l'accord de niveau de service qui donne son sens au pourcentage
Le SLA (service level agreement, en français accord de niveau de service) est la partie du contrat d'hébergement qui chiffre l'engagement du prestataire et prévoit la compensation s'il n'est pas tenu. Deux fournisseurs qui affichent 99,9 % ne promettent pas la même chose tant que leurs SLA n'ont pas été comparés ligne à ligne. Quatre questions suffisent à les départager.
Qu'est-ce qui est mesuré ?
Le périmètre de mesure varie du serveur physique au réseau du centre de données, ou jusqu'à la réponse effective du site internet. Une machine allumée dont le service web est bloqué peut compter comme disponible si le SLA ne porte que sur le matériel. Les offres les plus claires précisent l'outil de mesure, sa fréquence et l'endroit d'où partent les sondes.
Qu'est-ce qui est exclu du calcul ?
Les exclusions courantes sont la maintenance programmée et annoncée, les attaques par déni de service, les pannes d'un fournisseur tiers (électricité, opérateur réseau), les erreurs du client lui-même et les cas de force majeure. Plus la liste est longue, plus le chiffre affiché perd de sa portée. Une maintenance hebdomadaire de deux h, exclue du calcul, représente à elle seule plus de 100 h d'arrêt par an.
Quelle est la plage de service garanti ?
La plage de service garanti (PSG) délimite les jours et horaires pendant lesquels la promesse s'applique. Une PSG « 7 j sur 7, 24 h sur 24 » couvre toute la semaine ; une PSG « jours ouvrés de 8 h à 19 h » laisse les nuits et les week-ends hors contrat. Cette plage horaire conditionne aussi la prise en charge des tickets : un incident signalé un samedi peut n'être traité que le lundi.
Que se passe-t-il en cas de manquement ?
Le manquement ouvre droit, le plus souvent, à un avoir sur la facture du mois, calculé en pourcentage de l'abonnement et plafonné. Il faut le réclamer soi-même, par ticket ou depuis l'espace client, dans un délai court fixé par le contrat. Cet avoir ne compense jamais la perte réelle : il sert surtout à mesurer le sérieux du prestataire, pas à indemniser une journée de ventes manquées.
PSG, GTI, GTR : les délais qui complètent le taux
Les délais contractuels mesurent la réaction du prestataire une fois l'incident déclaré, là où le taux de disponibilité mesure un résultat global sur la période. Les contrats professionnels, notamment pour un serveur dédié ou une infogérance, associent ces délais au taux.
| Engagement | Ce qu'il mesure | Point à vérifier |
|---|---|---|
| Taux de disponibilité | part du temps où le service répond | période (mois ou an), exclusions |
| PSG (plage de service garanti) | heures couvertes par l'engagement | nuits, week-ends, jours fériés |
| GTI (garantie de temps d'intervention) | délai avant qu'un technicien agisse | point de départ du délai |
| GTR (garantie de temps de rétablissement) | délai de remise en service | rétablissement complet ou provisoire |
La GTR est la plus utile pour un site qui vend : elle fixe le délai maximal d'interruption d'un incident isolé, quand le taux annuel tolère qu'un seul arrêt dure plusieurs heures. Une GTR de 4 h sur une PSG 24 h sur 24 offre une protection plus concrète qu'un 99,95 % sans délai de rétablissement. La notion d'incident bloquant compte aussi : un site lent mais accessible n'est, dans la plupart des contrats, pas considéré comme coupé.
Ce qui fait réellement tomber un site
Les causes d'indisponibilité se répartissent entre l'infrastructure de l'hébergeur et l'exploitation du site, et la seconde catégorie pèse souvent plus lourd qu'on ne le croit. Les rapports annuels de l'Uptime Institute sur les pannes de centres de données citent l'alimentation électrique, le réseau et les erreurs humaines parmi les causes principales des incidents graves ; côté site, la liste est plus prosaïque.
- Extension ou thème mis à jour qui casse une page ou déclenche une erreur fatale.
- Certificat SSL expiré : le site répond, mais les navigateurs bloquent l'accès.
- Nom de domaine non renouvelé, qui coupe le site et les courriels en même temps.
- Disque plein ou quota dépassé, qui empêche la base de données d'écrire.
- Pic de trafic qui sature les ressources d'une offre mutualisée.
- Erreur de configuration DNS lors d'un changement de serveur.
Aucun de ces cas n'entre dans le SLA de l'hébergeur, puisqu'il relève de la gestion du client. Une bonne hygiène d'exploitation (renouvellements automatiques, alertes de quota, mises à jour testées sur une copie) fait donc gagner plus de disponibilité qu'un neuf supplémentaire au contrat.
La disponibilité d'une chaîne se multiplie, elle ne s'additionne pas
Un site moderne dépend d'une chaîne de composants (DNS, réseau de diffusion, serveur web, base de données, service de paiement), et la disponibilité de l'ensemble est le produit des disponibilités de chaque maillon. Deux composants à 99,9 % placés en série donnent 99,9 % x 99,9 %, soit 99,8 % : le temps d'arrêt toléré double. Avec cinq maillons à 99,9 %, l'ensemble descend vers 99,5 %, soit près de 44 heures par an.
La logique s'inverse quand les composants sont doublés en parallèle. Deux serveurs à 99,9 % capables de se remplacer l'un l'autre n'échouent ensemble que si les deux tombent au même moment : la probabilité de panne commune devient 0,1 % x 0,1 %, et la disponibilité théorique grimpe à 99,9999 %. C'est le principe de la redondance, à condition que les deux machines ne partagent ni la même alimentation ni le même réseau.
Ce raisonnement explique pourquoi la disponibilité ne s'achète plus seulement chez un fournisseur au-delà de 99,9 %. Elle se construit avec plusieurs serveurs, une répartition de charge et une base de données répliquée, ce que proposent les offres de migration vers un hébergement cloud fondées sur le cloud computing. Un réseau de diffusion de contenu placé devant le site joue un rôle voisin pour les pages statiques : il continue de servir une copie en cache quand le serveur d'origine ralentit, sans remplacer la redondance de la partie dynamique.
Surveiller soi-même la disponibilité de son site
La surveillance externe consiste à faire interroger son site par un service tiers, à intervalle régulier et depuis plusieurs pays, pour détecter une coupure avant les visiteurs. Le tableau de bord du prestataire indique l'état de son infrastructure, pas celui de votre page d'accueil : seule une sonde extérieure voit ce que voit l'internaute.
Trois réglages font la qualité de cette surveillance. La fréquence, d'abord : une vérification à la minute repère les coupures courtes que le SLA compte peut-être. Le contenu contrôlé, ensuite : mieux vaut chercher un mot précis dans la page qu'un simple code de réponse, car une page blanche ou un message d'erreur de base de données renvoient parfois un code 200. La confirmation, enfin : une alerte déclenchée par deux sondes situées dans des régions différentes écarte les fausses alertes dues à un problème réseau local.
Ce relevé constitue votre propre historique de disponibilité, avec les dates, heures et durées de chaque incident. Il sert à réclamer un avoir, à comparer la promesse au service réellement rendu sur plusieurs mois et, si l'écart se répète, à décider d'un changement de prestataire. Il prépare aussi la suite de l'alerte : savoir qui intervient, avec quels accès, et où se trouve la dernière copie de sauvegarde à restaurer.
Haute disponibilité : cluster, réplication et basculement automatique
La haute disponibilité désigne une architecture conçue pour qu'aucun composant isolé ne puisse interrompre le service : chaque élément du système informatique existe en au moins deux exemplaires, et un outil de supervision bascule le trafic vers la ressource saine quand l'autre tombe. Pour une entreprise, c'est la seule manière réaliste de dépasser 99,95 % sur un site dynamique.
Prenons l'exemple d'une entreprise qui souhaite améliorer la disponibilité d'une boutique WordPress. Sur un serveur unique, la moindre mise à jour de WordPress ou de PHP impose une courte coupure, et une panne de disque rend le site indisponible le temps de rétablir la machine. En mode cluster, deux ou trois serveurs web identiques se partagent les visites derrière un répartiteur de charge ; les fichiers WordPress sont synchronisés et la base MySQL est répliquée en continu vers un second nœud. Un nœud peut alors sortir du cluster pour une opération de maintenance pendant que les autres restent opérationnels, sans que l'utilisateur s'en aperçoive.
Cette architecture a un prix en ressources et en compétences. Le nombre de serveurs double ou triple, la configuration se complique, et l'équipe a besoin d'une formation à la supervision et aux procédures de basculement, faute de quoi la redondance reste théorique. Une redondance jamais testée ne protège pas : un exercice de bascule programmé deux fois par an vérifie que la machine de secours est réellement disponible, que les data répliquées sont à jour et que le nom de domaine pointe au bon endroit après l'opération.
Fixer son propre objectif de disponibilité
L'objectif de disponibilité d'un site se fixe à partir du coût d'une heure d'arrêt, pas du chiffre le plus élevé du marché. Un site vitrine ou un blog vit très bien avec un hébergement mutualisé à 99,9 %. Une boutique en ligne, un service de réservation ou une application dont dépendent des clients justifie de viser 99,95 % ou plus, avec une GTR courte et une PSG qui couvre les soirs et les week-ends.
Le plan de reprise d'activité complète cet objectif. Il décrit, avant la panne, la mise en place d'un site de secours, la durée maximale acceptable d'interruption et la quantité de données qu'on accepte de perdre entre deux sauvegardes. Rédigé en une page, il évite d'improviser le jour où le serveur ne répond plus.
Maintenance programmée, promesse de 100 % et avoir à réclamer
Une maintenance programmée compte-t-elle comme un arrêt ?
La plupart des SLA excluent du calcul les maintenances annoncées à l'avance, qui ne comptent donc pas dans le taux. Vérifiez leur fréquence, leur durée habituelle et l'heure à laquelle elles ont lieu : une intervention nocturne mensuelle gêne peu, une coupure en journée beaucoup plus.
Peut-on atteindre 100 % de disponibilité ?
Aucune infrastructure n'atteint 100 % de disponibilité, car tout matériel finit par tomber en panne et tout logiciel par demander une mise à jour. Un hébergeur sérieux ne promet jamais ce chiffre ; une telle promesse doit au contraire éveiller la méfiance.
Comment obtenir l'avoir prévu par le SLA ?
L'avoir prévu par le SLA s'obtient en le demandant, généralement par un ticket au support dans le délai fixé par le contrat, avec les dates et heures de l'incident. Un historique de surveillance externe appuie la demande.
