Exemple de reprise après sinistre : cas pratique et architecture

Un plan n’est véritablement évalué que lorsque les systèmes ne répondent plus, que le site principal est indisponible et que le délai d’intervention se mesure en minutes. Dans ce contexte, parler de reprise après sinistre, par exemple, ne signifie pas proposer un modèle théorique, mais montrer comment traduire les exigences de continuité, les contraintes technologiques et les responsabilités opérationnelles en une séquence réalisable.

Pour les organisations structurées, l’essentiel n’est pas de disposer d’un document intitulé « DRP ». L’essentiel est de disposer d’un dispositif de reprise d’activité cohérent avec les impacts sur l’activité, les dépendances infrastructurelles, les obligations contractuelles et la tolérance réelle à l’interruption. Un bon exemple sert justement à cela : mettre en évidence la logique de conception qui sous-tend le plan.

Exemple de reprise après sinistre : par quoi faut-il commencer ?

Une stratégie de reprise après sinistre crédible ne repose pas uniquement sur l’architecture informatique. Elle découle d’une décision de gouvernance : quels processus doivent être rétablis, dans quel délai, avec quel niveau de service minimum et selon quelles priorités en cas de ressources limitées.

C’est pourquoi, avant la conception technique, au moins quatre éléments sont nécessaires. Le premier est la classification des services critiques. Le deuxième est la définition des RTO et RPO pour les applications et les données. Le troisième est la cartographie des dépendances, y compris la connectivité, les identités, les services réseau, les fournisseurs et les infrastructures de soutien. Le quatrième est l’attribution formelle des rôles décisionnels et opérationnels.

Si l’un de ces facteurs fait défaut, le plan risque d’échouer, non pas en raison d’un manque de documentation, mais par manque de cohérence. Il arrive souvent, par exemple, qu’une application soit déclarée avec un RTO d’une heure, alors que la sauvegarde, la bande passante disponible, les procédures de restauration et la fenêtre d’intervention du fournisseur rendent réaliste un délai de restauration de huit heures, voire plus.

Un exemple concret de reprise après sinistre

Prenons l’exemple d’une entreprise manufacturière disposant de plusieurs sites commerciaux et d’un site de production principal. Le progiciel de gestion intégré (ERP) gère les commandes, les stocks et la planification. Le système de gestion de l’exécution de la production (MES) collecte les données de production et gère l’avancement des commandes. La messagerie électronique et les outils de collaboration sont hébergés dans le cloud, tandis que l’ERP et le MES résident sur une infrastructure virtualisée au sein du centre de données du site de production. La connexion entre l’usine et les sites périphériques s’effectue via un réseau MPLS avec une connexion Internet professionnelle de secours. La base de données de l’ERP est répliquée toutes les 15 minutes vers un site secondaire en colocation.

L’analyse d’impact indique que l’ERP a un RTO de 4 heures et un RPO de 15 minutes. Le MES a un RTO de 8 heures et un RPO de 1 heure. Le serveur de fichiers technique, bien qu’important, peut tolérer un RTO de 24 heures. Cette donnée est déterminante, car elle évite de traiter tous les systèmes comme étant d’une urgence égale, une erreur fréquente qui disperse les ressources et complique la réponse.

Le scénario de référence est un incendie dans la salle du centre de données (CED) du site principal, entraînant la perte des serveurs hôtes, des systèmes de stockage et des équipements réseau locaux. Cet incident ne compromet ni le site secondaire ni les services cloud.

À ce stade, le plan de reprise après sinistre peut être élaboré de manière réaliste.

Plan de redressement prévu

L’entreprise utilise un site secondaire en mode « warm standby ». Le site de colocation dispose déjà de capacités de calcul réservées, d’une segmentation du réseau préconfigurée, d’images des machines virtuelles critiques et d’une réplication des bases de données principales. Tout n’est pas actif en temps réel, car le coût d’un site de secours complet ne serait pas compatible avec le profil de risque et le budget approuvé.

Ce choix met en évidence un point essentiel : la meilleure solution de reprise après sinistre n’est pas celle qui est la plus sophistiquée sur le plan technologique, mais celle qui est adaptée à l’impact. Un « hot site » peut se justifier dans des contextes financiers ou sanitaires présentant un niveau de criticité très élevé ; dans de nombreux environnements industriels, un « warm site » bien testé offre un meilleur équilibre entre performances, complexité et coût.

Déclencheurs d’activation

Le plan définit précisément à quel moment on passe de la gestion d’incident à la déclaration de catastrophe. Dans le cas décrit, le déclencheur est activé lorsque l’équipe chargée de l’infrastructure confirme que le site principal ne peut pas être remis en état dans un délai de 2 heures, ou lorsque le responsable de crise reçoit la confirmation de l’indisponibilité du centre de données, accompagnée de dommages matériels sur les équipements principaux.

Cette étape est souvent sous-estimée. Si le seuil de déclenchement n’est pas clairement défini, l’organisation perd du temps dans des escalades improductives. S’il est trop strict, on risque de faire appel au plan de reprise après sinistre (DR) inutilement, ce qui entraîne des répercussions économiques et opérationnelles qui auraient pu être évitées.

Rôles et chaîne de décision

Ce plan désigne un responsable de la reprise après sinistre, le responsable des infrastructures, le responsable de l’application ERP, le référent réseau, le responsable de la cybersécurité, le responsable de la gestion de crise et le référent métier pour les opérations. Chacun dispose d’un périmètre de compétences bien défini.

Le responsable de la reprise après sinistre coordonne la mise en œuvre technique. Le responsable de crise autorise le basculement vers le site de secours en fonction des informations disponibles. Le référent métier valide la reprise minimale acceptable. L’équipe de cybersécurité vérifie que l’incident ne s’inscrit pas dans le cadre d’une attaque destructrice ou d’une compromission active, car dans ce cas, la logique de reprise change radicalement.

