Obtenir un maximum de feedback utilisateur sans bavardage.

Léo DRIAT

31 janv. 2021

Télémétrie : mesure des données d’utilisation d’une application pour l’améliorer un maximum, sans même avoir à bavarder avec ses utilisateurs.

Besoin de feedback

Savez-vous ce qu’est l’amélioration continue ?

Il s’agit d’un état d’esprit visant à tirer des leçons du passé. Autrement dit, apprendre de ces erreurs et s’auto-améliorer.

Par exemple, si vous avez complètement foiré un exercice de l’examen de M. Marron, vous saurez que vous allez devoir apporter plus d’attention sur cette partie-là lors de vos futures révisions.

De même, si vous avez complètement foiré un projet de développement parce que vous avez choisi le mauvais framework, la prochaine fois, vous saurez qu’il faudra passer plus de temps en phase de veille, et que tous les frameworks ne sont pas adaptés à toutes les situations.

C’est un comportement essentiel pour progresser un maximum. Après tout, c’est en tombant qu’on apprend à faire du ski.

C’est pour ça que les nouvelles méthodes agiles telles que Scrum mettent énormément en avant cet état d’esprit, afin de pousser tout le monde à réfléchir sur ce qui aurait pu être fait de mieux dans le projet.

Car si l’on veut que notre produit corresponde au mieux aux besoins des utilisateurs, on a plutôt intérêt à corriger nos erreurs le plus rapidement possible.

Mais pour cela, encore faut-il avoir le retour d’expérience (feedback) de la part des utilisateurs.

Quand M. Marron nous rend notre copie avec un gros zéro pointé, et qu’on se prend une fessée par nos parents, le feedback est plutôt clair.

Mais quand il s’agit d’une application, c’est difficile d’avoir un feedback honnête de la part des utilisateurs, surtout lorsqu’ils sont des milliers, voire des millions. On est complètement aveugle de la manière dont ils utilisent l’outil.

Si ça se trouve, vos utilisateurs se perdent constamment dans la jungle qu’est votre menu principal, mais vous n’en avez aucune idée.

Pire encore, l’application peut se mettre à planter chez certains, alors que dans vos tests, tout était bon (hum… hum… jeux vidéo… hum… hum…).

Sans feedback, pas d’amélioration, et vous vous retrouvez avec un produit qui est peut-être bon, mais qui pourrait l’être encore plus.

Ce sont des milliers, voire millions d’euros qui vous passent sous le nez, tout ça par manque d’information.

Je pense particulièrement au monde des startups où la correspondance au marché cible est primordiale pour assurer la réussite de l’entreprise. Sans feedback, pas moyen d’ajuster son application au marché, et l’entreprise se fait écraser par la concurrence et ferme la boutique, c’est aussi simple que ça.

Alors, comment s’en sortir ?

Piochage de données

Facile, il n’y a qu’à demander l’avis des utilisateurs, ils vont nous le dire s’il y a des choses qui ne vont pas.

C’est la solution de niveau zéro que l’on voit très régulièrement.

Par exemple : les méthodes agiles recommandent de faire des réunions avec les clients régulièrement pour leur demander leur avis.

Autre exemple : beaucoup d’entreprises envoient directement des sondages dans les boites mail de leurs utilisateurs.

Mais cette pratique est bien moins fiable qu’elle en a l’air. Si elle n’est pas compensée avec autre chose, le feedback qu’elle vous apportera est plutôt médiocre.

Quoi !? Pourquoi ? Le but c’est d’avoir son avis, non ?

Oui, mais en procédant uniquement de la sorte, on est complètement soumis à la capacité de jugement de la personne à qui l’on s’adresse, et l’être humain est trop biaisé pour emmètre des jugements de qualité à tous les coups.

Je vais généraliser, mais voici quelques exemples basés sur mon expérience :

Ils peuvent se laisser emporter par leurs émotions du moment, leur résistance au changement, ou encore leur manque d’implication.
Ils sont très mauvais pour détecter les vrais problèmes (ergonomie, latence…), mais très bons pour détecter ceux qui n’en sont pas (mauvaise utilisation, mot de passe oublié…).
Ils ne savent pas expliquer un problème correctement. On a le droit à des explications partielles, des exemples manquants et des étapes à reproduire oubliées…

