Dette technique d'un système public : la décision qui n'a jamais été prise

Un incident de sécurité dans une administration produit toujours deux récits concurrents. Le premier est technique et parle de vulnérabilité, d'exploitation, de correctif. Le second est budgétaire et parle de priorités, de calendriers d'investissement et de reports. La compromission des systèmes de la direction générale des Finances publiques a fait remonter le second récit à la surface, sous un nom emprunté au vocabulaire du génie logiciel : la dette technique. Ce déplacement de vocabulaire n'est pas anodin, parce qu'il change la nature de la question posée.

Le Fil de la Veille a rapporté le contenu factuel de cette mise en cause. L'analyse commence là où le compte rendu s'arrête : que signifie exactement, dans une organisation publique, l'idée qu'un système d'information porte une dette ? Qui la contracte, qui en paie les intérêts, et à quel moment l'échéance devient-elle exigible ? La réponse détermine si l'incident relève de la faute d'un service ou d'un mode de décision installé sur une décennie.

L'enjeu n'est pas rhétorique. Selon que l'on qualifie la vétusté d'un système de défaillance opérationnelle ou de conséquence d'arbitrages répétés, on ne convoque ni les mêmes responsables, ni les mêmes remèdes, ni la même échelle de temps. Une défaillance se corrige par un plan d'action de six mois. Un arbitrage reconduit ne se corrige que par un changement de règle de décision, ce qui suppose d'abord de nommer la règle en vigueur.

Ce que recouvre la dette technique dans un système d'information public

La métaphore est née dans l'ingénierie logicielle pour désigner le coût futur d'un choix de court terme. On livre plus vite en acceptant une solution imparfaite ; l'écart entre la solution retenue et la solution robuste constitue un principal, et le surcoût de maintenance qu'il engendre constitue des intérêts. Tant que le principal n'est pas remboursé, chaque évolution ultérieure coûte plus cher que prévu. Appliquée à un système d'information public, la mécanique reste la même mais l'échelle change complètement.

Dans une administration fiscale, le principal ne se limite pas à des lignes de code. Il inclut des modèles de sécurité conçus à une époque où le périmètre pertinent était un réseau fermé, des formats de données qui interdisent le chiffrement sélectif, des couplages applicatifs qui rendent toute isolation coûteuse, et des dépendances à des composants dont plus personne ne maîtrise le cycle de vie. Les intérêts se paient en délai de correction, en surface d'exposition et en incapacité à cloisonner un incident quand il survient.

Cette distinction compte pour qui lit un rapport d'audit. Un système peut être parfaitement à jour de ses correctifs et rester lourdement endetté, parce que sa dette porte sur l'architecture et non sur les versions installées. Inversement, un retard de correctif isolé est un incident de maintenance, pas une dette. Confondre les deux conduit à des plans de remédiation qui traitent les symptômes mesurables et laissent intact le principal, avec l'apparence rassurante d'un taux d'avancement en progression.

Sud Ouest, un syndicat, et la requalification d'un incident en choix de gestion

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

L'intérêt analytique de cette prise de parole ne tient pas au chiffre, qui circule par ailleurs et dont les décomptes varient selon les publications, mais à l'opération de qualification qu'elle effectue. En nommant une dette, on affirme qu'il y a eu emprunt, donc décision, donc décideur. On sort du registre de l'accident pour entrer dans celui de la responsabilité. C'est un geste politique au sens strict : il transforme un fait technique en objet de délibération.

La nuance doit être tenue. Qu'une organisation syndicale désigne une cause principale ne suffit pas à l'établir : elle porte un intérêt légitime et situé, celui des agents et de leurs conditions de travail, et sa lecture d'un incident reste une lecture parmi d'autres. Ce qui donne du poids à celle-ci, c'est sa convergence avec des constats antérieurs d'institutions de contrôle, que le même article rappelle sans les confondre avec la position syndicale.

Une dette technique n'est jamais découverte par un incident. Elle est seulement rendue exigible par lui.

L'alerte répétée sans décision datée, pathologie ordinaire des grands systèmes

Le point le plus instructif du dossier n'est pas que la vétusté ait causé un dommage, mais qu'elle ait été signalée avant. Un constat d'audit antérieur change la structure du problème : il exclut l'hypothèse de l'ignorance et impose de comprendre pourquoi une information disponible n'a produit aucune décision. C'est le régime ordinaire des grands systèmes d'information. L'alerte existe, elle est archivée, elle est reformulée l'année suivante, et elle n'est jamais assez urgente pour déplacer une ligne budgétaire.

Trois mécanismes expliquent cette inertie, et aucun ne suppose de mauvaise foi. Le premier est l'asymétrie des horizons : le coût du remboursement est immédiat et visible, le bénéfice est différé et invisible puisqu'il consiste en incidents qui n'ont pas lieu. Le deuxième est la dilution : la dette est partagée entre une maîtrise d'ouvrage métier, une direction du numérique et un contrôle budgétaire, sans que personne n'en porte le solde. Le troisième est la substitution du contrôle à la décision, où produire un rapport tient lieu d'avoir traité le sujet.

