Sommaire
Un plan de sauvegarde part de deux seuils : la perte de données maximale admissible et la durée d’arrêt maximale admissible. L’ANSSI recommande trois copies des données sur deux supports différents, dont une hors ligne et des restaurations testées régulièrement. Une sauvegarde jamais restaurée n’est pas une sauvegarde.
Une base de données supprimée par erreur, un compte d’administration piraté, un rançongiciel, un hébergeur en panne : le jour où l’outil métier s’arrête, la question n’est plus « avons-nous des sauvegardes ? » mais « combien de temps pour repartir et avec quelles données ? ». Voici la méthode que j’applique pour y répondre avant l’incident, en m’appuyant sur les recommandations de l’ANSSI.
Deux seuils à fixer avant tout
L’ANSSI, dans son guide Les fondamentaux de la sauvegarde des systèmes d’information (version 1.1 du 27 novembre 2025, consultée le 27 octobre 2026), demande de bâtir la stratégie sur deux valeurs, définies pour chaque activité :
- la perte de données maximale admissible (PDMA, ou RPO en anglais) : combien d’heures de saisie pouvez-vous perdre sans dommage grave ?
- la durée maximale d’interruption admissible (DMIA, ou RTO) : combien de temps pouvez-vous travailler sans l’outil ?
Ces deux chiffres sont des décisions de direction, pas des choix techniques. Ils se fixent avec les responsables métier, en se demandant ce que coûte une journée sans outil ou une demi-journée de commandes à ressaisir.
| Profil d’outil | Perte de données admissible | Durée d’arrêt admissible | Dispositif adapté |
|---|---|---|---|
| Outil interne consulté ponctuellement | 24 heures | 2 à 3 jours | Sauvegarde quotidienne, copie externe, procédure écrite |
| Outil de gestion utilisé chaque jour | Quelques heures | 1 jour | Sauvegarde quotidienne + restauration fine, copie externe, restauration testée |
| Outil critique (commandes, production, portail client) | Moins d’une heure | Quelques heures | Restauration à la minute, réplication, copie hors ligne, plan de reprise répété |
Ces profils sont des exemples d’illustration : vos seuils dépendent de votre activité. L’ANSSI note que lorsque la perte admissible descend sous 24 heures, la réplication devient plus adaptée que la seule sauvegarde.
La règle 3-2-1 et la copie hors ligne
Le guide de l’ANSSI recommande :
- trois copies des données : la production et deux sauvegardes ;
- deux supports différents ;
- au moins une copie hors ligne, déconnectée du système d’information, même si elle est moins fréquente.
La copie hors ligne protège contre le scénario le plus redouté : un attaquant qui obtient les accès d’administration et chiffre ou supprime à la fois la production et les sauvegardes en ligne. L’ANSSI recommande aussi des comptes d’administration des sauvegardes nominatifs et dédiés, distincts de ceux de la production.
Ce que fait vraiment l’hébergeur
Les sauvegardes incluses dans les offres d’hébergement sont un bon point de départ, mais il faut lire ce qu’elles couvrent. Exemple avec Supabase, que j’utilise souvent pour la base de données, d’après sa documentation sur les sauvegardes consultée le 27 octobre 2026 :
- les offres payantes incluent une sauvegarde quotidienne automatique, conservée 7 jours sur l’offre Pro, 14 jours sur l’offre Team et jusqu’à 30 jours sur l’offre Enterprise ;
- une restauration à un instant précis (point-in-time recovery) est disponible en option payante, facturée au mois selon la durée de rétention ;
- la sauvegarde de la base n’inclut pas les fichiers stockés via le service de stockage (documents, photos).
Autrement dit : sans copie complémentaire, une erreur découverte au bout de dix jours sur l’offre Pro n’est plus récupérable et les pièces jointes ne sont pas couvertes par la sauvegarde de la base.
Le plan de reprise : écrit, court, testé
Une sauvegarde sans procédure de restauration ne sert pas le jour J. Le plan de reprise tient en quelques pages :
- qui décide de déclencher la reprise et qui l’exécute, avec les coordonnées à jour ;
- où sont les sauvegardes et comment y accéder si le compte principal est compromis ;
- les étapes de restauration, dans l’ordre : base de données, fichiers, configuration, vérifications ;
- le mode dégradé : comment l’équipe continue à travailler pendant l’arrêt (export récent, procédure papier) ;
- la communication aux utilisateurs et, si des données personnelles sont touchées, l’évaluation de la notification à la CNIL (voir RGPD et application métier).
Le RGPD le demande aussi : l’article 32 du règlement (UE) 2016/679 cite parmi les mesures de sécurité la capacité à rétablir la disponibilité des données et l’accès à celles-ci dans des délais appropriés en cas d’incident. L’ANSSI insiste sur des tests de restauration réguliers. Je recommande au minimum un test réel par an et après chaque évolution majeure de la structure des données.
Quand un dispositif lourd n’est pas justifié
Je le dis franchement : pour un outil interne dont l’arrêt d’une journée ne bloque personne, une sauvegarde quotidienne de l’hébergeur, une copie hebdomadaire exportée sur un autre compte et une procédure de restauration testée une fois suffisent. Payer une restauration à la minute ou une réplication sur deux sites n’a de sens que si la perte de quelques heures de données ou un arrêt d’une demi-journée coûte réellement cher. Le dispositif doit suivre les seuils fixés, pas la peur.
Comment je l’intègre dans un projet
- Au cadrage : fixation des deux seuils avec vous, choix de l’hébergement (voir héberger ses données en France ou dans l’UE).
- Au développement : sauvegardes automatiques, copie indépendante, sauvegarde des fichiers, comptes d’administration séparés.
- À la mise en ligne : premier test de restauration et plan de reprise écrit, remis avec les accès.
- Ensuite : tests périodiques dans le cadre de la maintenance (voir combien coûte la maintenance d’une application).
Ces éléments font partie de toute application métier que je livre. Pour un outil existant, l’audit technique vérifie notamment la base de données et les sauvegardes. Pour estimer un nouveau projet, utilisez l’estimateur.
Questions fréquentes
La sauvegarde de l’hébergeur suffit-elle ?
Rarement à elle seule. Elle protège contre une panne matérielle, mais elle est souvent liée au même compte que la production : une erreur de manipulation, un compte compromis ou un litige avec l’hébergeur peuvent emporter les deux. Une copie indépendante, sur un autre compte ou chez un autre prestataire, complète le dispositif.
À quelle fréquence faut-il tester une restauration ?
Au minimum à chaque évolution importante de l’application et au moins une fois par an, en restaurant réellement les données dans un environnement de test. On mesure au passage le temps nécessaire, qui doit rester compatible avec la durée d’arrêt admissible.
Combien coûte un plan de sauvegarde ?
La mise en place fait partie du projet de développement. Le stockage des copies s’ajoute à l’hébergement, à la charge du client. Les options de restauration fine chez l’hébergeur (à la minute près) coûtent davantage : elles ne se justifient que si la perte de quelques heures de données pose un vrai problème.
Les fichiers déposés dans l’application sont-ils sauvegardés avec la base ?
Pas toujours. Chez certains hébergeurs, la sauvegarde de la base de données n’inclut pas les fichiers stockés à part (PDF, photos, pièces jointes). Il faut le vérifier et prévoir une copie dédiée si nécessaire.