Créer une page de statut sur votre nom de domaine

Quand votre service tombe, vos clients se posent tous la même question : le problème vient-il de chez moi ou de chez vous ? Sans réponse visible, ils écrivent au support, publient sur les réseaux sociaux, ou concluent que vous n'êtes pas au courant. Une page de statut répond à cette question avant qu'ils ne la posent.

Ce guide couvre le contenu d'une bonne page de statut, l'intérêt de la publier sur un sous-domaine comme status.example.com, la configuration DNS pas à pas, la vérification avec dig, et la manière de s'en servir pendant un incident.

Pourquoi publier une page de statut

Une page de statut sert d'abord à réduire le bruit. Pendant un incident, un message public remplace des dizaines de réponses individuelles, et le support peut renvoyer vers une seule adresse. Elle rassure aussi en dehors des crises : un historique de disponibilité jour par jour montre que vous mesurez votre service et que vous ne cachez rien. Certains prospects la consultent avant de signer.

En interne, elle aligne tout le monde. Le commercial au téléphone et l'équipe support lisent la même information, au même moment. Pour une agence web, une page par client, sur le domaine du client, devient un élément du service rendu.

Que mettre sur la page

Des composants pensés pour vos utilisateurs

Regroupez vos services en composants tels que vos utilisateurs les perçoivent, pas tels qu'ils sont déployés. Personne ne sait ce qu'est web-02 ou redis-cache, tout le monde comprend « Espace client ». Un composant peut agréger plusieurs sondes : l'espace client peut reposer sur la page de connexion et sur l'API qui l'alimente.

Entre trois et huit composants suffisent dans la plupart des cas. Au-delà, la page devient difficile à lire précisément quand vos utilisateurs sont inquiets.

Des mots simples

Décrivez l'impact tel que l'utilisateur le vit : « Une partie des paiements par carte échoue » parle à tout le monde, « Saturation du pool de connexions » à personne. Indiquez toujours le fuseau horaire des horodatages. Et choisissez la langue de vos clients : chez LucidStack, chaque page s'affiche en français ou en anglais.

Pourquoi un sous-domaine comme status.example.com

Trois raisons plaident pour un sous-domaine de votre propre nom de domaine :

• La confiance. Vos clients reconnaissent votre domaine. Un lien vers status.example.com dans un e-mail ou un message de support inspire plus confiance qu'une adresse chez un tiers, et ressemble moins à du hameçonnage.
• L'indépendance. Une page de statut hébergée sur vos propres serveurs tombe en même temps que votre application. Avec un CNAME vers un hébergeur externe, la page vit ailleurs, tout en portant votre nom.
• La convention. status. est le préfixe que les utilisateurs habitués essaient spontanément. statut.example.fr fonctionne tout aussi bien pour un public francophone.

Une limite à garder en tête : le sous-domaine dépend toujours de vos serveurs DNS. Si la panne vient justement de votre hébergeur DNS, la page ne sera plus joignable par ce nom. Prévoyez un canal de secours (réseaux sociaux, e-mail aux clients) pour ce cas précis.

Créer l'enregistrement CNAME

Un enregistrement CNAME déclare qu'un nom est un alias d'un autre nom. Vous indiquez que status.example.com est un alias de status.lucidstack.dev ; le service reconnaît ensuite votre domaine et sert votre page. Dans LucidStack, le domaine personnalisé est disponible à partir du plan Solo : ajoutez d'abord votre domaine dans les réglages de la page de statut, puis créez l'enregistrement.

Dans un fichier de zone

; Zone example.com
status    3600    IN    CNAME    status.lucidstack.dev.

Le point final après status.lucidstack.dev. est indispensable. Sans lui, le nom est considéré comme relatif à la zone et devient status.lucidstack.dev.example.com, qui n'existe pas.

Dans l'interface d'un hébergeur DNS

La plupart des interfaces demandent les mêmes champs, sous des noms variables :

Attention au champ Nom : beaucoup d'interfaces ajoutent votre domaine automatiquement. Saisir status.example.com y crée alors status.example.com.example.com. Si votre DNS passe par un service mandataire (le nuage orange de Cloudflare, par exemple), réglez cet enregistrement en mode « DNS uniquement » : une couche intermédiaire peut gêner l'émission du certificat.

Le cas du domaine racine

Vous ne pouvez pas utiliser example.com lui-même. Un CNAME ne peut pas cohabiter avec d'autres enregistrements sur le même nom (RFC 1034, section 3.6.2), et la racine d'une zone porte toujours ses enregistrements SOA et NS, sans compter vos MX. Certains hébergeurs proposent des pseudo-enregistrements (ALIAS, ANAME, « CNAME flattening »), mais le sous-domaine reste la solution simple, standard et sans surprise. La même règle vaut pour le sous-domaine : s'il porte déjà un enregistrement TXT ou MX, supprimez-le ou choisissez un autre nom.

