Une PME de 60 personnes dans le secteur médical subit un ransomware un lundi matin. Le responsable IT ne sait pas qui doit décider du paiement ou non de la rançon. Le dirigeant ne sait pas à qui il doit notifier l’incident. La responsable RH ne sait pas si elle doit prévenir les clients dont les données sont peut-être compromises. Personne n’a les coordonnées de l’assureur cyber sous la main. L’entreprise perd quatre jours à organiser sa propre réponse avant de commencer à remédier.

Ce scénario n’est pas exceptionnel. C’est ce qui arrive quand un incident survient sans plan de réponse documenté.

Ce guide est consacré à la construction du plan — le document que vous rédigez avant tout incident, qui définit qui fait quoi, dans quel ordre, avec quels contacts. Il ne couvre pas la conduite minute par minute d’un incident réel : notre guide de réponse au phishing et notre fiche réflexe cyberattaque traitent les premières heures d’un incident actif. Ce guide couvre le travail préparatoire — la fondation sur laquelle tout le reste repose.

Pourquoi un plan de réponse à incident

La gestion d’un incident cyber sans préparation préalable ressemble à une évacuation incendie sans exercice ni plan : tout le monde court, personne ne sait où sortir, et les premières décisions sont prises par la panique plutôt que par la méthode.

Le coût de l’improvisation

Le rapport IBM Cost of Data Breach 2024 établit que les organisations disposant d’un plan de réponse à incident réduisent le coût moyen d’une violation de données de 58 % par rapport à celles qui n’en ont pas. Le délai moyen d’identification et de confinement est de 258 jours sans plan, contre 162 jours avec un plan structuré. Pour un attaquant actif sur votre réseau, chaque jour supplémentaire est une opportunité d’exfiltrer plus de données ou d’étendre sa compromission.

Les obligations réglementaires

La directive NIS2 (article 21.2.b), transposée en droit français en 2025, impose aux entités concernées de mettre en place des politiques de gestion des incidents — vérifiées lors des audits. L’absence d’un plan structuré constitue un écart formellement sanctionnable. Consultez notre page conformité NIS2 pour vérifier si votre entreprise est concernée.

ISO 27001 (Annexe A.5.24 à A.5.26) encadre la planification à la gestion des incidents : définition des rôles, procédures de détection et d’escalade, analyse post-incident. Le plan est un livrable attendu lors de tout audit de certification.

Le RGPD (article 32) impose des mesures organisationnelles pour protéger les données personnelles. La CNIL considère qu’un plan de réponse fait partie de ces mesures. En cas de contrôle après une violation de données, son absence est documentée dans le rapport d’inspection.

L’exigence des assureurs cyber

Les assureurs cyber ont durci leurs conditions de souscription depuis 2022. Certains contrats conditionnent la couverture à l’existence d’un plan documenté, au même titre que le MFA et les sauvegardes testées. Sans plan, l’assureur peut refuser l’indemnisation en arguant que l’entreprise n’a pas pris les mesures organisationnelles pour limiter l’impact. Notre guide sur l’assurance cyber détaille les exigences actuelles.

La structure du plan

Un plan de réponse à incident n’est pas un document de théorie — c’est un document opérationnel que quelqu’un doit pouvoir utiliser sous pression, parfois en état de stress, parfois à 2h du matin. Sa structure doit être claire, sa navigation rapide, et son contenu directement actionnable.

Voici l’architecture recommandée :

1. Objet et périmètre

Définissez ce que le plan couvre et ce qu’il ne couvre pas. Périmètre géographique (sites), périmètre technique (systèmes d’information, applications métier, infrastructure cloud, équipements industriels si applicable), périmètre humain (collaborateurs, prestataires, sous-traitants). Mentionnez la version du document, la date de dernière révision et les noms des approbateurs.

2. Cellule de crise

La composition de la cellule, les rôles de chacun, les coordonnées téléphoniques directes (hors messagerie professionnelle), et l’ordre d’activation. Ce chapitre doit tenir sur une seule page imprimable.

3. Niveaux de gravité et critères d’escalade

Une grille de classification objective des incidents, avec les seuils d’activation de la cellule de crise et les procédures d’escalade pour chaque niveau.

4. Procédure de détection et signalement interne : comment un collaborateur signale un incident suspect, le canal de signalement, la personne destinataire, l’information minimale à fournir. Plus le chemin est court, plus le délai de détection est réduit.

5. Fiches réflexes par type d’incident : une fiche par scénario courant (phishing/BEC, ransomware, fuite de données, DDoS), chacune avec les actions immédiates dans l’ordre, les contacts à activer et les délais légaux. C’est la partie du plan la plus utilisée en conditions réelles.

