Le scénario revient sur mon bureau presque chaque semaine. Quelqu'un a construit une application avec Lovable, Bolt ou v0 en un week-end. La démo était bluffante, les premiers utilisateurs enthousiastes. Puis, un matin, le déploiement échoue. Ou la base de données renvoie des erreurs incompréhensibles. Ou l'IA, sollicitée pour corriger un bug, en crée trois autres. Et la personne m'écrit : « j'ai créé une app avec Bolt et je suis bloqué, vous pouvez la finir ? »
Ma réponse est franche : je ne finis pas le code généré par d'autres ou par l'IA. Et « finir » n'est de toute façon presque jamais le bon mot : il manque le plus souvent des fondations qui n'ont jamais été posées. Ce que je propose, c'est de reconstruire le produit proprement, de zéro, en me servant de votre prototype comme cahier des charges. Je développe des applications web et mobiles depuis des années, et j'ai vu suffisamment de projets générés par IA pour reconnaître les schémas. Dans cet article, je vous explique pourquoi ces outils cassent, ce que vous pouvez faire vous-même, et comment décider entre sauver l'existant et reconstruire proprement.
L'essentiel en trois phrases
Le prototype tient, mais ce n'est pas prêt pour la production. Lovable, Bolt et v0 vous amènent vite à 80 % d'une démo séduisante, puis butent sur les 20 % qui font la différence : sécurité, base de données fiable, paiements, conformité RGPD et CNIL.
L'IA recasse parce qu'elle perd le contexte. Plus le code grossit, plus elle corrige à l'aveugle. Chaque « fix » ajoute de la dette technique.
Avant de paniquer, sauvegardez votre projet et notez votre intention. C'est la base pour décider s'il faut corriger l'existant ou reconstruire — et à quel coût.
Pourquoi l'IA vous amène à 80 % puis s'arrête
Ces outils sont remarquables pour ce qu'ils font : transformer une phrase en interface fonctionnelle en quelques minutes. C'est réel, ce n'est pas de la magie marketing. Le problème n'est pas la qualité du départ — c'est la nature même des 20 % restants.
Les 80 % faciles, ce sont les écrans, les boutons, la mise en page, un formulaire qui s'affiche. Les 20 % difficiles, ce sont les choses invisibles qui font qu'une application tient en conditions réelles : que se passe-t-il quand deux utilisateurs modifient la même donnée en même temps ? Que devient un paiement interrompu ? Comment se comporte l'application quand la base de données est lente, quand un champ est vide, quand quelqu'un essaie de contourner un contrôle ? L'IA ne se pose pas ces questions toute seule, parce que vous ne les avez pas posées — et que personne, dans un prompt, ne pense à tout cela.
C'est exactement le mur dont je parle dans mon article sur le vibe coding : du prototype IA au vrai produit. Le prototype prouve une idée. Le produit, lui, doit survivre au monde réel, aux utilisateurs imprévisibles et — en France — au cadre légal.
Où ça casse, outil par outil
Chaque outil a ses points de rupture caractéristiques. Les connaître aide à comprendre pourquoi votre projet bloque là où il bloque.
Lovable — le déploiement et la base de données
Lovable va loin : il branche souvent une vraie base de données (via Supabase) et gère l'authentification. C'est ce qui le rend impressionnant. Mais c'est aussi là que ça coince. Les règles de sécurité de la base (les fameuses Row Level Security) sont souvent mal configurées — vos données peuvent être lisibles par n'importe qui. Le déploiement échoue dès que le projet sort du cadre prévu. Et quand vous ajoutez des fonctionnalités, la structure de données devient incohérente. Le symptôme typique : « mon app Lovable ne marche plus » après une série de modifications qui semblaient anodines.
Bolt — l'état de l'application et les intégrations
Bolt (Bolt.new) excelle pour générer une interface React vivante. Son talon d'Achille, c'est la gestion de l'état (le state) : à mesure que l'application grandit, la façon dont les données circulent entre les écrans devient fragile, et des bugs surgissent sans logique apparente. Les intégrations externes — un paiement Stripe, un envoi d'e-mail, une connexion à un service tiers — sont souvent ébauchées mais jamais réellement finalisées ni sécurisées. La démo marche ; le branchement réel, non.
v0 — une belle interface, mais un back-end à vérifier
v0 (de Vercel) est honnête sur sa mission : il génère des interfaces. Et il le fait magnifiquement. Le malentendu vient de l'utilisateur qui croit avoir une application alors qu'il a une coquille. Il peut aussi générer base de données, authentification et logique serveur, mais c'est le front-end qu'il fait le mieux : tout le back-end — la moitié invisible et la plus coûteuse du travail — reste à vérifier et à sécuriser.
Cursor — il génère, mais c'est vous qui devez comprendre
Cursor est différent : c'est un éditeur de code assisté par IA, pensé pour les développeurs. Il produit du code de bonne qualité, rapidement. Mais il part du principe que vous savez lire et structurer ce code. Entre les mains de quelqu'un qui ne programme pas, Cursor accumule des centaines de lignes que personne ne maîtrise vraiment. Tant que tout va bien, c'est invisible. Le jour où il faut diagnostiquer un bug profond, le projet est devenu une boîte noire.
Le point commun de tous ces blocages
Aucun de ces outils ne pense, par défaut, à la sécurité, à la robustesse ni à la conformité légale. Une app « vibe codée » n'a presque jamais de mentions légales conformes, de bandeau cookies aux normes CNIL, ni d'hébergement maîtrisé. En France, ce n'est pas un détail : c'est ce qui sépare un jouet d'un produit que vous pouvez mettre entre les mains de vrais clients.
Pourquoi l'IA « répare » puis recasse
C'est la frustration numéro un que l'on me décrit. Vous signalez un bug, l'IA propose une correction, ça marche cinq minutes — puis autre chose casse. Vous corrigez ça, et le premier bug revient. On tourne en rond.
La raison est technique mais simple à comprendre : l'IA travaille avec une fenêtre de contexte limitée. Au début de votre projet, elle voit tout. Quand le code atteint des milliers de lignes réparties sur des dizaines de fichiers, elle ne peut plus tout garder en tête. Elle corrige donc un endroit en ignorant qu'ailleurs, du code en dépend. Sans architecture pensée en amont, sans tests automatisés pour signaler les régressions, et sans une vision d'ensemble que seul un humain expérimenté maintient, chaque correction devient un coup de dés.
C'est ce qu'on appelle la dette technique. Au début elle est invisible. Puis elle s'accumule jusqu'au point où ajouter la moindre fonctionnalité casse trois choses. Un développeur ne se contente pas de corriger le bug du jour : il comprend la cause, restructure ce qui doit l'être, et empêche le bug de revenir. C'est cette continuité que l'IA, par construction, ne peut pas offrir.
Ce qu'il faut préparer avant de demander de l'aide
Si vous décidez de faire corriger le code existant — par la personne qui l'a construit ou par un autre développeur —, plus votre dossier est clair, plus son diagnostic sera rapide et son devis précis. Voici ce qui fait gagner du temps — et donc de l'argent — à tout le monde.
Votre kit de préparation en trois points
- L'accès au code. Exportez votre projet depuis Lovable ou Bolt vers un dépôt GitHub, ou partagez le lien du dépôt existant. C'est la chose la plus importante : sans le code, on ne peut rien auditer.
- Votre intention, écrite simplement. Que doit faire l'application, pour qui, et quel problème résout-elle ? Une page suffit. C'est ce qui permet de juger si le code existant sert vraiment cet objectif — et, pour une reconstruction, c'est la base du cahier des charges.
- La liste de ce qui ne marche pas. Des exemples concrets, des captures d'écran, les messages d'erreur. « Le paiement échoue quand je teste avec une carte » vaut mille fois mieux que « ça bug ».
Si vous avez déjà des comptes (base de données Supabase, hébergement, compte de paiement), notez-les. On évitera d'en recréer inutilement.
Ce travail de préparation, vous le faites une fois et il vous sert quel que soit le prestataire choisi. C'est aussi le réflexe sain du marché français : un dossier clair, qui permet de comparer plusieurs devis sur la même base. Si vous optez pour une reconstruction propre avec moi, seuls le deuxième point et un lien vers votre prototype sont nécessaires : je ne reprends pas le code, l'accès au dépôt n'est donc pas requis.
Sauver ou reconstruire ?
La question qui compte vraiment. Et la réponse honnête dépend de la profondeur des problèmes, pas d'un dogme. Voici comment trancher.
| Situation | On sauve l'existant | On reconstruit proprement |
|---|---|---|
| Interface (UI) | Belle et cohérente : on la garde | Incohérente, dupliquée : à refaire |
| Base de données | Structure logique, juste à sécuriser | Aucune structure ni règle de sécurité |
| Authentification | Présente, à durcir | Inexistante ou factice |
| Paiements / intégrations | Esquisses à finaliser | Aucune, ou clés exposées |
| Conformité RGPD | Manquante mais ajoutable | Architecture qui ignore la donnée |
| Coût prévisible | Reprise ciblée, plus économique | Repartir sur des bases saines |
Le bon réflexe : décider sur des faits
Ne devinez pas. Si vous envisagez de sauver l'existant, faites examiner l'architecture, la base de données, l'authentification, les paiements et la conformité par la personne qui a construit le projet ou par un développeur de confiance, avant d'investir davantage. Pour ma part, je ne fais pas ce diagnostic et je ne reprends pas de code généré : je reconstruis le produit proprement, de zéro, en me servant de votre prototype comme cahier des charges — sans hériter de ses failles cachées.
Quel outil pour quel usage — et où est sa limite
Pour être juste : ces outils ont leur place. Le problème n'est pas de les utiliser, c'est de croire qu'ils livrent un produit fini. Voici comment je les situe.
| Outil | Ce qu'il fait bien | Sa limite | Bon pour |
|---|---|---|---|
| Lovable | App complète avec base + auth | Sécurité et déploiement fragiles | MVP à valider vite |
| Bolt | Interfaces React dynamiques | État et intégrations instables | Prototype interactif |
| v0 | Interfaces très soignées | Back-end à vérifier et sécuriser | Maquette front-end |
| Cursor | Code rapide et de qualité | Exige de savoir coder | Développeurs expérimentés |
Mon avis ? Je connais bien ces outils : ils accélèrent le travail quand on sait déjà ce qu'on fait. Ils ne remplacent pas l'ingénierie ; ils la rendent plus rapide entre les mains de quelqu'un qui sait relire, sécuriser et structurer. La différence entre un prototype et une application production-ready reste un travail de métier.
La conformité RGPD : l'angle mort le plus dangereux en France
C'est le point que les outils IA ignorent totalement, et c'est précisément celui qui peut vous coûter le plus cher en France. Une application qui collecte des données — donc presque toutes — doit respecter le RGPD et les recommandations de la CNIL. Or une app « vibe codée » ne respecte quasiment jamais ces obligations.
Ce qui manque presque toujours dans un projet IA
- Mentions légales conformes : identité de l'éditeur, SIREN/SIRET, hébergeur, et DPO si applicable.
- Bandeau cookies aux normes CNIL : consentement explicite, avec un refus aussi simple que l'acceptation. Un simple « OK » ne suffit pas.
- Registre des traitements et base légale claire pour chaque donnée collectée.
- Hébergement maîtrisé : idéalement dans l'Union européenne, avec des acteurs français comme OVHcloud, Scaleway ou Clever Cloud — un vrai argument de souveraineté, surtout dans la santé ou le secteur public.
- Sécurité réelle des données : règles d'accès, chiffrement, clés d'API jamais exposées côté client.
Mettre une application en production sans ces garde-fous, c'est s'exposer à une plainte, à un contrôle CNIL, et à la perte de confiance de vos clients. C'est pour moi un passage obligé de tout projet que je construis : un produit sérieux est aussi un produit conforme.
Les fourchettes de prix, sans langue de bois
Parlons argent clairement, en TJM et en forfaits, avec les conventions du marché français. Tous les montants sont indiqués HT.
Le TJM d'un développeur freelance senior en France se situe en 2026 entre 700 et 1 200 € selon la spécialité (React, Next.js, mobile, IA), avec une médiane tech autour de 500 à 550 €. Je ne propose ni audit, ni stabilisation, ni finalisation de code généré par IA : je reconstruis le produit proprement, de zéro, à partir de votre prototype, au forfait. Les intégrations locales (CB, FranceConnect, Factur-X, logistique) sont incluses dans le périmètre, le plus souvent au palier application métier :
| Prestation | Format | Prix (HT) |
|---|---|---|
| MVP / PWA (iOS et Android, une seule base de code) | Forfait | à partir de 2 900 € |
| Application métier (paiements, comptes, intégrations locales) | Forfait | à partir de 6 900 € |
| Plateforme complexe sur mesure | Forfait | à partir de 14 900 € |
Je positionne toujours une reconstruction propre comme un investissement face à la dette technique, jamais comme une solution low-cost. Investir dans une application réellement en production, sécurisée et conforme, c'est moins cher que de raccommoder pendant un an une base instable qui finira de toute façon par être reconstruite. Le réflexe français des trois devis est sain : demandez-les, mais comparez ce qui est comparable. Un devis qui ignore la sécurité et le RGPD n'est pas moins cher, il est incomplet. Je travaille toujours avec un devis détaillé signé, des CGV et une facture conforme.
Si vous hésitez encore entre garder votre outil no-code et passer à une vraie application, mon article sur le coût réel d'un site « gratuit » fait avec l'IA chiffre précisément ce que ces solutions coûtent vraiment une fois en production. Et si vous partez de zéro, je détaille mon approche dans la rubrique développement d'applications sur mesure.
Votre projet IA a cassé ? Reconstruisons-le proprement.
Je ne répare pas le code généré : votre prototype devient le cahier des charges, je conserve les écrans et les parcours, et je construis en dessous, de zéro, des fondations solides — base de données, authentification, paiements, RGPD et déploiement. MVP à partir de 2 900 € HT. Décrivez-moi ce que l'app doit faire : sous 24 heures, vous recevez un devis détaillé, sans engagement.
Recevoir un devisQuestions fréquemment posées (FAQ)
En résumé
Lovable, Bolt, v0 et Cursor sont d'excellents outils pour prouver une idée. Mais un prototype séduisant n'est pas un produit, et le mur des 20 % restants — sécurité, base de données, paiements, RGPD — ne se franchit pas avec un prompt de plus. Quand l'IA tourne en rond et recasse ce qu'elle vient de réparer, c'est le signal qu'il faut une vraie continuité d'ingénierie.
Si votre application a cessé de fonctionner, ne perdez pas vos nuits à relancer l'IA. Écrivez en une page ce que l'app doit faire, gardez votre prototype comme référence — puis parlons-en. Je ne reprendrai pas le code cassé : je reconstruirai le produit proprement, de zéro, et vous repartirez avec une application réellement en production, sécurisée et conforme au cadre français. C'est tout ce qui sépare « j'ai bricolé un truc avec l'IA » de « j'ai un produit que je peux confier à mes clients ».