VIOLATIONS DE DONNÉES EN FRANCE

Bilan février 2026 — Ce que chaque organisation doit retenir

Par Christelle REYNO — Avocate au Barreau de Guadeloupe, Saint-Martin et Saint-Barthélemy

DPO certifiée CNIL-AFNOR • LEGALPROTECH-AVOCATS • Baie-Mahault, Guadeloupe

Ce que la loi exige, et ce que ces violations révèlent

La France traverse en ce début d’année 2026 une crise cyber sans précédent. Plus de cent incidents signalés, 60 millions de lignes de données compromises en quatre semaines, et des organismes publics parmi les premières victimes : le tableau est alarmant. Mais au-delà des chiffres, ce qui nous frappe, en notre qualité de DPO, c’est la récurrence des mêmes causes profondes — des causes que le RGPD, précisément, est conçu à prévenir.

Cet article revient sur les violations les plus marquantes de la période, en identifiant pour chacune ce qui aurait pu — et aurait dû — être fait. Il ne s’agit pas d’accabler les victimes mais de rappeler que la conformité RGPD n’est pas une contrainte administrative : c’est un système de protection dont l’efficacité dépend entièrement de la rigueur de sa mise en œuvre.

Les principes fondamentaux que ces violations ont en commun

Le RGPD pose plusieurs exigences claires que chaque responsable de traitement et sous-traitant est tenu de respecter. Les violations analysées ci-après révèlent que ces principes ont été, dans la plupart des cas, soit ignorés, soit insuffisamment appliqués :

• Article 5 — Principes relatifs au traitement
• Minimisation des données : ne collecter que ce qui est strictement nécessaire à la finalité déclarée
• Exactitude, intégrité et confidentialité : protéger les données contre tout accès non autorisé
• Limitation de la conservation : ne pas conserver les données au-delà de leur durée utile
• Article 25 — Protection des données dès la conception (Privacy by Design)
• Concevoir les systèmes en intégrant la protection des données dès la phase de développement, pas en réponse à un incident
• Article 32 — Sécurité du traitement
• Mettre en œuvre des mesures techniques et organisationnelles adaptées au niveau de risque : chiffrement, authentification forte, contrôle des accès, tests de pénétration réguliers
• Article 28 — Sous-traitants et co-responsables
• S’assurer contractuellement que les partenaires, prestataires et co-responsables offrent des garanties équivalentes de sécurité

Trois erreurs systémiques à corriger d’urgence

1. « C’est l’État, c’est national, donc c’est sécurisé » — Une présomption dangereuse

L’une des illusions les plus répandues est de considérer qu’une plateforme nationale ou interministérielle est, par nature, protégée. Les violations du FICOBA, de la DINUM, de France Travail et de l’OFB démontrent le contraire. La « nationalité » d’un prestataire ou d’une plateforme ne constitue aucune garantie de sécurité. Le RGPD ne fait aucune distinction : que le responsable de traitement soit public ou privé, français ou européen, ses obligations sont identiques. Travailler avec une plateforme de l’État ne dispense pas d’une analyse de risques, d’une clause contractuelle de sécurité, ni d’une vérification des mesures mises en place.

2. Avoir un DPO — et « vraiment l’écouter »

Plusieurs des organisations victimes disposaient d’un DPO ou de référents RGPD. Dans certains cas documentés — notamment France Travail — les analyses d’impact (AIPD) avaient correctement identifié les risques et préconisé des mesures correctives. Il semble que mesures n’ont pas toujours été déployées. La CNIL le retient d’ailleurs comme circonstance aggravante.

Un DPO n’est pas une fonction d’affichage. Son rôle est d’alerter, de conseiller et d’accompagner. Lorsque ses recommandations sont ignorées par la direction ou les services informatiques, l’organisation s’expose non seulement à une violation, mais à une sanction aggravée. Nommer un DPO ne suffit pas : il faut lui donner les moyens d’agir et s’engager à suivre ses préconisations.

3. Chaque institution doit disposer d’un Responsable de la Sécurité des Systèmes d’Information (RSSI) en interne

Les violations de cette période mettent en lumière un angle mort critique : l’absence, dans de nombreuses institutions publiques et entreprises traitant des données sensibles, d’un RSSI dédié disposant d’une autorité réelle et d’un budget propre. La cybersécurité ne peut pas être gérée comme une fonction périphérique confiée à un prestataire externe ou absorbée par une DSI déjà surchargée.

