De l’idée au prototype : concept, preuve de concept et MVP expliqués

Pour passer de l’idée au prototype, vérifiez d’abord que le problème est réel, puis construisez la chose la moins chère qui réponde à votre question ouverte la plus risquée. Un concept répond à « que construisons-nous, et pour qui ? », un prototype cliquable à « les gens savent-ils s’en servir ? », une preuve de concept à « peut-on le construire ? » et un MVP à « les gens vont-ils l’utiliser et payer pour ? ». Avec des entretiens clients la première semaine, un prototype cliquable testé avec cinq utilisateurs et, si besoin, un spike technique, une idée bien délimitée se teste en deux à quatre semaines, pas en plusieurs mois.

#Concept, prototype, preuve de concept, MVP : à quelle question chacun répond

Ces termes sont employés indifféremment dans les pitch decks et les devis, et c’est ainsi que des fondateurs finissent par payer pour la mauvaise chose. Chacun répond à une question, pour un public différent, avec une durée de vie différente.

Eric Ries a défini le produit minimum viable comme la version d’un nouveau produit qui permet à une équipe de recueillir le maximum d’apprentissage validé sur ses clients avec le minimum d’effort. Le prototype et la preuve de concept viennent avant et coûtent encore moins. Pour la suite, notre guide pour construire un MVP qui fonctionne encore au neuvième mois détaille les fondations.

#Validez le problème avant de concevoir quoi que ce soit

Le prototype le plus cher est un beau prototype pour un problème que personne ne subit assez pour changer ses habitudes.

Des entretiens clients qui ne vous induisent pas en erreur

The Mom Test, de Rob Fitzpatrick, est l’ouvrage de référence, fondé sur un constat : les gens sont polis avec votre idée. Ses trois règles : parlez de leur vie plutôt que de votre idée, interrogez-les sur des situations précises du passé plutôt que sur des généralités ou des opinions sur l’avenir, et parlez moins pour écouter davantage.

• « Quand cela vous est-il arrivé pour la dernière fois ? Racontez-moi comment ça s’est passé. »
• « Qu’avez-vous fait, et combien cela vous a-t-il coûté en temps ou en argent ? »
• « Qu’avez-vous déjà essayé, et pourquoi avez-vous arrêté ? »
• « Qui d’autre intervient quand ça se passe mal ? »

Évitez « Est-ce que vous utiliseriez… ? » et « Combien paieriez-vous pour… ? ». Les réponses à des questions hypothétiques sont des opinions sur l’avenir. Le signal honnête se trouve dans ce que les gens font déjà : contournements, tableurs, argent déjà dépensé, et leur accord pour une étape suivante concrète, comme un deuxième rendez-vous, une mise en relation avec un collègue ou un pilote.

Smoke tests : mesurer l’intention, pas les compliments

Un smoke test montre la promesse avant que le produit n’existe et mesure ce que font les gens. Les formes courantes sont une landing page avec un seul appel à l’action (liste d’attente, demande de démo, précommande), un bouton « fake door » dans un produit existant et un test concierge, où vous livrez le résultat à la main à quelques clients. Décidez à l’avance quel résultat vaut un oui, pour ne pas vous en convaincre après coup. Soyez honnête avec les visiteurs sur ce qui existe déjà, et ajoutez une mention d’information sur les données si vous collectez des adresses e-mail.

#Cadrez le prototype en jours, pas en mois

Un prototype se cadre par sa question, pas par une liste de fonctionnalités. Prenez l’hypothèse ouverte la plus risquée et ne construisez que ce qui la met à l’épreuve. Tout le reste est de la décoration.

1. Écrivez l’hypothèse la plus risquée sous forme de phrase qui peut se révéler fausse, par exemple : « Les responsables de cabinet laisseront les patients déplacer leurs rendez-vous sans téléphoner. »
2. Classez-la. Le désir et l’utilisabilité demandent des entretiens et un prototype cliquable ; la faisabilité demande un spike technique ; la viabilité économique demande des discussions sur le prix puis, plus tard, un pilote.
3. Choisissez un utilisateur et un parcours, du déclencheur au résultat. Un seul parcours de quelques écrans suffit généralement.
4. Fixez une durée et une date de test avant de commencer, et réservez dès maintenant les participants pour que la date ne glisse pas.
5. Convenez de ce que vous déciderez ensuite : continuer, changer de cap ou arrêter.

Le design sprint de GV montre jusqu’où peut aller une durée fixe : cinq jours entre la cartographie du problème et l’observation de clients face à un prototype réaliste, selon le principe qu’une façade réaliste suffit pour tester avec des clients. Inutile de mener un sprint formel, mais une journée de test fixe garde le prototype petit.

