Preuve de concept vs prototype : que construire en premier ?

Une preuve de concept, un prototype et un MVP répondent à trois questions différentes. Payez pour construire le mauvais et vous passez des semaines à prouver une chose que vous saviez déjà.

Un fondateur est venu nous voir l’an dernier avec un devis signé pour un « prototype » de son app de logistique : quarante mille dollars, une version cliquable de chaque écran. Ce qui l’empêchait vraiment de dormir, c’était de savoir si l’app pourrait récupérer des données en temps réel auprès de trois transporteurs dont personne dans son entreprise n’avait touché les systèmes. Ce n’est pas une question de prototype. Il était sur le point de payer pour découvrir que ses écrans étaient jolis, pendant que la seule chose capable de tuer l’entreprise restait sans test.

C’est tout le piège de preuve de concept vs prototype. Une preuve de concept répond à une question : est-ce que ça peut vraiment être construit ? Un prototype en répond à une autre : est-ce que ça a du sens pour celui qui va s’en servir ? Un MVP répond à une troisième : est-ce que quelqu’un va payer pour ça ? Trois artefacts, trois risques, et ce ne sont pas trois tailles de la même chose. Le vrai travail du fondateur est de dépenser de l’argent uniquement sur la question à laquelle il ne sait pas encore répondre. Si vous savez que la partie technique est triviale, une preuve de concept est un gaspillage. Si vous savez que les gens en veulent et que c’est constructible, sautez les deux et construisez la chose.

Voici comment les distinguer, et comment décider vers quoi votre argent doit aller en premier.

Ce qu’une preuve de concept prouve vraiment

Une preuve de concept est une expérience jetable qui vérifie si un risque technique précis a une solution. Pas le produit entier. La seule partie qui vous rend nerveux.

La vraie preuve de concept du fondateur en logistique, c’était deux semaines d’un ingénieur essayant de s’authentifier auprès de ces trois API de transporteurs et de normaliser les données en un seul flux. Un script laid, sans interface, sans écran de connexion, rien qu’un client verrait un jour. La sortie était un oui ou un non. Elle est revenue « oui pour deux d’entre elles, et la troisième exige une offre enterprise payante ». Cette réponse valait plus que la version cliquable à quarante mille dollars, parce qu’elle a changé le modèle de prix de toute l’entreprise avant qu’une ligne de vrai produit ne soit écrite.

Une preuve de concept est le bon choix quand votre plus grande inconnue est une phrase qui commence par « est-ce qu’on peut seulement ». Est-ce qu’on peut seulement s’intégrer au système de dossiers de cet hôpital. Est-ce qu’on peut seulement faire tourner cet algorithme de matching assez vite pour que ça paraisse instantané. Est-ce qu’on peut seulement amener un modèle d’IA à extraire les bons champs d’un PDF en désordre de façon fiable. Quand le risque est la faisabilité technique, rien d’autre que vous construisez ne compte tant que cette question n’a pas de réponse, parce qu’un beau produit posé sur une intégration impossible n’est qu’une façon coûteuse d’apprendre que l’intégration était impossible.

Ce qu’une preuve de concept n’est pas : ce n’est pas la première version de votre produit. Vous la jetez. Réutiliser le code d’une preuve de concept comme fondation est l’une des erreurs les plus coûteuses que nous voyons, parce que ce code a été écrit pour répondre vite à une question, pas pour être maintenu par une équipe pendant trois ans.

Ce qu’un prototype prouve vraiment

Un prototype vérifie si la chose a du sens avant que quelqu’un ne la construise pour de vrai. Le risque qu’il retire n’est pas « est-ce que ça peut être construit », mais « est-ce la bonne forme pour celui qui l’utilise ».

La plupart des prototypes ne sont pas du code du tout. Ce sont des écrans cliquables, faits dans un outil de design, qui laissent un vrai utilisateur parcourir un flux et se perdre devant vous. La valeur est entièrement dans le fait d’assister à cette confusion pendant que changer un écran coûte encore un après-midi plutôt qu’un sprint. Si vous vous êtes déjà assis derrière quelqu’un utilisant votre produit et avez senti votre estomac se serrer quand il a complètement raté le bouton dont vous étiez fier, vous comprenez à quoi sert un prototype. Il déplace ce serrement d’estomac de l’après-lancement vers l’avant, avant que vous ne payiez pour construire.

