Santé plateforme et statut public : le vert veut dire quelque chose
Comment les contrôles de readiness, le cockpit admin, les passages de jobs et le statut public empêchent les incidents de devenir du folklore.
Les contrôles de santé n’ont rien de glamour. C’est tout leur charme. Ils disent au platform staff si l’app, la base, l’auth, le stockage, le mail, la file de notifications, les crons, les webhooks, l’API publique, la facturation, le coffre à secrets externe, l’audit d’activité et l’observabilité se comportent assez bien pour le travail normal. Treize composants, une question chacun : est-ce que cette chose fait son travail en ce moment ?
/api/health
L’endpoint technique de santé renvoie la readiness de l’app avec les contrôles par composant, la latence et un statut nettoyé. Il est fait pour la supervision d’uptime et les smoke checks de déploiement, pas pour laisser fuir des détails de base de données sur internet.
Le cockpit plateforme
/admin/platform/health est la console d’incident des platform owners et du staff ; les platform viewers ne voient pas l’entrée de sidebar et sont redirigés s’ils ouvrent l’adresse, et les admins d’organisation ne peuvent pas l’ouvrir du tout. Elle montre le statut global, la readiness de release, un résumé support, les causes probables, le statut par dépendance avec sa catégorie — plateforme, données, externe, intégration tenant, facturation, file ou evidence —, le nombre de tenants affectés là où c’est déductible sans risque, le dernier contrôle, le dernier succès et la dernière erreur, ainsi que les passages de jobs récents. Les routes cron et les jobs de fond écrivent des enregistrements de passage bornés, pour que la plateforme puisse dire si une tâche planifiée a tourné, a échoué, a été bloquée, a tourné partiellement, ou a discrètement fait la sieste.
Des mots, pas des codes
La console parle la langue du support. Les codes de sévérité internes sont remplacés par des libellés d’impact — Incident urgent, Impact élevé, Suivi incident requis, Revue basse priorité — et deux états existent précisément pour que personne ne panique devant la mauvaise carte : « Pas encore configuré » veut dire qu’une dépendance est délibérément absente ou n’a pas de moniteur direct, ce qui n’est pas une panne, et « Impossible à vérifier » veut dire que la page n’a pas pu lire ou valider les données source. La facturation peut signaler que la facturation par abonnement n’est pas configurée pendant que l’application locale des packages continue de fonctionner. Chaque carte de composant renvoie vers la page admin, de paramètres ou de santé la plus pertinente. Quand le support ouvre un ticket pendant un incident, un instantané de ce contexte peut être attaché automatiquement au ticket.
Statut public
/api/status/public expose un flux de composants nettoyé, pour une page de statut ou un moniteur externe. Il peut dire que le stockage de fichiers ou les tâches planifiées sont dégradés sans révéler de noms de tenants, de payloads, de secrets ou de stack traces. La transparence, c’est bien ; en dire trop reste en dire trop.
Pourquoi ça compte
Quand quelque chose ne va pas, le support a besoin d’une source de vérité commune. La santé transforme « c’est juste moi ? » en « le stockage est dégradé, les uploads sont touchés, tout le reste va bien ». Cette phrase économise une quantité surprenante d’oxygène.