Anonymous statistical

Bebel27 · Mars 28, 2026, 10:50

Bonsoir , j’ai découvert ce log lors de la dernière mise à jour de JMQTT

Dans la classe jMQTTPlugin , la fonction stats() est appelée :

Cette fonction envoie une requête HTTP POST vers :
https://stats.bad.wf/v1/query

avec un payload contenant :

hardwareKey (identifiant unique machine)
un UUID persistant + un UUID rotatif
version Jeedom / plugin
informations système (OS, PHP, Python)
langue et source du plugin

Un log est généré :
« Anonymous statistical data have been sent (…) »

Points qui m’ interrogent :

ce mécanisme n’est pas documenté dans la doc utilisateur du plugin.
il n’y a pas d’option visible pour désactiver cet envoi , Plugin ou configuration Jeedom !
la présence de hardwareKey + UUID rend l’anonymisation discutable

Je ne remets pas en cause l’intention (statistiques d’usage), mais :

une clarification serait bienvenue @Bad

la finalité exacte de ces données
leur durée de conservation

l’ajout :

une option de désactivation
une case pour le consentement .

Merci

jerryzz · Mars 29, 2026, 7:40

Bonsoir,

Merci pour ton analyse, et j’'en suis très surpris.

J’apprécie énormément ce plug-in que j’utilise depuis des années, merci au travail déployé par son développeur.

Néanmoins, j’ajouterai aussi à celtte liste, l’adresse IP de sortie, considérée par la RGDP comme donnée personnelle.

« les adresses IP, qui permettent d’identifier indirectement une personne physique, sont des données à caractère personnel, de sorte que leur collecte constitue un traitement de données à caractère personnel et doit faire l’objet d’une déclaration préalable auprès de la CNIL ».

https://www.cnil.fr/fr/comprendre-mes-droits/le-droit-detre-informe-sur-lutilisation-de-vos-donnees

https://www.cnil.fr/fr/comprendre-mes-droits/le-droit-dopposition-refuser-lutilisation-de-vos-donnees

Sans documentation, ni information de l’utilité, l’exploitation, utilisation de ces données pseudo-anonymisées, un consentement semble au moins être la base.

Bebel27 · Mars 29, 2026, 8:33

Oui, en effet, l’adresse IP est également transmise implicitement via HTTP.
C’est un élément supplémentaire qui me laisse penser que ce n’est pas conforme au RGPD.

Ce qui est plus problématique, c’est qu’une fois le plugin passé en version stable, le développeur peut le faire évoluer sans repasser par une véritable étape de validation ou de contrôle. Cela ouvre la porte à ce type de dérives.

À première vue, il ne semble pas y avoir d’intention malveillante, mais cela soulève tout de même des questions : où vont réellement les données, que deviennent-elles, et que se passe-t-il si elles tombent entre de mauvaises mains (sécurité du serveur, accès non autorisé, etc.) ?

J’ai néanmoins bloqué tout envoi de données vers ce serveur.

Bad · Mars 30, 2026, 1:18

Bonjour à tous,

Je comprends vos inquiétudes et vos demandes, je vais tâcher d’y répondre.

Ce mécanisme a été ajouté en 2023, afin d’avoir de la visibilité sur les systèmes sur lesquels tournent jMQTT, notamment suite aux problèmes subits avec les machines ne supportant que Python2 et aussi pour savoir si certains choix ne vont pas impacter trop d’utilisateurs.

Initialement, l’information souhaitée était la version de jMQTT (+source), de Jeedom, du système Debian, de Python et de PHP. Pour savoir quand introduire une nouvelle langue de traduction, la langue du système a aussi été incluse.

Afin de pouvoir rafraichir des statistiques précédemment reçues (sans créer de doublons), j’ai initialement utilisé la hardwareKey (identifiant « unique » de l’installation Jeedom), et ajouté un compteur pour savoir combien de fois une installation a envoyé ses statistiques. Vous le voyez peut-être venir et je m’en doutais un peu aussi, mais je me suis rapidement rendu compte que la hardwareKey n’est pas toujours unique : notamment quand une installation est clonée et que la hardwareKey n’est pas régénérée.
Donc j’ai arrêté d’utiliser la hardwareKey au profit d’un UUID généré dynamiquement lors de chaque envoi de statistique et du précédant UUID pour référence, cela permet d’éviter que compter un clone d’installation comme la même machine.
Je reconnais que la hardwareKey n’est aujourd’hui pas nécessaire et doit être supprimée, ce sera fait dans la prochaine version.

