Six communes flamandes sur dix n’ont aucun plan pour ce qui doit se passer en cas de cyberattaque, selon l’examen mené par Audit Vlaanderen auprès de 89 administrations locales entre 2023 et 2025. Dans la minorité qui dispose bel et bien d’un plan de continuité, la plupart n’abordent jamais la question de savoir qui informe les citoyens, le personnel et les médias, de quoi, et par quel canal, le jour où les systèmes dont les citoyens dépendent tombent en panne.
Ce qu’est un plan de communication en cas d’incident cyber
Un plan de communication en cas d’incident cyber est l’ensemble de décisions arrêtées à l’avance qui détermine qui informe qui, dans quel ordre et par quel canal, dès qu’une cyberattaque ou une panne majeure de systèmes est confirmée. Il se place à côté du plan de continuité technique, pas à l’intérieur de celui-ci. Le plan de continuité restaure les serveurs, les réseaux et les données ; le plan de communication gère ce que les citoyens, le personnel, les fournisseurs et les journalistes entendent pendant que cette restauration est en cours, ce qui explique pourquoi certains spécialistes en relations publiques le présentent comme un sous-ensemble spécifique de la communication de crise. L’examen mené par Audit Vlaanderen entre 2023 et 2025 auprès de 89 communes et intercommunales flamandes a révélé que les auditeurs se sont limités à vérifier l’existence d’un plan de continuité, sans jamais vérifier s’il incluait un quelconque protocole de communication (Audit Vlaanderen, 2025). Cette distinction compte. Une organisation peut cocher la case de la continuité des activités tout en laissant chaque porte-parole, attaché de presse et agent de call center improviser le jour où l’e-mail, le site web et le système téléphonique tombent en panne en même temps.
Les chiffres de l’audit vont bien au-delà du constat de six sur dix
Le rapport d’Audit Vlaanderen regroupe les audits de sécurité informatique menés localement en Flandre entre 2023 et 2025. La participation était volontaire : 77 des 300 communes flamandes et 12 intercommunales y ont pris part, ce qui signifie que l’échantillon penche vers les organisations disposées à se faire contrôler plutôt que vers un échantillon représentatif de l’ensemble des administrations locales. Même au sein de ce groupe auto-sélectionné et plus sensibilisé à la sécurité, les auditeurs ont recensé 1 899 vulnérabilités numériques, dont 353 jugées à haut risque, et n’ont trouvé aucune entité auditée totalement exempte de failles (Audit Vlaanderen, 2025).
| Groupe audité | Aucun plan de continuité | Mots de passe faibles en moyenne |
|---|---|---|
| Communes (77) | 59 % | 30 % de tous les mots de passe testés |
| Intercommunales (12) | 67 % | 18 % des mots de passe des comptes admin |
Les chiffres sur les mots de passe sont le signe le plus clair que le déficit de continuité n’est pas une simple lacune de planification isolée. Sur les 89 entités auditées, en moyenne 30 % des mots de passe testés étaient suffisamment faibles pour être déchiffrés rapidement, et des mots de passe faibles ont été relevés sur 18 % des comptes d’administrateur système, les identifiants offrant l’accès le plus large à un réseau (Audit Vlaanderen, 2025). La VVSG, l’association représentant les villes et communes flamandes, reconnaît que de nombreuses administrations locales ne font que rattraper leur retard, poussées par la directive NIS2 de l’Union européenne plutôt que par une initiative interne (VVSG, 2025). Les auditeurs se sont contentés de vérifier l’existence d’un plan de continuité, pas sa qualité, si bien que même les 41 % de communes en règle sur papier peuvent encore manquer d’un plan testé et réellement opérationnel. Pour les équipes de communication, cela signifie que le risque technique et le risque réputationnel surviennent le même jour, souvent sans scénario convenu pour l’un ou l’autre.
Pourquoi l’attaque contre Anvers reste la référence de ce qui est en jeu
Pour les administrations publiques flamandes, le point de référence reste la cyberattaque contre la ville d’Anvers en décembre 2022, qui a perturbé les services pendant des mois et non des jours. Les citoyens ne pouvaient plus demander de documents, le personnel a perdu l’accès aux systèmes internes, et la ville a dû communiquer via des canaux improvisés tandis que ses canaux habituels restaient hors service. Les premières heures après une brèche déterminent dans quelle mesure cette perturbation se transforme en un échec de communication qui vient s’ajouter à l’échec technique.
Anvers et le récent épisode PHP2Shell illustrent le même constat. Un canal que les citoyens s’attendent à utiliser, un site web, une adresse e-mail, une ligne téléphonique, peut disparaître pour des raisons qui n’ont rien à voir avec la qualité des communiqués publics d’une organisation.
Pourquoi les failles PHP2Shell ont-elles mis des sites publics hors ligne ?
En octobre 2026, cela s’est reproduit, cette fois sans intrusion confirmée. Deux failles critiques dans PHP, le langage de programmation derrière WordPress et une grande partie du web, ont été rendues publiques sous le nom de PHP2Shell (CVE-2026-109618 et CVE-2026-109619). Toutes deux permettent à un attaquant d’exécuter des commandes sur un serveur web sans mot de passe ni compte, et AWS a observé des attaquants les exploiter quatre jours avant leur divulgation, selon The Register. L’une des deux failles a été découverte par des chercheurs travaillant avec OpenAI, signe que l’IA accélère la recherche de faiblesses des deux côtés.
Les gouvernements n’ont pas attendu. Les autorités en Belgique, aux Pays-Bas, en Allemagne, en France, en Finlande et en République tchèque ont mis des sites hors ligne pour les corriger, et la National Security Agency américaine a conseillé de déconnecter tout système impossible à mettre à jour immédiatement, d’après Al Jazeera. Au Royaume-Uni, 32 services publics sont devenus indisponibles. La plupart de ces coupures étaient préventives, mais pour les citoyens le résultat ressemblait exactement à une attaque : le site dont ils avaient besoin avait disparu.
C’est le scénario que la plupart des plans de communication oublient, une coupure volontaire et planifiée. Elle exige tout de même un message d’attente sur une page de secours ou un réseau social, un court message au personnel sur les canaux encore disponibles, et un seul responsable qui décide quand annoncer le retour du site. Tout commence par une question simple à votre partenaire web : la mise à jour de sécurité PHP d’octobre est-elle installée ? Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, et les sites sous PHP 8.1 ou antérieur doivent être mis à niveau.
Qu’exige NIS2 une fois un incident confirmé
La directive NIS2, officiellement la directive (UE) 2022/2555, renforce les obligations de notification pour les entités essentielles et importantes, une catégorie qui inclut désormais explicitement les administrations publiques locales partout dans l’Union européenne. Lauren Cuyvers, du cabinet d’avocats Crowell & Moring, observe que l’intelligence artificielle redessine ce tableau dans les deux sens : elle aide les attaquants à trouver et exploiter des vulnérabilités plus vite, tout en offrant aux défenseurs de meilleurs outils de détection, ce qui rend les clauses contractuelles signées avec les fournisseurs de logiciels plus importantes que jamais (Crowell & Moring, 2025).
- Une alerte précoce dans les 24 heures suivant la prise de connaissance de l’incident.
- Une notification plus complète de l’incident dans les 72 heures, incluant une évaluation initiale de sa gravité et de son impact.
- Un rapport final dans un délai d’un mois, couvrant la cause profonde et les mesures correctives.
Respecter ces délais légaux est une tâche technique et juridique. Cela ne dit rien de ce que l’organisation communique au public, au personnel ou aux clients durant cette même période. Un plan de communication répond à la question que NIS2 ne pose pas : qui s’adresse à qui en dehors du régulateur, et pourquoi il est essentiel de disposer de ce plan par écrit bien avant qu’un incident ne déclenche le chronomètre.
Pourquoi ce n’est pas seulement un problème communal
L’audit portait sur les administrations locales, mais le problème structurel ne se limite pas au secteur public. Les entreprises privées du Benelux séparent la planification de la continuité et celle de la communication de la même manière, souvent parce que les deux relèvent de départements différents : l’IT détient le plan de continuité, la communication revient au marketing ou à une agence externe, et les deux documents sont rarement testés ensemble. Un fabricant qui perd son système de commandes, un prestataire de soins de santé qui perd l’accès aux dossiers patients, ou une entreprise de logistique qui perd ses données de suivi se trouve confronté à la même première question qu’une commune : qui dit quoi aux clients, au personnel et aux médias, dès maintenant, pendant que l’équipe technique travaille.
NIS2 élargit le cercle des organisations soumises à une obligation légale de notification bien au-delà des infrastructures critiques : aucune entreprise du Benelux ne peut donc classer ce risque comme le problème de conformité d’un autre. L’audit flamand ne fait que chiffrer un déficit que la plupart des organisations, publiques ou privées, partagent déjà.
Cinq éléments indispensables à tout plan de communication en cas d’incident cyber
Wouter Decruy, de l’auditeur informatique Acen, qui a contribué aux conclusions de l’audit, structure la planification de la continuité autour de questions très concrètes : qui est informé, dans quel ordre les systèmes sont redémarrés, et si l’organisation a répété tout cela à travers un exercice d’incendie numérique. Les mêmes questions valent pour la communication. Cinq éléments transforment un plan de continuité en un plan qui protège aussi la relation de l’organisation avec les personnes qui dépendent d’elle.
- Des communiqués d’attente préapprouvés. Une ou deux déclarations courtes, déjà rédigées et validées, qui peuvent être diffusées dès la première heure sans attendre une relecture juridique alors que les faits ne sont pas encore confirmés.
- Des listes de contacts hors ligne. Numéros de téléphone et adresses du personnel, des fournisseurs, de la presse locale et des clients clés, conservés en dehors du réseau qui pourrait être lui-même en panne.
- Des canaux de secours. Un moyen d’atteindre les gens lorsque le site web et l’e-mail sont tous deux hors service : SMS, arbre d’appels téléphoniques, comptes de réseaux sociaux hébergés ailleurs, avis physiques affichés à l’entrée d’une maison communale ou d’un bureau.
- Des rôles de porte-parole définis. Un porte-parole désigné et un remplaçant, briefés à l’avance sur ce qu’ils peuvent et ne peuvent pas confirmer avant que les équipes techniques n’aient vérifié les faits.
- Une répétition intégrée à l’exercice de continuité. Les rôles de communication testés dans le même exercice que celui utilisé pour le rétablissement technique, au moins une fois par an, et non comme un exercice séparé ajouté plus tard.
Questions fréquentes sur les plans de communication en cas d’incident cyber
Qui doit être informé en premier lorsque les systèmes tombent en panne ?
Le porte-parole et la petite équipe qui gère l’incident doivent être informés en premier, avant toute déclaration publique. Le personnel interne a besoin, dès la première heure, d’instructions pratiques, par exemple quels systèmes éviter et où signaler les nouveaux problèmes. Les citoyens, les clients et les médias viennent ensuite, une fois que l’organisation peut confirmer des faits de base plutôt que de les deviner publiquement.
Que doit contenir un communiqué d’attente ?
Un communiqué d’attente confirme qu’une situation fait l’objet d’une enquête, indique ce qui est entrepris pour y remédier, et promet une mise à jour à une heure précise. Il ne doit jamais se risquer à deviner la cause, l’ampleur ou la responsabilité avant que l’équipe technique n’ait confirmé ces faits. Une réassurance vague, sans échéance claire pour la prochaine mise à jour, érode la confiance plus vite que le silence.
Une cyberattaque doit-elle être confirmée avant la diffusion d’un communiqué d’attente ?
Non. Un communiqué d’attente peut reconnaître une perturbation technique ou un incident de sécurité en cours d’investigation sans en confirmer la cause. Attendre une confirmation complète avant de dire quoi que ce soit est précisément ce qui transforme une courte panne en un problème réputationnel plus long, car le public comble le silence avec ses propres explications. La première déclaration doit seulement être exacte sur ce qui est connu à ce moment-là, pas exhaustive.
À quelle fréquence le plan doit-il être testé ?
Au minimum une fois par an, en l’intégrant à l’exercice de continuité technique plutôt que comme un exercice séparé que personne ne planifie jamais. Wouter Decruy, d’Acen, appelle cela un exercice d’incendie numérique : un test chronométré de qui est informé, dans quel ordre les systèmes redémarrent, et ce que disent les porte-parole pendant ce temps. Les communes soumises aux obligations NIS2 devraient considérer cette répétition comme une tâche de conformité, et non comme un supplément facultatif.
Que se passe-t-il si l’e-mail et le site web sont tous deux hors service ?
C’est exactement le scénario pour lequel un plan de canaux de secours existe. Des alternatives convenues à l’avance, arbres d’appels téléphoniques, alertes SMS, comptes de réseaux sociaux hébergés hors du réseau touché, et avis physiques, permettent à l’information de continuer à circuler lorsque les canaux principaux font défaut. Les organisations sans plan de secours retombent généralement dans le silence, et le public interprète ce silence soit comme de l’incompétence, soit comme une dissimulation.
Ce qui transforme un plan écrit en un plan qui fonctionne vraiment
Un plan de communication en cas d’incident cyber ne fonctionne que s’il a été testé sous la même pression que le rétablissement technique auquel il est associé. L’examen d’Audit Vlaanderen a révélé que 59 % des communes flamandes et 67 % des intercommunales n’avaient aucun plan de continuité, et les auditeurs se sont limités à vérifier l’existence du plan, pas sa qualité, si bien qu’un plan écrit resté dans un tiroir compte de la même manière que l’absence de plan dans cet audit (Audit Vlaanderen, 2025). Dans notre propre expérience de conseil auprès d’organisations belges en matière de gestion de crise, les plans qui tiennent sous une pression réelle partagent un trait commun : les rôles de communication y sont testés dans le même exercice que le rétablissement technique, et non ajoutés après coup comme un exercice séparé dont personne ne se souvient. Les délais de notification imposés par NIS2 ajoutent une raison légale de bien faire les choses, mais c’est généralement le coût réputationnel du silence pendant une panne, bien plus que l’amende, qui finit par convaincre un conseil d’administration d’approuver enfin le budget.
- Vérifier séparément l’existence d’un plan de communication, sans présumer qu’il est inclus dans le plan de continuité.
- Rédiger et préapprouver des communiqués d’attente avant qu’un incident ne survienne, pas pendant.
- Constituer une liste de contacts hors ligne et prévoir au moins un canal de secours qui ne dépend ni de l’e-mail ni du site web.
- Désigner un porte-parole et un remplaçant, et briefer les deux à l’avance sur ce qu’ils peuvent confirmer.
- Tester le plan de communication dans le même exercice que celui utilisé pour le rétablissement technique, au moins une fois par an.
Les organisations qui considèrent cela comme de la préparation plutôt que de la paperasse, et qui prennent l’habitude de s’entraîner avant qu’un incident ne déclenche le chronomètre, sont celles qui restent maîtres du récit une fois les systèmes de nouveau en ligne.
'/%3E%3C/svg%3E){kind=small}
