Fuite de données : par où elle arrive, comment la détecter, quoi faire en
72 heures

En 2025, la CNIL a reçu 6 167 notifications de violation de données, soit 9,5 % de plus que l'année précédente, et un incident déclaré sur deux relève d'un piratage. Derrière ces notifications, il y a rarement une attaque sophistiquée. Il y a des organisations qui découvrent, souvent des mois trop tard, que des données qu'elles pensaient closes circulaient déjà ailleurs. Une fuite de données se joue dans ce silence, puis dans les trois jours qui suivent sa découverte.

Côté entreprise, le sujet est double. Il y a la mécanique technique, par où les données sortent, et la mécanique réglementaire, avec une horloge de 72 heures qui démarre au pire moment, celui où personne ne sait encore l'étendue des dégâts. Les deux se traitent ensemble ou pas du tout : un RSSI qui maîtrise son périmètre mais improvise sa notification prend une sanction, et un juriste aguerri sur l'article 33 sans télémétrie derrière n'a rien à notifier parce qu'il ne voit rien.

Ce que le RGPD appelle une violation de données

Le RGPD n'emploie ni fuite de données ni data breach. Son article 4 (12) définit une violation de données à caractère personnel comme "une violation de la sécurité entraînant, de manière accidentelle ou illicite, la destruction, la perte, l'altération, la divulgation non autorisée de données à caractère personnel transmises, conservées ou traitées d'une autre manière, ou l'accès non autorisé à de telles données". Confidentialité, intégrité, disponibilité : les trois y passent.

Un ransomware qui chiffre vos bases sans rien exfiltrer ne divulgue rien, mais détruit la disponibilité : violation notifiable. Un salarié qui modifie des dossiers sans habilitation porte atteinte à l'intégrité : violation également. Un ordinateur portable non chiffré oublié dans un train, un mail envoyé à la mauvaise liste de diffusion, une sauvegarde perdue par un prestataire, tout cela entre dans la même case juridique que l'exfiltration de vingt millions de lignes par un groupe organisé. Beaucoup d'organisations n'ouvrent leur procédure que sur le scénario spectaculaire, et se retrouvent démunies devant les cas ordinaires, qui sont les plus nombreux.

Les cinq chemins que prend une fuite de données

Les vecteurs se répètent avec une régularité déprimante, et aucun n'exige de 0-day. Tous ont en commun d'être invisibles depuis l'intérieur du système d'information, parce qu'ils vivent sur des actifs que personne dans l'organisation ne considère comme siens.

1. Le dépôt Git public

Un identifiant de base de données codé en dur, poussé une fois, reste dans l'historique même après avoir été "retiré" au commit suivant. Le cas d'école reste Toyota : une clé d'accès poussée par un sous-traitant sur un dépôt public en décembre 2017, découverte en septembre 2022, et pendant ces cinq ans un accès aux données de près de 300 000 clients. Le mécanisme, la vitesse à laquelle des bots ramassent une clé exposée et l'ordre correct des opérations de réponse sont détaillés dans notre article sur les fuites de secrets, clés d'API et credentials exposés. C'est le chemin le plus documenté, et de loin le plus fréquent.

2. Le stockage objet mal configuré

Un bucket S3, un conteneur Azure Blob, un espace GCP Storage passé en lecture publique pour débloquer un déploiement, puis jamais refermé. Le contenu typique n'est pas anodin : exports CSV pour l'équipe marketing, sauvegardes de base au format .sql.gz, pièces jointes d'un back-office, journaux applicatifs qui recopient des corps de requête entiers. L'URL n'a même pas besoin d'être devinée : les moteurs d'indexation de buckets font ce travail en continu, et un ListBucket autorisé rend l'inventaire complet accessible en une requête.

3. Le sous-domaine que plus personne ne regarde

Toute organisation qui a plus de trois ans traîne des actifs orphelins : une recette montée pour une refonte, un outil interne exposé "temporairement" sur Internet, un ancien site de campagne. Ces machines cumulent trois défauts simultanés. Elles ne sont plus mises à jour, elles n'ont pas d'équipe propriétaire, et elles hébergent très souvent une copie des données de production, parce qu'on avait besoin d'un jeu de test réaliste. C'est ce fantôme qui fuit, pendant que l'application principale reste patchée et surveillée. Un inventaire annuel ne le voit pas : entre deux audits, le périmètre a déjà changé plusieurs fois.

