MVP vibe-coded : passer en prod

Le vibe coding n'a pas créé de nouveaux risques techniques. Il a supprimé le délai qui vous obligeait à les regarder. Avant, six semaines séparaient une idée de sa première version. Un développeur finissait par poser les questions de sécurité, de données ou de coût. Aujourd'hui, votre MVP fonctionne en quatre jours. Il est assez convaincant pour être vendu avant que quelqu'un se demande s'il peut vraiment tenir en production.

Dans les reprises de produits, je retrouve souvent ce décalage. Le fondateur a atteint son premier client plus vite que prévu, et c'était bien le but. Seulement, le prototype a validé l'idée avant que quelqu'un décide s'il fallait garder sa base, la reprendre ou la refaire.

Le vibe coding a supprimé le délai de réflexion

Lovable, Bolt, Cursor ou Claude Code permettent de tester une intuition sans engager immédiatement une équipe complète. Vous décrivez un parcours, l'outil assemble les écrans et vous obtenez une version montrable. Pour un fondateur, cette vitesse change la manière de lancer un produit.

Un MVP sert précisément à réduire le risque avant d'investir davantage. Vous confrontez l'idée au marché avant de passer des mois sur une architecture dont personne ne veut.

Le problème commence après la validation. Le prototype ressemble déjà au produit final. L'inscription fonctionne, les données apparaissent dans un tableau de bord et le paiement passe en environnement de test. Rien dans l'interface ne signale les décisions qui n'ont pas encore été prises.

Qui peut consulter quelles données ? Que se passe-t-il si un paiement est envoyé deux fois ? Combien coûte réellement chaque requête à un modèle d'IA ? Comment restaurer les informations d'un client après une mauvaise manipulation ?

Ces questions existaient avant le vibe coding. Elles remontaient pendant le développement, car construire prenait du temps et mobilisait plusieurs personnes. Cette friction a presque disparu. Tant mieux pour tester une idée. Mais une démo fluide ne prouve toujours pas que le produit est fiable.

Un prototype réussi répond à « est-ce que quelqu'un veut ce produit ? ». La production pose une autre question : « pouvons-nous le vendre sans exposer nos clients et notre entreprise ? ».

Ce que cette vitesse peut coûter à votre entreprise

Votre premier prospect B2B est convaincu par la démonstration. Puis son équipe vous envoie un questionnaire de sécurité : où sont stockées les données, qui peut y accéder, comment sont-elles sauvegardées et sous quel délai détectez-vous un incident ?

Si personne ne peut répondre clairement, le deal ralentit. Le prospect ne voit pas un prototype prometteur. Il voit un fournisseur incapable d'expliquer comment son produit protège les informations qu'on va lui confier. La vente peut s'arrêter sans qu'aucun bug ne soit apparu.

Deux entreprises utilisent maintenant votre application. Une règle d'accès existe dans l'écran, mais pas dans le système qui fournit les données. Un utilisateur modifie un identifiant dans l'URL et consulte le document d'un autre client. La correction technique prend peut-être une heure. La confiance perdue ne revient pas au déploiement suivant.

Parfois, rien ne casse. Votre fonctionnalité IA consomme quelques centimes pendant les tests. Après le lancement, un client importe des centaines de documents ou relance dix fois la même opération. La facture du fournisseur dépasse le revenu de son abonnement. Chaque utilisation vous fait perdre de l'argent, alors que le client est satisfait.

Une équipe classique peut commettre exactement les mêmes erreurs. Le vibe coding change surtout le calendrier : le produit rencontre de vrais usages avant que ses règles économiques et opérationnelles soient explicites.

Une revue avant production commence donc par les conséquences possibles pour le client, la vente et la continuité du produit. La beauté du code vient après.

Garder, reprendre ou refaire : comment décider

Vous n'avez pas besoin de comprendre chaque fichier pour prendre la bonne décision. Vous devez obtenir des réponses nettes à quelques questions de dirigeant.