6. Obligations de notification : tableau récapitulatif des délais légaux — CNIL (72h, RGPD article 33), CERT-FR (24h puis 72h, NIS2), assureur (délai contractuel, conditionné au dépôt de plainte sous 72h LOPMI), police ou gendarmerie (72h LOPMI), notification aux personnes concernées si risque élevé (RGPD article 34).

7. Communication interne et externe : modèles de messages selon les destinataires (équipes, direction, clients, partenaires, médias). Nommez explicitement la personne autorisée à s’exprimer publiquement — en général le dirigeant ou son délégué.

8. Procédures de remédiation et restauration : étapes de nettoyage et de reconstruction, critères de validation avant remise en production, points de contrôle intermédiaires.

9. Retour d’expérience (post-mortem) : modèle de rapport post-incident. Voir section ci-dessous.

10. Annexes : carnet d’adresses complet (contacts internes, prestataires, CERT-FR, CNIL, assureur, avocat), inventaire des outils disponibles, check-lists imprimables.

Constituer la cellule de crise

La cellule de crise est le groupe de personnes qui gère l’incident. Son efficacité dépend moins de sa taille que de la clarté des rôles et de la préparation préalable.

Les rôles à couvrir

Le pilote est le décideur. En PME, c’est généralement le dirigeant ou un cadre de direction désigné par délégation. Il valide les décisions engageantes : payer ou ne pas payer une rançon, communiquer publiquement, activer l’assurance, notifier la CNIL. Il ne gère pas le technique — il tranche quand il faut trancher.

Le référent technique est responsable du confinement, de l’analyse et de la remédiation. En PME, c’est le responsable IT interne ou, dans la majorité des cas, le prestataire informatique. Son rôle dans le plan : être joignable 24h/24 sur un numéro d’urgence, et connaître les accès administrateurs à tous les systèmes critiques. Ces accès ne doivent pas dépendre d’une seule personne.

Le référent juridique et RGPD évalue les obligations de notification et prépare les communications aux autorités et aux personnes concernées. En PME, c’est le DPO (interne ou externe), un avocat spécialisé, ou la personne qui gère les contrats et la conformité. S’il n’y a personne, désignez la personne la plus à même de traiter ce sujet et prévoyez de lui faire lire ce guide.

Le référent communication gère les messages internes et externes. En PME, c’est souvent la direction, la responsable RH, ou le responsable marketing selon la structure. Son rôle : rédiger les communications pendant l’incident, coordonner avec les relations presse si l’incident devient public, et s’assurer qu’une seule voix parle au nom de l’entreprise vers l’extérieur.

Le prestataire de réponse à incident (externe) est activé quand l’incident dépasse la capacité technique interne. L’ANSSI publie une liste de prestataires qualifiés PRIS sur cyber.gouv.fr. Identifiez-le en amont et obtenez un devis-cadre : un ransomware actif n’est pas le moment de négocier les tarifs.

Pour les petites structures

Dans une PME de moins de 30 personnes, une même personne peut cumuler deux ou trois rôles. Ce qui compte : documenter qui remplit chaque rôle, même si c’est la même personne pour quatre d’entre eux. Prévoir une suppléance pour les absences : que se passe-t-il si le référent technique est en vacances quand l’incident survient ?

L’arbre d’appel

Intégrez au plan un arbre d’appel : qui appelle qui, dans quel ordre, par quel canal. L’arbre d’appel doit être imprimé et accessible sans passer par les systèmes informatiques potentiellement compromis. Une feuille A4 plastifiée dans le tiroir du dirigeant et dans celui du responsable IT suffit.

Les niveaux de gravité

Un système de classification évite deux erreurs opposées : l’escalade excessive sur des incidents mineurs qui mobilisent inutilement toute la cellule de crise, et la sous-réaction sur des incidents graves traités comme des tickets de support ordinaires.

Voici un modèle à trois niveaux, adapté aux PME :

Niveau 1 — Incident mineur

Critères : tentative d’attaque non aboutie, alerte antivirus isolée sur un poste, email de phishing signalé et non cliqué, tentatives de connexion bloquées par le MFA, défaut de configuration mineur sans exploitation avérée.

Impact : nul ou limité à un poste. Aucune donnée compromise. Aucune interruption de service.

Procédure : prise en charge par le référent technique seul. Documentation dans le journal d’incidents. Pas d’activation de la cellule de crise. Vérification sous 24 heures que l’incident est bien contenu.

Niveau 2 — Incident significatif

