Créer une page de statut de services sans code avec l'IA

Créer une page de statut sans code

Oui, et c'est un projet court : une ou deux pages, un tableau d'états et un historique d'incidents. Comptez 6 crédits pour une construction simple sur Zugo, 3 crédits par modification ensuite. Attention à une confusion fréquente : la page affiche l'état de vos services, elle ne les surveille pas.

Cette nuance décide de tout le reste. Une page de statut sans source d'information derrière elle affiche simplement ce que vous avez tapé la dernière fois, ce qui est pire que pas de page du tout.

À quoi sert vraiment une page de statut ?

À faire baisser le bruit pendant un incident. Quand un service tombe, vos utilisateurs ont deux réflexes : recharger, puis écrire au support. La page de statut intercepte le second, à condition d'être trouvable et à jour.

Elle sert aussi de preuve après coup. Un client qui vous demande pourquoi la facturation n'a pas fonctionné le 12 du mois n'a pas envie d'une explication orale : il veut une ligne datée qui dit ce qui s'est passé et quand c'est revenu à la normale.

Enfin, elle joue un rôle commercial rarement anticipé. Les acheteurs professionnels regardent l'historique public avant de signer, et une page qui reconnaît trois incidents documentés inspire plus confiance qu'une page vierge depuis deux ans, que personne ne croit.

Le seul cas où elle ne sert à rien : quand vous êtes le seul à la mettre à jour et que vous oubliez de le faire pendant les incidents. La page devient alors un mensonge silencieux, et c'est le reproche que vos clients formuleront le jour où ils s'en apercevront.

Que doit afficher la page pendant un incident ?

Quatre informations, pas une de plus, et toujours au même endroit. La tentation d'ajouter des graphiques détaillés arrive vite, alors que le lecteur en panne veut une réponse en trois secondes.

La liste des composants doit refléter le vocabulaire de vos utilisateurs, pas votre architecture technique. Personne ne sait ce qu'est votre file de traitement asynchrone. Tout le monde comprend « envoi des e-mails de confirmation ».

Le message d'incident mérite un modèle écrit à froid, avant d'en avoir besoin. En pleine panne, personne n'a le calme nécessaire pour rédiger. Trois phrases préparées à l'avance, dans lesquelles il ne reste qu'à compléter l'heure et le périmètre, valent mieux qu'une belle prose improvisée à minuit.

Une page générée surveille-t-elle vos services toute seule ?

Non, et il faut le dire clairement. Zugo génère la page, l'affichage des états, le formulaire de mise à jour et l'historique. La détection automatique des pannes est un autre métier, assuré par un outil de supervision qui interroge vos services en continu.

Trois façons de faire vivre la page existent, par ordre de complexité. La mise à jour manuelle : vous ouvrez un écran protégé et changez l'état. C'est rustique, mais c'est ce que font beaucoup d'équipes de moins de dix personnes, et cela fonctionne si la responsabilité est nommée.

La mise à jour depuis une base : les états vivent dans Supabase et la page les lit. Vous pouvez alors les modifier depuis un formulaire, un script ou un outil interne. Le branchement se fait sur un projet existant et le détail est expliqué dans notre article sur Supabase.

La mise à jour automatique : votre outil de supervision écrit dans cette même base quand une sonde échoue. C'est le montage le plus fiable, mais il demande du travail réel, plusieurs modifications successives et quelqu'un capable de configurer les alertes. Ce n'est pas une phrase à écrire, c'est un petit projet.

Comment décrire la page pour obtenir une base exploitable ?

En nommant vos composants, vos états et vos écrans. Une description vague donne une page décorative, une description précise donne quelque chose que vous pouvez brancher.

Exemple à adapter : « Page de statut pour une application de gestion. Bandeau d'état global en haut avec trois niveaux : opérationnel, incident partiel, panne majeure. Liste de cinq composants : site public, application, connexion, paiements, envoi d'e-mails. Section incident en cours avec titre, heure de détection et suivi horodaté. Historique des incidents des trois derniers mois. Page d'administration protégée par mot de passe permettant de changer un état et de publier un message. Design très sobre, fond clair, gros contrastes, lisible sur mobile. »

Ce paragraphe donne trois niveaux d'état, cinq composants, deux écrans et une contrainte de lisibilité. Demandez explicitement le mobile : une page de statut se consulte au téléphone, dans le train, par quelqu'un d'agacé.

