Un vendredi à 18 heures, un client nous appelle : son site affiche des redirections vers un domaine russe depuis deux heures, et des clients lui signalent l’anomalie sur les réseaux sociaux. Ce n’est pas le moment de découvrir comment on gère un incident. Le nettoyage technique proprement dit — que nous couvrons ailleurs — n’est qu’une partie du travail. La partie souvent négligée, c’est l’organisation humaine et la conformité qui accompagnent la crise, et qui déterminent si l’incident reste maîtrisé ou s’aggrave par mauvaise communication.
Ce plan ne remplace pas un conseil juridique pour les cas complexes, mais il donne la structure minimale que toute agence ou équipe interne devrait avoir préparée avant qu’un incident ne survienne, pas pendant.
Désigner un rôle décisionnaire unique avant que la crise n’arrive
Le piège le plus fréquent en cas d’incident : plusieurs personnes agissent en parallèle sans se coordonner, l’une restaure une sauvegarde pendant que l’autre modifie des mots de passe, et personne ne sait plus quel est l’état réel du site. La première décision, dès la détection, consiste à désigner un responsable incident unique qui centralise les actions et les décisions, même si plusieurs personnes interviennent techniquement.
- Un responsable incident qui décide de l’ordre des actions et communique avec le client.
- Un ou deux techniciens qui exécutent, sans agir de leur propre initiative sur des points structurants (mise hors ligne, restauration, changement de mots de passe).
- Une personne en charge de la documentation en temps réel : ce qui est constaté, ce qui est fait, à quelle heure.
Les toutes premières minutes : contenir avant de comprendre
Face à un site compromis, la tentation est de vouloir comprendre immédiatement l’origine du problème. C’est une erreur d’ordre : il faut d’abord contenir, ensuite comprendre. Contenir signifie mettre le site en mode maintenance ou hors ligne, couper les accès qui pourraient permettre à l’attaquant de poursuivre (comptes FTP, clés API exposées), et préserver l’état actuel pour l’analyse, plutôt que de tout nettoyer précipitamment et perdre les traces de l’intrusion.
Cette phase de containment ne dure généralement pas plus d’une heure. Elle précède toute communication externe, car communiquer avant d’avoir stoppé l’hémorragie expose à devoir se corriger publiquement peu après.
La communication client : avant, pas après
Le client (l’entreprise propriétaire du site, pas forcément l’utilisateur final) doit être informé dès la phase de containment, même sommairement : « nous avons détecté une anomalie, le site est mis en pause le temps de l’analyser, nous revenons vers vous d’ici telle heure ». Cette communication précoce, même incomplète, évite que le client découvre l’incident par un client final ou par un outil de surveillance tiers avant vous, ce qui abîme durablement la relation de confiance.
Un point de suivi régulier, même bref (« toujours en cours d’analyse, prochain point à 20h »), vaut mieux qu’un silence de plusieurs heures suivi d’un rapport complet.
Qui doit être prévenu, et dans quel ordre
- Le responsable côté client, immédiatement, dès le containment engagé.
- L’hébergeur, si l’incident dépasse le périmètre applicatif (compromission au niveau serveur, autres sites mutualisés potentiellement touchés).
- Les utilisateurs finaux du site, seulement une fois l’ampleur réelle connue, pour éviter une communication qui devrait être corrigée ensuite.
- L’autorité de contrôle compétente (la CNIL en France), si l’incident constitue une violation de données personnelles au sens du RGPD.
Quand une violation de données doit être notifiée à la CNIL
Toute compromission ne constitue pas une violation de données au sens réglementaire. La question à se poser est précise : des données personnelles ont-elles été, ou ont-elles pu être, consultées, modifiées ou exfiltrées par une personne non autorisée ? Une simple défiguration du site sans accès à la base de données n’entre pas dans ce cadre. Un accès confirmé ou probable à la table des utilisateurs, des commandes ou des formulaires de contact, si.
Le règlement général sur la protection des données impose, lorsque la violation est susceptible d’engendrer un risque pour les droits et libertés des personnes, une notification à l’autorité de contrôle dans un délai de 72 heures à compter de la découverte de la violation, et non de l’incident lui-même — ce qui laisse une marge si la découverte est tardive, mais impose la rigueur dès l’identification du problème.
Notre conseil maison : dès qu’un doute existe sur l’accès à des données personnelles, on documente comme si une notification serait nécessaire. Revenir en arrière coûte moins cher que de reconstituer une chronologie a posteriori.
Ce qu’il faut documenter en continu
- L’heure de détection et la source (alerte utilisateur, outil de surveillance, hasard).
- Chaque action entreprise, avec heure et auteur.
- Les preuves techniques trouvées (fichiers modifiés, logs, comptes créés), avant tout nettoyage.
- L’évaluation de ce qui a potentiellement été exposé, même en l’absence de certitude absolue.
Cette documentation sert deux objectifs : elle nourrit une éventuelle notification CNIL, et elle permet un retour d’expérience utile pour éviter la répétition de l’incident.
En résumé
Un incident de sécurité se gère aussi bien humainement que techniquement. Un rôle décisionnaire clair, une communication précoce et honnête avec le client, et une évaluation rigoureuse de l’obligation de notification CNIL font la différence entre un incident maîtrisé et une crise qui s’étend bien au-delà du problème technique initial. Ce plan gagne à être écrit et partagé avec l’équipe avant qu’un incident ne survienne, pas pendant.