Critères : compromission d’un compte utilisateur (identifiants volés, connexion suspecte confirmée), malware actif sur un ou plusieurs postes, fuite de données limitée (quelques dizaines d’enregistrements), interruption d’un service non critique, accès non autorisé à un système interne.

Impact : un ou plusieurs postes ou comptes compromis. Possibilité de données personnelles exposées. Interruption limitée.

Procédure : activation du pilote et du référent technique. Évaluation de la nécessité d’informer le référent juridique selon la présence de données personnelles. Décision d’activation de l’assureur et dépôt de plainte selon l’évaluation. Documentation complète. Pour un incident de phishing à ce niveau : voir le guide de réponse au phishing.

Niveau 3 — Crise majeure

Critères : ransomware actif avec chiffrement de fichiers, compromission de l’Active Directory ou de l’infrastructure centrale, exfiltration confirmée de données sensibles à grande échelle, indisponibilité prolongée des systèmes critiques (ERP, messagerie, production), fraude au virement aboutie.

Impact : systèmes critiques inaccessibles. Données confidentielles ou personnelles compromises. Impact financier direct. Risque réputationnel.

Procédure : activation complète de la cellule de crise. Isolation immédiate des systèmes concernés. Activation du prestataire externe si nécessaire. Notifications légales déclenchées (CNIL, CERT-FR si NIS2, assureur, dépôt de plainte). Communication interne et externe sous validation du pilote.

Les fiches réflexes

Une fiche réflexe est une check-list actionnable pour un scénario spécifique. Elle doit pouvoir être utilisée par quelqu’un sous pression, sans expertise technique approfondie. Voici le modèle pour les quatre scénarios les plus fréquents.

Chaque fiche suit le même squelette : premiers gestes (check-list ordonnée), contacts à activer, délais légaux applicables.

Fiche 1 — Phishing et compromission de compte (BEC)

Premiers gestes : déconnecter le poste du réseau sans l’éteindre, changer le mot de passe compromis depuis un autre appareil, révoquer toutes les sessions actives (Entra ID ou Google Workspace), vérifier et supprimer les règles de transfert d’email suspectes, conserver l’email original sans le supprimer. Si virement frauduleux : appeler la banque en premier, avant tout autre appel.

Contacts : référent technique → pilote (si niveau 2 ou 3). Délais : CNIL sous 72h si données personnelles exposées, dépôt de plainte sous 72h (LOPMI).

Notre guide de réponse au phishing détaille les actions minute par minute sur Microsoft 365 et Google Workspace.

Fiche 2 — Ransomware

Premiers gestes : isoler toutes les machines du réseau immédiatement sans attendre d’identifier le périmètre exact, ne pas éteindre les machines (la RAM contient des données forensiques), ne pas redémarrer, photographier les messages de rançon, identifier le patient zéro et vérifier l’état des sauvegardes — ont-elles aussi été chiffrées ? Consulter NoMoreRansom pour les déchiffreurs gratuits disponibles.

Contacts : référent technique → pilote → prestataire externe → 3218 (Mon Aide Cyber). Délais : CNIL sous 72h, ANSSI sous 24h si entité NIS2, dépôt de plainte sous 72h (LOPMI).

Ne pas payer la rançon. La position de l’ANSSI est formelle : le paiement ne garantit pas la récupération des données.

Fiche 3 — Fuite de données

Premiers gestes : identifier la source de la fuite (compte compromis, accès externe, API exposée), couper l’accès sans effacer les preuves, évaluer la nature et le volume des données exposées, contacter le référent juridique pour évaluer l’obligation de notification CNIL.

Contacts : référent technique + référent juridique → pilote. Délais : CNIL sous 72h (RGPD article 33) si données personnelles exposées. Risque élevé (données bancaires, de santé) : notification CNIL + information individuelle des personnes concernées (RGPD article 34). Entités NIS2 : alerte CERT-FR sous 24h. Dépôt de plainte sous 72h (LOPMI).

Fiche 4 — DDoS

Premiers gestes : vérifier que l’indisponibilité est bien liée à un volume anormal de trafic, contacter l’hébergeur ou le fournisseur CDN pour activer la protection anti-DDoS. Surveiller simultanément les journaux d’intrusion : un DDoS sert parfois d’écran de fumée pour masquer une intrusion parallèle. Si activité suspecte détectée : passer en niveau 3.

Contacts : référent technique → hébergeur → pilote si durée > 2h ou activité suspecte parallèle. Délais : dépôt de plainte recommandé (article 323-2 Code pénal). Signalement sur cybermalveillance.gouv.fr.

