Comment créer une page de statut : composants, incidents et contrôles de disponibilité

Une page de statut indique à vos utilisateurs, en un seul endroit, si votre service fonctionne. Pour en créer une, il vous faut une liste de composants (site web, API, paiements, envoi d'e-mails), un statut actuel pour chacun, des incidents avec des mises à jour horodatées, un historique des incidents passés et, si vous le souhaitez, des abonnements pour que les gens soient prévenus des problèmes sans avoir à vérifier. La page elle-même est simple. La décision importante concerne l'endroit où elle tourne : une page de statut doit rester en ligne quand votre app est en panne, elle ne doit donc pas partager l'hébergement, la base de données ni le pipeline de déploiement de ce qu'elle surveille.

À quoi sert une page de statut

Quand quelque chose casse, les utilisateurs veulent savoir trois choses : est-ce que le problème ne vient que de moi, êtes-vous au courant, et quand sera-t-il réglé. Une page de statut répond aux trois sans déclencher un flot de tickets de support. Elle renforce aussi la confiance dans la durée, car un historique d'incidents visible, accompagné de comptes rendus honnêtes, montre comment vous gérez les problèmes.

Ce n'est pas un journal des modifications. Les nouvelles fonctionnalités vont dans une page de changelog ; les pannes et les maintenances vont ici.

Ce dont la page a besoin

Données

Table	Champs clés
Composants	Nom (application web, API, paiements, envoi d'e-mails), description, statut actuel, ordre d'affichage, groupe
Incidents	Titre, impact (mineur, majeur, critique), statut (en investigation, identifié, sous surveillance, résolu), composants touchés, date de début, date de résolution
Mises à jour d'incident	Incident, message, statut au moment de la publication, date de publication, auteur
Fenêtres de maintenance	Titre, composants concernés, début et fin prévus, message
Abonnés	E-mail, confirmé oui/non, composants qui les intéressent, jeton de désabonnement

Les statuts des composants forment en général une courte liste fixe : opérationnel, performances dégradées, panne partielle, panne majeure, en maintenance.

Droits d'accès

Le public voit tout ce qui est publié. Seule votre équipe peut publier. Si possible, gardez la connexion à l'administration séparée du système de connexion de votre app principale, pour qu'une panne de votre fournisseur d'authentification ne vous empêche pas d'accéder à votre propre page de statut.

La décision clé : la rendre indépendante

C'est là que échouent la plupart des pages de statut faites maison. Si votre page de statut :

tourne sur le même serveur ou le même compte d'hébergement que votre app,
lit la même base de données,
passe par la même configuration de domaine ou de CDN,
ou est déployée par le même pipeline,

alors beaucoup de pannes la feront tomber aussi, exactement au moment où les gens en ont besoin. Mesures pratiques :

Hébergement séparé. Un projet ou un fournisseur différent de l'app principale.
Son propre sous-domaine, comme status.exemple.com, pointé séparément dans le DNS. Voir comment fonctionnent les domaines et le DNS.
Ses propres données. Les incidents sont stockés dans l'espace de la page de statut, pas dans la base de données de votre app.
Un secours statique. Certaines équipes rendent la page publique statique et la reconstruisent à chaque mise à jour, pour qu'il y ait presque rien qui puisse casser.

Mises à jour manuelles ou contrôles automatisés

Manuel (pour commencer)

Votre équipe publie les incidents et change les statuts des composants à la main, depuis la page d'administration. C'est ainsi que fonctionnent beaucoup de pages de statut en pratique, car un jugement humain (« les paiements sont lents pour certains types de cartes ») est plus utile qu'un point rouge automatique.

Pour être alerté rapidement en cas de problème, utilisez un outil externe de surveillance de disponibilité qui vérifie votre app toutes les minutes environ et vous prévient par e-mail, SMS ou messagerie. Beaucoup de services de surveillance proposent une offre gratuite.

Automatisé

L'automatisation signifie que quelque chose vérifie régulièrement chaque composant et met à jour son statut. Il faut pour cela du code qui tourne selon un planning, depuis l'extérieur de l'infrastructure de votre app principale. Deux schémas courants :

Un outil de surveillance externe appelle votre page de statut via un webhook quand un contrôle échoue ou se rétablit, et la page de statut met à jour le composant.
Une tâche planifiée dans l'hébergement de la page de statut interroge chaque composant et enregistre le résultat. Vérifiez comment votre hébergeur gère les tâches planifiées avant de vous y fier ; notre guide sur l'exécution de tâches en arrière-plan présente les options.

Les changements automatiques peuvent osciller (en ligne, hors ligne, en ligne) sur un réseau lent. Exigez deux ou trois échecs consécutifs avant de changer un statut, et laissez un humain confirmer avant d'annoncer une panne majeure.

Rédiger les mises à jour d'incident

Publiez tôt. « Nous enquêtons sur des signalements de problèmes de connexion » quelques minutes après le début vaut mieux qu'un message parfait une heure plus tard.
Dites ce que les utilisateurs remarquent, pas ce qui a cassé en interne.
Annoncez l'heure de la prochaine mise à jour, et tenez cette promesse.
Terminez par un bref résumé une fois résolu : ce qui s'est passé, combien de temps cela a duré, ce que vous changez.

Un premier prompt qui fonctionne

Crée une page de statut autonome pour notre app Parcelio, hébergée séparément sur status.parcelio.com. Composants : Site web, API de suivi, Notifications, Paiements, chacun avec le statut Opérationnel, Performances dégradées, Panne partielle, Panne majeure ou En maintenance. La page publique affiche une bannière globale qui reprend le pire statut actuel, chaque composant avec son statut, les incidents actifs avec leurs mises à jour horodatées, les plus récentes en premier, les maintenances à venir et la liste des incidents passés classés par mois. Chaque incident a sa propre page. Ajoute une page d'administration protégée par mot de passe pour créer des incidents (titre, impact, composants touchés), publier des mises à jour (message et statut : En investigation, Identifié, Sous surveillance, Résolu), changer le statut des composants et programmer des maintenances. Ajoute un point d'accès POST /api/check-result qui accepte le nom d'un composant et up/down depuis un outil de surveillance externe, protégé par un jeton secret, et ne passe un composant en Performances dégradées qu'après trois échecs consécutifs. Stocke tout dans la base de données de cette app. Design simple et calme, rapide à charger sur téléphone.

Étapes de création

Page publique et administration avec incidents manuels. Cela suffit déjà à faire une page de statut fonctionnelle.
L'héberger séparément et pointer un sous-domaine vers elle.
Pages d'incident et historique.
Fenêtres de maintenance.
Abonnements. Inscription par e-mail avec double confirmation, et notifications à chaque nouvel incident et à chaque mise à jour. L'e-mail nécessite un fournisseur ; voir comment envoyer des e-mails depuis votre app.
Webhook de surveillance, si vous voulez des changements de statut automatiques.
Faire un exercice. Créez un faux incident, publiez des mises à jour, résolvez-le, vérifiez les e-mails, puis supprimez-le.

Erreurs courantes

L'héberger avec l'app. L'erreur la plus fréquente et la plus grave.
Une page qui affiche toujours « Tous les systèmes sont opérationnels ». Si elle ne montre jamais de problème, les utilisateurs cessent de lui faire confiance.
Pas d'horodatage ni de fuseau horaire. Affichez toujours les heures avec leur fuseau.
S'appuyer sur la connexion de votre app principale pour la page d'administration.
Le silence entre les mises à jour. « Pas de changement, nous travaillons toujours dessus » est une mise à jour valable.
Des statuts automatiques qui oscillent. Exigez des échecs répétés avant tout changement.

Quand un service de page de statut hébergé est le meilleur choix

Les services de page de statut hébergés sont conçus pour résoudre le problème de l'indépendance : ils tournent sur une infrastructure séparée, gèrent les notifications d'abonnés par e-mail et SMS, et incluent souvent la surveillance et l'intégration avec des outils de gestion d'incidents. Si la disponibilité fait partie de ce que vos clients paient, ou si vous avez des obligations contractuelles de signaler les incidents, un service dédié vaut en général le coût. Beaucoup proposent des offres gratuites ou peu coûteuses pour les petites équipes, donc vérifiez avant de tout construire.

Construisez la vôtre quand vous voulez un contrôle total sur le design et la formulation, quand vos besoins sont simples (quelques composants, mises à jour manuelles), ou quand la page de statut fait partie d'un produit que vous créez pour d'autres.

La créer avec Mythex

Sur Mythex, vous pouvez créer la page de statut comme un projet à part, séparé de votre app principale, ce qui lui donne un hébergement distinct et sa propre base de données. Décrivez-la dans le chat, vérifiez-la dans l'aperçu en direct, puis publiez-la et connectez un sous-domaine comme status.votredomaine.com (les domaines personnalisés sont inclus dans l'offre Pro). Gardez à l'esprit que les apps Mythex publiées et leurs bases de données se mettent en veille quand elles ne sont pas utilisées, et se réveillent à la visite suivante : le premier chargement après une période calme peut donc être plus lent ; une page simple et légère aide.

Mythex ne documente pas les tâches planifiées. Pour les contrôles automatisés, utilisez donc un outil externe de surveillance qui appelle un point d'accès webhook de votre page de statut (voir la recette webhooks). Les alertes e-mail aux abonnés passent par votre propre fournisseur, avec la clé stockée comme secret de projet (recette d'envoi d'e-mails).

Questions

Qu'est-ce qu'une page de statut ?

Une page publique qui indique si chaque partie de votre service fonctionne, liste les incidents en cours et passés avec des mises à jour horodatées, et permet souvent de s'abonner aux notifications. Elle réduit la charge du support pendant les pannes.

Ma page de statut doit-elle être hébergée avec mon app ?

Non. Si elle partage l'hébergement, la configuration du domaine ou la base de données de votre app, elle peut tomber pendant la même panne qu'elle est censée signaler. Hébergez-la séparément, sur un sous-domaine comme status.votredomaine.com.

Ai-je besoin d'une surveillance automatisée ?

Elle est utile, mais pas indispensable pour démarrer. Beaucoup de petites équipes publient les incidents à la main et utilisent un outil externe de surveillance de disponibilité pour s'alerter elles-mêmes. Les changements de statut automatiques peuvent venir plus tard.

Que doit dire une mise à jour d'incident ?

Ce qui est touché, ce que les utilisateurs vont remarquer, ce que vous faites et à quel moment aura lieu la prochaine mise à jour. Courte, simple et horodatée, même si la mise à jour dit seulement « enquête en cours ».