IAPrototypeMVPMaintenanceSaaS
Mettre en production une application créée avec Lovable, Bolt ou Base44
9 min de lecture
Mettre en production une application créée avec Lovable, Bolt ou Base44, c'est la faire passer d'une démonstration qui marche à un service dont des clients dépendent. Le chemin tient en trois verbes appliqués module par module : garder ce qui est validé (écrans, parcours), consolider ce qui est fragile (droits d'accès, données, secrets), réécrire seulement ce qui coûterait plus cher à corriger qu'à refaire. L'outil n'a pas à être abandonné, mais il ne fait pas ce travail à votre place.
Cet article s'adresse à un fondateur ou à un dirigeant qui a déjà un prototype, parfois des premiers utilisateurs, et qui se demande ce qui manque avant d'ouvrir les portes. Il ne dénigre aucun outil : ils sont faits pour aller vite, et ils le font bien.
Ce que votre prototype prouve déjà
Un prototype généré par l'IA a une valeur que beaucoup sous-estiment : il prouve le besoin. Les écrans, l'enchaînement des étapes, les données manipulées, les mots employés par vos utilisateurs, tout cela est décidé et visible. C'est le travail le plus long d'un projet classique, et vous l'avez déjà fait.
Ce que le prototype ne prouve pas, en revanche :
- que les données d'un client sont invisibles pour un autre ;
- que l'application tient quand cent personnes s'en servent en même temps ;
- qu'une modification de demain ne cassera pas ce qui marche aujourd'hui ;
- que vous saurez restaurer les données après une erreur ;
- que quelqu'un sera là pour corriger un incident un dimanche.
La différence entre les deux listes est exactement ce qu'on appelle la mise en production. Notre article sur les limites des générateurs d'applications par IA aide à savoir si vous en avez besoin ; celui-ci suppose que oui.
Ce que disent les éditeurs eux-mêmes
Les plateformes sont claires sur le partage des responsabilités. La documentation sécurité de Lovable l'écrit en toutes lettres : « You are responsible for ensuring that your app meets the security requirements appropriate for its use case. » Elle précise que ses outils d'analyse ne garantissent pas une sécurité complète et recommande une revue professionnelle pour les applications qui traitent des données sensibles.
Le risque n'est pas théorique. En mai 2025, la vulnérabilité CVE-2025-48757 a été publiée : des règles d'accès insuffisantes au niveau de la base, sur des applications générées par Lovable, permettaient à des visiteurs non authentifiés d'accéder aux données. L'éditeur conteste la qualification, mais le fond reste : le générateur produit, et c'est vous qui répondez de ce qui est en ligne. La check-list sécurité d'une application codée avec l'IA détaille ce que vous pouvez vérifier vous-même.
La grille : garder, consolider, réécrire
Découpez l'application en modules, puis passez chacun dans la grille. Ce découpage évite le faux choix entre « on garde tout » et « on repart de zéro ».
| Module | Le plus souvent | Ce qu'on vérifie |
|---|---|---|
| Écrans et parcours | Garder | Cohérence, accessibilité, affichage mobile |
| Comptes et connexion | Consolider | Réinitialisation du mot de passe, sessions, double authentification pour l'administration |
| Droits d'accès aux données | Consolider ou réécrire | Règles par table, contrôle côté serveur, tests à deux comptes |
| Logique métier (calculs, statuts) | Consolider | Tests automatisés sur les cas limites |
| Paiement et abonnements | Réécrire si fragile | Vérification des notifications de paiement côté serveur |
| Intégrations (e-mail, CRM, API) | Consolider | Clés hors du navigateur, reprise sur erreur |
| Données et sauvegardes | Consolider | Restauration testée, environnement de test séparé |
Garder
Les écrans validés par vos utilisateurs se gardent presque toujours. Les retoucher n'apporte rien au lancement et fait perdre ce que vous avez appris. On corrige l'affichage sur mobile et l'accessibilité, on ne redessine pas.
Consolider
C'est le gros du travail. Consolider veut dire garder le code et la structure, mais ajouter ce qui manque :
- des règles d'accès vérifiées sur chaque table. La plupart de ces outils s'appuient sur Supabase ou une base équivalente ; la documentation de Supabase demande d'activer la sécurité au niveau des lignes (RLS) sur chaque table exposée, faute de quoi elle est lisible et modifiable par tout rôle qui y a accès ;
- des tests automatisés sur les règles métier qui comptent : un prix, un statut de commande, un droit d'accès ;
- un environnement de test distinct de la production, pour qu'un essai ne touche jamais les données réelles ;
- une supervision : être prévenu d'une erreur avant vos clients.
Réécrire
On réécrit un module quand le corriger coûterait plus cher que le refaire, ou quand il porte un risque qu'on ne sait pas mesurer. En pratique, c'est souvent le paiement (abonnements, remboursements, notifications du prestataire de paiement) ou un système de droits devenu illisible à force de corrections par conversation. La réécriture reste ciblée : le reste de l'application continue de tourner.
L'audit, première étape concrète
Avant de choisir, il faut regarder. Un audit d'une application générée suit la même méthode que pour n'importe quel logiciel repris, décrite dans auditer une application existante avant de la reprendre, avec trois points d'attention propres aux générateurs :
- Les règles de la base de données. Elles sont souvent écrites une fois, au début, puis jamais revues alors que l'application a grandi.
- Les secrets. Une clé d'API collée dans une conversation peut finir dans le code envoyé au navigateur. La documentation de Supabase rappelle qu'une clé secrète ne doit jamais être utilisée côté navigateur.
- Les dépendances ajoutées en passant. Chaque demande peut ajouter une bibliothèque ; certaines ne servent plus, d'autres ne sont plus maintenues.
Le livrable est une liste priorisée : ce qui bloque le lancement, ce qui peut attendre, et le classement de chaque module dans la grille.
Récupérer le code et les données
Mettre en production ne veut pas forcément dire quitter la plateforme. Mais il faut pouvoir la quitter, ne serait-ce que pour que quelqu'un d'autre relise le code.
- Le code. La page des formules de Lovable indique une synchronisation Git (GitHub, GitLab, Bitbucket) sur toutes les formules. Chez Bolt, la connexion GitHub sauvegarde le projet avec son historique. Chez Base44, la synchronisation GitHub demande la formule Builder ou supérieure.
- Les données. C'est le point le plus délicat. La documentation de Lovable Cloud précise qu'un projet ne se déplace pas en une seule étape vers votre propre projet Supabase : il faut exporter la base, la restaurer, déplacer les fichiers, puis reconfigurer l'authentification et les secrets. Chez Bolt, le centre d'aide indique qu'il n'existe pas, à ce jour, de migration prise en charge d'une base Bolt existante vers Supabase.
- Le fonctionnement. Le code exporté depuis Base44 s'appuie sur le SDK de Base44, décrit comme une interface pour construire des applications sur la plateforme : récupérer le code ne suffit donc pas à le faire tourner ailleurs sans travail.
Ces différences ne disqualifient aucun outil. Elles se décident avant le lancement, pas le jour où il faudrait partir en urgence. Notre article sur la réversibilité explique ce qu'il faut pouvoir récupérer, quel que soit le fournisseur. Et pour situer les trois plateformes sur ces points, voyez le comparatif Lovable, Bolt et Base44.
L'exploitation, ce qui commence le jour du lancement
Une application en production vit. Les éléments suivants n'existent pas dans un prototype et doivent être prévus avant le premier client :
- Les sauvegardes, et surtout la restauration. Une sauvegarde jamais restaurée est une hypothèse. Faites l'essai une fois, sur l'environnement de test.
- Le journal des erreurs. Savoir qu'un paiement a échoué, quand et pour qui.
- Les mises à jour. Les bibliothèques reçoivent des correctifs de sécurité ; quelqu'un doit les appliquer et vérifier que rien ne casse.
- Le support. Qui répond à un client bloqué, et sous quel délai.
- Les obligations légales. Mentions légales, politique de confidentialité, registre des traitements si vous traitez des données personnelles, ce que détaille notre article sur la sécurité d'une application métier.
Les erreurs les plus coûteuses
- Corriger par conversation en production. Chaque demande à l'IA peut modifier plusieurs fichiers. Sans environnement de test, un correctif de bouton peut casser une règle d'accès.
- Ouvrir à tous d'un coup. Ouvrez d'abord à quelques clients de confiance, observez, puis élargissez.
- Repartir de zéro par principe. Jeter un prototype qui marche fait perdre des semaines d'apprentissage. La grille sert à ne réécrire que ce qui doit l'être.
- Garder tout par économie. À l'inverse, publier sans avoir testé les droits d'accès, c'est parier les données de vos clients.
Comment nous abordons ces projets
Chez LPR Studio, un prototype fait avec Lovable, Bolt ou Base44 est un excellent point de départ : il montre ce que vous voulez mieux qu'un cahier des charges. Nous commençons par le regarder avec vous, puis nous vous présentons en visio, sous 5 jours ouvrés, un prototype gratuit de ce que deviendrait la version de production, avec le classement de chaque module. Les droits sur le code produit sont définis au cas par cas dans le contrat. Nous utilisons aussi l'IA pour écrire du code ; la différence tient à la vérification qui l'entoure, et au fait que nous éditons et exploitons nous-mêmes nos propres logiciels.