4. Le credential stuffing

Ici, rien n'est cassé chez vous. L'attaquant rejoue sur votre formulaire d'authentification des couples e-mail et mot de passe volés lors de la fuite d'un autre service, et ouvre les comptes des utilisateurs qui avaient recyclé le leur. La CNIL, qui range le credential stuffing parmi les attaques dont il faut se prémunir, a tranché sur la responsabilité dès janvier 2021 en sanctionnant un responsable de traitement (150 000 €) et son sous-traitant (75 000 €) pour des mesures insuffisantes face à des vagues d'attaques étalées de 2018 à 2020 : les identifiants venaient d'ailleurs, le manquement à l'article 32 était chez eux. La mécanique, des combo lists aux défenses qui tiennent encore, est traitée dans notre article sur le credential stuffing et les limites du filtrage par IP.

5. Le sous-traitant

Deux des fuites de données les plus massives déclarées en France ces dernières années ne sont pas parties d'une faille applicative chez le responsable de traitement. En février 2024, la CNIL annonce que la compromission des opérateurs de tiers payant Viamedis et Almerys touche plus de 33 millions de personnes, via l'usurpation de comptes de professionnels de santé hameçonnés. Un mois plus tard, l'attaque contre France Travail expose les données de 43 millions de personnes inscrites au cours des vingt dernières années, par usurpation de comptes de conseillers Cap emploi. Dans les deux cas, l'accès légitime d'un tiers a servi de porte d'entrée. Votre surface d'attaque inclut donc les comptes que vous avez ouverts à d'autres, et les vôtres chez eux.

Détecter une fuite de données avant qu'on vous l'apprenne

Le mode de découverte le plus courant d'une fuite reste l'alerte extérieure : un client qui reçoit un phishing trop bien renseigné, parfois signé d'un domaine qui imite le vôtre, un journaliste, un chercheur, ou l'attaquant lui-même qui publie un échantillon pour prouver sa marchandise. Ce n'est pas une fatalité, c'est la conséquence d'une télémétrie construite pour l'exploitation et pas pour la détection. Quatre signaux suffisent à inverser ça, deux à l'intérieur du SI, deux à l'extérieur.

Voir sortir la donnée

Une exfiltration a une signature simple : un compte légitime lit, en peu de temps, beaucoup plus d'enregistrements que d'habitude. Encore faut-il que quelqu'un compte. La journalisation applicative sert rarement à ça : elle trace les erreurs, pas les volumétries de lecture. Poser un compteur par compte et par fenêtre glissante, définir un seuil au-delà duquel une alerte part, et conserver ces journaux assez longtemps pour reconstituer un périmètre après coup, c'est peu de travail, et c'est précisément son absence qui a été reprochée à France Travail.

Le 30 avril 2025, la CNIL a publié des consignes pour les bases de données de plusieurs millions de personnes qui listent quatre attendus : authentification multifacteur pour les accès distants, y compris ceux des sous-traitants ; traçabilité des accès conservée de six mois à un an, avec limitation des volumes d'extraction par utilisateur et détection des activités suspectes ; sensibilisation régulière du personnel ; encadrement contractuel et audit des sous-traitants. La CNIL a annoncé renforcer ses contrôles sur ces points à partir de 2026, l'absence de MFA pouvant à elle seule justifier une procédure de sanction.

-- Détecter un compte qui lit anormalement, sur une fenêtre d'une heure.
-- Le seuil se calibre sur VOTRE p99, pas sur une valeur trouvée dans un blog.
SELECT account_id,
       date_trunc('hour', ts) AS bucket,
       count(*)               AS records_read
FROM access_log
WHERE action = 'read' AND ts > now() - interval '7 days'
GROUP BY 1, 2
HAVING count(*) > 5000          -- p99 observé chez vous x 3, par exemple
ORDER BY records_read DESC;

Regarder son périmètre depuis dehors

Les vecteurs 1 à 3 ne sont visibles que du point de vue de l'attaquant : depuis Internet, sans identifiants, en partant du nom de domaine. C'est l'exercice que couvre le module détection de fuites et de secrets de notre EASM : découverte des dépôts Git exposés et de leur historique, test des fichiers de configuration servis sans authentification, inspection des buckets ouverts et des endpoints qui divulguent des données, à la fréquence à laquelle votre périmètre change. La valeur d'un secret trouvé est masquée avant toute écriture, pour ne pas recréer la fuite dans la base qui la détecte.

