Rançongiciels en 2026 : ce que l'attaque contre l'hôpital AZ Monica apprend aux PME belges

Le 13 janvier 2026 au petit matin, les équipes informatiques de l'hôpital AZ Monica, à Anvers et Deurne, détectent une anomalie sur leurs systèmes. En quelques minutes, la cellule de crise interne prend une décision radicale : couper elle-même l'ensemble de l'infrastructure des deux campus, avant même de savoir précisément ce qui se passe. Il faudra cinq semaines pour que tout revienne à la normale.

C'est l'un des incidents de rançongiciel les mieux documentés de l'année en Belgique. Un hôpital n'a évidemment ni les enjeux ni les moyens d'une entreprise de vingt personnes, mais la mécanique de l'attaque et les points de bascule sont les mêmes. Chaque chiffre cité ci-dessous porte sa source ; là où les sources se contredisent, je le dis ; ce qui circule sans source vérifiable n'y figure pas.

Chronologie : ce qui s'est passé, jour par jour

Mardi 13 janvier 2026, vers 6h30. L'alerte est déclenchée simultanément sur les deux campus. Computable.be situe le déclenchement à 6h32. La cellule de crise décide d'éteindre tous les serveurs pour empêcher la propagation (VRT NWS).

Dans la journée du 13. Dossier patient électronique, imagerie médicale et site web deviennent inaccessibles. Les interventions programmées sont annulées : la presse belge parle d'au moins septante opérations, The Record évoque environ quatre-vingts reports. Sur le campus d'Anvers, toute la chirurgie est suspendue ; à Deurne, quelques actes sont maintenus à l'appréciation des médecins. Environ septante patients rentrent chez eux et sept sont transférés vers d'autres hôpitaux — des patients en soins critiques, transférés avec l'appui de la Croix-Rouge selon The Record. Le service mobile d'urgence (MUG) et l'équipe d'intervention paramédicale (PIT) sont mis hors service et repris par d'autres hôpitaux via le plan catastrophe provincial (VRT NWS, ITdaily).

Le 13 et le 14 janvier. Le parquet d'Anvers ouvre une information judiciaire et confirme qu'il s'agit bien d'une attaque par rançongiciel. La Federal Computer Crime Unit de la police judiciaire fédérale se déplace sur place, et une équipe CERT est mobilisée en appui. Le parquet précise un point important : à ce stade, aucune demande de rançon n'avait été formulée (VRT NWS, ITdaily).

Mercredi 14 janvier. L'hôpital rouvre partiellement : environ 30 % de l'activité de soins peut reprendre le premier jour, puis la capacité se stabilise autour de 50 %. À Deurne, les consultations, l'hôpital de jour et l'oncologie fonctionnent de nouveau. Les serveurs, eux, restent éteints : le responsable technique Wout Struyfs explique que l'équipe ne redémarrera pas tant qu'elle n'est pas certaine à 100 % que la porte d'entrée utilisée par les attaquants est refermée (VRT NWS).

Du 15 janvier à la mi-février. Reprise très progressive. Une partie des ambulances est réorientée vers AZ Monica dès le 15 janvier, parce que la pression sur les hôpitaux voisins devient trop forte (VRT NWS). Pendant des semaines, une partie des dossiers est tenue au papier et au crayon.

Mardi 17 février 2026. Plus d'un mois après l'attaque, la quasi-totalité des systèmes informatiques est rétablie : médication, urgences, prescriptions électroniques, imagerie, stérilisation. L'hôpital indique qu'« à sa connaissance, aucune donnée patient n'a été volée ». Certaines restrictions subsistent (wifi visiteurs, accès internet de certains services). Le parquet d'Anvers poursuit son enquête (VRT NWS).

Ce qui est établi, et ce qui ne l'est pas

Il faut être clair sur les limites de ce qu'on sait, parce que c'est précisément là que le récit se déforme en circulant.

Établi : la nature de l'attaque (rançongiciel, confirmé par le parquet), la décision d'arrêt volontaire, l'ampleur des perturbations, la durée de la remise en service, l'absence d'indication de vol de données selon l'hôpital, l'ouverture d'une enquête judiciaire.

