Faut-il prévenir ses clients quand le site est piraté ?

Pas automatiquement, pas jamais

Faut-il prévenir ses clients quand le site est piraté ? La réponse marketing (« transparence totale tout de suite ») et la réponse panique (« surtout rien dire ») sont toutes les deux mauvaises. On prévient quand quelqu’un a un geste à faire (changer un mot de passe, surveiller une carte, ne pas saisir sur une page) ou un droit à l’information (données personnelles potentiellement lues). On ne prévient pas le monde entier parce que la home a affiché un drapeau trois heures.

Un défacement sans accès à la base n’est généralement pas une violation de données — encore faut-il pouvoir l’établir. C’est le constat qui décide, pas le ressenti du lundi matin. Tant que le constat n’existe pas, une comm’ large invente des faits (« toutes vos cartes ont fuité ») que vous ne pourrez plus rattraper.

Inversement, attendre trois semaines alors qu’un skimmer tournait, pour « ne pas faire de vagues », est le scénario qui finit mal : banque, clients, parfois CNIL, et la vague quand même. L’arbre ci-dessous tranche plus vite qu’un comité.

• Geste utile pour eux → prévenir ceux qui doivent agir.
• Données / paiement à risque → prévenir + cadre légal.
• Gêne visuelle seule → interlocuteurs directs, pas la une.

Aucun accès données, aucun paiement : rester ciblé

Home défigurée, spam SEO, redirection déjà coupée, alerte Chrome en cours de levée : les gens qui vous ont écrit méritent une réponse (« nous traitons, le site légitime est X, ne saisissez rien sur les pages étranges »). Un blast à toute la base CRM, non. Vous créez des tickets, des rumeurs, parfois un article de presse local sur une rumeur plus large que les faits.

Les partenaires qui dépendent du site (agenda, B2B) : un mail court, horloge 1 vs 2 vs 3. Délais. Pas « on a été hackés par un groupe international ».

Équipe interne : oui, tout de suite, consignes (ne pas payer, ne pas restaurer, ne pas tweeter). C’est de la comm’ opérationnelle, pas client.

Risque réel : qui est « concerné »

Checkout skimmé : les clients de la fenêtre de dates, pas « depuis la création de la boutique ». Comptes connectés : ceux dont la table a pu être lue. Newsletter : si la liste a pu sortir. Employés : si la messagerie a servi de relais. La précision des dates vient des logs et des mtimes, pas du note de rançon (« 50 000 clients »).

Banque / PSP : souvent avant ou en même temps que les clients, si cartes. Ils ont des process. Boutique : l’ordre tunnel d’abord.

Personnes non clientes (visiteurs d’un formulaire de contact) : si ce fichier a pu partir, elles aussi. Le CRM n’est pas le seul silo.

L’arbre en cinq questions

1) Un paiement a-t-il pu être saisi sur une page non légitime ? Oui → concernés + PSP. 2) Une table (clients, leads, mots de passe) a-t-elle pu être lue ou dumpée ? Oui → concernés + cadre fuite. 3) Un phishing sur votre domaine a-t-il pu collecter des identifiants d’un tiers (banque) ? Oui → couper, parfois prévenir si vous avez leurs emails, signaler. 4) Seulement une gêne (home, redirect, Chrome) ? → réponses ciblées. 5) Vous ne savez pas encore ? → pas de blast, constat d’abord, consignes à ceux qui appellent déjà.

Un « je ne sais pas » sur 1 ou 2 n’est pas un « non ». C’est un constat à faire en 24–48 h, pas un communiqué le soir même ni un silence d’un mois.

Rancon qui menace de publier : le texte n’est pas une preuve. Qualifiez, puis décidez. Ne pas payer.

Le canal : pas un thread public en premier

Email / courrier / SMS que vous maîtrisez, vers les concernés. Site (bannière factuelle) une fois que vous contrôlez le HTML. Réseaux sociaux : après, en une phrase, renvoyant vers la page que vous tenez — pas un thread de 40 réponses où l’attaquant ou un troll ajoute des « faits ». Twitter n’est pas une notification RGPD.

Presse : si on vous appelle, faits courts, pas de volumétrie inventée. « Nous traitons, les personnes concernées sont informées par nos canaux. » Point.

Téléphone : pour les gros comptes B2B, parfois. Script écrit, pour que cinq commerciaux ne disent pas cinq versions.

Le ton : faits, dates, ce qu’on leur demande

Qui vous êtes, quelle période, quel risque (pas « vos vies sont en danger »), quoi faire (surveiller relevés, changer un mot de passe de compte site, ignorer les mails de rançon), où poser une question (un vrai email, pas un formulaire encore sur le CMS sale). Pas de jargon. Pas d’accusation de l’hébergeur. Pas de promesse « plus jamais ».

Ne demandez pas de ressaisir une carte « pour vérifier ». Ne joignez pas d’exécutable. Ne renvoyez pas vers une page de login si vous n’êtes pas sûrs qu’elle est propre.

Traduisez si votre base est bilingue. Un mail FR à une base BE/NL se forward et se déforme.

CNIL et obligations : ce qui n’est pas un tweet

Violation de données personnelles : notification CNIL dans les 72 h si le risque l’exige, et information des personnes si le risque est élevé. C’est un formalisme, pas un post LinkedIn. Avocat / DPO. Le constat technique alimente. Il ne remplace pas le formulaire.

Un défacement sans lecture de base : souvent pas une violation. Un dump `wp_users` + emails : si. Ne laissez pas un community manager « gérer la CNIL ». Mauvais métier.

Contrats clients (B2B, sous-traitance) : parfois une obligation d’informer le responsable de traitement plus stricte que « on verra ». Lisez le DPA. Horloge courte.

Timing : trop tôt, trop tard

Trop tôt : blast « toutes les cartes » le matin d’un défacement, démenti le soir, crédibilité à zéro. Trop tard : skimmer de trois semaines, mail le mois suivant. Fenêtre utile : dès que 1 ou 2 de l’arbre est oui, avec les dates que vous tenez, quitte à affiner (« période au moins du … au …, investigation en cours »).

Pendant l’horloge Safe Browsing : une phrase à ceux qui voient le rouge (« c’est une liste, le contenu est en cours de traitement, ne forcez pas »). Pas une conférence de presse.

Documentez qui a été informé, quand, quel texte. Pièce assurance et CNIL. Déclarer le sinistre.