Sujet 3.9 — Continuité d'activité et reprise après sinistre

Dans la santé et l'action sociale, une panne système majeure est un événement de sécurité patient avant d'être un problème informatique, donc votre capacité à continuer de livrer des soins pendant qu'un système est hors service — et à le récupérer entièrement et rapidement — est une capacité clinique et de confiance publique fondamentale, pas une note de bas de page technique.

Pourquoi c'est important dans la santé et l'action sociale#

Les soins ne s'arrêtent pas quand la technologie s'arrête. Lorsqu'un dossier de santé électronique, une plateforme de prescription électronique, ou un système de résultats de laboratoire échoue à travers un hôpital, les cliniciens ne peuvent pas mettre le traitement en pause pendant que les ingénieurs travaillent. Ils doivent continuer à voir des patients, prescrire des médicaments, et prendre des décisions — souvent sans les alertes d'allergie, les vérifications de dose, et l'historique antérieur que le système défaillant fournit normalement. C'est pourquoi une panne ne se mesure pas seulement en heures d'arrêt et crédits de service ; elle se mesure en diagnostics retardés, interactions manquées, opérations annulées, et le risque supplémentaire porté par chaque clinicien travaillant à l'aveugle. La continuité d'activité est la discipline consistant à s'assurer que lorsque le pire arrive, les soins restent aussi sûrs que possible.

Les enjeux sont nationaux et bien documentés. L'attaque du rançongiciel WannaCry de 2017 a perturbé environ un tiers des trusts du NHS en Angleterre, a forcé l'annulation de milliers de rendez-vous et d'opérations, a dérouté des ambulances, et a verrouillé le personnel hors des appareils mêmes — y compris certains équipements d'imagerie et de pathologie — dont il avait besoin pour traiter les gens. Cela a coûté au NHS un estimé de 92 millions de livres sterling et, plus important encore, a montré qu'une cyberattaque contre l'infrastructure de santé atterrit comme une crise clinique, pas simplement un incident de sécurité des données. Depuis lors, la résilience s'est déplacée de la salle des serveurs à la table du conseil d'administration, et à juste titre.

Ce sujet étend la discipline opérationnelle du Sujet 3.8 — Gestion de service et opérations en direct, mais déplace l'attention de l'exploitation quotidienne vers la perturbation majeure : l'incendie, l'inondation, la cyberattaque, l'effondrement de fournisseur, ou la panne régionale qui menace de mettre un service critique hors service pendant des heures ou des jours. Il se relie étroitement au Sujet 1.7 — Gouvernance de l'information, protection des données et cybersécurité (car la récupération de rançongiciel est maintenant un scénario de continuité central), au Sujet 4.0 — Architecture technique, cloud et héritage (car la résilience est conçue en amont, pas ajoutée après coup), et au Sujet 6.4 — Gouvernance et assurance (car quelqu'un doit posséder, tester, et être responsable du plan). Bien faire cela et la perturbation devient une mauvaise journée ; mal le faire et elle devient une enquête publique.

Concepts fondamentaux#

Continuité d'activité et reprise après sinistre. La planification de continuité d'activité (BCP) est la capacité de continuer à livrer des produits ou services — dans votre cas, des soins sûrs — à des niveaux acceptables prédéfinis pendant et après un incident perturbateur. La reprise après sinistre informatique (DR) est le sous-ensemble technique plus étroit concerné par la restauration des systèmes, données, et infrastructure qui sous-tendent ces services. La continuité d'activité est la promesse plus large (« les patients continuent d'être traités ») ; la reprise après sinistre est l'un des moyens (« le système de résultats est de retour dans les quatre heures »). Vous avez besoin des deux, et vous ne devez pas confondre un serveur restauré avec un service restauré.

Gestion de continuité d'activité et analyse d'impact d'activité. La gestion de continuité d'activité (BCM) est le processus de gestion continu — pas un document ponctuel — qui identifie les menaces et construit la résilience organisationnelle. Sa fondation est l'analyse d'impact d'activité (BIA) : une évaluation structurée de chaque service qui demande à quelle vitesse sa perte cause un préjudice inacceptable, de quoi il dépend, et jusqu'où en arrière dans le temps vous pouvez vous permettre de perdre des données. La BIA est là où le jugement clinique entre dans l'ingénierie : les cliniciens, pas seulement les technologues, doivent définir ce que signifie « inacceptable » pour un système de maternité par rapport à un intranet du personnel.

