Alors que les solutions de monitoring serveur deviennent toujours plus complexes et dépendantes de stacks lourdes, deux projets open source (NdM: absence de licence) récents prennent le contre-pied de cette tendance : MonitorBox et Monitux. Leur objectif commun : revenir à un monitoring lisible, fiable et maîtrisable, pensé avant tout pour les administrateurs Linux.

MonitorBox : réduire le bruit pour mieux gérer l’urgence

MonitorBox part d’un constat largement partagé dans les équipes techniques : la multiplication des alertes engendre une fatigue des notifications, au point que les incidents critiques risquent d’être ignorés.
Le projet introduit une logique volontairement simple mais efficace : réduction des faux positifs par vérifications successives, séparation claire entre alertes critiques et informationnelles, et retour d’un outil longtemps abandonné mais redoutablement efficace : le pager (bipper).

En complément des notifications classiques, MonitorBox propose :

• une interface terminal pensée pour l’exploitation,
• un dashboard web léger,
• et une alerte matérielle dédiée pour les situations réellement urgentes.

Le projet assume une philosophie pragmatique : mieux vaut peu d’alertes fiables que beaucoup d’alertes ignorées.

Code source : https://github.com/simple-group/MonitorBox
Présentation : https://www.ihaveto.be/2026/01/pourquoi-jai-ressuscite-le-pager-des.html

Monitux : un monitoring “zero-dependency” pour réduire la surface d’attaque

Monitux s’inscrit dans une démarche encore plus radicale de sobriété technique. Le projet se définit comme un outil de monitoring serveur sans base de données, sans langage interprété (PHP, Python, Node.js), et sans dépendances externes.

Il repose exclusivement sur :

• les outils natifs GNU/Linux (top, df, ss, systemd…), un affichage web minimaliste, et une protection d’accès via les mécanismes standards d’Apache (.htaccess / .htpasswd).

Ce choix permet de limiter fortement la surface d’attaque, de simplifier l’installation et de garantir une excellente lisibilité du code. Monitux se destine particulièrement aux environnements où la stabilité, la sécurité et la compréhension priment sur la sophistication fonctionnelle.

Code source : https://github.com/simple-group/Monitux/
Présentation : https://www.ihaveto.be/2025/12/monitux-le-monitoring-serveur-revient.html

Une même philosophie : simplicité, contrôle et responsabilité

Bien que différents dans leur approche, MonitorBox et Monitux partagent une vision commune :
le monitoring ne doit pas devenir une boîte noire, ni un empilement de dépendances difficile à auditer. Ces projets s’adressent aux administrateurs et équipes techniques qui souhaitent reprendre le contrôle, réduire la complexité et privilégier des outils compréhensibles, durables et open source.

Les deux projets sont publiés sous licence libre et ouverts aux contributions.

NdM: aucune licence n'est mentionnée sur les deux projets en question, qui ne sont donc pas libres en l'état.

Quand on développe et distribue des applications open-source auto-hébergées, il y a une question très simple à laquelle il est presque impossible de répondre :

Combien d’instances actives de mon application sont réellement utilisées ?

C’est exactement le problème que j’ai rencontré avec Ackify, une application open-source de preuve de lecture de documents (politiques internes, procédures, formations, etc.), déployée en self-hosted par ses utilisateurs - sans que j'ai le moindre contrôle dessus.

Pas de SaaS, pas de compte centralisé, pas de tracking utilisateur.
Résultat : zéro visibilité.

👉 Combien d’instances Ackify tournent vraiment ?
👉 Quelles versions sont encore actives ?
👉 Quelles fonctionnalités sont utilisées (ou pas) ?

C’est pour répondre à ce besoin très concret que j’ai créé SHM – Self-Hosted Metrics.

SHM, c’est quoi ?

SHM est un serveur de télémétrie privacy-first, conçu spécifiquement pour les applications self-hosted open-source.

L’idée est simple :

• chaque instance auto-hébergée envoie périodiquement un snapshot de métriques agrégées
• aucune donnée utilisateur
• aucun événement individuel
• aucun tracking comportemental

Juste ce qu’il faut pour comprendre l’usage réel d’un logiciel déployé “dans la nature”.

---

Un point important : SHM est agnostique

Contrairement à beaucoup d’outils existants, SHM n’impose aucun schéma.

Tu envoies :

{
  "documents_created": 123,
  "active_users": 42,
  "webhooks_sent": 9
}

➡️ le dashboard s’adapte automatiquement :

• nouvelles cartes KPI
• nouvelles colonnes
• graphiques générés dynamiquement

Aucun frontend à recompiler, aucune migration à écrire.

---

Un petit mot sur Ackify

Ackify est l’application qui a déclenché tout ça :

• open-source
• self-hosted
• preuve de lecture avec signature cryptographique
• alternative légère à DocuSign pour des usages internes

SHM est désormais utilisé pour répondre à des questions très simples :

• combien d’instances actives ?
• combien de documents créés ?
• combien de signatures générées ?

---

Projet open-source

• Code source : https://github.com/btouchard/shm
• Déploiement simple en docker compose
• SDK Go (et Node.js) pour intégrer la collecte facilement

Le projet est encore très jeune (MVP), mais fonctionnel et déjà utilisé en conditions réelles.

Les retours, critiques et idées sont évidemment bienvenus 🙂

---

Stack technique (sobre et assumée)

• Backend : Go (binaire unique, léger)
• Stockage : PostgreSQL (JSONB)
• Déploiement : Docker
• Licence : AGPLv3 (SDK en MIT)
• Auth des instances : Ed25519 (clé générée localement, signature des snapshots)

Chaque instance :

• génère une identité cryptographique locale
• s’enregistre une seule fois
• signe chaque envoi de métriques ➡️ impossible de spoof une instance existante.

---

Et côté vie privée ?

C’était non négociable.

SHM :

• ne collecte aucune donnée personnelle
• ne collecte pas les IP (hors reverse-proxy)
• ne collecte ni hostname, ni username
• fonctionne sur des compteurs agrégés uniquement

C’est au mainteneur du logiciel de décider quelles métriques exposer, et à l’utilisateur final de pouvoir désactiver la télémétrie.