Guetter la réapparition, sans jouer les explorateurs

Quand des identifiants d'un domaine ressortent dans une combolist ou sur un forum de revente, l'information est exploitable : elle date la fuite, borne le périmètre et permet de forcer une réinitialisation ciblée. La tentation d'aller voir soi-même est mauvaise conseillère, pour des raisons à la fois juridiques et opérationnelles que détaille notre article sur l'accès au dark web. Ce que vaut une offre de surveillance du dark web, ses angles morts et les questions à poser à un prestataire méritent aussi d'être regardés froidement avant signature : le marché vend beaucoup de tableaux de bord pour peu de renseignement actionnable.

Notification CNIL sous 72 h : article 33 RGPD

L'article 33 du RGPD impose au responsable de traitement de notifier la CNIL "dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance", sauf si la violation n'est pas susceptible d'engendrer un risque pour les droits et libertés des personnes. Au-delà, la notification doit être motivée par les raisons du retard. Quand le risque est élevé, l'article 34 ajoute une obligation distincte : informer aussi les personnes concernées, dans les meilleurs délais. Le point de départ, le mode de décompte et le contenu appellent chacun une précision.

• Le point de départ n'est pas l'intrusion : le délai court à partir du moment où l'organisme a connaissance de la violation avec un degré raisonnable de certitude. Une alerte brute non qualifiée ne démarre pas l'horloge ; une première vérification concluante, si. Corollaire désagréable : repousser la qualification pour gagner du temps ne tient pas, la CNIL apprécie le délai "raisonnable" de cette phase.
• 72 heures calendaires : week-ends et jours fériés comptent. Une découverte le vendredi soir laisse jusqu'au lundi soir, ce qui ne se tient pas sans astreinte prévue.
• La notification peut être fractionnée : l'article 33 (4) autorise à transmettre les informations "par phases" quand elles ne sont pas toutes disponibles. Notifier un dossier incomplet dans les temps vaut toujours mieux qu'un dossier parfait hors délai.

Deuxième horloge, ignorée de beaucoup d'équipes juridiques : si votre entité relève de NIS2, l'article 23 de la directive impose un calendrier distinct auprès du CSIRT national, avec une alerte précoce sous 24 heures, une notification qualifiée sous 72 heures et un rapport final sous un mois. Les deux régimes se cumulent, avec des destinataires, des seuils de déclenchement et des contenus différents. Un incident majeur peut donc exiger une première déclaration avant même que le délai CNIL ne soit écoulé, et une procédure de crise qui ne connaît qu'une seule échéance rate la plus courte des deux.

Que faire en cas de fuite de données : l'ordre qui compte

La première réaction naturelle, réinstaller le serveur compromis pour "repartir propre", est la plus destructrice. Elle efface les traces qui auraient permis de dater l'intrusion, de borner ce qui est sorti et de rédiger une notification honnête. Sans elles, il ne reste qu'à déclarer le pire cas, ce qui coûte plus cher en réputation et en obligations d'information que la réalité de l'incident. Ce qui suit suppose une fuite avérée ; si vous en êtes encore à constater une intrusion sans savoir ce qui est sorti, la phase amont est traitée dans que faire en cas de piratage.

1. Horodater et geler : noter par écrit qui a su quoi et à quelle heure, faire une copie des journaux avant qu'ils ne tournent, prendre une image disque des machines suspectes. Isoler du réseau plutôt qu'éteindre, pour ne pas perdre la mémoire vive.
2. Couper l'accès, pas les preuves : révoquer les clés, invalider les sessions, forcer la rotation des credentials concernés, fermer le bucket ou le dépôt exposé. L'ordre exact de ces opérations, et la raison pour laquelle le nettoyage d'un historique Git arrive en dernier, sont détaillés dans le pilier sur les fuites de secrets.
3. Qualifier le périmètre : quelles catégories de données, combien de personnes concernées (un ordre de grandeur suffit pour notifier), quelles conséquences probables. C'est ce paragraphe qui détermine ensuite si l'article 34 s'applique.
4. Notifier : la CNIL via le téléservice dédié, le CSIRT si NIS2, le client si un contrat l'exige, l'assureur cyber dans les délais de la police. Déposer plainte : c'est un prérequis de nombreuses garanties.
5. Informer les personnes si le risque est élevé, en décrivant la nature de la violation, ses conséquences probables et les mesures prises, sans langue de bois. Une communication tardive ou minimisante se retourne systématiquement contre l'émetteur.
6. Corriger, puis vérifier la correction : la remédiation n'est terminée que lorsqu'un test indépendant confirme que le chemin est refermé. Structurer cette phase relève de la gestion des vulnérabilités : un cycle, avec des priorités, des responsables et des dates.

