Fuites de données en France en août 2026 : le dataset des incidents confirmés par la victime

Août 2026 laisse derrière lui, en France, une accumulation d'annonces de fuites de données dont le décompte varie selon qui le publie. Le problème n'est pas la rareté de l'information : les revendications d'attaquants, les avis aux clients et les relais spécialisés abondent. Le problème est l'absence de base commune. Un même incident peut être compté une fois comme intrusion chez un fournisseur, treize fois comme fuite chez ses clients, ou pas du tout si personne ne le confirme.

Ce dataset répond à cette difficulté par un critère unique et vérifiable : ne sont retenus que les incidents pour lesquels l'organisation victime a elle-même reconnu publiquement la compromission de données, sur la période du 1er au 31 août 2026, avec une entité concernée établie en France. Les revendications non confirmées sont conservées à part, comme signaux faibles en attente de qualification.

L'article expose la définition retenue, le protocole de collecte, la volumétrie observée, les deux cas qui structurent le mois, puis les limites du comptage et ce qui rend la mesure reproductible par un tiers. Les chiffres extérieurs cités sont attribués à leur publication d'origine, et les ordres de grandeur présentés comme les nôtres sont des observations assumées comme telles.

Définition retenue : ce qu'est une fuite de données confirmée par la victime

Une fuite confirmée par la victime suppose trois éléments réunis. Premier élément, un auteur identifiable du côté de l'organisation touchée : communiqué, notification aux personnes concernées, information des clients, déclaration rendue publique. Deuxième élément, la reconnaissance d'une compromission de données, et non simplement d'une tentative d'intrusion ou d'une indisponibilité de service. Troisième élément, une date de reconnaissance située dans la période d'observation.

Ce critère écarte volontairement une matière abondante. Une revendication publiée sur un forum criminel, même détaillée et même crédible, ne suffit pas : elle entre dans un second registre, celui des allégations à qualifier. À l'inverse, une confirmation sans volumétrie chiffrée est retenue, avec un champ de volume laissé vide plutôt qu'une estimation reconstituée. Le dataset préfère une case vide à un chiffre fabriqué, parce que la case vide reste interprétable.

Protocole de collecte : sources primaires, recoupement et chaîne de garde

La collecte part des relevés spécialisés qui documentent le sujet en France, puis remonte systématiquement vers la source primaire. INCYBER a publié une synthèse des fuites françaises du mois, et DCOD a recensé douze fuites majeures pour la seule journée du 20 août 2026 : ces relevés servent de point d'entrée, pas de preuve. Chaque entrée est ensuite rattachée, quand elle existe, à la communication de la victime elle-même.

Chaque ligne conserve donc deux niveaux d'information : le fait rapporté et le chemin par lequel il a été établi. Cette chaîne de garde, date de première mention, date de confirmation, support de la confirmation, est la partie la plus coûteuse du travail et la seule qui rende le dataset contestable dans le bon sens du terme, c'est-à-dire vérifiable ligne par ligne par un lecteur qui n'a pas participé à la collecte.

Volumétrie observée en août 2026 et cas documentés

Le mois se caractérise moins par un incident unique que par une densité inhabituelle. French Breaches a indiqué le 21 août 2026 avoir relayé cinq incidents en une seule matinée, susceptibles d'avoir affecté douze millions de comptes au total, et recensait au 23 août 2026 une cinquantaine de fuites confirmées par la victime depuis le début du mois. Solutions Numériques a publié pour sa part un bilan mensuel convergent.

Ce tableau n'est pas un classement de gravité. Un volume en gigaoctets et un nombre de personnes concernées ne sont pas commensurables : 71 Go de documents d'ingénierie peuvent peser davantage, pour la compétitivité d'une entreprise, que plusieurs centaines de milliers de lignes d'annuaire. Le dataset conserve les deux unités telles qu'elles ont été publiées et refuse toute conversion, faute de méthode défendable. D'autres victimes du mois complètent la liste, notamment Gédimat, Suez Eau de France, ainsi que les sites LaSante.net et Achats Or et Argent.

Le vol de données fiscales, cas de référence pour la qualification

Le dossier de la Direction générale des finances publiques concentre les difficultés méthodologiques du mois. Un attaquant revendique le 12 août 2026 l'extraction de 678 438 lignes issues d'un outil interne de l'administration fiscale, et l'administration reconnaît le 13 août 2026 un vol de données concernant 678 000 particuliers et entreprises. Deux chiffres voisins, deux natures différentes : des lignes extraites d'un côté, des personnes concernées de l'autre.

