Dette de sécurité technique

Le terme n'est pas une métaphore. Comme une dette financière, la dette de sécurité résulte d'un arbitrage entre le présent et l'avenir, elle porte intérêt puisque le coût de correction croît avec l'ancienneté du composant et le nombre de systèmes qui en dépendent, et elle devient exigible à une date que le débiteur ne choisit pas. Sa particularité tenait jusqu'ici à son invisibilité comptable : elle ne figure à aucun bilan, ne se mesure dans aucune unité partagée, n'a pas d'échéance, et son omission ne constitue aucune irrégularité. Une entreprise pouvait donc présenter des états parfaitement fidèles tout en portant un passif considérable dont personne, y compris elle-même, ne connaissait le montant. Le règlement européen sur la cyberrésilience a changé ce statut sans changer la nature du danger, en fournissant les quatre attributs manquants, une date d'exigibilité, un créancier sous la forme de l'autorité de surveillance du marché, une unité de mesure avec la nomenclature logicielle, et un barème de sanction. À ne pas confondre avec la dette technique des développeurs, qui mesure le coût d'entretien d'un code mal conçu : la dette de sécurité mesure ce que coûtera une vulnérabilité connue et non corrigée, et un tiers peut l'exiger. Où le mot se lit : dans aucune police ; on la lit dans le questionnaire de souscription (délai de correction des vulnérabilités critiques) et, pour les produits vendus dans l'Union, dans le règlement (UE) 2024/2847, dont les obligations principales s'appliquent à partir du 11 décembre 2027.