Un RSSI interne permet la détection précoce des comportements anormaux, la réponse rapide aux incidents, la mise en œuvre continue des politiques de sécurité et le dialogue permanent avec le DPO. Cette fonction n’est plus optionnelle — elle est stratégique.

Ci-après une analyse de certaines violations du mois de février 2026.

CEGEDIM SANTÉ — La trahison du champ commentaire

  Source : Ministère de la Santé confirme — franceinfo.fr

  Source : Décision CNIL 2024 — cnil.fr

Les faits

Révélée le 26 février 2026 lors du journal de 20 heures de France 2, cette violation est l’une des plus graves jamais documentées dans le secteur de la santé en France. Via une intrusion dans le logiciel MLM (MonLogicielMedical.com) utilisé par 3 800 médecins, le groupe de cybercriminels dumpsec aurait exfiltré les données de millions de patients.

Les données administratives exposées comprennent noms, prénoms, dates de naissance, adresses postales et électroniques, numéros de téléphone. Pour plusieurs milliers de patients, ce sont les annotations libres saisies par les médecins dans les champs de commentaires qui ont été exfiltrées : des informations d’une intimité extrême.

Le point central : les zones de commentaires libres

Ce qui fait la gravité particulière de cette violation, ce n’est pas tant le volume des données administratives exposées — certes considérable — que le contenu des champs de commentaires libres. Ces zones ont été utilisées par certains médecins pour consigner des informations d’une extrême sensibilité :

• Statut sérologique (VIH notamment)
• Orientation sexuelle
• Antécédents de violences sexuelles, inceste, viol
• Antécédents judiciaires
• Situations familiales intimes
• Données politiques, religieuses

Des personnalités politiques de premier plan figureraient dans cette base. Ce champ « commentaire administratif », laissé en texte libre à la discrétion de chaque praticien, est devenu le vecteur d’une violation d’une ampleur et d’une intimité inédites.

Points de vigilance et recommandations

Mesure essentielle — Organisationnelle et comportementale

La mesure la plus déterminante n’est pas technique : elle est comportementale. Il ne faut jamais saisir de données sensibles — au sens de l’article 9 du RGPD — dans des champs de texte libre.

Cette règle, qui devrait être enseignée dès la formation initiale des professionnels de santé et rappelée dans toute politique d’utilisation des logiciels médicaux, aurait suffi à neutraliser l’essentiel du préjudice. Un logiciel peut être compromis : ce qui n’y est pas saisi ne peut pas être volé.

Les champs commentaires sont des espaces fonctionnels, pas des dossiers médicaux. Ils ne bénéficient souvent d’aucun chiffrement différencié, d’aucune restriction d’accès spécifique, et d’aucun contrôle de contenu. Y inscrire des données relatives à la santé, à la sexualité ou à la religion revient donc à une violation du RGPD.

Mesures techniques complémentaires pour l’éditeur de logiciel

• Chiffrement des champs libres au repos : les annotations texte doivent être chiffrées individuellement, distinctement des données administratives structurées
• Authentification multifacteur (MFA) obligatoire pour tous les accès médecins
• Journalisation et détection d’anomalies : des requêtes anormales sur des comptes médecins peuvent déclencher une alerte immédiate

Il convient de rappeler que le 5 septembre 2024, la CNIL avait prononcé une amende de 800 000 euros à l’encontre de la société pour avoir traité des données de santé sans autorisation, dans le cadre d’un « observatoire médical ». En l’occurrence les données auraient dû être anonymisées et non pseudynomisées.

CAF / DINUM — Les données RSA exposées par la chaîne inter-administrations

  Source : FrenchBreaches — Analyse de l’incident CAF/DINUM

  Source : Déclaration officielle CNAF — caf.fr

Les faits

Révélée le 25 février 2026, cette violation concerne les bénéficiaires du Revenu de Solidarité Active (RSA). L’intrusion ne s’est pas produite dans les systèmes de la CNAF elle-même, mais dans ceux de la DINUM — la Direction interministérielle du Numérique — qui constitue le canal de transmission des données entre la CAF et les conseils départementaux dans le cadre de l’instruction du RSA.

Les données compromises sont particulièrement sensibles : matricule allocataire, numéro de sécurité sociale (NIR), noms et prénoms, coordonnées de contact, dates liées aux droits et devoirs. Aucune donnée bancaire ni mot de passe n’a été compromis, mais la combinaison identité + NIR + coordonnées constitue une base suffisante pour des campagnes de phishing ultra-ciblées et des tentatives d’usurpation d’identité.

