Points clés
- Les erreurs les plus courantes dans le patch management sont organisationnelles autant que techniques : absence de priorisation formelle, délais non définis, tests insuffisants avant déploiement.
- Appliquer tous les correctifs sans priorisation crée une surcharge opérationnelle qui paradoxalement retarde les corrections critiques.
- Les environnements de test insuffisants conduisent à des correctifs qui introduisent de nouvelles instabilités — ce risque est souvent utilisé pour justifier des retards injustifiés.
- La direction doit valider une politique de patch management avec des SLA définis par niveau de criticité et un processus d'exception documenté.
Le patch management est l'une des disciplines de sécurité les plus opérationnelles et les plus éprouvées — et pourtant l'une de celles où les organisations commettent le plus régulièrement des erreurs structurelles. Ces erreurs ne sont généralement pas dues à un manque de compétences techniques : elles reflètent des lacunes organisationnelles que la direction a la capacité et la responsabilité de corriger.
L'absence de priorisation : corriger tout ou corriger rien
Face à un volume de CVE publié chaque mois — parfois plusieurs centaines d'entrées — les équipes sans cadre de priorisation formalisé se retrouvent devant deux écueils symétriques : tenter de tout corriger (surcharge opérationnelle, épuisement des équipes, retards cumulatifs) ou ne corriger que ce qui est visible et urgent (abandon des corrections systématiques).
Un cadre de priorisation efficace combine le score CVSS (sévérité technique) avec l'EPSS (probabilité d'exploitation), la criticité métier du système concerné, et la présence ou non de la faille dans le catalogue KEV de la CISA. Ce croisement permet d'identifier une liste de priorité absolue réduite — typiquement 5 à 15 % des CVE détectés — sur laquelle concentrer l'effort avec les délais les plus contraints.
Les SLA non définis : un retard structurel
Sans délai cible formalisé par niveau de criticité, le patch management opère dans un vide normatif où chaque équipe applique implicitement sa propre tolérance au retard. NIS2 et DORA imposent à leurs entités soumises de définir des délais de correction selon la criticité de la vulnérabilité. Le NIST SP 800-40 recommande des délais indicatifs : 24 à 72 heures pour les failles critiques activement exploitées, 7 à 14 jours pour les failles critiques sans exploitation connue, 30 jours pour les failles élevées.
L'insuffisance des environnements de test
Un correctif peut introduire une instabilité dans un système dont il modifie le comportement. Cette réalité est souvent utilisée comme argument pour retarder les mises à jour — parfois de façon légitime, mais souvent de façon disproportionnée. La solution n'est pas de ne pas tester, c'est de disposer d'environnements de test représentatifs permettant de valider rapidement les correctifs avant leur déploiement en production. L'investissement dans ces environnements est un prérequis à un patch management réactif.
La ville de Baltimore a été paralysée par le ransomware RobbinHood pendant plusieurs semaines. L'audit post-incident conduit par l'inspecteur général de la ville a révélé que la municipalité n'avait pas de politique de patch management formalisée avec des délais définis. Des vulnérabilités critiques sur des serveurs exposés n'avaient pas été corrigées pendant des mois. Le coût total de l'incident a dépassé 18 millions de dollars, essentiellement des coûts de remédiation et de perte de productivité.
L'attaque REvil sur Kaseya VSA a exploité des vulnérabilités zero-day, mais l'ampleur de la propagation a été facilitée par l'absence de contrôles compensatoires dans les organisations clientes dont le patch management était insuffisant. L'ENISA a utilisé cet incident dans ses recommandations pour souligner l'importance de combiner patch management et segmentation réseau comme contrôles complémentaires, notamment pour les situations où le délai de correction ne peut être respecté.
Le vol de 81 millions de dollars via le réseau SWIFT de la banque centrale du Bangladesh a été facilité par des vulnérabilités sur des systèmes non correctement maintenus. L'enquête a révélé que des équipements réseau fonctionnaient sur des firmware obsolètes depuis plusieurs mois et que le processus de patch management n'incluait pas les équipements réseau dans son périmètre. SWIFT a ultérieurement renforcé ses exigences sur le patch management dans le Customer Security Programme (CSP).