Une entreprise peut avoir des sauvegardes quotidiennes, de la réplication cloud et un prestataire qui “stocke tout”, et pourtant rester bloquée pendant des heures ou des jours quand un incident survient. Le problème n’est généralement pas l’absence de copies. Le problème est de confondre avoir une sauvegarde et être capable de restaurer.

Une sauvegarde qu’on ne peut pas restaurer dans le délai dont l’entreprise a besoin n’est pas un plan de continuité ; c’est une assurance théorique.

La discussion sérieuse ne commence pas par la technologie. Elle commence par une question inconfortable : combien de temps l’activité peut-elle rester arrêtée avant d’impacter les ventes, la facturation, le support client ou la production ? Une fois cette limite connue, la conversation change. Il ne s’agit plus de “conserver des données”, mais de concevoir un système de reprise capable d’absorber la réalité opérationnelle.

Le faux confort du “on a déjà des sauvegardes”

Dans beaucoup de PME, la sauvegarde est traitée comme une tâche administrative. On active une politique, on stocke une copie dans le cloud et l’on considère le sujet réglé. L’échec apparaît au moment où une vraie restauration est nécessaire.

Les symptômes sont assez prévisibles :

• personne n’a testé une restauration complète depuis des mois ou des années ;
• la sauvegarde se trouve dans le même compte, tenant ou domaine que la production ;
• personne ne sait quelles données sont critiques et lesquelles peuvent attendre ;
• la reprise dépend d’une seule personne qui “sait comment faire” ;
• le temps de restauration ne correspond pas au maximum de coupure tolérable.

L’erreur de fond est de traiter la sauvegarde comme du stockage. Sur le plan opérationnel, la sauvegarde est une capacité de réponse. Si vous ne pouvez pas estimer le délai de reprise, la perte de données acceptable et l’ordre de restauration des systèmes, alors vous n’avez pas un design de résilience. Vous avez une politique de copie.

Ce que signifie vraiment “reprendre”

Reprendre ne veut pas simplement dire revoir les fichiers. Cela veut dire restaurer le bon service, avec une intégrité suffisante, dans le bon ordre. En contexte métier, cela implique souvent trois niveaux :

1. Restauration technique : les données existent et peuvent être remontées.
2. Restauration fonctionnelle : les processus critiques redémarrent sans erreurs majeures.
3. Restauration opérationnelle : l’entreprise peut facturer, expédier, répondre au support ou continuer à produire.

Exemple réaliste : un distributeur de taille moyenne perd l’accès à son ERP et à une partie de son référentiel documentaire à cause d’une corruption de stockage. L’entreprise a des sauvegardes nocturnes. Sur le papier, elle est couverte. Mais lors du test, elle découvre que la restauration de l’ERP dans le même environnement compromis ramène les mêmes droits cassés, que les pièces jointes ne correspondent plus aux commandes et que l’équipe opérationnelle ne sait pas quel processus relancer en premier. Le problème n’était pas la sauvegarde. C’était l’absence d’un runbook de reprise et d’une priorisation claire des services.

Les bonnes questions sont beaucoup plus précises :

• Quels systèmes sont restaurés en premier, et pourquoi ?
• Quel est le RTO de chaque système critique ?
• Quel RPO est acceptable pour les commandes, la comptabilité, le stock ou le support ?
• La reprise se fait-elle dans un environnement isolé ou sur le même périmètre ?
• Qui valide la cohérence des données restaurées ?

L’erreur inconfortable : sauvegarder sans isoler le risque

Voici la décision que beaucoup d’organisations évitent : une sauvegarde trop proche de l’infrastructure de production peut elle aussi être attaquée, chiffrée ou supprimée. En cas de ransomware, il ne suffit pas que la copie existe ; elle doit être isolée, immuable, ou au minimum protégée par des contrôles d’accès très différents de ceux de la production.

Cela impose un arbitrage inconfortable : le dispositif de reprise le plus sûr n’est pas toujours le plus simple à administrer. Il peut nécessiter des comptes séparés, des politiques d’immutabilité, des règles de rétention distinctes et des permissions qui ne suivent pas la logique quotidienne.

Il y a aussi un arbitrage économique. Plus de rétention, plus de copies et plus de tests coûtent du temps et de l’argent. La question n’est pas de savoir si cela coûte, mais combien coûte une interruption. Si la réponse est “beaucoup”, la sauvegarde bon marché revient très cher.

Comment savoir si votre stratégie est sérieuse

Pas besoin d’un laboratoire parfait pour progresser. En revanche, il faut mesurer. Ces critères séparent souvent une stratégie décorative d’une stratégie utile :

• Tests réguliers de restauration : pas seulement vérifier que la sauvegarde s’exécute, mais restaurer de vrais systèmes ou des sous-ensembles représentatifs.
• Isolation du référentiel : comptes, identifiants ou domaines d’administration séparés.
• Immutabilité ou protection contre la suppression : particulièrement si le ransomware est un risque réel.
• Priorisation par impact : tous les systèmes ne méritent pas le même objectif de reprise.
• Documentation opérationnelle simple : runbook clair avec étapes, responsables et validation.
• Télémétrie de reprise : savoir combien de temps prend chaque restauration et où elle échoue.

Si une entreprise ne peut pas répondre avec des chiffres à “dans combien de temps sommes-nous de nouveau opérationnels ?” et “combien de données pouvons-nous perdre sans casser l’activité ?”, alors le plan n’est pas mûr.

Une règle pratique pour décider d’investir

Il faut penser sauvegarde et continuité comme un portefeuille de risques. On ne protège pas la comptabilité comme un archive marketing. On ne restaure pas un fichier historique comme un ERP de commandes. Et on ne justifie pas le même niveau de protection pour tout.

Le bon réflexe est de classer les systèmes par criticité et de fixer un objectif réaliste pour chacun. Parfois, cela signifie renforcer seulement trois points : le référentiel le plus critique, la procédure de restauration et le test périodique. D’autres fois, cela oblige à repenser complètement la stratégie de sauvegarde.

Le vrai changement est là : arrêter de demander “avons-nous une sauvegarde ?” et commencer à demander “que se passe-t-il si nous devons l’utiliser demain à 9 h ?”.

Chez Codefuente, nous abordons souvent ces sujets avec la continuité opérationnelle, le cloud et la sécurité, parce que la réponse n’est presque jamais uniquement technique : elle touche aussi au processus, aux dépendances et aux vraies priorités de l’entreprise.