La question en recouvre trois, et elles n'ont pas la même réponse. Une suppression faite dans l'application se rattrape : rien n'est réellement effacé, la ligne part dans une corbeille d'où un bouton la restaure. Vos données sortent quand vous le voulez, chaque liste ayant son export. Mais la base de données d'une application déployée n'est sauvegardée par AUCUN automatisme du produit — il n'existe aucune commande de sauvegarde dans la chaîne de déploiement, et c'est à l'hébergeur de la mettre en place. Autrement dit : un clic de trop se répare tout seul, une base perdue ne se répare pas. Cette page dit précisément où passe la frontière, pour que vous posiez les bonnes questions avant d'y mettre des données réelles.
Supprimer, dans votre application, ne détruit rien
Le bouton Supprimer ne supprime pas : il marque la ligne comme supprimée par une colonne dédiée. Elle disparaît alors des listes, des totaux et des indicateurs — mais elle est toujours en base. Une carte « Corbeille » apparaît dans les Paramètres dès qu'une ligne a été supprimée, et elle porte un bouton « Restaurer ». C'est vérifiable dans le code livré : aucune des routes générées n'appelle la suppression définitive de la base de données.
S'y ajoute une confirmation en deux temps — un premier clic arme la suppression, un second la valide — plutôt que la fenêtre de confirmation du navigateur. Le cas de loin le plus fréquent, le clic de trop en fin de journée, se rattrape donc en trente secondes et sans appeler personne. C'est aussi la seule des trois couches que l'application gère entièrement seule, et c'est pour cela qu'elle vient en premier.
Sortir vos données quand vous voulez
Chaque liste porte un bouton d'export au format CSV. Il exporte les lignes que vous VOYEZ — filtrées par la recherche et les filtres actifs — et le libellé du bouton porte le nombre de lignes qui partent : on n'exporte jamais en silence des données que vous n'avez pas à l'écran. Le fichier est produit pour s'ouvrir correctement dans un tableur en français, sans la ligne d'accents cassés qui guette d'ordinaire les exports.
C'est une copie que vous détenez, et il faut la nommer pour ce qu'elle est : ce n'est pas une sauvegarde au sens technique. Un CSV ne restaure pas une application — il ne porte ni les liens entre vos tables, ni l'historique, ni ce qui a été supprimé. Il sert à reprendre la main : ouvrir vos chiffres dans un tableur, les transmettre à votre comptable, alimenter un autre outil. C'est ce qui vous empêche d'être captif, pas ce qui vous protège d'une panne.
Ce qui n'est PAS fait, et qu'il faut décider
Quand votre application est déployée, elle reçoit sa propre base de données PostgreSQL. Et rien dans la chaîne de déploiement ne la sauvegarde : il n'y a aucune commande de sauvegarde dans le code qui déploie les applications. Ce n'est pas un oubli qu'on tait, c'est une frontière — la sauvegarde dépend de l'endroit où l'application tourne, donc elle appartient à celui qui l'héberge, que ce soit vous, votre prestataire, ou nous quand nous l'hébergeons.
Trois questions suffisent à la lever, et il faut les poser avant de saisir des données réelles. Qui produit la copie, et à quelle fréquence ? Où est-elle gardée — ailleurs que sur la machine qui fait tourner l'application, sinon la même panne emporte les deux ? Et surtout : quelqu'un a-t-il déjà RESTAURÉ à partir de cette copie ? La troisième est celle qu'on oublie, et c'est la seule qui prouve quelque chose : une sauvegarde jamais restaurée n'est pas une sauvegarde, c'est une hypothèse.
Ce que ça change selon ce que vous y mettez
Tout ne mérite pas le même dispositif. Pour un outil dont le contenu se reconstitue — un planning de la semaine, un suivi léger qu'on retape en une heure — un export mensuel rangé quelque part suffit largement. Pour un registre qui ne se reconstitue pas, en revanche — vos adhérents, l'historique de vos interventions, vos dossiers en cours —, la sauvegarde automatisée de la base est un préalable et non une option : personne ne réécrit trois ans d'historique de mémoire.
La bonne nouvelle est qu'il n'y a aucun obstacle technique : le code généré est du Next.js et du Prisma standard sur une base PostgreSQL, sans format propriétaire à contourner, et sauvegarder une base PostgreSQL est une opération que sait faire n'importe quel prestataire. La question n'est donc jamais « est-ce possible ? » mais « qui le fait, depuis quand, et l'a-t-on vérifié une fois ? ».