Non établi publiquement : l'identité du groupe. Aucun groupe n'a revendiqué l'attaque à ma connaissance, aucune donnée d'AZ Monica n'a été publiée sur un site de fuite connu, et le vecteur d'entrée initial n'a pas été rendu public.

Contradiction à signaler : le parquet indiquait le 14 janvier qu'aucune rançon n'avait été demandée, tandis que la synthèse mensuelle de Comparitech affirme qu'AZ Monica « a refusé de payer la rançon ». Les deux affirmations ne peuvent pas être vraies au même moment. Je retiens la version du parquet, source primaire, en notant que la situation a pu évoluer après le 14 janvier sans communication publique.

Pourquoi couper soi-même ses serveurs était la bonne décision

Vu de l'extérieur, éteindre tout un hôpital avant d'avoir compris ce qui se passe paraît disproportionné. C'est pourtant, dans la plupart des cas documentés, la décision qui limite le mieux les dégâts.

Un rançongiciel moderne ne chiffre pas tout d'un coup : il se propage d'un poste vers un serveur de fichiers, puis vers un contrôleur de domaine, puis vers les sauvegardes. Chaque minute pendant laquelle l'infrastructure reste allumée est une minute de propagation — et souvent d'exfiltration — supplémentaire. Couper le réseau arrête les deux. Le coût est immédiat et visible ; le bénéfice est invisible, puisqu'il consiste en dégâts qui n'ont pas eu lieu.

Pour une PME, la leçon transposable n'est pas « éteignez tout ». C'est : savoir à l'avance qui a l'autorité de couper, et comment. Trois questions à se poser aujourd'hui, à froid :

• Qui, nommément, peut décider d'isoler le réseau à 6h30 du matin un mardi, sans attendre de validation hiérarchique ?
• Cette personne sait-elle physiquement comment le faire (débrancher quoi, couper quel accès distant, désactiver quel VPN) ?
• Comment continue-t-on à travailler pendant ce temps — et comment prévient-on les clients, les fournisseurs, le personnel, si la messagerie est justement hors service ?

Si vous n'avez pas de réponse écrite à ces trois questions, c'est le chantier le moins cher et le plus rentable de votre année.

L'angle mort révélé par l'incident : le prestataire partagé

C'est la partie la moins commentée de cette affaire, et probablement la plus importante pour une PME.

Le 14 janvier, l'expert en sécurité Geert Baudewijns (société Secutec) révèle que le prestataire utilisé par AZ Monica pour l'enregistrement des patients sert aussi trois autres hôpitaux flamands. Une faille permettait de récupérer les mots de passe des plateformes de ces autres établissements, ouvrant potentiellement l'accès à environ 71 000 dossiers patients — noms, adresses, numéros de registre national. Les failles ont été corrigées, et rien n'indique qu'elles aient été exploitées par des criminels (VRT NWS).

Trois établissements sans faute de sécurité connue étaient donc exposés par un fournisseur commun. C'est exactement le raisonnement qui sous-tend les obligations de sécurisation de la chaîne d'approvisionnement introduites par NIS2. Retenez la symétrie : vous êtes exposé par vos fournisseurs, et vous êtes le fournisseur exposant de quelqu'un d'autre.

Anatomie d'une attaque par rançongiciel, étape par étape

Comprendre l'enchaînement permet de savoir où placer les défenses. Voici le schéma générique, décrit au niveau qui sert à se protéger — pas à reproduire.

1. L'accès initial. Trois portes principales : un identifiant valide obtenu par hameçonnage ou racheté à un « courtier en accès » ; une vulnérabilité non corrigée sur un service exposé à Internet (VPN, passerelle, serveur de fichiers) ; ou un fournisseur compromis. L'ENISA classe l'hameçonnage comme premier vecteur d'intrusion en Europe (60 %), devant l'exploitation de vulnérabilités (21,3 %) — ENISA Threat Landscape 2025.

2. La reconnaissance discrète. L'attaquant ne chiffre pas tout de suite : il repère les serveurs, les partages, les comptes d'administration, les sauvegardes. Cette phase dure de quelques heures à plusieurs semaines. C'est la fenêtre où une détection est encore possible et peu coûteuse.

3. L'escalade et le déplacement latéral. Il cherche un compte à privilèges élevés pour atteindre l'annuaire central, ce qui lui donne la capacité de déployer partout d'un coup.

4. La neutralisation des sauvegardes. Étape décisive : si les sauvegardes sont joignables depuis le réseau avec un compte d'administration, elles seront supprimées ou chiffrées. C'est ce qui transforme un incident en catastrophe.

5. L'exfiltration. Les données sont copiées vers l'extérieur avant tout chiffrement — le levier de la double extorsion.

6. Le chiffrement. Souvent déclenché la nuit ou un week-end. C'est le seul moment où la victime voit quelque chose, et c'est déjà la fin de l'histoire.

Conclusion pratique : tout ce qui déplace la détection de l'étape 6 vers les étapes 2 à 4 vaut de l'or.

Double et triple extorsion : le modèle économique

Le chiffrement n'est plus l'unique levier :

• Double extorsion : les données sont exfiltrées avant d'être chiffrées, puis leur publication est menacée. Une bonne sauvegarde ne règle plus le problème, puisqu'elle ne fait rien contre la divulgation.
• Triple extorsion : les attaquants contactent directement clients, patients, partenaires ou régulateurs pour augmenter la pression.

S'y ajoute une industrialisation : le rançongiciel-comme-service, où un groupe fournit l'outillage et des « affiliés » mènent les attaques, et les courtiers en accès qui revendent des accès déjà obtenus. D'où la résilience de l'écosystème face aux opérations de police : après le démantèlement de LockBit, le CCB observe une fragmentation, avec Qilin, Akira et Clop parmi les groupes les plus actifs contre des organisations belges (CCB, chiffres 2025).

Les chiffres belges et européens, sans gonflage

En Belgique, pour 2025 (CCB, repris par Telecompaper) :

• 635 notifications d'incidents, soit près de +70 % par rapport à 2024 ;
• dont 556 incidents cyber, en hausse de 58 % sur un an ;
• 144 compromissions de comptes, un chiffre qui a doublé ;
• 144 incidents DDoS, stables ;
• 105 incidents de rançongiciel, contre 109 en 2024 ;
• le CCB est intervenu directement dans 103 dossiers.

Ce cinquième point contredit le récit habituel. Le nombre de rançongiciels notifiés en Belgique n'a pas augmenté en 2025 : il est resté stable. La hausse globale de 70 % vient surtout des nouvelles obligations de signalement (NIS2, DORA), de meilleures capacités de détection et de l'explosion des compromissions de comptes. Dire « les rançongiciels explosent en Belgique » serait faux au vu des données du CCB : ce qui a changé, c'est l'impact par incident, pas la fréquence des signalements.

Au niveau européen (ENISA Threat Landscape 2025, 4 875 incidents analysés entre le 1er juillet 2024 et le 30 juin 2025) :

• le rançongiciel représente 81,1 % des incidents de cybercriminalité visant des organisations de l'UE, devant les violations de données (15,2 %) ;
• l'hameçonnage est le premier vecteur d'intrusion (60 %) ;
• l'administration publique est le secteur le plus visé (38,2 %) ;
• 53,7 % des incidents analysés concernent des entités entrant dans le champ de NIS2.

Pour janvier 2026, Comparitech recense 50 attaques par rançongiciel confirmées dans le monde, dont 6 dans la santé. Ce décompte ne capte que les cas rendus publics : c'est une tendance, pas une mesure exhaustive.

Les signaux d'alerte avant le chiffrement

Ce qu'une PME peut réalistement remarquer, sans centre opérationnel de sécurité, si quelqu'un regarde :

• une connexion réussie depuis un pays où vous n'avez ni client ni collaborateur, ou à une heure invraisemblable ;
• un nouveau compte administrateur que personne ne revendique ;
• la désactivation soudaine de l'antivirus sur un poste ;
• des sauvegardes qui échouent silencieusement depuis quelques jours, ou dont le volume chute ;
• un pic de trafic sortant nocturne vers un service de stockage inconnu ;
• l'apparition d'outils d'administration à distance que vous n'avez pas déployés ;
• des journaux d'événements vidés ou interrompus.

