Comment tester une idée technologique avec les personnes qui en ont besoin

Un groupe de jeunes développeurs talentueux a un jour passé six mois à construire une application pour aider les commerçantes du marché à suivre leurs ventes. Elle avait des graphiques, des rapports, des tableaux de bord aux couleurs codées et une connexion protégée par un mot de passe très sécurisé.

Quand ils l'ont enfin montrée aux commerçantes, les réactions ont été polies mais claires : « Où est-ce que je clique ? » « Pourquoi j'ai besoin d'un mot de passe ? Mon téléphone est toujours avec moi. » « Je n'ai pas de données pour l'utiliser tous les jours. » « Est-ce qu'elle parle fon ? » « Ma fille le fera pour moi… peut-être. »

L'application était bien construite. Elle n'avait simplement pas été construite avec les personnes qui en avaient besoin.

Comment les innovateurs peuvent-ils tester tôt leurs idées technologiques avec de vrais utilisateurs — avant de passer des mois à construire la mauvaise chose ?

Pourquoi tester avec les utilisateurs est important

Les technologies échouent pour de nombreuses raisons. L'une des plus courantes est de construire quelque chose que les gens ne veulent pas ou ne peuvent pas utiliser. Les recherches de CB Insights sur l'échec des start-up ont montré à plusieurs reprises que l'« absence de besoin sur le marché » figure parmi les principales raisons pour lesquelles les entreprises échouent.

En Afrique, l'écart entre les concepteurs et les utilisateurs peut être particulièrement grand. Les développeurs vivent souvent en ville, parlent couramment l'anglais ou le français, ont un internet rapide et des téléphones récents. Beaucoup d'utilisateurs vivent dans d'autres conditions : zones rurales, langues locales, téléphones basiques, données chères. Ce qui paraît « facile » à un développeur peut être déroutant pour un utilisateur.

La solution : impliquer les utilisateurs dès le début. On parle de conception centrée sur l'humain (ou conception centrée sur l'utilisateur).

Étape 1 : comprendre avant de construire

Avant de construire quoi que ce soit, passez du temps avec les personnes que vous voulez aider. Observez-les. Interrogez-les sur leur vie.

De bonnes questions (inspirées de « The Mom Test » de Rob Fitzpatrick) :

• « Racontez-moi la dernière fois que vous avez [eu ce problème]. »
• « Qu'avez-vous fait ? »
• « Qu'est-ce qui a été le plus difficile ? »
• « Combien cela vous a-t-il coûté en temps ou en argent ? »
• « Qu'avez-vous déjà essayé ? »

Évitez les questions du type « Utiliseriez-vous une application qui fait X ? ». Les gens sont polis ; ils diront oui. Interrogez-les sur ce qu'ils ont réellement fait, pas sur ce qu'ils pourraient faire.

Pause humour : si vous demandez à votre tante si elle utiliserait votre application, elle dira : « Oui, mon enfant, c'est merveilleux. » Si vous lui demandez ce qu'elle a fait hier pour suivre ses ventes, elle vous montrera un cahier, une calculatrice et un sac plastique très bien organisé. Voilà votre vraie concurrence.

Étape 2 : aller là où sont les utilisateurs

Ne testez pas seulement dans votre bureau. Allez :

• Sur les marchés, dans les boutiques et les ateliers.
• Dans les exploitations agricoles et les coopératives.
• Dans les écoles et les centres de santé.
• Chez les gens (avec leur autorisation).
• Dans les gares routières et les pôles de transport.

Observer les gens dans leur environnement réel révèle des choses qu'ils ne mentionneraient pas : le bruit, le soleil sur les écrans, les mains occupées, les téléphones partagés, le mauvais réseau, les interruptions.

C'est particulièrement important dans les contextes de faible connectivité — voir Comment concevoir une technologie utile en contexte de faible connectivité.

Étape 3 : commencer sur papier

Avant de coder, dessinez votre application sur papier. Dessinez chaque écran sur une carte. Montrez aux utilisateurs l'« écran d'accueil » et demandez-leur de toucher (du doigt) l'endroit où ils iraient pour accomplir une tâche. Changez de carte pour montrer l'écran suivant.

Les prototypes papier sont :

