Navré je ne suis pas sûr de comprendre votre remarque ?
Si vous publiez une app on-premise ce n'est pas un moteur de recherche qui vous dira si elle est déployé et utilisé…
Alors soit rassuré, le coeur c'est l'open source.
Pour SHM je pense me tourner vers une licence serveur opensource (c'est du soutien non obligatoire en somme) c'est plus aligner DevOps.
Ackify CE donnera lieu a un SaaS basé plus aligné pour les équipes non tech (mais c'est les mm fonctionnalités)
Merci Philippe 🙏
Et oui, l’égo fait sûrement partie de l’équation pour beaucoup d’entre nous — vouloir savoir si ce qu’on construit est utilisé, utile, apprécié, c’est humain.
Mais dans mon cas, c’est surtout très concret et stratégique.
Je fais de l’open source d’abord parce que je m’en sers moi-même, au quotidien, et que je crois profondément que des briques ouvertes, auditées et maîtrisables sont une base saine.
SHM est né exactement de ce besoin : arrêter de piloter “au doigt mouillé” des logiciels auto-hébergés, sans pour autant trahir la confiance des utilisateurs.
Et effectivement, pour certains projets comme Ackify, l’open source coexiste avec l’idée d’un SaaS (à venir, et là je pari que certain vont hurler au blasphème) :
non pas pour enfermer, mais pour proposer une alternative à ceux qui ne veulent pas (ou ne peuvent pas) gérer l’auto-hébergement.
Merci pour ton message en tout cas, ça fait vraiment plaisir à lire 👍
Non en effet, ce n'est pas adapté comme solution. Ackify se concentre sur la confirmation de lecture de document, ce n'est pas un outils de signatures certifiantes.
OpenTelemetry fait de l’auto-instrumentation : beaucoup de métriques partent par défaut, puis on filtre si on prend le temps.
SHM fait l’inverse : rien ne part tant que l’éditeur ne l’a pas explicitement défini.
Ce sont deux philosophies différentes. Pour deux besoins différent. Et encore une fois celui qui déploie l'app observer peut désactiver la télémétrie s'il ne souhaite pas participer…
Je ne cherche pas à “espionner” qui que ce soit comme un tracker publicitaire !
On parle d’un heartbeat serveur → serveur, opt-in, désactivable, sans données personnelles, sans IP, sans données sur les utilisateurs finaux.
Juste un signal technique : “cette instance tourne”.
Et côté fiabilité ; un heartbeat agrégé vaut quand même un peu mieux que :
- les retours de trolls,
- les étoiles GitHub,
- ou “on m’a dit sur un forum”.
Ce n’est pas de la surveillance, c’est du pilotage de projet.
Je ne récupère aucune donnée utilisateur.
L’outil ne fait qu’agréger des métriques envoyées volontairement par l’application elle-même, côté serveur.
La télémétrie est du ressort du créateur du produit, pas du mien.
C’est l’auteur de l’application qui choisit :
quelles métriques envoyer
si elles sont pertinentes (pour son produit)
et si la télémétrie est activée, désactivable ou absente (elle devrait tjs être désactivable)
Je ne définis aucune métrique “métier”.
Je fournis uniquement une brique technique agnostique pour agréger des événements JSON.
Rien de plus.
En résumé :
ce n’est ni du tracking imposé, ni une vision produit, ni une décision politique.
C’est un outil, libre aux mainteneurs de l’utiliser… ou pas.
Est-ce parce que c'est opensource que ca doit être dans la nature et fini…
Je ne suis pas d'accord, déjà savoir si ton produit est utilisé permet de savoir si tu dois continuer a investir dessus, s'il n'est pas utilisé a quoi bon, passe a autre chose plutot que de perdre du temps.
Ensuite en ayant des metrics d'utilisations tu sais également si ce que tu as imaginé est utilisé (ou pas), et tu sais alors sur quoi il faut se concentrer.
Une application n'est pas faite une fois et hop c'est balancé et c'est fini, il faut la faire vivre, évoluer, maintenir.
Vous avez raison sur le plan théorique - un admin avec accès BDD et à la clé privée Ed25519 pourrait forger une signature. C'est d'ailleurs vrai de tout système, y compris les tiers de confiance qui ont leurs propres admins.
Le terme "preuve" ici désigne une preuve vérifiable cryptographiquement dans le contexte d'un litige collaborateur/employeur, pas une preuve contre l'organisation elle-même. Pour ce cas d'usage (le plus fréquent), la signature Ed25519 avec horodatage est juridiquement solide.
Pour les cas nécessitant une preuve opposable à l'organisation, l'ancrage blockchain ou l'horodatage RFC 3161 sont effectivement des options
[^] # Re: Moteur de recherche
Posté par Benjy33 (site web personnel) . En réponse à la dépêche SHM : des métriques d’usage pour applications self-hosted… sans espionner les utilisateurs. Évalué à 1 (+0/-0).
Navré je ne suis pas sûr de comprendre votre remarque ?
Si vous publiez une app on-premise ce n'est pas un moteur de recherche qui vous dira si elle est déployé et utilisé…
Benjamin
[^] # Re: Intéressant
Posté par Benjy33 (site web personnel) . En réponse à la dépêche SHM : des métriques d’usage pour applications self-hosted… sans espionner les utilisateurs. Évalué à 1 (+0/-0).
En effet, merci nous sommes d'accord.
Merci en tout cas pour ton soutien.
Benjamin
# Mise à jour SHM v1.2.0
Posté par Benjy33 (site web personnel) . En réponse à la dépêche SHM : des métriques d’usage pour applications self-hosted… sans espionner les utilisateurs. Évalué à 7 (+7/-1).
Petit retour rapide côté projet.
Je viens de publier SHM v1.2.0.
Cette version ne change pas le principe de base, mais clarifie l’orientation du projet :
une télémétrie agnostique pour les logiciels auto-hébergés, sans hypothèses sur le modèle applicatif ni collecte de données personnelles.
La v1.2 rend surtout ce modèle utilisable sur des cas réels (plusieurs applications, volumes plus importants, meilleure lisibilité).
👉 https://github.com/btouchard/shm/releases/tag/v1.2.0
J'attends vos retour ;)
Benjamin
[^] # Re: c'est important ?
Posté par Benjy33 (site web personnel) . En réponse à la dépêche SHM : des métriques d’usage pour applications self-hosted… sans espionner les utilisateurs. Évalué à 4 (+4/-1). Dernière modification le 24 décembre 2025 à 00:26.
Ça me semble aussi essentiel, quand on met autant de temps et d'énergie dans un projet, il est impératif d'en connaître l'impact.
Merci
Benjamin
[^] # Re: c'est important ?
Posté par Benjy33 (site web personnel) . En réponse à la dépêche SHM : des métriques d’usage pour applications self-hosted… sans espionner les utilisateurs. Évalué à 3 (+3/-1).
Alors soit rassuré, le coeur c'est l'open source.
Pour SHM je pense me tourner vers une licence serveur opensource (c'est du soutien non obligatoire en somme) c'est plus aligner DevOps.
Ackify CE donnera lieu a un SaaS basé plus aligné pour les équipes non tech (mais c'est les mm fonctionnalités)
Benjamin
[^] # Re: c'est important ?
Posté par Benjy33 (site web personnel) . En réponse à la dépêche SHM : des métriques d’usage pour applications self-hosted… sans espionner les utilisateurs. Évalué à 5 (+5/-1).
Merci Philippe 🙏
Et oui, l’égo fait sûrement partie de l’équation pour beaucoup d’entre nous — vouloir savoir si ce qu’on construit est utilisé, utile, apprécié, c’est humain.
Mais dans mon cas, c’est surtout très concret et stratégique.
Je fais de l’open source d’abord parce que je m’en sers moi-même, au quotidien, et que je crois profondément que des briques ouvertes, auditées et maîtrisables sont une base saine.
SHM est né exactement de ce besoin : arrêter de piloter “au doigt mouillé” des logiciels auto-hébergés, sans pour autant trahir la confiance des utilisateurs.
Et effectivement, pour certains projets comme Ackify, l’open source coexiste avec l’idée d’un SaaS (à venir, et là je pari que certain vont hurler au blasphème) :
non pas pour enfermer, mais pour proposer une alternative à ceux qui ne veulent pas (ou ne peuvent pas) gérer l’auto-hébergement.
Merci pour ton message en tout cas, ça fait vraiment plaisir à lire 👍
Benjamin
[^] # Re: Bon de commande
Posté par Benjy33 (site web personnel) . En réponse à la dépêche Ackify CE : preuve de lecture cryptographique en Go + Vue3. Évalué à 2 (+1/-0).
Bonjour
Navré, je n'avais pas vu votre question.
Non en effet, ce n'est pas adapté comme solution. Ackify se concentre sur la confirmation de lecture de document, ce n'est pas un outils de signatures certifiantes.
Cordialement
Benjamin
Benjamin
[^] # Re: La télémétrie transparente, c'est comme la publicité non intrusive
Posté par Benjy33 (site web personnel) . En réponse à la dépêche SHM : des métriques d’usage pour applications self-hosted… sans espionner les utilisateurs. Évalué à 7 (+7/-1).
On ne débat clairement pas sur le même registre.
Je m’arrête là, ce n’est plus constructif.
Benjamin
[^] # Re: La télémétrie transparente, c'est comme la publicité non intrusive
Posté par Benjy33 (site web personnel) . En réponse à la dépêche SHM : des métriques d’usage pour applications self-hosted… sans espionner les utilisateurs. Évalué à 6 (+6/-1).
OpenTelemetry fait de l’auto-instrumentation : beaucoup de métriques partent par défaut, puis on filtre si on prend le temps.
SHM fait l’inverse : rien ne part tant que l’éditeur ne l’a pas explicitement défini.
Ce sont deux philosophies différentes. Pour deux besoins différent. Et encore une fois celui qui déploie l'app observer peut désactiver la télémétrie s'il ne souhaite pas participer…
Benjamin
[^] # Re: La télémétrie transparente, c'est comme la publicité non intrusive
Posté par Benjy33 (site web personnel) . En réponse à la dépêche SHM : des métriques d’usage pour applications self-hosted… sans espionner les utilisateurs. Évalué à 7 (+7/-1).
Ben donc il n'y a pas de problème, opentélémetry qui permet de tracker les utilisateurs est bien bien plus intrusif que ce je propose avec SHM…
Benjamin
[^] # Re: La télémétrie transparente, c'est comme la publicité non intrusive
Posté par Benjy33 (site web personnel) . En réponse à la dépêche SHM : des métriques d’usage pour applications self-hosted… sans espionner les utilisateurs. Évalué à 7 (+7/-1).
A priori tu rejettes toute métrique par principe, le débat est donc plutôt stérile.
Je propose un outil technique optionnel pour piloter un projet, pas espionner des utilisateurs (justement, ce n'est pas GA…)
Les lecteurs se feront leur avis.
Benjamin
[^] # Re: La télémétrie transparente, c'est comme la publicité non intrusive
Posté par Benjy33 (site web personnel) . En réponse à la dépêche SHM : des métriques d’usage pour applications self-hosted… sans espionner les utilisateurs. Évalué à 8 (+9/-2).
Je ne cherche pas à “espionner” qui que ce soit comme un tracker publicitaire !
On parle d’un heartbeat serveur → serveur, opt-in, désactivable, sans données personnelles, sans IP, sans données sur les utilisateurs finaux.
Juste un signal technique : “cette instance tourne”.
Et côté fiabilité ; un heartbeat agrégé vaut quand même un peu mieux que :
- les retours de trolls,
- les étoiles GitHub,
- ou “on m’a dit sur un forum”.
Ce n’est pas de la surveillance, c’est du pilotage de projet.
Benjamin
[^] # Re: c'est important ?
Posté par Benjy33 (site web personnel) . En réponse à la dépêche SHM : des métriques d’usage pour applications self-hosted… sans espionner les utilisateurs. Évalué à 6 (+6/-1).
Je pense que tu te trompes sur ce que je propose.
Je ne récupère aucune donnée utilisateur.
L’outil ne fait qu’agréger des métriques envoyées volontairement par l’application elle-même, côté serveur.
La télémétrie est du ressort du créateur du produit, pas du mien.
C’est l’auteur de l’application qui choisit :
Je ne définis aucune métrique “métier”.
Je fournis uniquement une brique technique agnostique pour agréger des événements JSON.
Rien de plus.
En résumé :
ce n’est ni du tracking imposé, ni une vision produit, ni une décision politique.
C’est un outil, libre aux mainteneurs de l’utiliser… ou pas.
Benjamin
[^] # Re: c'est important ?
Posté par Benjy33 (site web personnel) . En réponse à la dépêche SHM : des métriques d’usage pour applications self-hosted… sans espionner les utilisateurs. Évalué à 10 (+10/-1).
Est-ce parce que c'est opensource que ca doit être dans la nature et fini…
Je ne suis pas d'accord, déjà savoir si ton produit est utilisé permet de savoir si tu dois continuer a investir dessus, s'il n'est pas utilisé a quoi bon, passe a autre chose plutot que de perdre du temps.
Ensuite en ayant des metrics d'utilisations tu sais également si ce que tu as imaginé est utilisé (ou pas), et tu sais alors sur quoi il faut se concentrer.
Une application n'est pas faite une fois et hop c'est balancé et c'est fini, il faut la faire vivre, évoluer, maintenir.
Benjamin
[^] # Re: Preuve?
Posté par Benjy33 (site web personnel) . En réponse à la dépêche Ackify CE : preuve de lecture cryptographique en Go + Vue3. Évalué à 5 (+6/-1).
Vous avez raison sur le plan théorique - un admin avec accès BDD et à la clé privée Ed25519 pourrait forger une signature. C'est d'ailleurs vrai de tout système, y compris les tiers de confiance qui ont leurs propres admins.
Le terme "preuve" ici désigne une preuve vérifiable cryptographiquement dans le contexte d'un litige collaborateur/employeur, pas une preuve contre l'organisation elle-même. Pour ce cas d'usage (le plus fréquent), la signature Ed25519 avec horodatage est juridiquement solide.
Pour les cas nécessitant une preuve opposable à l'organisation, l'ancrage blockchain ou l'horodatage RFC 3161 sont effectivement des options
Benjamin
[^] # Re: iso27001
Posté par Benjy33 (site web personnel) . En réponse à la dépêche Ackify CE : preuve de lecture cryptographique en Go + Vue3. Évalué à 3 (+3/-0).
J'ai fais un article a ce sujet
https://www.ackify.eu/fr/blog/audit-sensibilisation-iso-27001
Benjamin
[^] # Re: iso27001
Posté par Benjy33 (site web personnel) . En réponse à la dépêche Ackify CE : preuve de lecture cryptographique en Go + Vue3. Évalué à 5 (+5/-0).
Bonjour
Oui c'est tout à fait dans cet optique que j'ai créer Ackify.
Je suis sur que cela conviendra à l'auditeur au vus de la signature cryptographique.
Bon courage pour votre audit 💪
Benjamin