Comment tester une idée avant de la construire

Pour tester une idée avant de la construire, listez ce qui doit être vrai pour qu'elle fonctionne, choisissez la croyance à la fois la plus importante et la moins prouvée, et menez le test le moins cher capable de montrer qu'elle est fausse. Décidez à l'avance du résultat qui vaut réussite, menez le test avec de vraies personnes dans des conditions réelles, puis choisissez de poursuivre, de modifier ou d'arrêter. Vous ne testez pas si les gens aiment l'idée. Vous testez si la chose la plus risquée que vous croyez à son sujet tient.

Pourquoi « nous l'avons montrée et les gens ont aimé » n'est pas un test

La validation la plus courante est une présentation suivie d'applaudissements. Les gens sont polis, surtout avec des collègues, et surtout quand l'idée est présentée avec soin. Ce que les gens disent qu'ils feraient et ce qu'ils font réellement sont souvent très éloignés.

Un vrai test a trois caractéristiques. Il cible une hypothèse précise. Il a un seuil de réussite convenu avant que quiconque ne voie les résultats. Et il demande aux gens de faire quelque chose, comme donner du temps, fournir une information, changer une habitude ou s'engager, plutôt que de donner un avis. Si votre test ne peut pas échouer, c'est une démonstration.

Tester une idée : sept étapes

1. Écrire l'idée en une phrase, avec un « qui » et un changement

« Une application mobile pour les étudiants » est une catégorie, pas une idée que l'on peut tester. « Les étudiants de première année qui manquent un cours peuvent le rattraper en 24 heures grâce à un court résumé enregistré par l'enseignant » se teste. Nommez à qui elle s'adresse, ce que ces personnes feront différemment, et ce qui s'améliore pour elles.

2. Lister toutes les hypothèses qui la sous-tendent

Demandez à l'équipe : qu'est-ce qui doit être vrai pour que cela fonctionne ? Poussez pour obtenir au moins quinze croyances. Regroupez-les sous trois questions souvent utilisées en design : les gens la veulent-ils (désirabilité), pouvons-nous la réaliser (faisabilité), et pouvons-nous la pérenniser (viabilité) ? Les équipes listent d'abord les risques de faisabilité, parce qu'il est confortable d'en parler. Les risques qui coulent les idées se trouvent plus souvent du côté de la désirabilité et de la viabilité.

Un premortem, la technique de Gary Klein qui consiste à imaginer que le projet a déjà échoué et à se demander pourquoi, permet de faire émerger rapidement les hypothèses que les gens hésitent à formuler à voix haute.

3. Trouver l'hypothèse la plus risquée

Placez chaque hypothèse sur deux axes : son importance pour l'idée, et le niveau de preuves dont vous disposez déjà. C'est la cartographie des hypothèses, popularisée par David J. Bland. Le coin supérieur gauche, critique et non prouvé, est celui que vous testez en premier. Choisissez-en une, deux au plus. Tout le reste attend.

Une vérification utile : « Si cela se révèle faux, l'idée meurt-elle ou change-t-elle simplement ? » Testez celles qui la tueraient.

4. En faire une hypothèse avec un seuil de réussite

Rédigez-la sous forme de test d'hypothèse selon ce modèle : Nous pensons que [qui] va [faire quoi] parce que [raison]. Nous saurons que c'est vrai si [résultat mesurable] dans un délai de [durée].

Fixez le seuil de réussite avant de mener le test, et écrivez-le. « Au moins 8 des 20 étudiants qui ont manqué un cours ouvrent le résumé dans la journée » est un seuil. « Les étudiants réagissent bien » n'en est pas un. Convenez aussi de ce que vous ferez si le résultat est en deçà ou se situe entre les deux. Les équipes qui sautent ce point trouvent toujours le moyen de lire le résultat comme une bonne nouvelle.

5. Choisir le test le moins cher capable de vous donner tort

Adaptez le test à l'hypothèse, pas à l'outil que vous aimez :

