Le jour où vous découvrez que vos sauvegardes ne se restaurent pas

Tout incident grave commence par une certitude rassurante : « Pas d'inquiétude, on a des sauvegardes. » Puis vient le moment de vérité. Une base de données est corrompue, un ransomware a chiffré les volumes, une suppression accidentelle a effacé des mois de données. On lance la restauration… et rien ne se passe comme prévu. Le dernier backup exploitable date de plusieurs semaines. Le fichier est corrompu. La sauvegarde existait bien, mais elle ne contenait pas ce qu'on croyait. Ou pire : le job de sauvegarde échouait silencieusement depuis des mois, sans que personne ne le remarque.

Ce scénario est l'un des plus redoutés de l'administrateur cloud, parce qu'il combine deux catastrophes : la perte de données du client et la révélation que le filet de sécurité censé l'empêcher n'a jamais été fonctionnel. La règle, brutale mais juste, mérite d'être affichée en grand :

Une sauvegarde qui n'a jamais été restaurée avec succès n'est pas une sauvegarde. C'est une hypothèse.

Sur le terrain, l'écart entre « on sauvegarde » et « on est capable de restaurer » est immense — et c'est précisément dans cet écart que se loge la responsabilité de l'administrateur.

L'administrateur cloud n'est pas tenu de garantir qu'aucune donnée ne sera jamais perdue — ce serait une obligation de résultat irréaliste face à un ransomware sophistiqué ou à une défaillance imprévisible. Vous êtes soumis à une obligation de moyens, mais une obligation de moyens renforcée sur un point précis : la mise en place et la vérification d'une stratégie de sauvegarde et de reprise crédible.

Concrètement, on attend d'un professionnel diligent qu'il :

• conçoive une politique de sauvegarde adaptée à la criticité des données du client ;
• configure les sauvegardes de façon à couvrir réellement les données importantes (et pas seulement une partie) ;
• vérifie périodiquement que la restauration fonctionne, par des tests réels et non théoriques ;
• surveille l'exécution des jobs et soit alerté en cas d'échec ;
• documente l'ensemble, pour pouvoir en rendre compte.

La nuance juridique est décisive. Si une perte de données survient malgré une stratégie sérieuse, testée et documentée, votre responsabilité a de bonnes chances d'être écartée : vous avez fait ce qu'un professionnel raisonnable devait faire. Si elle survient parce que les sauvegardes n'avaient jamais été testées, échouaient en silence, ou ne couvraient pas les bonnes données, la faute devient caractérisée. La frontière entre la mise hors de cause et la condamnation tient souvent à une seule question : « Aviez-vous vérifié que ça se restaurait ? »

Une erreur de raisonnement revient sans cesse : croire que, parce que les données sont chez AWS, Azure ou GCP, le fournisseur s'occupe de tout. C'est une lecture fausse du modèle de responsabilité partagée, et elle peut coûter cher.

Dans ce modèle, le provider est responsable de la sécurité du cloud : la durabilité physique du stockage, la disponibilité de l'infrastructure, la résilience des centres de données. Le client — et donc, par délégation, son administrateur — reste responsable de la sécurité dans le cloud : la configuration, les accès, et surtout la stratégie de sauvegarde et de récupération des données applicatives.

Autrement dit, le fournisseur garantit qu'un objet stocké ne disparaîtra pas tout seul. Il ne garantit pas que vous avez correctement configuré vos sauvegardes, qu'elles couvrent les bonnes données, qu'elles sont conservées assez longtemps, ni qu'elles sont restaurables. Quelques exemples de pièges classiques :

• activer la réplication d'une base ne remplace pas une sauvegarde : une corruption ou une suppression se réplique aussi instantanément ;
• une rétention de sauvegarde trop courte (quelques jours) ne protège pas contre un incident détecté tardivement ;
• les snapshots automatiques d'un service managé peuvent être supprimés en même temps que l'instance, si la configuration n'a pas prévu de copie indépendante ;
• une sauvegarde stockée dans le même compte et la même région qu'un système compromis peut être chiffrée ou effacée par l'attaquant.

Le provider ne vous protège d'aucun de ces scénarios. Ils relèvent tous de la conception de la stratégie — c'est-à-dire de votre périmètre.