Ces informations sont envoyées tous les 5 à 7 jours, ou sur mise à jour du plugin, et sont conservées 10 jours maximum après qu’elles aient été reçues, les mises à jour successives ne sont pas historiées, seul les données « live » sont utilisées.

L’infrastructure de collecte est hébergée en VM/docker sur des serveurs dédié chez OVH en France et protégé par des reverse-proxy (WAF) ne transmettant pas l’adresse IP réelle du client au service docker. Les logs d’accès à cette infrastructure, ainsi que les alertes de sécurité, sont archivées à part pour 60 à 365 jours, sans les données transmises.
Donc : il n’y a pas de corrélation entre les statistiques et les IP venant se connecter au service.

Dans les prochaines versions :

du plugin, une case à cochée sera mise en place dans la page de configuration du plugin pour désactiver les statistiques, et la hardwareKey ne sera plus envoyée,
de la documentation, des précisions au sujet des statistiques ajoutée.

En toute transparence, voici les données sortant du service (à 15h10 le 30/03/2026) :

{
	"branch": {
		"beta": 72,
		"dev": 1,
		"stable": 3812,
		"unknown": 1
	},
	"reason": {
		"cron": 3125,
		"install": 24,
		"update": 737
	},
	"config_version": {
		"13": 8,
		"13.0": 8,
		"13.0.0": 8,
		"16": 8,
		"16.0": 8,
		"16.0.0": 8,
		"18": 12,
		"18.0": 12,
		"18.0.0": 12,
		"19": 4,
		"19.0": 4,
		"19.0.0": 4,
		"20": 6,
		"20.0": 6,
		"20.0.0": 6,
		"22": 246,
		"22.0": 246,
		"22.0.0": 246,
		"23": 1916,
		"23.11": 1916,
		"23.11.3": 28,
		"23.11.5": 8,
		"23.11.6": 82,
		"23.11.7": 11,
		"23.11.8": 1787,
		"26": 1686,
		"26.1": 1685,
		"26.1.1": 938,
		"26.1.2": 747,
		"26.2": 1,
		"26.2.0": 1
	},
	"source": {
		"file": 2,
		"github": 39,
		"market": 3845
	},
	"distrib_name": {
		"debian": 3032,
		"generic": 32,
		"genericcloud": 6,
		"nocloud": 4,
		"raspbian": 469,
		"unknown": 343
	},
	"distrib_version": {
		"10": 600,
		"11": 2057,
		"12": 801,
		"13": 26,
		"unknown": 402
	},
	"hardware_name": {
		"atlas": 303,
		"bhyve": 4,
		"container-other": 2,
		"diy": 735,
		"docker": 111,
		"freebox": 55,
		"google": 1,
		"kvm": 722,
		"luna": 245,
		"lxc": 93,
		"microsoft": 139,
		"odroid": 3,
		"oracle": 71,
		"parallels": 1,
		"qemu": 2,
		"rpi": 43,
		"rpi1": 4,
		"rpi2": 26,
		"rpi3": 360,
		"rpi4": 510,
		"rpi5": 129,
		"rpiz": 1,
		"smart": 181,
		"vmware": 142,
		"xen": 3
	},
	"jeedom_version": {
		"4": 3886,
		"4.0": 2,
		"4.0.6": 2,
		"4.2": 9,
		"4.2.14": 2,
		"4.2.18": 1,
		"4.2.20": 4,
		"4.2.21": 2,
		"4.3": 163,
		"4.3.12": 5,
		"4.3.15": 8,
		"4.3.16": 1,
		"4.3.17": 45,
		"4.3.18": 2,
		"4.3.19": 6,
		"4.3.20": 6,
		"4.3.21": 19,
		"4.3.22": 20,
		"4.3.23": 50,
		"4.3.9": 1,
		"4.4": 602,
		"4.4.0": 1,
		"4.4.10": 1,
		"4.4.12": 98,
		"4.4.14": 3,
		"4.4.15": 1,
		"4.4.16": 3,
		"4.4.17": 26,
		"4.4.18": 10,
		"4.4.19": 248,
		"4.4.2": 3,
		"4.4.20": 148,
		"4.4.3": 1,
		"4.4.5": 12,
		"4.4.6": 16,
		"4.4.7": 8,
		"4.4.8": 12,
		"4.4.9": 11,
		"4.5": 3110,
		"4.5.0": 143,
		"4.5.1": 38,
		"4.5.2": 2920,
		"4.5.3": 9
	},
	"php_version": {
		"7": 2988,
		"7.3": 682,
		"7.3.11": 4,
		"7.3.14": 7,
		"7.3.19": 72,
		"7.3.27": 31,
		"7.3.29": 44,
		"7.3.31": 521,
		"7.3.9": 3,
		"7.4": 2306,
		"7.4.25": 3,
		"7.4.28": 2,
		"7.4.3": 3,
		"7.4.30": 42,
		"7.4.33": 2255,
		"7.4.8": 1,
		"8": 898,
		"8.0": 2,
		"8.0.1": 1,
		"8.0.3": 1,
		"8.1": 6,
		"8.1.2": 2,
		"8.1.34": 4,
		"8.2": 855,
		"8.2.18": 1,
		"8.2.20": 9,
		"8.2.24": 16,
		"8.2.26": 106,
		"8.2.28": 62,
		"8.2.29": 380,
		"8.2.30": 243,
		"8.2.7": 38,
		"8.3": 6,
		"8.3.11": 1,
		"8.3.6": 5,
		"8.4": 29,
		"8.4.11": 7,
		"8.4.16": 18,
		"8.4.18": 4
	},
	"python_version": {
		"": 283,
		"3": 3603,
		"3.10": 3,
		"3.10.12": 3,
		"3.11": 855,
		"3.11.2": 853,
		"3.11.4": 1,
		"3.11.7": 1,
		"3.12": 5,
		"3.12.3": 5,
		"3.13": 27,
		"3.13.5": 27,
		"3.5": 1,
		"3.5.2": 1,
		"3.6": 1,
		"3.6.9": 1,
		"3.7": 626,
		"3.7.3": 626,
		"3.8": 3,
		"3.8.10": 3,
		"3.9": 2082,
		"3.9.19": 18,
		"3.9.2": 2062,
		"3.9.21": 1,
		"3.9.6": 1
	},
	"lang": {
		"de_DE": 1,
		"en_US": 43,
		"es_ES": 256,
		"fr_FR": 3584,
		"it_IT": 1,
		"pt_PT": 1
	},
	"total": 3886
}