Et je ne parle même pas de la difficulté pour ne serait-ce qu’obtenir un feedback. Ce n’est pas pour rien que beaucoup d’entreprises insistent LOURDEMENT pour que vous leur laissiez un avis, quitte à marchander en vous offrant des réductions ou des bonus.

La racine de tous ces problèmes vient du fait qu’un avis utilisateur n’est qu’un ressenti.

Entre ce qu’il ressent et ce qu’il fait, il y a un gouffre gigantesque. Pourtant, ce sont surtout les faits qui nous intéressent.

Au final, le meilleur moyen d’obtenir du feedback, c’est encore de regarder l’utilisateur utiliser l’application.

On le verrait galérer sur un menu, revenir instinctivement en arrière après avoir rencontré une erreur 404, cliquer sur le bouton « effacer » au lieu de « envoyer »… Des choses qu’il n’aurait même pas pensé à dire si on lui avait demandé.

Mais c’est absurde, on ne va pas enregistrer l’écran de nos utilisateurs non plus.

Non, mais on peut faire encore mieux grâce à la télémétrie.

Il s’agit d’une pratique visant à récupérer des données qui vont vous permettre de savoir si les gens utilisent votre application de manière optimale ou non, et ce automatiquement et en toute transparence.

Chaque utilisateur y contribue, donc vous allez avoir du feedback en grande quantité, mais surtout, honnête et insoumis à tous les biais énumérés ci-dessus.

C’est la manière la plus efficace d’obtenir un retour d’expérience. C’est comme si M. Marron corrigeait votre copie avec vous, en vous expliquant vos erreurs au fur et à mesure.

Et ce feedback pourra vous permettre de vous améliorer continuellement. Par exemple :

Déceler les problèmes les plus tordus : bugs ultra-contextuels, designs bancals, problèmes de performances…
Définir des priorités : parmi toutes les améliorations que vous avez prévues, lesquelles se font le plus attendre ?
Identifier en profondeur le besoin de l’utilisateur : et rendre l’application encore plus irrésistible pour lui.
Tester des hypothèses : pour prendre des décisions, une pratique absolument impossible sans feedback (par exemple : des tests A/B).

Ainsi, la télémétrie vous donne les clefs pour faire un produit qui apporte encore plus de valeur aux utilisateurs sans même les importuner. M. Marron n’aurait pas rêvé mieux !

Oula, attends un peu. C’est légal au moins ?

Tout à fait. Néanmoins, il y a quelques mesures à prendre pour éviter toute embrouille juridique.

Déjà, il faut avoir des conditions d’utilisation et une politique de confidentialité qui supportent cela, même quand il s’agit de données anonymes.

Ensuite, une bonne pratique est de donner le choix aux utilisateurs d’activer ou non la télémétrie.

Vous vous privez d’une partie du feedback, mais au moins, vous montrez patte blanche et vous évitez tout problème juridique (à condition de ne pas mentir, bien entendu…).

Car même anonymes, certains utilisateurs particulièrement suspicieux pourront vous reprocher de récupérer leurs données, peu importe les fins.

Bien sûr, tout ça n’est nécessaire que si vous avez des utilisateurs externes.

Si vous travaillez sur une application interne ou que vous faites une prestation de service, expliquez simplement à votre client que ces données permettront d’améliorer l’outil dans LEUR intérêt, et ils vous les donneront à cœur joie (normalement).

Ouais, mais bon… Case à cocher ou non, ça reste quand même limite de l’espionnage.

Beaucoup de personnes trouvent cette pratique discutable, logique quand on voit la manière dont certaines entreprises (qu’on ne citera que par l’acronyme GAFAM) l’ont utilisé pour faire du beurre sur notre dos.

Néanmoins, la télémétrie en elle-même n’est pas bonne ou mauvaise, ce n’est qu’un outil. Comme un marteau, certains l’utiliseront pour construire des choses, et d’autres pour braquer une supérette.

La majorité des entreprises, et même des projets open source, l’utilisent uniquement dans un objectif d’amélioration continue, avec des données anonymisées, intraçables, et temporaires.

Donc, ne jetons pas le bébé avec l’eau du bain, surtout quand il peut être bénéfique à tout le monde, créateur comme utilisateur.

Comment ça marche ?

D’accord, d’accord, excuse-moi. Et ça marche comment du coup ?

C’est assez simple : quand le client fait une action bien précise, le logiciel récupère des données et les envois à un serveur (backend), qui ne sert en général qu’à faire de la télémétrie.

