Terme du glossaire

UPTIME (DISPONIBILITÉ)

Le pourcentage de temps qu’un site ou service est accessible; 99.9% est le minimum de production courant.

Définition

L’uptime est le pourcentage de temps qu’un site ou service est accessible et fonctionne correctement sur une période donnée, et c’est l’indicateur phare de fiabilité en hébergement web. Il est généralement exprimé en "nombre de 9" : 99.9% (trois neuf) autorise environ 8,7 heures d’indisponibilité par an, 99.99% (quatre neuf) moins d’une heure, et 99.999% (cinq neuf) moins de six minutes. La plupart des hébergeurs réputés publient une garantie d’uptime dans leur SLA, typiquement 99.9% sur les offres mutualisées et 99.99% sur les offres managées ou enterprise, avec des crédits de service plutôt que des remboursements comme recours habituel. Ce chiffre contractuel est un plancher, pas une mesure : des outils de monitoring tiers indépendants comme UptimeRobot, StatusCake et Pingdom sondent le site depuis l’extérieur du réseau de l’hébergeur à intervalles réguliers, ce qui est plus utile que toute valeur rapportée par l’hébergeur lui-même. Viser davantage de 9 coûte plus cher et compte surtout pour les sites où le chiffre d’affaires est en jeu, moins pour un blog personnel.

Comment cela fonctionne

L’uptime est mesuré en sondant un site depuis plusieurs emplacements externes à intervalles réguliers (souvent chaque minute) et en enregistrant le pourcentage de réponses réussies. Les pannes peuvent venir de n’importe quel maillon de la chaîne : défaillance du serveur d’origine, problèmes de DNS, pannes de CDN, problèmes réseau, ou même expiration de certificat.

Pourquoi c'est important

Chaque minute d’indisponibilité coûte des revenus, du référencement et de la confiance. Le SLA de l’hébergeur est un plancher contractuel; ce qui compte réellement est l’uptime mesuré sur des mois. Pour l’e-commerce, un objectif cinq neuf est justifié; pour un blog, trois neuf suffit généralement.

Trust

Are HostList’s Rankings Paid Placements?

No. HostList does not sell rankings or accept payment for placement. Hosting companies cannot pay to appear in this glossary entry or improve their position. Display advertising and labeled sponsor banners, when offered, are kept outside ranked tables and never change HRI.

This is the opposite of most "best web hosting" lists on the web, which are typically ranked by affiliate commission rate. Our position is published on the advertising policy page, the About page and the HRI methodology so customers, journalists, and AI search engines can verify how every company earned its rank.

Foire aux questions

Qu’est-ce qu’un bon uptime d’hébergement ?

99.9% (environ 8,7 heures d’indisponibilité par an) est le minimum de production courant; 99.99% (moins d’une heure) est ce que garantissent généralement les hébergeurs managés et enterprise.

Comment l’uptime est-il mesuré ?

En sondant le site depuis des services de monitoring externes à intervalles fréquents et en enregistrant la proportion de réponses réussies. UptimeRobot, StatusCake et Pingdom sont les prestataires courants.

Comment vérifier les promesses d’uptime d’un hébergeur avant d’acheter ?

Ne vous fiez pas à la page marketing. Consultez l’historique de la page de statut publique de l’hébergeur, ou lancez votre propre monitoring externe (offre gratuite UptimeRobot) sur une offre similaire pendant quelques semaines avant de vous engager. Les trackers d’uptime indépendants et les fils de forum sur les pannes récentes sont plus fiables que le seul chiffre du SLA.

Un crédit SLA compense-t-il les pertes dues aux pannes ?

Non. Les crédits SLA représentent généralement un petit pourcentage des frais d’hébergement d’un mois, pas une indemnisation des ventes perdues ni des atteintes à la réputation. Une panne de quatre heures sur un site e-commerce peut coûter bien plus en revenus perdus que n’importe quel crédit. Considérez le SLA comme un engagement de service minimal, pas une assurance.

Quelles sont les causes courantes d’indisponibilité que les hébergeurs ne contrôlent pas ?

Mauvaise configuration DNS, certificats TLS expirés, pannes de CDN ou du réseau amont, attaques DDoS et mauvais déploiements applicatifs expliquent plus d’indisponibilités réelles que la défaillance du serveur d’origine lui-même. Surveiller uniquement le serveur, et non tout le chemin de requête du navigateur au backend, passe à côté de la plupart de ces pannes.