SHM — Pourquoi j’ai créé un système de métriques pour le self-hosted

Quand on édite un logiciel self-hosted, on accepte une réalité un peu frustrante :
👉 on ne sait presque rien de ce qui se passe réellement chez ses utilisateurs.

Combien d’instances sont actives ?
Quelles versions tournent encore ?
Quelles fonctionnalités sont réellement utilisées ?
À quel rythme les projets vivent… ou meurent ?

Dans le monde du SaaS, ces réponses sont triviales.
Dans le monde du self-hosted, elles sont presque taboues.

C’est exactement de cette tension qu’est né SHM — Self-Hosted Metrics.

La genèse : voler à l’aveugle en self-hosted

Je développe et maintiens plusieurs projets open-source et auto-hébergés, comme Ackify.
À chaque fois, le même constat revient :

• des étoiles GitHub (cool mais très abstrait)
• des pulls Docker Hub (impressionnants… mais trompeurs)
• quelques issues et discussions
• aucune vision claire de l’usage réel

Et surtout :
👉 aucune solution existante réellement adaptée au self-hosted

Les outils de télémétrie classiques (GA, Mixpanel, Segment…) sont :

• intrusifs
• orientés SaaS
• souvent incompatibles avec une philosophie open-source / privacy-first

À l’inverse, Prometheus, Grafana & co sont :

• excellents pour l’infra
• totalement inadaptés aux métriques produit / métier

Il manquait quelque chose entre les deux.

Le postulat de départ

SHM repose sur quelques principes simples (et non négociables) :

1. Privacy first, vraiment

Pas de tracking utilisateur.
Pas de PII.
Pas de données métiers sensibles.

👉 Uniquement des compteurs agrégés, envoyés (a VOTRE instance SHM) volontairement par l’instance (les instances de VOTRE produit).

2. L’éditeur ne doit pas espionner

L’utilisateur sait ce qui est envoyé.
Il peut désactiver la télémétrie.
Il peut inspecter le code.

La confiance est un prérequis, pas une option.

3. Zéro schéma, zéro friction

Chaque application est différente.

Donc SHM devait être :

• agnostique
• capable de recevoir n’importe quel JSON
• sans configuration côté serveur

Si demain tu veux envoyer documents_signed, jobs_processed ou pizzas_eaten, ça doit juste marcher.

SHM, concrètement, c’est quoi ?

SHM est un serveur de métriques auto-hébergé, conçu pour les éditeurs de logiciels self-hosted.

Il permet de :

• recenser les instances actives
• suivre les versions déployées
• collecter des KPIs métier agrégés
• sans jamais collecter de données utilisateurs

Le tout avec :

• une API simple
• une lib cliente
• un dashboard dynamique intégré

Une approche technique volontairement simple

Backend

• Go
• API HTTP minimaliste
• PostgreSQL avec stockage JSONB
• une seule image Docker

Dashboard

• UI embarquée dans le binaire
• aucun build frontend externe
• génération dynamique des KPIs à partir des données reçues

👉 Tu envoies des clés, SHM les affiche.
Pas de migration. Pas de config. Pas de magie noire.

Une identité cryptographique par instance

Un point important :
SHM ne fait pas confiance au réseau, ni aux IP, ni aux headers.

Chaque instance :

• génère une paire de clés Ed25519
• s’enregistre une seule fois
• signe chaque envoi de métriques

Résultat :

• impossible de spoof une instance
• aucune authentification lourde
• aucun secret partagé

C’est simple, robuste, et très peu coûteux.

Métriques système vs métriques métier

SHM distingue volontairement deux mondes :

Métriques système (automatiques)

• OS / arch
• CPU
• mémoire
• environnement (prod, staging…)

Métriques métier (libres)

• nombre d’utilisateurs
• documents créés
• signatures
• jobs
• tout ce qui fait sens pour ton produit

C’est cette séparation qui permet d’avoir une vision claire :
👉 comment le logiciel vit, pas juste comment il tourne.

Pourquoi SHM est “agnostique”

SHM ne connaît pas ton produit.
Il ne cherche pas à le comprendre.

Il se contente de :

• stocker des snapshots JSON
• agréger
• afficher
• historiser

Ce choix est volontaire :

• pas de coupling
• pas de modèle imposé
• pas de dette produit côté serveur

SHM est un outil, pas une plateforme qui dicte ta roadmap.

À qui s’adresse SHM ?

• éditeurs de logiciels self-hosted
• projets open-source qui veulent comprendre leur adoption
• équipes qui refusent le tracking intrusif
• développeurs qui veulent des métriques produit, pas du marketing

Si tu publies des binaires, des images Docker ou des charts Helm, SHM est probablement fait pour toi.

Ce que SHM n’est pas (et ne sera pas)

• ❌ un outil de tracking utilisateur
• ❌ un remplaçant de GA ou Mixpanel
• ❌ une solution SaaS opaque
• ❌ une plateforme de revente de données

SHM restera :

• auto-hébergeable
• open-source
• orienté éditeur, pas surveillance

Et maintenant ?

SHM est encore jeune.
C’est un MVP fonctionnel, né d’un besoin réel.

La suite dépendra :

• des retours
• des usages
• de la communauté

Si tu développes un projet self-hosted et que tu veux enfin comprendre comment il vit, sans trahir tes utilisateurs :
👉 SHM est là pour ça.

🔗 Projet GitHub
https://github.com/btouchard/shm