Comment rediger un plan de reponse aux incidents cyber en 7 etapes

Aout 2026 restera comme un des mois les plus charges de l'histoire de la cybersecurite. Plus de 50 breaches documentees en France, la fuite DGFiP de 678 000 dossiers fiscaux, des failles critiques ServiceNow sur les composants IA, des agents IA autonomes qui attaquent des infrastructures. Chaque semaine, nous recevons des appels de dirigeants de PME et ETI qui decouvrent, au moment ou l'incident frappe, qu'ils n'ont aucun plan.

Le probleme n'est pas l'absence de volonte. C'est que la redaction d'un plan de reponse aux incidents (PRI) parait complexe, reservee aux grandes entreprises, et que personne dans l'organisation ne sait par ou commencer. Ce guide propose une methode en 7 etapes concretes, testee chez nos clients PME et ETI, conforme aux exigences de NIS2 et aux recommandations de l'ANSSI.

Un avertissement prealable : un plan de reponse aux incidents n'est pas un document juridique. C'est un document operationnel. S'il fait plus de 30 pages, personne ne le lira le jour ou l'incident se produira. S'il n'a jamais ete teste, il ne fonctionnera pas. Visez la clarte, la concision et l'actionabilite. Un plan de 10 pages teste vaut mieux qu'un plan de 80 pages classe dans un tiroir.

Etape 1 — Identifier vos actifs critiques

Avant de rediger la moindre procedure, il faut repondre a une question simple : que protegez-vous, exactement ? La reponse n'est pas « tout ». Un PRI qui protege tout ne protege rien, parce qu'il ne permet pas de prioriser quand les ressources sont limitees — et elles le sont toujours pendant un incident.

Concretement, listez les systemes dont l'arret provoquerait une perte de chiffre d'affaires, une impossibilite de servir vos clients, ou une infraction reglementaire. Pour une PME industrielle, ce sera typiquement l'ERP, la messagerie, le systeme de gestion de production et les sauvegardes. Pour un cabinet medical, ce sera le logiciel de gestion des patients, la plateforme de rendez-vous et les dossiers medicaux electroniques.

Pour chaque actif, documentez : le responsable operationnel (la personne qui sait comment ca marche), le prestataire de maintenance (le numero a appeler a 3 heures du matin), les donnees hebergees (type, volume, sensibilite RGPD), et le temps d'arret tolerable (RTO — Recovery Time Objective). L'ANSSI recommande cette cartographie dans son guide de gestion des incidents de securite et NIS2 l'impose au titre de l'article 21 sur la gestion des risques.

Etape 2 — Constituer la cellule de crise

Un plan sans equipe est un document mort. La cellule de crise n'est pas un comite strategique : c'est le groupe operationnel qui prend les decisions pendant les premieres heures de l'incident. Dans une PME, elle comprend typiquement 4 a 6 personnes : le dirigeant ou son delegue, le responsable informatique, le DPO ou referent RGPD, un responsable de la communication, et le contact du prestataire de securite externe.

