De retour chez vous en fin de journée, avez-vous déjà découvert dans le miroir que vous aviez de la salade dans les dents ? « Tous ces gens qui l’ont vu et qui ne m’ont rien dit ! » En tant que QA, c’est ce genre de malaise que l’on ressent lorsqu’on trouve un bug et que l’on se rend compte qu’il est déjà en production depuis plusieurs mois. Mais à quel point devons-nous espérer que les internautes lambda remontent des anomalies ? Et si l’on renverse les points de vue, dans quelle mesure peut-on considérer que rapporter un bug est un devoir ?
Premier constat : rapporter des bugs n’amuse personne
(… sauf les QA ?)
En tant qu’internaute, nous poursuivons un but qui nous est propre. Quand nous rencontrons un bug non bloquant, le plus simple est de le contourner. Lorsqu’au contraire on se retrouve dans un cul de sac, avant de prendre la décision de demander de l’aide, on réévalue notre but initial.
- Est-ce que ça peut attendre ? Je réessaierai plus tard.
- Est-ce vraiment indispensable tout de suite ? Je laisse tomber complètement, ou bien je bascule sur un service concurrent.
Résultat : les entreprises reçoivent essentiellement des feedbacks de personnes irrémédiablement bloquées dans leur navigation. Encore faut-il ensuite faire le tri entre les demandes d’assistance (mécompréhension de l’application) et les « vrais » bugs.
En général, il y a donc une grosse perte d’informations. C’est bien sûr dommageable pour l’organisation concernée.
Une question de confiance ?
Au fond, tout le monde pourrait faire le calcul et envisager les gains, pour soi et pour les autres, d’une remontée d’anomalie. Pourquoi n’est-ce pas le cas ?
Outre les problématiques habituelles de manque de temps, peut-être est-ce parce que le chemin paraît incertain et que l’entreprise semble injoignable. Un formulaire de contact trop généraliste ou difficile d’accès suffit certainement à décourager.
A titre d’exemple, Facebook semble dissimuler à dessein son formulaire de remontée d’anomalies, et tout dans le parcours qui suit invite plutôt à changer d’avis.
Premièrement, il faut cliquer sur le bouton « point d’interrogation ». Pour quelle raison ? Vouloir communiquer un problème et se poser une question, ce n’est pas la même chose.
Deuxièmement, il faut cliquer sur l’option « Signaler un problème », précédée d’une icône en forme de point d’exclamation (ah, là c’est plus cohérent !)
Troisièmement, quatre options, assez hétéroclites, se présentent dans une modale. Il faut cliquer sur « Quelque chose ne fonctionne pas ».
Un formulaire de rapport de bug s’ouvre enfin, qui permet de saisir son problème.
Pour finir, un message de remerciement un peu mielleux affiche (ironie du sort !) une liste d’anomalies connues, qu’il eût été bien avisé de positionner avant l’accès au formulaire.
Cette sinueuse suite d’étapes n’incite pas à la remontée d’anomalies, et pourtant Facebook fait partie des sites les plus fréquentés au monde.
Pour favoriser ces usages, il faudrait adapter le design des applications pour éviter des efforts inutiles (ainsi que le travail de dédoublonnage des anomalies en aval), et lui assurer, si la remontée d’anomalie est bel et bien nécessaire :
- que son retour sera traité en un laps de temps donné
- qu’on l’informera du traitement de « son » anomalie le cas échéant.
Éventuellement, une compensation (réelle ou symbolique) pourrait lui être attribuée le cas échéant.
En rendant à la fois familier et attractif le processus de remontée d’anomalies, il serait alors possible d’engager véritablement sa clientèle dans la qualité des services numériques.
La démarche n’en est qu’à ses débuts, même si l’on peut observer ici et là quelques petites trouvailles d’UX (comme l’onglet ci-dessous, discret mais toujours présent sur l’interface web d’AdopteUnMec.com).
Cependant, au moins deux domaines contredisent ce premier constat : la sécurité informatique et le monde du jeu vidéo.
Sécurité informatique : une symbiose plus ou moins organisée
Les échanges entre le public et entreprises peuvent être assez intenses concernant l’aspect de la sécurité logicielle. Il s’agit alors essentiellement de personnes expertes en la matière qui recherchent activement des failles de sécurité. Leurs motivations peuvent être de toutes natures. Elles sont tantôt sociétales, visant à protéger la communauté (dans ce cas, on est clairement dans une optique de devoir citoyen). Elles peuvent également être vénales dans une certaine mesure, si l’on tient compte des politiques de « bugs bounties » mises en place par les grands noms du web ou des opportunités de recrutement occasionnées. Le processus de feedback est parfois structuré de manière à inclure les hackers white-hat dans la chaîne de production logicielle.
Dernièrement, ce fonctionnement a reçu de la part de l’Union Européenne une véritable reconnaissance dans la mesure où cette institution a lancé en 2019 un bug bounty sur quinze des logiciels libres très utilisés (dont VLC, Drupal, Notepad++ et FileZilla).
Les médias évoquent l’initiative avec enthousiasme, scandant avec gourmandise les montants des rémunérations hypothétiques. Rappelons tout de même que cette « chasse au trésor » ne profitera qu’à ceux qui trouveront des anomalies (pour la première fois), et non à ceux qui confirmeront, par l’échec de leurs tentatives d’intrusion, la robustesse des applicatifs. Pourtant, l’une et l’autre de ces issues ont de l’importance. Il y a un décalage paradoxal entre l’urgence des enjeux de sécurité informatique et les moyens déployés, qui reproduisent sans complexe le mécanisme de la machine à sous, où seul l’alignement des trois paires de cerises profitera au joueur assidu.
Early-access : un pacte sous le sceau de la qualité
Tu paies tout ou partie du prix du produit, et tu obtiens en accès anticipé une version inachevée de celui-ci. Dans le monde du biscuit, on aurait droit à des paquets d’Oreo à 50 XPF, pour découvrir peut-être que certains ne contiennent pas de crème vanillée (ou sont même carrément immangeables, carbonisés). Quelques mois plus tard, on recevrait éventuellement un deuxième paquet gratuit, rempli de biscuits parfaits. Ce contrat vous conviendrait-il ?
Les offres d’accès anticipé (ou early-access) sont très variées et comportent toutes un risque : le jeu pourrait très bien s’avérer rempli de bugs et ne jamais être finalisé. Certains jeux passent par des rebondissements des plus burlesques. D’autres sortent au bout de plusieurs années, comme DayZ qui est resté en version alpha de décembre 2013 à décembre 2018. Nombreux sont ceux qui se découragent de voir sortir un jour Star Citizen, en alpha depuis juin 2014.
Le early-access, en résumé, c’est un pacte entre un joueur enthousiasmé par un produit, et une équipe de développement ayant besoin d’alimenter leur trésorerie avant la release finale.
Les retours sur la qualité (et surtout sur les bugs ou glitches) du jeu sont très bienvenus. Voir par exemple les consignes de rapport d’anomalie prodiguées par l’équipe de Sad Square, éditeur du jeu Visage dont le jeu est sorti en accès anticipé en octobre dernier. Le joueur est invité d’abord à vérifier si « son » bug a déjà été rapporté, à trouver un moyen de le reproduire, puis à rédiger le rapport en tant que tel en suivant une trame prédéfinie, comprenant les informations de jeu, les étapes de reproduction, etc. Pour être rigoureux, il n’est pas excessif de penser que le processus entier dure entre 15 minutes voire 30 minutes au minimum.
Sans cette sollicitation de rapports de bugs, on pourrait comparer le modèle du early-access à la vente de billets pour les pool parties du Kuendu Beach, qui sont à 1500 XPF en pré-vente et 2500 XPF sur place. Le produit est le même, mais ceux qui prennent le risque de payer à l’avance (sans savoir par exemple s’il pleuvra des cordes le jour même) sont récompensés par un prix plus avantageux.
Mais force est de constater que le rôle du joueur va plus loin que ça. On peut considérer que les bénéficiaires de l’accès anticipé sont amenés à réaliser un travail de testeur, un travail rémunéré par avance, au forfait, grâce au tarif préférentiel. La frontière entre producteur et consommateur se brouille. La responsabilité de la qualité semble de déplacer du côté de l’utilisateur, et le travail du testeur se cantonner à un forfait bloqué, au-delà duquel il faudra œuvrer bénévolement, pour l’amour de l’art.
Si cette problématique vous intéresse, nous vous conseillons cet article de fond consacré au modèle économique de l’accès anticipé.
Une question de responsabilités ?
Faire participer les utilisateurs à la remontée des anomalies et plus globalement à la démarche qualité d’un produit pose donc un certain nombre de problèmes, et en premier lieu celui de la responsabilité.
Marie-Anne Dujarier, dans son essai Le Travail du consommateur, De Mac Do à eBay : comment nous coproduisons ce que nous achetons, met au jour la manière dont un certain nombre de tâches ont été déléguées aux consommateurs, que ce soit dans le monde physique (peser ses fruits et légumes au supermarché) ou numérique (faire la promotion d’une marque sur les réseaux sociaux). Ce phénomène est une véritable tendance de fond qui s’invite subrepticement dans nos vies. Il structure parfois des processus auxquels on ne peut pas échapper, comme si nous étions une partie d’une chaîne de production minutieusement conçus ; impossible par exemple d’attendre à une table au Mac Donald que l’on prenne notre commande, comme de quitter ladite en laissant les reliefs du repas aux soins d’un inexistant employé de salle. Lorsqu’un client entre dans un fast-food, il accepte tacitement le rôle que l’enseigne lui confère. D’ailleurs, s’il s’assied à une table souillée de soda et de frites, ce n’est pas à la chaîne qu’il s’en prendra dans ses vitupérations, mais bien à l’incivilité de ses semblables.
De la même manière, un produit buggé sera-t-il à terme la faute des utilisateurs réputés négligents, dont on aurait attendu qu’ils préviennent dès que possible les équipes techniques ?
Il faudrait trouver un équilibre entre optimisation de la qualité à l’aide des utilisateurs d’une part et responsabilisation des éditeurs d’autre part. Exercice difficile qui, nous l’espérons, s’illustrera dans les années à venir par des dispositifs innovants.
Pour finir sur une note pragmatique, en tant qu’utilisateur, nous vous proposons de retenir ces derniers points :
- Si vous avez payé pour accéder au produit, vous n’êtes pas tenu de fournir un travail bénévole à son éditeur.
- Si vous n’avez pas payé pour accéder à ce produit mais que son modèle économique repose sur l’exploitation de vos données, vous n’êtes pas non plus tenu de fournir un travail bénévole à son éditeur.
- Toute contribution bénévole à l’amélioration de ce produit est un acte surérogatoire qui vous honore, et non un devoir qui vous incombe.
- Tentez d’obtenir une compensation proportionnelle en tant qu’échange de bons procédés (bon d’achat, réduction, entrée gratuite…)
En parallèle, à nous d’inventer les meilleures façons d’écouter nos utilisateurs, mais aussi et surtout de compenser leurs efforts.
Le crowdtesting comme filet de sécurité
Le crowdtesting, ou test participatif, représente un moyen d’anticiper les problématiques rencontrées en production par les utilisateurs réels. En général, les campagnes de test participatif ont lieu en amont d’une mise en production. On peut voir cette pratique comme un filet de sécurité, en complément des canaux à mettre en place pour permettre à l’ensemble des utilisateurs de remonter les anomalies trouvées.
Le crowdtesting prévoit une rémunération pour les testeurs ; la relation gagnant-gagnant est garantie dès le début. Sur la plateforme Testeum par exemple, la rémunération est identique que l’on trouve des anomalies ou non, ce qui garantit le paiement des testeurs.
Pour continuer d’explorer ce sujet, nous vous suggérons également de consulter l’article « Why I don’t report bugs« , de Cassandra H. L.