Disaster recovery : pourquoi un backup non testé ne sauve pas

« Nous avons des sauvegardes. » Deux mots qui rassurent n'importe quel dirigeant — et qui, le jour d'un incident réel, se révèlent souvent l'illusion la plus coûteuse de l'entreprise. Car entre avoir une sauvegarde et pouvoir s'en restaurer, il y a un gouffre que la plupart des entreprises découvrent au pire moment possible : quand elles ont besoin des données et qu'elles ne reviennent pas.

Une sauvegarde qui n'a pas été testée n'est pas un filet de sécurité. C'est une supposition. Et en 2026, cette supposition est devenue dangereusement coûteuse, car les attaquants ont appris où frapper exactement : non seulement les données de production, mais aussi les copies de sauvegarde censées vous sauver.

Sauvegarde ne veut pas dire récupération

Une sauvegarde est une copie des données. Le disaster recovery est la capacité de remettre l'entreprise en fonctionnement — à temps, complètement, avec des processus clairs. Ce sont deux choses différentes, et avoir la première ne garantit rien sur la seconde.

Vous pouvez avoir des copies parfaites de vos données et rester tout de même à l'arrêt deux semaines : parce que personne n'a jamais mesuré combien de temps prend une restauration complète, parce que la sauvegarde se trouve sur le serveur même que le ransomware a chiffré, parce qu'il n'existe aucune procédure écrite et que sous pression tout le monde improvise, ou parce que la dernière vérification « ça a marché » remonte à un an et que le job échoue silencieusement chaque nuit depuis. La sauvegarde est la matière première. Le disaster recovery est la recette, la cuisine et le cuisinier capable de la servir dans le délai promis.

Ce que montrent les données 2025–2026

Les chiffres de l'année écoulée racontent une histoire claire : le problème n'est plus que les entreprises manquent de sauvegardes, mais que la récupération réelle est bien plus difficile qu'elle n'en a l'air.

• Près de 9 violations de sécurité sur 10 dans les petites entreprises impliquent un ransomware, contre environ 4 sur 10 dans les grandes entreprises — les PME sont la cible privilégiée, pas une exception.
• En moyenne, une entreprise touchée par un ransomware a besoin d'environ 24 jours pour revenir à un fonctionnement normal. Pour beaucoup de PME, trois semaines d'arrêt sont fatales.
• Seule la moitié environ des victimes se rétablissent en moins d'une semaine ; une part importante a besoin de plus d'un mois, et très peu y parviennent en une seule journée.
• Dans la grande majorité des attaques par ransomware, les attaquants visent directement les copies de sauvegarde — et réussissent à les compromettre dans plus de trois quarts des cas. La sauvegarde n'est plus un coin sûr, mais une cible.
• Les entreprises qui parviennent à restaurer à partir de sauvegardes intactes dépensent, en moyenne, plusieurs fois moins pour la récupération que celles dont les sauvegardes sont compromises — la différence se mesure en centaines de milliers d'euros.
• Et pourtant, une grande partie des plans de récupération sont testés rarement ou jamais — beaucoup d'entreprises n'ont jamais vérifié si leur plan fonctionne réellement.

La conclusion se lit entre les lignes : les entreprises qui se rétablissent vite et à moindre coût ne sont pas celles qui ont le logiciel de sauvegarde le plus cher, mais celles qui ont testé leur récupération avant le désastre. Les autres paient la facture — en jours perdus, en argent et, dans le pire des cas, avec l'existence même de l'entreprise.

RTO et RPO : deux décisions de business, pas techniques

Tout plan de disaster recovery sérieux part de deux nombres. Ils ne sont pas décidés par un technicien mais par la direction — car ce sont, au fond, des décisions sur le niveau de risque que l'entreprise peut se permettre.

RPO — combien de données vous pouvez vous permettre de perdre

Le Recovery Point Objective est la fenêtre maximale de données dont vous acceptez la perte. Si vous sauvegardez une fois par jour, un incident peut vous coûter jusqu'à 24 heures de travail. Pour une comptabilité, cela peut être acceptable. Pour une boutique en ligne ou un système transactionnel, une heure perdue peut signifier des commandes et de l'argent disparus. Le RPO vous dit à quelle fréquence vous devez faire des copies.

RTO — à quelle vitesse vous devez revenir

Le Recovery Time Objective est le temps maximal acceptable jusqu'à ce que le système soit de nouveau fonctionnel. Un RTO de 8 heures et un de 15 minutes exigent des architectures totalement différentes — et des coûts différents. L'astuce n'est pas d'exiger une « récupération instantanée » partout, mais d'identifier correctement quels systèmes sont critiques (ceux qui arrêtent l'activité) et lesquels peuvent attendre. Vous investissez dans les critiques ; sur le reste, vous économisez.

