En résumé : le vibe coding est excellent pour valider une idée et très insuffisant pour exploiter un produit. Un prototype généré par IA démontre qu'un parcours est possible. Un produit en production doit en plus être sécurisé, testé, observable, maintenable et capable d'encaisser des cas que personne n'a prévus. L'écart entre les deux se comble avec un audit, un tri entre ce qui se garde et ce qui se réécrit, puis quelques semaines de consolidation ciblée.
De plus en plus de fondateurs arrivent avec une application qui fonctionne déjà, construite en quelques soirées avec Lovable, Bolt, v0, Cursor ou Claude Code. C'est une très bonne nouvelle : l'idée est concrète, testable, et souvent déjà montrée à des utilisateurs. La question devient alors : que faut-il faire avant d'y brancher de vrais clients et de vrais paiements ?
Ce qu'est le vibe coding
Le terme désigne une façon de développer où l'on décrit ce que l'on veut en langage naturel, et où un modèle d'IA écrit le code. On juge le résultat à l'écran plutôt qu'en lisant le code, et on itère par instructions successives.
Deux familles d'outils coexistent :
- Les générateurs d'applications (Lovable, Bolt, v0, Replit) : pensés pour les non-développeurs, ils produisent une application complète et l'hébergent.
- Les assistants de programmation (Cursor, Claude Code, GitHub Copilot) : pensés pour les développeurs, ils travaillent dans une base de code existante.
Les seconds sont aujourd'hui utilisés quotidiennement par des équipes professionnelles, la nôtre comprise. La différence ne tient pas à l'outil, mais à qui relit, comprend et assume le code produit.
Ce que le vibe coding fait très bien
- Valider une idée en quelques jours au lieu de quelques semaines.
- Montrer plutôt qu'expliquer. Un prototype cliquable vaut mieux que n'importe quel cahier des charges pour aligner une équipe ou convaincre un investisseur.
- Créer des outils internes à faible enjeu : tableaux de bord, scripts, petits utilitaires.
- Explorer plusieurs pistes de design ou de parcours avant de s'engager.
Pour toutes ces situations, c'est un progrès considérable, et il serait absurde de s'en priver.
Là où les prototypes générés cassent
Les mêmes faiblesses reviennent dans presque toutes les applications générées que l'on nous demande de reprendre.
La sécurité
C'est le problème le plus grave et le moins visible. Clés d'API exposées dans le code du navigateur, base de données accessible sans règles de contrôle d'accès, absence de vérification des droits côté serveur : l'application fonctionne parfaitement en démonstration, et n'importe quel utilisateur un peu curieux peut lire les données des autres.
Le modèle de données
Les modèles génèrent un schéma qui répond à la demande du moment. Dix itérations plus tard, on obtient des tables redondantes, des relations incohérentes et aucune stratégie de migration. C'est la partie la plus coûteuse à corriger une fois que des données réelles existent.
Les cas d'erreur
Le parcours nominal fonctionne. Que se passe-t-il si le paiement échoue à mi-chemin, si le réseau coupe, si deux personnes modifient la même donnée, si un champ est vide ? Généralement, rien de prévu.
L'absence de tests et de suivi
Sans tests automatisés, chaque nouvelle instruction donnée à l'IA peut casser une fonctionnalité existante sans que personne ne le remarque. Sans journalisation ni alertes, vous apprenez les pannes par vos clients.
La cohérence du code
Trois manières différentes de faire la même chose, du code mort, des dépendances inutiles. L'application marche, mais chaque évolution devient plus lente et plus risquée, pour un humain comme pour une IA.
Les coûts à l'usage
Requêtes non optimisées, appels à des modèles d'IA sans limite ni cache : la facture reste invisible avec dix utilisateurs et devient un problème avec mille.
La liste de contrôle avant la mise en production
| Domaine | À vérifier |
|---|---|
| Sécurité | Aucun secret côté navigateur, contrôle des droits côté serveur, règles d'accès à la base, limitation du nombre de requêtes |
| Données | Schéma revu, migrations versionnées, sauvegardes automatiques testées |
| Authentification | Gestion des sessions, réinitialisation de mot de passe, rôles et permissions |
| Paiement | Webhooks vérifiés, gestion des échecs et des remboursements |
| Qualité | Tests sur les parcours critiques, intégration continue, revue de code |
| Exploitation | Journalisation, suivi des erreurs, alertes, environnements de test et de production séparés |
| Conformité | RGPD, mentions légales, consentement, localisation des données |
| Performance | Temps de chargement, requêtes optimisées, maîtrise des coûts d'infrastructure |
Si vous ne pouvez pas répondre avec certitude à ces points, l'application n'est pas prête à recevoir des données de clients.
Reprendre ou réécrire ?
C'est la question que tout le monde pose, et la réponse n'est presque jamais « tout jeter ».
À conserver en général : l'interface et les parcours, qui ont été validés auprès d'utilisateurs ; la connaissance produit accumulée ; souvent la stack elle-même, car ces outils génèrent des technologies standard comme React, TypeScript et des bases PostgreSQL.
À reprendre en général : le modèle de données, l'authentification et les droits, tout ce qui touche au paiement, et la structure du projet.
La bonne démarche se déroule en trois temps :
- Un audit technique d'une à deux semaines, qui produit une liste priorisée des risques. Voir notre offre d'audit technique.
- Une consolidation ciblée des fondations : sécurité, données, tests sur les parcours critiques, mise en place de l'exploitation.
- Une reprise de la roadmap, avec une méthode qui empêche la dette de se reformer.
Sur un prototype de taille raisonnable, la consolidation prend généralement entre trois et huit semaines. C'est nettement moins qu'un développement depuis zéro, parce que le plus difficile, savoir quoi construire, est déjà fait.
Continuer à utiliser l'IA, mais autrement
Passer en production ne signifie pas abandonner l'IA. Cela signifie l'encadrer :
- Chaque modification passe par une revue de code faite par quelqu'un qui comprend ce qu'il lit.
- Les tests automatisés servent de garde-fou : l'IA peut proposer, les tests vérifient qu'elle n'a rien cassé.
- Les conventions du projet sont écrites et fournies aux outils d'IA, pour que le code généré reste cohérent.
- Les tâches sont petites et bien délimitées, plutôt qu'une instruction vague appliquée à toute l'application.
- Les décisions d'architecture restent humaines.
Utilisée ainsi, l'IA accélère réellement une équipe expérimentée. Utilisée sans cadre, elle accélère surtout l'accumulation de dette technique.
Questions fréquentes
Peut-on mettre en production une application créée avec Lovable ou Bolt ?
Oui, à condition de la faire auditer et consolider avant. Les points à traiter en priorité sont la sécurité des données, les règles d'accès à la base, le paiement et l'ajout de tests sur les parcours critiques.
Faut-il tout réécrire après un prototype en vibe coding ?
Rarement. L'interface et les parcours validés se conservent le plus souvent. Ce sont le modèle de données, l'authentification et la structure du code qui demandent généralement une reprise.
Combien coûte la reprise d'un prototype généré par IA ?
Cela dépend de la taille de l'application. Comptez une à deux semaines d'audit, puis trois à huit semaines de consolidation pour un prototype de taille raisonnable, soit un budget nettement inférieur à un développement complet.
Le vibe coding va-t-il remplacer les développeurs ?
Il change leur travail plus qu'il ne le supprime. Écrire du code devient moins coûteux ; décider quoi construire, garantir la sécurité, concevoir l'architecture et assumer la mise en production restent des responsabilités humaines.
Quels sont les risques d'une application générée par IA non auditée ?
Les principaux sont la fuite de données d'utilisateurs, l'exposition de clés d'API, des pertes de données faute de sauvegardes, et une application qui devient impossible à faire évoluer.
👉 Vous avez un prototype et vous voulez savoir ce qu'il vaut ? Découvrez notre accompagnement vibe coding et notre offre de reprise de projet, ou programmez un appel.