Points de vigilance et recommandations

Un constat préalable : les collectivités réceptrices n’ont pas le choix

Il faut le dire clairement : un conseil départemental qui reçoit les données RSA via la DINUM n’a pas d’alternative. La DINUM est l’infrastructure mandatée par l’État — personne ne choisit de l’utiliser, on s’y raccorde parce que c’est ainsi que le système est conçu. Recommander à une collectivité de ‘préférer une plateforme plus sécurisée’ serait aussi peu réaliste que de lui conseiller de choisir un autre État.

Le vrai problème révélé par cet incident est que la chaîne interministérielle elle-même n’était pas suffisamment sécurisée. C’est une responsabilité qui incombe à l’État — à la DINUM et aux ministères concernés — et non aux organismes récepteurs des données. Cela dit, certaines obligations s’imposent à tous les acteurs de la chaîne, quelle que soit leur position.

Ce qui relève de la DINUM et de l’État — mesures techniques

• Chiffrement de bout en bout des flux inter-administrations : les données en transit entre la DINUM et les conseils départementaux auraient dû être systématiquement chiffrées — c’est une obligation de sécurité à la charge de l’opérateur de la chaîne
• Cloisonnement des environnements de transmission : un accès compromis à un nœud de transit ne devrait pas permettre l’extraction de données en clair
• Authentification forte (MFA) obligatoire sur tous les accès aux canaux interministériels — mesure relevant de la gouvernance de la DINUM
• Monitoring des flux anormaux en temps réel : un volume inhabituellement élevé de requêtes ou d’exports doit déclencher une alerte automatique

Ce que chaque maillon de la chaîne peut malgré tout maîtriser

• Cartographier précisément les flux reçus et transmis : même sans contrôler la plateforme, chaque organisme doit savoir quelles données il reçoit, de qui, et ce qu’il en fait — c’est une obligation du registre des traitements
• Ne jamais retransmettre de données issues de la chaîne DINUM par messagerie électronique standard : un email est un canal non sécurisé — même en interne, même au sein de l’administration
• Interpeller formellement l’État sur les garanties de sécurité de la chaîne : une collectivité réceptrice peut et doit demander, dans le cadre de la convention qui la lie à la CAF ou à la DINUM, une documentation sur les mesures de sécurité appliquées

Ce que l’ANSSI impose — pour mémoire

Pour les organisations qui ont la main sur le choix de leur plateforme d’échange — hors chaîne interministérielle imposée — les exigences minimales de sécurité à vérifier sont les suivantes :

• Chiffrement de bout en bout des données en transit et au repos
• Authentification à double facteur pour tous les utilisateurs
• Traçabilité complète des accès : qui, quoi, quand, depuis où
• Isolation des environnements par niveau de sensibilité des données
• Pour les données particulièrement sensibles : hébergement sur infrastructure qualifiée SecNumCloud (ANSSI)
• Contrat de sous-traitance conforme à l’article 28 RGPD avec l’opérateur de la plateforme
• Tests de pénétration annuels menés par un prestataire qualifié

Ces critères s’appliquent aux plateformes privées comme aux outils numériques de l’État. La qualification publique d’une infrastructure ne vaut pas garantie de conformité — cet incident le démontre.

FICOBA / DGFiP — Le fichier bancaire national compromis

  Source : IT Social — DGFiP confirme l’exfiltration FICOBA

Les faits

Le 18 février 2026, la Direction Générale des Finances Publiques (DGFiP) a révélé qu’un acteur malveillant avait accédé illégitimement au FICOBA — le Fichier national des comptes bancaires — en usurpant les identifiants d’un fonctionnaire disposant d’accès inter-ministériels. L’intrusion, active depuis fin janvier 2026, a permis la consultation et l’extraction de données portant sur 1,2 million de comptes bancaires, incluant coordonnées bancaires complètes (RIB et IBAN), identité du titulaire, adresse postale et, dans certains cas, identifiant fiscal.

Le FICOBA est l’un des fichiers administratifs les plus sensibles de l’État : il recense l’intégralité des comptes ouverts en France. Un IBAN seul ne permet pas un débit direct, mais associé à des données d’identité complètes, il constitue une base redoutable pour des fraudes par virement, du phishing bancaire personnalisé ou des usurpations d’identité documentaires.

La CNIL a été notifiée, une plainte a été déposée et l’ANSSI a été mobilisée.