Propagation et vérification avec dig

Ce que « propagation » veut dire

Un enregistrement DNS ne se propage pas vraiment : il est disponible immédiatement sur vos serveurs faisant autorité, et les résolveurs du monde entier le découvrent à mesure que leur cache expire, selon le TTL. Piège fréquent : si vous avez interrogé le nom avant de créer l'enregistrement, les résolveurs ont mis en cache la réponse « ce nom n'existe pas », pour une durée fixée par l'enregistrement SOA de votre zone (RFC 2308).

Vérifier l'enregistrement

# Le CNAME est-il en place ?
dig +short status.example.com CNAME
# Réponse attendue : status.lucidstack.dev.

# Résolution complète, jusqu'aux adresses IP
dig +short status.example.com

# Interroger un résolveur public précis
dig @1.1.1.1 +short status.example.com CNAME

# Interroger directement votre serveur faisant autorité
dig @ns1.votre-hebergeur-dns.example +short status.example.com CNAME

Si le serveur faisant autorité répond correctement mais pas votre résolveur habituel, la configuration est bonne : il suffit d'attendre l'expiration du cache. Si le serveur faisant autorité ne répond rien, l'enregistrement est mal saisi.

Le certificat HTTPS

Chez LucidStack, le certificat HTTPS est émis automatiquement à la première visite. Une fois dig satisfait, ouvrez vous-même la page : c'est vous qui déclenchez l'émission, pas votre premier client. Si votre domaine publie des enregistrements CAA, ils doivent autoriser l'autorité de certification utilisée ; sinon, l'émission échoue. Vérifiez ensuite :

curl -sI https://status.example.com | head -n 1

Abonnés, flux et pages privées

Une page que personne ne consulte n'informe personne. Proposez l'abonnement par e-mail : chez LucidStack, il fonctionne en double opt-in, et les abonnés reçoivent les annonces d'incidents et de maintenances. Les flux RSS et Atom servent aux lecteurs de flux comme aux outils de discussion d'équipe qui savent les suivre. Un badge SVG peut s'afficher dans le pied de page de votre site, et un résumé JSON alimente vos outils internes.

Toutes les pages ne sont pas publiques : une page protégée par mot de passe convient pour un client stratégique, une équipe interne ou un service en préversion. Pour les agences, la marque blanche (logo, couleurs, CSS personnalisé, sans mention de LucidStack) est disponible à partir du plan Agency.

Rester en ligne pendant la panne

Une page de statut doit survivre à la panne qu'elle annonce. L'hébergement externe règle l'essentiel ; LucidStack ajoute une copie statique de chaque page, rafraîchie toutes les minutes et servie automatiquement si l'application ne répond pas.

Deux précautions de votre côté. Si votre CSS personnalisé charge une police ou une image depuis vos propres serveurs, elle disparaîtra avec eux : hébergez ces ressources ailleurs. Et surveillez l'enregistrement lui-même : un CNAME supprimé lors d'un nettoyage de zone fait disparaître la page sans bruit. La surveillance DNS détecte ce genre de modification.

Communiquer pendant un incident

Publier vite, même sans tout savoir

Le premier message compte plus que le diagnostic. Chez LucidStack, l'incident apparaît automatiquement sur la page dès qu'il est confirmé ; ajoutez rapidement quelques mots humains :

Enquête en cours, 14 h 05 (heure de Paris)
Une partie des paiements par carte échoue depuis 13 h 50.
Les commandes déjà validées ne sont pas concernées.
Prochaine mise à jour à 14 h 35 au plus tard.

Tenir le rythme

Chaque mise à jour reprend la même structure : l'impact, ce que vous faites, l'heure du prochain point. Publiez à l'heure annoncée, même sans nouvelle. Le silence inquiète davantage qu'un « toujours en cours ». Si vous manquez de temps, l'analyse d'incident par IA peut rédiger un brouillon de message public, à relire avant publication.

Clore proprement

Annoncez la résolution, la durée de l'impact et ce qui va suivre. Pour les incidents sérieux, un post-mortem publié quelques jours plus tard referme le sujet. Et pensez aux maintenances : annoncées à l'avance, elles préviennent les abonnés et évitent les mauvaises surprises.

Mettre en place votre page

Créez la page, regroupez vos services en composants, ajoutez votre domaine, puis l'enregistrement CNAME vers status.lucidstack.dev ; le certificat suit à la première visite. Les pages de statut LucidStack incluent l'historique sur 90 jours, les abonnés, les flux et la copie de secours. Le plan gratuit comprend une page ; le domaine personnalisé commence au plan Solo, comme indiqué sur la page tarifs.