À l'été 2026, des identifiants d'agents publics usurpés ont permis d'extraire les données fiscales de 678 000 particuliers et professionnels du système d'information de la DGFiP. Ton espace impots.gouv.fr et ton mot de passe n'ont pas été touchés, mais tu dois te méfier des arnaques qui vont s'appuyer sur ces données. Et si tu développes une application, la même erreur peut exister chez toi aujourd'hui.
« Les impôts, c'est l'État. C'est forcément ultra-sécurisé. »
C'est ce qu'on pense tous. Des centaines de milliers de Français viennent d'apprendre que non.
Dans la vidéo ci-dessus, je prends les deux casquettes. D'abord comprendre comment l'attaquant s'y est pris. Ensuite reproduire le scénario sur une application de test, la sécuriser, et la faire auditer par une IA comme le ferait un hacker.
Ce qui s'est passé : la chronologie vérifiée
Voici les faits tels qu'ils ressortent des sources officielles et de la presse.
- Fin juin 2026 : première intrusion. Selon le ministère de l'Économie, les accès reposent sur « des usurpations d'identifiants d'un agent de la DGFiP et d'un tiers habilité ». Silicon.fr décrit l'usurpation d'un identifiant donnant accès à un VPN, puis l'utilisation d'un outil interne de recherche sur les dossiers des usagers.
- Fin juillet 2026 : deuxième intrusion, cette fois sur des données cadastrales.
- 12 août 2026 : un pirate se présentant sous le pseudonyme ZeroBytes revendique le vol sur un forum cybercriminel.
- 14 août 2026 : communiqué officiel. La DGFiP chiffre l'intrusion à 678 000 particuliers et professionnels, saisit la CNIL et annonce une plainte.
- À partir du 17 août 2026 : les personnes concernées sont informées par courriel ou par courrier.
Côté justice, une enquête pour extraction frauduleuse de données et association de malfaiteurs a été ouverte par le parquet de Paris et confiée à l'Office anti-cybercriminalité (Ofac). Depuis le tournage, le 4 septembre 2026, un jeune homme de 18 ans soupçonné d'appartenir à ZeroBytes a été mis en examen et placé en détention provisoire, selon le parquet cité par l'AFP.
700 000 ou 678 000 ?
Dans la vidéo, je parle de 700 000 Français : c'est l'ordre de grandeur qui circulait à ce moment-là. Le chiffre officiel est de 678 000 particuliers et professionnels. Dans sa FAQ, la DGFiP précise qu'un peu plus de 350 000 particuliers sont concernés par le vol de données sensibles.
Pour le cadastre, plusieurs médias ont évoqué plus de 2 millions de propriétaires, à partir de la revendication du pirate. Les chiffres ont varié selon les sources et les mises à jour : je ne les donne pas comme établis.
Quelles données ont fuité ?
D'après la FAQ officielle pour les particuliers :
- identifiant fiscal et état civil ;
- coordonnées postales, téléphoniques et électroniques ;
- situation fiscale : situation de famille, personnes à charge, nombre de parts, revenu fiscal de référence, taux de prélèvement à la source ;
- la liste des messages échangés avec la DGFiP via la messagerie d'impots.gouv.fr (et leur contenu pour moins de 250 contribuables, sans les pièces jointes) ;
- des données cadastrales sur des adresses et des surfaces de biens immobiliers.
Pour les entreprises, le communiqué cite aussi la raison sociale et le numéro SIREN.
Ce qui n'a pas été compromis : le site impots.gouv.fr et les espaces Finances publiques. Le mot de passe ne fait pas partie des données volées.
Le délai qui choque
Entre les premières intrusions fin juin et la revendication du 12 août, il s'est écoulé environ sept semaines. Dans la vidéo, je compte 48 jours.
Le RGPD impose de notifier une violation à la CNIL dans les 72 heures après en avoir pris connaissance. La DGFiP explique que les accès frauduleux ont été détectés et fermés dès juin et juillet, mais que le vol de données lui-même n'a été établi qu'à partir du 12 août. En clair : elle a vu les accès, pas l'extraction. C'est justement le sujet.
Mon analyse : le problème n'était pas le manque de moyens
L'État a des moyens. Et l'attaquant n'a pas cassé un coffre-fort numérique.
Un identifiant volé, un accès VPN, un outil interne. Trois petites choses, et des centaines de milliers de dossiers dans la nature.
Mon analyse, c'est que le problème est interne : ces applications n'ont visiblement pas été testées comme l'aurait fait un attaquant. Ce n'est pas une attaque ultra-sophistiquée. C'est une application interne qui laisse sortir la donnée en série sans que personne ne s'en aperçoive.
Je n'ai pas accès au code de la DGFiP. Ce qui suit n'est donc pas une reconstitution de leur système, mais une démonstration des erreurs classiques qui rendent ce type d'extraction possible.
Je reproduis l'attaque sur une application de test
J'ai développé un faux portail agent, avec des usagers fictifs (aucune vraie donnée). On se connecte avec un login et un mot de passe, puis on recherche des dossiers par identifiant.
Faille 1 : un seul facteur d'authentification
L'attaquant avait un couple identifiant et mot de passe. Sur mon portail vulnérable, ça suffit pour entrer. Pas de double authentification.
Faille 2 : un cookie modifiable à la main
Dans les outils développeur du navigateur, je trouve un cookie auth qui vaut 1 quand on est connecté. Je me déconnecte, il passe à 0. Je le remets à 1 à la main, je recharge le dossier numéro 3 : j'ai accès à la donnée.
On voit encore ce genre de mécanisme dans des applications internes anciennes, faites « à l'arrache ». Un cookie de session doit être signé ou chiffré, jamais un simple booléen.
Faille 3 : l'IDOR, le vol en série
L'identifiant du dossier est dans l'URL, et c'est un entier : 1, 2, 3, 4… Il suffit de le changer pour voir le dossier suivant. C'est ce qu'on appelle une IDOR (référence directe non sécurisée à un objet).
Avec Claude, j'écris en quelques minutes un script qui balaie tous les identifiants et exporte tout en CSV. Pas besoin du mot de passe : je récupère le cookie de session, je force la valeur à 1, et l'extraction de masse est lancée.
La version sécurisée de la même application
J'ai ensuite construit un projet équivalent, avec les protections de base :
- double authentification (simulée dans la démo) : c'est le minimum aujourd'hui ;
- cookie de session chiffré : si je le modifie ou le supprime, je suis renvoyé vers la connexion ;
- contrôle d'accès par périmètre : un agent ne voit que les dossiers qui le concernent. Si je demande le dossier 19, la réponse est « aucun dossier accessible dans votre périmètre », et le refus apparaît dans les logs ;
- API qui vérifie les droits : un
curldirect renvoie un 401 ; - rate limiting : trop de requêtes rapprochées, et on est bloqué (code 429).
Je relance mon script d'attaque sur cette version : usurpation bloquée, IDOR bloquée, injection SQL bloquée, rate limiting actif. L'attaque est tuée dans l'œuf.
Le pentest par l'IA : Kimi K3 audite les deux applications
Dernière étape : j'ai demandé à Kimi K3, via OpenCode, de réaliser un pentest complet sur les deux applications qui tournent en local.
Il a cartographié les technologies et les endpoints, testé la configuration serveur, l'injection SQL, l'authentification, le CORS. Le tout a pris 38 minutes.
| Point de contrôle | Application vulnérable | Application sécurisée |
|---|---|---|
| Authentification | Mot de passe seul | Double authentification |
| Cookie de session | Booléen modifiable | Chiffré, non modifiable |
| Accès aux dossiers | ID entier dans l'URL (IDOR) | Contrôle par périmètre, 401 hors droits |
| Extraction par script | Possible en masse | Bloquée |
| Rate limiting | Absent | Actif sur l'API, absent sur la page de login |
| Verdict de Kimi K3 | 20 failles, dont 8 critiques et 7 hautes | Correctifs fonctionnels, mais des points oubliés |
Ce qui m'a intéressé, c'est ce que l'IA a trouvé sur la version sécurisée et que je n'avais pas prévu : pas de rate limiting sur la page de connexion (des dizaines de tentatives en une seconde), des sessions sans expiration ni rotation, et un identifiant énorme qui fait planter l'application.
C'est pour ça qu'il faut faire tester ses applications, en profondeur.
Si tu développes une application : ta responsabilité
Si c'est toi qui développes, c'est toi qui es responsable du traitement de la donnée.
Et quand on « vibe code » une application, Claude ou ChatGPT ne mettent pas ces protections en place par défaut. Double authentification, contrôle d'accès, rate limiting, sessions qui expirent : ce sont des réflexes d'ingénieur et d'architecte. Je le vois systématiquement sur les projets faits par des non-techniques : ça marche, mais ça ne tient pas la route.
Autre piège : les agents de code sont bons pour ajouter du code, beaucoup moins pour maintenir l'existant. On rajoute des fonctionnalités, les fichiers grossissent, et des failles s'installent au fur et à mesure.
C'est une partie de plus en plus importante du métier : dans mes missions de consultant IA, la sécurité des données revient dès qu'un agent ou une application touche des données clients. Si tu veux faire le point sur ce que ton entreprise expose, c'est typiquement le périmètre d'un audit IA.
Que faire si tu es concerné
Ces conseils viennent de la FAQ officielle de la DGFiP et de la page d'actualité d'impots.gouv.fr.
- Pas besoin de changer ton mot de passe impots.gouv.fr : il n'a pas été volé. Tu peux le faire si tu veux, mais en te connectant toi-même.
- Le vrai message de la DGFiP ne contient aucun lien vers ton espace et ne te demande aucune information confidentielle. Tout message qui te fait cliquer est suspect.
- Méfie-toi des appels et messages trop bien renseignés. Le principal risque, c'est l'hameçonnage et les arnaques au faux conseiller rendues crédibles par tes vraies données.
- Ne communique jamais codes, mots de passe, coordonnées bancaires ou pièces d'identité en réponse à une sollicitation.
- Tape toi-même impots.gouv.fr dans ton navigateur, et vérifie qu'aucune coordonnée (adresse, RIB) n'a été modifiée.
- Garde les preuves (messages, captures d'écran, adresses des sites) si tu soupçonnes une fraude.
- Signale sur cybermalveillance.gouv.fr ou fais-toi orienter par 17Cyber. En cas de préjudice, la CNIL recommande de porter plainte (commissariat, gendarmerie, plateforme THÉSÉE ou courrier au procureur).
- Une question ? La DGFiP répond au 0809 401 401 (non surtaxé) ou via la messagerie sécurisée de ton espace.
FAQ
Combien de personnes sont concernées par le piratage de la DGFiP ?
Le chiffre officiel est de 678 000 particuliers et professionnels, dont un peu plus de 350 000 particuliers selon la FAQ de la DGFiP. Des données cadastrales ont aussi été consultées en parallèle.
Mon mot de passe impots.gouv.fr a-t-il été volé ?
Non. Selon la DGFiP, les espaces Finances publiques n'ont pas été compromis et le mot de passe ne fait pas partie des données dérobées. Le changer n'est pas nécessaire.
Comment savoir si je suis concerné ?
La DGFiP informe individuellement les personnes concernées depuis le 17 août 2026, par courriel ou par courrier. Ce message ne contient aucun lien vers ton espace fiscal.
Qu'est-ce qu'une faille IDOR ?
C'est quand une application donne accès à une ressource à partir d'un identifiant prévisible (par exemple un numéro dans l'URL) sans vérifier que l'utilisateur a le droit de la voir. Il suffit alors de changer le numéro pour récupérer les données des autres.
Comment tester la sécurité de mon application ?
Commence par les bases : double authentification, cookies signés, contrôle d'accès côté serveur, rate limiting, sessions qui expirent. Puis fais réaliser un pentest, par un professionnel ou avec un agent IA comme je le montre dans la vidéo, uniquement sur des applications qui t'appartiennent.
Conclusion
La même erreur qui a coûté des centaines de milliers de dossiers à l'État peut être dans ton application, en production, en ce moment.
La bonne nouvelle, c'est que les protections de base ne sont pas compliquées. Il faut juste les connaître, et tester comme un attaquant avant qu'un attaquant le fasse.
Pour voir la démonstration complète, abonne-toi à la chaîne YouTube @SophieneIA.
Tu veux sécuriser les outils IA ou les applications de ton entreprise ? Découvre mon accompagnement de consultant IA ou réserve un appel.