PrototypeMVPMéthodeCahier des charges
Prototype, maquette, MVP, POC : quelles différences ?
6 min de lecture
Une maquette montre à quoi ressemblera l'application, un prototype montre comment on s'en sert, un POC (preuve de concept) prouve qu'une difficulté technique peut être résolue, et un MVP vérifie auprès de vrais utilisateurs que le produit répond à un besoin. Ces quatre livrables ne répondent pas à la même question, ne coûtent pas la même chose et ne finissent pas au même endroit : seuls le MVP et la V1 sont faits pour la production.
Les confondre est l'une des sources de malentendu les plus fréquentes entre un client et son prestataire. Voici les définitions côte à côte, ce que chacun prouve, et dans quel ordre les enchaîner selon votre projet.
Le tableau des définitions
| Livrable | Question posée | Nature | Fonctionne ? | Devient |
|---|---|---|---|---|
| Wireframe | Qu'y a-t-il sur chaque écran ? | Un schéma en blocs gris, sans style | Non | Une base pour la maquette ou le prototype |
| Maquette | À quoi ressemblera l'application ? | Des écrans dessinés, avec couleurs et typographie | Non, images fixes | Le référentiel visuel |
| Prototype cliquable | Comment s'en sert-on, du début à la fin ? | Des écrans enchaînés en parcours, avec des données réalistes | En apparence seulement | Le cahier des charges du développement |
| POC | Ce point technique est-il faisable ? | Un bout de code jetable, centré sur une seule difficulté | Oui, sur ce seul point | Un enseignement, rarement du code réutilisé |
| MVP | Des utilisateurs réels en tirent-ils de la valeur ? | Un produit réduit à un parcours complet | Oui, en production | La base de la V1 |
| V1 | Le produit sert-il durablement tout son public ? | Le produit complet de la première version | Oui, en production | Le socle des évolutions |
Deux colonnes méritent l'attention. « Fonctionne-t-il ? » sépare ce qui se montre de ce qui s'exploite. « Ce qu'il devient » dit ce que vous achetez réellement à chaque étape.
Wireframe et maquette : la forme
Le wireframe pose la structure : quelles zones, quels champs, quels boutons, sans aucun choix graphique. La maquette habille cette structure : couleurs, typographie, icônes, rendu final des écrans. Les deux sont des images. On peut cliquer sur une maquette dans un outil de design, mais elle ne fait rien : aucune donnée ne change, aucune règle ne s'applique.
Leur limite, pour une application métier, est de répondre surtout à la question du goût. Or ce qui fait réussir ou échouer un outil interne, ce sont rarement les couleurs : c'est l'ordre des saisies, les cas particuliers, le nombre de clics pour l'opération répétée cinquante fois par jour.
Le prototype : le parcours
Le prototype cliquable enchaîne les écrans comme dans l'application finale, avec des données qui ressemblent à celles de l'entreprise : de vrais noms de produits, des montants plausibles, des statuts réels. On peut y dérouler un parcours entier, de la création d'une commande à sa facturation par exemple.
C'est l'étape où les utilisateurs disent enfin « non, chez nous, ça ne se passe pas comme ça ». Ces corrections ne coûtent presque rien sur un prototype, et beaucoup une fois le code écrit. C'est aussi ce qui permet de chiffrer un forfait sérieusement : ce qui est à l'écran entre dans le prix, le reste fait l'objet d'une décision explicite. Nous détaillons cet usage dans notre article sur le fait de voir son logiciel avant de le payer.
Un prototype, en revanche, ne contient ni règles métier réelles, ni base de données, ni sécurité. Il démontre, il ne produit rien.
Le POC : la faisabilité technique
Le POC répond à une seule question technique, posée avant d'engager le budget : peut-on lire automatiquement les PDF de ce fournisseur ? Peut-on écrire dans cet ERP ancien qui n'a pas d'API documentée ? Le temps de réponse reste-t-il acceptable avec le volume réel de données ?
Il est volontairement rudimentaire : pas d'interface soignée, pas de gestion des erreurs, pas de tests. Il se juge sur une réponse, oui ou non, assortie de ses conditions. Tous les projets n'en ont pas besoin : un POC ne se justifie que lorsqu'un point technique précis menace l'ensemble du projet. Les connexions à un système existant en sont la cause la plus fréquente, comme nous l'expliquons dans notre article sur l'intégration d'une application à un ERP.
Le MVP : la valeur, avec de vrais utilisateurs
Le MVP est le premier livrable qui fonctionne pour de vrai : de vrais utilisateurs, de vraies données, en production. Il est réduit à un seul parcours complet, parce que son rôle est de vérifier une hypothèse (les clients paieront, les équipes l'adopteront), pas de tout couvrir. Comment choisir ce qui y entre est détaillé dans notre article sur le MVP.
Parce qu'il tourne en production, un MVP doit être sécurisé, sauvegardé et maintenu. Ce qui est réduit, c'est le nombre de fonctions, pas la qualité.
Dans quel ordre, et lesquelles sauter
Aucun projet n'a besoin des six étapes. L'enchaînement dépend de ce qui est incertain :
| Votre situation | L'enchaînement raisonnable |
|---|---|
| Application interne, besoin connu, pas de difficulté technique | Prototype, puis V1 livrée par paliers |
| Nouveau SaaS, marché à vérifier | Prototype, puis MVP, puis V1 |
| Connexion risquée à un système existant | POC en parallèle du prototype, puis V1 |
| Identité visuelle à créer de zéro | Maquette intégrée au prototype |
Le prototype figure sur toutes les lignes, et ce n'est pas un hasard : c'est l'étape la moins coûteuse pour aligner tout le monde sur ce qui sera construit.
Les confusions qui coûtent cher
Prendre le prototype pour une application presque finie. Les écrans existent, donc « l'essentiel est fait ». En réalité, les règles métier, les données, les intégrations et la sécurité restent entièrement à construire. Un prototype réussi raccourcit le projet ; il ne le remplace pas.
Mettre un POC en production. Le code d'une preuve de concept a été écrit pour répondre vite à une question, pas pour durer. Le promouvoir en produit, c'est hériter d'une dette dès le premier jour.
Valider une maquette sans parcours. Des écrans magnifiques, validés un par un, peuvent cacher un enchaînement absurde. On ne le découvre qu'en développement.
Appeler MVP une V1 complète. Un MVP qui contient tout coûte le prix d'une V1 et n'apprend rien de plus.
Qui possède quoi
La question mérite d'être posée à chaque étape, avant de commencer. Chez LPR Studio, le prototype de démonstration est gratuit : il est présenté en visio, pas livré, et il reste la propriété du studio. Pour l'application développée ensuite, les droits dépendent de la formule retenue et sont définis au cas par cas dans le contrat ; les trois formules sont présentées sur la page des offres.
Par où commencer
Si vous ne savez pas encore de quel livrable vous avez besoin, commencez par celui qui coûte le moins et qui éclaire tous les autres : le prototype. Chez LPR Studio, il est gratuit et présenté en visio sous 5 jours ouvrés, avec des écrans, des parcours et des données réalistes. Une fois validé, il devient le cahier des charges, et le prix du forfait est fixé avant la première ligne de code. Le détail de la démarche est sur notre page d'approche.