Vol des données FICOBA : ce n’est pas un couac administratif, c’est une catastrophe. Voici pourquoi.

Publié le 20/02/2026 par Etienne Wery 179 vues

Le 18 février 2026, la Direction générale des finances publiques (DGFiP) a signalé dans un communiqué laconique, que des accès illégitimes avaient été constatés dans le fichier national des comptes bancaires (FICOBA), à la suite de l’usurpation des identifiants d’un agent habilité. Les données concernées portent sur environ 1,2 million de comptes et comprennent notamment…

Le 18 février 2026, la Direction générale des finances publiques (DGFiP) a signalé dans un communiqué laconique, que des accès illégitimes avaient été constatés dans le fichier national des comptes bancaires (FICOBA), à la suite de l’usurpation des identifiants d’un agent habilité. Les données concernées portent sur environ 1,2 million de comptes et comprennent notamment l’identité des titulaires, leur adresse, leur banque et leur IBAN. Présenté comme un incident rapidement maîtrisé, l’événement pourrait être perçu comme une défaillance technique isolée. Ce serait une erreur.

Ficoba ?

Le FICOBA est le “fichier des comptes bancaires” : une base de données qui recense l’ensemble des comptes ouverts en France, qu’il s’agisse de comptes bancaires, d’épargne ou assimilés. Il ne contient pas les soldes ni le détail des opérations, mais il permet d’identifier, pour chaque personne, les établissements dans lesquels des comptes sont détenus ainsi que leurs références (notamment l’IBAN).

Ce fichier est utilisé par différentes administrations, notamment à des fins fiscales, judiciaires ou de lutte contre la fraude. Il offre une vision d’ensemble des relations bancaires des particuliers et des entreprises. C’est précisément cette centralisation qui en fait un instrument efficace… et une base particulièrement sensible en cas d’accès non autorisé.

Un modus operandi qui doit inquiéter

On comprend, à la lecture du communiqué, que le vol a été possible grâce à l’utilisation d’identifiants valides, appartenant à un agent autorisé à consulter le fichier dans le cadre d’échanges entre administrations.

Traduction de ce charabia : le voleur avait la clé. Il n’a pas dû forcer la serrure, ou casser une fenêtre. Il est entré parce qu’il a réussi à mettre la main sur une clé dont il s’est tout naturellement servi pour ouvrir la porte.

Ce point est essentiel. Il montre que les dispositifs de sécurité les plus visibles et auxquels on pense en premier (qui visent à bloquer les intrusions extérieures) ne suffisent pas. La fragilité ne se situe pas seulement dans la protection technique, mais aussi dans la gestion des accès et des identités.

La clarté devra être faite : comment est-il possible qu’un identifiant valable ait pu être détourné, et surtout, quelles garanties entouraient son utilisation ?

Car en matière de sécurité des systèmes d’information, certains principes sont aujourd’hui bien établis. L’accès à des bases aussi sensibles ne devrait jamais reposer sur la seule possession d’un identifiant et d’un mot de passe. Il suppose, en principe, des mécanismes d’authentification renforcée, une limitation stricte des droits accordés, ainsi qu’une traçabilité fine des consultations effectuées. S’y ajoutent des exigences de surveillance : détection des accès inhabituels, alertes en cas de consultation massive ou anormale, et capacité à bloquer rapidement un compte compromis.

Un autre principe fondamental est celui du “moindre privilège” : un utilisateur ne doit pouvoir accéder qu’aux seules données strictement nécessaires à sa mission. Dans un environnement inter-administrations, cela implique également un cloisonnement rigoureux des accès, afin d’éviter qu’un identifiant compromis n’ouvre des droits trop larges.

La gestion des identifiants elle-même doit faire l’objet d’une vigilance particulière. Elle implique notamment des politiques de mots de passe robustes, leur renouvellement régulier, ainsi que la mise en place d’une authentification à plusieurs facteurs. À défaut, un identifiant compromis peut rester exploitable pendant une durée prolongée sans être détecté.

Enfin, la sécurité repose aussi sur des pratiques organisationnelles : formation des agents, protection des identifiants, procédures de révocation rapide en cas de doute.

L’enquête devra absolument déterminer comment il a été possible d’utiliser des identifiants valables. Il ne s’agit pas de mettre la faute sur une personne en particulier, mais d’en tirer des enseignements pour l’avenir.

