La sauvegarde qui ne se restaure pas : le sinistre silencieux du DBA

Le scénario ne commence jamais par une catastrophe spectaculaire. Il commence par une routine qui fonctionne, mois après mois, sans la moindre alerte. Le job de sauvegarde s'exécute chaque nuit, le rapport indique succès, l'espace disque se remplit comme prévu. Tout le monde dort tranquille, vous le premier.

Puis survient l'événement : une corruption du fichier de données après une coupure électrique, un ransomware qui chiffre les volumes, ou une commande de purge lancée sur le mauvais environnement. Peu importe la cause d'origine. Vous lancez la restauration, sereinement, parce que vous avez des sauvegardes. Et là, la restauration échoue. Le fichier est tronqué, le jeu de sauvegarde incohérent, la chaîne de logs de transactions cassée depuis trois semaines sans que personne l'ait remarqué.

C'est ce que l'on appelle un sinistre silencieux : la défaillance était déjà présente longtemps avant l'incident qui la révèle. Et dans l'esprit du client, le responsable n'est pas la coupure électrique ni l'attaquant. C'est vous, l'administrateur dont la mission contractuelle était précisément de garantir la récupérabilité.

Il faut distinguer deux fautes que les clients confondent souvent, mais que les juristes séparent nettement. La première est l'événement déclencheur : la panne matérielle, l'attaque, l'erreur de manipulation. Vous n'en êtes généralement pas l'auteur. La seconde est l'incapacité à restaurer : et celle-ci, si votre périmètre incluait la stratégie de sauvegarde, vous est directement imputable.

La jurisprudence française est constante sur ce point : le prestataire informatique est tenu d'une obligation de moyens renforcée sur la sécurité et la sauvegarde des données qui lui sont confiées. Un administrateur qui met en place un plan de sauvegarde sans jamais en vérifier la restaurabilité commet une négligence caractérisée. L'argument « les sauvegardes tournaient » ne tient pas devant un tribunal : une sauvegarde non testée est juridiquement assimilée à une absence de sauvegarde.

Une sauvegarde n'existe pas tant qu'on ne l'a pas restaurée. Tant qu'aucune restauration test n'a réussi, vous ne possédez qu'un fichier dont vous espérez qu'il fonctionne.

Le reproche se cristallise donc sur l'absence de procédure de vérification : pas de restauration test périodique, pas de contrôle d'intégrité, pas de documentation du RPO (objectif de point de reprise) ni du RTO (objectif de temps de reprise) acceptés avec le client. C'est cette zone qui transforme un aléa en faute professionnelle indemnisable.

Prenons un cas réaliste. Un éditeur de logiciel de gestion vous confie l'administration de sa base de production hébergée sur un serveur dédié. Pendant huit mois, vos sauvegardes complètes hebdomadaires et incrémentales quotidiennes s'exécutent sans erreur visible. Un incident de stockage corrompt la base un lundi matin. La restauration révèle que le dernier jeu cohérent remonte à six semaines, à cause d'une option de compression mal configurée qui invalidait les fichiers depuis.

Face à un tel montant, votre prestation mensuelle d'administration devient anecdotique. Ce n'est pas le prix de votre travail qui est en jeu, c'est le préjudice subi par le client du fait de votre carence. Sans assurance, c'est votre patrimoine personnel qui répond.

Une réclamation n'aboutit pas toujours à une responsabilité de 100 % à votre charge. Le client a, lui aussi, des devoirs : valider la stratégie de sauvegarde proposée, allouer les ressources de stockage, accepter le niveau de service. La répartition réelle des torts dépend de ce qui a été convenu, et surtout de ce qui a été tracé.

Or c'est précisément là que beaucoup d'administrateurs perdent leur procès avant de l'avoir plaidé. Sans échange écrit, le client soutiendra qu'il vous avait confié la maîtrise totale de la récupérabilité, et que vous ne l'avez jamais alerté sur une limite. À l'inverse, un DBA qui peut produire un courriel où il recommandait des restaurations tests, refusées ou non budgétées par le client, déplace une part substantielle de la responsabilité.

Trois preuves pèsent lourd dans ce partage :

• les recommandations écrites que vous avez formulées et leur réception par le client ;
• les alertes sur les limites du dispositif (rétention, fréquence, absence de test) ;
• la validation du niveau de service par un interlocuteur identifié côté client.

Ce travail de traçabilité ne supprime pas l'utilité de l'assurance, mais il en conditionne souvent l'issue : un assureur défend d'autant mieux son assuré que celui-ci a documenté sa diligence.

Tous les contrats d'assurance ne se valent pas face à ce sinistre. Le poste décisif s'appelle les dommages immatériels non consécutifs : il s'agit du préjudice financier subi par le client sans qu'il y ait eu de dommage matériel préalable couvert. La perte d'exploitation liée à des données irrécupérables entre exactement dans cette catégorie.

Beaucoup de contrats grand public excluent ou plafonnent très bas ces dommages immatériels non consécutifs, qui sont pourtant la signature même du métier de DBA. Vérifiez trois lignes dans vos conditions particulières :

• le plafond dédié aux dommages immatériels non consécutifs, qui doit être cohérent avec la criticité des bases que vous administrez ;
• l'absence d'exclusion sur la perte de données en tant que telle ;
• la couverture des frais de reconstitution de données, souvent le poste le plus lourd.

Une assurance RC Pro calibrée pour les métiers de la data couvre la faute, l'erreur de configuration et les dommages immatériels qui en découlent. C'est le socle indispensable pour un administrateur de base de données qui prend en charge la stratégie de sauvegarde d'un tiers.

L'assurance indemnise, mais le meilleur sinistre reste celui qui n'arrive pas. Trois pratiques réduisent à la fois votre exposition juridique et la probabilité d'une réclamation.

1. Restauration test documentée et datée. Restaurez réellement vos sauvegardes dans un environnement isolé, à intervalle régulier, et conservez la preuve de chaque test. Ce journal est votre première ligne de défense en cas de litige.
2. Formalisation contractuelle du RPO et du RTO. Faites signer au client le niveau de service attendu : combien de données il accepte de perdre, combien de temps il accepte d'attendre. Sans cet accord, le client réclamera toujours le zéro-perte, et vous serez réputé l'avoir promis.
3. Supervision active des chaînes de sauvegarde. Un succès rapporté n'est pas une garantie d'intégrité : ajoutez des contrôles de cohérence et des alertes sur la chaîne de logs, pas seulement sur l'exécution du job.

Ces réflexes ne suppriment pas le risque résiduel, qui justifie pleinement votre couverture. Si votre activité touche aussi à la conformité des données personnelles ou à la défense face à une attaque, l'assurance cyber vient compléter utilement votre RC Pro. Vous retrouvez le détail des garanties propres à votre métier sur la page assurance administrateur de base de données.