Pour chaque membre, inscrivez dans le plan : nom, role dans la cellule, numero de telephone mobile personnel, adresse email alternative (pas l'email professionnel — si la messagerie est compromise, il est inaccessible), et le nom du suppleant en cas d'absence. Un tableau d'une page suffit. Testez les numeros de telephone une fois par trimestre : les plans de reponse aux incidents echouent plus souvent a cause d'un numero de telephone obsolete que d'une erreur technique.

Prevoyez un canal de communication hors bande. Si votre SI est compromis, vous ne pouvez pas communiquer par email interne, par Teams, ou par le standard telephonique sur IP. Un groupe Signal ou WhatsApp cree a l'avance avec les membres de la cellule est la solution la plus simple. L'ANSSI recommande explicitement de prevoir des moyens de communication independants du SI potentiellement compromis.

Etape 3 — Classifier les incidents par niveaux de gravite

Tous les incidents ne justifient pas la meme reponse. Un email de phishing detecte et bloque par l'antispam n'exige pas de reveiller le dirigeant a 3 heures du matin. Un rancongiciel qui chiffre le serveur de fichiers, si. La classification doit etre objective, basee sur des criteres mesurables, pas sur le ressenti du moment.

Nous recommandons trois niveaux, alignes sur le referentiel ANSSI :

Niveau 1 — Mineur. Tentative de phishing bloquee, scan de ports detecte, malware isole par l'antivirus. Aucun impact sur la production. Action : journalisation, analyse par l'equipe IT, rapport mensuel. Pas d'activation de la cellule de crise.

Niveau 2 — Majeur. Compromission d'un compte utilisateur, exfiltration suspectee de donnees non sensibles, indisponibilite d'un service non critique pendant plus de 4 heures. Action : activation partielle de la cellule (responsable IT + prestataire externe), confinement du perimetre affecte, analyse forensique legere, notification au dirigeant.

Niveau 3 — Critique. Rancongiciel actif, exfiltration confirmee de donnees personnelles ou strategiques, compromission d'un compte administrateur, indisponibilite d'un actif critique. Action : activation complete de la cellule de crise, confinement immediat (coupure reseau si necessaire), notification ANSSI et CNIL dans les delais legaux, communication de crise. C'est le scenario qui mobilise l'integralite du PRI.

Etape 4 — Rediger les procedures de reponse

C'est le coeur du plan. Chaque procedure decrit les actions a mener dans l'ordre, par qui, avec quels outils. La structure suit le cycle classique recommande par l'ANSSI et le NIST : detection, confinement, eradication, restauration.

Detection. Comment detectez-vous qu'un incident est en cours ? Alertes EDR, signalement d'un utilisateur, notification d'un prestataire, alerte du SOC. Pour chaque source de detection, indiquez qui recoit l'alerte et quel est le delai maximal de prise en charge. Exemple concret : « Alerte EDR critique : le responsable IT est notifie par SMS. Delai de prise en charge : 30 minutes en heures ouvrees, 2 heures hors heures ouvrees. »

Confinement. L'objectif est de limiter la propagation de l'incident sans detruire les preuves. Les procedures de confinement varient selon le type d'incident. Pour un rancongiciel : isoler la machine du reseau (cable et Wi-Fi), ne pas eteindre (la memoire vive contient des artefacts forensiques), bloquer le compte compromis dans l'Active Directory. Pour une exfiltration : bloquer l'adresse IP ou le domaine de destination, revoquer les tokens d'acces concernes, changer les mots de passe des comptes suspects.

Eradication. Supprimer la cause de l'incident. Cela peut aller du nettoyage d'un malware au reformatage complet d'une machine, en passant par la revocation d'un acces prestataire compromis. Documentez les outils utilises et les etapes de verification : comment confirmez-vous que l'eradication est complete ?

Restauration. Remettre les systemes en production. Depuis les sauvegardes, depuis une image systeme, depuis une reinstallation propre. Indiquez les delais cibles (RTO) pour chaque actif critique identifie a l'etape 1. Testez la restauration au moins une fois par an : les sauvegardes non testees sont la principale cause de non-reprise apres un rancongiciel.

Etape 5 — Definir les procedures de notification

La notification est l'etape ou les PME perdent le plus de temps en situation de crise, parce qu'elles decouvrent a ce moment-la qu'elles ne savent pas exactement qui prevenir, dans quel ordre, et avec quel contenu. Preparez tout a l'avance.

Notification ANSSI (NIS2). Les entites essentielles et importantes doivent transmettre une alerte initiale a l'ANSSI dans les 24 heures suivant la detection d'un incident significatif. Une notification intermediaire suit sous 72 heures avec les premiers elements d'analyse. Un rapport final est attendu sous un mois. Preparez un modele pre-rempli avec les coordonnees de votre organisation, le perimetre de votre activite NIS2, et les contacts de votre cellule de crise.

Notification CNIL (RGPD). Si l'incident implique une violation de donnees personnelles, la notification a la CNIL doit intervenir dans les 72 heures suivant la connaissance de la violation (article 33). Le formulaire de notification est disponible sur le site de la CNIL. Si la violation est susceptible d'engendrer un risque eleve pour les droits et libertes des personnes, celles-ci doivent etre informees sans delai injustifie (article 34). La fuite DGFiP de 678 000 dossiers en aout 2026 illustre la complexite de la notification a grande echelle : preparez des modeles de communication pour les personnes concernees.

Notification interne. Qui previent la direction ? A partir de quel niveau de gravite ? Par quel canal ? Preparez un arbre de decision simple : incident mineur = email au responsable IT ; incident majeur = appel telephonique au dirigeant ; incident critique = activation du groupe Signal de la cellule de crise.

Communication externe. Clients, partenaires, presse. La communication de crise ne s'improvise pas. Preparez un communique type adaptable, designez un porte-parole unique, et definissez la regle d'or : on ne communique que ce qui est confirme, on ne specule pas sur l'origine ou l'etendue, et on indique les mesures prises et les prochaines etapes.

Etape 6 — Tester le plan avec un exercice de simulation

Un PRI non teste est un document decoratif. L'exercice de simulation est le moment ou vous decouvrez que le numero de telephone du prestataire est obsolete, que personne ne sait comment isoler un poste du reseau, ou que le dirigeant est en vacances et que son suppleant n'a jamais ete informe de son role.

L'exercice le plus accessible pour une PME est l'exercice sur table (tabletop exercise). Il dure une demi-journee, ne necessite aucune interruption de production, et implique les membres de la cellule de crise autour d'un scenario fictif mais realiste. Exemple de scenario pour une PME industrielle : « Vendredi 17 heures, un operateur signale que l'ecran de sa station de supervision affiche un message de rancongiciel. L'ERP est inaccessible. Le serveur de messagerie ne repond plus. Que faites-vous ? »

Deroulez le scenario etape par etape. A chaque phase, posez les questions : qui fait quoi ? Avec quels outils ? Quel est le delai acceptable ? Qui est notifie ? Documentez les points de blocage, les hesitations, les informations manquantes. Le retour d'experience (RETEX) de l'exercice est la matiere premiere de la mise a jour du PRI.

L'ANSSI recommande au minimum un exercice annuel. NIS2 impose des tests reguliers. Nous recommandons un exercice sur table tous les six mois et un exercice technique complet (simulation d'incident reel avec interventions sur les systemes) une fois par an. Le premier exercice revele toujours des failles dans le plan. C'est exactement son role.