Tester le plan : l’exercice de crise

Un plan non testé est un plan non fiable. Les exercices de simulation de crise — appelés tabletop exercises dans le vocabulaire du NIST SP 800-61 — permettent de vérifier que le plan fonctionne en conditions proches du réel, sans mettre les systèmes en danger.

Le format tabletop

Un exercice tabletop est une réunion de deux heures autour d’un scénario fictif. Un facilitateur présente la situation initiale et fait évoluer le scénario selon les décisions de l’équipe. Pas de systèmes en jeu : juste des questions, des décisions, et des prises de conscience.

Participants : les membres de la cellule de crise, et si possible un ou deux collaborateurs non spécialistes. Choisissez un scénario pertinent pour votre secteur :

Ransomware : « 7h45. Votre IT vous appelle : les serveurs de fichiers sont inaccessibles et un message de rançon s’affiche sur plusieurs postes. Que faites-vous maintenant ? »
Phishing / BEC : « Un collaborateur de la comptabilité a cliqué sur un faux email bancaire et a peut-être saisi ses identifiants. Quelle est votre première action ? »
Fuite de données : « Un inconnu vous écrit qu’il a téléchargé votre base clients et la mettra en vente dans 48h. Il joint un extrait. Comment réagissez-vous ? »

Le facilitateur injecte des événements au fil de l’exercice — « les sauvegardes ont aussi été chiffrées », « la presse locale vous contacte » — pour tester la capacité d’adaptation et révéler les décisions non documentées dans le plan.

Le debriefing

Trente minutes après l’exercice : ce qui a bien fonctionné, ce qui a mal fonctionné, ce qui a surpris, et la liste des actions correctives à intégrer au plan avant le prochain exercice.

Les simulations de phishing comme complément

Les exercices tabletop testent les procédures organisationnelles. Les simulations de phishing testent les réflexes individuels des collaborateurs tout au long de l’année : mesure du taux de clic, du délai de signalement, et formation automatique après chaque clic. Une simulation mensuelle maintient une vigilance que les exercices annuels seuls ne peuvent pas installer.

Le retour d’expérience

Chaque incident réel — même mineur — est une source d’apprentissage. Le retour d’expérience (REX) est le processus qui transforme cet apprentissage en améliorations concrètes du plan.

Organisez le REX dans les 5 à 10 jours suivant la clôture de l’incident, quand les souvenirs sont encore précis mais que le stress immédiat est retombé.

Structure du rapport post-incident

Résumé exécutif (une page) : type d’incident, date et durée, impact résumé, décisions clés. À destination de la direction.

Chronologie complète : heure par heure, de la détection à la clôture, avec le nom de la personne responsable de chaque action. Cette chronologie sert pour le dépôt de plainte, la notification CNIL et la déclaration d’assurance.

Vecteur d’entrée : comment l’attaquant est entré — email de phishing, vulnérabilité non patchée, accès tiers compromis, erreur humaine. Si le vecteur n’est pas identifié avec certitude, documentez les hypothèses.

Ce qui a fonctionné / ce qui a échoué : les éléments du plan utilisés avec succès, les procédures absentes, les délais dépassés, les contacts introuvables.

Actions correctives : liste numérotée, avec un responsable et une date d’échéance pour chaque action. Ces corrections doivent être intégrées au plan avant le prochain exercice.

Coûts de l’incident : frais de remédiation, perte d’exploitation, frais juridiques, coûts de notification.

Mettre à jour le plan après chaque REX

Le plan est un document vivant. Révisez-le après chaque incident réel, chaque exercice, et chaque changement organisationnel (nouveau prestataire IT, départ du référent juridique, évolution réglementaire). Versionnez chaque révision avec une date et le nom des approbateurs.

Questions fréquentes

Thomas Ferreira, CISSP, GCFA, GCIH — Consultant en réponse à incident et formateur en cybersécurité. Thomas accompagne des PME et ETI françaises dans la gestion de crise cyber, la préparation aux incidents, et la mise en conformité réglementaire. Il anime des exercices de simulation de crise (tabletop) depuis 2016 dans des secteurs allant de la santé à l’industrie. Ce guide s’appuie sur le cadre NIST SP 800-61 Rev. 3, les guides publiés par l’ANSSI sur cyber.gouv.fr, les contrôles ISO 27001 Annexe A.5.24-26, et les exigences de l’article 21 de la directive NIS2.

Pour construire votre PSSI (politique de sécurité des systèmes d’information) ou compléter votre programme de simulation de phishing, consultez les guides correspondants sur nophi.sh.