Combien de recherche utilisateur faut-il avant de construire un logiciel ?

Commencer par les décisions

Il n’existe pas de nombre universel d’entretiens qui rende un logiciel sûr à construire. Cinq échanges peuvent révéler un motif fort dans un public étroit, tandis que vingt n’aboutissent à rien si les participants ne sont pas pertinents. La bonne question n’est pas « Combien de personnes interroger ? » mais « Quelle décision cette recherche doit-elle permettre ? »

Listez les décisions susceptibles de changer le projet. Le problème est-il fréquent ? Le public est-il accessible ? La solution actuelle coûte-t-elle du temps ou de l’argent ? Les utilisateurs changeraient-ils de comportement et qui paierait ? Une application convient-elle mieux à la situation qu’un site ou un service ? La recherche suffit pour l’étape suivante lorsque ces incertitudes sont réduites à un niveau acceptable.

Écrivez les hypothèses avant les entretiens. Sinon l’équipe risque de confirmer ses croyances tout en pensant apprendre. Classez chaque hypothèse comme connue, incertaine ou risquée. Concentrez-vous sur celles qui pourraient rendre le produit inutile, difficile à vendre ou impossible à réaliser.

Recruter les personnes concernées

La pertinence des participants est déterminante. Interrogez des personnes qui correspondent au contexte et ont vécu récemment le comportement. L’intérêt général pour la technologie ne suffit pas. Une personne peut aimer l’idée sans connaître le problème ni décider de l’achat.

Demandez de raconter un événement récent. Que s’est-il passé ? Qu’a-t-elle fait ensuite ? Quels outils, documents ou interlocuteurs ont été nécessaires ? Où a-t-elle perdu du temps, de l’argent ou de la confiance ? Comment la situation a-t-elle été résolue ? Les histoires concrètes révèlent mieux les priorités que les prédictions.

Incluez les rôles différents si le produit en comporte plusieurs. Client, administrateur et décideur ne voient pas le même parcours. Ne mélangez pas trop vite leurs besoins. Repérez les objectifs communs et les différences de contenus, permissions et assistance.

Poser des questions sur le comportement

Évitez « Utiliseriez-vous une application qui envoie des rappels ? » Ce type de question invite à un accord poli et pousse les personnes à concevoir la solution à votre place. Demandez plutôt ce que la personne fait aujourd’hui, la fréquence du problème, ce qui a été tenté et ce qui arrive sans solution. Creusez les détails au lieu de passer trop vite à la question suivante.

Recherchez les signes de priorité. Un tableur créé, une solution payante, un changement de fournisseur ou un processus manuel montrent un effort. Une personne qui trouve le problème intéressant sans rien faire ressent peut-être une urgence faible. Les deux réponses sont utiles si elles sont interprétées correctement.

Présentez une solution seulement après avoir compris la situation actuelle. Faites essayer un prototype et observez les attentes. Ne mesurez pas seulement l’appréciation : vérifiez si la tâche est réalisable, si le bénéfice est compréhensible et ce qui empêcherait l’usage.

Repérer motifs et différences

Notez chaque échange avec la même structure : contexte, problème, contournement, fréquence, conséquence, résultat attendu et force de preuve. Séparez les paroles exactes de votre interprétation. Vous distinguerez ainsi un motif d’un commentaire mémorable.

Un motif ne signifie pas que tous les participants emploient les mêmes mots. Ils peuvent partager un déclencheur, un contournement ou une conséquence tout en employant des mots différents. Les différences comptent aussi. Un problème peut être urgent pour un segment et secondaire pour un autre. Une fonction peut aider le client tout en ajoutant du travail interne. Segmentez les résultats au lieu d’imposer un utilisateur moyen unique.

Utilisez une synthèse simple. Marquez les hypothèses confirmées, contredites et ouvertes. L’objectif n’est pas de produire un document élégant, mais de rendre la prochaine décision visible pour toute l’équipe et d’éviter que l’opinion la plus bruyante devienne la feuille de route.

Fixer une règle d’arrêt

Définissez avant la prochaine série ce qui suffit pour continuer. Il peut s’agir d’un problème répété dans un segment, d’un contournement clair, d’un acheteur crédible et d’un test réussi du comportement central. Le seuil dépend du risque : un prototype bon marché demande moins de certitude qu’un processus réglementé ou un grand projet d’intégration.

Observez les rendements décroissants. Si plusieurs conversations pertinentes donnent le même déclencheur et le même besoin, de nouveaux entretiens apporteront peut-être seulement des détails. Passez alors au prototype, au pilote ou au test de prix. Si chaque échange révèle un problème différent, le public ou la question est peut-être trop large.

Arrêter ne signifie pas que tout est résolu. Notez les risques restants et décidez comment les traiter par le design, un pilote ou des mesures après lancement. La recherche doit mener à une prochaine étape responsable, pas à une prétention de certitude.

Transformer les preuves en plan

Résumez la recherche sous forme de décisions : premier public, problème, comportement, preuves, risques et prochain test. Retirez les fonctions apparues seulement parce que quelqu’un les a mentionnées, sauf si elles servent le résultat prouvé. Définissez des critères d’acceptation observables pour que l’équipe sache si la première version fonctionne.

Prévoyez l’apprentissage après lancement. Les statistiques peuvent montrer activation, réussite, erreurs et retour. Les échanges avec l’assistance peuvent révéler la confusion et les contenus manquants. Un pilote teste la charge et les intégrations. Les apprentissages avant et après lancement se complètent sans justifier un report permanent.

La recherche est suffisante lorsque l’équipe comprend le problème, peut choisir un public initial étroit et possède des preuves pour la suite. Le but est d’avancer avec discernement, pas d’obtenir une certitude parfaite.

Sources

• User interviews · Nielsen Norman Group
• Events · Google Analytics

Questions fréquentes

Combien d’entretiens faut-il ?

Il faut assez d’échanges pour voir des motifs répétés auprès de personnes pertinentes et réduire les incertitudes qui pourraient changer la décision. Le nombre dépend de la taille du public, de la variation du problème et du risque du projet.

Faut-il montrer mon idée d’application pendant un entretien ?

Comprenez d’abord le problème actuel sans solution. Utilisez ensuite un prototype pour tester compréhension et comportement, pas seulement appréciation.

Que faire si toutes les réponses sont différentes ?

Vérifiez si le public est trop large, si la question est floue ou si le problème n’est pas partagé. Segmentez les résultats avant de conclure que la recherche a échoué.

La recherche peut-elle retarder le développement ?

Oui. Fixez une règle d’arrêt et passez à l’expérience la moins coûteuse capable de répondre à la prochaine question. Recherche et construction doivent former un cycle d’apprentissage plutôt que des phases séparées sans fin.