Meilleures pratiques en matière de gestion des correctifs : comment réduire les risques plus rapidement

La plupart des listes de bonnes pratiques en matière de gestion des correctifs se ressemblent toutes. Dressez l'inventaire de vos actifs. Testez avant de déployer. Documenter une politique. Automatisez autant que possible. Tout cela est vrai, mais ces conseils manquent de nuance. Ils ne permettent pas de distinguer celles qui amélioreront réellement votre niveau de sécurité de celles qui ne sont que des options facultatives que vous pouvez reporter si votre équipe est déjà débordée.

Ce guide les classe. Non pas par ordre alphabétique, ni selon la taxonomie du NIST, mais en fonction de ce qui fait vraiment la différence sur les indicateurs qui comptent : le délai de correction des vulnérabilités critiques, le pourcentage de parc couvert, la solidité face à un audit et la probabilité de violation. Certaines des pratiques présentées ci-dessous réduiront de moitié votre fenêtre d’exposition. D’autres feront gagner quelques heures par mois à votre équipe. Les solutions RMM de Kaseya gèrent l’application des correctifs sur des millions de terminaux pour le compte de prestataires de services gérés (MSP) et d’équipes informatiques internes, ce qui donne une idée assez claire des pratiques communes aux programmes bien gérés et de celles qui sont systématiquement négligées dans les programmes en difficulté.

Si vous souhaitez d'abord obtenir des informations de base, commencez par consulter notre guide complet sur la gestion des correctifs. Sinon, passons directement aux bonnes pratiques.

Meilleures pratiques en matière de gestion des correctifs — classées par ordre d'impact décroissant

Les pratiques ci-dessous sont regroupées en fonction de leur impact, et non selon un ordre chronologique. Au sein de chaque groupe, elles sont classées approximativement en fonction de l'effort qu'elles requièrent par rapport au gain en matière de sécurité.

Les pratiques à fort impact modifient votre profil de risque de manière mesurable. Si vous n’avez le temps de vous consacrer qu’à trois choses ce trimestre, choisissez-les parmi celles-ci. Les pratiques à impact modéré constituent les bases opérationnelles qui portent leurs fruits au fil du temps : elles ne changent pas la donne cette semaine, mais un programme qui s’en passe ne restera pas viable très longtemps. Quant aux pratiques à faible impact, ce sont celles que l’on retrouve dans toutes les listes de contrôle d’audit. Elles méritent d’être mises en œuvre, mais ne les confondez pas avec le travail qui vous permet réellement de rester à jour.

Pratiques à fort impact

Voici les quatre pratiques qui permettent d'améliorer sensiblement vos résultats. Si vous les négligez, le reste de la liste ne vous sera d'aucune utilité. Si vous les mettez correctement en œuvre, vous pourrez vous permettre d'être un peu négligent sur la plupart des points suivants tout en gérant un programme efficace. Elles sont plus difficiles à mettre en œuvre que les mesures à impact modéré, mais le gain en termes de sécurité par heure consacrée est plusieurs fois supérieur.

Hiérarchisez les problèmes en fonction de leur exploitabilité, et pas uniquement de leur gravité

Les scores CVSS constituent un bon point de départ, mais un très mauvais point d'arrivée. Un score CVSS de 9,8 dans un logiciel que vous ne rendez pas accessible au public est moins urgent qu'un score CVSS de 7,5 figurant déjà dans le catalogue KEV de la CISA et exploité par des groupes de ransomware cette semaine.

En 2025, la CISA a ajouté 245 vulnérabilités à son catalogue des vulnérabilités connues pour avoir été exploitées(KEV), portant ainsi le nombre total à 1 484. Cela représente une hausse de 20 % en une seule année. Vingt-quatre des ajouts de 2025 étaient déjà utilisés dans des campagnes de ransomware au moment de leur inscription, et 20,5 % de toutes les entrées du catalogue KEV ont été utilisées par des opérateurs de ransomware par le passé. C'est là que se situe le véritable volume d'attaques, et cela ne représente qu'une fraction de l'univers total des CVE.

