Dette technique des systèmes publics : le diagnostic posé par un syndicat après la fuite du fisc

Après la compromission des systèmes de la Direction générale des Finances publiques, le débat public s'est d'abord porté sur le volume de données exposées. Une organisation syndicale a déplacé la question ailleurs, sur l'état des systèmes eux-mêmes. Sud Ouest rapporte que le syndicat Solidaires Finances publiques désigne la dette technique de la DGFiP, c'est-à-dire l'ancienneté de ses systèmes d'information et de ses modèles de sécurité, comme cause principale des fuites.

Ce déplacement est important pour qui fait de la veille. Un incident attribué à une attaque sophistiquée relève de l'aléa et se traite par la réponse. Un incident attribué à une vétusté connue relève de l'arbitrage budgétaire et se traite par la programmation pluriannuelle. Les deux lectures n'appellent pas les mêmes sources, ni les mêmes interlocuteurs, ni le même horizon de suivi.

Cet article précise ce que recouvre la notion de dette technique quand elle s'applique à un système d'information public, ce que le diagnostic syndical apporte de vérifiable, et comment transformer ce type de constat en objet de surveillance concret pour une organisation privée qui dépend des mêmes briques technologiques.

Ce que le syndicat met exactement en cause dans les systèmes de la DGFiP

Sud Ouest rapporte que Solidaires Finances publiques pointe la vétusté des systèmes et met en avant deux composantes distinctes de cette vétusté : l'ancienneté des systèmes d'information proprement dits et l'ancienneté des modèles de sécurité qui les protègent. La distinction mérite d'être soulignée, car elle sépare deux problèmes qui ne se corrigent pas de la même façon et qui n'ont pas le même coût.

L'ancienneté d'un système d'information désigne un patrimoine applicatif construit par strates, où des composants conçus pour des usages internes se retrouvent exposés à des interfaces publiques auxquelles ils n'étaient pas destinés. L'ancienneté d'un modèle de sécurité désigne autre chose : une architecture de confiance fondée sur la protection du périmètre, où l'accès validé une fois vaut autorisation durable à l'intérieur. Un système récent peut porter un modèle ancien, et l'inverse arrive aussi.

Sud Ouest précise que cette ancienneté avait déjà été critiquée par la Cour des comptes et l'Inspection générale des Finances. C'est l'élément le plus lourd du diagnostic, et pas seulement pour la DGFiP. Il transforme un incident en alerte non suivie d'effet, c'est-à-dire en défaut de traitement d'un risque documenté par des corps de contrôle. Cette qualification change la nature des questions que poseront les instances de contrôle et les juridictions saisies.

Dette technique : une notion à délimiter avant de l'employer

La dette technique n'est pas un synonyme de vieillissement. Elle désigne l'écart accumulé entre l'état d'un système et l'état qu'il devrait avoir pour rester sûr et modifiable à coût raisonnable, écart né de choix de court terme répétés. Comme une dette financière, elle porte intérêt : chaque année sans remboursement rend la correction plus coûteuse, parce que les compétences se raréfient, que la documentation se perd et que les dépendances se multiplient.

Quatre marqueurs la rendent observable. La présence de composants dont l'éditeur a cessé le support, la dépendance à des langages ou à des environnements pour lesquels le recrutement est difficile, l'absence de tests automatisés permettant de modifier sans régression, et l'existence de contournements documentés que plus personne n'ose retirer. Aucun de ces marqueurs ne cause à lui seul une compromission, mais leur cumul allonge le délai entre la publication d'un correctif et son application effective.

Il faut se garder d'un usage trop commode de la notion. Attribuer une intrusion à la dette technique ne dit rien du vecteur employé ni de la chaîne d'exploitation. C'est une explication de contexte, qui décrit pourquoi une organisation était moins capable de résister et de détecter, pas une description de ce qui s'est passé. Un rapport de veille rigoureux tient ces deux niveaux séparés et n'utilise pas le premier pour combler l'absence du second.

Ce que les données exposées disent de l'architecture

La nature des informations sorties renseigne sur l'endroit d'où elles sont sorties. The Star écrit que l'attaque a exposé les données personnelles de 350 000 particuliers et de 250 000 entreprises, et que les données compromises comprennent les revenus imposables, les taux de prélèvement à la source, ainsi que les adresses et la superficie de biens immobiliers. Sud Ouest indique de son côté que la fuite affecte au moins 678 000 particuliers et professionnels, ainsi qu'environ 200 000 comptes cadastraux.

Un ensemble qui associe des données de revenu, des taux de prélèvement et des caractéristiques cadastrales n'appartient pas à un seul référentiel applicatif. Sa constitution suppose soit un accès à plusieurs bases, soit un point de consolidation qui les rapproche déjà. Cette observation n'établit pas le scénario d'attaque, mais elle indique où porter l'attention quand on cherche à comprendre la portée d'une intrusion dans un système ancien : les interfaces d'échange entre applications comptent souvent davantage que les applications elles-mêmes.

The Star rapporte par ailleurs que le ministre du Budget, David Amiel, a déclaré que dans la course contre les attaquants, l'État ne peut pas ralentir. La déclaration illustre la tension propre à la dette technique : moderniser vite augmente la surface de changement à court terme, ne pas moderniser laisse s'accroître l'écart. Aucune des deux branches n'est confortable, et c'est pourquoi ces arbitrages se prennent au niveau politique et non au niveau technique.

