Reprise après sinistre : l'assurance pour laquelle personne ne veut payer jusqu'à ce qu'il en ait besoin

Il existe une catégorie d’investissement que tout manager sait devoir réaliser et presque personne ne donne la priorité : celui dont la valeur n’apparaît que le pire jour. La reprise après sinistre en est l’exemple parfait. Même si tout fonctionne, c'est comme de l'argent gaspillé. Lorsque le serveur prend feu, que le ransomware crypte tout ou que le centre de données est inondé, cela devient la chose la plus importante au monde.

Le problème est que le moment où il faut savoir si vous avez un plan ne peut pas être le moment du désastre. A ce moment-là, soit le plan existe et fonctionne, soit l'organisation découvre, dans le pire contexte possible, qu'elle fonctionnait sans filet de sécurité.

Cet article est une introduction au concept pour ceux qui ne le traitent pas encore avec le sérieux qu’il exige. Il ne s'agit pas d'un manuel technique, mais d'une explication des raisons pour lesquelles la reprise après sinistre devrait être à l'ordre du jour de tout dirigeant dont le fonctionnement dépend des systèmes. Et aujourd’hui, c’est pratiquement tout le monde.

Qu'est-ce que la reprise après sinistre, en réalité ?

La reprise après sinistre est l’ensemble des plans, processus et ressources qui permettent à une organisation de restaurer ses opérations après un événement les perturbant gravement. L'acronyme technique est DR, pour reprise après sinistre, et il s'inscrit dans un concept plus large : la continuité des activités.

La différence entre les deux choses. La continuité des activités pose la question : « Comment pouvons-nous maintenir les opérations en cours pendant une crise ? » La reprise après sinistre pose la question : « Comment pouvons-nous nous remettre en marche après que quelque chose nous ait renversé ? » L’un s’occupe pendant, l’autre après.

Le point central est qu’une catastrophe, dans ce contexte, ne signifie pas seulement une catastrophe naturelle. Cela désigne tout événement rendant vos systèmes ou vos données indisponibles : une panne matérielle, une erreur humaine qui efface la base de production, une attaque de ransomware, la chute d'un fournisseur de cloud. La plupart des véritables « catastrophes » sont banales et donc courantes.

La thèse : la catastrophe n'est pas une exception, ce sont des statistiques

La façon la plus dangereuse d’y penser est de considérer la catastrophe comme quelque chose qui est peu susceptible d’arriver à d’autres. Je soutiens le contraire : le désastre est une certitude répartie dans le temps. Vous ne savez pas quand, mais vous savez que quelque chose va mal tourner.

Les disques échouent. Les gens font des erreurs. Les attaquants existent et ils sont infatigables. Les fournisseurs ont des pannes. Additionnez tout cela au fil des années de fonctionnement d'une organisation et la question cesse d'être « si » et devient « quand » et « dans quelle mesure serons-nous préparés ».

Ceux qui internalisent cette logique cessent de considérer la reprise après sinistre comme du pessimisme et commencent à la considérer comme une gestion de base des risques. C'est le même raisonnement que l'assurance automobile ou un extincteur : on ne l'achète pas dans l'espoir de s'en servir, on l'achète parce que le coût de ne pas l'avoir quand on en a besoin est trop élevé.

Les deux chiffres qui définissent chaque plan

La reprise après sinistre semble abstraite jusqu'à ce que vous appreniez deux concepts qui la rendent concrète et mesurable.

RTO, Objective Recovery Time. Combien de temps l'opération peut-elle être arrêtée avant que les dommages ne deviennent graves ? Minutes? Heures? Jours? Ce nombre définit la rapidité avec laquelle votre plan doit restaurer les systèmes.

RPO, Recovery Objective Point. Quelle quantité de données pouvez-vous vous permettre de perdre ? Si la dernière sauvegarde remonte à vingt-quatre heures et que le sinistre se produit maintenant, vous perdez une journée d'informations. Le RPO définit la fréquence à laquelle vous devez enregistrer.

