MVP, POC et prototype : ne pas les confondre

Trois mots employés comme des synonymes, trois objets totalement différents. Un POC répond « est-ce possible ? ». Un prototype répond « est-ce utilisable ? ». Un MVP répond « est-ce que quelqu'un en veut ? ». Les mélanger est la façon la plus fiable de gaspiller un budget.

Les trois objets, et leur question

La preuve de concept (POC)

Elle répond à une question technique : est-ce que c'est faisable ? On teste l'hypothèse la plus risquée, avec le minimum de code, sans interface soignée, sans sécurité, sans données réelles. Sa durée se compte en jours ou en semaines.

Un POC réussi produit une réponse, pas un logiciel. Il devrait être jetable — et il doit être jeté. Le promouvoir en production est le mode d'échec le plus courant et le plus coûteux des projets d'IA en particulier : la démo impressionne, quelqu'un décide de la garder, et six mois plus tard on découvre qu'il n'y a ni tests, ni gestion d'erreur, ni supervision, ni modèle de coût.

Le prototype

Il répond à une question d'usage : est-ce que les gens comprennent et savent s'en servir ? Souvent sans code du tout — une maquette cliquable suffit. On le montre à de vrais utilisateurs, on regarde où ils bloquent.

Le MVP

Il répond à une question de marché : est-ce que quelqu'un utilise ça pour de vrai, et est-ce que ça produit le résultat attendu ? Contrairement aux deux autres, un MVP est un vrai produit en production, avec de vrais utilisateurs et de vraies données. Il est réduit en périmètre, pas en qualité.

Le malentendu central sur le MVP

« Minimum viable » ne veut pas dire « bâclé ». Le mot viable fait tout le travail : le produit doit fonctionner assez bien pour qu'on puisse en tirer une conclusion honnête.

Si votre MVP est lent, planté ou incompréhensible, vous n'apprenez rien sur votre marché. Vous apprenez que les gens n'aiment pas les logiciels cassés — ce que vous saviez déjà.

La bonne façon de réduire un MVP : couper la largeur, pas la profondeur. Un seul cas d'usage, mais traité complètement, avec ses cas d'erreur. Pas dix cas d'usage traités à moitié.

Comment cadrer le périmètre

Écrivez l'hypothèse, avec un chiffre. Pas « les courtiers vont aimer », mais « les courtiers vont traiter 30 % de dossiers de plus par semaine ». Sans chiffre, il n'y a pas d'expérience, seulement une opinion à venir.
Identifiez le parcours unique qui la teste. Le chemin le plus court entre l'utilisateur et le résultat.
Listez ce qui est hors périmètre, explicitement. La liste des exclusions est plus utile que celle des inclusions : c'est elle qu'on relira quand quelqu'un demandera « on pourrait juste ajouter... ».
Fixez le critère de décision d'avance. Quel résultat vous fera continuer, pivoter ou arrêter ? Décidé après coup, ce seuil se déplace toujours pour justifier de continuer.

Ce qu'on ne coupe jamais dans un MVP

Même à périmètre minimal, quatre choses restent :

L'authentification et les autorisations. Une fuite de données sur un MVP est une vraie fuite de données.
La mesure. Si vous ne pouvez pas observer l'usage, vous n'apprendrez rien — et c'était le but.
La gestion des erreurs. Un utilisateur qui perd son travail à cause d'un plantage ne revient pas donner une seconde chance.
Une porte de sortie des données. Un export. Si vous pivotez, vous ne voulez pas laisser les données de vos premiers utilisateurs dans un cul-de-sac.

Et si le MVP fonctionne ?

C'est le moment le plus délicat. Le MVP a été bâti pour apprendre, avec des raccourcis assumés. Il ne faut ni le jeter, ni prétendre que c'est une plateforme mature.

La séquence qui fonctionne : stabiliser ce qui est réellement utilisé, inscrire les raccourcis comme de la dette technique explicite avec un plan, puis étendre le périmètre une fonctionnalité à la fois. Ce qui ne fonctionne pas : ajouter cinq fonctionnalités par-dessus les fondations provisoires, jusqu'à ce que plus rien ne bouge.

Notre position

On ne livre pas de démos. Nos mandats visent la production, même quand le périmètre est réduit — parce qu'un système qui ne va pas en production n'a rien prouvé. Le MVP est une stratégie de périmètre, pas une excuse pour sauter l'ingénierie.

Questions fréquentes

Quelle est la différence entre un MVP et un POC ?

Un POC répond à une question technique — est-ce faisable — et doit être jetable. Un MVP est un vrai produit en production, avec de vrais utilisateurs, réduit en périmètre mais pas en qualité, qui répond à une question de marché : est-ce que quelqu'un l'utilise et ça marche.

