Introduction
Le 18 février 2026, la DGFiP (Direction générale des Finances publiques) a confirmé des accès illégitimes au FICOBA (Fichier national des comptes bancaires et assimilés). L’élément marquant tient autant à l’ampleur : environ 1,2 million de comptes concernés qu’au scénario : usurpation d’identifiants d’un agent habilité dans un contexte inter-ministériel, permettant la consultation et potentiellement l’extraction de données à caractère personnel.
Pour les organisations (public/privé), cet incident est une étude de cas très claire : la compromission d’un identifiant valide peut suffire à contourner de nombreux contrôles, si l’IAM, la journalisation et la détection d’anomalies ne sont pas dimensionnées au niveau du risque.
→ Un compte légitime peut devenir un “super-pouvoir” si son périmètre couvre une base sensible.
→ L’enjeu se déplace : vérifier l’autorisation ne suffit plus, il faut valider la cohérence d’usage (usage attendu vs usage anormal).
→ La prévention passe par MFA, revues d’habilitations, PAM, logs exploitables et contrôles anti-exfiltration.
1) Éléments factuels confirmés
Selon les informations officielles, à compter de fin janvier 2026, un acteur malveillant a usurpé les identifiants d’un fonctionnaire disposant d’accès dans le cadre de l’échange d’information entre ministères, puis a consulté une partie du FICOBA. Les données susceptibles d’avoir été consultées/extraites incluent notamment :
● Coordonnées bancaires (RIB / IBAN)
● Identité du titulaire
● Adresse
● Et, dans certains cas, l’identifiant fiscal
Dès détection, des restrictions immédiates d’accès ont été mises en œuvre pour stopper l’attaque, limiter l’ampleur et prévenir toute nouvelle consultation. Les usagers concernés doivent être informés individuellement. La DGFiP indique également une mobilisation avec le HFDS et l’ANSSI, une notification à la CNIL et un dépôt de plainte.
2) FICOBA : de quoi parle-t-on exactement ?
Le FICOBA recense les comptes bancaires et assimilés existant sur le territoire national : il contient des données d’identification (titulaire) et des éléments d’identification du compte.
Point crucial : les données issues de FICOBA ne permettent pas d’accéder aux soldes et ne suffisent pas à réaliser directement des opérations bancaires, mais elles restent à haut risque car elles renforcent fortement des scénarios de fraude et d’ingénierie sociale.
|Pourquoi ces données restent à haut risque ? Un IBAN + identité + adresse, c’est un kit de crédibilité : de quoi alimenter des campagnes de phishing/vishing ciblées, des fraudes aux prélèvements, ou des tentatives d’usurpation auprès d’acteurs tiers (fournisseurs, opérateurs, services clients).
3) Risques opérationnels : exploitation de l’IBAN et des données d’identité
Même sans transactions, IBAN + données personnelles ouvrent plusieurs scénarios réalistes.
a) Prélèvements SEPA frauduleux / abonnements indus
La CNIL rappelle qu’un IBAN peut, dans certains cas, être utilisé pour mettre en place des prélèvements indus ou détourner un mandat, et recommande des réflexes de base : surveillance des opérations, vigilance sur les mandats, réaction rapide en cas d’anomalie.
En France, il existe des démarches de contestation et de remboursement selon la situation (autorisé contesté vs non autorisé), avec des délais qui varient selon le cas.
b) Phishing / vishing ultra crédible
L’administration fiscale a explicitement alerté sur la circulation de tentatives d’escroquerie par email/SMS et rappelle qu’elle ne demande pas identifiants ou données bancaires par message : en cas de doute, il faut passer par les canaux officiels.
4) Retour d’expérience (REX) : mesures de prévention et de détection
4.1. Le point central : la défense contre la compromission d’identifiants
Cet incident met en évidence une réalité opérationnelle : un compte peut devenir un compte à privilèges par son périmètre de données.
Contrôles structurants à renforcer :
● MFA sur les accès sensibles, y compris pour les comptes non administrateurs. Le CERT-FR recommande la généralisation du MFA comme mesure efficace contre l’usurpation de compte.
● Hygiène d’authentification : durcissement des politiques, protection anti-bruteforce, gouvernance des secrets, cohérence entre le niveau de risque et le niveau d’authentification requis.
● Revue régulière des habilitations : application du moindre privilège, séparation des rôles, processus Joiner Mover Leaver, en priorité sur les accès transverses inter-entités et inter-systèmes.
● PAM et contrôles renforcés dès qu’un compte donne accès à une base de données à forte valeur, même s’il ne dispose pas de privilèges administrateur.
4.2. Détection : contrôle de cohérence d’usage et détection d’anomalies :
Avec un identifiant légitime, le contrôle d’accès ne suffit plus ; il faut évaluer la cohérence d’usage.
● Journalisation exploitable : qui, quoi, quand, depuis où, combien de consultations/exports.
● Alertes volumétriques : consultation massive, exports, horaires atypiques, nouveaux terminaux, changements de pattern.
● Surveillance renforcée des comptes à risque (accès à référentiels sensibles) au même titre que les comptes à privilèges.
4.3. Protection des données : réduction du risque d’exfiltration malgré un accès autorisé :
● DLP / contrôle des exports : bloquer, alerter, filigraner, limiter les extractions et formats.
● Cloisonnement / segmentation des flux, particulièrement sur les passerelles et usages inter-entités.
● Minimisation : champs strictement nécessaires, masquage lorsque possible, limitation du “bulk access”.
Conclusion
L’incident FICOBA rappelle une règle simple : un identifiant volé peut suffire quand l’organisation n’a pas cadré finement les habilitations, instrumenté la traçabilité au bon niveau et mis en place une détection d’anomalies capable de repérer l’usage non attendu. L’absence d’information sur le solde ne réduit pas significativement le risque : l’association de données d’identité et de coordonnées bancaires demeure fortement valorisable dans des schémas de fraude et d’usurpation.
