Ce post a été publié sur LinuxFr.org. Vous pouvez le lire là bas, ainsi que les commentaires associés

‘Jour ‘Nal,

J’ai envie de te parler d’un truc pour avoir ton avis mais ce n’est pas un sujet hyper populaire dans les parages, alors je vais commencer par la fin :

Comment t’y prendrais-tu pour collecter des informations sur le comportement des utilisateurs de tes programmes tout en respectant leur anonymat et leur vie privée ?

Et maintenant les détails :)

Pourquoi observer les utilisateurs et quoi regarder

Quand je développe une application, j’ai envie de savoir quelles sont les parties qui intéressent l’utilisateur et quelles sont celles qui ne servent à personne. Il y a plusieurs raisons à cela : favoriser les fonctionnalités qui rapporte le plus, bien sûr (si c’est une application monétisée), ou encore jeter sans remord les parties inutiles (moins de bagages, moins de maintenance). Et il y a bien sûr un aspect tout bête, celui de fournir le meilleur service possible, tout simplement.

Dans le passé avant de lancer un logiciel on faisait une étude de marché. Aujourd’hui on part d’une idée et on essaye plutôt de sortir quelque chose rapidement sans faire trop d’hypothèses, on regarde comment cela se comporte, et on réajuste en continu. Bien sûr pour pouvoir réajuster il faut avoir quelque chose à regarder.

Imaginons quelques indicateurs, comme par exemple un rapport de ventes ou de téléchargements, disons trimestriel. Pas très dynamique et porteur de peu d’information, le logiciel sera mort avant d’avoir le temps de réajuster quoi que ce soit.

Plus précis, il faudrait avoir cette mesure en temps réel, au pire à la journée. Ça donne une idée plus claire de l’attrait du produit. Si on peut aussi avoir un suivi des désinstallations ça permet de sortir un indicateur de satisfaction pour l’utilisateur. À supposer qu’il ait effectivement lancé le logiciel avant de le supprimer.

Pour lever le doute il faut une mesure des lancements du programme. Si on peut savoir quand l’utilisateur lance l’application, on peut mesurer ce que l’on appelle une « rétention ». En pratique c’est un pourcentage des utilisateurs qui lancent encore le programme N jours après l’installation. Avec cela on commence à voir apparaître une indication crédible de l’intérêt du logiciel. Si on peut en plus avoir la durée de la session, c’est encore mieux.

Mais ce n’est pas tout.

Au fur et à mesure qu’on apprend des choses en regardant ces mesures, on a envie d’en savoir plus. Que fait l’utilisateur dans le programme, où clique-t-il, où va-t-il, où dépense-t-il, que fait-t-il avant de fermer ou de désinstaller…

Le problème de l’identification d’un utilisateur

En réalité on ne s’intéresse pas vraiment à l’individu qui utilise l’application mais plus à des notions vagues comme les tendances des gens en général.

Cependant on voit bien que plus on va vouloir des mesures précises plus on va regarder dans le détail des comportements et donc plus on va être intrusif. Cela est complètement indépendant de ce qui est optimisé au final, publicité ciblée, qualité de service. Quand bien même le projet serait d’améliorer le confort des transports en commun, de fluidifier passage à la caisse au supermarché ou de réduire les trajets en voiture, dans tous les cas on gagne à connaître les tendances des gens en général.

Les tendances.

En général.

Le problème étant que pour pouvoir observer une utilisation du produit il faut pouvoir associer les actions à un utilisateur. Pas un individu. Un utilisateur. Cela peut se faire en les groupant par adresse IP comme cela se fait depuis la nuit des temps pour compter les visites sur un site web. On peut aussi stocker un token sur le client et le récupérer à chaque accès. Pour ceux qui suppriment régulièrement les cookies on peut carrément utiliser des techniques d’empreinte digitale d’appareil.

Au final il est relativement facile d’isoler un individu dans une foule, même si on ne le souhaite pas.

De l’utilité de mesurer

J’ai cité plus haut l’idée de supprimer des parties inutiles d’une application. J’ai récemment été face à ce cas où j’avais du mal à trouver une place pour un bouton dans mon app tout en ayant à maintenir une partie que je soupçonnais être sans intérêt pour le joueur. Cette partie consommait justement un emplacement de bouton. C’est parce que j’ai pu constater dans les métriques que quasiment personne n’utilisait cette partie du logiciel que j’ai pu la supprimer et par là-même récupérer de la place pour mon bouton.

Sur le site que tu es en train de regarder actuellement il y a une page de statistiques avec notamment une page générée par Webalizer qui scanne les logs serveur pour compter les visites par adresse IP. Cela permet d’avoir une idée du trafic sur le site et de suivre son évolution d’une année à l’autre.

Du côté de Debian on trouve la Popularity Contest dont le but est de suivre l’état d’installation des paquets.

Mozilla a un projet Telemetry qu’ils utilisent pour améliorer Firefox.

Ce sont des exemples parmi d’autres.

Anonyme mais identifiable

La documentation de Debian Popularity Contest contient une note de sécurité concernant l’anonymat, que je recopie ci-dessous :

it’s impossible to make a submission completely anonymous, since Internet servers tend to add headers and log messages along the way. Our receiver program at debian throws away this information as soon as possible so no one will see it, but if you’re really paranoid you might not want to participate.

et je traduirais ça par

c’est impossible de rendre une soumission complètement anonyme puisque les serveurs sur Internet ont tendance à ajouter des informations d’en-tête et des messages de journalisation pendant le transfert. Notre programme recevant les données chez debian supprime ces informations dès que possible pour que personne ne puisse les voir mais si vous êtes vraiment paranoïaque vous voudrez ne pas participer.

J’aime bien cette précision qui implique qu’il est juste impossible de passer sans laisser de trace. Finalement le seul moyen d’être totalement anonyme est de ne pas participer.

De son côté, Mozilla précise que les données envoyées via Telemetry sont non-personnelles. Ce qui ne signifie aucunement qu’elles ne peuvent permettre d’identifier indirectement un utilisateur.

Combiner mesures et respect de l’utilisateur

Au final j’ai l’impression qu’il n’y a pas de solution pour avoir à la fois des mesures sur l’utilisation de l’application et un respect total de l’anonymat de l’utilisateur. Éventuellement il y a le compromis de l’opt-in qui a l’inconvénient que tellement peu de personnes l’activent que les mesures en deviennent difficiles à lire.

Comment t’y prends-tu toi pour savoir ce que font les utilisateurs de tes programmes, pour savoir quelles sont les fonctionnalités utiles et quelles sont celles à jeter ? Où mets-tu le curseur entre le respect total de la vie privée et la granularité des mesures ?