Status page publique : ce que tes clients attendent vraiment

À quoi sert vraiment une status page

Une status page (ou page de statut) est une page publique qui affiche l'état de tes services : ce qui marche, ce qui ne marche pas, et ce que tu fais pour le réparer. Elle vit à une adresse fixe, que tes clients peuvent garder en favori ou trouver depuis ton site, ton support ou ta signature d'email.

On la présente souvent comme un outil de transparence. C'est vrai, mais son premier intérêt est beaucoup plus terre à terre : elle absorbe les questions à ta place. Pendant une panne, chaque client qui ne sait pas ce qui se passe t'écrit, t'appelle ou te relance sur Slack. Dix clients, dix fois la même réponse, au moment précis où tu devrais être en train de réparer. Avec une page de statut à jour, la réponse existe déjà : tu la donnes une fois, tout le monde la lit.

Elle sert aussi en dehors des pannes. Un prospect qui hésite peut y voir l'historique de disponibilité des derniers mois. Un client qui doute (« votre site est lent depuis ce matin, non ? ») peut vérifier lui-même qu'aucun incident n'est en cours, et chercher la cause de son côté. Et toi, tu as un endroit où annoncer une maintenance sans envoyer un email à toute ta base.

Pour une agence ou un freelance qui gère les sites de ses clients, c'est encore plus net : la page de statut devient la réponse standard à « le site est en panne ? ». Tu envoies le lien, ton client voit par lui-même, et tu gardes ton énergie pour la réparation.

Ce que tes clients cherchent en arrivant sur la page

Personne ne lit une page de statut par plaisir. On y arrive stressé, souvent depuis un téléphone, avec une question précise. Chaque élément de la page doit y répondre vite. Voici ce qui compte, dans l'ordre où le regard le cherche.

1. Un verdict global, lisible en une seconde

Le haut de la page doit donner la réponse sans avoir à lire : un bandeau vert « Tous les systèmes opérationnels », ou un bandeau rouge « Incident en cours ». C'est ce que le visiteur vient chercher. S'il doit parcourir une liste de quinze services pour deviner s'il y a un problème, la page a raté son rôle principal.

2. Un statut par service, avec des noms que le client comprend

Sous le verdict global, chaque service a son propre état. Le piège classique, c'est de reprendre les noms internes : api-prod-eu-1, worker-queue, db-replica. Ton client ne sait pas ce que c'est. Il connaît « le site », « l'espace client », « le paiement en ligne », « l'application mobile ».

La règle simple : nomme chaque service comme ton client en parle au téléphone. Si ton monitor surveille https://api.monsite.fr/health, appelle-le « Espace client » ou « Réservation en ligne », pas « API health ».

3. Un historique honnête

Une page qui n'affiche que l'instant présent ne rassure pas vraiment. Les visiteurs regardent aussi le passé : combien de pannes ces derniers mois, combien de temps elles ont duré, quel pourcentage de disponibilité. Une barre de disponibilité sur 90 jours, avec un jour par case, se lit en un coup d'œil et raconte beaucoup plus qu'un long discours.

Un historique avec quelques cases rouges n'est pas un problème. C'est même ce qui rend la page crédible : tout le monde sait qu'aucun service ne tourne sans aucune panne. Ce qui inquiète, c'est une page parfaitement verte le jour où tout le monde constate que le site ne répond plus.

4. Des messages pendant l'incident

Un bandeau rouge dit qu'il y a un problème. Il ne dit pas si quelqu'un s'en occupe. Pendant une panne, ce que le client veut savoir, c'est : est-ce que vous êtes au courant, et quand est-ce que ça revient ? Un simple message daté (« On a identifié la cause, retour prévu dans 30 minutes ») change complètement la perception de l'incident. On y revient plus bas, avec des modèles prêts à l'emploi.

5. Les maintenances annoncées à l'avance

Une coupure prévue et annoncée est une maintenance. La même coupure sans prévenir est une panne, aux yeux de tes clients. Afficher « Maintenance prévue le dimanche 12 de 2 h à 4 h » quelques jours avant évite la plupart des tickets de ce jour-là.

6. L'heure de la dernière vérification

Un petit « Mis à jour à 14 h 32 » en bas de page a l'air anodin. C'est pourtant ce qui prouve que la page est vivante. Sans lui, un visiteur ne sait pas si ce vert date d'il y a trente secondes ou de la semaine dernière.

Les erreurs qui rendent une status page inutile

La page mise à jour à la main

C'est l'erreur la plus répandue. La page affiche ce que quelqu'un a pensé à y écrire, et pendant une panne, personne n'y pense : tout le monde est occupé à réparer. Résultat, la page reste verte pendant que le site est en panne. C'est pire que de ne pas avoir de page du tout, parce que le client en conclut que tu ne sais pas ce qui se passe, ou que tu le caches.