Des données qui exposent très concrètement la population à un risque significatif de fraude

L’association d’un nom, d’une adresse, d’un établissement bancaire et d’un IBAN constitue une base suffisamment complète pour construire des fraudes crédibles. Le risque est important et le communiqué appelle du reste la population à se montrer vigilante.

Il est exact qu’un IBAN, à lui seul, ne permet pas de débiter un compte. Mais ce raisonnement est trompeur. La fraude actuelle ne consiste plus nécessairement à pénétrer les systèmes bancaires, mais à convaincre les personnes d’agir elles-mêmes, en leur donnant le sentiment d’être face à un interlocuteur fiable.

Dans les faits, cela peut prendre des formes très concrètes :

• Une personne peut être contactée par téléphone par un prétendu “service fraude” de sa banque. Le discours est crédible, car l’interlocuteur connaît son nom et son établissement bancaire, parfois même une partie de son IBAN. Mise en confiance, la victime accepte de transmettre un code reçu par SMS, pensant sécuriser son compte, alors qu’elle valide en réalité une opération frauduleuse.
• De la même manière, un SMS ou un courriel invitant à “vérifier un compte” gagne en efficacité lorsqu’il mentionne la bonne banque. La victime est plus encline à cliquer sur le lien proposé et à saisir ses identifiants sur un site frauduleux.
• D’autres mécanismes, plus discrets, existent également. L’utilisation d’un IBAN pour tenter de mettre en place des prélèvements de faible montant, présentés comme des abonnements ordinaires, peut passer inaperçue pendant un certain temps. Même si des possibilités de remboursement existent, elles supposent que la fraude soit détectée.

Ce qui rend la situation plus préoccupante encore, c’est que les données volées restent valables dans le temps (sauf à imaginer que toutes les personnes concernées changent de compte bancaire, ce qui peut représenter un travail colossal et engendrer d’autres conséquences : domiciliations, mandats, ordres permanents, changement des modèles de facture, perturbation de l’activité profesisonnelle, etc.). Les données volées pourront être utilisées très longtemps après leur extraction, lorsque l’attention suscitée par l’incident a diminué. Le risque est donc diffus, durable, et difficile à anticiper.

Enfin, l’ampleur de l’incident renforce l’inquiétude : avec 1,2 million de comptes concernés, il devient possible d’organiser des campagnes de fraude à grande échelle, reposant sur l’envoi massif de messages ou d’appels. Même si seule une faible proportion de personnes est trompée, le nombre total de victimes peut être élevé.

La stratégie de centralisation des données : un choix parfois justifié mais extrêmement risqué en cas de faille

En matière de données, la centralisation augmente, de façon inhérente, le risque de fraude.

L’incident FICOBA permet de bien le comprendre : quand on met beaucoup de données au même endroit, on crée une cible unique. C’est ce que l’on appelle l’effet “pot de miel”. Plutôt que de s’attaquer à des milliers de systèmes, un attaquant a tout intérêt à viser ce point central. S’il y parvient, même brièvement, il accède à une masse considérable d’informations. C’est exactement ce qui s’est produit ici.

Or, la centralisation reste souvent un réflexe naturel dans les projets publics de gestion des données : enfermer tout dans un même endroit que l’on va super-protéger, en espérant que tout se passe bien (ce qui n’est pas jamais garanti).

Prenons l’exemple récent du contrôle pour accéder aux réseaux sociaux. Les débats portent en général sur un seul sujet : est-ce que d’un point de vue social et éducatif, il est justifié d’empêcher l’accès aux réseaux sociaux avant un certain âge ? C’est oublier l’autre grand sujet : comment organiser concrètement le contrôle de l’âge sans créer une base de données centralisée qui, au nom d’un objectif qui paraît légitime, crée un autre risque tout aussi significatif ?

Autre exemple : le contrôle de l’âge pour les sites pornographiques. La question est la même, avec, en plus, la sensibilité de la donnée.

L’incident FICOBA montre que la centralisation emporte, ontologiquement, des conséquences extrêmement sérieuses. Cela ne veut pas dire que cette stratégie n’est jamais bonne ; cela signifie que lorsqu’un système repose sur une centralisation, ce doit être consciemment, en ayant exploré les alternatives et après calcul du ratio coût/bénéfice.