Salut,
Le code est intégralement sous AGPL-3.0, y compris les features Pro. Rien n'est caché, rien n'est dans un repo privé. Le CLA c'est le même modèle que Nextcloud ou GitLab — mécanique pour maintenir le dual-licensing.
Oui, y'a du gating sur certaines features. Oui, on peut le retirer et recompiler. C'est exactement ce que l'AGPL permet et j'ai aucun problème avec ça.
Le modèle open-core, on peut ne pas aimer. Mais tout le monde ne vit pas d'amour et d'eau fraîche. Le Pro à 9€/mois c'est ce qui me permet de maintenir le projet dans la durée. Si c'est de l'open source washing, alors la moitié de l'écosystème libre qu'on utilise au quotidien l'est aussi.
Benjamin
Je suis totalement d'accord avec toi sur le principe, un ClusterRole read-only donne effectivement une vue large sur le cluster, et dans un contexte multi-tenant strict ou en environnement très sensible, c'est un vrai sujet.
Cela dit, c'est le compromis assumé de Maintenant : un seul déploiement, zéro config, tu vois ton cluster en 30 secondes. Demander à l'utilisateur de déployer un agent par namespace, c'est exactement le genre de complexité opérationnelle que le projet cherche à éviter — et que la plupart des outils de monitoring K8s (Prometheus, Datadog, Grafana Agent…) évitent aussi d'ailleurs, pour les mêmes raisons.
En pratique, il y a déjà un filtrage par namespace configurable, tu peux restreindre Maintenant à un ou plusieurs namespaces spécifiques plutôt que de lui donner une vue cluster-wide. Dans ce cas un Role (namespace-scoped) suffit au lieu du ClusterRole.
Mais oui, pour les environnements avec des exigences d'isolation fortes, Maintenant n'est probablement pas le bon outil. Et c'est OK, le positionnement c'est les petites équipes et les déploiements raisonnables, pas les clusters multi-tenant enterprise.
Hello Raoul, pas tout à fait, Dockhand est plutôt un concurrent de Portainer : c'est un outil de gestion qui démarre, arrête et redéploie tes conteneurs.
Maintenant ne touche jamais à ta stack, c'est purement de l'observation et de l'alerte : état des conteneurs, probing HTTP/TCP, heartbeats, SSL, métriques, page de statut.
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: Open source washing
Posté par Benjy33 (site web personnel) . En réponse à la dépêche Maintenant : monitorer toute sa stack Docker depuis un seul conteneur. Évalué à 3 (+2/-0).
Salut,
Le code est intégralement sous AGPL-3.0, y compris les features Pro. Rien n'est caché, rien n'est dans un repo privé. Le CLA c'est le même modèle que Nextcloud ou GitLab — mécanique pour maintenir le dual-licensing.
Oui, y'a du gating sur certaines features. Oui, on peut le retirer et recompiler. C'est exactement ce que l'AGPL permet et j'ai aucun problème avec ça.
Le modèle open-core, on peut ne pas aimer. Mais tout le monde ne vit pas d'amour et d'eau fraîche. Le Pro à 9€/mois c'est ce qui me permet de maintenir le projet dans la durée. Si c'est de l'open source washing, alors la moitié de l'écosystème libre qu'on utilise au quotidien l'est aussi.
Benjamin
Benjamin
[^] # Re: Cluster reader
Posté par Benjy33 (site web personnel) . En réponse à la dépêche Maintenant : monitorer toute sa stack Docker depuis un seul conteneur. Évalué à 3 (+2/-0).
Je suis totalement d'accord avec toi sur le principe, un ClusterRole read-only donne effectivement une vue large sur le cluster, et dans un contexte multi-tenant strict ou en environnement très sensible, c'est un vrai sujet.
Cela dit, c'est le compromis assumé de Maintenant : un seul déploiement, zéro config, tu vois ton cluster en 30 secondes. Demander à l'utilisateur de déployer un agent par namespace, c'est exactement le genre de complexité opérationnelle que le projet cherche à éviter — et que la plupart des outils de monitoring K8s (Prometheus, Datadog, Grafana Agent…) évitent aussi d'ailleurs, pour les mêmes raisons.
En pratique, il y a déjà un filtrage par namespace configurable, tu peux restreindre Maintenant à un ou plusieurs namespaces spécifiques plutôt que de lui donner une vue cluster-wide. Dans ce cas un Role (namespace-scoped) suffit au lieu du ClusterRole.
Mais oui, pour les environnements avec des exigences d'isolation fortes, Maintenant n'est probablement pas le bon outil. Et c'est OK, le positionnement c'est les petites équipes et les déploiements raisonnables, pas les clusters multi-tenant enterprise.
Benjamin
[^] # Re: Alternative
Posté par Benjy33 (site web personnel) . En réponse à la dépêche Maintenant : monitorer toute sa stack Docker depuis un seul conteneur. Évalué à 5 (+4/-0).
Hello Raoul, pas tout à fait, Dockhand est plutôt un concurrent de Portainer : c'est un outil de gestion qui démarre, arrête et redéploie tes conteneurs.
Maintenant ne touche jamais à ta stack, c'est purement de l'observation et de l'alerte : état des conteneurs, probing HTTP/TCP, heartbeats, SSL, métriques, page de statut.
Benjamin
[^] # 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.
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.
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.
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. 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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