Que veut dire MVP ?

Minimum Viable Product, ou produit minimum viable : la plus petite version d'un produit qui permet de vérifier une hypothèse auprès de vrais utilisateurs. Le mot important est « viable » — il doit fonctionner assez bien pour qu'on puisse en tirer une conclusion.

Combien de temps pour construire un MVP ?

Généralement de quelques semaines à quelques mois. Au-delà, le périmètre est probablement trop large : l'objectif est d'apprendre vite, et un MVP qui prend un an n'apprend rien avant que le marché ait bougé.

Peut-on transformer un POC en produit ?

Presque jamais directement. Un POC est bâti sans tests, sans sécurité, sans gestion d'erreur ni supervision. Le promouvoir en production revient à hériter de tous ces manques d'un coup — c'est le mode d'échec le plus fréquent des projets d'IA.

Parlons de votre projet

Une idée de produit sans équipe technique pour la bâtir ? C'est exactement ce qu'on fait — et sur certains produits, on met du capital à côté du code. Parlez-nous-en.

Three words used interchangeably, three completely different objects. A POC answers "is it possible?". A prototype answers "is it usable?". An MVP answers "does anyone want it?". Mixing them up is the most reliable way to waste a budget.

The three objects, and their question

Proof of concept (POC)

Answers a technical question: is this feasible? You test the riskiest hypothesis with the minimum of code, no polished interface, no security, no real data. Measured in days or weeks.

A successful POC produces an answer, not software. It should be disposable — and it must be disposed of. Promoting it to production is the most common and most expensive failure mode of AI projects in particular: the demo impresses, someone decides to keep it, and six months later it turns out there are no tests, no error handling, no monitoring and no cost model.

Prototype

Answers a usage question: do people understand it and know how to use it? Often with no code at all — a clickable mockup is enough. You put it in front of real users and watch where they stall.

MVP

Answers a market question: does anyone actually use this, and does it produce the expected outcome? Unlike the other two, an MVP is a real product in production, with real users and real data. It is reduced in scope, not in quality.

The central misunderstanding about MVPs

"Minimum viable" does not mean "sloppy". The word viable does all the work: the product must work well enough to support an honest conclusion.

If your MVP is slow, crashing or incomprehensible, you learn nothing about your market. You learn that people dislike broken software — which you already knew.

The right way to reduce an MVP: cut breadth, not depth. One use case, handled completely, error cases included. Not ten use cases handled halfway.

How to scope it

Write the hypothesis, with a number. Not "brokers will like it", but "brokers will process 30 percent more files per week". Without a number there is no experiment, only a future opinion.
Identify the single journey that tests it. The shortest path between user and outcome.
List what is explicitly out of scope. The exclusion list is more useful than the inclusion list: it is the one you re-read when someone says "could we just add...".
Set the decision criterion up front. What result makes you continue, pivot or stop? Decided afterwards, that threshold always moves to justify continuing.

What you never cut from an MVP

Even at minimum scope, four things stay:

Authentication and authorisation. A data leak on an MVP is a real data leak.
Measurement. If you cannot observe usage, you will learn nothing — and that was the point.
Error handling. A user who loses their work to a crash does not come back for a second chance.
A data exit. An export. If you pivot, you do not want your first users' data in a dead end.

And if the MVP works?

That is the delicate moment. The MVP was built to learn, with deliberate shortcuts. Neither throw it away nor pretend it is a mature platform.

The sequence that works: stabilise what is actually used, record the shortcuts as explicit technical debt with a plan, then extend scope one feature at a time. What does not work: stacking five features on provisional foundations until nothing moves any more.

Where we stand

We do not deliver demos. Our engagements target production even when scope is small — because a system that never reaches production has proven nothing. An MVP is a scoping strategy, not an excuse to skip engineering.

Frequently asked questions

What is the difference between an MVP and a POC?

A POC answers a technical question — is this feasible — and should be disposable. An MVP is a real product in production with real users, reduced in scope but not in quality, answering a market question: does anyone use it and does it work.

What does MVP stand for?

Minimum Viable Product: the smallest version of a product that lets you test a hypothesis with real users. The important word is viable — it must work well enough to support a conclusion.

How long does it take to build an MVP?

Usually weeks to a few months. Beyond that the scope is probably too wide: the goal is to learn fast, and an MVP that takes a year learns nothing before the market has moved.

Can a POC be turned into a product?

Almost never directly. A POC is built without tests, security, error handling or monitoring. Promoting it to production means inheriting all of those gaps at once — the most frequent failure mode of AI projects.

Let's talk about your project

A product idea and no engineering team to build it? That is exactly what we do — and on some products we put capital alongside the code. Tell us about it.

MVP, POC,
prototype.