Un modèle de hiérarchisation basé sur les risques s'appuie sur trois critères : la gravité du vulnérabilité (CVSS), le statut d'exploitation (présence dans la liste KEV, flux de renseignements sur les menaces, disponibilité publique d'exploits) et l'impact métier (par exemple, si un système est exposé à Internet, traite des données sensibles ou sert de point de pivot vers des systèmes critiques). Les correctifs qui obtiennent un score élevé pour ces trois critères sont traités en priorité. Ceux qui obtiennent un score élevé pour l’un de ces critères et faible pour les autres suivent le rythme habituel. Ce changement n’est pas compliqué à mettre en œuvre. Il s’agit principalement d’un changement de méthode dans la manière dont vous triez votre rapport hebdomadaire sur les vulnérabilités.

Coût : quelques heures par semaine de travail d'un analyste. Gains : la majeure partie de vos efforts inutiles, ainsi que la possibilité de justifier vos choix de priorisation auprès d'un auditeur.

Réduire le délai de correction sur les systèmes exposés à Internet

Le rapport 2025 de Verizon sur les enquêtes relatives aux fuites de données a recensé 17 vulnérabilités affectant des appareils périphériques figurant sur la liste KEV. Le délai médian nécessaire aux entreprises pour corriger entièrement ces vulnérabilités était de 209 jours. Le délai médian nécessaire aux pirates pour commencer à exploiter ces vulnérabilités à grande échelle après leur divulgation était de cinq jours.

C'est dans cette brèche que les failles se produisent. Les systèmes périphériques (passerelles VPN, pare-feu, pare-feu d'applications web, fournisseurs d'identité et tout autre élément accessible depuis Internet) doivent être soumis à un SLA de mise à jour distinct et nettement plus rapide que le reste de votre infrastructure. Un délai de 14 jours pour les correctifs de routine concernant les systèmes exposés à Internet et un délai de 24 à 48 heures pour ceux faisant l’objet d’exploitations actives constituent un objectif raisonnable. Au-delà de ces délais, c’est comme si vous laissiez sciemment la porte grande ouverte.

Cette pratique a un fort impact, car elle concentre les efforts sur les systèmes que les attaquants ciblent en priorité. Elle n'implique pas d'accélérer le rythme pour chaque correctif, mais bien d'accélérer le rythme pour les correctifs les plus importants.

Automatiser les tâches routinières

L'application manuelle de correctifs à grande échelle ne fonctionne pas. Le catalogue KEV a augmenté de 20 % en un an, alors que les effectifs de la plupart des équipes informatiques sont restés stables. Les chiffres ne jouent pas en faveur des humains.

Concrètement, il s'agit d'automatiser tout ce qui est prévisible (identification, planification, déploiement vers des anneaux définis, logique de réessai, génération de rapports) et de confier aux humains tout ce qui nécessite un jugement (gestion des exceptions, validation des fenêtres de modification pour les systèmes sensibles, décisions de retour en arrière, communication avec les parties prenantes). Bien menée, cette approche permet de réduire ce qui était auparavant un travail à temps plein consacré aux correctifs à quelques heures de supervision par semaine.

L’objection la plus courante est la crainte que des correctifs défectueux ne provoquent une interruption de la production. La solution ne consiste pas à tout faire manuellement, mais à mettre en place les garde-fous appropriés pour l’automatisation : des anneaux de déploiement qui détectent les problèmes sur un groupe pilote avant qu’ils n’atteignent la production, une annulation automatique en cas d’échec signalé par un agent, et un parcours d’exception défini pour les 5 % de systèmes qui nécessitent réellement une intervention manuelle. Pour en savoir plus sur le modèle opérationnel et sur ce qu’il convient d’automatiser ou de laisser à la gestion manuelle, consultez notre article sur la gestion automatisée des correctifs.

Traitez les applications tierces avec la même rigueur que le système d'exploitation

La plupart des programmes de mise à jour gèrent efficacement Windows, macOS et Linux, mais ne s'occupent des autres systèmes qu'au second plan. C'est là que réside la lacune. Les vulnérabilités des navigateurs, des lecteurs de PDF, des outils de visioconférence, des environnements d'exécution et des outils de développement sont largement exploitées, et bon nombre des chaînes d'attaques les plus répandues s'appuient sur elles comme vecteur d'attaque initial.

La pratique consiste à intégrer les applications tierces dans le même inventaire, le même cadre de priorisation et les mêmes SLA que ceux utilisés pour les correctifs de votre système d’exploitation. Il ne s’agit pas d’un projet distinct, ni d’un outil distinct, ni d’un bilan trimestriel distinct. C’est exactement la même chose. Si votre plateforme de gestion des correctifs prend en charge nativement plusieurs centaines d’applications tierces (ce qui est le cas de la plupart des plateformes modernes), il s’agit davantage d’un changement de configuration que d’un nouveau programme. Si ce n’est pas le cas, c’est cette lacune qu’il faut combler en priorité. Vous trouverez la liste des applications spécifiques à prioriser ainsi qu’une analyse plus approfondie du sujet dans notre article de blog consacré à la gestion des correctifs tiers.

Entraînements à impact modéré

Les quatre pratiques suivantes sont celles qui permettent à un programme performant de rester performant. Prises isolément, aucune d’entre elles ne réduira de moitié votre fenêtre d’exposition comme peuvent le faire les mesures à fort impact. Mais ensemble, ce sont elles qui font la différence entre un programme capable de résister à un audit et aux changements de personnel, et un programme qui se dégrade discrètement dès qu’un collaborateur quitte l’entreprise ou que l’activité s’intensifie.

Utilisez des cycles de déploiement, plutôt que de tout déployer en une seule fois ou un par un.

Un « anneau de déploiement » désigne une séquence définie de groupes de systèmes qui reçoivent un correctif par vagues : tout d'abord un petit groupe pilote représentatif de l'ensemble du parc, puis un groupe de validation plus large, et enfin le déploiement complet en production. Chaque anneau est suivi d'une période d'attente avant le début du suivant, durant laquelle la surveillance permet de détecter tout problème induit par le correctif.

Cette pratique permet d'écarter deux modes de défaillance qui coûtent cher aux équipes. Le premier est l'approche consistant à « tout déployer le vendredi après-midi », qui garantit qu'un correctif défectueux paralysera d'un seul coup l'ensemble de l'organisation. Le second est l'approche consistant à « appliquer le correctif sur une machine à la fois », qui semble prudente mais prend tellement de temps que le correctif est déjà obsolète avant d'être entièrement déployé. Les « rings » vous offrent la rapidité de l'automatisation tout en garantissant la sécurité d'un déploiement par étapes.

Une structure de départ raisonnable consiste en trois phases : 5 à 10 % du parc en phase pilote, 25 à 35 % en phase de validation à plus grande échelle, et le reste en phase de déploiement définitif. Les délais d'attente de 24 à 48 heures entre chaque phase conviennent pour les correctifs de routine et peuvent être réduits à quelques heures en cas d'urgence.

Faites de la restauration une opération à part entière, et non une mesure d'urgence

La restauration est une pratique que tout le monde approuve, mais que la plupart des équipes n’ont en réalité jamais testée. Le moment idéal pour découvrir que votre procédure de restauration ne fonctionne pas, ce n’est pas le lendemain matin d’un correctif défaillant qui a mis hors service 4 000 terminaux.

Une capacité de retour en arrière efficace repose sur trois éléments : une procédure documentée pour chaque grand système d’exploitation et chaque type de correctif, un chemin de restauration dont la fiabilité est avérée (image, instantané ou désinstallation native de la plateforme), et au moins un exercice d’urgence par trimestre au cours duquel l’équipe effectue le retour en arrière sur un groupe test. L’exercice d’urgence est l’étape que la plupart des programmes négligent. Sans cela, la documentation se dégrade et personne ne s’en rend compte avant d’en avoir besoin.

Il s'agit d'un impact modéré plutôt que d'un impact élevé, car dans les programmes bien gérés où le déploiement par anneaux est efficace, les retours en arrière sont rares. Mais l'asymétrie a son importance : les incidents rares qui prennent plusieurs jours à résoudre coûtent plus cher que les incidents fréquents qui ne prennent que quelques minutes.

Suivre et rendre compte de la conformité par appareil, et non pas uniquement sous forme de données agrégées

Un taux de conformité de 95 % est rassurant, mais n'a guère de sens. La question intéressante est de savoir quels sont ces 5 % non conformes, pourquoi et depuis combien de temps. Le fait que ce soient toujours les mêmes 5 % qui ne soient pas conformes à chaque cycle pose un problème différent de celui d'un échantillon de 5 % réparti de manière aléatoire, et la réponse appropriée est également différente.

La pratique consiste à établir des rapports avec un niveau de détail par appareil, en identifiant les responsables de chaque appareil non conforme et en définissant clairement les cas d’exception. Un appareil est soit conforme, soit dans une situation d’exception documentée avec une date de réévaluation, soit en infraction à la politique. Trois états, pas de flou. La plupart des équipes découvrent, lorsqu’elles effectuent cet exercice pour la première fois, que l’essentiel de leur « non-conformité persistante » provient d’un petit ensemble stable d’appareils : des ordinateurs portables utilisés en déplacement et dont le redémarrage n’est pas effectué régulièrement, des systèmes hérités dont les propriétaires hésitent à toucher, et des segments de développement ou de laboratoire fonctionnant en dehors du périmètre d’application des correctifs de production. La liste est limitée. S’attaquer délibérément à ces cas particuliers est un problème distinct de l’amélioration de la conformité générale, et cela mérite une attention trimestrielle spécifique.

Pour les programmes destinés à plusieurs unités opérationnelles ou, dans le cas d'un MSP, à plusieurs clients, la même pratique s'applique par locataire. Les rapports de conformité par client constituent également le document d'audit le plus fréquemment demandé lors des examens de cadre de référence.

Consigner le programme dans une politique concrète et appliquée

Tous les cadres d’audit et la plupart des demandes de souscription d’assurance cyber exigent désormais une politique de gestion des correctifs. La mauvaise version consiste en un document de trois pages indiquant que « les correctifs seront appliqués en temps opportun » et qui finit dans un dossier SharePoint que personne n’ouvre. La version utile précise les accords de niveau de service (SLA) en fonction de la gravité des correctifs, définit les rôles et les procédures d’approbation, précise les créneaux de maintenance, établit la procédure d’exception et fait l’objet d’une révision trimestrielle.

La partie « réelle et appliquée » correspond à la pratique. Une politique qui ne correspond pas à ce que fait réellement l’équipe est pire que l’absence de politique, car elle donne lieu à des constatations d’audit chaque fois que la réalité s’écarte du document. La rigueur consiste soit à modifier la politique lorsque la pratique change, soit à adapter la pratique pour qu’elle corresponde à la politique. Pour connaître la structure d’une politique viable et les sections qui importent vraiment aux auditeurs, consultez notre guide sur l’élaboration d’une politique de gestion des correctifs.

Pratiques à faible impact

Ces éléments figurent sur toutes les listes de contrôle. Ils méritent d'être mis en œuvre, mais ne vous attendez pas à ce qu'ils aient un impact significatif sur vos résultats :

• Tenir à jour un inventaire des actifs demande beaucoup de travail, mais la plupart des équipes en disposent déjà d'un. Le véritable problème en matière d'inventaire réside dans l'informatique fantôme et les terminaux non gérés, problèmes que l'inventaire en lui-même ne peut pas résoudre.
• Il est utile de communiquer les créneaux de maintenance aux utilisateurs finaux pour entretenir de bonnes relations avec l'entreprise, mais cela ne modifie en rien votre niveau de sécurité.
• La standardisation des versions logicielles prises en charge présente un réel intérêt, même si les résultats ne sont pas immédiats : réduire le nombre de versions différentes de systèmes d'exploitation et d'applications au sein du parc informatique facilite grandement toutes les autres tâches, mais le projet nécessaire pour y parvenir prend généralement un an, voire plus.
• Former les utilisateurs finaux à ne pas ignorer les notifications de mise à jour porte ses fruits, mais la plupart des failles exploitées ne nécessitent aucune action de la part de l'utilisateur. Le comportement des utilisateurs joue un rôle plus important dans le hameçonnage que dans l'application des correctifs.

Si ces conseils figurent dans toutes les listes, c’est parce qu’ils sont faciles à noter et qu’il est difficile de les contester. S’ils se trouvent en bas de celle-ci, c’est parce que les appliquer à la perfection tout en négligeant les conseils des deux premières sections ne garantira pas votre sécurité.

Indicateurs de gestion des correctifs : comment évaluer l'efficacité des bonnes pratiques

Une pratique qu'on ne peut pas mesurer n'est pas une pratique. C'est une aspiration. Les indicateurs qu'il vaut la peine de suivre chaque semaine ou chaque mois sont peu nombreux :

1. Délai de correction des vulnérabilités critiques, mesuré entre la publication par le fournisseur et le déploiement à l'échelle du parc informatique.
2. Pourcentage du parc informatique conforme au SLA de mise à jour, ventilé par niveau de priorité des correctifs (critique, élevé, modéré).
3. Âge moyen des vulnérabilités non corrigées encore présentes dans l'environnement.
4. Nombre d'appareils se trouvant dans un état d'exception documenté, avec une date de révision à jour.
5. Nombre d'incidents provoqués par les correctifs par cycle, servant d'indicateur de retour d'expérience pour les tests et le déploiement en anneau.

Cinq chiffres. S'ils évoluent dans la bonne direction, c'est que le programme fonctionne. S'ils stagnent ou s'aggravent malgré les efforts déployés, cela signifie que l'une des pratiques mentionnées ci-dessus n'est pas mise en œuvre telle qu'elle est décrite.

En quoi Kaseya fait la différence

Les pratiques décrites ci-dessus illustrent le fonctionnement d'un programme de gestion des correctifs efficace. Le choix des outils déterminera si votre équipe sera en mesure de maintenir ces pratiques sans s'épuiser.

Les fonctionnalités à privilégier : un inventaire unifié couvrant tous les systèmes d'exploitation et les applications tierces, une hiérarchisation des priorités basée sur des règles et intégrant les données KEV, un déploiement par anneaux avec des périodes de retenue automatiques, la gestion des appareils hors réseau, la réessai automatisé et la remontée des exceptions, ainsi que des rapports de conformité par appareil fournissant à la demande des preuves prêtes pour un audit.

Les solutions RMM de Kaseya fournissent un logiciel de gestion des correctifs destiné aux MSP et aux équipes informatiques internes, quel que soit le système d’exploitation. Le module « Advanced Software Management » de Datto RMM prend en charge plus de 200 applications tierces prêtes à l’emploi, les politiques de déploiement par anneaux, la gestion hors réseau et les rapports de conformité par locataire requis par les pratiques décrites ci-dessus. Datto RMM, qui fait partie de la famille Kaseya RMM, est la solution native du cloud destinée aux équipes qui souhaitent bénéficier des mêmes fonctionnalités sans avoir à gérer l’infrastructure sous-jacente.

Les pratiques qui font vraiment la différence sont celles présentées ci-dessus dans la section « à fort impact ». Choisissez-en une pour ce trimestre, mettez-la en œuvre correctement et mesurez les résultats obtenus.