Comment créer une status page

Une page de statut ne vaut la peine que si elle se met à jour pendant un incident et si les clients peuvent la trouver quand ils en ont besoin. Ces étapes en construisent une pilotée par de vrais moniteurs dès le départ, avec assez de contexte humain pour réduire le bruit côté support.

1. 1

   Décider quels composants afficher

   Listez les parties de votre produit qu’un client reconnaîtrait et auxquelles il tient séparément : le site ou l’application principale, l’API si d’autres s’y intègrent, le checkout ou la facturation s’ils peuvent échouer indépendamment, et tout service d’arrière-plan critique que les clients remarquent quand il s’arrête. Gardez une liste courte et utile ; trois à six composants reconnaissables valent mieux que vingt libellés internes que personne hors de votre équipe ne comprend.

2. 2

   Rattacher chaque composant à un vrai moniteur

   Connectez chaque composant de la page au moniteur qui le vérifie déjà : la même vérification externe ou le même heartbeat qui surveille votre site au quotidien. C’est ce qui permet à la page de se mettre à jour seule : le composant passe au rouge quand la vérification sous-jacente échoue, puis au vert quand elle récupère, sans étape manuelle entre les deux. Si un composant n’a pas de moniteur derrière lui, ajoutez-en un ou retirez-le de la page publique.

3. 3

   Publier et placer le lien là où les gens regarderont

   Placez le lien de la page de statut là où il sera vraiment trouvé pendant un incident : footer du site, documentation, réponse automatique du support, emails d’onboarding et documentation API sont des emplacements courants. Une page de statut techniquement en ligne mais liée nulle part ne réduit pas les tickets support. Si vos clients ont des contrats ou des SLA, assurez-vous que cette page soit l’endroit que vous référencerez pendant une panne.

Après la mise en ligne

Pendant un vrai incident, publiez une courte mise à jour dès que vous savez que quelque chose ne va pas, même avant d’en connaître la cause : « nous sommes au courant et enquêtons » vaut mieux que le silence. Mettez à jour quand vous avez plus d’informations, puis publiez une note de résolution une fois le problème corrigé. Le statut automatique des composants couvre « en ligne ou hors ligne » ; une courte note humaine couvre l’impact, le périmètre, le contournement et l’heure de la prochaine mise à jour. Les deux comptent pendant un incident.

Ce qu’il faut ajouter ensuite

Une fois la page en ligne et correctement reliée à de vrais moniteurs, ajoutez les éléments qui réduisent les questions répétées : un badge d’historique d’uptime, des abonnements RSS ou email, et un court modèle d’incident que votre équipe peut réutiliser sous pression. Si les moniteurs sous-jacents incluent des vérifications TLS ou d’expiration de domaine, décidez si elles méritent des composants visibles par les clients ou si elles sont mieux représentées dans le statut du site principal : un certificat sur le point d’expirer est un vrai risque, mais il n’a pas forcément besoin de sa propre ligne publique.

Erreurs courantes à éviter

Lister chaque composant interne. Une page avec une douzaine de composants qu’aucun client ne reconnaît est plus difficile à parcourir d’un coup d’œil qu’une page avec trois ou quatre éléments qui leur importent vraiment ; gardez la décomposition détaillée pour une vue interne si votre équipe en veut une.

Ne la relier à rien. Une page de statut non connectée à un vrai moniteur n’est qu’une page statique que quelqu’un doit penser à mettre à jour, ce qui échoue précisément quand tout le monde est le plus occupé. La source de vérité devrait être le moniteur qui détecte déjà le problème.

La publier sans la lier nulle part. Comme à l’étape 3, une page de statut en ligne mais absente de votre site, de vos docs ou du parcours support ne sera trouvée par personne au moment important. Testez sa découvrabilité comme vous testez les alertes : demandez où un client regarderait d’abord.