« Il nous faut un MVP pour demain. »

La phrase revient souvent. Un investisseur veut une démo, un prospect attend un lien, un associé veut voir quelque chose fonctionner. Dans ce contexte, sortir une première version en quelques jours peut être une bonne décision.

Mais il faut appeler cette version par son vrai nom : un prototype. Elle sert à apprendre. Elle ne garantit pas que le produit est prêt pour des clients, des paiements ou des données personnelles.

J'ai longtemps travaillé sur des formats de sprint très courts. Ce que j'en retiens est simple : la vitesse est utile quand elle réduit une incertitude précise. Elle devient dangereuse quand elle donne l'impression que toutes les questions sont réglées.

Ce qu'un prototype rapide doit valider

Un bon prototype vous aide à répondre à des questions produit que vous ne pouvez pas résoudre dans un document.

Les utilisateurs comprennent-ils le problème ?

Une interface peut sembler évidente pour la personne qui l'a imaginée et rester incompréhensible pour quelqu'un qui la découvre. Un prototype permet de regarder les hésitations, les contournements et les questions qui reviennent.

Le parcours principal tient-il debout ?

Vous pouvez tester le chemin le plus important : créer un compte, effectuer une action, obtenir un résultat. Ce parcours ne couvrira pas tous les cas limites, mais il montre déjà si l'idée a une forme utilisable.

Quel retour mérite une nouvelle itération ?

Le prototype donne une matière concrète aux discussions. Un utilisateur peut montrer l'écran où il bloque. Une équipe peut discuter d'un flux réel plutôt que de débattre d'une intention abstraite.

Ce sont de bonnes raisons de prototyper vite. Elles ne nécessitent pas de construire toute l'infrastructure d'un produit mature.

Ce que six jours ne prouvent pas

Une version visible ne permet pas de conclure que l'application est prête pour une utilisation réelle.

Lovable présente lui-même le prototype comme une étape de validation avant transfert aux ingénieurs. Sa documentation sur le passage du prototype au code de production cite notamment l’ajout de la logique backend, des tests et du déploiement après la synchronisation GitHub. La vitesse de la première version et la préparation à la production correspondent donc à deux travaux différents.

Il reste notamment à vérifier :

qui peut accéder à chaque donnée et à chaque action ;
ce qui se passe quand un service externe répond mal ;
comment restaurer les données après une erreur ;
si le déploiement peut être reproduit par quelqu'un d'autre ;
comment gérer les paiements et les événements reçus plusieurs fois ;
quelles parties sont couvertes par des tests ;
qui pourra reprendre le code dans quelques mois.

Ces sujets ne sont pas toujours nécessaires au premier test utilisateur. Ils le deviennent dès qu'une personne dépend du produit ou qu'une erreur a un coût réel.

Pour les accès, l’OWASP recommande de vérifier l’autorisation sur chaque requête et chaque objet. Une connexion fonctionnelle ne démontre pas, à elle seule, qu’un client ne peut pas atteindre les données d’un autre.

Un sprint court n'est pas une promesse de production

Le chiffre six est pratique pour parler d'un format. Il ne décrit pas la complexité de votre application.

Un parcours de formulaire simple et une application multi-utilisateur avec paiements n'ont pas le même périmètre. Deux apps avec le même nombre d'écrans peuvent aussi avoir des risques très différents selon les données, les intégrations et les permissions.

Le délai doit donc servir à cadrer une hypothèse, pas à masquer ce qui reste à décider. Si le produit est destiné à une première démonstration privée, vous pouvez accepter davantage de travail manuel. Si vous ouvrez l'accès à des clients, la barre change.

Le bon enchaînement après le prototype

Une fois la première version en ligne, ne partez pas directement dans une longue liste de fonctionnalités. Faites d'abord trois choses.

Mettez le parcours devant quelques personnes

Choisissez des utilisateurs qui correspondent au problème visé. Regardez ce qu'ils font réellement. Les retours d'une personne qui connaît déjà toutes vos intentions ne valent pas ceux d'une personne qui découvre l'app.

Notez ce qui bloque vraiment

Séparez les problèmes de compréhension, les besoins métier et les problèmes techniques. Un écran mal compris ne se corrige pas forcément avec du code. Un paiement qui échoue à cause d'un webhook ne se corrige pas avec une nouvelle couleur de bouton.

Décidez si le prototype a atteint sa frontière

Vous approchez de cette frontière quand plusieurs de ces situations apparaissent :

un premier client attend une version utilisable ;
l'app traite des informations personnelles ou des paiements ;
chaque correction casse une autre partie ;
vous ne savez plus expliquer les règles métier importantes ;
une échéance commerciale approche ;
vous envisagez d'ajouter des utilisateurs sans savoir comment surveiller les erreurs.

À ce moment, le sujet n'est plus de sortir un écran de plus. Il faut savoir ce qui tient déjà.

Quand continuer à prototyper

Continuez avec Lovable, Bolt, Claude Code ou un autre outil si vous êtes encore en train de vérifier l'idée, que personne ne dépend du produit et qu'aucune donnée sensible n'est en jeu.

Vous n'avez pas besoin de payer une reprise pour une hypothèse qui n'a pas encore rencontré d'utilisateur. Dans cette phase, votre argent sert davantage à obtenir du signal qu'à préparer une architecture complète.

La réponse honnête peut être de ne pas faire appel à un développeur maintenant. C'est aussi une manière de protéger votre budget.

Quand demander un audit

L'audit devient pertinent quand vous avez déjà un prototype et que le coût d'une erreur dépasse celui d'un diagnostic.

Vous n'avez pas forcément besoin d'un chantier complet. Vous avez besoin de savoir si le code peut servir de base, quelles zones doivent être reprises et combien la suite va coûter.

Chez TechSprint, l'audit prend une semaine et coûte 2k€. Il produit un état des lieux du code, de la sécurité et de l'hébergement, une liste priorisée des risques, un verdict garder / reprendre / refaire et un chiffrage de la suite.

Le rapport reste utilisable même si vous confiez les travaux à quelqu'un d'autre. C'est important : un diagnostic n'a de valeur que s'il peut vous aider à décider librement.

Ce que je ne vends plus

Je ne propose plus de construire un MVP générique à partir d'une idée chez TechSprint. Dans la plupart des cas, il est plus raisonnable de commencer par un prototype autonome, de le confronter au marché, puis de demander de l'aide quand il rencontre ses premières limites.

Mon intervention commence plutôt au moment suivant : le prototype fonctionne en démo, mais vous devez l'ouvrir à de vrais utilisateurs, des paiements ou des données personnelles.

Pour comprendre cette frontière, lisez aussi Mon prototype Lovable fonctionne. Est-il prêt pour la production ?.

Si vous êtes précisément dans ce moment-là, la page passer un prototype IA en production détaille ce qui doit changer entre une V0 qui impressionne et un produit qui peut accueillir de vrais clients.

Si votre prototype existe déjà et que vous ne savez pas s'il faut continuer, corriger ou reprendre, réservez un appel de 30 minutes. On regardera le contexte avant de parler de chantier.

Fabrice Payet — fondateur de TechSprint, La Réunion.

Un prototype en 6 jours : ce que ça valide, et ce que ça ne garantit pas