J’attends vos retours et vos remarques.

Bad

Mips · Mars 30, 2026, 2:01

Salut,

Je vais être très franc et très direct.

Je suis choqué que ceci ait été fait sans communication (edit: c’était dans un changelog) ni la moindre réserve.

Donc je trouve que ca devrait être au minimum un opt-out par défaut et que seulement ceux qui veulent explicitement partager des données puissent le faire.

Comme on dit, « L’enfer est pavé de bonne intention », et le risque zéro n’existe pas.
Qu’importe qu’on puisse démontrer que les données sont protégées et que rien de critique n’est gardé etc, c’est le principe même que je condamne;
Ca reste de l’extraction de données qui ne t’appartient pas donc je reste fermement opposé à ce genre de pratique surtout dans ce contexte de plugin tiers: on n’a aucun contrat entre nous et les utilisateurs, aucune conditions générales pour encadrer cela.
Il n’y a de mon point de vue aucune légitimité à récolter ces informations et honnêtement, on n’en a pas besoin pour savoir ce qu’on doit supporter comme environnement.

Je trouve ce sujet suffisamment important que je souhaiterais avoir la position officielle de Jeedom/Domadoo sur ce genre d’initiative:
Est-ce autorisé d’extraire des données utilisateurs vers un serveur personnel (càd autre que l’infrastructure servant à fournir le service, je pense aux services clouds que certains plugins permettent d’interroger) et si oui, quelles données?