Etape 7 — Maintenir et ameliorer en continu

Un PRI n'est pas un document qu'on redige une fois et qu'on range dans un classeur. C'est un document vivant qui doit etre mis a jour a chaque changement significatif dans l'organisation ou dans le paysage des menaces.

Mettez a jour le PRI apres chaque incident reel. L'incident est le meilleur test du plan. Qu'est-ce qui a fonctionne ? Qu'est-ce qui a coince ? Quelles procedures etaient incompletes, obsoletes ou irrealistes ? Chaque incident doit donner lieu a un RETEX formel et a une mise a jour documentee du PRI.

Mettez a jour le PRI apres chaque changement majeur d'infrastructure. Migration vers le cloud, changement d'ERP, deploiement d'une plateforme IA, changement de prestataire d'hebergement : chaque modification de la surface d'attaque ou de l'architecture de restauration doit etre refletee dans le plan. Les entreprises qui ont deploye ServiceNow AI cette annee sans mettre a jour leur PRI l'ont appris a leurs depens avec les failles critiques du 29 aout.

Mettez a jour le PRI apres chaque depart d'un membre de la cellule de crise. Un PRI qui contient le numero de telephone d'un collaborateur parti depuis six mois est un PRI qui echouera. Integrez la mise a jour des contacts dans votre processus de depart des collaborateurs.

Revoyez le PRI au minimum une fois par an, meme en l'absence d'incident ou de changement majeur. Le paysage des menaces evolue — les agents IA offensifs d'aout 2026 n'existaient pas il y a un an — et les procedures doivent evoluer avec lui. La revue annuelle est aussi l'occasion de verifier que les coordonnees sont a jour, que les outils references sont toujours operationnels, et que les procedures restent realistes.

En resume : un plan de reponse aux incidents n'est pas un projet, c'est un processus. Il ne sera jamais parfait. Mais un plan imparfait qui a ete teste vaut infiniment plus qu'un plan theoriquement parfait qui dort dans un tiroir. Commencez par l'etape 1 cette semaine. Dans un mois, vous aurez un PRI operationnel. Dans six mois, apres deux exercices et un ou deux incidents reels, vous aurez un PRI qui fonctionne vraiment.