Ce que le plan de communication doit réellement résoudre

Le plan doit permettre de partager une situation fiable alors que les informations, les outils et les responsabilités sont encore instables. Il ne s’agit pas d’un communiqué de presse préécrit, mais d’un mécanisme de décision qui fonctionne pendant une panne, une compromission Microsoft 365, un ransomware, une fuite de données ou l’indisponibilité d’un fournisseur critique.

Incident technique, incident cyber et violation de données

Le plan doit survivre à la panne

Si le tenant Microsoft 365, le réseau, le téléphone IP et le gestionnaire de mots de passe dépendent du même environnement, l’équipe peut perdre simultanément ses messages, ses contacts et ses procédures. Une copie protégée hors ligne, un annuaire de crise limité, des téléphones vérifiés et un canal alternatif deviennent alors des composants opérationnels, pas des annexes administratives.

La page GVISION dédiée à la protection et à la réponse en cybersécurité présente les contrôles techniques qui réduisent le risque. Le présent guide traite le volet humain : garder une parole cohérente lorsque l’organisation ne dispose encore que de faits partiels.

Organiser la communication pendant la première heure

La première heure sert à installer une source de vérité, protéger les échanges et annoncer une prochaine échéance ; elle ne sert pas à expliquer définitivement l’incident. Le chronomètre ci-dessous est un modèle interne à adapter à la gravité, aux horaires et à la structure de l’organisation. Ce ne sont pas des délais légaux.

0 à 15 minutes : ouvrir le journal et joindre les décideurs

Notez l’heure de détection, le déclarant, les services touchés, les actions déjà réalisées et les incertitudes. Désignez provisoirement un responsable d’incident et un responsable communication. Activez un canal de secours si l’intégrité de la messagerie ou de Teams est douteuse. Évitez de transférer des captures sensibles dans des groupes improvisés.

15 à 30 minutes : qualifier l’impact communicable

Décrivez les services indisponibles, les populations concernées et les comportements demandés. Par exemple : ne pas redémarrer, ne pas se reconnecter au VPN, ne pas utiliser une application ou conserver un appareil allumé. Faites valider ces consignes par le responsable technique ; une instruction erronée peut détruire des preuves ou étendre l’incident.

30 à 60 minutes : publier le premier message utile

Le message initial indique ce qui est observé, l’impact concret, l’action attendue, le canal de support et l’heure de la prochaine mise à jour. Il ne doit pas attribuer l’incident, minimiser le risque ni annoncer une restauration certaine. Si aucune information nouvelle n’est disponible à l’échéance promise, publiez tout de même un point de situation.

Attribuer les rôles et les droits de décision

Une communication crédible exige un propriétaire par message et un validateur clairement désigné. Une grande cellule de crise sans droits de décision crée des retards ; une seule personne qui cumule technique, juridique et communication crée des angles morts.

Responsable d’incident

Il tient la chronologie, arbitre les priorités et confirme la version opérationnelle des faits. Il ne doit pas nécessairement être le technicien le plus expérimenté : son rôle est de coordonner, protéger la capacité de décision et escalader.

Responsable technique

Il confirme l’impact, les mesures de confinement, les dépendances et les scénarios de restauration. Il fournit des faits, pas des formulations publiques. Il indique explicitement ce qui reste inconnu et ce qui ne peut pas être diffusé sans nuire à l’enquête.

Communication, direction, juridique et DPO

La communication adapte le niveau de langage et maintient la cohérence entre canaux. La direction décide des engagements ayant un impact commercial ou institutionnel. Le juridique vérifie les obligations contractuelles et le risque de divulgation. Le DPO évalue la dimension « données personnelles » et conseille le responsable du traitement ; il ne remplace pas la décision de celui-ci.

Suppléants et seuils

Chaque rôle critique doit avoir un suppléant et un moyen de contact indépendant. Le plan peut prévoir trois niveaux : incident local géré par l’IT, incident majeur nécessitant direction et métiers, crise exigeant communication externe, conseil juridique et autorités. Les seuils se basent sur l’impact, la durée probable, la sensibilité des données et l’étendue, pas sur l’intensité émotionnelle.

Prévoir des canaux qui restent disponibles et sûrs

Le canal de crise principal ne doit pas dépendre exclusivement du système potentiellement compromis. Une boîte e-mail « urgence » dans le même tenant n’est pas un véritable canal de secours si l’identité, le DNS ou Microsoft 365 sont touchés.

Trois espaces, trois finalités

