Un plan n’est v\u00e9ritablement \u00e9valu\u00e9 que lorsque les syst\u00e8mes ne r\u00e9pondent plus, que le site principal est indisponible et que le d\u00e9lai d’intervention se mesure en minutes. Dans ce contexte, parler de reprise apr\u00e8s sinistre, par exemple, ne signifie pas proposer un mod\u00e8le th\u00e9orique, mais montrer comment traduire les exigences de continuit\u00e9, les contraintes technologiques et les responsabilit\u00e9s op\u00e9rationnelles en une s\u00e9quence r\u00e9alisable. <\/p>\n
Pour les organisations structur\u00e9es, l’essentiel n’est pas de disposer d’un document intitul\u00e9 \u00ab DRP \u00bb. L’essentiel est de disposer d’un dispositif de reprise d’activit\u00e9 coh\u00e9rent avec les impacts sur l’activit\u00e9, les d\u00e9pendances infrastructurelles, les obligations contractuelles et la tol\u00e9rance r\u00e9elle \u00e0 l’interruption. Un bon exemple sert justement \u00e0 cela : mettre en \u00e9vidence la logique de conception qui sous-tend le plan. <\/p>\n
Une strat\u00e9gie de reprise apr\u00e8s sinistre cr\u00e9dible ne repose pas uniquement sur l’architecture informatique. Elle d\u00e9coule d’une d\u00e9cision de gouvernance : quels processus doivent \u00eatre r\u00e9tablis, dans quel d\u00e9lai, avec quel niveau de service minimum et selon quelles priorit\u00e9s en cas de ressources limit\u00e9es. <\/p>\n
C’est pourquoi, avant la conception technique, au moins quatre \u00e9l\u00e9ments sont n\u00e9cessaires. Le premier est la classification des services critiques. Le deuxi\u00e8me est la d\u00e9finition des RTO et RPO pour les applications et les donn\u00e9es. Le troisi\u00e8me est la cartographie des d\u00e9pendances, y compris la connectivit\u00e9, les identit\u00e9s, les services r\u00e9seau, les fournisseurs et les infrastructures de soutien. Le quatri\u00e8me est l\u2019attribution formelle des r\u00f4les d\u00e9cisionnels et op\u00e9rationnels. <\/p>\n
Si l’un de ces facteurs fait d\u00e9faut, le plan risque d’\u00e9chouer, non pas en raison d’un manque de documentation, mais par manque de coh\u00e9rence. Il arrive souvent, par exemple, qu’une application soit d\u00e9clar\u00e9e avec un RTO d’une heure, alors que la sauvegarde, la bande passante disponible, les proc\u00e9dures de restauration et la fen\u00eatre d’intervention du fournisseur rendent r\u00e9aliste un d\u00e9lai de restauration de huit heures, voire plus. <\/p>\n
Prenons l\u2019exemple d\u2019une entreprise manufacturi\u00e8re disposant de plusieurs sites commerciaux et d\u2019un site de production principal. Le progiciel de gestion int\u00e9gr\u00e9 (ERP) g\u00e8re les commandes, les stocks et la planification. Le syst\u00e8me de gestion de l\u2019ex\u00e9cution de la production (MES) collecte les donn\u00e9es de production et g\u00e8re l\u2019avancement des commandes. La messagerie \u00e9lectronique et les outils de collaboration sont h\u00e9berg\u00e9s dans le cloud, tandis que l\u2019ERP et le MES r\u00e9sident sur une infrastructure virtualis\u00e9e au sein du centre de donn\u00e9es du site de production. La connexion entre l\u2019usine et les sites p\u00e9riph\u00e9riques s\u2019effectue via un r\u00e9seau MPLS avec une connexion Internet professionnelle de secours. La base de donn\u00e9es de l\u2019ERP est r\u00e9pliqu\u00e9e toutes les 15 minutes vers un site secondaire en colocation. <\/p>\n
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\u2019important, peut tol\u00e9rer un RTO de 24 heures. Cette donn\u00e9e est d\u00e9terminante, car elle \u00e9vite de traiter tous les syst\u00e8mes comme \u00e9tant d\u2019une urgence \u00e9gale, une erreur fr\u00e9quente qui disperse les ressources et complique la r\u00e9ponse. <\/p>\n
Le sc\u00e9nario de r\u00e9f\u00e9rence est un incendie dans la salle du centre de donn\u00e9es (CED) du site principal, entra\u00eenant la perte des serveurs h\u00f4tes, des syst\u00e8mes de stockage et des \u00e9quipements r\u00e9seau locaux. Cet incident ne compromet ni le site secondaire ni les services cloud. <\/p>\n
\u00c0 ce stade, le plan de reprise apr\u00e8s sinistre peut \u00eatre \u00e9labor\u00e9 de mani\u00e8re r\u00e9aliste.<\/p>\n
L’entreprise utilise un site secondaire en mode \u00ab warm standby \u00bb. Le site de colocation dispose d\u00e9j\u00e0 de capacit\u00e9s de calcul r\u00e9serv\u00e9es, d\u2019une segmentation du r\u00e9seau pr\u00e9configur\u00e9e, d\u2019images des machines virtuelles critiques et d\u2019une r\u00e9plication des bases de donn\u00e9es principales. Tout n\u2019est pas actif en temps r\u00e9el, car le co\u00fbt d\u2019un site de secours complet ne serait pas compatible avec le profil de risque et le budget approuv\u00e9. <\/p>\n
Ce choix met en \u00e9vidence un point essentiel : la meilleure solution de reprise apr\u00e8s sinistre n\u2019est pas celle qui est la plus sophistiqu\u00e9e sur le plan technologique, mais celle qui est adapt\u00e9e \u00e0 l\u2019impact. Un \u00ab hot site \u00bb peut se justifier dans des contextes financiers ou sanitaires pr\u00e9sentant un niveau de criticit\u00e9 tr\u00e8s \u00e9lev\u00e9 ; dans de nombreux environnements industriels, un \u00ab warm site \u00bb bien test\u00e9 offre un meilleur \u00e9quilibre entre performances, complexit\u00e9 et co\u00fbt. <\/p>\n
Le plan d\u00e9finit pr\u00e9cis\u00e9ment \u00e0 quel moment on passe de la gestion d’incident \u00e0 la d\u00e9claration de catastrophe. Dans le cas d\u00e9crit, le d\u00e9clencheur est activ\u00e9 lorsque l’\u00e9quipe charg\u00e9e de l’infrastructure confirme que le site principal ne peut pas \u00eatre remis en \u00e9tat dans un d\u00e9lai de 2 heures, ou lorsque le responsable de crise re\u00e7oit la confirmation de l’indisponibilit\u00e9 du centre de donn\u00e9es, accompagn\u00e9e de dommages mat\u00e9riels sur les \u00e9quipements principaux. <\/p>\n
Cette \u00e9tape est souvent sous-estim\u00e9e. Si le seuil de d\u00e9clenchement n’est pas clairement d\u00e9fini, l’organisation perd du temps dans des escalades improductives. S’il est trop strict, on risque de faire appel au plan de reprise apr\u00e8s sinistre (DR) inutilement, ce qui entra\u00eene des r\u00e9percussions \u00e9conomiques et op\u00e9rationnelles qui auraient pu \u00eatre \u00e9vit\u00e9es. <\/p>\n
Ce plan d\u00e9signe un responsable de la reprise apr\u00e8s sinistre, le responsable des infrastructures, le responsable de l’application ERP, le r\u00e9f\u00e9rent r\u00e9seau, le responsable de la cybers\u00e9curit\u00e9, le responsable de la gestion de crise et le r\u00e9f\u00e9rent m\u00e9tier pour les op\u00e9rations. Chacun dispose d’un p\u00e9rim\u00e8tre de comp\u00e9tences bien d\u00e9fini. <\/p>\n
Le responsable de la reprise apr\u00e8s sinistre coordonne la mise en \u0153uvre technique. Le responsable de crise autorise le basculement vers le site de secours en fonction des informations disponibles. Le r\u00e9f\u00e9rent m\u00e9tier valide la reprise minimale acceptable. L’\u00e9quipe de cybers\u00e9curit\u00e9 v\u00e9rifie 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. <\/p>\n
Il convient ici de faire une autre distinction n\u00e9cessaire : toutes les catastrophes ne sont pas uniquement des probl\u00e8mes d’infrastructure. Si la cause est d’origine cybern\u00e9tique, la restauration ne peut se limiter \u00e0 activer des copies et des r\u00e9pliques. Il faut d’abord proc\u00e9der \u00e0 un endiguement, v\u00e9rifier l’int\u00e9grit\u00e9, proc\u00e9der \u00e9ventuellement \u00e0 un isolement et s’assurer que les sauvegardes sont fiables. <\/p>\n
Dans notre exemple de reprise apr\u00e8s sinistre, la s\u00e9quence op\u00e9rationnelle s’articule autour de priorit\u00e9s et de d\u00e9pendances. Il faut d’abord activer la connectivit\u00e9, les services DNS, l’authentification et les segments de r\u00e9seau du site secondaire. Sans ces \u00e9l\u00e9ments, la restauration des applications ne permet pas d’obtenir un service utilisable. <\/p>\n
On d\u00e9marre ensuite les bases de donn\u00e9es r\u00e9pliqu\u00e9es de l’ERP et on effectue un contr\u00f4le de coh\u00e9rence. On d\u00e9marre ensuite les serveurs d’applications ERP et les interfaces vers les syst\u00e8mes satellites. Ce n’est qu’apr\u00e8s les tests fonctionnels minimaux que le trafic des utilisateurs est redirig\u00e9 vers le site secondaire. <\/p>\n
Le MES est r\u00e9tabli lors de la phase suivante, en mode d\u00e9grad\u00e9 : certaines fonctions analytiques non critiques restent suspendues, tandis que la collecte des donn\u00e9es essentielles et le traitement des commandes sont assur\u00e9s. Cette configuration est plus r\u00e9aliste qu\u2019une approche \u00ab tout ou rien \u00bb. En situation d\u2019urgence, le v\u00e9ritable objectif n\u2019est pas de ramener imm\u00e9diatement l\u2019ensemble de l\u2019\u00e9cosyst\u00e8me \u00e0 son plein r\u00e9gime, mais de r\u00e9tablir les niveaux minimaux d\u2019activit\u00e9 convenus. <\/p>\n
Enfin, on passe aux services de moindre priorit\u00e9, tels que les archives documentaires secondaires et les partages de fichiers non essentiels. L’ensemble du processus s’accompagne de listes de contr\u00f4le, de d\u00e9lais cibles, de conditions pr\u00e9alables et de points de contr\u00f4le. <\/p>\n
L’int\u00e9r\u00eat d’un exemple ne r\u00e9side pas dans la liste des technologies, mais dans la coh\u00e9rence entre les objectifs, le contexte et la capacit\u00e9 de mise en \u0153uvre. Trois aspects, en particulier, font toute la diff\u00e9rence. <\/p>\n
Le premier est l\u2019alignement sur l\u2019impact m\u00e9tier. Si les commandes et la production d\u00e9pendent de l\u2019ERP, la priorit\u00e9 doit \u00eatre attribu\u00e9e en cons\u00e9quence. Le deuxi\u00e8me est la gestion des d\u00e9pendances cach\u00e9es. Un syst\u00e8me r\u00e9pliqu\u00e9 mais d\u00e9pourvu d\u2019authentification, de nommage ou de connectivit\u00e9 n\u2019est pas r\u00e9ellement r\u00e9cup\u00e9rable. Le troisi\u00e8me est la v\u00e9rifiabilit\u00e9. Chaque \u00e9tape du plan doit pouvoir \u00eatre test\u00e9e de mani\u00e8re observable et mesurable. <\/p>\n
C’est pourquoi, dans les programmes bien rod\u00e9s, on met en place des indicateurs de performance : temps de mobilisation de l’\u00e9quipe, temps de prise de d\u00e9cision, temps de basculement, perte effective de donn\u00e9es, taux d’ach\u00e8vement des listes de contr\u00f4le, r\u00e9sultats des tests applicatifs. Sans ces indicateurs, la reprise apr\u00e8s sinistre reste une simple d\u00e9claration d’intention. <\/p>\n
De nombreux plans sont r\u00e9dig\u00e9s correctement d’un point de vue formel, mais s’av\u00e8rent n\u00e9anmoins peu efficaces sur le plan op\u00e9rationnel. L’erreur la plus courante consiste \u00e0 confondre sauvegarde et reprise apr\u00e8s sinistre. La sauvegarde prot\u00e8ge les donn\u00e9es ; la reprise apr\u00e8s sinistre prot\u00e8ge la capacit\u00e9 \u00e0 r\u00e9tablir un service dans des d\u00e9lais d\u00e9finis. <\/p>\n
Une deuxi\u00e8me erreur consiste \u00e0 documenter des proc\u00e9dures qui d\u00e9pendent de personnes sp\u00e9cifiques, sans rempla\u00e7ants ni syst\u00e8me de permanence structur\u00e9. Une troisi\u00e8me erreur est de ne pas tenir compte des fournisseurs critiques, notamment lorsque la connectivit\u00e9, l\u2019h\u00e9bergement, le cloud ou la maintenance des applications sont externalis\u00e9s. Enfin, il y a le probl\u00e8me des tests symboliques : des simulations non \u00e9tay\u00e9es par des preuves techniques, des tests limit\u00e9s \u00e0 des composants isol\u00e9s ou des exercices qui ne mettent pas r\u00e9ellement \u00e0 l\u2019\u00e9preuve les points de d\u00e9faillance. <\/p>\n
Dans les contextes r\u00e9glementaires ou d’assurance, ces lacunes prennent une importance particuli\u00e8re, car elles ont une incidence sur la capacit\u00e9 \u00e0 d\u00e9montrer l’efficacit\u00e9 des mesures de contr\u00f4le et sur la qualit\u00e9 globale de la gouvernance des risques.<\/p>\n
Un mod\u00e8le efficace doit \u00eatre adapt\u00e9, et non copi\u00e9. Une m\u00eame architecture peut convenir \u00e0 une entreprise et s’av\u00e9rer insuffisante pour une autre. En effet, la tol\u00e9rance \u00e0 l’arr\u00eat, la r\u00e9partition g\u00e9ographique, l’exposition aux cyberrisques, les contraintes de conformit\u00e9, la pr\u00e9sence de syst\u00e8mes OT et les cons\u00e9quences \u00e9conomiques d’une interruption varient d’une entreprise \u00e0 l’autre. <\/p>\n
C’est pourquoi la bonne approche consiste \u00e0 commencer par une analyse d’impact sur l’activit\u00e9 et une \u00e9valuation des risques<\/a>, \u00e0 traduire les r\u00e9sultats en exigences de reprise, \u00e0 concevoir l’architecture cible, puis \u00e0 la valider au moyen de tests progressifs. Ce n’est qu’ensuite qu’il est judicieux de finaliser le plan documentaire. <\/p>\n Dans cette optique, la formation sp\u00e9cialis\u00e9e<\/a>, l’\u00e9valuation technique et les simulations jouent un r\u00f4le d\u00e9cisif. Les organisations qui souhaitent renforcer leur capacit\u00e9 de r\u00e9action n\u2019ont pas besoin d\u2019un document suppl\u00e9mentaire, mais d\u2019un programme qui relie les normes, les responsabilit\u00e9s, les infrastructures et les d\u00e9cisions op\u00e9rationnelles. C\u2019est sur ce point qu\u2019un partenaire tel que Continuitaly<\/a> peut apporter une valeur ajout\u00e9e concr\u00e8te, notamment lorsqu\u2019il s\u2019agit d\u2019int\u00e9grer la r\u00e9silience organisationnelle, la technologie et les logiques de risque assurable. <\/p>\n Un plan de reprise apr\u00e8s sinistre bien con\u00e7u ne garantit pas l\u2019absence d\u2019interruptions. Il garantit quelque chose de bien plus important : savoir, avant la crise, ce qui est r\u00e9cup\u00e9rable, dans quel d\u00e9lai et avec quel niveau de fiabilit\u00e9. C\u2019est cette clart\u00e9 op\u00e9rationnelle, bien plus que les discours sur la r\u00e9silience, qui prot\u00e8ge v\u00e9ritablement l\u2019organisation lorsque l\u2019\u00e9v\u00e9nement se produit. <\/p>\n","protected":false},"excerpt":{"rendered":" Exemple concret de reprise apr\u00e8s sinistre : comment d\u00e9finir les objectifs, les r\u00f4les, les sites, les tests et la s\u00e9quence de reprise afin de r\u00e9duire les temps d’arr\u00eat et les pertes.<\/p>\n","protected":false},"author":1,"featured_media":5130,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[384],"tags":[],"class_list":["post-5132","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-actualites"],"acf":[],"yoast_head":"\n