• Bon marché (du papier et des stylos).
• Rapides (on peut changer un écran en quelques secondes).
• Honnêtes (les utilisateurs critiquent plus librement du papier qu'une application léchée).

Les designers de nombreuses entreprises technologiques mondiales utilisent le prototypage papier. Ça fonctionne aussi bien à Cotonou qu'en Californie.

Étape 4 : donner des tâches, puis se taire

Pendant un test, donnez une tâche à l'utilisateur : « Enregistrez une vente de 3 000 francs. » Puis observez. N'aidez pas. N'expliquez pas. Ne défendez pas votre conception.

Demandez-lui de « penser à voix haute » : dire ce qu'il pense au fur et à mesure. « Je cherche… peut-être ce bouton ? Non… »

Notez :

• Où il hésite.
• Où il se trompe.
• Quels mots le déroutent.
• Ce qu'il dit aimer ou ne pas aimer.

C'est pénible de regarder quelqu'un se débattre avec votre conception. Cette gêne est précieuse.

« Soyez attentif à ce que font les utilisateurs, pas à ce qu'ils disent. » — Jakob Nielsen, expert en utilisabilité

Étape 5 : tester l'expérience dans son ensemble

La technologie ne se limite pas à l'écran. Testez :

• L'inscription : comment les utilisateurs s'inscrivent-ils ? Ont-ils besoin d'une adresse e-mail (beaucoup n'en utilisent pas) ?
• Le paiement : peuvent-ils payer facilement par mobile money ?
• Les données : combien de données l'application consomme-t-elle ?
• La langue : les utilisateurs comprennent-ils les mots ?
• L'assistance : si quelque chose ne va pas, qui appellent-ils ?
• La confiance : se sentent-ils en sécurité pour saisir des informations personnelles ?

Parfois, le plus grand obstacle n'est pas l'application — c'est la confiance. Voir Comment les petites marques africaines gagnent la confiance.

Étape 6 : utiliser un test « magicien d'Oz »

Avant de construire une technologie complexe, simulez-la. Dans un test « magicien d'Oz » (Wizard of Oz), les utilisateurs interagissent avec ce qui semble être un système automatisé — mais c'est un humain qui fait le travail en coulisses.

Exemple : vous voulez construire un chatbot d'IA qui répond aux questions des agriculteurs. Au lieu de construire l'IA, créez un numéro WhatsApp. Les agriculteurs envoient leurs questions ; un agronome y répond manuellement. Vous apprenez ce que demandent les agriculteurs, comment ils formulent leurs questions, à quelle heure ils écrivent et quelles réponses les aident. Ensuite, vous décidez s'il faut automatiser (et comment).

Cela évite des mois de construction inutile. Cela rejoint notre Guide pratique pour tester une idée d'entreprise.

Étape 7 : mesurer le comportement réel

Une fois qu'une première version est en ligne, observez ce que font les gens :

• Combien de personnes s'inscrivent ?
• Combien accomplissent la tâche principale ?
• Combien reviennent au bout d'une semaine ?
• Où s'arrêtent-elles ?

Le comportement dit la vérité. Si 1 000 personnes téléchargent votre application mais que seulement 20 l'utilisent encore au bout d'une semaine, quelque chose ne va pas — peu importe combien de gens ont dit l'adorer.

Étape 8 : inclure les personnes souvent laissées de côté

Testez avec un groupe diversifié :

• Des femmes et des hommes.
• Des personnes plus âgées et plus jeunes.
• Des personnes moins à l'aise avec la lecture.
• Des personnes en situation de handicap.
• Des utilisateurs ruraux et urbains.
• Des locuteurs de différentes langues.

Si vous ne testez qu'avec vos amis de l'université, vous construirez une application pour vos amis de l'université. Voir Ce dont les filles ont besoin pour se sentir à leur place en cours de technologie pour comprendre pourquoi la diversité des points de vue compte dès le départ.

Éthique : respecter vos testeurs

• Demandez leur consentement et expliquez l'objectif.
• Protégez les données personnelles.
• Rémunérez ou remerciez les participants pour leur temps (crédit téléphonique, petit cadeau, repas).
• Ne faites pas de promesses que vous ne pouvez pas tenir (« Ça va vous rendre riche ! »).
• Partagez les résultats avec eux quand c'est possible.