Précisez aussi ce que vous ne voulez pas : pas de graphique de temps de réponse tant que vous n'avez pas de mesures réelles à y mettre. Un graphique vide ou inventé décrédibilise toute la page.

Combien coûte une page de statut en crédits ?

Peu, et c'est l'un des projets les plus économiques à générer, parce qu'il est petit par nature.

Une page publique seule revient à 6 crédits. Si vous ajoutez un écran d'administration et une page d'historique détaillée, vous passez sur une plateforme à 12 crédits pour les trois premières pages. La formule gratuite donne 5 crédits, Pro coûte $25 par mois pour 200 crédits, Business $99 par mois pour 800 crédits.

Prévoyez surtout des modifications les premières semaines : vous découvrirez en conditions réelles que vos composants sont mal découpés ou que le message d'incident manque d'un champ. Chaque ajustement coûte 3 crédits, et les regrouper reste la meilleure économie.

Côté délai, une page simple se construit en une minute environ. Le projet passe en bac à sable avant livraison, donc une version qui ne s'ouvre pas ne vous est pas remise.

Faut-il prévenir par e-mail à chaque incident ?

Pas à chaque incident, seulement à ceux qui empêchent réellement de travailler. Une notification pour un ralentissement de quelques secondes forme vos utilisateurs à ignorer vos messages, et le jour où vous en aurez vraiment besoin, personne ne le lira.

La règle utile tient en une ligne : on prévient quand l'utilisateur ne peut pas accomplir sa tâche, et on prévient une seconde fois au rétablissement. Ce deuxième message est celui que les équipes oublient le plus souvent, alors que c'est lui qui referme le sujet.

Techniquement, l'envoi passe par Resend, avec une liste d'abonnés stockée dans votre base. Le paramétrage est décrit dans l'article sur les e-mails de projet, et l'ajout se fait par modification sur un projet déjà en ligne.

Pensez à héberger cette page ailleurs que sur l'infrastructure qu'elle surveille. Une page de statut qui tombe en même temps que le service est une plaisanterie récurrente du métier, mais elle arrive vraiment.

Page maison ou service de statut du marché ?

Les deux se justifient, et la comparaison mérite d'être faite sans caricature.

Les services spécialisés gagnent nettement sur un point : la partie surveillance et notification est déjà faite, testée par des milliers d'équipes, avec des sondes réparties dans plusieurs régions. Reconstruire cela n'a aucun intérêt si votre besoin est standard.

La page générée prend l'avantage quand vous voulez un vocabulaire propre à votre métier, un affichage intégré à votre identité, ou quand vous tenez à héberger ces informations vous-même. Elle se marie bien avec une page de changelog, les deux répondant à la même question posée autrement : que s'est-il passé sur le produit.

Quelles limites accepter avant de se lancer ?

Trois, sans détour. Zugo ne remplace pas une équipe de développement sur un système complexe : une supervision multi-région avec bascule automatique n'est pas un projet de génération, c'est de l'infrastructure.

La logique très spécifique se construit par modifications successives. Calculer un taux de disponibilité à partir de vos propres relevés, par exemple, demande plusieurs passes et un accord clair sur la méthode de calcul avant d'écrire quoi que ce soit.

Enfin, la vérification en bac à sable garantit que la page s'ouvre, pas qu'elle dit la vérité. L'exactitude dépend entièrement du processus humain derrière : qui met à jour, sous quel délai, avec quel niveau de détail. C'est une décision d'organisation, pas une fonctionnalité.

Par où commencer cette semaine ?

Listez d'abord vos composants avec les mots de vos utilisateurs, cinq maximum. Écrivez ensuite vos trois modèles de message : détection, mise à jour, rétablissement. Nommez enfin la personne responsable de la publication pendant un incident, avec un remplaçant.

Construisez la page publique, testez-la en simulant un incident fictif un mardi matin, et regardez combien de temps il vous faut pour la mettre à jour. Si cela prend plus de cinq minutes, simplifiez l'écran d'administration avant d'ajouter quoi que ce soit d'autre.

Complétez plus tard avec l'historique, les abonnements et la connexion à votre supervision. Vous pouvez commencer sur zugo.dev, publier une première version honnête, et l'améliorer à mesure que vous découvrez ce dont vos utilisateurs ont réellement besoin de savoir.