À 9 h 12, le site ne répond plus. À 9 h 45, quelqu'un crée une page Notion « Statut incident en cours ». À 10 h 30, les clients ont déjà inondé le support — et les réseaux sociaux — faute d'un canal unique. La page de statut n'est pas un luxe post-mortem : c'est une infrastructure de confiance à construire quand tout va bien.
Une page de statut publique indique l'état de vos services, l'historique des incidents et les abonnements aux alertes. Bien faite, elle déleste le support et cadre la communication incident. Mal faite — ou créée sous stress — elle ajoute de la confusion.
Ce qu'une page utile contient
| Élément | Rôle | Erreur fréquente |
|---|---|---|
| Composants découpés | Site, API, mail — pas un bloc « tout » | Un voyant vert global alors que le paiement est KO |
| Historique 90 jours | Preuve de sérieux | Page vide après chaque incident |
| Abonnements email/RSS/webhook | Clients informés sans appeler | Pas de lien depuis le footer ou le support |
| Maintenance planifiée | Réduit les tickets « c'est down ? » | Annoncée la veille seulement |
| Hébergement séparé | Reste up si prod down | Statut sur le même VPS que le site |
Outils courants : Statuspage (Atlassian), Cachet, Instatus, ou SaaS européens selon contraintes RGPD. L'hébergeur peut aussi fournir une page — utile pour son infra, insuffisante pour votre stack.
Préparer avant l'incident : runbook minimal
Listez les composants avec owner technique et contact. Définissez qui publie — une personne nommée, pas « l'équipe » vague. Rédigez des modèles de message : investigating, identified, monitoring, resolved. Testez une fausse panne trimestrielle avec mise à jour et notification abonnés. Liez la page depuis le site (footer, page support) et la signature support.
Pendant l'incident, chaque update suit la règle : dire ce que l'on sait, marquer ce qu'on ne sait pas, horodatage clair. Pas de « tout est réglé » avant preuve.
Relier monitoring et statut
Automatisez ce qui peut l'être : sondes HTTP sur URLs critiques (homepage, /health, API checkout), alertes Prometheus ou UptimeRobot vers webhook statut. Évitez de passer automatiquement en « résolu » sans validation humaine.
Le SLA uptime de l'hébergeur ne remplace pas vos propres sondes applicatives.
Le sommet : la page statut est un contrat implicite avec vos utilisateurs
Les hébergeurs avec statut public (OVH, Scaleway, etc.) montrent l'exemple côté infra ; votre responsabilité reste de traduire l'impact métier.
Décider et avancer sans angle mort
Choisissez un outil hébergé hors de votre production principale. Découpez quatre à six composants visibles côté métier. Formez un publieur de garde et rédigez des modèles de message. Planifiez un exercice semestriel : fausse panne, notification, chronométrage. Comparez les hébergeurs avec historique de statut public via l'annuaire.
Questions fréquentes
Faut-il une page si l'hébergeur en a une ?
Oui pour votre couche applicative : certificat expiré, WordPress, API, tunnel de paiement. Le statut OVH ou AWS ne dit pas si votre service métier fonctionne.
Quels composants lister ?
Ce que l'utilisateur voit ou ce qui bloque une commande : site public, API, back-office, emails transactionnels, DNS.
Même hébergeur pour statut et site ?
Risqué — si le datacenter tombe, la page tombe avec. Préférez un SaaS externe ou une autre région.
Fréquence de mise à jour en incident ?
Toutes les quinze à trente minutes minimum en impact majeur, même sans cause identifiée. Le silence alimente les rumeurs.
Configurez votre page de statut un jour calme. Le jour de la panne, vous n'aurez ni le temps ni la tête pour l'inventer — seulement pour la remplir.