Le scenario revient sur mon bureau presque chaque semaine. Quelqu'un a construit une application avec Lovable, Bolt ou v0 en un week-end. La demo etait bluffante, les premiers utilisateurs enthousiastes. Puis, un matin, le deploiement echoue. Ou la base de donnees renvoie des erreurs incomprehensibles. Ou l'IA, sollicitee pour corriger un bug, en cree trois autres. Et la personne m'ecrit : « j'ai cree une app avec Bolt et je suis bloque, vous pouvez la finir ? »
La bonne nouvelle, c'est que dans la plupart des cas, oui. La mauvaise, c'est que « finir » n'est presque jamais le bon mot : il s'agit le plus souvent de consolider des fondations qui n'ont jamais ete posees. Je developpe des applications web et mobiles depuis des annees, et j'ai repris suffisamment de projets generes par IA pour reconnaitre les schemas. Dans cet article, je vous explique pourquoi ces outils cassent, ce que vous pouvez faire vous-meme avant de me contacter, et comment decider entre sauver l'existant et reconstruire proprement.
L'essentiel en trois phrases
Le prototype tient, mais ce n'est pas pret pour la production. Lovable, Bolt et v0 vous amenent vite a 80 % d'une demo seduisante, puis butent sur les 20 % qui font la difference : securite, base de donnees fiable, paiements, conformite RGPD et CNIL.
L'IA recasse parce qu'elle perd le contexte. Plus le code grossit, plus elle corrige a l'aveugle. Chaque « fix » ajoute de la dette technique.
Avant de paniquer, exportez votre code et notez votre intention. Un audit clair vous dira s'il faut reprendre ou reconstruire — et combien.
Pourquoi l'IA vous amene a 80 % puis s'arrete
Ces outils sont remarquables pour ce qu'ils font : transformer une phrase en interface fonctionnelle en quelques minutes. C'est reel, ce n'est pas de la magie marketing. Le probleme n'est pas la qualite du depart — c'est la nature meme des 20 % restants.
Les 80 % faciles, ce sont les ecrans, 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 reelles : que se passe-t-il quand deux utilisateurs modifient la meme donnee en meme temps ? Que devient un paiement interrompu ? Comment se comporte l'application quand la base de donnees est lente, quand un champ est vide, quand quelqu'un essaie de contourner un controle ? L'IA ne se pose pas ces questions toute seule, parce que vous ne les avez pas posees — et que personne, dans un prompt, ne pense a 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 idee. Le produit, lui, doit survivre au monde reel, aux utilisateurs imprevisibles et — en France — au cadre legal.
Ou ca casse, outil par outil
Chaque outil a ses points de rupture caracteristiques. Les connaitre aide a comprendre pourquoi votre projet bloque la ou il bloque.
Lovable — le deploiement et la base de donnees
Lovable va loin : il branche souvent une vraie base de donnees (via Supabase) et gere l'authentification. C'est ce qui le rend impressionnant. Mais c'est aussi la que ca coince. Les regles de securite de la base (les fameuses Row Level Security) sont souvent mal configurees — vos donnees peuvent etre lisibles par n'importe qui. Le deploiement echoue des que le projet sort du cadre prevu. Et quand vous ajoutez des fonctionnalites, la structure de donnees devient incoherente. Le symptome typique : « mon app Lovable ne marche plus » apres une serie de modifications qui semblaient anodines.
Bolt — l'etat de l'application et les integrations
Bolt (Bolt.new) excelle pour generer une interface React vivante. Son talon d'Achille, c'est la gestion de l'etat (le state) : a mesure que l'application grandit, la facon dont les donnees circulent entre les ecrans devient fragile, et des bugs surgissent sans logique apparente. Les integrations externes — un paiement Stripe, un envoi d'e-mail, une connexion a un service tiers — sont souvent ebauchees mais jamais reellement finalisees ni securisees. La demo marche ; le branchement reel, non.
v0 — une belle interface, mais pas de back-end
v0 (de Vercel) est honnete sur sa mission : il genere 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 n'y a pas de base de donnees, pas d'authentification reelle, pas de logique metier derriere les ecrans. C'est un excellent point de depart pour le front-end, mais tout le back-end — la moitie invisible et la plus couteuse du travail — reste a construire.
Cursor — il genere, mais c'est vous qui devez comprendre
Cursor est different : c'est un editeur de code assiste par IA, pense pour les developpeurs. Il produit du code de bonne qualite, 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 maitrise vraiment. Tant que tout va bien, c'est invisible. Le jour ou il faut diagnostiquer un bug profond, le projet est devenu une boite noire.
Le point commun de tous ces blocages
Aucun de ces outils ne pense, par defaut, a la securite, a la robustesse ni a la conformite legale. Une app « vibe codee » n'a presque jamais de mentions legales conformes, de bandeau cookies aux normes CNIL, ni d'hebergement maitrise. En France, ce n'est pas un detail : c'est ce qui separe un jouet d'un produit que vous pouvez mettre entre les mains de vrais clients.
Pourquoi l'IA « repare » puis recasse
C'est la frustration numero un que l'on me decrit. Vous signalez un bug, l'IA propose une correction, ca marche cinq minutes — puis autre chose casse. Vous corrigez ca, et le premier bug revient. On tourne en rond.
La raison est technique mais simple a comprendre : l'IA travaille avec une fenetre de contexte limitee. Au debut de votre projet, elle voit tout. Quand le code atteint des milliers de lignes reparties sur des dizaines de fichiers, elle ne peut plus tout garder en tete. Elle corrige donc un endroit en ignorant qu'ailleurs, du code en depend. Sans architecture pensee en amont, sans tests automatises pour signaler les regressions, et sans une vision d'ensemble que seul un humain expérimenté maintient, chaque correction devient un coup de des.
C'est ce qu'on appelle la dette technique. Au debut elle est invisible. Puis elle s'accumule jusqu'au point ou ajouter la moindre fonctionnalite casse trois choses. Un developpeur ne se contente pas de corriger le bug du jour : il comprend la cause, restructure ce qui doit l'etre, et empeche le bug de revenir. C'est cette continuite que l'IA, par construction, ne peut pas offrir.
Ce qu'il faut preparer avant de me contacter
Plus votre dossier est clair, plus mon audit est rapide et mon devis precis. Voici ce qui fait gagner du temps — et donc de l'argent — a tout le monde.
Votre kit de reprise en trois points
- L'acces au code. Exportez votre projet depuis Lovable ou Bolt vers un depot GitHub, ou partagez le lien du depot existant. C'est la chose la plus importante : sans le code, on ne peut rien auditer.
- Votre intention, ecrite simplement. Que doit faire l'application, pour qui, et quel probleme resout-elle ? Une page suffit. C'est ce qui me permet de juger si le code existant sert vraiment cet objectif.
- La liste de ce qui ne marche pas. Des exemples concrets, des captures d'ecran, les messages d'erreur. « Le paiement echoue quand je teste avec une carte » vaut mille fois mieux que « ca bug ».
Si vous avez deja des comptes (base de donnees Supabase, hebergement, compte de paiement), notez-les. On evitera d'en recreer inutilement.
Ce travail de preparation, vous le faites une fois et il vous sert quel que soit le prestataire choisi. C'est aussi le reflexe sain du marche francais : un dossier clair, qui permet de comparer plusieurs devis sur la meme base.
Sauver ou reconstruire ?
La question qui compte vraiment. Et la reponse honnete depend de la profondeur des problemes, pas d'un dogme. Voici comment je tranche.
| Situation | On sauve l'existant | On reconstruit proprement |
|---|---|---|
| Interface (UI) | Belle et coherente : on la garde | Incoherente, dupliquee : a refaire |
| Base de donnees | Structure logique, juste a securiser | Aucune structure ni regle de securite |
| Authentification | Presente, a durcir | Inexistante ou factice |
| Paiements / integrations | Esquisses a finaliser | Aucune, ou cles exposees |
| Conformite RGPD | Manquante mais ajoutable | Architecture qui ignore la donnee |
| Cout previsible | Reprise ciblee, plus economique | Repartir sur des bases saines |
Le bon reflexe : l'audit d'abord
Je ne devine pas — j'audite. Je recupere votre code, j'examine l'architecture, la base de donnees, l'authentification, les paiements et la conformite, puis je vous remets un diagnostic ecrit et structure. Vous savez alors precisement ce qui est recuperable, ce qui ne l'est pas, et le cout de chaque option. C'est ce document qui vous permet de decider en confiance, devis a l'appui.
Quel outil pour quel usage — et ou est sa limite
Pour etre juste : ces outils ont leur place. Le probleme 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 complete avec base + auth | Securite et deploiement fragiles | MVP a valider vite |
| Bolt | Interfaces React dynamiques | Etat et integrations instables | Prototype interactif |
| v0 | Interfaces tres soignees | Aucun back-end | Maquette front-end |
| Cursor | Code rapide et de qualite | Exige de savoir coder | Developpeurs experimentes |
Mon usage personnel ? Ces outils acceleration le travail quand on sait deja ce qu'on fait. Ils ne remplacent pas l'ingenierie ; ils la rendent plus rapide entre les mains de quelqu'un qui sait relire, securiser et structurer. La difference entre un prototype et une application production-ready reste un travail de metier.
La conformite RGPD : l'angle mort le plus dangereux en France
C'est le point que les outils IA ignorent totalement, et c'est precisement celui qui peut vous couter le plus cher en France. Une application qui collecte des donnees — donc presque toutes — doit respecter le RGPD et les recommandations de la CNIL. Or une app « vibe codee » ne respecte quasiment jamais ces obligations.
Ce qui manque presque toujours dans un projet IA
- Mentions legales conformes : identite de l'editeur, SIREN/SIRET, hebergeur, 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 legale claire pour chaque donnee collectee.
- Hebergement maitrise : idealement dans l'Union europeenne, avec des acteurs francais comme OVHcloud, Scaleway ou Clever Cloud — un vrai argument de souverainete, surtout dans la sante ou le secteur public.
- Securite reelle des donnees : regles d'acces, chiffrement, cles d'API jamais exposees cote client.
Mettre une application en production sans ces garde-fous, c'est s'exposer a une plainte, a un controle CNIL, et a la perte de confiance de vos clients. C'est pour moi un passage oblige de toute reprise : un produit serieux 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 marche francais. Tous les montants sont indiques HT (la TVA a 20 % s'ajoute pour les professionnels).
Le TJM d'un developpeur freelance senior en France se situe en 2026 entre 700 et 1 200 € selon la specialite (React, Next.js, mobile, IA), avec une mediane tech autour de 500 à 550 €. Pour une reprise de projet IA, je travaille generalement ainsi :
| Prestation | Format | Fourchette indicative (HT) |
|---|---|---|
| Audit du code IA | Forfait fixe | 800 - 2 000 € |
| Stabilisation / securisation | Forfait ou TJM | 3 000 - 8 000 € |
| Finalisation MVP (auth + base de donnees) | Forfait | 8 000 - 25 000 € |
| Reconstruction complete sur mesure | Forfait | a partir de 12 000 € |
Je positionne toujours la reprise comme un investissement face a la dette technique, jamais comme une solution low-cost. Payer 15 000 € pour une application reellement en production, securisee et conforme, c'est moins cher que de raccommoder pendant un an une base instable qui finira de toute facon par etre reconstruite. Le reflexe francais des trois devis est sain : demandez-les, mais comparez ce qui est comparable. Un devis qui ignore la securite et le RGPD n'est pas moins cher, il est incomplet. Je travaille toujours avec un devis detaille signe, des CGV et une facture conforme.
Si vous hesitez encore entre garder votre outil no-code et passer a une vraie application, mon article sur le cout reel d'un site « gratuit » fait avec l'IA chiffre precisement ce que ces solutions coutent vraiment une fois en production. Et si vous partez de zero, je detaille mon approche dans la rubrique developpement d'applications sur mesure.
Votre projet IA a casse et l'IA n'arrive plus a le reparer ?
Envoyez-moi le lien de votre code et une description de ce que l'app doit faire. Sous 24 heures, je vous dis honnetement s'il faut le reprendre ou le reconstruire, et combien ca coute — devis detaille, sans engagement.
Demander un auditQuestions frequemment posees (FAQ)
En resume
Lovable, Bolt, v0 et Cursor sont d'excellents outils pour prouver une idee. Mais un prototype seduisant n'est pas un produit, et le mur des 20 % restants — securite, base de donnees, paiements, RGPD — ne se franchit pas avec un prompt de plus. Quand l'IA tourne en rond et recasse ce qu'elle vient de reparer, c'est le signal qu'il faut une vraie continuite d'ingenierie.
Si votre application a cesse de fonctionner, ne perdez pas vos nuits a relancer l'IA. Exportez votre code, ecrivez en une page ce que l'app doit faire, listez ce qui casse — puis parlons-en. Je vous dirai sans detour si l'on reprend ou si l'on reconstruit, et vous repartirez avec une application reellement en production, securisee et conforme au cadre francais. C'est tout ce qui separe « j'ai bricole un truc avec l'IA » de « j'ai un produit que je peux confier a mes clients ».