La solution : le statut doit venir de la surveillance automatique, pas d'un humain. Tu interviens ensuite pour ajouter du contexte (la cause, le délai), mais le rouge doit s'afficher tout seul.

La page hébergée sur le même serveur que le site

Si ta page de statut tourne sur la même machine que ton site, elle tombe en même temps que lui. Exactement au moment où on en a besoin. Une page de statut doit être hébergée ailleurs que les services qu'elle décrit : c'est l'intérêt de passer par un service externe.

Le jargon technique

« Latence élevée sur le cluster Redis suite à une saturation des connexions » est précis, et incompréhensible pour la plupart de tes clients. « Le site est plus lent que d'habitude, on a trouvé la cause et on corrige » dit la même chose, pour tout le monde. Garde les détails techniques pour ton postmortem interne.

Le silence après le premier message

Un message « On regarde » posté à 10 h, puis plus rien jusqu'à 13 h : pendant trois heures, tes clients se demandent si tu es toujours dessus. Même quand il n'y a rien de neuf, un message régulier rassure : « Toujours en cours, prochaine mise à jour dans 30 minutes ».

Les promesses que tu ne peux pas tenir

« Retour à la normale dans 10 minutes », puis 10 minutes plus tard, rien. Chaque promesse ratée coûte plus de confiance que la panne elle-même. Si tu ne sais pas, dis-le : « On ne peut pas encore estimer la durée, prochain point à 15 h ». Et de la même façon, n'affiche pas « 99,99 % de disponibilité garantie » si ton infrastructure ne permet pas de le tenir.

Écrire un message d'incident qui rassure

Un bon message d'incident répond toujours aux mêmes questions : qu'est-ce qui ne marche pas, pour qui, depuis quand, ce que tu fais, et quand tu donneras des nouvelles. Voici trois modèles à adapter, un pour chaque étape d'un incident. Mets l'étape en tête du message, ça permet de suivre l'avancement d'un coup d'œil.

Au début : tu as vu le problème