La composition des données pèse plus lourd que le volume. Identité, adresse, situation familiale, revenu fiscal de référence et taux de prélèvement à la source forment un profil directement exploitable pour de l'ingénierie sociale ciblée, parce qu'il permet d'ouvrir une conversation en connaissant déjà ce que la personne croit confidentiel. Le dataset enregistre donc, pour chaque ligne, la nature des champs compromis quand elle est publiée, et pas seulement leur nombre.

Le risque en cascade par le fournisseur, angle mort de tout dénombrement

Le cas BigCloud illustre la limite structurelle de l'exercice. Cette plateforme SaaS, qui fournit des solutions ERP aux entreprises du commerce et de la location d'engins agricoles, industriels et de chantier, a reconnu le 8 août 2026 une intrusion. Treize entreprises clientes ont ensuite confirmé une fuite liée à cette attaque, pour un volume total de 185 Go dérobés. Une intrusion, quatorze confirmations possibles.

Compter une fois par victime confirmée gonfle la série et suggère une multiplication d'attaques qui n'a pas eu lieu. Compter une fois par intrusion masque l'exposition réelle des clients, qui est justement le fait qui les concerne. Le dataset tranche en conservant les deux niveaux dans des champs distincts, incident racine et entités affectées, ce qui autorise deux comptages explicites au lieu d'un compromis silencieux.

Un compteur de fuites qui ne distingue pas l'incident racine de ses victimes en cascade mesure la propagation de l'information, pas celle de l'attaque.

Limites connues, biais du dataset et conditions de reproductibilité

Le premier biais est celui de la visibilité. Une organisation qui communique apparaît, une organisation qui notifie discrètement ses seules personnes concernées reste absente. Le dataset mesure donc la fuite confirmée publiquement, sous-ensemble de la fuite survenue, et cet écart ne se corrige pas par une pondération : il se signale. Le deuxième biais est temporel, puisqu'une confirmation intervenue en septembre pour une intrusion d'août sort du relevé d'août.

La reproductibilité tient à trois éléments publiés avec le dataset : la définition du critère de confirmation, la liste des points d'entrée consultés, et la chaîne de garde de chaque ligne. Un tiers qui applique le même critère à la même période doit retrouver le même ordre de grandeur, sans forcément retrouver la même liste exacte, et l'écart entre deux relevés devient alors interprétable au lieu d'être un simple désaccord d'opinion.

Une fois le critère posé, la difficulté redevient un problème d'outillage : détecter la première mention, suivre la revendication jusqu'à sa confirmation ou son abandon, et remonter à la source sans perdre le lien. NewsCore (www.newscore.fr) couvre en continu des millions de sources en plusieurs langues, trie les signaux par pertinence et raccourcit le délai entre la première mention d'un incident et sa qualification par une équipe de veille.

Questions fréquentes

Qu'est-ce qu'une fuite de données confirmée par la victime ?

C'est un incident pour lequel l'organisation touchée reconnaît elle-même publiquement la compromission de données, par communiqué, notification aux personnes concernées ou information de ses clients. Trois conditions sont exigées : un auteur identifiable du côté de la victime, la reconnaissance d'une compromission et non d'une simple tentative, et une date située dans la période d'observation. Une revendication d'attaquant, même détaillée, reste hors de ce périmètre et rejoint le registre des allégations à qualifier.

Combien de fuites de données françaises ont été confirmées en août 2026 ?

French Breaches recensait au 23 août 2026 une cinquantaine de fuites confirmées par la victime depuis le début du mois, après avoir relayé le 21 août cinq incidents en une matinée, susceptibles d'avoir affecté douze millions de comptes. Ce chiffre est un ordre de grandeur de relevé public, pas un dénombrement exhaustif : il dépend du critère de confirmation retenu, du traitement des incidents en cascade et de la date d'arrêt du comptage.

Comment compter une fuite qui passe par un fournisseur commun à plusieurs entreprises ?

En conservant deux champs distincts plutôt qu'un compteur unique. L'incident racine désigne l'intrusion chez le fournisseur, les entités affectées désignent les clients qui confirment une fuite. Le cas BigCloud, une intrusion reconnue le 8 août 2026 et treize entreprises clientes ayant confirmé une fuite, produit ainsi deux lectures explicites : une attaque, quatorze organisations concernées. Fusionner les deux niveaux revient à mesurer la circulation de l'information plutôt que celle de l'attaque.