edit: je tiens à préciser que mon ressenti, mon opinion écrite ici, concerne les faits, pas la personne.
Je sais très bien que Bad n’a pas chercher à mal faire ni à nuire.

rennais35000 · Mars 30, 2026, 2:31

C’était pourtant écrit : it’s bad

Bebel27 · Mars 30, 2026, 4:41

Moi aussi, je serais curieux de connaître le point de vue d’un représentant de Jeedom, mais comme il s’agit d’un plugin non officiel, j’ai bien peur que la réponse soit vite expédiée.

@Loic : Salut ! Si tu passes par là , j’aimerais vraiment avoir ton avis sur ce sujet et éventuellement si tu pouvais relayer à la team

Loic · Mars 30, 2026, 4:52

Bonjour

Je remonterais ce point à la team à la prochaine réunion que j’ai avec eux.

Phpvarious · Mars 30, 2026, 8:48

Bonjour,

Pour ma part, je ne suis pas surpris, car j’avais déja connaissance depuis quelque temps que le plugin envoyait des statistiques.
Votre étonnement reste toutefois tout a fait légitime.

Je ne cherche pas ici à juger du caractère bienveillant ou non de cette situation, mais je souhaite tout de même partager ce post :

Je comprend que l’équipe Jeedom ait d’autres priorités et que l’enchaînement de versions majeures ait fortement mobilisé leurs ressources - et les nôtres également.

Je ne voudrais froisser personne, notamment ceux qui travaillent peut-être dans l’ombre sur des éventuelles évolutions ou bugfix du core , mais on ressent tout de même un ralentissement coté développement/amélioration du core, ce n’est pas un reproche, mais signe de la stabilté du core.

Ce community étant riche de développeurs, ne serait-ce pas le bon moment d’envisager la mise en place d’un groupe de travail ? est-ce que l’équipe serait interressé par ce groupe ? a-t-elle déja discuté d’une roadmap pour amélioration/évolution du market ?

Merci.
Bonne soirée a tous.

Loic · Mars 31, 2026, 1:42

Bonjour,
On a abordé le sujet ce matin, je laisserais l’équipe rentrer dans les détails (surtout par peur de dire des betise) mais en gros pour le sujet ici on va demander au dev de mettre une case en opt out.

Ensuite on réfléchis aussi a mettre en place une IA de validation de plugin (mais c’est juste une idée pour le moment). Bien sur en cas d’alerte il y aurait évidement une 2eme validation humaine, l’IA ne prendrait pas la décision toute seul d’exclure un plugin.

Enfin pour le dev effectivement ca ralentie (en vrai non c’est juste qu’on travails beaucoup sur le market, le cloud et d’autre surprise).

En revanche pour la roadmap nous sommes bien sur toujours ouvert aux propositions.

pifou · Mars 31, 2026, 8:18

Bonjour,
Le manque de transparence évidemment est répréhensible… donc oui une coche « opt-out » est le minimum, et bien visible dès l’activation du plugin.

Par contre je trouve ça génial, de l’avoir fait, en tant que développeur on a toujours besoin de ce genre d’infos, de connaitre nos utilisateurs, et là on voit de tout, ça interroge (tient par exemple pourquoi microsoft? oracle? des versions php > 8.4 vraiment ? hey, il y a plus d’espagnols que d’anglais, il faut vraiment qu’on fasse des efforts à l’international! beaucoup de box diy sans surprise, docker aussi, mais kvm?) Je pense que ça apporterait un vrai plus d’avoir ces infos avec une évolution mensuelle, ça donnerait une émulation supplémentaire, surtout lors des passages de version. ça comble un manque pas tant dans le code (je suis sur que Jeedom a ces infos) mais en terme de communication tout simplement.

Mais je rebondis surtout sur le msg de @Phpvarious concernant le ralentissement / stagnation… Moi je m’étais lancé dans l’aventure l’an dernier j’ai ouvert plusieurs PR (et j’en avais d’autres) mais c’est resté lettre morte, ça m’a refroidis. J’ai plutôt l’impression avec le recul qu’on privilégie la stabilité à l’amélioration.

