Fuite Intermarché : le réflexe RGPD 72 h et le plan de réponse PME

Une enseigne de la grande distribution confirme une cyberattaque avec exfiltration de données clients. Au-delà du cas Intermarché, c'est le déroulé opérationnel des 72 premières heures — notification CNIL, information des personnes, preuve de diligence — qui doit être pré-écrit dans toute organisation, PME comprise.

En bref

Intermarché a confirmé une cyberattaque survenue « la semaine dernière » (date exacte non documentée dans la source), ayant entraîné une fuite de données. Le périmètre précis des données, le vecteur d'intrusion et le nombre de personnes concernées ne sont pas documentés dans l'extrait disponible.
L'enseigne appartient au groupement Les Mousquetaires (ITM Entreprises), structure coopérative d'adhérents indépendants : un modèle qui complexifie la chaîne de responsabilité RGPD entre tête de réseau et points de vente.
Le compte à rebours réglementaire est de 72 heures (article 33 RGPD) pour notifier la CNIL, et « dans les meilleurs délais » (article 34) pour informer les personnes en cas de risque élevé.
Depuis la LOPMI de janvier 2023, l'indemnisation par l'assurance cyber est conditionnée au dépôt de plainte sous 72 heures ouvrées (article L. 12-10-1 du code des assurances).
Le secteur de la production/distribution alimentaire figure à l'annexe II de NIS2 : les enseignes de taille moyenne et grande relèvent du statut d'« entité importante ».

Contexte

Intermarché a confirmé publiquement avoir subi une cyberattaque la semaine précédant la publication de l'information par Le Monde Informatique, avec pour conséquence une fuite de données. À ce stade, l'extrait de source dont nous disposons ne détaille ni le vecteur d'intrusion, ni la nature exacte des données exfiltrées, ni le volume de clients touchés, ni l'identité d'un éventuel groupe revendiquant l'attaque. Ces éléments sont non documentés et il faut se garder de les extrapoler : dans la plupart des incidents de ce type, la communication initiale de l'entreprise est volontairement prudente, puis affinée à mesure que l'investigation forensique progresse.

Ce qui est en revanche structurant, c'est le modèle organisationnel de l'enseigne. Intermarché est l'une des enseignes du groupement Les Mousquetaires (avec Netto, Bricomarché, Bricorama, Brico Cash, Roady), une coopérative de commerçants indépendants. Chaque point de vente est juridiquement une entreprise autonome, souvent une PME de quelques dizaines de salariés, tout en s'appuyant sur des services mutualisés : centrale d'achat, systèmes d'encaissement, programme de fidélité, e-commerce, drive, plateformes marketing. Cette architecture hybride est fréquente dans le retail français (Système U, Leclerc/Galec, Intersport) et elle crée une zone grise : qui est responsable de traitement, qui est sous-traitant, qui notifie ?

