Un passif qui ne figure dans aucun bilan
Système d'exploitation en fin de vie. Bibliothèque non maintenue. Application si imbriquée qu'on n'ose plus la mettre à jour. Chaque élément pris isolément paraît gérable. Ensemble, ils forment une dette technique dont le coût se paie désormais en exposition.
Et l'IA accélère la facture. Les modèles les plus avancés progressent dans la découverte et l'exploitation des failles logicielles, y compris dans des dépendances open source réutilisées partout.
Détecter plus vite ne suffit pas
Le piège est là. Une détection plus rapide peut simplement allonger la file des corrections en attente si la chaîne de livraison ne suit pas. Un correctif présent dans un dépôt ne modifie pas l'application en production. Ça paraît évident. Dans les faits, c'est l'écart le plus fréquent.
La dette aggrave chaque étape. Une application difficile à tester est délicate à corriger en confiance. Des environnements hétérogènes multiplient les interventions. Des responsabilités floues laissent vivre des composants vulnérables. Et les équipes absorbées par les urgences n'ont plus le temps de moderniser.
Une dette future : la cryptographie
Des données chiffrées collectées aujourd'hui pourraient être déchiffrées plus tard par un ordinateur quantique suffisamment puissant. Les premiers standards post-quantiques du NIST sont publiés. Reporter l'inventaire des mécanismes cryptographiques, dans les applications, les certificats, les bibliothèques et les services tiers, c'est créer la prochaine dette.
Standardiser pour pouvoir corriger
La réponse passe par la plateforme. Systèmes d'exploitation cohérents, conteneurs, automatisations réutilisables : moins de configurations uniques, donc des correctifs plus fiables et des reprises plus rapides. La sécurité doit être intégrée à la chaîne de livraison, avec des composants de confiance et des contrôles automatisés.
Côté gouvernance, la gestion des vulnérabilités doit tenir compte de l'exploitabilité, de l'exposition et de la criticité métier, avec des délais clairs par responsable.
Les deux indicateurs qui comptent
Le nombre d'actifs critiques sans support. Et le délai entre la publication d'un correctif et sa vérification en production. Pas la fermeture du ticket. La vérification.
En tierce maintenance applicative comme en interne, c'est ce second chiffre qui dit si l'organisation corrige vraiment.
