Un jour, coupure réseau sur un de nos sites. Les ERP ne répondent plus. De son côté, l’équipe infra est déjà dessus : elle cherche d’où vient la panne et comment rétablir. Sauf que personne n’a communiqué. Résultat, les équipes dev et projet se retrouvent à recevoir des tickets et des messages sur cette coupure, sans rien savoir de la situation.

Ce genre de scène, je l’ai vue sous plein de formes dans les boîtes où j’ai bossé :

• Une appli interne passe en nouvelle version, sans changelog. Les utilisateurs ne savent pas qu’elle a été mise à jour, ni ce qui a bougé, ni ce qui a été corrigé.
• Un service va être coupé deux heures pour une maintenance. Si personne ne l’annonce, tout le monde le découvre en plein travail.
• Microsoft 365 tombe. Outlook et Teams ne répondent plus, l’IT n’y peut rien, mais tant qu’elle ne l’a pas dit, c’est quand même vers elle que tout le monde se tourne.

À chaque fois, quelqu’un savait. L’info n’est simplement jamais arrivée jusqu’aux personnes concernées.

C’est pour régler ça que j’ai créé Statup : une status page auto-hébergée où chaque équipe écrit une fois ce qui est en panne, ce qui est prévu et ce qui a changé, et où tout le monde le lit, en clair. La première version publique vient de sortir, alors je vous la présente.

Statup, c’est quoi ?

Une page web que tout le monde dans l’entreprise peut ouvrir, depuis un poste ou un téléphone, pour savoir si un outil marche, ce qui est en cours et ce qui est prévu. Le tout repose sur trois briques :

• Les services : les outils dont les gens se servent au quotidien, comme la messagerie, le VPN, l’ERP ou la téléphonie. Chacun affiche un état parmi quatre : opérationnel, dégradé, en panne ou en maintenance.
• Les événements : ce qui est publié sur la page. Un incident quand quelque chose casse, une maintenance quand une intervention est prévue, une annonce pour le reste : une mise à jour, un nouvel outil, une imprimante qui change d’étage. Un incident passe les services concernés en dégradé ou en panne selon son impact, une maintenance les passe en maintenance, et tout revient en opérationnel quand c’est terminé.
• Les personnes : les lecteurs consultent la page, avec ou sans compte selon le choix des administrateurs. Les éditeurs publient les événements, que ce soit l’IT ou, par exemple, la responsable d’une appli métier qui annonce une panne sur son outil. Les administrateurs gèrent en plus les réglages, l’équipe et la mise en page.

Le tableau de bord, sur des données de démo.

Le bandeau en haut répond tout de suite à la question que tout le monde se pose : un service est perturbé, le Wi-Fi des 2e et 3e étages, depuis 48 minutes, avec la dernière nouvelle publiée. En dessous, chaque service avec ses 30 derniers jours, l’activité récente et les maintenances à venir.

Ce qu’il sait faire

Une page qui répond d’abord : le bandeau dit s’il y a un souci, ce qui est touché et depuis quand, avant tout le reste. La page se rafraîchit toute seule chaque minute.

Les incidents, du début à la fin : de l’analyse à la résolution, avec des mises à jour datées et des modèles réutilisables pour les pannes qui reviennent. Microsoft 365 tombe ? Un incident sur Outlook et Teams, et une phrase pour dire que la panne est chez Microsoft et qu’il n’y a rien à faire de notre côté.

Des maintenances qui se gèrent seules : annoncée à l’avance, une maintenance démarre et se termine aux heures prévues, sans personne au clavier. Elle peut aussi préciser que les services restent utilisables pendant les travaux.

Les nouveautés : c’est le changelog qui manquait à l’appli interne de l’intro. Une annonce se lit comme un court article : ce qui a changé, ce qui a été corrigé, où se trouve désormais telle fonction. Et à la fin d’une maintenance, un bouton prépare directement l’annonce des nouveautés, liée à la maintenance d’où elles viennent.

L’historique : tous les événements dans une liste, avec une recherche et des filtres par type, service ou date. Pratique pour retrouver quand on a touché au serveur de mail la dernière fois.

Être prévenu sans ouvrir la page : un flux Atom, à suivre dans un lecteur de flux ou dans sa messagerie, avec une page qui explique comment s’abonner à ceux qui n’ont jamais entendu parler de RSS.

Une page à votre image : ouverte à tous ou réservée aux membres, avec le nom et le logo de l’entreprise. Les blocs se déplacent, s’agrandissent ou se masquent directement sur la page. Le tout en français ou en anglais, en clair ou en sombre.

L’installer

J’ai choisi Rust parce que je voulais quelque chose de léger et moderne. Statup tient dans un seul binaire avec une base SQLite embarquée, et l’image Docker fait moins de 10 Mo à télécharger. Elle tourne sur n’importe quel serveur Linux, en x86-64 comme en ARM.

Avec Docker, trois commandes suffisent :

mkdir statup && cd statup
curl -O https://raw.githubusercontent.com/karl-cta/statup/main/docker-compose.yml
docker compose up -d

L’app répond ensuite sur le port 3000 du serveur. Au premier lancement, elle vous guide en quatre étapes : le compte administrateur, le nom et le logo de la page, les services à suivre, puis l’adresse à partager.

Pour avoir du HTTPS et une adresse du type status.mondomaine.fr, il suffit de la placer derrière un reverse proxy. J’en parle dans mon article sur Nginx Proxy Manager, et le guide self-host donne les configurations pour nginx et Caddy, les sauvegardes et le reste des réglages.

Ce qu’il ne fait pas encore

Autant être clair sur la plus grosse limite : aujourd’hui, Statup ne sait que ce qu’on lui dit. Il ne vérifie pas lui-même que vos services répondent. Si personne ne l’alimente, on en revient exactement au problème du départ.

C’est là-dessus que je veux bosser ensuite : que Statup détecte une partie des pannes tout seul, avec des vérifications simples (un ping, une requête HTTP sur le service), et une API pour que d’autres outils publient d’eux-mêmes, un outil de supervision comme Zabbix ou Grafana par exemple.

Côté alertes, pas encore de notifications Teams, Slack ou par mail : on suit Statup sur la page ou via son flux Atom. C’est sur la feuille de route, avec les groupes d’utilisateurs qui ne voient que leurs services et les maintenances récurrentes.

Conclusion

Statup est né d’un problème de communication que j’ai vu revenir un peu partout. Je l’ai pensé pour l’interne, mais j’aimerais qu’il serve plus largement : une page publique marche tout aussi bien pour prévenir des clients d’une panne ou d’une maintenance. Même OVH, pendant la crise Januscape, a dû monter une bannière en pleine opération pour prévenir ses clients.

Statup n’a encore jamais tourné en production, donc je serais très content d’avoir des gens pour le tester, en perso comme en entreprise. Et si vous avez des idées, je prends tout : les issues GitHub sont là pour ça.

Liens utiles :

• statup.dev
• Statup sur GitHub
• Le guide self-host