Ransomware à l'hôpital : pourquoi la réponse compte plus que la prévention

En février 2024, un seul ransomware (un logiciel malveillant qui chiffre les fichiers d’un ordinateur et réclame une rançon pour les débloquer) a mis hors service en une journée les systèmes de dossiers patients de plus d’une centaine d’hôpitaux roumains. Les médecins sont repassés au papier et au stylo pour les admissions, les demandes d’analyses ont circulé à la main entre les services, et les pharmacies ont préparé les commandes à partir de notes manuscrites. Aucun décès n’a été signalé, et la plupart des hôpitaux avaient retrouvé un fonctionnement à peu près normal en une semaine. C’est justement ce dénouement calme, plutôt qu’une catastrophe, qui rend le cas intéressant à étudier : la réponse à un ransomware hospitalier se joue moins sur la capacité à empêcher chaque attaque que sur ce qui se passe dans les heures et les semaines qui suivent une intrusion réussie.

Ce que recouvre vraiment la réponse à incident

Prévention et réponse à incident ne résolvent pas le même problème, et un hôpital doué pour l’une n’est pas automatiquement doué pour l’autre. La prévention cherche à empêcher l’attaquant d’entrer : corriger les logiciels, cloisonner le réseau, apprendre au personnel à repérer un email de phishing (un message piégé qui imite une source de confiance). La réponse à incident part d’un postulat différent : l’attaquant est déjà à l’intérieur. Elle pose une série de questions plus étroite. Peut-on isoler les systèmes touchés assez vite pour empêcher que les dégâts ne se propagent ? L’organisation peut-elle restaurer ses données depuis une sauvegarde plutôt que de négocier avec l’attaquant ? Comment les soins aux patients continuent-ils pendant que les ordinateurs sont hors service ? Et une fois la panne visible terminée, combien de temps prend la partie invisible du rétablissement, à savoir rattraper tout ce qui s’est accumulé pendant que les systèmes étaient éteints ?

Les hôpitaux roumains répondent bien aux quatre questions, ce qui justifie de s’y attarder plutôt que de se contenter du titre dans la presse. L’attaque en elle-même n’avait rien d’inhabituel : un logiciel obsolète, un groupe criminel motivé par l’argent, un système partagé qui donnait à une seule intrusion une portée démesurée. Ce qui a rendu l’issue exceptionnelle, c’est la réponse qui a suivi, construite des mois avant que quiconque sache qu’une attaque se préparait.

Ce qui s’est passé dans les hôpitaux roumains

L’attaque a démarré dans un hôpital pour enfants de Pitești le samedi 10 février 2024, quand le personnel a découvert que les dossiers patients venaient d’être chiffrés et rendus illisibles. Au cours des deux jours suivants, elle s’est propagée à des dizaines d’autres établissements utilisant le même logiciel, un système appelé Hipocrate Information System, développé par un éditeur basé à Bucarest, Romanian Soft Company, qui gère les admissions, les résultats de laboratoire, les commandes de pharmacie et la facturation pour une large part des lits d’hôpitaux du pays. Comme tant d’hôpitaux étaient connectés à cette même plateforme, le ransomware s’est propagé dans le réseau plus vite qu’aucune équipe informatique isolée n’aurait pu réagir seule. Le temps que la direction nationale roumaine de la cybersécurité, la DNSC, termine son évaluation des dégâts, 26 hôpitaux avaient effectivement leurs données bloquées, et environ 79 de plus avaient été déconnectés d’Internet par précaution avant que le ransomware ne puisse les atteindre. C’est cette addition qui donne le chiffre largement repris de « cent hôpitaux » : un mélange d’établissements réellement touchés et d’établissements coupés du réseau avant de l’être.

L’outil derrière l’attaque était une souche de ransomware nommée Backmydata, une variante d’une famille plus ancienne appelée Phobos, en circulation chez des groupes criminels depuis des années. Les attaquants ont exigé 3,5 bitcoins, soit entre environ 157 000 et 160 000 euros selon le taux de change retenu par les médias pour les convertir. Ces chiffres donnent une idée de l’ampleur, mais ils sont aussi la partie la plus périssable de l’histoire. Ce qui compte, six mois ou six ans plus tard, ce n’est pas le cours du bitcoin. C’est ce que les hôpitaux ont fait ensuite.

Pourquoi une intrusion est devenue le problème de cent hôpitaux

Il ne s’agissait pas de cent failles de sécurité indépendantes survenues en même temps. C’était un seul logiciel partagé qui a fait boule de neige dans chaque hôpital connecté à lui, quelle que soit la préparation de chaque équipe informatique prise isolément.