Les prototypes existent en plusieurs fidélités, et le mot sert pour toutes, ce qui fait partie de la confusion. Un croquis sur papier est un prototype. Un wireframe en boîtes grises est un prototype. Un mockup parfait, cliquable, ayant l’apparence exacte de l’app finie, est un prototype. Ils s’étalent sur un spectre qui va de « assez brut pour tester le flux » à « assez soigné pour tester le ressenti », et les plus soignés commencent à se confondre avec le travail de design que vous feriez de toute façon. Nous avons écrit sur l’endroit où cette ligne se situe dans notre article sur wireframe contre mockup ; en bref, un wireframe teste la plomberie et un mockup teste la peinture.

Un prototype est le bon choix quand votre plus grande inconnue porte sur les gens, pas sur les machines. Vont-ils comprendre le flux. Vont-ils faire assez confiance pour entrer leur carte. L’onboarding a-t-il du sens pour quelqu’un qui n’est pas vous. Quand la technique est banale et bien balisée mais que l’expérience n’est pas prouvée, c’est le travail d’un prototype.

Où le MVP entre en jeu, et pourquoi les trois se confondent

Le troisième mot vers lequel les fondateurs se tournent est MVP, et il a sa place dans cette conversation parce qu’il répond au risque que les deux autres ne touchent pas : le marché va-t-il vraiment payer.

Une preuve de concept prouve que ça peut être construit. Un prototype prouve que ça a du sens. Aucun des deux ne prouve que quelqu’un en veut assez pour ouvrir son portefeuille. C’est le travail du produit minimum viable, et c’est le risque que le travail de customer development de Steve Blank place au centre de tout : un MVP doit être un logiciel réel, fonctionnel, utilisé par de vrais clients avec du vrai argent ou de vraies données en jeu. Un prototype cliquable ne valide pas la demande, parce que personne ne risque rien en parcourant une démo. Nous avons déjà soutenu que la plupart des choses que les fondateurs appellent MVP sont trop petites pour prouver quoi que ce soit dans notre analyse du produit minimum viable, et cette question de demande est exactement ce qu’un effort de validation de marché est fait pour trancher.

Les trois se confondent parce qu’ils peuvent se chevaucher dans une seule construction, et parce que les prestataires ont intérêt à garder les mots flous. Si la même expérience de deux semaines prouve que l’intégration fonctionne et est montrée à trois clients qui disent « je paierais pour ça », elle a fait le travail d’une preuve de concept et d’une validation bricolée à la fois. Très bien. Le but n’est pas de mener trois projets séparés dans une séquence rigide. Le but est de savoir quel risque chaque heure de dépense achète vraiment, pour que vous ne payiez pas un designer à polir des écrans quand votre vrai problème est une base de données dont vous n’êtes pas sûr qu’elle existe.

Preuve de concept vs prototype : lequel en premier ?

La réponse honnête : celui qui attaque votre plus grande inconnue. Il n’y a pas d’ordre universel, et tout prestataire qui vous en donne un sans interroger votre risque vend un processus, il ne pense pas à votre entreprise.

Cela dit, il y a une valeur par défaut utile. Quand un projet porte un vrai risque technique, la preuve de concept passe en premier, parce qu’il ne sert à rien de tester si les utilisateurs adorent un flux qui ne peut pas être construit. La faisabilité est la porte de tout. Quand la technique est ordinaire (encore un CRUD, encore une marketplace, encore un dashboard) et que le risque vit entièrement dans le fait que les gens s’en servent et paient, vous pouvez sauter la preuve de concept et commencer par un prototype, puis aller droit à un MVP.

L’échec que nous voyons le plus souvent, ce sont des fondateurs qui inversent l’ordre par enthousiasme. Le prototype est la partie amusante. Il est visuel, il se partage, il rend l’idée réelle, et vous pouvez le montrer à votre conjoint. Alors les fondateurs dépensent d’abord sur le prototype, en tombent amoureux, et ne découvrent le problème de faisabilité que des mois plus tard, quand un ingénieur tente enfin de construire la partie difficile. À ce moment-là, il y a un beau design auquel tout le monde tient et un mur technique que personne n’a vérifié. Ordonnez votre dépense par le risque, pas par ce qui est satisfaisant à regarder.

