Un proof of concept prouve que la technologie fonctionne, un prototype prouve que les utilisateurs comprennent l'idée, et un MVP prouve que quelqu'un l'utilisera dans son flux de travail réel. Le bon choix est l'artefact le moins coûteux qui teste votre hypothèse la plus risquée.
Chaque mois, des fondateurs paient le prix d'un MVP pour répondre à une question de prototype, et l'écart entre ces deux factures se compte en dizaines de milliers d'euros. Les trois termes se mélangent lors des appels avec les agences, et chaque prestataire a intérêt à vendre le plus gros.
Ce guide distingue les trois selon l'hypothèse que chacun élimine. Vous y trouverez un tableau comparatif avec des chiffres 2026, deux histoires de projets anonymisées tirées du journal de livraison de webvise, et une règle de décision qui s'applique en cinq minutes.
- Un proof of concept répond à une seule question : est-ce réalisable techniquement. Il prend de quelques heures à une semaine, et le code est jetable.
- Un prototype cliquable répond à : les utilisateurs comprennent-ils l'offre et le parcours. Il prend 2 à 5 jours et ne nécessite aucun backend.
- Un MVP ciblé répond à : un utilisateur réel ira-t-il au bout du flux de travail principal avec de vraies données. Il prend 3 à 5 semaines et coûte de 5 000 € à 25 000 € aux tarifs d'une agence assistée par IA.
- Choisissez l'artefact le moins coûteux qui teste votre hypothèse la plus risquée. Acheter un MVP pour répondre à une question de prototype brûle des dizaines de milliers d'euros.
- Un processus manuel déjà payant compte comme validation. Quand la demande est déjà prouvée, sautez le prototype et construisez directement le MVP en qualité production.
Ce que prouve chaque artefact
Les trois artefacts se situent sur un même axe : la quantité de réalité qu'ils laissent entrer. Un proof of concept ne touche aucun utilisateur. Un prototype touche des utilisateurs en entretien mais ne traite aucune donnée réelle. Un MVP tourne en production avec de vrais comptes, de vraies données et de vraies conséquences.
| Artefact | Question qu'il élimine | Délai | Coût (2026) | Qui le voit |
|---|---|---|---|---|
| Proof of concept | Est-ce réalisable avec la technologie actuelle ? | De quelques heures à 1 semaine | Temps interne, généralement sous 2 000 € | L'équipe, personne d'autre |
| Prototype cliquable | Les utilisateurs comprennent-ils l'offre et le parcours ? | 2 à 5 jours | 1 500 € à 5 000 € | Utilisateurs interrogés, public de démo, investisseurs |
| MVP ciblé | Un utilisateur ira-t-il au bout du flux de travail principal avec de vraies données ? | 3 à 5 semaines | 5 000 € à 25 000 € | Utilisateurs réels, en production |
Les délais correspondent au tableau de périmètre dans combien de temps prend la construction d'un MVP, qui détaille la fenêtre de 3 à 5 semaines semaine par semaine. Les fourchettes de coûts proviennent de la grille tarifaire de webvise pour les projets assistés par IA.
Si la question à trancher est celle du MVP, le service de développement MVP de webvise livre une première version ciblée en 3 à 5 semaines, de qualité production dès le premier commit.
Choisissez selon votre hypothèse la plus risquée
Écrivez la seule hypothèse qui tuerait le projet si elle s'avérait fausse. Cette phrase choisit l'artefact à votre place. C'est la même phrase qui sert d'ancrage au modèle de document d'exigences MVP que webvise utilise comme contrat d'apprentissage.
- Le risque de faisabilité ressemble à : le modèle peut extraire les lignes de factures scannées avec une précision de 95 %. Construisez un proof of concept. Un script testé sur 50 documents échantillons y répond en deux jours.
- Le risque de compréhension ressemble à : un acheteur du BTP comprend une tarification à la performance dès le premier contact. Construisez un prototype cliquable et observez la réaction de cinq personnes face à lui.
- Le risque comportemental ressemble à : les agents téléverseront des documents chaque semaine sans qu'on le leur rappelle. Construisez un MVP, car seul un comportement en production répond à une question de comportement.
La plupart des projets portent les trois risques à la fois, et l'ordre compte : éliminez d'abord le risque le moins coûteux. Passer 5 semaines sur un MVP alors qu'une question de faisabilité reste sans réponse en dessous, c'est parier toute la construction sur quelque chose qu'un script de deux jours aurait pu tester.
Mini-histoire : le prototype d'une semaine qui a répondu à la question
En juin 2026, webvise a construit un concept de moteur de livraison pour une équipe berlinoise travaillant sur des opérations de service natives IA. L'idée : les entreprises de services vendent des résultats finis, des agents exécutent les flux de travail, des humains valident les transitions risquées, et chaque exécution affiche sa marge. L'hypothèse la plus risquée était de savoir si les opérateurs comprendraient et croiraient à cette boucle opérationnelle. La faisabilité pouvait attendre.
L'artefact était une landing page associée à un concept de tableau de bord opérateur : une bibliothèque de flux de travail avec prix et marges cibles, un tableau de livraison, des chronologies d'exécution avec preuves jointes, et une vue des marges. Aucun backend de production, aucune exécution d'agent en direct. La livraison a pris une semaine.
Un MVP pour la même idée aurait impliqué une orchestration d'agents, des intégrations de connecteurs et des points de validation : des mois de travail et un budget de plusieurs dizaines de milliers d'euros. Le concept d'une semaine a présenté la même histoire aux opérateurs pour une fraction de ce coût, et leurs réactions déterminent désormais ce qui sera construit.
Où les fondateurs paient trop cher
L'erreur coûteuse joue dans les deux sens. Premier sens : payer le prix d'un MVP pour une question de prototype. Les agences traditionnelles annoncent de 60 000 € à 150 000 € pour des MVP qui passent leurs deux premiers mois en ateliers et maquettes, soit du travail de prototype à 20 fois le prix. Le détail des paliers dans le coût de développement d'un MVP en 2026 montre d'où viennent ces devis.
Deuxième sens : livrer un prototype en l'appelant MVP. Les builds en vibe coding font bonne impression en démo, puis s'effondrent à l'arrivée de vrais comptes, de vraies données et de cas limites. Ce mode d'échec a son propre article : le piège de la dette technique des MVP en vibe coding.
Le test est sans détour. Si aucun utilisateur réel ne peut s'inscrire et aller au bout du flux de travail principal sans aide, c'est un prototype, quoi que dise la facture. S'il ne survit pas à un deuxième rôle utilisateur ou à une saisie mal formée, c'est un prototype avec une URL de production.
Mini-histoire : quand sauter le prototype était la bonne décision
En février 2026, webvise a construit une plateforme de certificats de financement pour un service immobilier berlinois. Les acheteurs l'utilisent pour prouver leur solvabilité aux agents et aux vendeurs, et le service promet un certificat contraignant sous 24 heures. La demande était déjà prouvée, et à prix fort : l'équipe émettait les certificats manuellement, et les clients les payaient.
La demande étant réglée, le risque restant était opérationnel. Un formulaire de financement en 10 étapes, une génération automatisée de certificats PDF et une comparaison sur plus de 550 banques partenaires pouvaient-ils fonctionner sans le goulot d'étranglement manuel ? Seule la production répond à cela, donc la mission est passée directement à un MVP full-stack de 6 semaines.
La plateforme est sortie avec un tableau de bord admin couvrant tout le cycle de vie des demandes, un score de performance Lighthouse de 96, et des chargements de page sous 1,2 seconde. Une phase de prototype aurait retardé la réponse sans rien tester que le processus manuel n'avait déjà testé.
C'est la règle cachée derrière ces deux histoires. Un processus manuel déjà payant constitue une phase de validation achevée. Une histoire opérationnelle non prouvée dans une catégorie nouvelle mérite d'abord un prototype.
Le chemin de montée en gamme : ce qui survit à chaque étape
Les trois artefacts forment une échelle, mais la matière ne monte pas automatiquement. Savoir ce qui survit évite de payer deux fois pour la même chose.
- Depuis le proof of concept : l'apprentissage survit, le code meurt. Un script de PoC ayant prouvé la précision d'extraction devient une ligne d'exigence, jamais une fondation.
- Depuis le prototype : le parcours et les écrans survivent dans la construction du MVP, avec le câblage de production ajouté derrière. Les raccourcis du prototype restent en arrière.
- Depuis le MVP : tout survit, et c'est bien le but. webvise construit les MVP avec TypeScript, un vrai schéma de base de données, du CI/CD et du monitoring dès le premier jour, si bien que la base de code grandit avec le produit au lieu d'être réécrite.
Le chemin inverse est le piège. Promouvoir un prototype en production maintient ses raccourcis en vie sous charge réelle, et le nettoyage coûte généralement plus cher qu'un MVP correctement cadré n'aurait coûté dès le départ.
La version en cinq minutes : écrivez votre hypothèse la plus risquée en une phrase, puis achetez l'artefact le moins coûteux qui l'élimine. webvise cadre exactement cela lors d'un court appel et construit des MVP et prototypes en 1 à 5 semaines. Envoyez votre hypothèse en une phrase via le formulaire de contact et vous saurez quel artefact il vous faut.