Un lundi matin, l’entreprise passe en mode incident : l’ERP ne répond plus, l’ecommerce continue de recevoir des commandes, et l’équipe opérations ne sait pas s’il faut arrêter ou continuer. Tout le monde suppose que « des sauvegardes existent ». Personne ne sait combien de temps prendra la reprise, ni quel système doit revenir en premier.

Avoir des copies ne signifie pas pouvoir reprendre l’activité.

Cette différence paraît évidente jusqu’à une attaque par ransomware, une corruption de données ou une panne d’un fournisseur cloud. À ce moment-là, la question inconfortable surgit : protégeait-on les données, ou la continuité d’activité ?

Le vrai problème n’est pas de stocker, mais de restaurer

Beaucoup d’architectures de sauvegarde sont conçues pour cocher une case : copies quotidiennes, rétention de 30 jours, stockage hors du serveur principal. Cela réduit le risque de perte définitive, mais ne résout pas le temps de retour à la normale.

La restauration échoue pour des raisons très concrètes :

• Personne n’a testé une restauration complète, seulement quelques fichiers.
• Les dépendances ne sont pas documentées : base de données, files d’attente, identifiants, DNS, certificats, tâches planifiées.
• Les données ont été copiées, mais pas la configuration.
• L’ordre de redémarrage n’est pas défini.
• Personne ne sait quelles données sont critiques pour relancer la facturation.

Si une entreprise vend en ligne, facture des abonnements ou dépend du service client, l’objectif n’est pas de « tout récupérer un jour ». L’objectif est de remettre d’abord en route ce qui maintient l’entreprise en vie.

Ce qu’il faut mesurer avant d’acheter un autre outil

Avant de choisir un nouvel outil, il faut répondre à ces questions :

• Quel est le RTO réellement acceptable par système ? Pas le RTO théorique, celui que la direction accepte.
• Quel est le RPO acceptable pour les commandes, la comptabilité, le CRM et les documents ?
• Quels systèmes doivent être restaurés en séquence et lesquels peuvent attendre ?
• Quelles dépendances externes feraient échouer la reprise même si la sauvegarde est intacte ?
• Qui valide que les données restaurées sont réellement exploitables ?

Un bon plan de sauvegarde pour une PME n’a pas besoin d’être sophistiqué, mais il doit être explicite. Il doit préciser quoi est sauvegardé, à quelle fréquence, où c’est stocké, comment c’est chiffré, qui peut supprimer les copies et comment les restaurations sont testées.

En pratique, cela signifie souvent combiner plusieurs couches :

• Sauvegarde immuable ou protégée contre la suppression accidentelle.
• Copie séparée par compte, région ou fournisseur lorsque le risque le justifie.
• Tests réguliers de restauration complète, pas seulement partiels.
• Versioning et rétention alignés sur les besoins légaux et opérationnels.
• Runbook clair pour une restauration priorisée.

L’erreur inconfortable : choisir la sauvegarde la moins chère et appeler ça une stratégie

Voici la décision qui dérange : beaucoup d’entreprises achètent une sauvegarde comme une assurance générique. Elles comparent le coût par gigaoctet et oublient le coût réel d’un arrêt.

Cela mène souvent à trois erreurs :

1. Conserver trop de données trop longtemps sans savoir pourquoi.
2. S’appuyer sur une seule couche de protection.
3. Ne pas budgéter les tests de restauration.

Les tests sont la partie la moins glamour et la plus précieuse. Ils révèlent souvent des problèmes que le fournisseur ne voit pas : des droits qui empêchent une base de données de redémarrer, des identifiants expirés, des scripts liés à un ancien chemin, ou des intégrations qui ne se reconnectent pas après la restauration.

Dans certains cas, la meilleure décision n’est pas de tout garder « toujours prêt », mais de définir ce qui peut être reconstruit de zéro et ce qui exige une reprise rapide. Tous les systèmes ne méritent pas le même niveau de criticité.

Mini-cas : la sauvegarde existait, mais l’entreprise ne pouvait toujours pas opérer

Dans une entreprise moyenne avec ecommerce et logistique interne, les sauvegardes cloud étaient automatisées et l’équipe se sentait protégée. Le problème est apparu lors d’un vrai test de restauration : la base de données revenait, mais les traitements planifiés, les clés d’intégration avec le transporteur et plusieurs droits utilisateurs n’étaient pas inclus dans le plan.

Résultat : les données étaient visibles, mais les commandes ne pouvaient pas être traitées.

La solution n’a pas été d’acheter plus de stockage. Elle a consisté à redessiner la continuité avec trois décisions concrètes : prioriser les services, documenter les dépendances et réaliser des exercices de reprise trimestriels. En moins de deux exercices, ils ont découvert des défaillances qui auraient coûté des heures de facturation et de service.

Les signaux qui montrent que votre sauvegarde n’est pas prête pour un incident

Certains symptômes sont faciles à reconnaître :

• Personne n’a effectué de restauration complète depuis 90 jours.
• Le plan de reprise vit dans un document que personne ne consulte.
• Il n’existe pas d’ordre de priorité par processus métier.
• Les sauvegardes dépendent du même fournisseur ou des mêmes identifiants que la production.
• L’équipe suppose que « si cela arrive, on improvisera ».

Si vous voyez deux de ces signaux ou plus, vous n’avez pas seulement une dette technique. Vous avez une dette opérationnelle.

La conclusion est simple : une sauvegarde utile n’est pas celle qui stocke le plus, mais celle qui réduit le temps et l’incertitude pour remettre l’activité en marche. Si ce sujet touche votre ERP, votre ecommerce, votre cloud ou votre DevOps, chez Codefuente nous commençons généralement par la continuité réelle, pas par l’outil.