La fuite ne vient plus de la base de données, elle vient de la copie constituée pour la regarder
On a passé dix ans à durcir la base de données, et construit juste à côté un endroit où tous les accès se rejoignent : la copie rassemblée pour analyser. Elle détient les identifiants de tout ce qu'elle interroge, elle vit souvent chez un prestataire qui en sert des centaines, et elle tombe sans qu'un seul mot de passe soit volé. Deux organisations l'ont documenté sur elles-mêmes en 2026 : un hébergeur français, puis l'agence nationale de cybersécurité.
Deux vagues, deux histoires
L'été 2026 a enchaîné deux séquences de fuites françaises qui ne racontent pas la même chose, et c'est le passage de l'une à l'autre qui fait le sujet.
La première vise des systèmes d'information publics. L'attaquant entre avec des identifiants légitimes détournés, ceux d'un agent et d'un tiers habilité, et le rapport d'incident publié le 29 septembre écarte l'hypothèse d'une attaque sophistiquée au profit de l'exploitation de faiblesses d'identité, d'architecture et de détection.
La seconde ne vise plus le système qui détient les données, mais celui qui sert à les regarder. Une injection SQL notée 10 sur 10 dans un outil de tableaux de bord répandu, exploitable sans aucune authentification. Le détail des faits et des dates se trouve dans la chronologie sourcée.
Ce que détient la copie
Un outil d'analyse ne contient pas seulement des graphiques. Il conserve les identifiants de connexion des bases qu'il interroge, parce que c'est à cette condition qu'il peut produire un tableau de bord à trois heures du matin sans que personne tape un mot de passe.
Le cas le mieux documenté de la vague l'est parce que l'entreprise touchée a publié son propre bulletin de sécurité. Chez un hébergeur français, une instance d'analyse interne est compromise le 8 août, environ 90 000 personnes sont concernées, la CNIL est notifiée le 11 août. Et le point qui compte : le contenu des bases de production reste intact. L'exfiltration a eu lieu depuis l'entrepôt analytique.
La base a tenu. La copie a cédé.
Quand l'agence nationale de cybersécurité le constate chez elle
Le 30 septembre 2026, l'ANSSI annonce avoir été touchée par cette même vulnérabilité : 118 comptes d'un de ses laboratoires d'innovation, dont une trentaine de comptes externes, ainsi que des instances de la direction interministérielle du numérique. Les données exposées sont des statistiques d'usage, des identifiants, des adresses électroniques et des empreintes de mots de passe. Ses bases de production ne sont pas en cause. C'est son instance d'analyse qui est tombée.
L'autorité nationale de cybersécurité connaissait la vulnérabilité mieux que quiconque, puisque c'est elle qui avait ouvert l'alerte le 6 août. Ce qui donne à ce cas sa valeur de démonstration : quand une organisation dont c'est le métier constate le même schéma chez elle, le problème n'est plus un défaut de diligence. C'est la forme de l'architecture.
Pourquoi une seule instance en touche plusieurs
La copie d'analyse ne vit pas seulement chez celui qui détient les données. Elle vit souvent chez un prestataire, qui rend le même service à des centaines de clients et rassemble donc, au même endroit, ce que chacun lui confie.
En 2026, une seule instance compromise chez un prestataire de suivi de livraison a suffi pour que cinq enseignes notifient leurs clients dans la même semaine. Aucune de ces cinq entreprises n'avait été attaquée. Le point de convergence a bougé d'un cran en amont, et la portée d'une intrusion unique a été multipliée par cinq.
Ce que ça ne dit pas
Une architecture sans point de convergence ne change pas la probabilité qu'une brique logicielle tombe. Un outil vulnérable reste vulnérable, un correctif non appliqué reste non appliqué, un identifiant volé reste volé. Rien de ce qui précède ne décrit une protection contre l'intrusion.
Ce qui change, c'est ce qui est atteignable quand une brique tombe. S'il n'existe pas de copie rassemblée, il n'y a pas de copie rassemblée à exfiltrer. C'est une réduction de surface, pas une protection contre l'intrusion.
Deux précisions encore. L'analyse répartie ne supprime pas le besoin d'une sécurité classique sur chaque site, elle le déplace. Et elle ne couvre pas tous les usages : certains travaux demandent toujours un accès direct aux enregistrements, ligne à ligne.
La question que la couverture pose rarement
Les deux vagues ont été largement couvertes, incident par incident. La question en amont apparaît beaucoup plus rarement : pourquoi faut-il rassembler les données pour les analyser ?
Pour un grand nombre d'usages, il ne le faut pas. Entraîner un modèle sur des données réparties entre plusieurs sites, ou entre plusieurs organisations, peut se faire en déplaçant le calcul au lieu des données : chaque détenteur entraîne sur place, et seuls les paramètres appris circulent, chiffrés. C'est le principe de l'apprentissage fédéré, et c'est ce que construit Mesh (Mesh Universe). La page analyser sans centraliser détaille ce que cela couvre, et ce que cela ne couvre pas.
FAQ : la fuite par la couche d'analyse
Pourquoi une fuite de données peut-elle venir d'un outil d'analyse ?
Parce qu'il conserve les identifiants des bases qu'il interroge, et parce qu'il travaille le plus souvent sur une copie rassemblée pour l'analyse. Le catalogue de la CISA le décrit pour CVE-2026-72898 : un attaquant qui obtient les droits d'administrateur sur l'instance peut voler les identifiants stockés des bases connectées, lire toute donnée accessible par ces connexions, et l'exporter. La base de production peut rester intacte alors que la donnée est partie.
Qu'est-ce qu'un point de convergence des données ?
L'endroit où plusieurs sources sont réunies pour être analysées ensemble : entrepôt analytique, lac de données, instance de tableaux de bord. Il concentre à la fois les données et les accès aux systèmes dont elles proviennent. Sa valeur pour l'organisation et sa valeur pour un attaquant croissent exactement pour la même raison.
L'apprentissage fédéré aurait-il empêché ces fuites ?
Non. Une architecture sans point de convergence ne change pas la probabilité qu'une brique logicielle tombe. Ce qu'elle change, c'est ce qui est atteignable quand elle tombe : s'il n'existe pas de copie rassemblée, il n'y a pas de copie rassemblée à exfiltrer. C'est une réduction de surface, pas une protection contre l'intrusion.
Pourquoi faut-il rassembler les données pour les analyser ?
Pour beaucoup d'usages, il ne le faut pas. Entraîner un modèle sur des données réparties peut se faire en déplaçant le modèle au lieu des données : chaque détenteur entraîne sur place, seuls les paramètres appris circulent. Certains usages, comme une exploration ad hoc ligne à ligne, demandent toujours un accès direct aux enregistrements.
Un chiffrement de la base aurait-il suffi ?
Pas dans ce schéma. L'outil d'analyse se connecte avec des identifiants valides et lit des données déchiffrées, puisque c'est son travail. Un attaquant qui hérite de ces accès lit ce que l'outil lit. Le chiffrement au repos protège contre le vol du support, pas contre l'usage légitime d'une connexion volée.
Si la copie n'existe pas, elle ne fuit pas
Mesh (Mesh Universe) entraîne un modèle commun là où vivent les données. Regardons si votre cas s'y prête.