• Les gens le veulent-ils ? Une fausse porte (fake door : proposer le service ou le bouton et compter qui essaie de l'utiliser, puis expliquer honnêtement), une page d'inscription, ou un pré-engagement comme la réservation d'un créneau.
• L'utiliseront-ils comme nous le prévoyons ? Un prototype papier ou un test d'utilisabilité modéré sur une version sommaire.
• La valeur tient-elle en usage réel ? Un test concierge : rendre le service à la main à quelques personnes, ouvertement, avant d'automatiser quoi que ce soit.
• L'expérience fonctionne-t-elle avant que la technologie n'existe ? Un test du magicien d'Oz : l'utilisateur interagit avec ce qui ressemble à un service opérationnel pendant qu'une personne fait le travail en coulisses. Le terme a été forgé par John F. Kelley dans la recherche en interaction homme-machine vers 1980.
• Laquelle de deux versions fonctionne le mieux ? Une expérimentation A/B, une fois que vous avez assez de trafic ou d'utilisateurs pour comparer.

Le coût se mesure en jours, pas en argent. Un bon premier test prend d'un à dix jours. S'il exige une validation budgétaire, vous êtes probablement en train de construire, pas de tester. Pour des idées sur la fabrication du support de test lui-même, voyez le prototype le moins cher que vous puissiez faire cette semaine.

6. Le mener avec de vraies personnes, et observer

Testez avec les personnes auxquelles l'idée s'adresse, pas avec des collègues qui les remplacent. Gardez des conditions aussi proches de la réalité que possible : leur lieu, leur appareil, leur pression temporelle. Observez ce qu'elles font plus que ce qu'elles disent.

Consignez ce que vous voyez dans une grille de recueil des retours : ce qui a marché, ce qui n'a pas marché, les questions soulevées et les nouvelles idées. Notez les surprises immédiatement ; elles s'estompent dès le lendemain.

Si un test implique le public, dites clairement aux gens ce qui est expérimenté et obtenez les validations que votre organisation exige. Tester n'autorise pas à tromper qui que ce soit.

7. Décider : poursuivre, modifier ou arrêter

Comparez le résultat au seuil fixé. Puis prenez à voix haute l'une de ces trois décisions :

• Poursuivre : l'hypothèse a tenu. Passez à la suivante par ordre de risque.
• Modifier : elle a tenu en partie, ou pour un autre public. Ajustez l'idée et testez à nouveau.
• Arrêter : elle n'a pas tenu. Consignez ce que vous avez appris et clôturez. Arrêter une idée après un test de deux semaines est un bon résultat ; l'arrêter après un an de développement ne l'est pas.

Rédigez une note courte : ce que vous avez testé, ce qui s'est passé, ce que vous avez décidé et pourquoi. C'est cette trace qui permet à une équipe d'apprendre d'une idée à l'autre au lieu de repartir de zéro à chaque fois.

Exemple illustratif

Illustratif. Une université australienne voulait développer une application de tutorat entre pairs pour les étudiants de première année d'ingénierie. Le plan initial prévoyait six mois de développement.

L'équipe a listé 22 hypothèses. Sur la cartographie des hypothèses, la plus risquée n'était pas technique. C'était celle-ci : « Les étudiants de deuxième année consacreront une heure par semaine au tutorat des premières années en échange de crédits de cours plutôt que d'une rémunération. » Si elle tombait, l'application n'avait personne à mettre en relation.

Leur hypothèse : « Si nous proposons des crédits de cours, au moins 15 étudiants de deuxième année s'inscriront à un créneau de tutorat en une semaine. » Ils ont placé un simple formulaire d'inscription dans la lettre d'information des deuxièmes années, l'ont géré à la main comme un test concierge, et ont mis en relation tuteurs et étudiants par e-mail.

Neuf se sont inscrits, en dessous du seuil. Mais les échanges qui ont suivi ont été révélateurs : plusieurs ont dit qu'ils feraient du tutorat en binôme, pas seuls, parce qu'ils doutaient de leurs propres connaissances. L'équipe a modifié l'idée en tutorat en binôme, a relancé le formulaire, et a obtenu 21 inscriptions. L'application n'était toujours pas développée. Le test suivant consistait à savoir si les premières années viendraient réellement.

À faire, à éviter

À faire

• Tester une hypothèse à la fois et la nommer dans le plan de test.
• Fixer un seuil de réussite et une règle de décision avant de voir les résultats.
• Préférer les tests où les gens agissent à ceux où ils commentent.
• Garder le premier test sous la barre des deux semaines.
• Considérer « arrêter » comme un résultat utile et consigner pourquoi.

À éviter

• Présenter l'idée et compter les compliments.
• Tester avec des collègues quand l'idée s'adresse à des clients ou à des citoyens.
• Construire un prototype abouti pour tester si quelqu'un en veut.
• Déplacer le seuil de réussite une fois les résultats arrivés.
• Tromper les participants ; une fausse porte doit se conclure par une explication honnête.

Questions fréquentes

Quel est le moyen le plus rapide de valider une idée ? Trouvez l'hypothèse unique qui tuerait l'idée si elle était fausse, puis menez un test qui demande à de vraies personnes d'agir, comme réserver un créneau, s'inscrire ou utiliser une version gérée à la main. Beaucoup de tests de ce type peuvent se mener en une semaine.

Quelle est la différence entre un test concierge et un test du magicien d'Oz ? Dans un test concierge, les gens savent qu'une personne rend le service à la main. Dans un test du magicien d'Oz, le service paraît automatisé à l'utilisateur pendant qu'une personne travaille en coulisses. Le test concierge éprouve la valeur ; le magicien d'Oz éprouve l'expérience d'un futur système.

Combien de personnes faut-il pour tester une idée ? Pour les premiers tests qui cherchent les problèmes d'une expérience, une poignée de participants suffit souvent à faire apparaître les principaux. Pour les tests qui mesurent la demande, fixez d'abord un seuil chiffré, puis touchez assez de personnes pour que ce chiffre ait un sens.

Pour aller plus loin

Commencez par la cartographie des hypothèses et le guide du test d'hypothèse, puis choisissez entre le test concierge et le test du magicien d'Oz selon ce que vous devez apprendre. Si vous êtes encore en train de choisir les idées à tester, lisez comment prioriser des idées, et pour l'ensemble des méthodes, voyez quel outil d'innovation utiliser.