Le test d’une seule question pour décider où payer

Voici la méthode que nous parcourons avec les fondateurs. Elle prend environ cinq minutes et se résume à une question, posée honnêtement.

Écrivez la seule chose la plus susceptible de tuer ce projet. Pas une liste. Une phrase. Puis regardez par quel mot elle commence.

• Si elle commence par « peut-on construire » : c’est un risque technique. Payez pour une preuve de concept.
• Si elle commence par « les gens vont-ils comprendre, faire confiance ou utiliser » : c’est un risque de design. Payez pour un prototype.
• Si elle commence par « quelqu’un va-t-il payer, le marché existe-t-il » : c’est un risque de marché. Payez pour un MVP, ou pour une validation moins chère avant de construire quoi que ce soit.
• Si vous ne pouvez pas écrire honnêtement une phrase, vous n’avez pas encore de décision de dépense. Vous avez de la réflexion à faire.

La discipline consiste à refuser de dépenser sur un risque que vous avez déjà retiré. Si vous vous êtes déjà intégré à ce prestataire de paiement sur trois projets passés, « peut-on construire les paiements » n’est pas votre risque, et une preuve de concept pour ça est du théâtre. Si dix clients vous supplient déjà pour ça et paient des concurrents pour une version pire, « quelqu’un va-t-il payer » a sa réponse, et mener une longue validation est de la procrastination déguisée en rigueur.

La règle empirique : construisez une preuve de concept seulement quand votre plus grand risque est « est-ce que ça peut être construit », un prototype seulement quand c’est « vont-ils s’en servir », et si vous connaissez déjà les deux réponses, arrêtez de tester et construisez la vraie chose. Eric Ries a bien résumé l’objectif de fond dans Lean Startup : « La seule façon de gagner, c’est d’apprendre plus vite que les autres. » Chacun de ces artefacts n’est qu’une façon d’acheter à bas prix un morceau précis d’apprentissage. S’il n’achète pas un apprentissage que vous n’avez pas déjà, il n’est pas bon marché. C’est une facture.

Un prototype peut-il être une preuve de concept ?

Parfois, et c’est là que les mots se chevauchent vraiment. Un prototype peut faire office de preuve de concept quand la partie risquée est l’interaction elle-même, pas la plomberie derrière.

Disons que votre pari est une façon radicalement plus simple de déclarer une note de frais, un geste au lieu d’un formulaire. Construire une version fonctionnelle de ce geste et la mettre devant des utilisateurs teste à la fois la faisabilité (« peut-on rendre cette interaction fluide ») et le désir (« les gens la préfèrent-ils vraiment »). Un artefact, deux risques retirés. Mais l’inverse tient rarement : une preuve de concept n’est presque jamais un prototype, parce qu’une POC est d’ordinaire un script sans tête, sans interface pour que quiconque réagisse. Elle prouve que le moteur démarre. Elle ne dit rien sur le fait que quelqu’un veuille conduire la voiture.

Le piège est de supposer que le chevauchement existe toujours. La plupart du temps, non. La plupart des risques techniques vivent dans le backend, invisibles, et la plupart des risques d’utilisabilité vivent dans le frontend, et tester l’un ne vous dit rien de l’autre. Supposez qu’ils sont séparés jusqu’à ce que vous puissiez expliquer clairement pourquoi, dans votre cas précis, ils sont la même chose.

Combien chacun doit vous coûter, en semaines et non en features

Les fondateurs demandent combien ça coûte, et la réponse utile est en temps et en périmètre, pas en un chiffre d’argent, parce que le chiffre d’argent n’est que le temps multiplié par un taux que vous pouvez consulter dans notre analyse de combien coûte vraiment une application.

Une preuve de concept doit être petite et rapide : de quelques jours à deux ou trois semaines, un ingénieur, une question. Si quelqu’un vous chiffre deux mois pour une preuve de concept, soit il teste trop de choses à la fois, soit il construit discrètement votre produit en l’appelant POC. Répliquez. Une preuve de concept qui prend deux mois a cessé d’être une preuve de concept.

