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 n'a pas mal travaillé. Il a simplement atteint le premier client beaucoup plus vite que prévu. Le prototype a validé l'idée, mais personne n'a encore décidé 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.

C'est aussi le rôle d'un MVP : réduire le risque avant d'investir davantage. Vous pouvez confronter votre 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 apparaissaient simplement pendant le développement, parce que construire prenait du temps et mobilisait plusieurs personnes. La vitesse a supprimé cette période de friction. C'est une bonne nouvelle pour tester une idée, mais un piège si vous interprétez une démo fluide comme une preuve de fiabilité.

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

Imaginez que votre premier prospect B2B soit convaincu par la démonstration. Son équipe vous envoie ensuite un questionnaire de sécurité. Elle veut savoir où sont stockées les données, qui peut y accéder, comment elles sont sauvegardées et sous quel délai vous détectez 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.

Autre scénario : deux entreprises utilisent votre application. Une règle d'accès a été ajoutée 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 peut prendre une heure. La perte de confiance, elle, ne se corrige pas avec un nouveau déploiement.

Le coût peut aussi être plus discret. 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 alors le revenu de son abonnement. Vous avez vendu une fonctionnalité qui vous fait perdre de l'argent à chaque utilisation.

Dans ces trois situations, le problème n'est pas que le code a été généré par une IA. Une équipe classique peut faire les mêmes erreurs. La différence tient au calendrier : le produit a rencontré de vrais usages avant que ses règles économiques et opérationnelles soient explicites.

C'est pour cela qu'une revue avant production ne doit pas commencer par la beauté du code. Elle doit commencer par les conséquences possibles pour le client, la vente et la continuité du produit.

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 l'empiler sous des corrections fragiles.

La décision ne dépend donc pas de la propreté apparente du code. Elle dépend de l'option qui réduit le plus vite le risque pour les clients et la roadmap. 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, puis à transformer cette base en produit fiable. Commencez par un audit avant d'exposer vos premiers clients aux limites du prototype.