Réponse en bref
Avant de construire un produit complet, écrivez les hypothèses dont il dépend et retenez celle qui ferait le plus de dégâts si elle était fausse et qui repose sur le moins de preuves. Transformez-la en une affirmation qui peut échouer, choisissez le plus petit prototype capable de la réfuter, croquis papier, maquette cliquable ou service assuré à la main, et fixez les critères de réussite et d’échec avant le test. Agissez ensuite selon le résultat : arrêter, tester à nouveau ou construire.
Une plateforme est un empilement de paris avec un écran de connexion
Le plan d’une nouvelle plateforme se lit comme une liste de faits : les clients en ont besoin, ils quitteront ce qu’ils utilisent aujourd’hui, les données peuvent être obtenues, le partenaire s’intégrera, le prix couvre le coût. Aucun n’est encore un fait. Chacun est une hypothèse, et le produit ne fonctionne que si presque toutes se vérifient.
Construire le produit complet est une façon de le savoir. C’est aussi la plus lente et la plus chère, car elle teste toutes les hypothèses au même moment et ne livre la réponse qu’une fois le budget dépensé. Kara Pernice, du Nielsen Norman Group, faisait la comparaison en 2016 : jeter du code coûte cher ; jeter un prototype, surtout s’il est en papier, non.
Des outils plus rapides n’y changent rien. Dans un article de mars 2026 pour le même cabinet, Sara Paul observe que les plateformes low-code et les assistants d’IA ont accéléré la construction, mais que ce qui rend un produit risqué est ce qu’il en coûte de se tromper, non ce qu’il en coûte de le construire. Un mauvais produit bâti en une semaine reste le mauvais produit.
Listez ce qui doit être vrai, puis classez par dégâts
Commencez par écrire les hypothèses, une par ligne. Une bonne amorce est « pour que cela marche, il faut qu’il soit vrai que… ». Répartissez-les grossièrement en quatre familles : les gens le veulent, les gens peuvent l’utiliser, nous pouvons le construire et le faire tourner, et il se finance dans le cadre des règles applicables.
Donnez ensuite deux notes à chaque ligne : la gravité si l’hypothèse est fausse, et la quantité de preuves que vous détenez déjà. Le GOV.UK Service Manual fait de l’identification et du test des hypothèses les plus risquées une part cruciale de sa phase alpha, et ajoute que leur nature dépend du service. Paul propose une règle pratique : le risque est souvent inversement proportionnel aux preuves existantes.
Le manuel donne deux exemples. Une équipe qui veut réduire la solitude grâce à un service d’information en ligne devrait d’abord apprendre comment les personnes concernées reçoivent l’information aujourd’hui, car si elles n’utilisent pas internet, elles ont peu de chances d’utiliser le service. Et l’équipe de Register to vote a vu que tout reposait sur une interface avec les systèmes d’inscription de plus de 400 collectivités locales ; sa phase alpha s’est donc concentrée là-dessus.
Transformez l’hypothèse dangereuse en une phrase qui peut échouer
Une hypothèse devient testable quand elle dit qui, quoi et comment vous le saurez. Le Nielsen Norman Group propose un modèle pour la première question, celle de savoir si quelqu’un accorde de la valeur à l’offre : nous pensons que telle proposition a de la valeur pour tel public, et nous saurons que c’est vrai quand nous observerons un comportement précis pendant le test.
Voici une illustration aux détails inventés. Une chaîne de boulangeries envisage une plateforme de précommande. L’hypothèse dangereuse est que les clients réguliers commanderont la veille au soir au lieu de passer en boutique. Sous forme testable : nous pensons que la précommande a de la valeur pour les habitués de la semaine, et nous le saurons quand au moins un tiers de ceux que nous invitons passeront une deuxième commande en deux semaines sans relance. La proportion illustre un critère ; ce n’est pas une référence.
Écrivez, avant tout test, à quoi ressemblera chaque issue. L’article de NN/g en distingue trois : hypothèse confirmée, partiellement confirmée, non confirmée. Les fixer à l’avance compte davantage que les chiffres exacts, car après coup presque n’importe quel résultat peut être présenté comme un succès par celui qui est déjà tombé amoureux de l’idée.
Choisissez le plus petit test capable de vous donner tort
La forme du prototype découle de la nature du doute. Si la question est de savoir si les gens comprennent l’offre et la veulent, NN/g cite trois formats courants : des croquis sur papier, une maquette cliquable et la méthode du Magicien d’Oz, dans laquelle le produit paraît automatisé alors qu’une personne fait le travail en coulisses. La boulangerie pourrait prendre des précommandes avec un simple formulaire et les honorer à la main pendant deux semaines.
Si le doute est technique, le plus petit test est un fragment étroit de vraie ingénierie : une connexion au système extérieur dont tout dépend, comme pour Register to vote, ou un essai pour savoir si les données sont assez bonnes. Si le doute est juridique ou contractuel, le test peut être une conversation : le Service Manual suggère de consacrer une partie de la phase alpha à mesurer s’il est faisable de lever une contrainte législative.
Dans tous les cas, le conseil du manuel est le même : inutile de prototyper tout le parcours ; concentrez-vous sur les zones que vous jugez les plus difficiles et faites le minimum nécessaire pour tester les hypothèses les plus risquées. Le cadre de prototypage de Nesta l’illustre avec une chaise : dans la première phase, on teste les matériaux, la longueur des pieds et l’angle de l’assise, pas la chaise terminée.
Brut exprès : le degré de finition qu’il faut à un prototype
Un prototype doit être aussi brut que la question le permet. Pernice énumère ce qu’apporte la basse fidélité : moins de temps de préparation et davantage pour la conception, des changements possibles entre deux séances, des participants plus libres de critiquer un objet visiblement inachevé, des concepteurs moins attachés à leur travail et des décideurs qui voient que ce n’est pas prêt à sortir.
La rusticité a toutefois un plancher. Si les gens n’arrivent pas à comprendre comment s’en servir, prévient Paul, le test devient un test de l’interface et non de l’idée. L’offre doit être assez claire pour qu’un refus signifie « je n’en veux pas » et non « je n’ai pas compris ». Un contenu réel, des prix réels et une formulation vraisemblable comptent plus que les couleurs.
Quelle que soit sa forme, traitez le prototype comme jetable. Le Service Manual demande aux équipes de construire des choses juste assez complexes pour tester des idées, pas du code de qualité production, et de s’attendre à jeter le code, ainsi que beaucoup d’idées, à la fin de la phase alpha. Un prototype peaufiné pendant un mois se jette difficilement, raison de plus pour le garder brut.
La preuve, c’est ce que les gens font, pas ce qu’ils disent aimer
Un test de prototype produit trois sortes de signaux, qui n’ont pas la même valeur. Le compliment est le plus faible : on est aimable avec celui qui montre une idée. Une intention déclarée, « je m’en servirais », vaut un peu mieux. Le comportement est le plus fort : la personne accomplit la tâche sans aide, revient une seconde fois, verse un acompte ou confie les données dont le service a besoin.
Ce classement n’a rien d’excentrique. Le modèle de NN/g réclame un signal comportemental dans sa seconde moitié, et le cadre de Nesta recommande d’observer les personnes qui utilisent les prototypes en plus de les interroger, parce que ce qu’elles disent, pensent ou feront diffère souvent de leur façon réelle d’agir. Organisez le test de sorte qu’il y ait quelque chose à faire, et pas seulement quelque chose à regarder.
Soyez aussi strict sur le choix des participants. Les collègues, les amis et les admirateurs existants ne sont pas le public nommé dans l’hypothèse. Quelques séances avec les bonnes personnes peuvent montrer si l’idée est comprise et désirée ; elles ne vous diront pas la taille du marché, et elles ne doivent pas être présentées comme si elles le faisaient.
Arrêter, recommencer ou construire : écrivez la règle avant les résultats
Le but de l’exercice est une décision. Pour le Service Manual, la phase alpha est terminée quand le prototype est assez solide pour vous aider à décider de poursuivre ou non. Pour continuer, l’équipe doit être convaincue qu’elle peut créer quelque chose qui réponde aux besoins des utilisateurs avec un bon rapport coût-efficacité, et que le budget et les personnes existent. Dans le cas contraire, dit le manuel, elle peut s’arrêter complètement ou refaire une phase antérieure.
Nesta décrit la même bifurcation avec trois issues : assez d’enseignements pour rédiger le plan final ; des lacunes qui appellent un nouveau tour avec une spécification révisée ; ou tant de choses à repenser que l’équipe revient à la preuve de concept. Un résultat non confirmé n’est pas automatiquement la fin. NN/g conseille de se demander d’abord si c’est l’opportunité qui a échoué ou seulement cette manière de l’aborder : le mauvais public, le mauvais canal, une conception confuse.
Fixez une limite de temps en plus des critères. Les phases alpha de l’administration, selon le manuel, durent en général de six à huit semaines ; une petite entreprise qui veut tester une hypothèse avec un prototype devrait avoir besoin de bien moins, et la limite doit être écrite avant de commencer. Un prototype sans échéance devient discrètement le produit, sans qu’aucune décision ait été prise.
Ce qu’un test réussi ne prouve toujours pas
Un prototype répond à la question pour laquelle il a été construit et à aucune autre. Il peut montrer que les gens comprennent une offre et la veulent. Il ne peut pas montrer qu’ils continueront à s’en servir, que le service tient la charge ou que le modèle économique tient à grande échelle. Nesta est explicite : le prototypage ne remplace pas le pilote ; il vient avant et produit une meilleure spécification pour celui-ci.
L’étape suivante, dans la séquence de NN/g, est une petite version réelle mise entre les mains de vrais utilisateurs, qui permet de mesurer l’engagement, la rétention et la conversion. L’article énumère des garde-fous pour ce stade : limiter l’exposition à un segment ou à des utilisateurs invités, montrer aux gens ce que fera le produit avant de leur demander d’agir, le présenter comme une bêta ou un pilote et le surveiller en temps réel.
Deux précautions s’imposent ici. Un test dans lequel une personne fait discrètement le travail de la machine doit rester honnête sur ce qu’il advient des données et de l’argent des gens. Et un prototype qui a réussi doit être reconstruit, non promu : les raccourcis qui l’ont rendu bon marché sont la raison pour laquelle il n’est pas sûr d’y adosser une activité.
Checklist pratique
- Écrivez chaque hypothèse dont dépend le produit en une phrase simple commençant par « il faut qu’il soit vrai que ».
- Notez chacune selon les dégâts si elle est fausse et selon les preuves détenues, puis retenez la ligne la plus mal notée sur les deux plans.
- Réécrivez-la comme une hypothèse qui nomme le public, le comportement attendu et le résultat qui vaudrait échec.
- Construisez le prototype le plus brut capable de provoquer ce comportement et essayez-le avec des personnes du public visé.
- Convenez par écrit de la limite de temps et de la règle arrêter, recommencer ou construire avant la première séance.
Questions et réponses
Qu’est-ce que l’hypothèse la plus risquée d’une idée de produit ?
C’est la conviction dont dépend tout le plan, celle qui repose sur le moins de preuves et qui causerait le plus de dégâts si elle se révélait fausse. Elle peut porter sur la demande, la facilité d’usage, la technologie, le coût ou le droit. Le GOV.UK Service Manual note qu’elle varie d’un service à l’autre ; il faut donc l’identifier délibérément plutôt que la copier sur le projet d’un autre.
Quelle différence entre un prototype et un produit minimum viable ?
L’usage des termes varie, d’où l’intérêt de préciser ce que vous entendez. Le Nielsen Norman Group considère le MVP comme une expérience qui peut prendre la forme d’un prototype, en papier, en maquette cliquable ou en service opéré à la main, ou celle d’un code réel mis à la disposition de vrais utilisateurs. Les prototypes conviennent à la question de savoir si les gens accordent de la valeur à l’offre. Le code réel convient à la question suivante : une solution précise attire-t-elle et retient-elle ses utilisateurs ?
Combien de temps doit durer le test d’une hypothèse avec un prototype ?
Il n’existe pas de durée fixe, mais il faut une limite fixe. Le Service Manual indique que les phases alpha de l’administration durent en général de six à huit semaines, et Nesta décrit le prototypage comme un processus peu coûteux, aux délais courts à moyens par rapport à un pilote. Une petite entreprise qui vérifie une seule hypothèse peut le plus souvent fixer une période bien plus courte. L’essentiel est de convenir de la limite avant le début du travail.
Que faire lorsque le test du prototype échoue ?
Cherchez d’abord ce qui a échoué. NN/g déconseille d’abandonner une idée sur un seul résultat non confirmé et suggère d’examiner la conception, l’approche technique et des facteurs extérieurs, comme le fait d’avoir touché le mauvais public. Si les bonnes personnes ont compris l’offre et n’en ont tout de même pas voulu, s’arrêter est une issue légitime et peu coûteuse. Le Service Manual cite l’arrêt complet parmi les façons acceptables de terminer une phase alpha.
Peut-on réutiliser le code du prototype dans le produit final ?
Prévoyez que non. Le Service Manual demande de construire des prototypes juste assez complexes pour tester des idées, pas du code de qualité production, et de s’attendre à jeter le code à la fin de la phase alpha. Un prototype laisse volontairement de côté la sécurité, la gestion des erreurs et le travail de performance, et le porter en production emporte ces lacunes avec lui. Gardez ce qui a été appris, le contenu et les choix de conception, puis reconstruisez correctement.