Tester une application mobile avec de vrais utilisateurs

Tout fonctionne, sauf la décision

Vous avez réservé un cours de Pilates, mais votre emploi du temps change. Dans l'application, vous retrouvez votre séance et un créneau jeudi soir. Le bouton pour modifier la réservation est bien là. Pourtant, vous hésitez : l'acompte sera-t-il conservé ? Faut-il annuler avant de réserver à nouveau ?

Ce scénario est fictif, pas un témoignage de client. Il montre une différence qu'un contrôle technique ne suffit pas à révéler. L'application peut déplacer une réservation sans erreur, alors que la personne n'arrive pas à décider si elle doit le faire. Le problème n'est pas forcément une fonction manquante. Il peut s'agir d'une explication qui arrive trop tard.

Demander si l'écran plaît donnera peut-être un « oui » poli. Observer quelqu'un qui essaie de déplacer sa séance permettra de repérer le moment exact où la confiance disparaît. C'est l'intérêt d'un test utilisateur, à intégrer au travail de conception de l'expérience mobile plutôt qu'à remplacer par un questionnaire de satisfaction.

Partez d'une décision à prendre

Avant d'organiser les séances, posez-vous une question simple : qu'allez-vous décider grâce à elles ? « Savoir si l'application est intuitive » ne suffit pas toujours. Une personne peut ne pas trouver sa réservation ; une autre peut la trouver immédiatement et mal comprendre les conditions. Ces deux difficultés n'appellent pas la même réponse.

Dans notre exemple, la question utile serait : peut-on déplacer une réservation déjà payée et expliquer ce qu'il advient de l'acompte ? Elle tient dans un parcours et débouche sur une décision concrète concernant les informations à afficher.

Précisez pour vous-même ce qui constitue une réussite : retrouver la bonne séance, choisir une nouvelle date et comprendre l'état final de la réservation et du paiement. Gardez ces critères dans vos notes. Les annoncer à la personne reviendrait à lui fournir une partie de la réponse.

Il faut aussi accepter ce que la méthode ne dira pas. L'existence d'une demande pour votre projet relève de la validation de l'idée d'application. Les plantages et les erreurs de paiement demandent une vérification technique. Une fonction peut être compréhensible mais défaillante, ou fonctionner tout en restant incompréhensible.

N'attendez pas forcément la fin du développement

Un prototype cliquable peut suffire pour vérifier l'enchaînement des écrans et le sens des libellés. En revanche, il ne reproduit pas forcément le clavier, les notifications ou le retour après une interruption. Choisissez une version capable de répondre à votre question. Le comparatif entre prototype et MVP aide à situer ces deux supports.

Préparez un compte d'essai contenant déjà une réservation plausible. La séance portera ainsi sur le changement de date, pas sur une inscription interminable. Utilisez des données fictives et un environnement de paiement sans risque. Un test ne doit pas annuler une vraie séance ni envoyer un message à un autre client.

Repérez les limites du prototype avant la rencontre. Si un lien n'a pas été construit, ne transformez pas son absence de réaction en problème d'utilisation. À l'inverse, ne présentez pas toutes les intentions du concepteur pour compenser une version inachevée. Vous pouvez déjà vérifier si les textes affichés se comprennent sans explication.

Invitez des personnes qui connaissent la situation

Un collègue retrouve parfois une option parce qu'il se souvient d'une réunion. Un proche peut minimiser une difficulté pour vous encourager. Ce sont de bonnes personnes pour répéter l'organisation de la séance, mais pas nécessairement pour comprendre votre public.

Pour notre application, cherchez quelqu'un qui a récemment réservé une activité et changé un créneau. Demandez comment cela s'est passé, quel téléphone il utilisait et ce qui l'a préoccupé. Une expérience récente renseigne davantage qu'une réponse enthousiaste à « utiliseriez-vous une application de sport ? ».

Les recommandations de Nielsen Norman Group sur le nombre de participants concernent notamment de petites études qualitatives répétées. Cinq personnes bien choisies peuvent constituer un premier groupe utile pour une tâche précise. Ce nombre n'apporte pas une garantie statistique.

Ne confondez pas non plus les rôles. Les élèves, les professeurs et le personnel administratif n'ont pas les mêmes objectifs. Un groupe de cinq personnes réparties entre ces rôles ne représente pas cinq essais pour chacun. Mieux vaut une question limitée et bien éclairée qu'un avis général sur tout le produit.

Donnez une raison d'agir, pas un mode d'emploi

Si vous demandez d'ouvrir « Mes réservations », de toucher « Modifier » et de sélectionner jeudi, vous ne découvrez plus si le chemin est évident. Vous venez de l'enseigner. La personne peut réussir alors qu'elle aurait été perdue seule.

Un scénario donne suffisamment de contexte pour agir sans nommer les commandes à trouver. L'article de NN/G sur les tâches de test explique cette distinction. Voici des exemples originaux adaptés à notre cours de Pilates :

La personne peut choisir de s'arrêter si les conditions ne sont pas claires. C'est parfois le résultat le plus instructif. Dans la vie réelle, elle aurait peut-être appelé le studio. Votre rôle n'est pas de lui faire terminer la tâche à tout prix.

