Valider une idée d'application avec un prototype, pas à pas
Un prototype d'application montre, avant toute ligne de code, si une idée fonctionne auprès de vrais utilisateurs : types, méthode de test et critères.
Équipe rabbitclipPublié: 7 min de lecture
En bref
Valider une idée d'application avec un prototype, c'est transformer les écrans et le parcours en maquette cliquable avant d'écrire la moindre ligne de code, puis la présenter à de vrais utilisateurs. Le but n'est pas d'obtenir une jolie maquette, mais de répondre à une seule question : cette personne voudrait-elle accomplir cette tâche avec cette application, et en est-elle capable ? Un prototype se prépare en quelques jours, quelques entretiens montrent si l'idée tient, et une hypothèse fausse apparaît avant le début du développement, donc au moindre coût.
La validation est souvent sautée, parce que l'auteur d'une idée a le sentiment de connaître déjà la réponse. Or l'approbation de sa propre équipe ou de ses proches n'est pas une preuve. Imaginez une application de prise de rendez-vous : le parcours est évident pour son propriétaire, mais un client qui le découvre peut buter dès le deuxième écran. L'apprendre après le développement coûte des mois d'efforts et de budget. L'apprendre grâce à un prototype coûte un après-midi.
Quelle différence entre un prototype et un MVP ?
Un prototype est un modèle qui ne fonctionne pas, mais qui donne l'impression de fonctionner. Les écrans sont reliés, les boutons mènent à l'écran suivant, mais il n'y a derrière ni vrai serveur, ni base de données, ni système de paiement. Son but est de tester une hypothèse, et il est conçu pour être jeté.
Un MVP, en revanche, est un vrai produit, simplement plus petit. De vrais utilisateurs saisissent de vraies données, le système tourne réellement et il peut arriver sur les stores. L'ordre habituel est le suivant : d'abord le prototype, puis le MVP si nécessaire. Une idée rejetée au stade du prototype n'entraîne jamais le coût d'un MVP, et une idée qui passe l'épreuve précise aussi le périmètre du MVP.
Quel prototype répond à quelle question ?
Il n'existe pas un seul type de prototype ; le choix dépend de la question à laquelle vous voulez répondre. Écrivez d'abord la question, puis choisissez l'outil le moins cher capable d'y répondre.
Si vous vérifiez que le problème lui-même est réel, une esquisse sur papier et un entretien suffisent. Si vous vérifiez que le parcours est compris, il vous faut des écrans cliquables réalisés dans un outil de design. Si vous vérifiez qu'une chose est techniquement possible, vous écrivez un petit morceau de code qui ne couvre que la partie risquée.
- Esquisse sur papier ou dessinée : le problème et le parcours de base sont-ils justes ? Testable en quelques heures
- Maquette d'écrans cliquable : le parcours et les textes sont-ils compris ? Essayée sur un vrai téléphone
- Service géré manuellement : une personne fait le travail en coulisses pendant que l'utilisateur voit une application automatique ; on mesure ainsi si la demande est réelle
- Test technique ciblé : on vérifie seulement si l'intégration ou la fonction la plus risquée fonctionne
Qui doit tester le prototype, et comment ?
Les testeurs doivent appartenir à la cible visée. Amis et famille sont en général bienveillants et cachent leur vraie réaction. Un petit groupe de cinq à huit personnes suffit souvent pour voir les mêmes problèmes commencer à se répéter ; plus que le nombre, ce qui compte, c'est que ces personnes fassent réellement partie du public visé.
Pendant l'entretien, n'expliquez pas l'application. Donnez à l'utilisateur une tâche, par exemple « Prenez un rendez-vous pour demain », puis taisez-vous et observez. L'endroit où il hésite, ce qu'il comprend de travers et le bouton qu'il cherche sont les vraies lacunes de votre produit.
Enregistrez l'entretien ou prenez des notes, mais consignez ce qui s'est passé sans y ajouter d'interprétation. Si un utilisateur dit « c'est joli », ne le considérez pas comme précieux. Les phrases qui décrivent un comportement, comme « je m'en servirais chaque semaine » ou « voici comment je fais aujourd'hui », sont les vraies données.
Qu'est-ce qui montre que l'idée a fonctionné ?
Écrivez les critères de réussite avant le test, pas après. Sinon, n'importe quel résultat peut être lu comme un bon résultat. Les critères sont : l'utilisateur a-t-il terminé la tâche sans aide, quel problème a-t-il nommé en la décrivant, et serait-il prêt à franchir une étape suivante, comme s'inscrire sur une liste d'attente ou passer une précommande.
Fixez aussi le seuil à l'avance. Si vous attendez que la plupart des personnes à qui l'on confie la tâche terminent le parcours sans aide, notez-le. Le seuil vous appartient, mais il doit être arrêté avant le début du test.
- L'utilisateur a-t-il terminé la tâche sans demander d'aide ?
- Plusieurs personnes sont-elles restées bloquées au même endroit ?
- Comment l'utilisateur résout-il ce problème aujourd'hui, et en est-il satisfait ?
- Serait-il prêt à une étape concrète comme une liste d'attente, une préinscription ou une précommande ?
Quelles erreurs fréquentes lors d'une validation par prototype ?
L'erreur la plus courante est de trop peaufiner le prototype. Un modèle dont chaque pixel est terminé pousse les utilisateurs à parler d'esthétique plutôt que du parcours, et comme l'on a investi des efforts, l'équipe se met sur la défensive face aux critiques. Un prototype doit être assez bon pour tester une hypothèse, et pas davantage.
La deuxième erreur consiste à poser des questions orientées. La réponse à « Aimez-vous cette fonction ? » est presque toujours oui. La troisième est d'attribuer les retours négatifs à des utilisateurs qui auraient mal compris ; si trois personnes butent au même endroit, le problème est dans l'écran, pas chez les gens.
- Peaufiner trop le prototype et transformer le résultat en débat sur l'apparence
- Poser des questions orientées qui appellent un oui
- Tester uniquement avec des proches et prendre leur gentillesse pour une preuve
- Fixer les critères de réussite après le test
Quand un prototype est-il inutile ou mal choisi ?
Si le problème que vous résolvez se situe dans un domaine bien connu, avec des produits similaires et un parcours établi, un long cycle de prototypage peut être inutile. Passer directement à un petit MVP et à des données d'usage réelles est alors plus instructif. Un prototype a de la valeur quand l'incertitude est forte, et il fait perdre du temps quand elle est faible.
Un prototype est aussi le mauvais outil pour tester un comportement lié au matériel, comme la qualité de l'appareil photo, les capteurs ou le bon fonctionnement hors ligne. Ces risques n'apparaissent que dans un petit essai technique. Déterminez si votre doute porte sur le marché et les comportements ou sur la technique ; un seul outil ne sert pas les deux.
Un prototype n'est pas un obstacle pour l'idée, c'est un service rendu à son auteur : il attrape à moindre coût une hypothèse fausse et renforce une hypothèse juste. Écrivez la question unique à laquelle il faut répondre, construisez le prototype le moins cher capable d'y répondre, testez-le avec quelques personnes de la cible et fixez les critères au préalable. Si vous souhaitez réfléchir ensemble à la manière de tester votre idée, vous pouvez convenir d'un entretien de découverte avec rabbitclip.
Questions fréquentes
Combien de temps faut-il pour réaliser un prototype ?
Cela dépend du périmètre de l'idée et du type choisi. Une esquisse sur papier prend quelques heures, une maquette d'écrans cliquable le plus souvent quelques jours. Plus vous intégrez d'éléments, plus c'est long ; ne prototypez donc que le parcours principal que vous devez tester.
Puis-je réaliser un prototype sans savoir coder ?
Oui. Les esquisses sur papier et les maquettes cliquables dans les outils de design ne demandent aucun code, pas plus qu'un service géré manuellement. Le code n'est nécessaire que pour tester la faisabilité technique.
Avec combien de personnes tester le prototype ?
Cinq à huit personnes de la cible suffisent souvent pour voir les mêmes problèmes commencer à se répéter. Plus que le nombre, ce qui compte, c'est qu'elles appartiennent vraiment au public visé ; l'avis des amis et de la famille n'est pas une mesure fiable.
Quelle est l'étape suivante si le prototype convainc ?
Vous prenez le parcours principal qui a tenu et vous définissez autour de lui un petit MVP. Vous ne construisez réellement que ce parcours, puis vous le mesurez avec de vrais utilisateurs. Les décisions sur les textes et le parcours apprises grâce au prototype passent directement dans le développement.
