« La sauvegarde, nous l'avons. » C'est la phrase que nous entendons le plus souvent — et elle est presque toujours vraie. Le problème, c'est qu'elle répond à la mauvaise question. La bonne question est autre : si demain matin les systèmes ne démarrent pas, dans combien de temps l'entreprise se remet-elle au travail? Et sur celle-ci, ceux qui ont « la sauvegarde » découvrent souvent qu'ils n'ont pas de réponse.
Une copie n'est pas une reprise
La sauvegarde est un objet : une copie des données, quelque part. La reprise est un processus : sur quel matériel vous restaurez, dans quel ordre vous remettez les services en marche, qui le fait, avec quels identifiants, en suivant quel document. Entre l'objet et le processus, il y a la différence entre ceux qui repartent en quelques heures et ceux qui restent à l'arrêt des jours — avec les services qui appellent, les clients qui attendent et chaque décision prise dans l'urgence.
Cette distinction porte deux noms précis : la data protection, c'est protéger la donnée; la business continuity et le disaster recovery, c'est garantir que l'entreprise continue de fonctionner. Ce sont deux disciplines différentes, et la seconde ne s'achète pas : elle se conçoit.
RTO et RPO : les deux questions à se poser d'abord
Tout plan sérieux part de deux paramètres, qui sont au fond deux questions simples :
- RTO (Recovery Time Objective) : combien de temps pouvez-vous rester à l'arrêt? Tout en découle : un RTO de 4 heures et un RTO de 2 jours conduisent à des architectures — et à des coûts — complètement différents;
- RPO (Recovery Point Objective) : combien de données pouvez-vous vous permettre de perdre? Les heures de travail entre la dernière copie utile et le moment de la panne ne reviennent pas.
Le point qui change la perspective : les RTO et RPO ne se définissent pas « pour l'entreprise », ils se définissent par service. La messagerie, l'ERP et les archives historiques n'ont pas la même valeur — et les traiter de la même manière, c'est dépenser trop là où ce n'est pas utile et trop peu là où ça fait mal.
Tous les services ne se valent pas
L'outil pour en décider s'appelle Business Impact Analysis (BIA) : l'analyse qui passe en revue les processus de l'entreprise, mesure ce qui se passe si chacun s'arrête — chiffre d'affaires manqué, obligations envers des tiers, atteinte à la réputation — et en déduit les priorités et les objectifs de reprise. C'est le moment où le plan cesse d'être un document IT pour devenir une décision business : quels services reviennent en premier, dans quel ordre, et combien il vaut la peine d'investir sur chacun.
Une sauvegarde non testée est un espoir
Le jour du sinistre n'est pas le bon moment pour découvrir si la restauration fonctionne.
Les copies peuvent être corrompues, incomplètes, ou simplement plus lentes à restaurer que quiconque ne l'imaginait. Le seul moyen de le savoir est de tester : des vérifications de restauration périodiques — par échantillonnage sur les systèmes individuels et, à la bonne cadence, complètes sur les services critiques — en chronométrant les temps réels et en les comparant au RTO déclaré. Si la restauration mesurée de l'ERP prend 11 heures alors que l'objectif était de 4, mieux vaut le savoir un mardi tranquille que pendant l'incident.
Quand l'attaquant cible précisément les sauvegardes
Il y a aujourd'hui une raison de plus de prendre tout cela au sérieux : dans les attaques ransomware modernes, les copies de sécurité ne sont pas un dommage collatéral — elles sont une cible prioritaire. Celui qui chiffre les données sait qu'une entreprise dont les sauvegardes sont intactes ne paie pas : c'est pourquoi il cherche d'abord à atteindre et à détruire les copies.
Les contre-mesures sont connues et s'appliquent ensemble : la règle 3-2-1 (trois copies, sur deux supports différents, dont une hors site), au moins une copie immuable ou déconnectée qu'aucun identifiant compromis ne puisse effacer, et la séparation entre les comptes qui administrent les systèmes et ceux qui administrent les sauvegardes. À cela s'ajoute le travail de prévention et de réponse : la sauvegarde est la dernière ligne de défense, pas la seule.
La valeur de quelqu'un qui regarde
Dernière leçon du terrain : les sauvegardes échouent en silence. Un job qui s'interrompt, un stockage qui se remplit, un nouveau système jamais ajouté aux politiques — et la découverte arrive toujours au pire moment. La différence, c'est une surveillance quotidienne : quelqu'un qui contrôle les résultats, corrige les dérives et maintient les politiques alignées sur ce qu'est l'entreprise aujourd'hui.
C'est la raison pour laquelle nous délivrons la protection de la donnée comme service géré — avec des vérifications de restauration incluses et le NOC qui surveille les jobs avec le reste de l'infrastructure. Et si vous voulez partir de la bonne question — « dans combien de temps repartons-nous? » — posons-la ensemble, avec une Business Impact Analysis.