Le client peut être l’ordinateur d’un utilisateur (application de bureau, page web…), ou bien un autre serveur (API REST…).

Le processus technique compte souvent 6 étapes :

Instrumentalisation : ajouter des lignes de code pour récupérer les données du client.
Traitements côté client : ce n’est pas nécessaire, mais parfois, on souhaite modifier légèrement les données avant de les envoyer au backend.
Exportation : l’envoi des données vers le backend. Pour cela, on utilise un protocole de communication (HTTP ou autre) pour assurer la transition entre les deux bouts.
Traitements côté serveur : ce n’est pas nécessaire, mais parfois, on souhaite modifier les données avant de les stocker dans notre base.
Stockage : mise en base de données afin de les réexploiter plus tard.
Présentation : visualisation des données pour mieux les analyser.

En général, on attache d’autres informations en plus des données que l’on souhaite, telles que l’heure de l’envoi ou l’OS du client, afin de nous aider dans notre analyse.

Mais bien que ce processus soit assez intuitif, il semble assez fastidieux, car il faut beaucoup de technologies pour le supporter (framework d’envoi, base de données, backend…).

Heureusement, la télémétrie a le vent en poupe puisqu’il existe de plus en plus de solutions permettant de prendre en charge toutes les étapes de ce processus. Vous n’avez plus qu’à raccorder les morceaux.

Je citerais notamment OpenTelemetry, la référence ultime pour la récupération et l’exportation de données. En plus, c’est open source et 100 % gratuit !

Et pour les backends, il y en a une tonne, et la plupart sont compatibles avec OpenTelemetry, donc vous n’avez qu’à choisir votre camp 😈

Pour n’en citer que quelques-uns (dans l’espoir qu’ils m’envoient un chèque 😆) :

Construire un plan de télémétrie bien huilé

OK, juste let's go en fait !

Hop hop hop, pas si vite ! Même si la télémétrie est bien plus accessible qu’à l’époque, ça ne veut pas dire qu’il faut y aller comme à la moisson et récupérer n’importe quoi.

Cette pratique à un cout non négligeable. Réceptionner et stocker des données, ce n’est pas gratuit !

On ne fait pas de la télémétrie pour le plaisir de faire des statistiques, mais pour améliorer une application. C’est le retour sur investissement de ces améliorations qui rentabilisera l’agent investi.

Ainsi, il faut avoir un plan de qualité pour avoir un maximum de résultat en un minimum d’investissement.

Je ne peux que vous conseiller l’approche de Vardhan Dugar dans son excellent article Telemetry in Software, que je vous invite plus que fortement à aller lire si le sujet vous intéresse.

Cette stratégie se déroule en 6 étapes :

Spécification

Il s’agit de répondre aux questions clefs concernant le but et le déroulement du plan de télémétrie. J’en ai choisi 6 (j’aime bien ce nombre) :

Quel objectif souhaitez-vous atteindre ? Dépister des problèmes ? Améliorer l’expérience utilisateur ? Déterminer les fonctionnalités clefs pour la version 2 ? Confirmer une hypothèse ? Il faut que vous soyez clair et net avec cette question, car un plan de télémétrie doit toujours vous emmener quelque part.
De quelles données avez-vous besoin pour accomplir cet objectif ? Vous ne devez récupérer QUE le nécessaire. Si votre objectif est de vous assurer que votre application fonctionne bien sous Linux, pas besoin de tester l’ergonomie du menu des paramètres.
Quelles assomptions essayez-vous d’atteindre avec ces données ? Clarifier la corrélation entre l’objectif et les données en question (si X alors Y).
Que faire si l’hypothèse est validée ? Dans l’idéal, chaque plan de télémétrie doit être rattaché à un plan d’action.
Quand est-ce que les données peuvent être retirées ? Stocker des données coute cher. Plus vite on s’en débarrasse, mieux c’est.
Comment la métrique va être calculée ? Cette question est pertinente lorsque les données récupérées ne valident pas directement l’hypothèse et doivent être retravaillées (modifiées, filtrées, mises en relation…).

Prenez le temps de répondre à ces 6 questions sur un document et bloquez-le. Ce sera votre bible qui guidera et donnera du sens à toutes vos actions (et celles de votre équipe) durant ce plan de télémétrie.

Attention cependant à ne pas tout mélanger. Un seul objectif par plan de télémétrie, sinon, ça va être un véritable enfer pour tout organiser.