Les utilisateurs ne sont pas des « sujets de test ». Ce sont des partenaires dans la construction de quelque chose d'utile.

De vrais exemples

• Le premier projet pilote de M-Pesa au Kenya a révélé que les utilisateurs voulaient surtout envoyer de l'argent à leur famille — et pas seulement rembourser des microcrédits, comme prévu à l'origine. L'équipe s'est adaptée, et la suite appartient à l'histoire.
• Ushahidi a commencé comme un outil créé rapidement par des technologues kényans pendant une crise, façonné par la manière dont les gens signalaient réellement les événements par SMS et sur le web.
• Beaucoup d'applications de santé africaines ont été repensées après que des tests de terrain ont montré que les agents de santé avaient besoin d'un accès hors ligne, de formulaires plus simples et de langues locales.

Ces exemples montrent qu'écouter les utilisateurs n'est pas une perte de temps. C'est le chemin le plus court vers quelque chose qui fonctionne.

Les erreurs qui ruinent les tests utilisateurs

• Ne tester qu'avec des amis. Ils vous connaissent et veulent être gentils.
• Les questions orientées. « Ce bouton est facile à trouver, non ? » pousse les utilisateurs à dire oui.
• Trop expliquer. Si vous devez l'expliquer, c'est que la conception n'est pas encore claire.
• Tester au mauvais endroit. Un bureau calme cache le bruit et les interruptions de la vie réelle.
• Ignorer les « petites » plaintes. Si trois personnes hésitent sur le même écran, ce n'est pas un petit problème.
• Tester trop tard. Après six mois de code, changer de direction est douloureux et coûteux.

Transformer les retours en décisions

Après chaque série de tests, réunissez votre équipe et classez les constats en trois groupes :

• À corriger impérativement : les problèmes qui empêchent les utilisateurs d'accomplir les tâches clés.
• À corriger : les problèmes qui ralentissent ou déroutent les utilisateurs.
• Souhaitable : les suggestions et idées pour plus tard.

Corrigez d'abord les éléments « à corriger impérativement », puis testez de nouveau avec de nouveaux utilisateurs. Recommencez. À chaque série, votre produit se rapproche de ce dont les gens ont vraiment besoin. Pour une démarche similaire dans le monde de l'entreprise, voir Pourquoi les retours clients comptent plus qu'un logo.

Un plan simple de tests utilisateurs pour votre prochaine idée

Semaine 1 : interrogez 10 utilisateurs potentiels sur leur comportement actuel. Semaine 2 : dessinez des prototypes papier et testez-les avec 5 utilisateurs. Semaine 3 : améliorez-les et construisez un prototype cliquable (avec des outils comme Figma) ou une version « magicien d'Oz » basée sur WhatsApp. Semaine 4 : testez avec 5 à 10 nouveaux utilisateurs dans leur environnement réel. Semaine 5 : décidez de ce qu'il faut construire — et de ce qu'il ne faut pas construire.

Construire avec, pas pour

Le plus grand changement d'état d'esprit dans la conception technologique est simple : arrêtez de construire pour les gens. Commencez à construire avec eux.

Les commerçantes de notre histoire d'ouverture n'étaient pas le problème. Elles étaient la solution — si seulement les développeurs leur avaient demandé plus tôt.

Poursuivez votre lecture : Du robot de classe à une solution locale, Les questions à se poser avant d'utiliser l'IA à l'école, et notre rubrique Technologie & Innovation.

Questions fréquentes

Combien d'utilisateurs faut-il pour tester une application ?

Tester avec environ cinq utilisateurs par série peut révéler la plupart des problèmes d'utilisabilité majeurs. Faites plusieurs séries avec des utilisateurs différents.

Qu'est-ce qu'un prototype papier ?

Une version dessinée à la main des écrans d'une application, sur papier, utilisée pour tester des idées à moindre coût avant de coder.

Qu'est-ce qu'un test « magicien d'Oz » ?

Un test dans lequel les utilisateurs interagissent avec ce qui ressemble à un service automatisé, alors que ce sont des humains qui accomplissent le travail en coulisses, afin de comprendre ce dont les utilisateurs ont besoin.