Comment sauvegarder la base de données de votre application (et la restaurer vraiment)

Pour sauvegarder la base de données de votre application, exportez-la dans un fichier selon un calendrier (pour Postgres, l'outil standard est pg_dump), conservez les copies à un endroit distinct de la base de données, et restaurez régulièrement une copie dans une base de données vide pour prouver qu'elle fonctionne. Faites une sauvegarde supplémentaire juste avant tout changement risqué. Votre sauvegarde du code, qu'il s'agisse d'un dépôt GitHub ou d'un export, ne contient pas vos données.

Ce guide s'adresse aux personnes qui gèrent une petite application et veulent cesser de craindre de la perdre. Il utilise Postgres pour les exemples, car la plupart des applications créées avec l'IA s'appuient dessus, mais les principes valent pour toute base de données.

Ce que doit couvrir une sauvegarde

Une application ne se résume pas à sa base de données. Sachez quelle partie chaque sauvegarde protège.

Les données sont la partie que vous ne pouvez pas recréer. Le code peut être réécrit et les réglages ressaisis ; les commandes de vos clients, non.

Étape 1 : décider de la quantité de données que vous pouvez perdre

Deux questions déterminent votre plan de sauvegarde :

• Quelle quantité de données récentes pouvez-vous perdre ? Si vous sauvegardez une fois par jour et que la base tombe le soir, vous perdez les modifications de la journée. Pour une application de loisir, c'est acceptable. Pour une application qui prend des commandes, peut-être pas.
• Combien de temps l'application peut-elle être indisponible pendant la restauration ? Une petite base se restaure en quelques minutes. Une grosse base peut prendre beaucoup plus de temps, et il vaut mieux le savoir avant d'en avoir besoin.

Pour la plupart des petites applications, une sauvegarde automatique quotidienne, complétée par une sauvegarde manuelle avant les changements risqués, est un bon point de départ. Les applications qui manipulent de l'argent ou des données de santé méritent des sauvegardes plus fréquentes, ou une base de données gérée avec récupération à un instant précis (la possibilité de restaurer à n'importe quel moment, et pas seulement à la dernière sauvegarde).

Étape 2 : vérifier ce que fait déjà votre hébergeur

De nombreux fournisseurs de bases de données gérées effectuent des sauvegardes automatiques. Renseignez-vous :

• Les sauvegardes sont-elles activées pour votre forfait, et à quelle fréquence sont-elles effectuées ?
• Combien de temps sont-elles conservées ?
• Pouvez-vous restaurer à un instant précis, ou seulement à un instantané quotidien ?
• Pouvez-vous télécharger une sauvegarde, ou seulement la restaurer dans leur système ?

Les sauvegardes du fournisseur sont utiles, mais elles partagent un point de défaillance unique avec votre base : le compte. Si le compte est fermé, suspendu ou si le projet est supprimé, les sauvegardes peuvent disparaître avec lui. C'est pourquoi vous voulez aussi votre propre copie.

Étape 3 : créer un export avec pg_dump

pg_dump exporte une base Postgres dans un fichier. Il lit un instantané cohérent, de sorte que l'application peut continuer de fonctionner pendant l'opération.

Une commande typique, utilisant la chaîne de connexion que votre application possède déjà dans une variable d'environnement :

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=sauvegarde-2026-09-29.dump

Rôle des options :

• --format=custom écrit un fichier compressé que pg_restore peut lire, et permet de restaurer plus tard une seule table. Utilisez --format=plain si vous préférez un fichier .sql lisible.
• --no-owner omet les commandes de propriété, ce qui simplifie la restauration dans une autre base.
• La date dans le nom du fichier permet de distinguer les sauvegardes.

La version de pg_dump doit être identique ou plus récente que la version de Postgres de votre base. Une version plus ancienne de pg_dump peut refuser de s'exécuter.

Si vous construisez avec l'IA et que vous ne voulez pas toucher à la ligne de commande, vous pouvez demander :

Crée une sauvegarde de la base de données de l'application avec pg_dump au format custom, avec la date du jour dans le nom du fichier. N'affiche pas la chaîne de connexion ni aucun secret. Indique-moi le nom du fichier et sa taille une fois terminé.

Étape 4 : automatiser

Les sauvegardes manuelles finissent par être oubliées. Automatisez-les avec ce que propose votre installation :

• Les sauvegardes planifiées de votre fournisseur de base de données, s'il en propose.
• Une tâche planifiée sur un serveur ou un service CI qui exécute pg_dump et envoie le fichier vers un stockage.
• Un service de sauvegarde hébergé qui se connecte à votre base.

