Sommaire
Les générateurs d’applications par IA (Lovable, Bolt, v0) et les plateformes no-code (Bubble, Glide, Softr) permettent de lancer un outil en quelques jours. C’est formidable pour tester une idée. Mais beaucoup de projets arrivent ensuite à un point où chaque modification casse autre chose, où les performances baissent, ou où la facture de la plateforme grimpe.
Je connais bien la situation : mon propre site était une application générée avec Lovable avant d’être reconstruite. Voici comment savoir où vous en êtes, et quelles options s’offrent à vous.
Les signes qu’il faut agir
- Chaque nouvelle demande à l’IA casse une fonction existante, et personne ne sait vraiment pourquoi.
- L’application est lente, surtout quand les données s’accumulent.
- Le référencement est faible : une application générée côté navigateur peut apparaître presque vide aux yeux de Google.
- La sécurité est floue : qui a accès à quelles données, les règles de la base sont-elles réellement appliquées côté serveur ?
- Les coûts montent : crédits d’IA, nombre d’utilisateurs, plan supérieur obligatoire pour une fonction.
- Vous dépendez d’une seule personne qui « sait parler à l’outil ».
Première étape : l’audit
Avant de décider quoi que ce soit, il faut savoir ce que vaut l’existant. Un audit répond à quatre questions :
- Le code ou la configuration sont-ils récupérables ? Les générateurs comme Lovable produisent du vrai code (souvent React et Supabase), exportable sur GitHub ; certaines plateformes no-code n’exportent rien d’exploitable.
- La base de données est-elle saine ? Structure, doublons, règles d’accès.
- La sécurité tient-elle ? Clés exposées, accès trop larges, contrôles faits seulement dans le navigateur.
- Qu’est-ce qui marche et qu’il faut garder ? Souvent plus qu’on ne le croit.
Les trois options
| Option | Quand la choisir | Ce que ça implique |
|---|---|---|
| Consolider | Le code est récupérable et la structure correcte | Nettoyage, sécurisation, tests, puis évolutions maîtrisées |
| Migrer progressivement | Une partie est saine, une autre bloque | Reconstruire les modules fragiles un par un, sans arrêter l’activité |
| Reconstruire | La base est fragile ou la plateforme n’exporte rien | Repartir de zéro en reprenant les données, les écrans validés et l’expérience acquise |
Reconstruire n’est pas un échec : la première version a servi à valider le besoin, ce qui rend la seconde plus rapide et plus juste.
Le cas particulier du référencement
Si votre application sert aussi de site vitrine, c’est souvent le point le plus urgent. Une application qui génère ses pages dans le navigateur peut afficher un écran de chargement à Google, avec le même titre et la même adresse officielle sur toutes les pages. La solution consiste à séparer le site public (pages statiques, rapides, bien référencées) de l’application (espace connecté), comme je l’ai fait pour mon propre site.
Combien ça coûte ?
L’audit est la première dépense, et la plus rentable : l’audit express démarre à 589€HT, l’audit complet à 1 990€HT. Le coût de la suite dépend de l’option retenue ; l’audit vous donne justement un plan d’action chiffré pour décider.
Mon conseil : n’empilez pas de nouvelles demandes sur une base qui vacille. Faites le point, sauvegardez votre code et vos données, puis choisissez entre consolider, migrer ou reconstruire en connaissance de cause.