Une dette technique ne provoque pas une intrusion. Elle décide du temps qu'il faudra pour la voir, la comprendre et la refermer. C'est ce délai qui fait la différence entre un incident et une fuite massive.

Une tendance qui dépasse le cas français

Le diagnostic gagne à être replacé dans un cadre plus large. Il Sole 24 ORE rapporte qu'en Italie, 2 729 incidents ont été gérés par l'ACN en 2025, soit une hausse de 38 pour cent de la moyenne mensuelle, et que le secteur public reste le plus exposé avec plus de 1 100 incidents enregistrés. La même publication indique que le secteur manufacturier constitue la zone de vulnérabilité structurelle la plus forte, avec des rançongiciels concentrés sur les petites et moyennes entreprises, et que le secteur de l'énergie est une cible prioritaire pour le hameçonnage ciblé.

Ces chiffres italiens ne se transposent pas à la France et ne mesurent pas la dette technique. Ils documentent en revanche une exposition durablement plus forte du secteur public, ce qui rend le débat français moins isolé qu'il n'y paraît. Une administration concentre des données à forte valeur, des systèmes anciens et des contraintes de continuité de service qui interdisent les fenêtres d'interruption longues. Ce triangle produit partout les mêmes difficultés.

L'Observatoire de l'Intelligence Économique relève que la vétusté d'un système est rarement une découverte au moment de l'incident : elle figure généralement déjà dans des rapports de contrôle antérieurs, ce qui déplace la question du diagnostic vers celle du suivi des recommandations. Pour une veille réglementaire, cela signifie que les rapports publics des corps de contrôle constituent un indicateur avancé bien plus utile que les communiqués de crise.

Transformer le constat en objet de veille pour sa propre organisation

Une entreprise ne peut pas auditer les systèmes d'une administration, mais elle peut instruire sa propre exposition avec la même grille. Cela commence par une cartographie honnête : quelles applications critiques reposent sur des composants dont le support s'achève, quelles interfaces exposent des données consolidées, quels prestataires détiennent des accès permanents, et quels contournements techniques traînent depuis assez longtemps pour que personne ne se souvienne de leur raison d'être.

Cette cartographie devient un objet de veille dès lors qu'on la relie à un flux extérieur : annonces de fin de support des éditeurs, publications de vulnérabilités touchant les composants recensés, incidents affectant des prestataires communs, rapports de contrôle sur des organisations comparables. NewsCore (www.newscore.fr) couvre en continu des millions de sources en plusieurs langues, trie ces signaux par pertinence et renvoie chaque alerte à sa publication d'origine, ce qui raccourcit le délai entre l'annonce d'une fin de maintenance et sa prise en compte dans le plan de remédiation.

Le cadrage, lui, appartient à l'organisation. Décider quels systèmes entrent dans le périmètre surveillé, à quel seuil une alerte remonte au comité de direction et sous quelle forme le sujet est présenté à des interlocuteurs non techniques relève d'un choix interne. Le rôle de la veille est de rendre l'écart visible et daté, pas de trancher l'arbitrage budgétaire qui suivra.

Questions fréquentes

Qu'est-ce que la dette technique d'un système d'information ?

C'est l'écart accumulé entre l'état réel d'un système et l'état qu'il devrait avoir pour rester sûr et modifiable à coût raisonnable. Elle naît de choix de court terme répétés et s'aggrave d'elle-même, parce que les compétences disponibles se raréfient et que la documentation se perd. Elle se manifeste par des composants sans support, des environnements difficiles à recruter, l'absence de tests permettant de modifier sans régression et des contournements que personne n'ose retirer.

Que reproche le syndicat aux systèmes de la DGFiP ?

Sud Ouest rapporte que Solidaires Finances publiques désigne la dette technique de la DGFiP, c'est-à-dire l'ancienneté des systèmes d'information et des modèles de sécurité, comme cause principale des fuites. La même publication indique que cette ancienneté avait déjà été critiquée par la Cour des comptes et l'Inspection générale des Finances, et que la fuite affecte au moins 678 000 particuliers et professionnels ainsi qu'environ 200 000 comptes cadastraux.

La dette technique suffit-elle à expliquer une fuite de données ?

Non, et c'est une confusion fréquente. La dette technique décrit une capacité dégradée à résister, à détecter et à corriger. Elle n'indique ni le vecteur d'entrée, ni la chaîne d'exploitation, ni la durée de présence de l'attaquant dans le système. Un rapport de veille solide sépare ces deux niveaux, cite le diagnostic de contexte avec sa source et s'abstient de l'utiliser pour combler l'absence d'éléments techniques sur le déroulement de l'intrusion.

Comment surveiller la dette technique de ses propres fournisseurs ?

En croisant un inventaire interne et un flux externe. L'inventaire recense les composants critiques, leur version, leur date de fin de support annoncée et le prestataire qui les exploite. Le flux externe apporte les annonces d'éditeurs, les vulnérabilités publiées sur ces composants précis et les incidents touchant les prestataires concernés. Le signal réellement actionnable est la coïncidence entre les deux, et sa valeur dépend directement du délai de détection.