Uptime Kuma

Uptime Kuma : sondes HTTP/TCP/ping, statuts publics, alertes (email, Slack, webhook…). Self-host, open source — savoir que c’est down avant le ticket support.

Léger, auto-hébergeable (Scaleway / OVHcloud), alertes actionnables. Le complementary de Sentry : dispo vs exception.

Uptime Kuma est un outil de monitoring de disponibilité : sondes (HTTP, TCP, ping, DNS…), tableaux de bord, pages de statut, et chaînes d’alerte. Nous le posons pour détecter une panne ou une dégradation avant que le client l’écrive. Ce n’est pas de l’analytics produit (PostHog) ni du stacktrace (Sentry) : c’est « est-ce que le service répond ? ».

Uptime Kuma, dans le socle Innovation Digitale, ce n’est pas une case à cocher sur une slide commerciale. C’est une brique que nous assumons en production : nous savons l’installer, la documenter, la tester, et la transmettre à une autre équipe. Le positionnement « sondes & alertes avant le client » résume le job ; le reste de cette fiche explique comment nous l’utilisons sur des projets réels — apps métier, APIs, modernisation, automatisation, TMA.

Beaucoup d’agences empilent les logos. Nous documentons le pourquoi et le comment. Uptime Kuma fait partie du socle parce qu’il tient dans le temps : documentation solide, communauté active, écosystème de talents, et une trajectoire qui ne force pas à tout jeter tous les dix-huit mois. C’est exactement le critère que nous appliquons quand un client demande un système qui doit encore tourner dans cinq ans.

Léger, auto-hébergeable (Scaleway / OVHcloud), alertes actionnables. Le complementary de Sentry : dispo vs exception.

Le critère n°1, c’est la stabilité opérationnelle. Uptime Kuma s’inscrit dans un écosystème où les sondes, le suivi des alertes et la disponibilité sont des sujets documentés, pas des bricolages. Quand un incident arrive à 2h du matin, nous voulons des patterns connus, des alertes actionnables, une communauté qui a déjà croisé le même cas — pas un outil abandonné six mois après le lancement.

Le critère n°2, c’est la documentation et la transmissibilité. Un logiciel qui vous appartient, c’est aussi un logiciel qu’une autre équipe peut reprendre. Uptime Kuma se recrute, s’audit, se forme. Nous pouvons écrire une doc courte, des critères Gherkin, une CI qui reste verte : le savoir ne reste pas dans la tête d’un seul prestataire.

Le critère n°3, c’est l’alignement avec la souveraineté numérique. Open source ou API maîtrisée, hébergement UE/FR possible selon le projet (Scaleway, OVHcloud), code remis au client : Uptime Kuma n’impose pas une cage propriétaire. Nous encapsulons derrière des ports hexagonaux quand c’est pertinent, pour pouvoir changer de brique sans réécrire le métier.

Sur un Brief ou un audit, nous partons du problème métier — pas de la techno. Ensuite seulement, Uptime Kuma entre en scène si c’est le bon outil. Exemple typique : une application métier Symfony + React, une API documentée, une base PostgreSQL, une CI, des tests qui protègent le domaine — et un run (TMA) qui voit les pannes et les risques avant le client. Uptime Kuma trouve sa place dans ce puzzle sans forcer le reste.

Concrètement, nous posons des frontières : domaine métier au centre, adapters pour l’UI, la BDD, les SaaS externes. Uptime Kuma vit surtout en périphérie (observabilité, sécurité, hébergement) — mais c’est là que le réel se joue après la mise en production. Dans tous les cas, nous documentons le « pourquoi ce choix » dans le dépôt : un futur mainteneur ne doit pas devoir deviner.

La qualité & méthode n’est pas un chapitre à part. Dès que Uptime Kuma touche du code ou de l’infra, nous le branchons dans le pipeline ou le runbook. Vert / silencieux = on peut dormir. Rouge / alerte = nous agissons avant la casse. C’est banal à écrire, radical à tenir — et c’est ce qui sépare un POC fragile d’un actif logiciel.

Pour les startups (POC / Build / scale) comme pour les PME/ETI, le même standard s’applique. Nous ne « faisons pas du Uptime Kuma pour faire du Uptime Kuma ». Nous l’utilisons pour un run propre : moins d’angles morts, des alertes utiles, plus de capacité à évoluer sans tout casser.

Uptime Kuma est un excellent choix quand le besoin touche les sondes, le suivi des alertes et la disponibilité, et que l’horizon du projet dépasse le trimestre. Si vous devez recruter, auditer, ou transmettre le SI, une brique mainstream et documentée comme Uptime Kuma réduit le risque opérationnel.

Nous passons notre tour quand un autre outil du socle couvre mieux le cas, ou quand l’existant client impose une contrainte claire (stack imposée, hébergeur, compétences internes). Exemple : les sondes natives d’un hébergeur (Scaleway, OVHcloud) suffisent parfois pour une vitrine simple — nous ne dupliquons pas pour le plaisir. L’honnêteté du discours fait partie de la méthode.

Nous évitons aussi les empilements « parce que c’est moderne ». Ajouter Uptime Kuma doit résoudre un goulot : angles morts de disponibilité, alertes fantômes, time-to-detect. Si le seul argument est le buzzword, ce n’est pas un argument.

Innovation Digitale choisit des technologies avec une trajectoire longue : versions majeures gérables, guides officiels à jour, issues et discussions publiques. Uptime Kuma coche ces cases. Ce n’est pas une garantie absolue — rien ne l’est — mais c’est un filtre qui élimine les paris jetables.

La communauté active, ça veut dire des réponses, des packages, des retours d’expérience. Ça veut aussi dire qu’un prestataire suivant pourra reprendre le flambeau. Pour un dirigeant, c’est aussi important que la feature list : la dépendance à une seule personne ou à un éditeur opaque, nous la refusons autant que possible.

Côté souveraineté made in France / Europe : selon le rôle de Uptime Kuma, nous privilégions les options UE (Scaleway, OVHcloud, self-host) quand le sujet data ou politique l’exige. Le site vitrine iD peut tourner sur Netlify ; vos apps métier, elles, choisissent l’hébergeur adapté.

En résumé : Uptime Kuma dans le socle iD, c’est une garantie de continuité : méthode avant magie. Une brique que nous expliquons, que nous testons, que nous documentons — et que vous possédez avec le reste du code.

Si vous hésitez entre plusieurs options (BDD, front, cloud, monitoring, sécu), le Brief 45 min sert exactement à ça : clarifier le problème, le risque, le périmètre, puis proposer un audit si le sujet tient la route. La stack suit le besoin — pas l’inverse.

Pour aller plus loin : consultez la documentation et le dépôt officiels ci-dessous, parcourez les autres fiches du socle, et regardez les réalisations (problématique → solution → résultat) pour voir Uptime Kuma (ou ses cousins) en situation réelle.