Vue lecture

SHM - La télémétrie qui respecte vos utilisateurs

Si vous développez un logiciel open source auto-hébergé, vous connaissez sûrement ce dilemme qui est de comment savoir si votre projet est réellement utilisé sans devenir l'affreux Big Brother que vous combattez ? Soit vous ne mesurez rien et vous codez dans le vide, soit vous collez du Google Analytics ou assimilé et vous trahissez l'esprit même du self-hosting.

Benjamin Touchard (que certains d'entre vous connaissent peut-être via son projet Ackify ) a décidé de résoudre ce problème avec SHM, pour Self-Hosted Metrics . Son idée c'est de proposer une télémétrie respectueuse de la vie privée, où chaque instance génère sa propre identité cryptographique dès le premier démarrage.

Concrètement, quand vous intégrez le SDK dans votre application (dispo en Go et Node.js 22+), chaque installation génère une paire de clés Ed25519, un peu comme quand vous générez vos clés SSH pour la première fois. Tous les échanges avec votre serveur SHM sont ensuite signés cryptographiquement, ce qui garantit l'intégrité des requêtes et leur origine. L'instance a une identité persistante (pseudonyme), mais ça n'identifie pas l'utilisateur final.

Côté données collectées, ensuite c'est vous qui décidez. Votre app envoie périodiquement un JSON avec les métriques que vous avez définies, et le dashboard s'adapte dynamiquement. Y'a pas de schéma imposé, pas de PII (données personnellement identifiables) et par défaut, le SDK collecte aussi des infos système (OS, CPU, RAM), mais c'est désactivable.

Pour ceux qui veulent héberger le bouzin, c'est du Docker classique... Vous créez un fichier compose.yml, vous configurez le DSN PostgreSQL, vous récupérez les migrations SQL, et hop un docker compose up -d. Le dashboard est alors accessible par défaut sur le port 8080 et affiche automatiquement vos métriques métier, la distribution des versions, le nombre d'instances actives, etc.

Et pour les utilisateurs finaux qui ne veulent vraiment pas participer, un simple DO_NOT_TRACK=true dans les variables d'environnement désactive complètement la télémétrie.

Le code du serveur est sous licence AGPL (les SDKs ont leur propre licence, vérifiez sur le dépôt) et y'a aussi des badges SVG à coller dans vos pages README pour afficher fièrement le nombre d'instances de votre app qui tournent.

Bref, si vous distribuez un logiciel auto-hébergé et que vous voulez savoir combien d'instances sont actives sans compromettre la vie privée des utilisateurs, c'est le top !

Merci à Benjamin pour le partage !

  •  

SHM : des métriques d’usage pour applications self-hosted… sans espionner les utilisateurs

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 ?

SHM

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.

Dashboard Graph
Dashboard Détail


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

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.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  
❌