Plan de gestion des incidents – comment les entreprises peuvent élaborer un plan pratique pour les cyberincidents
Partager
Par Mallbutiken · Données vérifiées le 1er octobre 2026 · Environ 9 minutes de lecture
Un plan de gestion des incidents décrit la manière dont l'organisation agit dès les premiers signes d'un incident cyber jusqu'à la stabilisation de l'activité, la sécurisation des preuves, la réalisation des signalements nécessaires et la mise en œuvre des leçons apprises. Le plan doit être suffisamment concis pour être utilisé sous stress, mais assez détaillé pour éliminer toute hésitation concernant les rôles, les voies de contact et les décisions.
Que doit couvrir un plan de gestion des incidents ?
Le plan doit s'appliquer aux événements susceptibles d'affecter la confidentialité, l'intégrité, la disponibilité ou l'authenticité des systèmes et des informations de l'entreprise. Parmi les exemples, citons les ransomwares, le piratage de comptes, les fuites de données, les attaques par déni de service, les fournisseurs compromis, les erreurs de configuration, le sabotage et les interruptions de service majeures.
Définissez un point d'entrée pour les alertes, même en cas d'incertitude. L'employé ne doit pas avoir à décider si un événement constitue juridiquement un « incident » avant de pouvoir le signaler en interne.
Rôles et mandats décisionnels – décidez avant l'incident
Les incidents s'aggravent souvent parce que tout le monde attend le même responsable. Définissez donc les rôles à l'avance. Une petite organisation peut combiner plusieurs rôles, mais les responsabilités doivent rester claires.
| Rôle | Responsabilité |
|---|---|
| Responsable d'incident | Coordonne la situation, les priorités, les décisions et le rythme des réunions. |
| Responsable technique | Analyse, confinement, journaux, remédiation et rétablissement. |
| Propriétaire métier | Évalue l'impact sur l'activité, les services critiques et les temps d'arrêt acceptables. |
| Juridique/protection des données | Évalue les obligations de signalement et d'information ainsi que les contrats. |
| Communication | Coordonne l'information interne et externe. |
| Direction | Prend les décisions sortant du mandat du groupe de gestion des incidents. |
Documentez également les remplaçants, les numéros d'astreinte et la procédure de rassemblement du groupe de gestion des incidents si les systèmes de communication habituels sont inopérants.
Flux d'incident en huit étapes
- Détection et enregistrement. Créer l'ID de l'incident, noter l'heure, le rapporteur et l'observation initiale.
- Triage. Évaluer rapidement quels systèmes, données, utilisateurs et services pourraient être concernés.
- Classification et escalade. Définir le niveau de gravité préliminaire et activer les rôles appropriés.
- Confinement. Limiter les dégâts sans détruire inutilement de preuves ni compliquer le rétablissement.
- Analyse. Déterminer la cause probable, le calendrier, le vecteur d'intrusion et l'étendue.
- Remédiation. Supprimer la cause, combler la vulnérabilité et vérifier que la menace n'est plus présente.
- Rétablissement. Rétablir les services de manière contrôlée et renforcer la surveillance.
- Post-analyse. Documenter la cause racine, les décisions, les enseignements et les mesures d'amélioration.
Créer un modèle de classification simple
La classification doit soutenir la prise de décision, pas devenir un système de notation académique. Évaluez par exemple :
- si une activité critique est interrompue,
- combien d'utilisateurs/clients sont affectés,
- si des données personnelles ou d'autres informations protégées ont pu être divulguées,
- si l'attaquant dispose d'un accès privilégié,
- si l'incident se propage,
- si des fournisseurs ou d'autres organisations sont affectés,
- si un signalement réglementaire est susceptible d'être déclenché.
Déterminez quel niveau active automatiquement la direction, le service juridique, la protection des données ou un partenaire externe en gestion des incidents.
Conserver les journaux et les preuves sans bloquer la réponse
Sous la pression du temps, il est facile de supprimer ou d'écraser des informations importantes. Le plan doit donc indiquer qui sécurise les journaux pertinents, les instantanés, les calendriers, les e-mails, les événements de compte et autres justificatifs techniques. Documentez qui a fait quoi et quand.
Le besoin de preuves doit être mis en balance avec l'exigence de limiter les dommages en cours. En cas d'incident grave, une expertise forensique externe peut devoir être sollicitée rapidement.
Communication et signalement externe
Créez des listes de contacts distinctes pour les autorités, le fournisseur de réponse aux incidents, l'assurance cyber, les fournisseurs IT critiques, la direction et la communication. Préparez des modèles pour un premier rapport de situation interne et pour les points de décision.
Pour les entreprises soumises à la loi sur la cybersécurité, des règles particulières s'appliquent au signalement des incidents significatifs. La loi impose une première notification au plus tard 24 heures après que l'opérateur a eu connaissance de l'incident, suivie d'une déclaration d'incident selon les délais applicables au type d'activité. Les détails sont traités séparément dans le guide sur le flux 24/72 heures NIS2.
Le rétablissement, c'est plus que relancer les systèmes
Définissez les critères permettant la réouverture d'un service. Vérifiez que la vulnérabilité est corrigée, que les comptes privilégiés sont sécurisés, que les données restaurées sont fiables et que la surveillance est renforcée pendant une période donnée.
Liez l'ordre de rétablissement à l'analyse d'impact sur l'activité (BIA) et au plan de continuité de l'organisation. Lisez le guide BIA étape par étape et le contenu d'un plan de continuité.
Post-analyse : rendez l'apprentissage obligatoire
Après l'incident, l'organisation doit documenter la cause racine, ce qui a fonctionné, ce qui a retardé le travail et quelles mesures de contrôle doivent être modifiées. Chaque action doit avoir un responsable et une échéance. Assurez-vous ensuite que l'action est effectivement réalisée.
Testez le plan avant d'en avoir besoin
Un plan d'incident qui n'a jamais été testé contient presque toujours des numéros de téléphone erronés, des mandats flous ou des hypothèses sur des systèmes qui n'existent plus. Organisez au moins des exercices de simulation (table-top) récurrents où la direction, l'informatique, le métier et les fonctions de support pertinentes traitent un scénario réaliste.
Variez les scénarios : ransomware, fournisseur SaaS compromis, compte administrateur divulgué ou arrêt de travail prolongé. Mettez à jour le plan après chaque exercice.
Liste de contrôle pour le plan
- Une voie d'alerte interne unique et claire
- Rôles, remplaçants et mandats
- Coordonnées disponibles même en dehors des heures de bureau
- Niveaux de gravité et critères d'escalade
- Étapes de confinement, d'analyse et de rétablissement
- Procédures pour les journaux et les preuves
- Point de décision pour le NIS2 et autres signalements aux autorités
- Point de décision pour le RGPD/incident de données personnelles
- Responsabilité de la communication interne et externe
- Lien avec le BIA et le plan de continuité
- Post-analyse avec mesures d'amélioration responsables
- Intervalles d'exercice et de mise à jour

Besoin de documenter le flux d'incident ?
Le pack de modèles NIS2 2026 de Mallbutiken contient des modèles intégrés pour, entre autres, la gestion des incidents, le reporting, la gestion des risques, la continuité et la sécurité des fournisseurs. Prix en boutique : 199 SEK.
Voir le pack de modèles NIS2Conseils connexes
Lisez également les mesures de sécurité NIS2, le signalement d'incident 24/72 heures et le plan de continuité.
Sources et lectures complémentaires
- Parlement suédois : loi sur la cybersécurité (2025:1506)
- FRA/NCSC : Centre national de cybersécurité
Ce guide fournit des informations générales. Le plan d'incident doit être adapté aux systèmes, aux activités, aux contrats et aux exigences de déclaration applicables à l'organisation.