Revenir à une version précédente de son application créée avec l'IA

Introduction

Hier soir, votre application fonctionnait. Vous avez demandé à l'IA « une petite amélioration » de la page d'inscription, et ce matin plus rien ne marche : le formulaire ne s'envoie plus, un écran est blanc, et chaque nouveau prompt pour réparer semble casser autre chose. C'est l'un des blocages les plus fréquents quand on construit sa première version avec Lovable, Bolt, Replit ou Cursor.

La bonne nouvelle : ces outils gardent un historique et permettent de revenir à une version précédente de votre application. La mauvaise : ce retour en arrière concerne le code, rarement les données. Un fondateur qui ne connaît pas cette différence peut restaurer une version « qui marchait » et découvrir qu'elle ne fonctionne plus avec sa base de données.

Ce guide explique comment revenir en arrière proprement, ce qui revient et ce qui ne revient pas, et quelle routine adopter pour le prochain incident.

Premier réflexe : arrêter de prompter

Quand une modification casse l'application, la tentation est d'enchaîner les demandes de correction. Chaque prompt ajoute pourtant de nouveaux changements par-dessus le problème initial, et il devient de plus en plus difficile de savoir ce qui a cassé quoi.

Avant toute nouvelle demande, prenez trois minutes :

• Notez le symptôme exact : quelle page, quelle action, quel message d'erreur.
• Repérez le dernier état qui fonctionnait : quelle demande l'a précédé, à quelle heure.
• Demandez-vous si des données ont changé depuis : nouvelles tables, champs renommés, utilisateurs inscrits, paiements reçus.

Cette dernière question décide de la suite. Si seul le code a changé, un retour en arrière suffit généralement. Si la structure de la base a été modifiée entre-temps, il faudra aussi vous occuper des données.

Ce que propose chaque outil

Chaque outil a son mécanisme de retour en arrière ; la logique est proche.

Lovable

Selon la documentation de Lovable, chaque modification crée automatiquement une version : il n'y a pas de bouton d'enregistrement. Le panneau History permet de prévisualiser une ancienne version, de voir les fichiers modifiés, de retrouver le message du chat qui l'a produite et de la restaurer avec Revert. Un badge Published indique la version que voient vos utilisateurs.

Trois limites sont précisées : le retour en arrière restaure le code mais pas les données de la base, une version très ancienne peut être prévisualisée sans pouvoir être restaurée, et les crédits consommés pour le travail annulé ne sont pas remboursés.

Bolt

La documentation de Bolt décrit l'historique des versions accessible depuis le menu du projet, avec un aperçu avant de confirmer la restauration, ainsi que la possibilité de restaurer depuis l'historique du chat. Elle précise que restaurer une version antérieure ne modifie pas les bases de données Bolt ou Supabase en cours.

Replit

Chez Replit, l'agent crée des checkpoints à des étapes clés. Un rollback ramène les fichiers, le contexte de conversation et la configuration à ce point, et supprime les changements faits ensuite. La documentation indique que, par défaut, le rollback ne modifie pas la base de données : il faut cocher l'option Database pour y inclure la base de développement. La base de production n'est pas restaurée par ce mécanisme et relève d'une procédure distincte.

Cursor

Dans Cursor, l'agent crée des checkpoints avant les changements importants. On peut prévisualiser les fichiers à ce point, puis restaurer. La documentation précise que les checkpoints sont stockés en local, séparément de Git, et recommande de les réserver à l'annulation des changements de l'agent, en utilisant Git pour l'historique durable.

Le piège : le code revient, les données non

C'est le point que la plupart des fondateurs découvrent trop tard. Sur les quatre outils, la documentation dit la même chose sous des formes différentes : revenir à une version précédente de l'application ne remet pas, par défaut, la base de données dans son état d'avant.

Exemple : la demande fautive a aussi renommé une colonne « telephone » en « phone ». Le code restauré cherche toujours « telephone » : l'application reste en panne, pour une autre raison.

Avant de restaurer, posez-vous donc deux questions :

• La structure de la base a-t-elle changé ? Nouvelle table, colonne renommée ou supprimée, règles d'accès modifiées. Si oui, il faudra soit revenir aussi sur la base, soit demander à l'IA d'adapter le code restauré à la structure actuelle.
• Des données réelles sont-elles arrivées depuis ? Inscriptions, commandes, messages. Restaurer une sauvegarde de base les effacerait. Dans ce cas, mieux vaut corriger la structure que revenir en arrière sur les données.

Si vous hésitez encore sur la base à utiliser, notre guide quelle base de données pour son MVP compare les options avec ce critère en tête.

Revenir en arrière pas à pas

Voici la démarche que nous recommandons, quel que soit l'outil.

• 1. Identifier la dernière version qui fonctionnait. Prévisualisez les versions une par une, en partant de la plus récente, jusqu'à trouver celle où le parcours cassé fonctionne. Lovable et Bolt permettent un aperçu avant restauration ; Cursor permet de voir les fichiers à un checkpoint.
• 2. Lire ce qui a changé depuis. Le détail des fichiers modifiés (« View code changes » dans Lovable) ou le message du chat associé vous dit quelle demande a introduit le problème. Notez-la : vous la reformulerez plus tard.
• 3. Vérifier l'impact sur la base. Si la demande fautive a touché la structure des données, traitez ce point avant ou juste après la restauration, comme expliqué plus haut.
• 4. Restaurer. Utilisez la fonction prévue par l'outil : Revert, Restore version, rollback ou Restore Checkpoint.
• 5. Tester le parcours complet. Inscription, connexion, action principale, paiement s'il existe. Une page qui s'affiche ne prouve pas que les données s'enregistrent.
• 6. Republier si besoin. Vérifiez que la version en ligne correspond bien à celle que vous venez de restaurer. Dans Lovable, le badge Published vous l'indique.
• 7. Refaire la modification autrement. Reprenez la demande initiale, plus petite et plus précise, une chose à la fois.