#UX et UI : du parcours utilisateur au prototype testé

Parcours utilisateur

Commencez par le parcours, pas par les écrans : les étapes entre le déclencheur (« le rendez-vous d’un patient est annulé ») et le résultat (« un nouveau créneau est réservé »), avec les points de décision et ce qui se passe quand quelque chose échoue. Un parcours tenant sur une page révèle les étapes manquantes et superflues avant que quiconque ne dessine un pixel.

Wireframes

Les wireframes sont des écrans basse fidélité : mise en page, contenus et actions dans des blocs gris. Ils se modifient vite, même entre deux sessions de test, et le Nielsen Norman Group souligne que les prototypes basse fidélité montrent clairement que le design n’est pas fini, si bien que les gens osent davantage le critiquer.

Prototypes cliquables dans Figma

Pour tester avec des utilisateurs et montrer le projet à des investisseurs, reliez des écrans réalistes en un prototype cliquable. Dans Figma, on relie les frames par des interactions pour former des parcours, puis on peut partager un lien ou présenter le prototype sur un appareil. Chaque zone cliquable du parcours testé doit fonctionner, sinon la session s’effondre. Utilisez des contenus réalistes, dans le vocabulaire de vos clients ; le faux texte masque justement les questions qui comptent.

Tests utilisateurs avec cinq personnes

Jakob Nielsen, du Nielsen Norman Group, soutient qu’un test qualitatif avec cinq utilisateurs révèle environ 85 % des problèmes d’utilisabilité et qu’un budget est mieux investi dans trois sessions de cinq personnes, en corrigeant entre chacune, que dans une seule grande étude. Deux nuances : avec des groupes d’utilisateurs nettement différents, comme le personnel d’un cabinet et les patients, testez trois ou quatre personnes par groupe ; et les mesures quantitatives demandent plus de cinq participants.

Un test utilisateur demande un animateur, des tâches réalistes et des participants qui ressemblent à votre premier utilisateur et qui pensent à voix haute pendant qu’ils travaillent. Formulez les tâches comme des objectifs, pas comme des instructions : « Vous devez déplacer le rendez-vous de mardi à la semaine prochaine », et non « Cliquez sur Reprogrammer ». NN/g prévient que les descriptions d’étapes contiennent des indices cachés sur l’utilisation de l’interface.

#Spikes techniques et vérifications de faisabilité IA

Une preuve de concept répond à la question de la faisabilité, et sa forme la plus rapide est le spike. Ward Cunningham raconte qu’il demandait à Kent Beck quelle était la chose la plus simple qu’ils pouvaient programmer pour se convaincre d’être sur la bonne voie, et Beck a appelé la réponse un spike : de bout en bout, mais très fin. Un spike est limité dans le temps, étroit et généralement jeté. Le livrable est l’enseignement, pas le code.

• Les intégrations avec des systèmes que vous ne maîtrisez pas, comme un ERP, un logiciel de gestion de cabinet ou une API bancaire : pouvez-vous vous authentifier, lire et écrire ce dont vous avez besoin, dans le respect de leurs limites d’appels et de leurs conditions d’utilisation ?
• La vitesse et la charge : la recherche, le matching ou le calcul répondent-ils dans le temps qu’un utilisateur est prêt à attendre ?
• Les données que vous supposez disponibles : existent-elles, sont-elles assez propres et peut-on légalement les utiliser à cette fin ?
• Les fonctions de l’appareil : synchronisation hors ligne, Bluetooth ou caméra, sur de vrais téléphones.

Faisabilité IA : testez le modèle sur vos cas réels

Pour un produit d’IA, la démo est la partie facile : un prompt qui fonctionne sur trois exemples choisis à la main en dit peu sur les cas réels. Une vérification utile :

1. Rassemblez de vraies entrées, y compris les plus désordonnées : formulaires incomplets, mauvaise langue, demandes ambiguës.
2. Écrivez à quoi ressemble une sortie correcte et quel taux d’erreur est acceptable avant de lancer quoi que ce soit.
3. Évaluez automatiquement dès que possible. Le guide d’Anthropic sur la construction d’évaluations recommande de refléter la répartition réelle des tâches, cas limites compris, et préfère de nombreux cas évalués automatiquement à quelques cas évalués à la main.
4. Mesurez le coût et le temps de réponse par requête au volume attendu, pas seulement la précision.
5. Vérifiez où vont les données : quel fournisseur, quelle région, sous quel contrat. Notre guide sur l’IA conforme au RGPD passe les options en revue.