Quelle que soit votre solution, faites-la vous prévenir en cas d'échec. Une tâche de sauvegarde qui a échoué discrètement pendant trois mois est le classique cauchemar.

Étape 5 : conserver des copies ailleurs

La règle empirique, souvent appelée 3-2-1, consiste à avoir trois copies de vos données, sur deux types de stockage différents, dont une copie hors site. Pour une petite application, une version pratique consiste à avoir :

• La base de données active
• Les sauvegardes automatiques du fournisseur
• Vos propres exports dans un stockage séparé, comme un bucket de stockage d'objets rattaché à un autre compte

Par ailleurs :

• Limitez l'accès. Une sauvegarde contient les données de chaque utilisateur. Traitez-la comme la base active.
• Définissez une politique de conservation. Par exemple, des sauvegardes quotidiennes pendant deux semaines et mensuelles pendant un an. Supprimez les anciennes de façon délibérée, et rappelez-vous que les lois sur la vie privée peuvent vous obliger à effacer les données personnelles sur demande.
• Ne versionnez jamais les sauvegardes dans Git. Un export dans un dépôt est une fuite de données qui n'attend que de se produire.

Étape 6 : tester une restauration

Une sauvegarde ne vaut que par votre dernière restauration réussie. Au moins tous les quelques mois, et après toute modification du processus de sauvegarde :

1. Créez une nouvelle base de données vide. Ne restaurez jamais par-dessus la base active pour faire un test.
2. Restaurez la dernière sauvegarde dans cette base :

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" sauvegarde-2026-09-29.dump

Pour un fichier .sql brut, utilisez plutôt psql "$TEST_DATABASE_URL" -f sauvegarde.sql.

1. Vérifiez que chaque table existe, comparez le nombre de lignes avec la base active et examinez quelques enregistrements récents.
2. Connectez-y une copie de l'application et connectez-vous, si possible.
3. Notez la durée de la restauration. C'est votre véritable délai de reprise.

Étape 7 : sauvegarder avant les changements risqués

Faites une sauvegarde fraîche juste avant :

• Une migration de base de données qui supprime ou renomme des colonnes
• Un import massif de données
• Le fait de laisser un agent IA effectuer de gros changements sur le modèle de données
• La suppression d'anciens enregistrements

Dans une application créée avec l'IA, l'agent peut modifier la structure des tables dans le cadre d'une fonctionnalité. Les points de contrôle et le contrôle de version annulent les modifications de code, mais ils ne restaurent pas les lignes supprimées. Une sauvegarde de trente secondes avant un gros changement est une assurance peu coûteuse.

Erreurs courantes

• Croire que Git ou un export de code est une sauvegarde. Il contient le code, pas les données.
• Ne jamais tester une restauration. Beaucoup de sauvegardes s'avèrent vides, partielles ou illisibles uniquement au moment où on en a besoin.
• Garder les sauvegardes dans le même compte que la base. Un compte compromis ou fermé fait perdre les deux.
• Oublier les fichiers téléversés. La base stocke le chemin du fichier ; l'image elle-même se trouve dans le stockage.
• Laisser des secrets dans les scripts de sauvegarde. Lisez la chaîne de connexion depuis une variable d'environnement, jamais depuis le texte du script. Voir comment protéger vos clés d'API.

Sauvegardes et Mythex

Les projets Mythex peuvent disposer d'une base Postgres dédiée, dont les paramètres de connexion sont injectés dans l'espace de travail et dans l'application publiée. La documentation Mythex ne décrit pas de fonctionnalité de sauvegarde ou de restauration de base de données, prévoyez donc la vôtre : demandez à l'agent de créer un export, téléchargez-le et conservez-le en lieu sûr, surtout avant les gros changements. Un export du projet (Pro) contient votre code, sans les secrets ni node_modules ; il ne contient pas les lignes de la base. Voir Base de données et Propriété des données dans la documentation. Pour en savoir plus sur la base elle-même, lisez qu'est-ce que Postgres.

Liste de contrôle des sauvegardes

• Vous avez défini la quantité de données que vous pouvez perdre et le temps d'indisponibilité acceptable
• Vous avez vérifié les sauvegardes automatiques proposées par votre hébergeur de base de données
• Votre export propre s'exécute selon un calendrier, et ses échecs vous alertent
• Les copies sont stockées séparément de la base, avec un accès restreint
• La politique de conservation est écrite noir sur blanc
• Les fichiers téléversés sont sauvegardés en plus de la base
• Une restauration a été testée dans une base vide, et le nombre de lignes vérifié
• Une sauvegarde est faite avant chaque changement risqué

Questions