Ces deux chiffres traduisent une décision commerciale en exigences techniques. Et ils sont révélateurs : de nombreuses organisations découvrent, en les définissant, qu’elles tolèrent moins de pertes et moins de temps d’arrêt qu’elles ne l’imaginaient, et que les sauvegardes dont elles disposent ne sont pas aussi bonnes.

Pourquoi la sauvegarde n'est pas la même chose que la récupération

L’erreur la plus courante et la plus dangereuse : confondre sauvegarde et reprise après sinistre. Ce sont des choses différentes, et la différence coûte cher.

La sauvegarde est la copie de données. La récupération est la capacité éprouvée à rétablir le fonctionnement de celui-ci. De nombreuses organisations ont religieusement effectué des sauvegardes qui n'ont jamais été testées. Le jour du sinistre, ils découvrent que la sauvegarde était corrompue, incomplète, ou que personne ne sait comment la restaurer, ou encore que la restauration prend beaucoup plus de temps que ce que l'opération peut gérer.

Une sauvegarde qui n'a jamais été testée n'est pas un plan. C'est un espoir. La différence apparaît exactement au moment où vous ne pouvez plus la corriger.

Dans les incidents de ransomware, cette distinction est devenue existentielle. Les attaquants modernes ciblent les sauvegardes avant de chiffrer la production, sachant que sans elles, la victime n'a aucune issue. Avoir la sauvegarde isolée et testée n'est plus une bonne pratique et est devenu une question de survie.

Le côté humain et organisationnel

Il y a une dimension que les plans techniques ont tendance à ignorer : le jour de la catastrophe, ce sont les personnes stressées qui exécutent le plan. Si cela n’existe que dans la tête d’une seule personne, ou dans un document que personne n’a lu, cela ne fonctionnera pas lorsque la pression est à son maximum.

Un véritable plan doit être clairement documenté, avec des rôles définis : qui décide, qui exécute, qui communique. Il faut le répéter, comme un exercice d'incendie, pour qu'à un moment critique, les gens sachent quoi faire sans improviser. Et vous devez envisager le scénario dans lequel la personne clé serait indisponible le jour même.

Dans le secteur public, cela prend un poids supplémentaire. Lorsqu’un système de santé, de perception des impôts ou de services aux citoyens s’effondre, ce n’est pas seulement l’organisation qui en souffre, c’est la population qui dépend de ce service. La continuité est une responsabilité publique et non une commodité opérationnelle.

La réflexion qui change de priorité

Le piège culturel est l’optimisme. « Rien ne nous est jamais arrivé » est la phrase qui précède la plupart des catastrophes non résolues. L'absence d'incident n'est pas une preuve de sécurité, c'est juste un hasard si ce n'est pas encore fini.

La reprise après sinistre est, à la base, un test de maturité du leadership. Les équipes immatures n’investissent que dans ce qui génère des résultats visibles. Les équipes matures investissent également dans ce qui évite des pertes catastrophiques, même sans applaudissements. C'est la différence entre gérer une bonne journée et gérer une mauvaise journée qui surviendra inévitablement.

Lorsqu’une catastrophe survient, et elle arrive, l’organisation qui s’est préparée a un historique de peur et de rétablissement. Ceux qui n’étaient pas préparés ont une histoire de crise, de perte et, parfois, de fin. Le choix entre ces deux histoires se fait aujourd’hui, le jour où il semble que tout va bien.

Si votre organisation n’a jamais vraiment testé ce qui se passerait en cas de perte totale de données, cela pourrait être le signe qu’il est temps. Il existe d'autres articles sur le blog sur la sécurité, la sauvegarde et la continuité qui approfondissent le sujet. S'il s'agit d'une préoccupation réelle dans votre contexte, cela vaut la peine d'en parler avant que la question ne devienne urgente.