• Canal technique : preuves, indicateurs, actions de confinement et journal détaillé.
• Canal de décision : impact métier, arbitrages, notifications, ressources et validation des messages.
• Canal d’information : messages approuvés destinés aux employés, clients ou partenaires.

Cette séparation limite les fuites, évite qu’une hypothèse technique soit reprise comme un fait et permet à chaque groupe de recevoir le bon niveau de détail. Conservez néanmoins une chronologie commune avec l’auteur, l’heure, la décision et la prochaine action.

Écrire des messages utiles sans spéculer

Chaque message doit répondre à cinq points : situation connue, impact, action attendue, solution temporaire et prochaine mise à jour. Le lecteur ne doit pas décoder du jargon ni deviner s’il peut continuer à travailler.

Dire ce qui est confirmé

Préférez « l’accès au portail est indisponible depuis 09 h 20 » à « nous subissons probablement un ransomware sophistiqué ». Si la confidentialité des données n’est pas encore évaluée, écrivez-le. Distinguez heure de détection, début estimé et heure de connaissance réglementaire.

Donner une consigne observable

Une consigne comme « restez vigilants » est trop vague. Indiquez l’action : ne pas ouvrir un lien, utiliser un numéro de secours, travailler hors ligne, conserver l’ordinateur allumé ou suspendre une saisie. Précisez qui est concerné et quand la consigne sera réévaluée.

Éviter les promesses absolues

Ne dites pas « aucune donnée n’a été volée » tant que l’analyse ne permet pas de l’établir. Ne promettez pas un retour à la normale à midi si l’équipe ne maîtrise pas toutes les dépendances. Un créneau de prochaine communication est généralement plus fiable qu’une heure de résolution.

Distinguer communication de crise, RGPD et NIS2

Les messages opérationnels ne remplacent jamais une notification réglementaire, et toutes les cyberattaques ne déclenchent pas les mêmes obligations. L’organisation doit qualifier séparément la disponibilité du service, la violation éventuelle de données personnelles, le caractère significatif d’un incident NIS2 et les clauses contractuelles applicables.

Violation de données personnelles

L’Autorité de protection des données rappelle qu’une violation doit être notifiée à l’autorité compétente sans retard injustifié et, si possible, dans les 72 heures après en avoir pris connaissance, sauf si elle n’est pas susceptible d’engendrer un risque pour les droits et libertés. La décision, les éléments connus et l’analyse doivent être documentés. Une communication aux personnes concernées répond à un seuil et à un contenu distincts ; elle ne doit pas être improvisée par l’équipe IT.

Incident significatif NIS2

Pour les entités belges concernées, le CCB décrit une notification par étapes : alerte précoce au plus tard dans les 24 heures suivant la prise de connaissance de l’incident significatif, notification complète dans les 72 heures — avec une règle particulière pour les prestataires de services de confiance — puis rapport final au plus tard un mois après la notification. Ces délais ne transforment pas chaque panne en incident NIS2 : le périmètre de l’entité et le caractère significatif doivent être vérifiés.

Plusieurs horloges peuvent démarrer

Un même événement peut impliquer l’APD, le CCB, un régulateur sectoriel, la police, un assureur et des clients liés par contrat. Les horloges, seuils et contenus diffèrent. Tenez une feuille de décision avec l’autorité compétente, la base, l’heure de connaissance, le responsable, l’échéance et le statut. Demandez un avis juridique lorsque le périmètre est incertain.

The plan de reprise et de continuité informatique décrit comment prioriser les restaurations. GVISION recommande de relier cette séquence technique au plan de communication : chaque reprise de service doit déclencher un message vérifié, sans annoncer qu’un système est sûr avant les contrôles nécessaires.

Construire une matrice des destinataires

Le même incident exige plusieurs messages, car employés, direction, clients et autorités n’ont ni les mêmes décisions à prendre ni le même besoin de détail.

Trois modèles de message prêts à adapter

Des modèles prévalidés accélèrent la première communication, mais les champs doivent être remplis uniquement avec des faits confirmés. Conservez-les hors ligne et indiquez qui peut les approuver.

1. Alerte interne initiale

Depuis [heure], [service] est [indisponible/perturbé]. L’équipe analyse la situation. Jusqu’à nouvel ordre, [consigne précise]. N’utilisez pas [canal ou application] et signalez [symptôme] via [canal de secours]. Prochaine mise à jour à [heure], même si l’analyse se poursuit.

2. Information client ou partenaire