Point de vigilance et recommandations

Mesures techniques

• Authentification multifacteur (MFA) obligatoire : tout accès à un fichier d’une telle sensibilité doit être protégé par un second facteur d’authentification — un mot de passe seul ne suffit pas
• Surveillance comportementale en temps réel : des outils de détection des anomalies (volumes d’accès inhabituel, plages horaires atypiques, export massif de données) auraient dû déclencher une alerte bien avant que l’intrusion n’atteigne 1,2 million de comptes
• Chiffrement des données extraites : même en cas d’accès illégitime, des données chiffrées à la source sont inexploitables sans la clé

Mesures organisationnelles

• Principe du moindre privilège : un fonctionnaire ne devrait accéder qu’aux données strictement nécessaires à ses missions — un accès large et permanent au FICOBA ne devrait jamais être accordé sans justification opérationnelle documentée
• Revue régulière des droits d’accès : les comptes inter-ministériels peu utilisés sont des cibles privilégiées ; une revue trimestrielle des habilitations actives permettrait de détecter et révoquer les accès dormants ou surdimensionnés
• Politique de séparation des tâches : aucun agent ne devrait disposer seul de la capacité d’accéder et d’extraire massivement des données d’un fichier aussi sensible
• Exercices de réponse aux incidents : simuler régulièrement les scénarios d’usurpation d’identifiants pour tester la détection et la réaction des équipes

IDMERIT — La fuite KYC qui expose 53 millions de Français

  Source : Futura Sciences — IDMerit : 53 millions de Français concernés

Les faits

Découverte par Cybernews, cette fuite d’ampleur mondiale est particulièrement préoccupante pour la France. La base de données d’un téraoctet appartenant à IDMerit, société spécialisée dans les solutions KYC (Know Your Customer — vérification d’identité), expose un milliard d’enregistrements sensibles dont des noms, adresses, dates de naissance, numéros d’identification nationaux, numéros de téléphone et adresses électroniques.

La France figure parmi les pays les plus touchés avec 53 millions d’enregistrements. Ces données sont utilisées par les entreprises pour vérifier l’identité de leurs clients dans les secteurs bancaire, fintech, assurance, santé et douane. L’ironie est cruelle : une plateforme conçue pour prévenir la fraude devient elle-même le vecteur d’une fraude potentielle à grande échelle.

Points de vigilance et recommandations

Ce que cet incident révèle avant tout : un risque systémique

Avant d’énoncer des recommandations, il faut poser une question que beaucoup évitent : a-t-on réellement le choix de son prestataire KYC ?

La réponse honnête est : souvent non. Le marché de la vérification d’identité est dominé par une poignée d’acteurs mondiaux et quelques autres. Dans de nombreux cas, le prestataire n’est pas librement choisi par l’entreprise : il est imposé par la banque partenaire, intégré dans un processeur de paiement (Stripe, Adyen…) ou embarqué dans un SaaS métier. L’organisation cliente peut même ne pas savoir qu’IDMerit figure quelque part dans sa chaîne de traitement.

Cette concentration du marché crée une dépendance massive à des acteurs dont personne — ni les clients directs, ni les régulateurs nationaux — ne contrôle réellement la sécurité. Ce n’est donc pas tant un problème de responsable de traitement individuel qu’un problème de structure sectorielle. La fuite IDMerit est un révélateur : quand un seul acteur agrège les identités de 53 millions de Français, une seule brèche suffit à exposer potentiellement l’ensemble des adultes d’un pays.

Ce qui relève du régulateur et du législateur

• Renforcer les obligations de sécurité imposées aux prestataires KYC dans les secteurs réglementés (banque, assurance, santé) via les autorités sectorielles — ACPR, AMF — en complément du RGPD
• Imposer aux plateformes KYC opérant sur le marché européen des audits de sécurité indépendants réguliers dont les résultats seraient communiqués aux autorités de contrôle

Ce que le prestataire KYC doit garantir — mesures techniques

• Contrôle strict des accès à la base de données : une base agrégant les identités nationales de milliards de personnes ne doit jamais être accessible sans segmentation réseau robuste, liste blanche d’adresses IP autorisées et authentification forte
• Chiffrement différencié par catégorie de données : numéros d’identification nationaux et données de passeport méritent un niveau de protection supérieur aux coordonnées de contact
• Détection et coupure automatique en cas d’accès ou d’extraction de masse : un comportement anormal sur une base de cette taille devrait déclencher une alerte et une interruption immédiates
• Tests de pénétration réguliers et rigoureux, menés par des prestataires indépendants qualifiés