Avant de brancher le moindre modèle, un prototype « Magicien d’Oz », où une personne produit les réponses derrière l’interface, teste l’expérience elle-même ; le Nielsen Norman Group le recommande pour les fonctions d’IA avant que l’IA ne soit construite. Vous séparez ainsi deux questions : les utilisateurs veulent-ils cette réponse, et un modèle peut-il la produire de façon fiable ?

#Ce qu’il faut montrer aux investisseurs et aux clients pilotes

Chaque public pose une question différente : montrez à chacun des preuves différentes.

Dites clairement ce qui est réel. Un prototype cliquable présenté comme un logiciel fini est le moyen le plus rapide de perdre un investisseur expérimenté ou le service informatique d’un client pilote.

Mettez chaque pilote par écrit sur une page : objectif, critères de succès, durée, qui fait quoi, et ce qui se passe si cela fonctionne. Un pilote sans critères de succès se termine souvent par un « intéressant » poli plutôt que par un contrat.

#Jeter le prototype ou le faire évoluer ?

Décidez-le avant de construire, car cela change la façon dont le prototype est fabriqué. La règle générale : les prototypes de design et les spikes sont jetés, le MVP est conservé. Le danger est entre les deux : un prototype codé qui devient le produit sans que personne ne l’ait décidé.

Martin Fowler appelle le code volontairement jetable une architecture sacrificielle et rappelle qu’eBay a commencé en 1995 comme un ensemble de scripts Perl écrits en un week-end. Jeter du code ne pose aucun problème quand c’était prévu ; le problème, c’est le code jamais conçu pour durer que l’on garde malgré tout.

Si vous le faites évoluer, relisez le code et corrigez d’abord les fondations coûteuses : modèle de données, comptes et rôles, paiements et région d’hébergement, comme l’explique le guide du neuvième mois.

#Un plan de deux à quatre semaines, de l’idée au prototype testé

Ce plan suppose une idée, un premier utilisateur et une petite équipe expérimentée. Deux semaines suffisent souvent pour le désir et l’utilisabilité ; prévoyez-en quatre s’il faut aussi prouver une intégration ou un modèle d’IA.

Le résultat de ce plan est une décision étayée par des preuves, pas un logiciel. Si la réponse est de continuer, l’étape suivante est la première version, construite sur des fondations que l’on garde.

#Les coûts, et les pièges qui les font grimper

Un prototype coûte surtout du temps humain, donc le coût suit le périmètre : nombre de groupes d’utilisateurs et de parcours, wireframes ou design au niveau de la marque, et besoin ou non d’une vérification de faisabilité technique ou IA. Pour obtenir une fourchette indicative pour votre idée, utilisez notre estimation gratuite ; c’est une estimation, pas un devis.

• Prototyper avant de valider. Un prototype soigné pour un problème non confirmé est un sondage très coûteux.
• Recueillir des opinions au lieu d’observer des comportements. « Je l’utiliserais sans hésiter » n’est pas une preuve ; un pilote accepté, si.
• Trop de fidélité trop tôt. Un design au niveau de la marque avant que le parcours ne soit arrêté ralentit chaque modification et rend chaque critique plus polie.
• Une démo qui cache la partie difficile. Si l’IA ou l’intégration est simulée, dites-le et testez-la à part.
• Un prototype qui devient le produit par accident. Décidez dès le départ s’il sera jeté ou prolongé.
• Des actifs au nom de quelqu’un d’autre. Fichiers de design, enregistrements de tests, domaines et dépôts doivent appartenir à votre entreprise dès le premier jour.

#Comment nous pouvons vous aider

Bespoke IT accompagne les fondateurs du concept à la première version : travail produit pour trouver et tester l’hypothèse la plus risquée, design UX et UI des parcours utilisateur jusqu’aux prototypes cliquables testés avec de vrais utilisateurs, architecture et spikes techniques pour la partie difficile, et développement de la version que vous garderez. Notre accompagnement des start-up commence par un discovery sprint, et notre page applications web et mobiles présente des concepts de notre équipe design à côté de produits que nous avons livrés.

Grâce à notre partenaire Salford Ventures GmbH, à Düsseldorf, les fondateurs bénéficient aussi d’un appui pour le financement : la stratégie, le plan financier, la préparation des documents que demandent les investisseurs et une liste d’investisseurs à contacter. Découvrez comment nous travaillons avec les start-up, obtenez une fourchette indicative pour votre prototype ou contactez-nous pour en parler.