Un client peut-il voir ou modifier les données d'un autre ? La réponse doit être démontrée, pas supposée parce que le bouton est caché. Si l'isolation dépend de règles dispersées et impossibles à vérifier, le risque doit être traité avant les premières données sensibles.

Quelqu'un a-t-il déjà restauré une sauvegarde ? Voir le mot « sauvegarde » dans un tableau de bord ne prouve pas que votre produit peut repartir après une erreur. Une restauration testée permet de savoir ce qui serait réellement perdu et combien de temps l'interruption durerait.

Sauriez-vous qu'un incident a lieu avant qu'un client vous écrive ? Si la seule alerte est un message reçu le lundi matin, vous exploitez le produit à l'aveugle. Il faut pouvoir repérer les erreurs importantes et identifier les utilisateurs touchés sans transformer le client en technicien support.

Les réponses déterminent la suite.

Gardez la base actuelle si les parcours principaux fonctionnent, si les risques critiques peuvent être corrigés rapidement et si une personne expérimentée peut expliquer comment le produit est construit. Un code imparfait mais compréhensible vaut souvent mieux qu'une réécriture de six mois.

Reprenez progressivement les zones qui menacent la vente ou la confiance. Les accès, les paiements ou la consommation des services d'IA peuvent être sécurisés sans reconstruire tous les écrans. Chaque chantier doit réduire un risque identifiable ou débloquer un usage attendu par les clients.

Refaites une fondation lorsque sa conception contredit le produit que vous vendez. Une application pensée pour un seul utilisateur peut nécessiter une nouvelle organisation des données avant d'accueillir plusieurs entreprises. Si le prototype est encore petit et ne contient pas de données clients, refaire cette partie peut coûter moins cher que d'empiler des corrections fragiles par-dessus.

Choisissez l'option qui réduit le plus vite le risque pour les clients et la roadmap. La propreté apparente du code dit peu de choses à ce stade. L'audit doit trancher ce qui se garde, ce qui se reprend et ce qui doit être refait, avec un ordre et un coût visibles.

Ce qu'il faut retenir

• Le vibe coding accélère la validation, mais il supprime aussi le temps pendant lequel les décisions techniques devenaient explicites.
• Un code imparfait est moins dangereux qu'une vente, des données clients ou une marge exposées trop tôt.
• Un fondateur doit demander des preuves sur l'isolation des données, la restauration et la détection des incidents.
• Garder, reprendre ou refaire se décide selon le risque business, jamais selon une préférence technique.

Questions fréquentes

Peut-on mettre en production un produit créé avec Lovable ou Cursor ?

Oui, si ses risques ont été identifiés et traités avant d'accueillir des données ou des paiements réels. Une personne expérimentée doit pouvoir expliquer les règles importantes, modifier un parcours sans casser les autres et déployer le produit de manière reproductible.

Faut-il réécrire un MVP vibe-coded avant de le vendre ?

Pas systématiquement. Si la base est compréhensible et que les risques critiques peuvent être corrigés sans tout reconstruire, une reprise ciblée sera plus rapide. La réécriture se justifie lorsqu'une fondation empêche le produit de servir ses clients en sécurité.

Quand faut-il faire auditer son prototype ?

Faites-le avant d'héberger des données sensibles, d'activer les paiements ou de signer un client B2B exigeant. L'audit est particulièrement utile lorsque vous ne savez pas distinguer un défaut gênant d'un risque capable de bloquer une vente.

Conclusion

Avant les premiers clients, faites trancher ce que vous pouvez déjà confier au produit et ce qui doit encore être sécurisé.

Si vous avez construit un prototype avec Lovable, Bolt, Cursor ou Claude Code, TechSprint vous aide à déterminer ce qu'il faut garder, reprendre ou refaire. L'audit fixe les priorités avant que le produit accueille les données de vos premiers clients.