[En cours d'analyse] Le paiement en ligne ne fonctionne plus
depuis 14 h 05. Les commandes déjà validées ne sont pas
concernées. On cherche la cause.
Prochaine mise à jour à 14 h 45 au plus tard.

L'essentiel : reconnaître le problème vite, même sans en connaître la cause. Préciser ce qui n'est pas touché évite aussi beaucoup d'inquiétude inutile.

Pendant : tu as trouvé la cause

[Cause identifiée] Le prestataire de paiement rencontre
une panne de son côté. On a mis en place une solution de
secours : les commandes sont enregistrées et seront
débitées dès le retour du service.
Prochaine mise à jour à 15 h 30.

Pas besoin de tout expliquer. Une cause en une phrase, et surtout ce que ça change concrètement pour le client.

À la fin : c'est réglé

[Résolu] Le paiement en ligne fonctionne à nouveau depuis
15 h 12. Les commandes passées pendant l'incident ont été
débitées normalement. Désolé pour la gêne.

Donne l'heure exacte du retour, dis ce qu'il est advenu des actions faites pendant la panne, et excuse-toi simplement. Si la panne a été longue ou a eu des conséquences, un court récapitulatif quelques jours plus tard (ce qui s'est passé, ce que tu changes pour que ça ne se reproduise pas) renforce beaucoup la confiance.

Publier une status page gratuitement avec Pinguro

Pinguro inclut une page de statut publique dans le plan gratuit, alimentée directement par la surveillance : quand un service tombe, la page passe au rouge toute seule, sans que tu aies à y penser. Voici la mise en place.

1. Surveille les services à afficher

Crée un compte sur pinguro.app, puis un monitor pour chaque service que tes clients utilisent : ton site, ton espace client, ton API. Le plan gratuit permet 3 monitors actifs (HTTP, DNS, TCP ou heartbeat), vérifiés toutes les 15 minutes au plus court (sauf le heartbeat, qui peut descendre à 1 minute).

Soigne les noms dès maintenant : ce sont eux qui s'afficheront sur la page publique. « Site vitrine », « Réservation en ligne », « Espace client » plutôt que des noms techniques.

Pour choisir quoi surveiller, à quel rythme, et éviter les fausses alertes, voir le guide Surveiller son site web gratuitement.

2. Crée la page

Dans le dashboard, ouvre Page de statut, choisis un identifiant (lettres minuscules, chiffres et tirets, par exemple mon-entreprise), puis clique sur Créer la page. Ta page est en ligne à l'adresse :

https://pinguro.app/status/mon-entreprise

Tu peux la dépublier à tout moment : elle cesse alors d'être accessible, et ta configuration est conservée pour plus tard.

3. Ce que tes visiteurs y voient

• Un verdict global : « Tous les systèmes opérationnels » ou « Incident en cours ».
• L'état de chaque service, avec sa disponibilité sur les 30 derniers jours.
• Une barre de disponibilité sur 90 jours, un jour par case, avec le détail au survol.
• Les incidents récents, en cours ou résolus, avec les messages que tu as publiés.
• Les maintenances en cours, ou prévues dans les 7 prochains jours.
• L'heure de la dernière vérification.

Les vérifications faites pendant une maintenance déclarée ne comptent pas dans le pourcentage de disponibilité : une coupure prévue et annoncée ne fait pas baisser tes chiffres.

4. Publie des messages pendant un incident

Quand un incident est en cours, ouvre le monitor concerné dans le dashboard : une zone Timeline de l'incident te permet d'ajouter des messages datés, qui apparaissent sous l'incident sur la page publique. C'est là que tu colles les deux premiers modèles. Dès que le monitor répond de nouveau, l'incident passe tout seul en « résolu » sur la page et la zone de messages disparaît : publie ton dernier point avant, ou envoie le message de fin directement à tes clients.

5. Annonce tes maintenances

Dans Maintenance, crée une fenêtre avec un titre, une date de début, une date de fin et les monitors concernés. Elle s'affiche sur la page de statut sept jours avant son début, puis comme « Maintenance en cours » pendant la fenêtre.

Ce que la page ne fait pas (encore)

Pour que tu choisisses en connaissance de cause, voici les limites actuelles :

• Pas d'abonnement pour les visiteurs : ils ne peuvent pas recevoir d'email ou de flux RSS à chaque incident. Ils consultent la page quand ils en ont besoin.
• Jusqu'à 15 minutes de délai : en plan gratuit, la page peut mettre jusqu'à un quart d'heure à passer au rouge.
• Pas de rafraîchissement automatique : pour voir les derniers messages, le visiteur recharge la page.
• Pas d'incident créé à la main : un incident commence quand la surveillance détecte une panne. Tu ne peux pas en ouvrir un pour un problème qu'elle ne voit pas (un bug d'affichage, par exemple). Et une fois l'incident résolu, tu ne peux plus y ajouter de message.
• Une page par workspace, en français, avec la mention « Propulsé par Pinguro » en bas de page.
• Logo et couleur personnalisés : prévus avec les plans payants, qui ne sont pas encore disponibles.

La checklist d'une bonne status page

• Le verdict global se lit en une seconde, sur mobile comme sur ordinateur.
• Chaque service porte le nom que tes clients utilisent.
• Le statut vient de la surveillance automatique, pas d'une mise à jour manuelle.
• La page est hébergée ailleurs que ton site.
• L'historique est visible, pannes comprises.
• Pendant un incident : un premier message rapide, puis une mise à jour au moins toutes les 30 minutes, avec l'heure du prochain point.
• Les maintenances sont annoncées plusieurs jours avant.
• Le lien de la page est facile à trouver : pied de page de ton site, réponses automatiques du support, signature d'email.

Questions fréquentes

Une status page, c'est seulement pour les grosses entreprises ?

Non. C'est même souvent plus utile pour une petite structure : quand tu es seul ou à deux, chaque appel pendant une panne te coupe dans la réparation. Une page que tes clients consultent d'eux-mêmes te fait gagner ce temps.

Afficher mes pannes, ça ne va pas faire fuir mes clients ?

Tes clients voient déjà tes pannes : ils sont devant le site qui ne répond pas. La page ne révèle rien de nouveau, elle montre que tu es au courant et que tu t'en occupes. C'est le silence qui fait fuir, pas la transparence.

Je dois mettre la page sur mon propre nom de domaine ?

Ce n'est pas indispensable. Une adresse comme pinguro.app/status/mon-entreprise fonctionne très bien, et elle a un avantage : elle reste accessible même si c'est ton nom de domaine ou ton DNS qui a un problème. L'important est que le lien soit facile à trouver.

Et si la panne vient d'un service que je ne surveille pas ?

Alors la page restera verte. C'est pour ça qu'il vaut mieux surveiller ce que le client utilise vraiment (la page de connexion, le tunnel de commande) plutôt que seulement la page d'accueil. Si tu as des tâches planifiées (sauvegardes, synchronisations), un monitor heartbeat détecte aussi celles qui ne tournent plus : voir le guide Comment monitorer un cron job.

Conclusion

Une bonne page de statut n'a rien de spectaculaire. Un verdict clair, des noms compréhensibles, un historique honnête, et des messages réguliers quand ça casse. Ce n'est pas la page qui rassure tes clients, c'est ce qu'elle prouve : que tu sais ce qui se passe, et que tu t'en occupes.

Le plus dur n'est pas de la créer, c'est de la faire vivre pendant un incident. Garde les trois modèles de messages sous la main : le jour où tu en auras besoin, tu n'auras pas le temps de les écrire.