Plan de reprise après sinistre : tester avant d’en avoir besoin
Un plan de reprise informatique qui n'a jamais été testé n'est qu'une hypothèse. À l'hôpital, on découvre ses failles soit pendant un exercice, soit pendant une cyberattaque. Mieux vaut la première option.
Le plan de reprise est rangé dans un classeur, à jour, signé. Le jour où le système d’information de l’hôpital est chiffré par un rançongiciel, l’équipe découvre que les sauvegardes du serveur d’identités étaient sur le même domaine que la production, que la procédure suppose un accès VPN qui ne fonctionne plus, et que le numéro d’astreinte du prestataire a changé. Un plan de reprise après sinistre à l’hôpital ne vaut que par ses tests. Ce guide propose une progression réaliste.
Pourquoi les plans échouent
Les retours d’expérience d’établissements touchés, partagés par les autorités et les agences de santé, montrent rarement un défaut de conception majeur. Ils montrent des détails : une dépendance oubliée, un accès d’urgence inexistant, une sauvegarde qui n’a jamais été restaurée en entier. Ce sont précisément les détails que seul un test révèle.
Une sauvegarde n’existe vraiment qu’une fois qu’on l’a restaurée.
Préalable : savoir ce qu’on veut rétablir, et en combien de temps
Un test n’a de sens que par rapport à un objectif. Pour chaque application critique (dossier patient, prescription, laboratoire, imagerie, bloc, pharmacie, identités, messagerie sécurisée), le plan doit indiquer :
- la durée maximale d’interruption admissible (RTO), décidée avec les médecins et les soignants, pas seulement par la DSI ;
- la perte de données maximale admissible (RPO) ;
- les dépendances : annuaire, réseau, base de données, licences, interfaces avec d’autres applications ;
- l’ordre de reprise : le dossier patient ne redémarre pas sans le serveur d’identités ni l’annuaire ;
- la procédure de mode dégradé des services pendant l’interruption.
Les quatre niveaux de test
Les tests se complètent. Chaque niveau révèle des erreurs que le précédent ne voit pas.
Niveau 1 : la relecture sur table
Les acteurs du plan (DSI, direction, soignants, prestataires) se réunissent deux heures et déroulent un scénario, pas à pas, document en main. « Le système est chiffré à 3 heures du matin. Qui est appelé ? Par quel moyen, si la messagerie est hors service ? Où sont les comptes d’urgence ? » Coût faible, résultats souvent spectaculaires : annuaires de crise périmés, rôles flous, procédures qui supposent un outil indisponible.
Niveau 2 : l’exercice de crise simulé
Une cellule de crise est réellement activée, sur une demi-journée, avec des stimuli injectés par une équipe d’animation : appel de la presse, panne qui s’étend, service qui réclame un résultat de laboratoire. L’ANSSI a publié un guide pour organiser un exercice de gestion de crise cyber. On teste ici la décision, la communication, la coordination avec les services de soins, et le passage au mode dégradé.
Niveau 3 : la restauration technique
Sur un environnement isolé, l’équipe technique restaure réellement un système critique à partir des sauvegardes, jusqu’à ce qu’un utilisateur puisse s’y connecter et consulter des données cohérentes. On mesure le temps réel, que l’on compare au RTO. C’est le test qui révèle les sauvegardes incomplètes, les clés de chiffrement introuvables et les dépendances oubliées.
Niveau 4 : la bascule réelle
Pour les systèmes qui disposent d’un site de secours, la production est réellement basculée, puis rebasculée. C’est le test le plus probant et le plus risqué ; il se planifie avec les services, à un moment de moindre activité, avec une procédure de retour arrière écrite.
| Niveau | Ce qu’il révèle | Fréquence indicative |
|---|---|---|
| Relecture sur table | Rôles, contacts, procédures irréalistes | Annuelle, et après chaque changement majeur |
| Exercice de crise | Décision, communication, mode dégradé | Annuelle ou tous les deux ans |
| Restauration technique | Sauvegardes, dépendances, délais réels | Plusieurs fois par an, par rotation des systèmes |
| Bascule réelle | Capacité effective du site de secours | Annuelle pour les systèmes concernés |
Le mode dégradé, partie intégrante du test
À l’hôpital, les soins ne s’arrêtent pas pendant que l’informatique redémarre. Les services basculent sur des procédures papier : fiches de prescription, bons de demande d’examens, registres d’admission, identification des patients. Ces procédures doivent être testées avec les équipes de soins, pas seulement relues. Un kit papier rangé au fond d’une armoire, avec des formulaires périmés, ne sert à rien à 3 heures du matin.
On oublie souvent la fin de l’incident : il faut ressaisir dans le dossier informatisé ce qui a été fait sur papier pendant l’interruption, sans erreur ni doublon. Cette phase prend du temps et doit être prévue, avec ses ressources et ses contrôles.
Exploiter chaque test
- Consigner les écarts Chaque test se termine par une liste d’écarts, sans recherche de coupable.
- Décider des actions Une action, un responsable, une échéance par écart significatif.
- Mettre à jour le plan Le document est corrigé dans la semaine, et diffusé en version datée.
- Vérifier au test suivant Les écarts corrigés sont re-testés en priorité.
Un exercice qui ne révèle aucun écart était probablement trop facile. Les dispositifs nationaux d’accompagnement des établissements de santé en cybersécurité, comme le programme CaRE en France, intègrent d’ailleurs les exercices et la continuité parmi leurs priorités.
Un calendrier annuel réaliste
- Premier trimestre : relecture sur table du plan complet, mise à jour des contacts.
- Chaque trimestre : restauration technique d’un ou deux systèmes critiques, par rotation.
- Deuxième semestre : exercice de crise avec activation du mode dégradé dans au moins un service.
- En continu : test après chaque changement majeur d’infrastructure ou d’application.
Notre solution Betz et notre expertise santé numérique intègrent la reprise et le mode dégradé dès la conception des systèmes. Pour le contexte des menaces, voir aussi l’article sur les rançongiciels et les petites structures.
Questions fréquentes
Quelle différence entre plan de continuité et plan de reprise ?
Le plan de continuité organise le maintien des activités essentielles pendant l'incident, souvent en mode dégradé. Le plan de reprise organise le retour des systèmes informatiques et des données dans un délai défini. À l'hôpital, les deux sont indissociables.
À quelle fréquence tester un plan de reprise ?
Un exercice sur table au moins une fois par an, une restauration technique des systèmes critiques plusieurs fois par an, et un exercice de crise plus complet chaque année ou tous les deux ans selon la taille de l'établissement.
Que sont le RTO et le RPO ?
Le RTO (durée maximale d'interruption admissible) fixe le délai dans lequel un système doit être rétabli. Le RPO (perte de données maximale admissible) fixe jusqu'à quel point dans le passé les données peuvent être perdues. Ils se décident avec les métiers, système par système.
Les tests peuvent-ils perturber les soins ?
Les tests sur table et les restaurations sur environnement isolé ne touchent pas la production. Les bascules réelles doivent être planifiées avec les services, à des moments de moindre activité, avec un retour arrière prévu.