Vendredi 14 h 12, votre boutique affiche des timeouts. Le dashboard interne crie, le support ouvre un ticket — et la page de statut de l'hébergeur reste verte. Quarante minutes plus tard, un bandeau « investigation en cours » apparaît sur un composant que vous n'aviez jamais repéré. Ce décalage n'est pas un accident de calendrier : c'est souvent le premier indice que la page de statut sert davantage à rassurer qu'à informer.
La question utile n'est donc pas « mon hébergeur a-t-il une page de statut ? ». Elle est plus précise : cette page décrit-elle réellement ce qui peut casser chez vous, avec quelle rapidité, et avec quel niveau de détail une fois la crise passée ?
Ce qu'une page de statut promet — et ce qu'elle ne couvre pas
Une page de statut publique (Statuspage, Cachet, solution maison) agrège l'état de composants prédéfinis : API, panel, DNS, région, backbone réseau. Chaque composant passe par des états standard — opérationnel, dégradé, panne, maintenance.
Le piège commence quand le périmètre monitoré ne recoupe pas votre architecture. Un VPS en Allemagne peut être down alors que seule la région « Europe » est affichée. Un problème de stockage objet peut ne pas remonter si seul le « panel client » est suivi. Un incident mutualisé peut rester invisible si la page ne distingue pas les clusters.
Une page verte ne signifie pas « tout va bien pour vous ». Elle signifie « rien de signalé sur les briques que l'hébergeur a choisi de montrer ».
Quatre critères pour distinguer transparence et vitrine
Avant de classer un hébergeur « transparent », passez sa page au fil de quatre filtres.
1. Granularité des composants. Les régions, produits et couches réseau sont-ils nommés explicitement ? « Cloud Platform » sans sous-découpage cache les incidents localisés.
2. Historique et post-mortems. Consultez les six à douze derniers mois. Des incidents récurrents sans analyse publiée suggèrent une communication défensive. Des post-mortems datés, avec cause racine et actions correctives, valent plus qu'un SLA affiché.
3. Délai de publication. Comparez l'heure de votre première alerte interne avec la première mise à jour publique. Un écart systématique de 30 à 60 minutes indique souvent une validation interne lente — ou une page mise à jour seulement quand l'impact devient massif.
4. Correspondance avec votre contrat. Votre offre, datacenter et services annexes (email, backup, CDN) figurent-ils dans les composants ? Sinon, la page ne vous concerne qu'en partie.
| Signal | Transparence crédible | Vitrine rassurante |
|---|---|---|
| Composants | Régions et produits nommés | Libellés fourre-tout |
| Historique | Incidents datés, détaillés | Peu d'entrées ou incidents « résolus » sans contexte |
| Post-mortem | Publié après panne significative | Absent ou générique |
| Délai | Mise à jour proche de la détection | Retard visible vs vos propres sondes |
Ce que révèlent les grands acteurs européens
Les hébergeurs visibles sur le marché européen ne jouent pas tous le même jeu. OVHcloud publie une page de statut structurée par produits et régions, avec un historique consultable — utile, à condition de vérifier que votre région y figure. Hetzner documente ses incidents de façon relativement directe, mais le support reste surtout anglais/allemand : la page informe, elle ne remplace pas un interlocuteur en panne nocturne.
Les acteurs plus petits affichent parfois une page minimaliste, voire absente. Ce n'est pas forcément un défaut pour un VPS solo géré par une équipe technique — mais c'est un risque pour une PME qui découvre l'incident via Twitter avant le bandeau officiel.
Le sommet : la page ne voit pas ce que vous subissez
Voici ce que les pages « 100 % uptime » eludent presque toujours.
C'est le cœur de l'enquête : beaucoup d'équipes installent un lien vers status.example.com dans leur runbook et considèrent le sujet clos. Or la vraie question est contractuelle et technique — quels composants sont suivis, par qui, avec quel seuil, et quelle obligation de publication existe réellement.
Décider et avancer sans angle mort
Avant de renouveler ou de migrer, ouvrez la page de statut de vos short-listés et notez trois choses : le dernier incident significatif, le délai entre début et première publication, et la présence ou non de votre région/produit.
Ensuite, croisez avec vos propres sondes (Uptime Kuma, Pingdom, Better Stack) sur les endpoints critiques. Si l'écart dépasse régulièrement 15 minutes, traitez la page comme un canal secondaire.
Pour comparer les acteurs et leurs pratiques documentées, consultez notre annuaire d'hébergeurs et le comparateur. Les profils techniques autonomes toléreront une page sobre ; les équipes avec SLA client exigeront historique et post-mortems publics.
Questions fréquentes
Une page de statut « verte » garantit-elle l'absence d'incident ?
Non. Elle indique seulement qu'aucun composant suivi n'est en panne au moment de la consultation. Un problème peut toucher un service non listé, une région absente du périmètre, ou un incident encore non publié.
Que demander à un hébergeur avant de se fier à sa page de statut ?
La liste exacte des composants monitorés, le délai cible de publication, l'accès à l'historique complet, et si votre produit (région, offre, couche réseau) y apparaît explicitement.
Faut-il s'abonner aux alertes de la page de statut ?
Oui, mais comme complément — pas comme unique canal. Croisez avec vos propres sondes, les logs applicatifs et, si possible, des canaux alternatifs (RSS, webhook, monitoring externe).
Comment repérer une page de statut « cosmétique » ?
Historique vide ou peu détaillé, composants trop génériques (« Infrastructure »), retards systématiques entre votre incident et la première publication, absence de post-mortem après panne majeure.
La prochaine fois qu'un commercial citera « notre page de statut en temps réel », demandez une seule chose : montrez-moi le dernier incident sur ma région, avec l'heure de première publication.