Ce tableau n'est pas un référentiel, c'est une grille de lecture. Il énonce une règle simple : à chaque étape, l'organisation produit un livrable qui ressemble à une décision sans en être une. La décision commence quand une échéance devient opposable et qu'un budget lui est affecté sur plusieurs exercices. Tant que ces deux conditions manquent, le dossier avance, la documentation s'épaissit, et la dette reste au même niveau.

Conséquences organisationnelles : qui porte le risque quand personne ne tranche

Quand la décision n'est pas prise, le risque ne disparaît pas, il se déplace. Il descend d'abord vers les équipes d'exploitation, qui compensent par des contrôles manuels, des procédures de contournement et une vigilance individuelle non financée. Il se transfère ensuite vers les usagers, qui supportent l'exposition de leurs données sans avoir participé à l'arbitrage ni disposé d'une information sur son existence. Il se reporte enfin sur le successeur, puisqu'un arbitrage différé devient mécaniquement un héritage.

Cette cascade produit un effet secondaire moins visible et plus durable : la démoralisation de la fonction d'alerte. Une direction technique qui signale trois fois sans effet apprend que signaler ne produit rien, et calibre ses alertes suivantes en conséquence, soit en les durcissant jusqu'à l'inaudible, soit en les abandonnant. L'organisation perd alors son capteur interne au moment précis où elle en aurait le plus besoin, et se retrouve dépendante de l'incident pour découvrir son propre état.

Rendre une dette exigible avant l'incident plutôt qu'après

Le remède n'est pas un outil, c'est une règle de gestion. Il consiste à attacher à chaque constat d'audit non traité trois attributs qui le rendent opposable : une date de réexamen inscrite au calendrier de direction, un porteur nommé qui n'est pas un collectif, et une mesure d'exposition mise à jour à chaque réexamen. Une dette datée entre dans la discussion budgétaire ; une dette seulement décrite reste dans un rapport que personne n'a intérêt à rouvrir.

La mesure d'exposition est la pièce difficile, parce qu'elle ne se déduit pas de l'audit interne. Elle se lit à l'extérieur : publication d'un exploit sur un composant utilisé, mise en vente d'accès sur des places de marché criminelles, incident survenu chez une administration comparable, alerte sectorielle d'un régulateur. Ces signaux ne disent pas si le système est vulnérable, ils disent que la fenêtre entre la vulnérabilité connue et son exploitation se referme, ce qui est une information budgétaire autant que technique.

C'est le point d'articulation entre deux fonctions habituellement séparées, l'audit interne et la veille externe. NewsCore (www.newscore.fr) couvre en continu des millions de sources et fait remonter en temps réel les signaux qui rendent une dette exigible, ce qui donne au responsable d'un système un argument daté à opposer au calendrier d'investissement. La qualification du signal, l'arbitrage et la décision de remédiation restent la part de l'organisation, et c'est précisément à cet endroit que le dossier de la direction générale des Finances publiques garde sa valeur d'exemple.

Questions fréquentes

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

C'est l'écart accumulé entre l'architecture réellement en service et celle qu'imposerait l'état de la menace, écart contracté par une succession de choix de court terme et non par une faute unique. Elle se compose d'un principal, l'ancienneté des modèles de sécurité et des couplages applicatifs, et d'intérêts, qui se paient en délai de correction et en surface d'exposition. Elle se distingue du simple retard de correctif, lequel relève de la maintenance courante.

La dette technique explique-t-elle à elle seule une fuite de données ?

Non, et la présenter ainsi serait un raccourci. Une fuite suppose toujours un acteur, un mode opératoire et une occasion. La dette technique agit sur la probabilité et sur l'ampleur : elle élargit la surface exposée, allonge le délai de détection et rend le cloisonnement plus coûteux une fois l'intrusion établie. Elle est un facteur aggravant structurel, pas une cause suffisante, et la distinction est importante pour calibrer la remédiation.

Comment mesurer la dette technique autrement que par un rapport d'audit ?

En la convertissant en exposition observable. Trois indicateurs suffisent à ouvrir la discussion : la part des composants dont le support éditeur est terminé, le délai médian entre publication d'une vulnérabilité et correction effective sur le parc, et le nombre de systèmes pour lesquels aucun cloisonnement n'est possible sans interruption de service. Ces mesures se comparent d'une année sur l'autre, ce que ne permet pas un jugement qualitatif de vétusté.

Pourquoi des alertes répétées ne débouchent-elles pas sur une décision ?

Parce que l'alerte et la décision n'obéissent pas au même calendrier ni au même porteur. L'alerte est produite par une fonction technique, à fréquence libre, sans budget attaché. La décision suppose une échéance opposable, un financement pluriannuel et un responsable identifié. Tant que l'alerte n'est pas traduite dans ces trois termes, elle reste une information sans destinataire décisionnel, et sa répétition renforce le sentiment que le sujet est traité.