C’est la même logique qui explique les attaques sur la chaîne logicielle, où un composant compromis atteint discrètement toutes les organisations qui l’ont installé, et la poussée vers une architecture zero trust, où le fait de se connecter à une plateforme partagée ne devrait jamais donner automatiquement un accès large à tout le reste du réseau. Aucune des deux idées n’aurait arrêté cette attaque précise, mais toutes deux pointent la même faiblesse : une infrastructure partagée, c’est un rayon d’impact partagé.

La rançon que personne n’a payée

Les autorités roumaines, via la DNSC, ont publiquement recommandé de ne pas payer la rançon, et aucune rançon n’a été versée. Le message de demande de rançon rompait lui-même avec un usage tacite du secteur : selon la DNSC, il ne donnait qu’une adresse email pour tout contact, sans nom de groupe, sans logo, sans aucune des mises en scène que les organisations de ransomware modernes utilisent d’ordinaire pour se faire connaître et faire pression sur leurs victimes. Le groupe à l’origine de l’attaque n’a jamais été identifié publiquement, une zone d’ombre inhabituelle pour une attaque de cette ampleur.

Un coordinateur, pas seulement cent hôpitaux isolés

Une partie de ce qui a limité les dégâts s’est jouée avant même que la plupart des hôpitaux touchés sachent qu’ils étaient exposés. La DNSC, agissant comme organe de coordination unique, a pris la décision de déconnecter préventivement environ 79 établissements de santé d’Internet dès que l’ampleur de l’attaque est devenue claire. C’est une décision que seul un organisme ayant autorité sur de nombreux hôpitaux à la fois peut prendre rapidement. L’équipe informatique d’un hôpital pris isolément, aussi compétente soit-elle, ne peut pas débrancher un établissement voisin sur lequel elle n’a aucune autorité.

C’est la partie de la réponse qui apparaît rarement dans les titres de presse a posteriori, précisément parce qu’elle est ennuyeuse par construction : quelqu’un ayant l’autorité d’agir sur tout un secteur, et un plan déjà préparé pour le jour où un système partagé serait compromis, plutôt que des dizaines d’hôpitaux découvrant en parallèle la même urgence et improvisant chacun de son côté.

La sauvegarde qui a vraiment fonctionné

La raison pour laquelle les autorités roumaines ont pu recommander de ne pas payer, et pour laquelle les hôpitaux ont réellement suivi ce conseil, tient à un fait peu spectaculaire : la plupart des hôpitaux touchés disposaient de sauvegardes récentes qui avaient été réellement testées et pouvaient être restaurées. La DNSC a crédité ces sauvegardes du retour en ligne des systèmes sans qu’il ait été nécessaire de négocier avec les attaquants.

Une sauvegarde qui n’existe que sur le papier, dans un document de politique informatique, n’a rien à voir avec une sauvegarde qui a été répétée et dont on a vérifié qu’elle fonctionne sous pression, et l’écart entre les deux reste invisible jusqu’au jour où il compte vraiment.

Le papier et le stylo ont encore leur utilité

Pendant que les systèmes numériques étaient hors service, le personnel hospitalier n’a pas improvisé. Il est revenu aux admissions, aux demandes d’analyses et aux commandes de pharmacie manuscrites, un plan de continuité manuel établi et déjà répété avant l’attaque, pas inventé sur le moment. Cette nuance compte : un plan de secours répété permet à un hôpital de continuer à fonctionner à un rythme plus lent, tandis qu’un plan improvisé produit des erreurs précisément au moment où les patients peuvent le moins se le permettre.

L’ère du papier ne s’est pas arrêtée dès que les ordinateurs sont revenus. Ressaisir des semaines de dossiers manuscrits dans les systèmes numériques a pris nettement plus de temps que le retour des hôpitaux eux-mêmes à un fonctionnement normal, survenu en environ cinq jours. Le rétablissement visible et le rétablissement invisible n’avancent pas sur le même calendrier, et les organisations qui ne préparent que le premier se font généralement surprendre par le second.

Ce qui a rendu l’issue roumaine différente

Deux autres cyberattaques hospitalières bien documentées offrent un contraste utile. L’attaque WannaCry de 2017 contre le service de santé public britannique (NHS) a perturbé des dizaines d’établissements hospitaliers et entraîné l’annulation de milliers de rendez-vous, mais il s’agissait d’un ver incontrôlé se propageant sans discernement sur Internet plutôt que d’une attaque visant spécifiquement des hôpitaux, et aucun décès de patient n’y a été formellement rattaché. L’attaque de 2024 contre Synnovis, un prestataire de services de pathologie pour des hôpitaux londoniens, était plus ciblée et plus lourde de conséquences : un rapport de 2025 du King’s College Hospital NHS Trust a établi que la perturbation, notamment via des retards dans les résultats d’analyses sanguines, avait contribué au décès d’un patient, premier cas publiquement confirmé au Royaume-Uni d’une cyberattaque ayant contribué à un décès.

