Le message commence souvent de la même façon : « J'ai fait une appli avec Lovable, elle marche presque. » Le « presque » cache tout le reste. Une page qui plante quand deux personnes l'utilisent en même temps. Un paiement qui passe une fois sur trois. Un écran que l'IA a corrigé dix fois, et qui casse quelque chose ailleurs à chaque correction.
Je ne suis pas contre ces outils, au contraire. Lovable, Bolt ou Cursor permettent à un gérant de voir son idée prendre forme en un week-end, sans attendre un devis. C'est une vraie révolution pour tester un projet. Le problème arrive après, le jour où des clients, des salariés ou de l'argent passent par l'application.
Voici comment je m'y prends pour reprendre une application faite en vibe coding, et comment savoir si la vôtre peut être sauvée.
Le vibe coding, c'est quoi exactement ?
On parle de vibe coding quand on construit une application en décrivant ce qu'on veut à une IA, sans écrire le code soi-même. On demande « ajoute une page de réservation », l'outil la génère, on teste, on redemande. Les outils les plus connus produisent le plus souvent une application en React, avec une base de données Supabase derrière.
Le résultat a l'air fini. L'écran est propre, les boutons répondent. Mais personne n'a vraiment relu ce qu'il y a dessous, et c'est là que les surprises se cachent.
Les signes qu'une application générée par IA arrive au bout
Après quelques semaines, les mêmes symptômes reviennent :
- chaque correction en casse une autre. L'IA ne voit qu'un morceau du code à la fois, alors elle répare un écran et en dérègle un autre ;
- le même code existe en quatre exemplaires, un peu différents, et personne ne sait lequel est utilisé ;
- ça marche pour vous, pas pour dix utilisateurs. Les pages ralentissent, les données se mélangent quand plusieurs personnes travaillent en même temps ;
- vous n'osez plus rien modifier avant un rendez-vous client, de peur que tout tombe ;
- la facture de l'outil grimpe à mesure que vous redemandez des corrections.
Si vous vous reconnaissez dans deux ou trois de ces points, ce n'est pas un échec. C'est le moment où un prototype doit devenir une vraie application.
Ce que je regarde en premier : la sécurité et les données
Avant de toucher à quoi que ce soit, je fais le tour de ce qui peut coûter cher.
Qui peut lire quoi. Sur Supabase, les règles qui empêchent un utilisateur de voir les données d'un autre ne se mettent pas toutes seules. Il arrive qu'une application générée laisse la base ouverte à quiconque connaît l'adresse. C'est la première chose que je vérifie, parce que des fiches clients exposées, ce n'est pas un bug, c'est un problème légal.
Les clés qui traînent. Une clé de paiement ou d'envoi d'e-mails écrite en clair dans le code du navigateur peut être récupérée par n'importe qui.
Les sauvegardes. Je regarde s'il existe une sauvegarde de la base, et si on sait la restaurer. Souvent, la réponse est non.
Le paiement. Un paiement qui réussit, c'est facile. Un remboursement, un acompte, un paiement abandonné à moitié, c'est là que les applications générées se trompent le plus. Sur Izidoor, la plateforme de réservation sur laquelle j'ai travaillé deux ans et demi, j'ai développé le paiement en ligne avec les acomptes et les remboursements : ce sont ces cas-là qui demandent le plus d'attention.
Reprendre, réécrire ou repartir de zéro ?
C'est la vraie question, et la réponse n'est pas toujours celle qu'on espère.
Reprendre et consolider quand la structure tient debout : on sécurise, on supprime les doublons, on ajoute des tests sur les parties sensibles, et on continue à partir de votre code. C'est le cas le plus fréquent quand l'application est récente et pas trop grosse.
Réécrire une partie quand un morceau précis est le problème, par exemple tout le module de réservation ou de paiement. On garde le reste.
Repartir sur une base propre quand chaque écran a été bricolé séparément et que les données sont mal rangées. Ça fait mal à entendre, mais c'est parfois moins cher que de colmater pendant des mois. Votre version générée garde alors toute sa valeur : c'est un cahier des charges vivant. On sait exactement ce que vous voulez, écran par écran, et ça raccourcit beaucoup le projet.
Je fais mon travail en Nuxt, Vue, TypeScript et Python, et j'ai aussi travaillé en React chez Kodeva et sur Izidoor. Une application React générée par Lovable ou Bolt ne me fait donc pas peur, et on n'est pas obligé de changer de technologie pour la reprendre.
Un exemple concret
Imaginons Claire, qui gère trois salles de sport. Elle a construit en un mois, avec Lovable, une application pour que ses adhérents réservent leurs cours. Au début, c'était parfait. Puis la rentrée est arrivée : deux cents adhérents en même temps le lundi matin, des cours réservés deux fois, une salle qui affiche des places libres alors qu'elle est pleine.
On commencerait par une demi-journée d'audit : lecture du code, de la base et des règles d'accès, liste des risques classés du plus urgent au moins urgent. Puis on corrige d'abord ce qui touche aux réservations en double et aux données des adhérents, avant d'ajouter la moindre fonctionnalité. L'application de Claire reste en ligne pendant ce temps : on travaille sur une copie, et on bascule quand c'est prêt.
Combien ça coûte de reprendre une application
Tout dépend de ce que l'audit révèle, et c'est pour ça que je commence toujours par lui. Consolider une petite application peut tenir en quelques jours de travail. Repartir sur une base propre se rapproche d'un projet classique : la plupart des outils de TPE et de PME que je réalise se situent entre 5 000 et 15 000 € au forfait, puis 100 à 300 € par mois de maintenance. Tout est détaillé sur ma page application métier sur mesure.
Et si votre besoin est standard, je vous le dirai aussi : parfois, un logiciel existant fait mieux le travail qu'une application maison, générée ou non. J'explique comment trancher dans ce comparatif entre logiciel du marché et sur mesure.
Questions fréquentes
Est-ce que je dois arrêter d'utiliser Lovable ou Bolt ?
Pas forcément. Pour tester une idée ou maquetter un nouvel écran, c'est très bien. Ce qui change, c'est qu'une fois l'application en production, chaque modification passe par quelqu'un qui relit le code.
Mon code m'appartient-il ?
Oui, et c'est un bon réflexe de le récupérer dès maintenant sur un dépôt GitHub à votre nom. C'est aussi ce qui permet à un développeur de le reprendre.
Combien de temps prend l'audit ?
En général une demi-journée à une journée pour une petite application. Vous recevez une liste écrite des risques et des corrections à prévoir, dans l'ordre.
Peut-on garder l'application en ligne pendant la reprise ?
Oui. On travaille sur une copie, et vos utilisateurs ne voient la nouvelle version que lorsqu'elle est prête.
On regarde la vôtre ?
Si vous avez une application faite avec une IA qui commence à vous inquiéter, envoyez-moi l'adresse et quelques mots sur ce qui coince. On en parle au téléphone ou en visio, je regarde le code, et vous repartez avec un plan d'action écrit : ce qu'il faut corriger tout de suite, ce qui peut attendre, et un ordre de grandeur de budget. Si votre application tient la route et qu'il suffit de quelques ajustements, je vous le dirai aussi.
