Guide · Sécurité
Faire évoluer un projet Lovable sans tout casser
Par Marie Van Haecke ·
Lovable enregistre chaque modification comme une version, et vous pouvez revenir en arrière. Mais le retour arrière restaure le code, pas les données de la base. Pour faire évoluer une application en ligne sans risque : marquez la version stable, faites une modification à la fois, testez dans l'aperçu, et ne republiez qu'une fois vérifié. La version en ligne ne change pas tant que vous ne publiez pas.
Ce que Lovable garde pour vous
- Chaque modification crée une version, sans action de votre part.
- Vous pouvez prévisualiser une ancienne version avant d'y revenir.
- Vous pouvez marquer une version (favori) pour la retrouver facilement, par exemple la dernière version stable.
- Revenir en arrière ne rembourse pas les crédits dépensés, et se fait version entière, pas modification par modification.
Le piège à connaître : revenir à une version antérieure restaure le code uniquement. Les données ajoutées ou modifiées dans la base depuis restent telles quelles. Si une évolution a changé la structure de la base, le retour arrière du code ne la défait pas.
Source : documentation Lovable, « Project history », consultée le 30 septembre 2026.
Aperçu et version en ligne : deux choses différentes
Publier met en ligne une photo du projet à un instant donné. Les modifications suivantes ne partent pas en ligne automatiquement : un point sur le bouton Publier signale qu'il y a des changements à déployer. Vous pouvez donc travailler dans l'aperçu pendant que vos utilisateurs continuent sur la version stable.
Source : documentation Lovable, « Publish », consultée le 30 septembre 2026.
La méthode pour chaque évolution
Marquez la version stable
Avant toute évolution, mettez en favori la version actuellement en ligne. C'est votre point de retour.
Décrivez l'évolution avant de la demander
Ce qui change, pour qui, et ce qui ne doit pas bouger. Utilisez le mode Plan pour en discuter avec l'IA sans modifier le code.
Une modification à la fois
Une demande qui touche l'écran, la base et les emails en même temps est difficile à vérifier et à défaire.
Soyez prudent avec la base de données
Ajouter un champ est sans risque. Renommer ou supprimer un champ, changer une règle d'accès, l'est beaucoup moins. Exportez les données concernées avant.
Testez le parcours complet dans l'aperçu
Pas seulement l'écran modifié : le parcours entier, avec chaque rôle. Et relancez l'analyse de sécurité si les accès ont changé.
Publiez, puis vérifiez en ligne
Publiez les changements, puis refaites le parcours principal sur la version en ligne.
Les garde-fous à mettre en place une fois pour toutes
- Synchronisez le projet avec GitHub : vous avez un historique complet du code, hors de Lovable.
- Remplissez la connaissance du projet : l'IA relit ces consignes à chaque demande et évite de défaire vos choix.
- Écrivez les règles qui ne doivent pas bouger : « ne jamais modifier la table des rôles », « garder le rendu serveur des pages ».
- Tenez un petit journal des évolutions : date, changement, version. Il sert quand quelque chose casse trois semaines plus tard.
Et les crédits ?
Une application qui casse consomme beaucoup de crédits en corrections successives. Quand deux ou trois demandes de correction n'ont pas résolu un problème, arrêtez : revenez à la version stable et reformulez la demande, au lieu d'empiler les corrections.
Questions fréquentes
Peut-on annuler une modification dans Lovable ?
Oui, en revenant à une version antérieure depuis l'historique. Le retour arrière restaure le code, pas les données de la base, et ne rembourse pas les crédits utilisés.
Mes modifications sont-elles visibles tout de suite par mes utilisateurs ?
Non. Elles restent dans l'aperçu tant que vous ne publiez pas les changements. La version en ligne ne bouge pas.
Mon projet Lovable est bloqué dans une boucle de corrections. Que faire ?
Revenez à la dernière version qui fonctionnait, puis reformulez la demande en une seule modification précise. Si le blocage persiste, un audit permet de décider ce qui peut être gardé.
Votre projet Lovable est bloqué ou devient fragile à chaque modification ? L'audit fait le point sur ce qui peut être gardé et ce qui doit être repris.
Marie Van Haecke · 20 ans à concevoir des produits tech et à coacher des équipes produit. Fondatrice de Grabloop, Lovable Certified Expert 2026 (App builder et Website builder).