L’incident roumain se situe entre les deux par son ampleur, mais s’en distingue par son issue. Aucun décès n’a été signalé, et les hôpitaux ont retrouvé un fonctionnement normal en quelques jours, pas en quelques semaines. La technologie en cause, un ransomware du commerce touchant des systèmes obsolètes ou mal cloisonnés, n’était ni sensiblement plus avancée ni moins avancée que dans les deux autres cas. Ce qui a fait la différence, c’est la préparation : des sauvegardes testées, un organisme national disposant d’un plan déjà rodé pour coordonner la réponse, et un personnel qui savait déjà faire tourner un hôpital sur le papier.

Questions fréquentes

Que recouvre concrètement la réponse à un ransomware hospitalier ?

C’est l’ensemble des décisions et des actions qu’un hôpital prend une fois qu’une attaque est déjà en cours ou déjà découverte : isoler les systèmes touchés, choisir entre restaurer depuis une sauvegarde ou négocier, maintenir les soins aux patients via des procédures manuelles, et coordonner avec les autorités extérieures. C’est un problème distinct de la prévention, et un hôpital doué pour l’une n’est pas automatiquement doué pour l’autre.

Pourquoi les hôpitaux sont-ils une cible si fréquente des ransomwares ?

Les hôpitaux fonctionnent sur des systèmes partagés et interconnectés qui doivent rester disponibles en permanence, ce qui rend une panne particulièrement perturbatrice pour les soins aux patients et crée une pression pour restaurer les systèmes au plus vite. Beaucoup d’hôpitaux dépendent aussi de logiciels vieux de plusieurs décennies, difficiles à remplacer sans interrompre les soins, ce qui laisse des failles connues sans correctif plus longtemps que dans d’autres secteurs.

Un hôpital doit-il un jour payer la rançon ?

Dans ce cas précis, la recommandation de la DNSC était de ne pas payer, et les hôpitaux ont suivi ce conseil parce que leurs sauvegardes leur ont permis de s’en sortir sans cela. Des agences de sécurité comme la CISA américaine et le FBI recommandent généralement la même chose, pour trois raisons : payer ne garantit pas d’obtenir un outil de déchiffrement fonctionnel, cela finance de futures attaques, et cela crée une incitation à être ciblé de nouveau. La décision dépend surtout de l’existence, ou non, de sauvegardes fiables, ce qui explique pourquoi les tester à l’avance compte davantage que la décision de payer elle-même.

Combien de temps faut-il réellement à un hôpital pour se remettre d’un ransomware ?

Dans le cas roumain, les hôpitaux avaient retrouvé un fonctionnement quasi normal en environ cinq jours, mais ressaisir l’arriéré de dossiers papier dans les systèmes numériques a pris des semaines de plus. La vitesse de rétablissement dépend bien davantage du fait que les sauvegardes soient à jour et restaurables que de la gravité de l’attaque elle-même.

Que peut concrètement faire un hôpital pour s’y préparer ?

La leçon qui revient dans tous les cas de ransomware hospitalier, pas seulement celui-ci, tient en trois points : garder des sauvegardes testées régulièrement et dont la restauration est prouvée, entretenir un plan de secours manuel répété, que le personnel a réellement pratiqué et pas seulement lu, et savoir à l’avance quelle autorité extérieure ou quelle équipe de réponse à incident appeler. Rien de tout cela n’exige de technologie exotique, ce qui explique en partie pourquoi c’est si souvent négligé.

Ce que les équipes IT hospitalières doivent en retenir

Ce qui frappe le plus dans l’issue roumaine, c’est à quel point elle n’a presque rien dû au fait d’avoir stoppé l’attaque. Les hôpitaux ont bel et bien été compromis, la demande de rançon est bel et bien arrivée, et le logiciel partagé est resté compromis. Ce qui a empêché l’incident de tourner à la tragédie s’est décidé des mois plus tôt : les sauvegardes avaient-elles été testées, une autorité nationale disposait-elle d’un plan prêt à coordonner la réponse, et le personnel avait-il réellement répété le fonctionnement d’un hôpital sur le papier. Tout hôpital qui lirait ce cas comme une histoire de ransomware passerait à côté de l’essentiel. C’est une histoire sur les décisions qui se prennent avant l’attaque, parce qu’une fois l’attaque lancée, ce sont les seules qui restent disponibles.