Loic · Avril 1, 2026, 6:09

Bonjour
À ben oui ça on privilégie la stabilité à l amélioration et pas parce que côté jeedom on en a envi (on aime pas trop ça en vrai) mais parce que c’est ce que veulent les utilisateurs. Il n’y a qu’à voir le résultat dès qu’on change le moindre truc sur l’interface….

Michel_F · Avril 1, 2026, 7:21

Ah la communication de Jeedom sur les PR laissés sans réponse ni commentaire gagnerait à s’améliorer, c’est sûr

Loic · Avril 1, 2026, 7:45

Bonjour,
Nous en sommes bien conscient mais nous ne trouvons pas la bonne méthode pour le moment, on a testé d’être très souple et de tout accepter, soucis quand ya un bug on arrive pas le corriger et ca rale et on s’en sort pas.
Par contre etre strict ne marche pas non plus ya plus rien qui avance. Ya surement un juste milieu mais on l’a pas.

Michel_F · Avril 1, 2026, 7:55

Dans les PR, il y a possibilité de mettre un commentaire. Un petit message du genre « PR vue, nous validerons en temps voulu (ça peut durer quelques mois) » suffit et ça prend 32 secondes. Au moins c’est une réaction et il y a des info. Mais ne pas réagir, c’est juste nulle.

Mais tout ça c’est HS, désolé

Loic · Avril 1, 2026, 8:41

Je vais remonter le point dans ma prochaine reunion, je ne gere plus les PR car j’arrive pas a voir ceux qui sont bon ou non et souvent je valide des trucs que je devrais pas donc je ne peux malheureusement pas en faire plus la dessus.

pifou · Avril 1, 2026, 2:07

Ha ça, il y a toujours des gens qui râlent… (et moi le premier, désolé ) La stabilité c’est bien mais la stagnation… moins bien En fait, il faut accepter d’avoir plusieurs branches, plusieurs version (et ne pas forcer les utilisateurs à passer sur la nouvelle version dès qu’elle sort, par exemple)!

Aujourd’hui on est sur la 4.5 et la 4.4 n’est plus même maintenue pour le moindre hotfix de sécurité?

La branche Trixie, c’est très bien aussi, laissez les devs s’amuser dessus, ajouter / enlever du moment que ça reste en lien avec la mise à jour pour Trixie, et lorsque la communauté estime que c’est prêt, stable, vous faites la review d’une mega-PR sur la prochaine release (pas forcément sur la sable en cours donc: stabilité)

Avoir plusieurs branches vous permettrait de déléguer la revue, le test de chaque PR, regrouper les gens par compétence (php / JS Jquery frontend / npm composer CI-CD build…) par fonctionnalités (dashboard, historique, backup restore, install, core autre divers…) et par affinité aussi, faites une branche par feature, on essaye de pousser nos suggestions et tester dessus… avec le risque et je pense qu’on l’acceptera aussi, d’abandonner une branche si c’est parti dans tous les sens et qu’il y a trop de divergence.

Loic · Avril 2, 2026, 12:09

Bonjour,
On aimerait pouvoir maintenir une branche 4.3, 4.4, 4.5 et autre toute en meme temps mais c’est completement impossible avec la taille de l’équipe il faudrait qu’on soit 4 ou 5 fois plus car qui dit plusieurs version du core dit aussi plusieurs version de plugin a maintenir et meme la avec une seule version on galere.

Par contre les branches vont etre revu sur le git pour avoir une branch dev et une branch stable/master pour simplifier les PR.

jpty · Avril 3, 2026, 9:21

Bonjour,

Pour revenir au sujet d’origine, je suis intéressé par les statistiques de mes plugins.
Pour le moment, je me contente du minimum (nombre d’installations visible sur le market).
Des infos comme les langues utilisées, les versions de Jeedom, du php, la beta est-elle utilisée me manquent.

Loic · Avril 3, 2026, 11:02

Bonjour,
Nous réfléchissons comment vous mettre ca a disposition mais pour le moment on bloque sur des questions de sécurité (connaitre l’os en particulier permet de connaitre pas mal de faille et on ne veut pas mettre en danger les utilisateurs).