Résistez à l'envie de sauver votre écran

Commencez par préciser que vous évaluez l'application, pas les capacités de la personne. Expliquez ce que vous souhaitez enregistrer et demandez son accord avant de le faire. Sur son propre téléphone, des messages privés peuvent apparaître. Convenez de la façon de les éviter et de l'accès aux enregistrements. Le guide de GOV.UK sur les tests modérés aborde cette préparation.

Puis laissez le temps de réfléchir. Quelques secondes de silence paraissent souvent interminables quand on connaît la réponse. « Regardez en bas » semble une aide anodine, mais change immédiatement la nature du résultat. Vous observez désormais une réussite accompagnée. Si vous devez donner une indication pour continuer, notez-la.

Préférez « qu'attendez-vous à cet endroit ? » ou « que pensez-vous qu'il s'est passé ? ». « Vous avez vu que l'acompte est conservé ? » fournit déjà l'interprétation attendue. Les félicitations après chaque bonne commande peuvent également orienter la personne vers ce qui vous fait plaisir.

Les conseils de modération des chercheurs de GDS sont utiles pour préparer une première rencontre. Lorsqu'on vous demande le sens d'un mot, explorez d'abord ce que la personne imagine. Vous pourrez expliquer ensuite ; vous ne pourrez pas retrouver son interprétation initiale une fois la réponse donnée.

Regardez les contraintes du vrai téléphone

Sur une grande maquette, les éléments ont de la place. Sur le téléphone habituel, le clavier peut cacher la suite, une date longue décaler le texte ou une commande devenir difficile à atteindre d'une main. Le parcours n'a pas changé, mais les conditions, si.

Il n'est pas nécessaire d'inventer une épreuve compliquée. Observez d'abord un usage normal, puis vérifiez les circonstances importantes pour le public. Si les réservations se modifient souvent en déplacement, regardez ce qui reste après une courte interruption. Si certaines personnes utilisent du texte agrandi, activez ce réglage au lieu de présumer que tout s'adaptera.

La langue fait partie de ces conditions. Une séance en anglais ne prouve pas que les libellés français sont clairs. Testez les dates, les textes et les confirmations de la version réellement utilisée. Par ailleurs, une étude générale ne remplace pas des essais ciblés avec des personnes utilisant des technologies d'assistance. Le guide d'accessibilité mobile aide à préparer ce travail.

*Une illustration de la démarche : repérer l'endroit où le parcours s'interrompt avant d'aider à le franchir.*

Écrivez ce que vous avez vu avant d'expliquer pourquoi

« Le bouton est trop petit » ressemble à une conclusion. C'est parfois seulement une hypothèse. Une observation plus précise serait : la personne ouvre deux fois la réservation, lit la ligne du paiement et s'arrête. Interrogée sur ce qu'elle attend, elle explique qu'elle pense perdre l'acompte en changeant la date. Dans ce cas fictif, agrandir le bouton ne résoudrait peut-être rien.

Distinguez le comportement observé, votre explication et la modification envisagée. Vous supposez que les conditions sont présentées trop tard. Vous proposez donc une explication courte avant la confirmation. C'est une piste à vérifier, pas encore une amélioration démontrée.

Consignez séparément les tâches terminées sans aide, terminées avec une indication et abandonnées. Décrivez aussi la conséquence : du temps perdu, un mauvais créneau ou une annulation involontaire possible. Dire que deux personnes sur cinq ont eu besoin d'aide dans cette série est exact. Affirmer que 40 % de tous vos clients échoueront ne l'est pas.

La fréquence ne décide pas de tout. Un seul risque d'annuler la mauvaise réservation peut mériter plus d'attention que plusieurs avis sur une couleur. Les observations rendent votre arbitrage plus solide ; elles ne le remplacent pas.

Vérifiez la correction plutôt que de célébrer la nouvelle maquette

Changer la navigation, les textes et l'ordre des éléments en même temps peut améliorer la séance suivante sans vous apprendre ce qui a compté. Partez de la cause la plus crédible et faites une modification ciblée. Ici, l'information sur l'acompte doit devenir compréhensible au moment de décider.

Si vous étudiez une première utilisation, de nouveaux participants évitent de confondre compréhension et mémoire du chemin. Les personnes précédentes peuvent servir à d'autres questions, à condition de préciser lesquelles. Demandez aussi ce que signifie l'état final : atteindre une confirmation ne garantit pas que l'ancienne réservation a été comprise.

Après le lancement, l'analyse d'usage de l'application peut montrer où les personnes quittent un parcours. L'observation aide à chercher pourquoi, et les tests d'une version bêta élargissent les appareils et situations rencontrés. Ces méthodes se complètent.

Une page suffit pour préparer un premier essai : votre question, le public recherché, quelques tâches, le compte de départ, les notes et la décision suivante. Si vous avez besoin d'une équipe, expliquez l'incertitude à Appfyl ou décrivez-la dans un court brief de projet. « Les clients ne savent pas ce que devient l'acompte » éclaire mieux le travail qu'une simple demande d'écran supplémentaire.

Questions fréquentes