En février 2021, une attaque par ransomware paralyse le système d'information du Centre Hospitalier de Dax. Les équipes se retrouvent à coordonner la réponse à la crise par SMS et téléphone fixe, les outils numériques étant soit chiffrés, soit inaccessibles. Le retour à un fonctionnement normal prendra plusieurs semaines. Cet épisode n'est pas un cas isolé — il illustre une faille structurelle que beaucoup d'organisations, y compris des OIV, n'ont pas encore corrigée.
La messagerie de crise est le dernier outil que vous devriez perdre lors d'un incident cyber. C'est pourtant souvent le premier à tomber.
Le paradoxe de l'outil de crise compromis
Lorsqu'une attaque frappe votre système d'information, le réflexe naturel est de déclencher la cellule de crise et d'ouvrir un canal de communication sécurisé. Mais que se passe-t-il si votre suite collaborative principale est :
-
hébergée sur la même infrastructure que le périmètre attaqué ?
-
inaccessible parce que l'Active Directory est compromis ?
-
potentiellement infiltrée par l'attaquant qui lit vos échanges en temps réel ?
-
soumise à une juridiction étrangère qui impose sa propre intervention ?
Dans ces cas, votre Plan de Continuité d'Activité (PCA) repose sur un outil qui fait partie du problème. La coordination de la réponse se fait en clair, de manière désorganisée, et potentiellement sous les yeux de l'attaquant.
Ce que la LPM exige — et ce qu'elle implique pour votre PCA
L'article R.1332-41-15 du Code de la défense impose aux OIV de mettre en place des mesures de sécurité garantissant la continuité de fonctionnement de leurs SIIV face aux incidents cyber. Concrètement, cela signifie que votre PCA doit intégrer un canal de communication de crise qui répond lui-même aux exigences de sécurité de la LPM — et qui fonctionne indépendamment de votre SI principal.
Scénario 1 : Ransomware sur l'AD central
L'authentification est compromise. Tous les outils SSO tombent simultanément. Votre messagerie collaborative devient inaccessible.
Scénario 2 : Attaque supply chain via l'éditeur
L'attaquant a compromis votre fournisseur de collaboration. Il lit vos échanges de crise pendant que vous discutez de la réponse à l'incident.
Scénario 3 : Coupure réseau intentionnelle
L'attaquant coupe votre accès internet pour ralentir la coordination. Vos outils cloud SaaS deviennent inutilisables en moins de 5 minutes.
Scénario 4 : Réquisition légale étrangère
Votre fournisseur, soumis au Cloud Act, est contraint de divulguer vos communications de crise à une autorité étrangère. En pleine gestion d'incident.
Les 4 propriétés non négociables d'un outil de gestion de crise pour OIV
Un canal de communication de crise conforme aux exigences d'un OIV doit présenter quatre caractéristiques architecturales — pas des fonctionnalités, des propriétés de conception.
Isolation du SI principal
Le canal de crise ne doit pas dépendre des mêmes systèmes d'authentification, d'hébergement ou de réseau que le périmètre potentiellement attaqué. L'architecture doit permettre une activation en mode dégradé, hors connexion si nécessaire.
Chiffrement de bout en bout avec clés maîtrisées par l'organisation.
En situation de crise, les échanges contiennent les informations les plus sensibles — nature de l'attaque, périmètre compromis, décisions tactiques. Leur confidentialité est critique. Aucun tiers ne doit pouvoir y accéder.
Disponibilité garantie contractuellement (SLA 99,9% minimum), hébergée en France.
Un outil de gestion de crise indisponible pendant une crise est une contradiction. La localisation française garantit l'absence de risque d'extraterritorialité au pire moment.
Traçabilité complète des échanges pour la gestion post-crise.
Après l'incident, l'ANSSI peut exiger la reconstitution de la chronologie des décisions. Les journaux d'audit horodatés et immuables sont une obligation de fait pour tout OIV ayant vécu un incident majeur.
A lire aussi : OIV : pourquoi votre messagerie collaborative peut mettre en danger votre conformité LPM ?
Intégrer le canal de crise dans votre Plan de Reprise d'Activité
La plupart des PRA et PCA d'OIV définissent des procédures de bascule pour les systèmes métier critiques — salle de contrôle, SCADA, systèmes de supervision. Mais combien intègrent explicitement un canal de communication de crise testé et qualifié dans leur dispositif ?
L'intégration d'Hexagone dans un PCA d'OIV suit une logique simple : le canal collaboratif souverain est déclaré comme système de communication de crise de niveau 1 dans le plan, avec des procédures d'activation documentées, des accès pré-provisionnés pour la cellule de crise, et des exercices réguliers intégrés aux exercices de crise existants (qui sont eux-mêmes exigés par la LPM).
L'exercice de crise : la seule façon de vérifier que ça fonctionne
La LPM impose aux OIV de réaliser des exercices de gestion de crise cyber. C'est lors de ces exercices que la question du canal de communication devient concrète : qui active quoi, depuis quel terminal, sur quel réseau ? Si votre équipe ne sait pas répondre à ces trois questions en moins de 30 secondes, votre dispositif de crise a une faille.
Un exercice bien construit sur Hexagone permet de valider trois points critiques : l'accès hors SI principal, la confidentialité des échanges, et la traçabilité post-exercice — les mêmes critères qu'un auditeur PASSI viendra vérifier.
Hexagone est aussi une solution de gestion de crise dédiée, conçue pour s'activer indépendamment de votre SI principal et répondre aux exigences d'homologation LPM. Découvrez comment l'intégrer à votre PCA existant.
2 juin 2026
Lecture en 3 min