Sans ces deux nombres, « nous avons des sauvegardes » est une phrase vide. Avec eux, la conception devient une décision rationnelle : vous savez exactement à quelle fréquence vous copiez et à quelle vitesse vous devez restaurer — et vous pouvez vérifier si vous y parvenez réellement.

Pourquoi les sauvegardes échouent exactement quand on en a besoin

Les récupérations échouent rarement pour une seule raison spectaculaire. Le plus souvent, la cause est l'une de celles-ci — banales, mais fatales :

1. 1La sauvegarde n'a jamais été testée. Le job « tourne », mais personne n'a jamais tenté une restauration complète. La première fois ne devrait pas être au milieu de la crise.
2. 2La sauvegarde se trouve à côté de la production. Une copie sur le même serveur ou réseau que les données de production est chiffrée par le même ransomware. Sans une copie hors site et immuable, vous n'avez pas de sauvegarde — vous avez deux victimes.
3. 3RPO/RTO manquent. Personne n'a décidé ce qui est acceptable de perdre, donc personne ne peut dire si la sauvegarde actuelle suffit ou si la récupération est « à temps ».
4. 4Il n'y a pas de runbook. Dans la première heure d'un incident, sous stress, les gens improvisent. Sans procédure écrite — qui, quoi, dans quel ordre — de précieuses heures sont perdues sur des décisions qui auraient dû être prises à l'avance.
5. 5La rétention ne couvre pas le scénario réel. Certaines attaques restent cachées des jours ou des semaines avant de frapper. Si vous ne gardez que les derniers jours de copies, vous risquez de restaurer des données déjà compromises.
6. 6La surveillance manque. Un job de sauvegarde qui échoue silencieusement pendant des mois ne révèle le problème qu'à la première restauration — c'est-à-dire trop tard.

À quoi ressemble un plan de disaster recovery qui fonctionne vraiment

Un plan opérationnel — pas un plan de tiroir — a quelques ingrédients clairs :

• RPO et RTO définis par système, validés avec la direction — pas un seul nombre pour tout.
• La stratégie 3-2-1-0 : trois copies des données, sur deux supports différents, une hors site, avec zéro erreur à la vérification. Au moins une copie immuable que le ransomware ne peut ni supprimer ni chiffrer.
• Des tests de restauration périodiques — mensuels pour les systèmes critiques, trimestriels pour le reste — en mesurant les temps réels et en les comparant au RTO cible.
• Des runbooks écrits : qui déclenche la récupération, dans quel ordre les systèmes sont restaurés, comment on communique, quand on escalade.
• Pour les systèmes à RTO faible, un site secondaire dans le cloud et une réplication continue (Disaster Recovery as a Service) avec des exercices de bascule.
• Des politiques de rétention et d'archivage alignées sur les exigences RGPD — conservez ce que vous devez, supprimez automatiquement ce qui a expiré, avec une piste d'audit complète.

Une sauvegarde que vous n'avez jamais restaurée n'est pas une sauvegarde — c'est une promesse que vous n'avez jamais vérifiée. La seule question qui compte est : combien de temps faut-il, en réalité, pour revenir ?

Comment nous travaillons

Dans nos projets de protection des données, nous commençons par un atelier d'analyse d'impact métier, où nous définissons avec vous le RPO et le RTO de chaque système. Nous concevons ensuite la stratégie 3-2-1-0 avec une copie immuable, configurons la sauvegarde, la surveillance et les alertes et — surtout — testons la restauration selon un calendrier clair, en documentant les temps réels jusqu'à atteindre le RTO cible. Pour les systèmes qui ne tolèrent pas d'interruption, nous ajoutons la réplication dans le cloud et des runbooks de bascule testés. Parce que le ransomware est aujourd'hui la principale menace pour les données, le plan de récupération va de pair avec les mesures de cybersécurité. Si vous voulez savoir combien de temps prend réellement une récupération complète dans votre entreprise, discutons 30 minutes — je vous dirai concrètement où vous êtes exposé.

Conclusion

Les données 2025-2026 sont sans équivoque : la différence entre une entreprise qui survit à un incident et une que l'incident ferme n'est pas le logiciel de sauvegarde, mais la récupération testée. La sauvegarde est obligatoire mais insuffisante. Le disaster recovery — avec RTO et RPO définis, copies immuables, runbooks et tests périodiques — est ce qui transforme une copie de vos données en une véritable garantie que votre entreprise survit. Ne laissez pas la première restauration se faire au milieu de la crise.