Reeve Backups
L'historique des versions n'est pas une sauvegarde de vos données.
Lovable et Bolt tiennent un historique des versions de votre code. Votre base de données est un service à part, et revenir en arrière ne la ramène pas.
En bref
- L'historique des versions restaure votre code. Il ne touche jamais à votre base de données, là où vivent vos utilisateurs, leurs contenus et leurs commandes.
- Une table supprimée, une ligne écrasée ou une migration ratée survivent donc intactes à un retour en arrière.
- Votre code a une annulation intégrée. Vos données n'en ont une que si vous la mettez en place.
Quelque chose a cassé, alors vous avez fait ce qu'il fallait. Vous avez ouvert l'historique des versions dans Lovable ou Bolt, retrouvé la version de ce matin et cliqué sur restaurer. L'application est revenue exactement comme elle était.
Les données, non.
Voici l'endroit où les gens se font piéger : votre code et vos données sont deux systèmes distincts, et un seul des deux possède un bouton d'annulation. Votre builder conserve les plans de votre app. Votre base de données contient ce qu'il y a dedans. L'historique des versions reconstruit les plans à la perfection, jusqu'au dernier détail, et vous rend un bâtiment identique et vide.
L'historique des versions de mon builder sauvegarde-t-il ma base de données ?
Non. Il enregistre votre code, et vos données vivent tout à fait ailleurs.
Lovable, Bolt, v0, Replit, Cursor et les autres tiennent tous un historique des fichiers de votre projet : vos pages, vos composants, votre logique, vos styles. Ce sont les plans. Restaurer une version réécrit ces fichiers tels qu'ils étaient le jour que vous avez choisi.
Votre base de données est un autre service, presque toujours Supabase, sur un compte à elle. Rien dans l'historique de votre projet n'y pénètre. La restauration n'a pas d'avis sur vos données, parce qu'elle ne peut pas les voir.
Pourquoi votre code et vos données vivent à deux endroits différents
Parce que vos données doivent survivre à ce que votre code fait sans arrêt : changer.
Votre code est reconstruit à chaque mise en ligne. Si les commandes de vos utilisateurs vivaient dedans, elles seraient effacées chaque fois que vous réparez un bouton. Les deux sont donc tenus séparés, délibérément : le code est remplaçable et les données ne le sont pas, et c'est pourquoi des outils différents les versionnent.
Le prix de cette séparation est le sujet de cet article. Tout outil qui versionne l'un des deux est aveugle à l'autre. Votre builder ne peut pas récupérer une table, et votre base de données ne peut pas récupérer une page cassée.
Ce qui se passe vraiment quand vous revenez en arrière
Vos écrans reviennent à ce qu'ils étaient. Vos données ne bougent pas du tout.
| Quoi | Retour en arrière sur le code |
|---|---|
| Pages, composants, styles | Restauré |
| La logique de votre app et ses correctifs | Restauré |
| Une table supprimée | Toujours supprimée |
| Des lignes écrasées par un script | Toujours écrasées |
| Une colonne retirée par une migration | Toujours retirée |
| Les fichiers envoyés par vos utilisateurs | Inchangés dans les deux sens |
La ligne de la migration est celle qui surprend le plus. Une migration que vous avez lancée contre votre base de données a déjà eu lieu ; elle vit dans la base, pas dans votre dépôt, et défaire le fichier qui la décrivait n'y change rien.
Là où cela mord vraiment
Dans les dix minutes qui suivent une erreur, quand vous cherchez l'annulation et découvrez qu'il n'y en a pas.
Les formes que cela prend sont tout à fait ordinaires :
- Une suppression dans l'éditeur de tables Supabase qui a touché plus de lignes que prévu.
- Une migration assistée par IA qui a retiré une colonne pour faire disparaître une erreur de type.
- Un script de remplissage ou de réinitialisation pointé sur le projet en production plutôt que sur un projet de test.
- Un nettoyage de ce qui ressemblait à des données de test et se trouvait être le vrai compte de quelqu'un.
Rien de tout cela ne touche une seule ligne de votre code. Chacune y survit intacte, et c'est pourquoi le retour en arrière donne l'impression de n'avoir rien fait. Il a fait exactement ce qu'il fait.
À quoi sert vraiment l'historique des versions
À beaucoup de choses, et cela mérite d'être dit clairement, parce que la réponse n'est pas « à rien ».
C'est une vraie annulation pour de vrais problèmes : un changement de design que vous regrettez, une mise en ligne qui a cassé une page, une modification de l'IA qui a réécrit en moins bien un écran qui marchait, une fonctionnalité qui a fini par rendre l'app plus difficile à utiliser. Tout cela vit dans votre code, et pour tout cela il fonctionne exactement comme annoncé.
L'ennui, c'est la supposition silencieuse selon laquelle son travail couvre tout. Personne ne fait cette supposition exprès ; c'est celle qui vous reste quand personne ne vous a dit qu'il y avait deux systèmes.
Comment obtenir une vraie annulation pour vos données
Vous devez en installer une. C'est-à-dire une copie de la base de données, prise selon un horaire, rangée dans un endroit que la perte du compte n'emporterait pas avec elle.
Il y a trois façons de le faire, elles coûtent des sommes et des attentions différentes, et à chacune échappe quelque chose que les autres couvrent. Trois façons de sauvegarder une base Supabase passe les trois en revue, dont celle que la plupart des gens devraient activer en premier et la raison pour laquelle elle ne suffit pas seule.
C'est aussi ce à quoi sert Reeve Care : des copies planifiées de votre base de données Supabase, conservées hors de votre compte Supabase et vérifiées avant d'être comptées comme prises. Connectez vos buckets Storage et les fichiers téléversés par vos utilisateurs voyagent avec, si bien qu'une restauration remet les lignes et les images vers lesquelles elles pointent.
Ce que contient une de ces copies, et ce que fait vraiment le bouton, est sur la page des sauvegardes Supabase.
Que faire cette semaine
Que faire
- Cherchez si quelque chose sauvegarde actuellement votre base de données. Pas votre code : votre base de données. Si la réponse met plus d'une minute à venir, la réponse est non.
- Activez la sauvegarde incluse dans votre plan Supabase. Elle vous protège de vos propres erreurs, qui sont exactement le sujet de cet article.
- Gardez en plus une copie ailleurs, car une sauvegarde qui vit dans le compte ne vous aide pas si vous perdez le compte.
- Sauvegardez les fichiers téléversés séparément. Ils ne sont ni dans votre code ni dans votre base de données.
- Restaurez une copie dans un projet jetable, pour que la première lecture de ce fichier ne soit pas le jour où vous en avez besoin.
Avant de fermer cet onglet, ouvrez votre projet Supabase et regardez si les sauvegardes sont activées. Cette seule vérification est tout le travail du jour. La checklist sécurité en 10 minutes la couvre avec le reste de ce qui mérite d'être confirmé sur une app fraîchement lancée, et le guide de sécurité Supabase passe en revue ce qui reste couramment ouvert.
FAQ
J'ai supprimé une table par erreur. Puis-je la récupérer ?
Seulement depuis une sauvegarde antérieure à la suppression : la première chose à savoir est donc s'il en existe une. Revenir en arrière sur votre code n'y suffira pas, et votre builder non plus. Sur un plan Supabase payant il y a des sauvegardes quotidiennes, et la restauration à un instant précis si vous l'avez ajoutée. Sur le plan gratuit, rien d'automatique. Vérifiez ce dont vous disposez avant de changer quoi que ce soit d'autre : certaines voies de retour se compliquent dès que de nouvelles données s'écrivent par-dessus le trou.
Est-ce que Lovable sauvegarde ma base de données Supabase ?
Votre builder versionne les fichiers de votre projet. Votre base de données est un service distinct sur votre propre compte Supabase, et rien dans l'historique du projet n'y pénètre. Les builders ajoutent des fonctions, alors consultez la documentation du vôtre plutôt que de supposer dans un sens ou dans l'autre, mais partez du principe que la réponse est non tant que vous n'avez pas lu qu'elle est oui.
Mon historique Git est-il une sauvegarde ?
Non, exactement pour la raison qui fait que l'historique des versions n'en est pas une. Git suit les fichiers à partir desquels votre app est construite. Il n'a jamais vu une seule ligne de vos données et ne peut en remettre aucune. Un dépôt et une base de données sont deux choses différentes qui s'appellent toutes les deux « votre projet ».
Mes données sont toutes là. Dois-je faire quelque chose aujourd'hui ?
Aujourd'hui est le jour le moins cher pour mettre cela en place, parce que les données sont petites et que ce qui compte est que l'habitude existe avant d'en avoir besoin. Les pertes qui font mal sont rarement spectaculaires : c'est une commande mal tapée pendant une réparation nocturne, sur un projet avec juste assez d'utilisateurs réels pour que tout recommencer ne soit pas envisageable.