Nous rencontrons depuis [heure] un incident affectant [service/périmètre]. Nos équipes ont activé les mesures de traitement prévues. À ce stade, l’impact confirmé est [fait]. Vous pouvez [solution temporaire ou action]. Nous publierons un nouveau point à [heure] via [canal].

3. Message de rétablissement

Le service [nom] est rétabli depuis [heure] et fait l’objet d’une surveillance renforcée. [Action utilisateur éventuelle]. L’analyse des causes et impacts se poursuit ; nous communiquerons les informations complémentaires pertinentes par [canal]. Si vous constatez [symptôme], contactez [point de contact].

Ces formulations évitent d’annoncer une origine, un vol de données ou une résolution définitive avant validation. Ajoutez les obligations contractuelles propres au secteur et faites relire les modèles par les fonctions concernées avant l’incident.

Adapter le plan aux réalités des organisations belges

La gravité communicable dépend du service rendu, pas seulement du nombre de machines touchées. Une même panne technique peut produire des conséquences très différentes selon le secteur.

École ou ASBL

Si l’e-mail est compromis, la priorité est de fournir au personnel un canal fiable, d’éviter que des messages frauduleux soient suivis et d’expliquer aux familles comment reconnaître la communication officielle. Le plan doit prévoir qui peut contacter les parents, dans quelles langues et via quelle plateforme indépendante.

Cabinet médical ou établissement de santé

L’indisponibilité d’un agenda ou d’un dossier change immédiatement l’accueil des patients. Le premier message interne doit décrire le mode dégradé, la consignation temporaire et le canal pour les urgences. Les informations publiques restent minimales pour protéger les données et la sécurité, tandis que le DPO évalue une éventuelle violation.

Entreprise multi-sites

Chaque site peut observer un impact différent. Utilisez des relais locaux qui confirment réception et exécution des consignes. Un tableau central sépare « non vérifié », « confirmé » et « résolu ». Les commerciaux reçoivent une formulation approuvée afin de répondre sans créer plusieurs versions de l’incident.

Administration ou organisation publique

Le plan doit intégrer les responsables institutionnels, les obligations de transparence, les procédures d’achat d’urgence et les canaux accessibles au public. Il doit aussi permettre de publier dans les langues nécessaires sans divergence de fond. Une version source unique et des traductions contrôlées réduisent ce risque.

Préparer et tester le dispositif en dix étapes

Un plan n’est opérationnel que si les contacts, canaux, modèles et droits de décision sont testés dans les conditions d’une vraie panne.

1. Définissez les scénarios. Ransomware, compromission d’identité, indisponibilité cloud, fuite de données et panne fournisseur.
2. Classez les niveaux de gravité. Reliez chaque niveau à un déclencheur de communication et à un décideur.
3. Nommez titulaires et suppléants. Direction, incident manager, IT, DPO, juridique, RH, communication et métiers.
4. Créez l’annuaire de crise. Coordonnées professionnelles et de secours, conservées de manière proportionnée et protégée.
5. Séparez les canaux. Technique, décision et information, avec une option indépendante de l’environnement principal.
6. Préparez les modèles. Alerte, point de situation, consigne, client, partenaire, autorité et résolution.
7. Cartographiez les obligations. NIS2, RGPD, secteur, police, assurance et contrats, avec responsables et procédures.
8. Reliez communication et reprise. Chaque étape technique doit avoir un critère de message et un validateur.
9. Simulez une indisponibilité réelle. Coupez volontairement l’accès aux outils habituels pendant l’exercice.
10. Corrigez et datez. Notez les écarts, mettez à jour les contacts et fixez le prochain test.

Les erreurs qui aggravent une crise

Les problèmes les plus fréquents viennent moins du style rédactionnel que de dépendances non testées et de décisions non attribuées.

• Tout conserver dans Microsoft 365 : procédures, mots de passe et contacts deviennent simultanément indisponibles.
• Créer un grand groupe informel : les hypothèses circulent, les décisions ne sont plus traçables et les accès persistent.
• Attendre une certitude complète : les utilisateurs inventent leurs propres explications et actions.
• Annoncer une attaque trop tôt : une panne peut être mal qualifiée et la communication devient difficile à corriger.
• Promettre un délai : la restauration dépend parfois d’un fournisseur, de preuves ou de contrôles de sécurité.
• Copier le même texte partout : un employé, un client et une autorité n’ont pas le même besoin.
• Oublier les langues : une traduction improvisée peut modifier une consigne ou une appréciation du risque.
• Fermer la communication au rétablissement : il faut confirmer le suivi, les actions utilisateur et le retour d’expérience.