Qui contacter, et dans quel ordre

Au-delà de la chronologie interne, quatre interlocuteurs comptent, et ils ne servent pas la même chose.

• La CNIL, via son téléservice de notification, dès que la violation est susceptible d'engendrer un risque (article 33), et les personnes concernées si ce risque est élevé (article 34).
• Le CERT-FR de l'ANSSI pour l'appui technique et le signalement : c'est lui qui joue le rôle de CSIRT national pour les entités relevant de NIS2, avec ses propres échéances (alerte précoce sous 24 heures).
• La police ou la gendarmerie, pour un dépôt de plainte : il conditionne de nombreuses garanties d'assurance et ouvre l'enquête pénale. Une TPE ou PME sans équipe sécurité peut s'appuyer sur cybermalveillance.gouv.fr pour être orientée et trouver un prestataire.
• L'assureur cyber, dans les délais imposés par la police d'assurance, souvent plus courts que ceux du RGPD : prévenir tard, c'est risquer un refus de prise en charge.

Ce qui réduit le risque, par ordre d'effet

Aucune mesure ne ramène le risque à zéro, mais toutes ne se valent pas. Les trois qui déplacent le curseur le plus fort ne sont pas des achats d'outil.

Réduire ce qui est exposé. Chaque service accessible depuis Internet est un candidat. Fermer une préprod publique, retirer une copie de base d'un environnement de test, supprimer un export CSV vieux de deux ans dans un bucket, c'est du risque qui disparaît du tableau au lieu d'y rester en surveillance. Encore faut-il savoir ce qui existe, ce qui suppose un inventaire vivant du périmètre externe plutôt qu'un tableur mis à jour à chaque audit.

Plafonner ce qu'un accès permet. Le grief le plus répété par la CNIL est celui des habilitations trop larges. Un compte de conseiller, de support ou de partenaire qui peut lire l'intégralité d'une base transforme un hameçonnage banal en fuite de masse. Le cloisonnement ne prévient pas l'intrusion : il plafonne son coût, ce qui est souvent la seule variable sur laquelle on garde la main.

Répéter la procédure à froid. Une notification en 72 heures est d'abord un problème de logistique : qui décide qu'on a "connaissance", qui rédige, qui valide, qui parle aux clients, comment on joint le DPO un samedi. Un exercice sur table d'une demi-journée par an révèle plus de trous qu'une politique de trente pages.

À retenir

• Le RGPD parle de violation de données, pas de fuite, et couvre trois atteintes : confidentialité, intégrité et disponibilité. Un ransomware sans exfiltration est notifiable.
• Cinq chemins concentrent l'essentiel des cas : dépôt Git public, bucket ouvert, sous-domaine oublié, credential stuffing, sous-traitant. Aucun n'exige de faille sophistiquée, tous sont invisibles depuis l'intérieur.
• Les 72 heures démarrent à la prise de connaissance avec un degré raisonnable de certitude, sont calendaires, et une notification par phases vaut mieux qu'un dossier complet hors délai.
• Si vous relevez de NIS2, une seconde horloge tourne : 24 heures d'alerte précoce au CSIRT, 72 heures de notification qualifiée, un mois de rapport final.
• En réponse : on gèle les preuves avant de nettoyer, on révoque les accès, on qualifie le périmètre, on notifie, puis seulement on reconstruit. Réinstaller d'abord, c'est se condamner à déclarer le pire cas.
• Le registre des violations de l'article 33 (5) couvre aussi les incidents non notifiés. Son absence est un manquement à part entière.

Technique et réglementaire, les deux chantiers ne se mènent pas au même endroit. Ce qui est déjà dehors se constate depuis l'extérieur, en partant d'un nom de domaine : c'est le travail du module Leaks & secrets de notre EASM. Le reste, l'astreinte du week-end, le registre de l'article 33 (5), la personne qui a le droit de dire qu'on a "connaissance", s'écrit à froid et ne s'achète nulle part. Un pentester répond sur la page contact pour confronter cette procédure à ce qu'un attaquant en ferait.

Questions fréquentes sur les fuites de données