Un prototype grandit avec la fidélité. Un flux cliquable brut pour tester un seul parcours, c’est quelques jours de design. Un mockup soigné de l’app entière, c’est plusieurs semaines, et à ce stade vous devriez vous demander si vous prototypez ou si vous faites simplement la phase de design de la vraie construction plus tôt, ce qui est souvent très bien tant que vous savez que c’est ça que vous payez.

Un MVP est le coûteux, parce que c’est un vrai logiciel, et son coût est une conversation entière à part. L’erreur est de laisser un MVP se déguiser en prototype dans un devis, ou un prototype se déguiser en MVP. Quand le chiffre paraît trop gros pour le mot, c’est le mot qui est en général faux.

L’erreur qui brûle le plus d’argent

L’erreur la plus coûteuse est celle que le fondateur en logistique a failli commettre : payer pour retirer le risque que vous n’avez pas tout en ignorant celui que vous avez. Un prototype magnifique d’une app dont l’intégration centrale se révèle impossible. Une preuve de concept solide pour un produit techniquement difficile dont personne ne veut vraiment. Un MVP complet construit avant que quiconque n’ait vérifié si la partie difficile pouvait être construite.

La raison pour laquelle cela se reproduit sans cesse, c’est que le risque amusant et le risque réel sont d’ordinaire des risques différents. L’amusant est visuel et se partage. Le réel est souvent ennuyeux, enfoui dans un backend, ou posé sur une question inconfortable de savoir si les clients s’en soucient. Les prestataires, on le comprend, préfèrent vous vendre l’amusant. Votre défense est le test d’une seule question et la volonté de dépenser votre premier dollar sur l’inconnue qui vous effraie vraiment, même quand c’est la partie la moins photogénique de toute l’idée. C’est la différence entre un partenaire et une boîte noire : un partenaire demande quel risque vous êtes en train de retirer avant de vous chiffrer, et vous détourne de la réponse coûteuse-mais-satisfaisante quand elle est mauvaise.

Questions fréquentes

Quelle est la différence entre une preuve de concept et un prototype ?
Une preuve de concept vérifie si quelque chose peut être construit (faisabilité technique). Un prototype vérifie si c’est agréable à utiliser (design et utilisabilité). Une POC est d’ordinaire un script jetable sans interface ; un prototype est d’ordinaire des écrans cliquables sans backend fonctionnel. Ils retirent des risques différents et sont rarement interchangeables.

Qu’est-ce qui vient en premier, une preuve de concept ou un prototype ?
Celui qui attaque votre plus grande inconnue. Par défaut, quand le projet a un vrai risque technique, la preuve de concept vient en premier, parce qu’il ne sert à rien de tester si les utilisateurs aiment un flux qui ne peut pas être construit. Quand la technologie est ordinaire et que le risque tient tout entier à l’adoption, vous pouvez sauter la POC et commencer par un prototype.

Quel est un exemple de preuve de concept ?
Une expérience de deux semaines où un ingénieur écrit un script laid pour vérifier si votre app peut s’authentifier auprès de trois systèmes externes et fusionner leurs données en un seul flux. Sans connexion, sans design, sans produit. La sortie est un oui ou un non sur la seule question technique qui pourrait tuer le projet.

Un prototype peut-il être une preuve de concept ?
Oui, quand la partie risquée est l’interaction elle-même plutôt que le backend. Construire et tester un geste nouveau prouve à la fois qu’il fonctionne et que les gens le veulent. Mais une preuve de concept n’est presque jamais un prototype, parce que la plupart des POC n’ont pas d’interface pour que quiconque réagisse.

Où se situe un MVP par rapport à une POC et un prototype ?
Un MVP est un logiciel réel, fonctionnel, utilisé par de vrais clients, et il répond au risque de marché que les deux autres ne touchent pas : quelqu’un va-t-il payer. Une preuve de concept prouve que ça peut être construit ; un prototype prouve que ça a du sens ; un MVP prouve que l’entreprise fonctionne. La plupart de ce que les fondateurs appellent MVP est en réalité un prototype ou une première version réduite.