Il vaut mieux en faire plusieurs à la suite que tout faire d’un coup.

Exemple ultra-simplifié de spécification.

Instrumentalisation

Identifiez les fonctions qui contiennent les données que vous recherchez, et modifiez le code pour récupérer ces données.

Cette étape se fait relativement facilement avec des frameworks tels qu’OpenTelemetry. Le plus dur, c’est encore de trouver les bons emplacements et d’être exhaustif pour ne rien oublier. Référez-vous bien à votre spécification.

Pensez aussi à noter ces emplacements, car ça facilitera le travail quand votre plan de télémétrie sera terminé et qu’il faudra faire machine arrière.

using(var activity = ActivitySource.StartActivity("AfterResponse"))
{        
    activity?.SetTag("UserAgent", Request.Headers["User-Agent"].ToString());
    activity?.SetTag("StatusCode", Response.StatusCode);
}

Exemple d'instrumentalisation en C# avec OpenTelemetry.

Transmission et stockage

Tout le processus du moment où les données sont extraites, jusqu’à ce qu’elles soient bien au chaud dans la base de données.

Le plus dur est de bien réfléchir aux différentes pièces du puzzle : type de base de données, méthodes de traitement des données, protocole de communication… Et une fois ça fait, il ne reste plus qu’à tout raccorder avec un framework tel qu’OpenTelemetry.

Il n’y a pas de solution type. Tout dépend vraiment des moyens que vous avez à disposition, et de ce qui est optimal dans votre cas.

Voici un exemple :

Traitements

Rendre les données exploitables pour l’analyse. On retrouve principalement 3 manières de traiter les données :

Avant transmission : directement sur le client. Parfait pour les traitements isolés, qui ne nécessitent pas de mise en relation avec d’autres données. Attention cependant de ne pas en abuser, car c’est un risque de dégrader les performances de l’application.
Avant stockage : au moment où les données arrivent sur le backend. Parfait pour sélectionner, filtrer et agréger les données pour ne garder que le nécessaire.
Avant présentation : c’est-à-dire au moment de les afficher sur l’interface d’analyse. Parfait pour mettre vos données en relation les unes avec les autres pour pouvoir faire de beaux graphiques.

Visualisation

Rendre les données présentables afin qu’elles puissent être analysées et interprétées par les décisionnaires. Typiquement, en construisant un magnifique tableau de bord avec moult graphiques.

Beaucoup de backends de télémétrie prennent cela en charge automatiquement (interface & graphiques), donc rien à coder, juste de l’organisation visuelle.

Analyse et actions

Grâce à toutes les données que vous avez sous la main, répondez à l’hypothèse émise au départ et prenez les mesures nécessaires pour améliorer l’application, tout ça en vous basant sur votre spécification.

Une fois ces améliorations apportées, la dernière étape est de supprimer les données et le code d’instrumentation pour repartir sur une application blanche comme neige.

Et c’est ainsi que vous concluez officiellement votre plan de télémétrie.

Et voilà comment mener un plan de télémétrie de A à Z. Encore une fois, allez lire l’article original qui apporte encore plus de détails croustillants sur cette démarche.

Voilà pour la télémétrie, une pratique que beaucoup ne connaissent que de nom, sans avoir essayé de chercher plus loin.

Et pourtant, je vous invite plus que fortement à vous y intéresser, et pourquoi pas essayer ! Car à une époque où les développeurs passent leur temps à s’énerver sur la stupidité des clients, et les clients sur la fainéantise des développeurs, un peu de feedback, ça ne fait pas de mal !

Merci d’avoir lu cet article jusqu’au bout, en espérant qu’il vous aura fait lever ne serait-ce qu’un sourcil 😊Si c’est le cas, partagez-le autour de vous et n’hésitez pas à soumettre (subtilement) l’idée à vos collègues/supérieurs.

Pour plus d’efficacité, suivez-moi aussi sur Twitter @ITExpertFr, car c’est là où je poste mes meilleurs conseils et trouvailles au quotidien.

Et pour ceux qu’ils veulent optimiser la qualité de leurs développements au peigne fin, j’ai d’autres articles pour vous :

Quant à moi, je vous laisse, j’ai deux/trois autres guides ultimes sur le feu.

Je vous donne rendez-vous la semaine prochaine pour un nouvel article sur le blog des développeurs ultra-efficaces. Tchao !