Il convient ici de faire une autre distinction nécessaire : toutes les catastrophes ne sont pas uniquement des problèmes d’infrastructure. Si la cause est d’origine cybernétique, la restauration ne peut se limiter à activer des copies et des répliques. Il faut d’abord procéder à un endiguement, vérifier l’intégrité, procéder éventuellement à un isolement et s’assurer que les sauvegardes sont fiables.

La séquence de récupération de l’exemple

Dans notre exemple de reprise après sinistre, la séquence opérationnelle s’articule autour de priorités et de dépendances. Il faut d’abord activer la connectivité, les services DNS, l’authentification et les segments de réseau du site secondaire. Sans ces éléments, la restauration des applications ne permet pas d’obtenir un service utilisable.

On démarre ensuite les bases de données répliquées de l’ERP et on effectue un contrôle de cohérence. On démarre ensuite les serveurs d’applications ERP et les interfaces vers les systèmes satellites. Ce n’est qu’après les tests fonctionnels minimaux que le trafic des utilisateurs est redirigé vers le site secondaire.

Le MES est rétabli lors de la phase suivante, en mode dégradé : certaines fonctions analytiques non critiques restent suspendues, tandis que la collecte des données essentielles et le traitement des commandes sont assurés. Cette configuration est plus réaliste qu’une approche « tout ou rien ». En situation d’urgence, le véritable objectif n’est pas de ramener immédiatement l’ensemble de l’écosystème à son plein régime, mais de rétablir les niveaux minimaux d’activité convenus.

Enfin, on passe aux services de moindre priorité, tels que les archives documentaires secondaires et les partages de fichiers non essentiels. L’ensemble du processus s’accompagne de listes de contrôle, de délais cibles, de conditions préalables et de points de contrôle.

Qu’est-ce qui rend cet exemple vraiment utile ?

L’intérêt d’un exemple ne réside pas dans la liste des technologies, mais dans la cohérence entre les objectifs, le contexte et la capacité de mise en œuvre. Trois aspects, en particulier, font toute la différence.

Le premier est l’alignement sur l’impact métier. Si les commandes et la production dépendent de l’ERP, la priorité doit être attribuée en conséquence. Le deuxième est la gestion des dépendances cachées. Un système répliqué mais dépourvu d’authentification, de nommage ou de connectivité n’est pas réellement récupérable. Le troisième est la vérifiabilité. Chaque étape du plan doit pouvoir être testée de manière observable et mesurable.

C’est pourquoi, dans les programmes bien rodés, on met en place des indicateurs de performance : temps de mobilisation de l’équipe, temps de prise de décision, temps de basculement, perte effective de données, taux d’achèvement des listes de contrôle, résultats des tests applicatifs. Sans ces indicateurs, la reprise après sinistre reste une simple déclaration d’intention.

Les erreurs les plus fréquentes lors de la mise en place d’un plan de reprise après sinistre : un exemple

De nombreux plans sont rédigés correctement d’un point de vue formel, mais s’avèrent néanmoins peu efficaces sur le plan opérationnel. L’erreur la plus courante consiste à confondre sauvegarde et reprise après sinistre. La sauvegarde protège les données ; la reprise après sinistre protège la capacité à rétablir un service dans des délais définis.

Une deuxième erreur consiste à documenter des procédures qui dépendent de personnes spécifiques, sans remplaçants ni système de permanence structuré. Une troisième erreur est de ne pas tenir compte des fournisseurs critiques, notamment lorsque la connectivité, l’hébergement, le cloud ou la maintenance des applications sont externalisés. Enfin, il y a le problème des tests symboliques : des simulations non étayées par des preuves techniques, des tests limités à des composants isolés ou des exercices qui ne mettent pas réellement à l’épreuve les points de défaillance.

Dans les contextes réglementaires ou d’assurance, ces lacunes prennent une importance particulière, car elles ont une incidence sur la capacité à démontrer l’efficacité des mesures de contrôle et sur la qualité globale de la gouvernance des risques.

Comment s’inspirer d’un exemple pour élaborer votre propre plan

Un modèle efficace doit être adapté, et non copié. Une même architecture peut convenir à une entreprise et s’avérer insuffisante pour une autre. En effet, la tolérance à l’arrêt, la répartition géographique, l’exposition aux cyberrisques, les contraintes de conformité, la présence de systèmes OT et les conséquences économiques d’une interruption varient d’une entreprise à l’autre.

C’est pourquoi la bonne approche consiste à commencer parune analyse d’impact sur l’activité et une évaluation des risques, à traduire les résultats en exigences de reprise, à concevoir l’architecture cible, puis à la valider au moyen de tests progressifs. Ce n’est qu’ensuite qu’il est judicieux de finaliser le plan documentaire.

Dans cette optique,la formation spécialisée, l’évaluation technique et les simulations jouent un rôle décisif. Les organisations qui souhaitent renforcer leur capacité de réaction n’ont pas besoin d’un document supplémentaire, mais d’un programme qui relie les normes, les responsabilités, les infrastructures et les décisions opérationnelles. C’est sur ce point qu’un partenaire tel queContinuitalypeut apporter une valeur ajoutée concrète, notamment lorsqu’il s’agit d’intégrer la résilience organisationnelle, la technologie et les logiques de risque assurable.

Un plan de reprise après sinistre bien conçu ne garantit pas l’absence d’interruptions. Il garantit quelque chose de bien plus important : savoir, avant la crise, ce qui est récupérable, dans quel délai et avec quel niveau de fiabilité. C’est cette clarté opérationnelle, bien plus que les discours sur la résilience, qui protège véritablement l’organisation lorsque l’événement se produit.

This post is also available in: