23h12. L'Active Directory tombe. En quelques minutes, la messagerie, l'intranet et la téléphonie IP deviennent inutilisables. La cellule de crise doit être convoquée — mais par quel canal joindre les équipes d'astreinte quand le système d'information est lui-même la victime ? C'est la séquence vécue par plusieurs établissements de santé français depuis 2022, et c'est exactement le scénario que la directive NIS2 demande désormais d'anticiper par écrit. Cet article décrit la mécanique d'une attaque par ransomware hospitalier et passe en revue les trois canaux qui restent pour mobiliser l'astreinte quand l'IT interne s'effondre.
C'est souvent la nuit, ou un week-end. Une compromission qui couvait depuis des jours bascule en quelques minutes. L'Active Directory — l'annuaire qui authentifie chaque session Windows et chaque accès applicatif — est neutralisé. Dans la foulée : Teams, Outlook, l'intranet, la téléphonie IP quand elle partage le même réseau. Tout ce qui sert habituellement à diffuser une alerte interne tombe en même temps.
Le responsable qui doit déclencher la mobilisation — RSSI, DSIH, coordinateur de cellule de crise — se retrouve face à une question qu'aucun support d'astreinte n'avait posée frontalement : comment réunir 150 à 300 personnes d'astreinte en moins de 30 minutes, sans le système d'information ?
La directive (UE) 2022/2555 dite NIS2, transposée en droit français en 2025, impose aux entités « essentielles » et « importantes » — dont les établissements de santé — de documenter leur gestion de crise et de démontrer la résilience de leur chaîne d'alerte. Deux mesures de l'article 21(2) visent directement ce point :
Article 21(2)(c) — « la continuité des activités, telle que la gestion des sauvegardes et la reprise des activités après une catastrophe, et la gestion des crises »
Article 21(2)(j) — « l'utilisation, lorsque cela est approprié, […] de systèmes sécurisés de communication d'urgence au sein de l'entité »
Le point clé : la gestion de crise doit rester robuste précisément dans le scénario où le SI est la cible. Une chaîne d'alerte qui repose entièrement sur Teams, le mail et la téléphonie IP n'est pas conforme à l'esprit du texte — parce qu'elle s'éteint au moment exact où on en a besoin.
D'après les analyses publiques de l'ANSSI et les bulletins du CERT-FR, une attaque par ransomware visant un établissement de santé suit le plus souvent quatre temps :
Quand l'étape 3 démarre, l'attaquant cherche à isoler l'établissement pour le mettre en position de faiblesse. Les canaux internes ne tombent pas par accident : leur neutralisation fait partie du plan.
C'est le cœur du problème. Messagerie, intranet, MS Teams, téléphonie IP : tous reposent sur la même couche — l'annuaire, le réseau interne, les serveurs. Quand cette couche est chiffrée, ils s'éteignent par dessein, simultanément. Le canal de coordination habituel de la DSI disparaît au moment précis où la cellule de crise doit s'activer.
Le responsable de la mobilisation a alors trois canaux réalistes pour joindre l'astreinte.
Indispensable pour le contact direct, mais il sature dès 30 à 40 appels parallèles et mobilise un standardiste à plein temps pendant que la cellule attend. L'arborescence d'appels en cascade est rapidement biaisée par les non-réponses (boîte vocale, occupé, hors couverture).
Pratique pour le grand nombre en situation nominale, mais il dépend de la cellule mobile locale — qui peut elle-même être saturée pendant les premières heures d'un incident majeur visible (afflux de familles, de presse, de secours). La livraison n'est pas garantie en SLA, et aucun accusé de réception n'est remonté en cellule.
Diffusion en broadcast sur un réseau radio dédié, hors-IP, indépendant de l'Active Directory et du SI hospitalier comme des opérateurs mobiles. Tous les pagers d'un même groupe reçoivent l'alerte simultanément, et l'acquittement est remonté à la cellule de crise pour confirmer la mobilisation effective. C'est précisément la fonction décrite à l'article 21(2)(j) : un système sécurisé de communication d'urgence au sein de l'entité, appliqué au cas le plus dur — celui où l'attaque vient par le SI lui-même.
Le tableau ci-dessous résume le comportement des canaux internes 45 minutes après le lancement du chiffrement.
| Canal | Statut à T+45 min | Pourquoi |
|---|---|---|
| Active Directory | ❌ KO | Cible directe du chiffrement |
| Messagerie Teams / Mail | ❌ KO | Dépend de l'AD et des serveurs internes |
| SMS via opérateur | ⚠️ Aléatoire | Dépend de la cellule mobile locale |
| Pager POCSAG | ✅ Actif | Réseau dédié hors-IP, indépendant du SI |
Le pager n'est pas une alternative au plan de reprise. C'est le canal de mobilisation qui le précède : celui qui permet de réunir la cellule de crise pour, ensuite, dérouler le PRA. La vraie question que pose NIS2 n'est pas « quel canal est le meilleur », mais :
Si demain le SI est chiffré, par quel canal documenté mobilisez-vous l'astreinte en moins de 30 minutes ?
Tant que cette question reste sans réponse écrite et testée, l'établissement n'est pas conforme à l'esprit de l'article 21(2)(c) — et son auditeur le notera.
e*Message accompagne depuis 30 ans les entités critiques françaises — CHU, SDIS, sites SEVESO, opérateurs d'énergie, data centers — dans la conception de leur chaîne d'alerte en cellule de crise.
Pour approfondir : notre comparatif des 4 canaux d'alerte en cellule de crise détaille le comportement de chaque canal sous stress, et notre article 5 mythes sur la radiomessagerie déconstruit les idées reçues sur le pager POCSAG.
Vous êtes RSSI ou DSIH dans un établissement de santé ? Nous ouvrons 5 créneaux de 30 minutes en juin pour comprendre comment vous testez votre chaîne d'alerte face à un scénario de chiffrement du SI. Aucune démo, aucun pitch — un échange confidentiel et anonymisé. Contactez-nous ou écrivez à contact@emessage.fr avec la mention « CHAÎNE ».
Oui, par conception. Le pager POCSAG fonctionne en broadcast unidirectionnel sur un réseau radio dédié, sans connexion IP entrante côté terminal. Il n'a pas de système d'exploitation Windows ou Linux exposé à un chiffrement, et ne dépend ni de l'Active Directory ni des serveurs internes de l'établissement. C'est ce qui en fait le canal de dernier recours quand le SI principal est compromis.
Parce qu'elles reposent sur la même infrastructure : annuaire Active Directory, réseau interne, serveurs. Quand le ransomware chiffre cette couche, tous les services qui en dépendent s'éteignent simultanément. C'est précisément pour cela qu'un canal de secours doit être indépendant de cette infrastructure.
NIS2 ne fixe pas de nombre minimal. Le principe est celui de la défense en profondeur : au moins un canal doit rester opérationnel dans chaque scénario d'incident envisagé. Viser trois canaux indépendants dont au moins un hors-IP est une posture défendable face à un auditeur — c'est ce que prévoient déjà la plupart des Plans Blancs hospitaliers.
En mode nominal, oui, avec un délai variable. Mais quand la cellule mobile locale est elle-même sous stress — afflux de familles, de presse et de secours pendant les premières heures d'un incident visible — la livraison se dégrade au moment le plus critique. Le SMS reste un complément utile, pas un canal de secours garanti.
L'article 21(2)(c) demande des tests réguliers de la continuité et de la reprise. Concrètement : un exercice trimestriel minimum, avec des scénarios qui dégradent volontairement un ou plusieurs canaux (« et si le SI était indisponible ? »), une mesure du délai de mobilisation effective (T+0 → T+30 min), et un acquittement remonté à la cellule. Ces exercices doivent être documentés : c'est cette documentation qui sera demandée en contrôle.
Article rédigé par l'équipe e*Message France. Publié le 2 juin 2026.