Aucun de ces signaux n'est une preuve. Mais deux d'entre eux en même temps méritent un appel immédiat à votre prestataire informatique.

Contre-mesures, classées par rapport coût/efficacité

Voici l'ordre dans lequel je les traiterais pour une PME belge de dix à cent personnes.

Niveau 1 — effet élevé, coût faible. À faire ce trimestre.

1. Authentification multifacteur partout où c'est possible : messagerie, VPN, accès distant, outils d'administration, comptes cloud. C'est la mesure qui coupe la majorité des accès initiaux par identifiants volés, et elle est souvent incluse dans les licences que vous payez déjà.
2. Une sauvegarde hors ligne ou immuable, non joignable avec les identifiants d'administration du réseau. Le test : « si mon compte administrateur est compromis ce soir, cette sauvegarde survit-elle ? »
3. Un test de restauration réel, chronométré, au moins une fois par an. Une sauvegarde jamais restaurée est une hypothèse, pas une protection.
4. Les décisions d'urgence sur une page imprimée : qui coupe, qui prévient qui, quels numéros — imprimée, parce que le PDF sera chiffré lui aussi.
5. Supprimer les comptes dormants et les accès des anciens collaborateurs et prestataires.

Niveau 2 — effet élevé, coût modéré. À planifier sur l'année.

1. Correctifs prioritaires sur tout ce qui est exposé à Internet : VPN, pare-feu, passerelles, serveurs web. Un délai cible écrit (par exemple 15 jours pour les vulnérabilités critiques) vaut mieux qu'une bonne intention.
2. Segmentation minimale du réseau : séparer la bureautique des serveurs et des équipements industriels ou médicaux. Cela ne stoppe pas une attaque, mais transforme une paralysie totale en incident circonscrit.
3. Une détection sur les postes (EDR) avec quelqu'un qui regarde les alertes. L'outil sans le regard humain ne sert pas à grand-chose.
4. Journalisation centralisée, rétention d'au moins six mois : sans journaux, l'enquête est impossible et vous ne saurez jamais si des données sont sorties.
5. Sensibilisation ciblée des fonctions exposées (comptabilité, direction, informatique), avec des cas réels plutôt que des diaporamas génériques.

Niveau 3 — pour ceux qui ont déjà le reste.

1. Un exercice de crise annuel d'une demi-journée, sur table, avec la direction.
2. Un contrat de réponse à incident pré-négocié, ou au minimum les coordonnées d'une équipe identifiée à l'avance : chercher un intervenant le jour J coûte cher et fait perdre des heures.
3. Une auto-évaluation CyFun (CyberFundamentals) niveau Basic : le référentiel du CCB est gratuit, structuré, et couvre l'essentiel de ce qui précède (CCB).

Ce que NIS2 exige spécifiquement sur ce risque

Si vous êtes une entité essentielle ou importante au sens de la loi belge du 26 avril 2024, plusieurs obligations visent directement ce scénario. L'article 21(2) de la directive NIS2 impose notamment : une politique d'analyse des risques ; la gestion des incidents ; la continuité des activités, incluant explicitement la gestion des sauvegardes et la reprise après sinistre ; la sécurité de la chaîne d'approvisionnement ; l'évaluation de l'efficacité des mesures ; l'hygiène informatique de base et la formation ; l'authentification à plusieurs facteurs.

Ce ne sont pas des recommandations : sur le papier, une entité couverte qui subit un rançongiciel sans sauvegarde isolée ni plan de continuité est en défaut sur au moins deux points explicites du texte. Et si vous n'êtes pas dans le champ de la loi, cette liste reste le meilleur ordre du jour gratuit pour une réunion de direction.

Les premières heures d'un incident : quoi faire, dans quel ordre

À froid, écrivez ceci sur une page et affichez-la.

Heure 0 à 1 — contenir.

