Fuites de données à la DGFIP et ailleurs : pourquoi la donnée doit devenir l'actif le plus précieux de l'État

Un défaut de conception, pas un piratage sophistiqué

Fin juin 2026, un attaquant s'est introduit dans le système d'information de la DGFIP en usurpant l'identifiant d'un agent sur un VPN normalement réservé au personnel du fisc, ce qui lui a permis d'interroger un outil de recherche interne sur les particuliers et les professionnels avant que l'accès ne soit coupé pendant l'exfiltration. Fin juillet 2026, une seconde intrusion a visé le serveur professionnel de données cadastrales (SPDC), cette fois en contournant l'authentification à plusieurs facteurs. L'ampleur du vol n'a été révélée que le 12 août, quand le groupe ZeroBytes a mis en vente sur un forum cybercriminel un extrait de 678 438 lignes de données : la DGFIP avait bien détecté ces comptes compromis dès juin et juillet, sans identifier à l'époque qu'un vol de données avait eu lieu. Environ 678 000 particuliers et professionnels ont vu leur état civil, leurs coordonnées, leur situation familiale, leurs revenus fiscaux et l'historique de leurs démarches administratives exposés ; les données cadastrales d'environ deux millions de propriétaires ont également fuité. Les espaces personnels des usagers sur impots.gouv.fr, avec leurs identifiants et mots de passe, n'ont en revanche pas été touchés : seuls des outils internes réservés aux agents et à des tiers habilités ont été compromis. Ce n'est pas une attaque informatique inédite exploitant une faille inconnue : c'est un identifiant usurpé et un contournement de MFA, deux défaillances qu'une conception rigoureuse de la gestion des accès est censée rendre difficiles à exploiter, et une compromission détectée sans être investiguée jusqu'au bout pendant plusieurs semaines.

Ce n'est pas un cas isolé. En mars 2024, une intrusion chez France Travail a exposé les données de plusieurs dizaines de millions de personnes inscrites comme demandeurs d'emploi au cours des vingt dernières années — identité, coordonnées, situation, parfois numéro de sécurité sociale. D'autres épisodes touchant des organismes publics ou parapublics (ANTS, Assurance Maladie via des tiers comme Almerys ou Viamedis) s'ajoutent à la liste ; notre article sur les fuites ANTS, Almerys et Cegedim en détaille trois. Le point commun de ces épisodes n'est pas la sophistication de l'attaquant : c'est que la donnée, une fois collectée, a été moins protégée qu'elle n'aurait dû l'être dès sa conception.

La donnée administrative traitée comme un sous-produit

Une administration collecte des données parce que sa mission l'exige : liquider l'impôt, verser une allocation, délivrer un titre. La donnée y est souvent perçue comme un sous-produit de la mission, pas comme l'actif qu'elle protège. Un établissement bancaire, lui, sait que la moindre fuite de données clients entraîne un coût de réputation et de confiance immédiat et mesurable ; cette pression de marché n'existe pas de la même façon pour un service public, dont les usagers ne peuvent pas « changer de fournisseur ».

Cette asymétrie n'excuse rien : elle explique en partie pourquoi la sécurité arrive après la fonctionnalité dans l'ordre des priorités budgétaires et calendaires de nombreux projets numériques publics, alors que la donnée qui y circule — identité, revenus, santé, situation familiale — est souvent plus sensible que celle que traite une entreprise privée classique. Traiter cette donnée comme un actif suppose d'inverser cet ordre : la sécuriser dès la conception, pas la sécuriser une fois l'incident survenu.

Ce que « protection des données dès la conception » veut dire concrètement

Le RGPD ne se limite pas à imposer un registre des traitements et un délégué à la protection des données. Son article 25 impose la protection des données dès la conception et par défaut (« privacy and security by design and by default ») : les mesures techniques et organisationnelles adaptées doivent être intégrées au moment de la définition des moyens du traitement, pas ajoutées après coup, et les paramètres par défaut doivent limiter le traitement au strict nécessaire.

L'intrusion à la DGFIP de l'été 2026 est, à ce titre, une illustration presque pédagogique du principe. Segmenter les accès des agents et des tiers habilités, imposer une authentification à plusieurs facteurs réellement infranchissable, et pousser une investigation jusqu'à son terme dès qu'un compte est repéré comme suspect ne sont pas des fonctionnalités de sécurité optionnelles ajoutées en fin de projet : ce sont des règles de conception qui doivent être posées avant la première ligne de code, au même titre que l'authentification elle-même. Quand un identifiant usurpé et un contournement de MFA passent plusieurs semaines sans qu'une investigation ne remonte jusqu'à l'exfiltration, c'est souvent le signe que la sécurité a été traitée comme une case à cocher en fin de recette plutôt que comme une contrainte de conception dès le cahier des charges.

Le volet juridique : une responsabilité qui ne s'efface pas devant la mission de service public

Le principe de responsabilité (article 5.2 du RGPD) place la charge de la preuve sur le responsable de traitement : c'est à lui de démonstrer qu'il a pris les mesures adéquates, pas à la personne concernée de prouver une négligence. L'article 32 impose une sécurité du traitement proportionnée au risque, et les articles 33 et 34 imposent une notification à la CNIL dans les 72 heures, puis aux personnes concernées si le risque est élevé — des obligations qui s'appliquent à une administration exactement comme à une entreprise.

La CNIL peut sanctionner un organisme public en cas de manquement, mais le régime de sanction applicable aux acteurs publics reste, en pratique, nettement moins dissuasif que celui qui s'applique aux entreprises privées, pour lesquelles l'amende peut atteindre 4 % du chiffre d'affaires mondial. Cet écart affaiblit mécaniquement l'effet incitatif de la sanction pour le secteur public : c'est un argument de plus pour ne pas attendre la menace financière pour agir, et pour s'appuyer sur une obligation réglementaire plus large — beaucoup d'opérateurs publics ou assimilés à des services essentiels relèvent par ailleurs de NIS2, qui impose ses propres exigences de sécurité et de notification d'incident indépendamment du RGPD.

Traiter la donnée comme un actif : ce que cela change dans l'organisation

Gouverner la donnée comme un actif de l'État plutôt que comme une information administrative suppose des choix concrets, avant tout projet numérique public :

• Un registre des traitements vivant, mis à jour à chaque évolution de service, et pas seulement audité une fois par an pour la forme.
• Des revues de sécurité au moment de la conception de tout nouveau service ou de toute évolution majeure — pas uniquement un audit de sécurité juste avant la mise en production, trop tardif pour changer une architecture d'accès mal pensée.
• Une détection d'anomalies suivie d'une investigation complète, pour qu'un identifiant ou un accès signalé comme suspect déclenche une recherche systématique d'exfiltration, plutôt qu'une simple coupure d'accès sans vérification de ce qui a pu être consulté ou copié avant la coupure.
• Une formation continue des équipes techniques et des porteurs de projet aux réflexes de sécurité et de protection des données, pour que le principe « par conception » devienne un réflexe de métier plutôt qu'une case du cahier des charges relue une fois.

Ce qu'il faut retenir

Les fuites de données qui touchent l'administration ne sont pas des anomalies ponctuelles : elles sont le symptôme d'une donnée encore trop souvent gouvernée comme un sous-produit de la mission plutôt que comme l'actif qu'elle représente réellement pour les personnes concernées. La protection des données dès la conception, obligation juridique depuis 2018, offre le cadre pour inverser cette logique — à condition de la traiter comme un principe de gouvernance porté au plus haut niveau d'un projet, et non comme une case cochée après l'incident.