Objectif de temps de récupération et objectif de point de récupération. Deux chiffres ancrent chaque plan de récupération. L'objectif de temps de récupération (RTO) est le temps maximum acceptable pour restaurer un service après un échec. L'objectif de point de récupération (RPO) est la quantité maximale acceptable de perte de données, exprimée en temps — un RPO de quinze minutes signifie que vous pouvez tolérer de perdre au maximum les quinze dernières minutes d'entrées. Pour un système clinique critique, ceux-ci peuvent être des minutes ; pour un entrepôt de rapports, ils peuvent être des jours. Les fixer honnêtement, par service, est la décision de continuité la plus utile que vous ferez.

Sauvegardes et restaurations testées. Une sauvegarde est une copie de données stockée ailleurs afin que l'original puisse être restauré après une perte. La base de référence de l'industrie est la règle 3-2-1 : trois copies, sur deux types de support, avec une détenue hors site (et, à l'ère du rançongiciel, une détenue immuable ou hors ligne). De manière cruciale, une sauvegarde que vous n'avez jamais restaurée est un espoir, pas un contrôle. Les rançongiciels chiffrent régulièrement les sauvegardes accessibles depuis le réseau, et les restaurations non testées échouent régulièrement le jour venu. La discipline n'est pas « sauvegardons-nous ? » mais « quand avons-nous restauré avec succès pour la dernière fois, de bout en bout, et combien de temps cela a-t-il pris ? »

Haute disponibilité, redondance, et bascule. La haute disponibilité (HA) est une propriété de conception qui garde un système en fonctionnement à travers l'échec de composants, habituellement mesurée en « neufs » de temps de fonctionnement. Elle est atteinte à travers la redondance — la duplication délibérée de composants critiques — et la bascule (failover), le basculement automatique vers un composant ou site de secours lorsque le principal échoue. La haute disponibilité réduit la fréquence des pannes ; la reprise après sinistre gère celles qui passent à travers. Elles sont complémentaires, pas des alternatives, et les confondre laisse des lacunes dangereuses.

Points uniques de défaillance et dépendances critiques. Un point unique de défaillance (SPOF) est tout composant dont l'échec arrête tout le service — un lien réseau, un service d'authentification, un fournisseur, une base de données, ou une personne qui seule sait comment quelque chose fonctionne. Cartographier les SPOF et les dépendances critiques (les services en amont et tiers dont votre service dépend silencieusement) est le cœur analytique de la résilience. Dans l'IT de santé moderne, les dépendances sont rarement locales : un service d'authentification unique, une connexion spine nationale, ou une région cloud peuvent mettre à terre de nombreux systèmes à la fois.

Temps d'arrêt clinique et procédures de continuité d'activité. La santé et l'action sociale ont un contrôle distinctif que l'IT générique n'a pas : la procédure de temps d'arrêt clinique, un repli répété et sûr — habituellement papier — pour livrer des soins lorsqu'un système numérique est indisponible, plus le processus de ré-entrée pour réconcilier ce dossier papier dans le système une fois qu'il revient. C'est la continuité d'activité rendue concrète au chevet du patient, et c'est là où les plans de continuité rencontrent le plus souvent la réalité.

Rançongiciel et cyber-récupération. Le rançongiciel chiffre vos données et exige un paiement, et il est devenu la menace de continuité déterminante pour les systèmes de santé. L'attaque du rançongiciel WannaCry de 2017 est le cas de référence : c'est pourquoi la cyber-récupération — isoler, reconstruire à partir de sauvegardes propres, et valider l'intégrité avant de reconnecter — est maintenant un scénario de premier ordre dans tout plan sérieux.

La norme de continuité. L'ISO 22301 est la norme internationale pour les systèmes de gestion de continuité d'activité. Elle fournit une structure reconnue — contexte, leadership, planification, soutien, exploitation, évaluation, amélioration — pour construire et auditer la capacité de continuité, et c'est une colonne vertébrale utile que vous cherchiez ou non une certification formelle.

Bonnes pratiques#

1. Commencez par une analyse d'impact d'activité possédée par les cliniciens, pas l'informatique seule. Classez chaque service par le préjudice clinique causé quand il échoue et par la vitesse à laquelle ce préjudice devient intolérable, puis assignez à chacun un RTO et RPO spécifique. Faites cela avec les cliniciens et gestionnaires opérationnels qui portent les conséquences, car « combien de temps pouvons-nous fonctionner sans cela en sécurité ? » est une question de soins, pas une question d'infrastructure. Le résultat est une liste priorisée qui vous dit où dépenser en premier votre budget de résilience fini.

2. Concevez la résilience proportionnellement à la criticité. Adaptez l'ingénierie à l'impact : les systèmes critiques pour la mission (service d'urgence, administration des patients, prescription électronique) justifient une haute disponibilité, une redondance géographique, et une bascule automatique ; les systèmes de criticité plus faible peuvent accepter une récupération plus longue et des sauvegardes plus simples. Résistez à la fois à la sous-ingénierie des systèmes critiques et à la survalorisation de ceux triviaux. L'architecture et la continuité doivent être conçues ensemble (voir Sujet 4.0 — Architecture technique, cloud et héritage), car vous ne pouvez pas ajouter la résilience après coup à une conception fragile.

3. Chassez les points uniques de défaillance et les dépendances cachées. Cartographiez systématiquement les dépendances de chaque service critique — réseau, authentification, DNS, connexions nationales, alimentation, refroidissement, fournisseurs clés, et personnes clés — et identifiez où un échec cascade. Portez une attention particulière aux services partagés tels que l'authentification unique ou un moteur d'intégration commun, dont l'échec met à terre de nombreux systèmes à la fois. Une dépendance que vous n'avez pas cartographiée est une dépendance que vous découvrirez pendant la panne.

4. Sauvegardez pour survivre au rançongiciel, et prouvez les restaurations en les testant. Suivez la règle 3-2-1 et gardez au moins une copie de sauvegarde immuable ou physiquement hors ligne, afin qu'un attaquant qui atteint votre réseau ne puisse pas chiffrer votre dernière ligne de défense. Puis testez les restaurations selon un calendrier, les chronométrant contre votre RTO et validant l'intégrité des données contre votre RPO — une restauration qui prend deux jours contre un objectif de quatre heures est un contrôle défaillant que vous n'avez simplement pas encore remarqué. Traitez « dernière restauration complète réussie » comme une métrique que vous rapportez, pas une tâche que vous supposez.

5. Écrivez, dotez en ressources, et répétez les procédures de temps d'arrêt clinique. Pour chaque système clinique critique, maintenez un repli papier (ou hors ligne) testé qui permet au personnel de continuer à livrer des soins sûrs pendant une panne, plus un processus clair pour ré-entrer ces données ensuite sans perte ni duplication. Stockez les formulaires de temps d'arrêt là où ils peuvent être atteints quand le réseau et les imprimantes sont aussi hors service. Répétez-les avec le personnel de première ligne, car une procédure qui ne vit que dans un dossier ne sera ni trouvée, ni comprise, ni fiable à 3h du matin pendant une crise.

6. Maintenez un plan de reprise après sinistre avec une véritable bascule de site. Documentez, pour chaque système critique, exactement comment il récupère : ce qui fonctionne où, dans quel ordre, qui décide de l'invoquer, et comment vous rebasculez ensuite. Là où l'impact le justifie, exploitez un site ou une région de récupération véritablement séparé et prouvez que vous pouvez y basculer — l'ordre de récupération compte, car les systèmes ont des dépendances qui dictent la séquence. Un site DR non testé est une hypothèse coûteuse.

7. Exercez le plan ; un plan jamais testé est un plan qui échoue. Menez des exercices réguliers à travers un spectre : des exercices sur table de bureau des scénarios, des tests techniques de bascule, et des simulations complètes en direct occasionnelles incluant le repli clinique. Les exercices exposent les lacunes — la liste de contacts périmée, l'étape de récupération qui nécessite un mot de passe que personne n'a, l'hypothèse que le personnel connaît le processus papier — pendant qu'il est sûr de les trouver. Capturez les leçons, corrigez-les, et retestez ; un exercice sans suivi est du théâtre.

8. Étendez la continuité à vos fournisseurs et cloud. Votre résilience n'est aussi forte que les tiers dont vos services critiques dépendent, donc faites de la continuité une question contractuelle et d'assurance : exigez que les fournisseurs prouvent leur propre RTO/RPO, test DR, et cyber-récupération, et comprenez le modèle de responsabilité partagée de votre fournisseur cloud — les zones et régions de disponibilité protègent contre certains échecs mais pas contre une mauvaise configuration ou une compromission de compte que vous possédez. Planifiez pour l'échec de fournisseur lui-même, y compris le scénario où un fournisseur clé est celui frappé par un rançongiciel (voir Sujet 6.3 — Achats et commercial).

9. Adoptez une norme reconnue et placez la continuité sous gouvernance. Utilisez l'ISO 22301 comme colonne vertébrale structurée et les directives du NHS et nationales comme superposition sectorielle, et donnez à un dirigeant nommé la responsabilité de la continuité d'activité, rapportant au conseil d'administration. Une continuité que personne ne possède, finance, ou révise se dégrade discrètement jusqu'à ce que l'incident la révèle. Câblez-la dans votre cadre d'assurance (voir Sujet 6.4 — Gouvernance et assurance) afin que les plans soient maintenus, testés, et améliorés comme une question de routine, pas redécouverts en crise.

Questions à discuter avec votre équipe#

1. Pour chacun de nos systèmes cliniques critiques, quels RTO et RPO avons-nous réellement convenus avec les cliniciens — et pouvons-nous actuellement les respecter ? Cette question force l'écart entre aspiration et capacité au grand jour. De nombreuses organisations n'ont jamais fixé d'objectifs de récupération explicites, ou les ont fixés en informatique sans contribution clinique, donc le temps d'arrêt « acceptable » est réellement juste ce que l'architecture actuelle livre. Débattez de où le besoin clinique (minutes pour un système d'urgence) entre en collision avec ce que vos sauvegardes et DR peuvent réellement atteindre (peut-être un jour), car cet écart est un risque clinique non géré que vous portez que vous le nommiez ou non. Regardez concrètement votre dernière véritable ou testée récupération : combien de temps a-t-elle pris, combien de données auriez-vous perdues, et qui a validé que c'était sûr ? Une bonne réponse honnête nomme des chiffres spécifiques par système, admet où vous ne pouvez pas encore les respecter, et transforme chaque écart en une action financée plutôt qu'un silence confortable.

2. Si un rançongiciel chiffrait nos systèmes principaux et nos sauvegardes ce soir, comment garderions-nous les patients en sécurité demain — et combien de temps avant d'être entièrement récupérés ? C'est le scénario qui a frappé de véritables systèmes de santé, donc il mérite un exercice concret et sans faille plutôt qu'une réassurance. Explorez honnêtement les deux moitiés : la continuité clinique immédiate (les procédures de temps d'arrêt sont-elles répétées, dotées en ressources, et assez fiables pour exploiter tout un hôpital sur papier pendant des jours ?) et la récupération technique (les sauvegardes sont-elles immuables et hors ligne, avez-vous testé la reconstruction à partir de copies propres, et connaissez-vous l'ordre de récupération ?). Faites surgir les dépendances inconfortables — si l'authentification unique, le moteur d'intégration, ou un fournisseur clé est en panne, combien d'autres choses tombent avec ? Considérez qui déclare l'incident majeur, qui parle au personnel, patients, et médias, et qui décide qu'un système est sûr à reconnecter. Une réponse forte décrit un plan répété avec des rôles nommés et des restaurations testées ; une faible suppose que les sauvegardes vont bien et que le processus papier fonctionnera simplement.

3. Quand avons-nous testé pour la dernière fois nos plans de continuité et de reprise après sinistre de bout en bout, et qu'avons-nous appris ? Le but ici est de distinguer une capacité vivante d'un document d'étagère. Un plan qui n'a pas été exercé est non testé, et les plans non testés échouent régulièrement au contact avec la réalité — la liste de contacts est périmée, l'étape de récupération nécessite des identifiants que personne n'a, les formulaires de temps d'arrêt sont stockés sur le système qui est en panne. Discutez de l'éventail d'exercices que vous faites réellement : scénarios de bureau, tests techniques de bascule, et simulations complètes qui incluent le repli clinique de première ligne, pas seulement la restauration de serveur. Sondez si les leçons des incidents et exercices passés ont réellement été corrigées et retestées, ou consignées et oubliées. Une bonne réponse montre un calendrier d'exercices régulier, des preuves de lacunes trouvées et fermées, et une honnêteté sur quelles parties du plan restent non prouvées.

4. Lesquelles de nos dépendances critiques ne contrôlons-nous pas — et quel est notre plan pour le jour où l'une d'elles échoue ? L'IT de santé moderne échoue rarement seule ; elle échoue à travers les services et fournisseurs en dessous d'elle. Poussez l'équipe au-delà des systèmes que vous possédez vers ceux dont vous dépendez simplement : la connexion spine nationale, le fournisseur d'authentification unique, la région cloud, le moteur d'intégration, le centre de données externalisé, le partenaire de service géré qui détient les clés de la récupération. Pour chacun, demandez ce qui arrive aux soins s'il disparaît pendant un jour, si le contrat oblige le tiers à un objectif de récupération qui correspond à votre besoin clinique, et si vous avez déjà vu une preuve de leur test DR plutôt qu'un paragraphe rassurant dans une offre. La vérité inconfortable est que vous pouvez porter un risque résiduel que vous n'avez jamais tarifé, car l'échec se situe dans le parc de quelqu'un d'autre. Une réponse honnête nomme les dépendances externes spécifiques de chaque service critique, énonce lesquelles sont contractuellement assurées et lesquelles sont simplement de confiance, et identifie un repli — même manuel — pour les dépendances que vous ne pouvez pas rendre résilientes.

5. Lorsqu'un incident majeur frappe, qui décide quoi, qui communique à qui, et tout le monde connaît-il son rôle avant le jour ? La continuité concerne autant le commandement et la communication que les sauvegardes, et c'est là que les plans répétés et le chaos improvisé divergent. Passez en revue la chorégraphie humaine : qui a l'autorité de déclarer un incident majeur et d'invoquer le plan, qui dirige la réponse opérationnelle, qui décide qu'un système est sûr à reconnecter, et qui parle au personnel, aux patients, à la presse, aux régulateurs, et — dans une cyberattaque — aux forces de l'ordre. Considérez l'échec de vos propres outils pendant l'incident, car la panne peut mettre hors service l'e-mail, l'annuaire téléphonique, ou l'intranet que vous utiliseriez normalement pour coordonner. Faites surgir la tension entre se déplacer vite et se déplacer en sécurité, et les enjeux réputationnels de mal faire passer le message public. Une réponse forte pointe vers une structure de commandement d'incident testée avec des rôles nommés et suppléés, des canaux de communication hors bande, et des modèles de message pré-convenus ; une faible suppose que les bonnes personnes se rassembleront simplement et sauront quoi faire.

6. Comment finançons-nous, possédons-nous, et maintenons-nous la continuité vivante quand rien n'a mal tourné depuis deux ans ? La résilience se dégrade discrètement dans l'écart entre les incidents, et cette question confronte la discipline organisationnelle qui l'empêche de pourrir. La continuité rivalise pour l'argent et l'attention contre des priorités cliniques et numériques visibles et urgentes, et l'organisation immature-et-chanceuse ressemble identique à la mature jusqu'au jour où elle ne l'est plus. Débattez de qui possède véritablement la continuité au niveau exécutif, si elle a une ligne financée plutôt qu'une bonne volonté empruntée, et comment les plans, cartes de dépendances, et listes de contacts sont maintenus à jour à mesure que les systèmes et le personnel changent. Demandez ce que le conseil d'administration voit réellement — une assurance testée et des lacunes honnêtes, ou une note verte et un document classé. Une bonne réponse décrit une responsabilité nommée, un budget récurrent et un calendrier d'exercices, et un rythme de gouvernance qui traite la continuité maintenue et testée comme routinière plutôt que quelque chose redécouvert dans la prochaine crise.

En pratique : un exemple de santé et d'action sociale#

Le Meadowvale NHS Foundation Trust exploite un hôpital de soins aigus de 600 lits. Un mardi matin, le personnel arrive pour trouver ses systèmes de dossier de santé électronique (EPR), de pathologie, et de radiologie verrouillés par une note de rançon ; les attaquants étaient entrés via un compte d'accès à distance d'un fournisseur dix jours plus tôt. Le directeur de l'information déclare un incident majeur dans l'heure, et le plan de continuité d'activité du trust s'active.

Parce que le trust avait fait son analyse d'impact d'activité, il savait que l'EPR et la pathologie étaient ses systèmes de plus haute criticité, avec des objectifs de récupération convenus, tandis que ses procédures de temps d'arrêt avaient été répétées l'automne précédent. Les services passent aux graphiques de médicaments papier et aux formulaires d'observation préimprimés — stockés délibérément dans des armoires physiques sur chaque service, pas sur un lecteur partagé — et le service d'urgence revient à son parcours papier. Les opérations électives de la semaine sont reportées et communiquées aux patients ; les ambulances sont déroutées des périodes les plus chargées. Les soins continuent, dégradés mais sûrs, car le personnel avait pratiqué le travail de cette manière.

La récupération est plus difficile que la restauration. L'équipe de sécurité isole le réseau pour arrêter la propagation, puis reconstruit les systèmes critiques à partir de sauvegardes immuables détenues hors ligne — des copies que les attaquants ne pouvaient pas atteindre. Ces sauvegardes avaient été testées en restauration trimestriellement, donc l'équipe savait que le processus fonctionnait et à peu près combien de temps cela prenait ; l'EPR est de retour dans son RTO de huit heures, bien que la pathologie, avec des dépendances plus complexes, prenne deux jours. Le RPO de quinze minutes signifie que seule une courte fenêtre de données a été perdue, et le personnel réconcilie les dossiers papier dans le système sous un processus de ré-entrée contrôlé, revérifiant les médicaments et résultats.

Dans le débriefing, le trust trouve de véritables lacunes : l'authentification unique était un point unique de défaillance qui a retardé l'accès des cliniciens pendant la récupération, et l'accès à distance du fournisseur n'avait pas été couvert par la propre assurance de continuité du trust. Les deux vont dans le registre des risques du conseil d'administration avec des propriétaires et des dates, et le prochain exercice complet est programmé. Ce fut une mauvaise semaine — mais pas une catastrophe, car le plan existait, était doté en ressources, et avait été testé.

Angles sectoriels#

Startup#

Une startup de santé numérique a rarement un centre de données de réserve, donc sa stratégie de continuité s'appuie presque entièrement sur la résilience native du cloud et des sauvegardes disciplinées. Utilisez des services gérés avec haute disponibilité intégrée à travers les zones de disponibilité, automatisez les sauvegardes avec des copies immuables et hors compte pour survivre à la fois au rançongiciel et à un compte cloud compromis, et répétez réellement une restauration dans un environnement propre. Vos clients — trusts du NHS et integrated care systems — exigeront de plus en plus une preuve de RTO, RPO, et test DR à travers des cadres comme le DTAC et l'assurance fournisseur, donc traitez la continuité comme un atout de vente, pas une charge. Le risque existentiel pour un petit fournisseur est qu'un seul incident, ou le fondateur qui seul comprend le déploiement, devienne votre point unique de défaillance.

Petite entreprise#

Un prestataire établi de petite taille — un cabinet de médecins généralistes, une pharmacie communautaire, une maison de retraite, une agence de soins à domicile, ou une clinique monosite — porte le même devoir de garder les patients en sécurité à travers une panne qu'un grand trust, mais avec de vrais patients, une trésorerie mince, et souvent aucun personnel informatique dédié du tout. La continuité ici est délibérément pragmatique : sachez quel un ou deux systèmes (le dossier clinique, le système de dispensation ou eMAR) arrêteraient les soins sûrs s'ils échouaient, insistez pour que votre fournisseur de système prouve ses propres sauvegardes, RTO, et RPO, et gardez un pack de temps d'arrêt simple et imprimé — graphiques de médicaments papier, numéros de téléphone clés, listes de patients récentes — où le personnel peut l'atteindre quand les écrans sont noirs. Parce qu'un seul gestionnaire de cabinet ou un contractant informatique isolé est fréquemment la seule personne qui comprend la configuration, écrivez les étapes de récupération et assurez-vous qu'une deuxième personne puisse les suivre. Le rançongiciel et une ligne haut débit cassée sont les menaces quotidiennes, donc une copie de sauvegarde hors ligne ou immuable et une façon de travailler de repli comptent plus que tout site DR élaboré que vous ne pouvez pas vous permettre ou exploiter.

Entreprise#

Un grand trust du NHS, un integrated care system, ou un grand fournisseur de health-tech porte un parc tentaculaire et interdépendant où le problème le plus difficile est de cartographier les dépendances et services partagés, pas un système unique. Investissez dans un programme BCM formel aligné sur l'ISO 22301, une carte de dépendances maintenue, des sites ou régions DR pour les systèmes critiques, et un calendrier continu d'exercices qui inclut le repli clinique. L'échelle signifie que les SPOF sont souvent des services partagés — identité, moteurs d'intégration, cœurs de réseau — dont l'échec cascade à travers des dizaines de systèmes. La gouvernance est la contrainte contraignante : avec de nombreuses équipes et fournisseurs, la continuité ne tient que si un dirigeant nommé la possède et que le conseil d'administration révise une assurance testée, pas des plans sur papier.

Gouvernement#

Un organisme national — NHS England, un département de santé décentralisé, ou UKHSA — doit penser la résilience à l'échelle de la population et systémique, où l'échec d'un service national ou d'un fournisseur largement utilisé est lui-même un événement de continuité pour tout le secteur. Fixez des normes et attentes (objectifs de récupération, cyber-récupération, exercice obligatoire), financez des capacités protectrices partagées, et coordonnez la réponse à l'échelle du secteur aux incidents majeurs tels qu'une campagne nationale de rançongiciel. La réponse à WannaCry a remodelé la politique nationale précisément parce que l'impact a traversé des centaines d'organisations à la fois, exposant des faiblesses communes. La responsabilité ici est publique et parlementaire, donc la transparence sur les risques connus, et le rapport honnête de la préparation, comptent autant que les contrôles techniques eux-mêmes.

Modes d'échec courants#

• Sauvegardes jamais restaurées. Confondre « nous sauvegardons chaque nuit » avec « nous pouvons récupérer ». Les restaurations non testées échouent régulièrement ou dépassent le RTO ; mesurez et rapportez les restaurations de bout en bout réussies, pas l'achèvement de sauvegarde.
• Sauvegardes accessibles au rançongiciel. Garder chaque sauvegarde en ligne et connectée au réseau, de sorte qu'un attaquant les chiffre avec la production. Détenez au moins une copie immuable ou hors ligne.
• DR qui protège les serveurs, pas les services. Restaurer une base de données mais pas les dépendances, intégrations, et accès qui en font un service clinique utilisable. Récupérez et testez des services entiers, dans l'ordre de dépendance.
• Procédures de temps d'arrêt qui n'existent que sur papier à propos de papier. Plans de repli jamais répétés, stockés sur le système qui échoue, ou inconnus du personnel de première ligne. Répétez-les là où les soins se passent réellement.
• Dépendances non cartographiées et SPOF partagés. Découvrir pendant la panne que l'authentification unique, le DNS, ou un fournisseur sous-tendait tout. Cartographiez les dépendances avant, pas pendant, l'incident.
• Un plan écrit pour l'auditeur, jamais exercé. La continuité comme document de conformité qui se dégrade non testé jusqu'au jour où il est nécessaire. Un plan jamais testé est un plan qui échoue.
• Ignorer la continuité fournisseur et cloud. Supposer que vos tiers sont résilients sans preuve, et oublier le modèle de responsabilité partagée. Rendez la continuité contractuelle et assurée.

Modèle de maturité#

Liste de contrôle#

• Une analyse d'impact d'activité, possédée avec les cliniciens, classe chaque service et fixe un RTO et RPO explicite pour chaque système critique.
• Les systèmes critiques ont une haute disponibilité et une redondance proportionnées à leur criticité clinique.
• Les points uniques de défaillance et dépendances critiques (y compris services partagés et fournisseurs) sont cartographiés et atténués.
• Les sauvegardes suivent la règle 3-2-1 avec au moins une copie immuable ou hors ligne que le rançongiciel ne peut atteindre.
• Les restaurations sont testées selon un calendrier et chronométrées contre RTO/RPO, avec « dernière restauration réussie » rapportée comme métrique.
• Chaque système clinique critique a une procédure de temps d'arrêt répétée et un processus de ré-entrée de données contrôlé.
• Un plan de reprise après sinistre définit les étapes de récupération, l'ordre, l'autorité de décision, et le rebasculement, et le site/région DR est testé.
• Un scénario de cyber-récupération (isoler, reconstruire à partir de sauvegardes propres, valider, reconnecter) est documenté et exercé.
• La continuité fournisseur et cloud est contractuellement requise, prouvée, et assurée, incluant le modèle de responsabilité partagée.
• La continuité est alignée sur l'ISO 22301, possédée par un dirigeant nommé, exercée selon un calendrier, et rapportée au conseil d'administration.

Sources clés#

• NHS England — Business Continuity Management Toolkit and Emergency Preparedness, Resilience and Response (EPRR) Framework and Core Standards.
• National Cyber Security Centre (NCSC) — guidance on offline/immutable backups, ransomware mitigation, and incident response.
• ISO 22301:2019 — Security and resilience — Business continuity management systems — Requirements (International Organization for Standardization).
• ISO/IEC 27031 — Guidelines for information and communication technology readiness for business continuity.
• Business Continuity Institute (BCI) — Good Practice Guidelines.
• National Audit Office — Investigation: WannaCry cyber attack and the NHS (2017) and Department of Health lessons-learned review.
• NHS England / Data Security and Protection Toolkit (DSPT) — data security standards including business continuity and incident response.
• GOV.UK Service Manual — resilience, monitoring, and recovery guidance for live services.

Références#

1. Business continuity planning — Wikipédia — https://en.wikipedia.org/wiki/Business_continuity_planning
2. IT disaster recovery — Wikipédia — https://en.wikipedia.org/wiki/IT_disaster_recovery
3. ISO 22301 — Wikipédia — https://en.wikipedia.org/wiki/ISO_22301
4. Backup — Wikipédia — https://en.wikipedia.org/wiki/Backup
5. High availability — Wikipédia — https://en.wikipedia.org/wiki/High_availability
6. Redundancy (engineering) — Wikipédia — https://en.wikipedia.org/wiki/Redundancy_(engineering)
7. Failover — Wikipédia — https://en.wikipedia.org/wiki/Failover
8. Single point of failure — Wikipédia — https://en.wikipedia.org/wiki/Single_point_of_failure
9. Ransomware — Wikipédia — https://en.wikipedia.org/wiki/Ransomware
10. WannaCry ransomware attack — Wikipédia — https://en.wikipedia.org/wiki/WannaCry_ransomware_attack
11. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements — International Organization for Standardization — https://www.iso.org/standard/75106.html
12. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
13. Emergency Preparedness, Resilience and Response (EPRR) — NHS England — https://www.england.nhs.uk/ourwork/eprr/
14. Offline backups in an online world — National Cyber Security Centre — https://www.ncsc.gov.uk/blog-post/offline-backups-in-an-online-world
15. Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/