1. Isoler : débrancher du réseau les machines suspectes, couper les accès distants et le VPN. Éviter d'éteindre brutalement une machine chiffrée si on peut l'isoler : la mémoire vive contient parfois des éléments utiles à l'enquête.
2. Ne rien effacer, ne rien « nettoyer » : les traces sont des preuves.
3. Déclencher le canal de communication de secours (téléphones personnels, groupe hors messagerie d'entreprise).

Heure 1 à 4 — qualifier et alerter. 4. Appeler votre prestataire informatique et, si vous en avez une, votre assurance cyber — beaucoup de polices imposent de passer par leur intervenant. 5. Vérifier l'état des sauvegardes sans les reconnecter au réseau compromis. 6. Déposer plainte auprès de la police, et signaler l'incident au CCB via Safeonweb@Work. Le CCB peut apporter un appui même hors de toute obligation légale.

Dans les 24 à 72 heures — notifier si vous êtes concerné. 7. Entité essentielle ou importante : l'article 23(4) de la directive NIS2 impose une alerte précoce dans les 24 heures, une notification dans les 72 heures, un rapport intermédiaire sur demande, et un rapport final dans le mois. 8. En cas de violation de données à caractère personnel, l'obligation RGPD de notifier l'Autorité de protection des données dans les 72 heures s'applique en parallèle. Les deux régimes coexistent.

Dans les jours qui suivent. 9. Ne pas redémarrer tant que le point d'entrée n'est pas identifié et refermé — la logique invoquée par l'équipe technique d'AZ Monica. 10. Réinitialiser tous les secrets : mots de passe d'administration, clés d'API, jetons d'accès, comptes de service. 11. Communiquer sobrement, en distinguant ce qui est établi de ce qui est en cours d'investigation.

Sur le paiement : ni le CCB ni les autorités judiciaires ne le recommandent. Payer ne garantit ni la restitution des données ni leur suppression chez l'attaquant, et finance l'écosystème. Cette décision, si elle se pose, se prend avec un conseil juridique, pas dans l'urgence de la première nuit.

Ce que je retiens

Trois choses, en tant que praticien en reconversion qui regarde ces incidents avec les outils d'un technicien réseau plutôt que ceux d'un consultant.

D'abord, la vitesse de décision compte plus que la sophistication de l'outillage. AZ Monica a réagi en quelques minutes et a limité les dégâts à cinq semaines de reconstruction, sans vol de données constaté à ce jour. Ce n'est pas un outil qui a produit ce résultat, c'est une décision prise vite par des gens qui savaient qu'ils avaient le droit de la prendre.

Ensuite, la continuité d'activité ne s'improvise pas. Elle tient à des questions ennuyeuses posées à froid : où sont les sauvegardes, qui décide, comment se parle-t-on si la messagerie tombe. Ces questions coûtent une réunion.

Enfin, votre périmètre de sécurité s'arrête bien après vos murs. L'histoire des 71 000 dossiers accessibles chez trois autres hôpitaux via un prestataire commun le montre mieux que n'importe quelle statistique.

Si un point de cet article vous semble inexact ou daté, écrivez-le-moi : ces analyses sont faites pour être corrigées.

---

Sources

• 30 procent van zorgverlening kan doorgaan in AZ Monica na cyberaanval | VRT NWS
• Parketmagistraat over AZ Monica | VRT NWS
• AZ Monica Antwerpen heropent, halve capaciteit | VRT NWS
• Ook bij 3 andere Vlaamse ziekenhuizen lag toegang tot patiëntengegevens open | VRT NWS
• Sommige ziekenwagens rijden opnieuw naar AZ Monica | VRT NWS
• IT-systemen AZ Monica werken opnieuw zoals voor cyberaanval | VRT NWS
• AZ Monica in Antwerpen doelwit van cyberaanval met ransomware | ITdaily
• Cyberaanval legt AZ Monica volledig plat | Computable.be
• Cyberattack forces Belgian hospital to transfer critical care patients | The Record
• Ransomware roundup: January 2026 | Comparitech
• More attacks, more reporting: Belgium's cyber reality in 2025 | CCB
• Belgian Cybersecurity Centre reports jump in national incidents in 2025 | Telecompaper
• ENISA Threat Landscape 2025
• Directive (UE) 2022/2555 (NIS2) | EUR-Lex
• La loi NIS2 | CCB Safeonweb@Work