Mettre en place une routine qui évite la panique

Ce qui fait gagner du temps, c'est de savoir à l'avance où se trouve la dernière version stable.

Marquer les versions stables

Lovable et Bolt permettent de mettre une version en favori. La documentation de Lovable conseille de le faire avant un changement important. Prenez l'habitude simple de marquer chaque version qui passe vos tests de parcours, avec un nom clair : « inscription OK », « paiement OK ».

Relier le projet à GitHub

GitHub conserve un historique de votre code en dehors de l'outil. Selon la documentation de Lovable, la connexion crée un dépôt privé par défaut, la synchronisation se fait dans les deux sens sur une seule branche, et le dépôt reste sur votre compte si vous déconnectez le projet.

Deux précautions issues de cette même documentation : ne supprimez pas le dépôt, sous peine d'arrêter la synchronisation, et sachez que si la branche a divergé, la synchronisation suivante remplace la version de Lovable par celle de GitHub, après une sauvegarde que le propriétaire du projet peut restaurer.

Une demande, un changement, un test

Plus une demande à l'IA est large, plus le retour en arrière est coûteux, car il annule tout d'un bloc. Lovable précise d'ailleurs que le retour en arrière s'applique à une version entière : pour annuler un seul changement, il faut le demander dans le chat. Découpez : une fonctionnalité par demande, un test du parcours après chaque demande, un favori quand c'est stable.

Sauvegarder les données à part

Le code et les données se sauvegardent séparément. Programmez un export régulier de la base, et testez au moins une fois sa restauration sur un projet vide. Nous le rappelons dans notre guide pour sécuriser une application créée avec l'IA : une sauvegarde qui n'a jamais été restaurée reste une hypothèse.

Les erreurs fréquentes

• Enchaîner les prompts de réparation. Chaque correction ajoute des changements et brouille la piste. Mieux vaut revenir à l'état stable et refaire proprement.
• Restaurer sans regarder la base. Le code restauré peut ne plus correspondre à la structure des données.
• Compter uniquement sur l'historique de l'outil. Les versions très anciennes ne sont pas toujours restaurables, et les checkpoints de Cursor sont locaux. GitHub et un export de base servent de seconde ligne.
• Oublier la version publiée. Restaurer dans l'éditeur ne garantit pas que vos utilisateurs voient la bonne version : vérifiez ce qui est en ligne.

Check-list avant chaque gros changement

• La version actuelle passe le test du parcours principal.
• Elle est marquée en favori avec un nom explicite.
• Le projet est relié à un dépôt GitHub.
• Un export récent de la base existe, stocké hors de l'outil.
• La demande à l'IA porte sur un seul changement, décrit précisément.
• Vous savez quelle version est publiée.

Questions fréquentes

Revenir à une version précédente efface-t-il mes données ?

D'après les documentations de Lovable, Bolt et Replit, le retour en arrière du code ne modifie pas la base par défaut. Vos données restent, mais elles peuvent ne plus correspondre au code restauré si leur structure a changé entre-temps.

Pourquoi la version restaurée ne fonctionne-t-elle plus ?

Le plus souvent, parce que la base de données a évolué depuis : une table ou une colonne a été créée, renommée ou supprimée. Le code d'hier s'attend à la structure d'hier. Il faut alors adapter le code ou revenir aussi sur la structure de la base.

Faut-il connecter GitHub si l'outil garde déjà un historique ?

C'est une sécurité utile : le dépôt garde l'historique du code hors de l'outil, reste sur votre compte et facilite la reprise par un développeur. Il ne remplace pas une sauvegarde de la base, qui se gère à part.

Peut-on annuler un seul changement sans perdre les autres ?

Dans Lovable, le retour en arrière s'applique à une version entière ; pour annuler un seul changement, la documentation conseille de le demander dans le chat. D'où l'intérêt de demandes courtes : chaque version ne contient alors qu'une modification.

Conclusion

Une application qui casse après un prompt n'est pas un échec, c'est le quotidien de la construction avec l'IA. Ce qui fait la différence, c'est d'avoir une version stable repérée, un historique hors de l'outil et des données sauvegardées à part. Avec ces trois réflexes, revenir à une version précédente devient une décision de quelques minutes, pas une journée perdue.

Pour aller plus loin sur la méthode, la page MVP de StartupWeek détaille notre démarche pour créer la première version testable de votre application avec l'IA et le No-Code. Si vous voulez construire la vôtre avec un cadre et un regard extérieur, vous pouvez candidater avec votre projet.

Sources

• Lovable, « Version history » : https://docs.lovable.dev/features/projects/history
• Lovable, « GitHub integration » : https://docs.lovable.dev/integrations/github
• Bolt, « Rollback and backup » : https://support.bolt.new/building/using-bolt/rollback-backup
• Replit, « Checkpoints and rollbacks » : https://docs.replit.com/core-concepts/agent/checkpoints-and-rollbacks
• Cursor, « Checkpoints » : https://cursor.com/docs/agent/chat/checkpoints
• Supabase, « Database backups » : https://supabase.com/docs/guides/platform/backups