Deux indicateurs structurent toute stratégie de reprise sérieuse. Les maîtriser, et surtout les vérifier, est au cœur de votre devoir professionnel.

Le RPO (Recovery Point Objective) définit la quantité maximale de données que l'on accepte de perdre, exprimée en temps : un RPO de 1 heure signifie que l'on peut perdre au plus une heure de données. Il dépend directement de la fréquence des sauvegardes.

Le RTO (Recovery Time Objective) définit le délai maximal acceptable pour remettre le service en route après un incident : un RTO de 4 heures signifie que tout doit être restauré et fonctionnel en quatre heures.

Le danger, c'est de manier ces chiffres comme des promesses commerciales sans jamais les éprouver. Annoncer un RTO de 4 heures alors qu'une restauration complète prend en réalité une journée entière, ou afficher un RPO d'une heure quand les sauvegardes ne tournent qu'une fois par nuit, c'est créer un écart entre l'engagement et la réalité. Le jour de l'incident, cet écart se retourne contre vous.

La seule façon de transformer ces objectifs en engagements solides est de les tester : restaurer pour de vrai, sur un environnement isolé, mesurer le temps réel, vérifier l'intégrité des données récupérées. Un test de restauration daté et documenté est à la fois votre meilleure assurance opérationnelle et votre meilleure preuve en cas de litige.

La différence entre un administrateur qui dort tranquille et un autre qui joue à la roulette tient à quelques habitudes méthodiques. Aucune n'est complexe ; leur absence, en revanche, coûte très cher.

1. Testez la restauration, pas seulement la sauvegarde. Programmez des restaurations réelles à intervalles réguliers, sur un environnement dédié. Une sauvegarde non restaurée reste une hypothèse jusqu'à preuve du contraire.
2. Surveillez les échecs de jobs. Mettez en place des alertes sur l'échec d'une sauvegarde. Un job qui échoue en silence pendant des semaines est la cause numéro un des mauvaises surprises.
3. Appliquez la règle 3-2-1. Trois copies des données, sur deux supports différents, dont une copie hors site (autre compte, autre région). Une sauvegarde stockée à côté du système qu'elle protège ne protège de rien en cas de compromission globale.
4. Vérifiez la couverture et la rétention. Assurez-vous que toutes les données critiques sont incluses et conservées assez longtemps pour absorber un incident détecté tardivement. Beaucoup de pertes viennent de données simplement oubliées dans le périmètre.
5. Documentez et cadrez par écrit. Politique de sauvegarde, RPO et RTO engagés, résultats des tests : tout doit être écrit. En cas de litige, cette documentation établit que vous avez agi en professionnel diligent.

Ces réflexes, en plus de protéger les données de vos clients, constituent votre ligne de défense : un administrateur capable de prouver qu'il testait régulièrement ses restaurations part avec une longueur d'avance le jour d'une mise en cause.

Malgré toutes les précautions, le risque zéro n'existe pas. Une perte de données chez un client se traduit presque toujours par un préjudice chiffrable : interruption d'activité, perte de chiffre d'affaires, reconstitution manuelle de données, perte de confiance. Si le client estime que la défaillance de la sauvegarde vous est imputable, il peut se retourner contre vous en invoquant un manquement à votre obligation de moyens.

C'est exactement ce que couvre la RC Professionnelle d'administrateur cloud d'Insurio : les conséquences financières d'une faute, erreur ou omission dans vos prestations, y compris une perte de données ou une indisponibilité résultant d'une sauvegarde défaillante, ainsi que vos frais de défense, dans la limite du plafond souscrit. La garantie des dommages immatériels est ici déterminante, car le préjudice du client est avant tout financier : il faut donc vérifier qu'elle figure bien à votre contrat.

Mais l'assurance n'intervient qu'après le sinistre, alors que la prévention permet souvent de l'éviter : c'est la combinaison « stratégie testée + documentation + couverture adaptée » qui vous protège réellement. Pour mesurer l'ensemble des risques propres à votre activité d'infrastructure, consultez aussi notre page assurance architecte systèmes, réseaux et cloud. Le bon réflexe avant chaque mission : ne jamais affirmer « on a des sauvegardes » sans pouvoir ajouter « et nous avons vérifié qu'elles se restaurent ».