L'incident s'inscrit dans une série continue de compromissions visant les bases clients du commerce français. Sur les deux dernières années, plusieurs enseignes ont publiquement reconnu des fuites affectant leurs fichiers de fidélité ou de commande — Boulanger, Cultura, Truffaut, Auchan, sans oublier les opérateurs télécoms (Free, SFR) dont les bases ont alimenté un marché de la donnée personnelle française. Le point commun : les données volées ne sont pas bancaires dans la majorité des cas, mais elles sont hautement qualifiantes (identité + coordonnées + historique d'achats + statut fidélité), donc directement monétisables pour du phishing ciblé, de la fraude au support client ou du SIM swapping.

Détails techniques

Ce que l'on peut raisonnablement analyser

En l'absence de détails techniques publiés, l'exercice utile consiste à cartographier les surfaces d'attaque typiques d'un back-office retail, celles que tout consultant doit auditer chez ce type de client :

| Surface | Vecteur observé dans le secteur | Donnée exposée |

|---|---|---|

| Plateforme CRM / marketing automation | Compte admin sans MFA, token API en clair | Base fidélité complète |

| Espace client web / API mobile | Énumération d'IDs, IDOR, absence de rate limiting | Profils un par un, à grande échelle |

| Prestataire (routeur d'e-mails, éditeur PDV) | Compromission en cascade supply chain | Extractions plates (CSV) |

| VPN / accès distant magasin | Credential stuffing, VPN non patché | Latéralisation vers l'AD |

| Exports « métier » | Fichiers CSV/XLS sur partage ouvert | Extractions historiques oubliées |

Le mode opératoire le plus fréquent dans les fuites retail n'est pas un ransomware avec chiffrement massif, mais une exfiltration silencieuse via un compte légitime : pas de bruit sur l'EDR, pas d'arrêt d'exploitation, détection tardive — souvent par la mise en vente de la base sur un forum.

Les 72 heures : ce que dit exactement le texte

L'article 33 du RGPD impose la notification à l'autorité de contrôle « dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance ». Trois points sous-estimés :

Le délai part de la prise de connaissance, pas de la fin de l'investigation. Une notification incomplète est prévue par le texte (art. 33.4 : information « par phases »).
Si le délai est dépassé, il faut motiver le retard dans la notification.
Le sous-traitant doit alerter le responsable de traitement sans délai (art. 33.2) — d'où l'importance des clauses contractuelles chiffrées (« sous 24 h ») dans les contrats d'hébergement, de CRM et d'éditeur de caisse.

L'article 34 déclenche l'information des personnes concernées si la violation est « susceptible d'engendrer un risque élevé pour les droits et libertés ». Sur une base fidélité (nom, e-mail, téléphone, adresse, historique), la CNIL considère généralement que le risque de phishing ciblé et d'usurpation justifie l'information individuelle.

Grille d'évaluation du risque, à formaliser avant l'incident


# risk_assessment.yaml — à remplir en séance de crise, horodaté
incident_id: INC-2026-0142
detected_at: "2026-01-14T09:12:00+01:00"        # T0 = départ des 72h
data_categories:
  - identite: [nom, prenom]
  - contact: [email, telephone, adresse_postale]
  - fidelite: [numero_carte, solde_points, historique_achats]
  - auth: [password_hash]                        # algo ? bcrypt / MD5 ?
  - bancaire: none                               # à PROUVER, pas à supposer
special_categories: false                        # art. 9 RGPD ?
volume_personnes: 0                              # estimation basse/haute assumée
gravite_ENISA:
  data_processing_context: 3
  ease_of_identification: 1
  circumstances_of_breach: 0.5
  severite_calculee: "eleve"
art34_information_requise: true
canal_information: [email_direct, bandeau_site, communique_presse]

La méthodologie de calcul de sévérité de l'ENISA (Recommendations for a methodology of the assessment of severity of personal data breaches) reste la référence pour objectiver la décision « art. 34 : oui/non » et la documenter. C'est ce document, pas la conviction du DPO, qui sera examiné en cas de contrôle.

Détection d'exfiltration : requêtes à préparer

Ce qui manque le plus souvent en PME, ce n'est pas l'outil mais la requête pré-écrite. Exemples à intégrer dans un runbook :


-- PostgreSQL : détecter les lectures massives sur la table clients
-- (nécessite pgaudit ou log_statement = 'all')
SELECT usename, client_addr, count(*) AS reqs, date_trunc('hour', log_time) AS h
FROM postgres_log
WHERE command_tag = 'SELECT'
  AND message ILIKE '%from customers%'
GROUP BY 1,2,4
HAVING count(*) > 500
ORDER BY reqs DESC;


# Nginx : top des IP par volume de réponse sortante (exfil via API client)
awk '{bytes[$1]+=$10} END {for (ip in bytes) print bytes[ip]/1048576" MB", ip}' \
  /var/log/nginx/access.log | sort -rn | head -20

# Recherche d'accès à un endpoint de profil avec énumération d'ID
grep -E '/api/v1/customers/[0-9]+' access.log \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head


// Microsoft 365 / Entra ID : export inhabituel depuis SharePoint/OneDrive
CloudAppEvents
| where ActionType in ("FileDownloaded","FileSyncDownloadedFull")
| summarize files=count(), volume=sum(todouble(RawEventData.ObjectSize))
    by AccountDisplayName, bin(Timestamp, 1h)
| where files > 200

La chaîne de responsabilité en réseau coopératif

Point critique pour les groupements : établir avant l'incident la qualification des traitements. Le programme de fidélité national est généralement piloté par la tête de réseau (responsable de traitement), tandis que la gestion locale du fichier client magasin peut relever d'une responsabilité conjointe (art. 26 RGPD) nécessitant un accord écrit répartissant les obligations, dont celle de notifier. Sans cet accord, chaque partie se renvoie la balle pendant les heures qui comptent.

Implications pour les consultants IT

Premier réflexe : le plan de réponse doit être un document exécutable, pas une politique. Un plan de réponse utile en PME tient en 6 à 10 pages et répond à quatre questions opérationnelles : qui décide (nom, portable, suppléant), qui isole (procédure de coupure des accès distants et de révocation des tokens), qui parle (client, autorité, presse, salariés), et qui écrit (journal de crise horodaté). Le journal de crise est l'artefact le plus rentable : c'est lui qui démontrera la diligence devant la CNIL et qui conditionnera l'appréciation de la sanction. La CNIL peut prononcer jusqu'à 10 M€ ou 2 % du chiffre d'affaires mondial pour manquement aux articles 32 (sécurité) et 33 (notification) — sachant que dans la pratique française, l'absence de MFA, l'absence de journalisation et la conservation excessive de données sont les trois manquements les plus régulièrement retenus dans les délibérations sur violations de données.

Deuxième réflexe : dissocier les trois horloges. L'horloge RGPD (72 h vers la CNIL), l'horloge assurantielle (72 h ouvrées pour le dépôt de plainte, condition de l'indemnisation depuis la LOPMI) et l'horloge NIS2 (pour les entités concernées : alerte précoce sous 24 h, notification sous 72 h, rapport final sous un mois auprès de l'ANSSI). Ces trois obligations ne visent pas le même destinataire ni le même contenu, et elles se déclenchent simultanément. Un tableau de correspondance dans le runbook, avec les canaux réels (téléservice de notification de violation de la CNIL, plateforme de l'ANSSI, formulaire de l'assureur, plainte via police/gendarmerie ou dispositif 17Cyber), évite de perdre une demi-journée en recherche administrative.

Troisième réflexe : traiter la donnée fidélité comme un actif critique. Dans le retail, le CRM est trop souvent perçu comme un outil marketing hors périmètre sécurité. Or c'est la cible n°1 : forte densité de données personnelles, accès nombreux (siège, agences, prestataires, magasins), exports CSV en libre-service, comptes techniques partagés, souvent en SaaS avec une fédération d'identité mal cloisonnée. Les mesures à imposer sont peu coûteuses : MFA sur tous les comptes back-office sans exception, suppression des comptes génériques, limitation et journalisation des exports (seuil d'alerte au-delà de N enregistrements), politique de purge effective des historiques (art. 5.1.e), et pseudonymisation des jeux de données utilisés en recette. Chaque enregistrement conservé au-delà de sa durée d'utilité est un passif.

Quatrième réflexe : anticiper la vague post-fuite. Une fuite de base clients dans la distribution alimentaire se traduit mécaniquement, dans les jours qui suivent, par des campagnes de phishing crédibles usurpant l'enseigne — faux remboursements, faux points de fidélité, faux drive. Le plan de communication doit donc être préventif : dire explicitement aux clients ce que l'enseigne ne leur demandera jamais (code de carte, virement, identifiants), publier une page unique de référence sur le domaine officiel, et surveiller les enregistrements de noms de domaine typosquattés. Côté interne, briefer les équipes de caisse et de service client avant qu'elles ne soient exposées aux appels : c'est le premier point de fuite d'informations non validées.

Pour aller plus loin

Source originale : Intermarché victime d'une fuite de données après une cyberattaque (Le Monde Informatique)

Trois actions concrètes à mener cette semaine chez vos clients du retail et de la distribution :

Auditer les accès au CRM et aux back-offices marketing : inventaire des comptes administrateurs, vérification de la couverture MFA à 100 %, révocation des tokens API dormants, activation de la journalisation des exports avec seuil d'alerte. Livrable : liste nominative des accès avec date de dernière connexion.
Tester le chronomètre des 72 heures à blanc : exercice sur table de deux heures, scénario « une base client de 400 000 lignes est en vente sur un forum ». Objectif mesurable : produire un projet de notification CNIL renseigné (catégories de données, volume estimé, mesures prises) et une évaluation de sévérité ENISA documentée. Vérifier au passage que les clauses de notification sous 24 h existent bien dans les contrats sous-traitants (art. 28).
Vérifier l'assurabilité et la chaîne juridique : confirmer par écrit auprès du courtier l'exigence de dépôt de plainte sous 72 h ouvrées, identifier le point de contact police/gendarmerie ou le parcours 17Cyber, et — pour les réseaux coopératifs — formaliser l'accord de responsabilité conjointe (art. 26) précisant qui notifie l'autorité et qui informe les personnes concernées.