Ce que les responsables de traitement peuvent malgré tout maîtriser

• Cartographier précisément les données transmises dans chaque chaîne KYC : même sans contrôler le prestataire, on contrôle ce qu’on lui envoie — ne transmettre que les données strictement nécessaires à la vérification
• Identifier si un acteur comme IDMerit apparaît comme sous-traitant de second rang chez son prestataire principal et le faire figurer dans le registre des activités de traitement — c’est une obligation RGPD, pas une option
• S’assurer a minima que le contrat avec le prestataire KYC direct contient une obligation de notification en cas de violation, même si le droit d’audit reste théorique face aux grands acteurs
• Préparer un plan de gestion de crise anticipant la brèche chez un prestataire tiers : lorsqu’on n’a pas le choix du prestataire, on peut au moins avoir le choix de sa réponse

CNRS — Les données d’anciens agents dans la nature

  Source : Communiqué officiel du CNRS — cnrs.fr

  Source : KultureGeek — Analyse détaillée de la violation

Les faits

Le 16 février 2026, le CNRS a annoncé avoir identifié des téléchargements non autorisés de fichiers contenant des données personnelles et professionnelles de personnes rémunérées par l’organisme avant le 1er janvier 2007. Les données exposées sont particulièrement sensibles : noms, prénoms, dates de naissance, adresses postales, numéros de sécurité sociale et relevés d’identité bancaire (RIB).

Le serveur compromis a été immédiatement isolé et arrêté. La CNIL et l’ANSSI ont été notifiées, et une plainte a été déposée auprès du parquet de Paris. L’incident ne s’est pas propagé au reste des infrastructures. Ce qui interpelle avant tout : pourquoi des données parfois vieilles de près de vingt ans étaient-elles encore accessibles sur un serveur connecté ?

Point de vigilance et recommandations

Mesures techniques

• Séparation stricte des environnements actifs et archives : les données d’anciens personnels n’ont aucune raison de résider dans les mêmes systèmes connectés que les données des agents en poste — elles doivent être stockées dans des environnements hors ligne ou strictement cloisonnés
• Chiffrement des archives RH au repos : les fichiers conservés à des fins légales doivent être chiffrés, rendant leur exfiltration inexploitable sans la clé de déchiffrement
• Contrôle et traçabilité des accès aux données historiques : tout accès à des archives doit être nominatif, justifié et journalisé, avec alerte automatique en cas de comportement anormal

Mesures organisationnelles

• Politique de conservation et de purge documentée et effectivement appliquée : chaque catégorie de données RH doit disposer d’une durée de conservation définie, connue des équipes, et mise en œuvre — les données d’anciens agents ne peuvent être conservées indéfiniment
• Registre des activités de traitement à jour : la cartographie des données RH historiques doit y figurer avec les durées de conservation associées et faire l’objet d’une revue annuelle
• Revue périodique des serveurs et bases de données : identifier régulièrement les données résiduelles, oubliées ou orphelines qui continuent d’exister sans justification opérationnelle ou légale
• Sensibilisation des équipes RH et informatiques : une archive n’est pas moins exposée qu’une base active — sa protection mérite le même niveau d’exigence

CONCLUSION — La conformité RGPD n’est pas une option

Les violations analysées dans cet article ne relèvent pas de l’inéluctable. Elles sont, pour la grande majorité, la conséquence de manquements prévisibles, documentés et évitables. Authentification insuffisante, champs libres utilisés pour y inscrire des informations sensibles, flux inter-administrations non sécurisés, archivages de données sans durée limitée, sous-traitants insuffisamment vérifiés : ces failles reviennent comme un leitmotiv.

Le RGPD n’impose pas la perfection. Il impose la proportionnalité : des mesures adaptées au niveau de risque. Pour les organisations qui traitent des données de santé, financières ou relatives à des populations vulnérables — comme les bénéficiaires du RSA — ce niveau de risque est élevé, et les mesures doivent l’être en conséquence.

La France paie aujourd’hui le prix d’années d’investissements insuffisants dans la cybersécurité et la conformité. La CNIL intensifie ses contrôles et ses sanctions. Les victimes commencent à exercer leurs droits en justice. Les organisations qui n’auront pas agi à temps s’exposent à un triple risque : financier, réputationnel et pénal.

Il est encore temps d’agir…