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. Consignez votre politique par écrit. Automatisez autant que possible. Tout cela est vrai, mais ces conseils manquent de relief. Ils ne permettent pas de distinguer ceux qui amélioreront réellement votre niveau de sécurité de ceux qui ne sont que des options facultatives que vous pouvez remettre à plus tard 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 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 les correctifs sur des millions de terminaux pour les MSP et les é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.
Bonnes pratiques en matière de gestion des correctifs — classées par ordre d'importance décroissante
Les pratiques ci-dessous sont classées par impact, et non par 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 tangible. Si vous n'avez le temps de faire que trois choses ce trimestre, choisissez parmi celles-ci. Les pratiques à impact modéré constituent l'hygiène opérationnelle qui s'accumule au fil du temps : elles ne changent pas grand-chose cette semaine, mais un programme qui s'en passe ne restera pas viable longtemps. Quant aux pratiques à faible impact, ce sont les éléments que l'on retrouve dans toutes les listes de contrôle d'audit. Elles valent la peine 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 moins rigoureux 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 priorités en fonction de l'exploitabilité, et pas seulement de la 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, portant le nombre total à 1 484. Cela représente une augmentation 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 KEV ont été utilisées par des opérateurs de ransomware par le passé. C'est là que se situe le volume réel des attaques, et cela ne représente qu'une fraction de l'univers CVE total.
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 sur l'activité (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 un critère 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 : une réduction considérable 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 violations 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 failles à 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 accord de niveau de service (SLA) distinct, prévoyant des mises à jour beaucoup plus rapides que pour le reste de votre infrastructure. Un délai de 14 jours pour les correctifs de routine exposés à Internet et un délai de 24 à 48 heures pour ceux qui font l'objet d'exploits actifs constituent un objectif raisonnable. Si vous vous contentez de délais plus longs, vous laissez sciemment la porte grande ouverte.
Cette pratique est particulièrement efficace, car elle concentre les efforts sur les systèmes que les pirates ciblent en premier. Elle n'implique pas d'accélérer le rythme pour chaque correctif, mais bien pour ceux qui revêtent le plus d'importance.
Automatiser les tâches routinières
La gestion manuelle des correctifs à grande échelle n'est pas viable. 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, 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 à plein temps 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 panne de l'environnement de production. La solution ne consiste pas à tout faire manuellement, mais à mettre en place les garde-fous adéquats pour l'automatisation : des cycles 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 l'agent, et un processus 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 en mode manuel, 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 faille. 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. Pas de projet distinct, pas d'outil distinct, pas de revue trimestrielle distincte. Tout doit être harmonisé. 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 d'un simple changement de configuration plutôt que d'un nouveau programme. Si ce n'est pas le cas, c'est cette lacune qu'il faut combler en premier lieu. Vous trouverez les applications spécifiques à prioriser ainsi qu'une analyse plus approfondie du sujet dans notre blog consacré à la gestion des correctifs tiers.
Activités à impact modéré
Les quatre pratiques suivantes sont celles qui permettent à un programme solide 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, elles font la différence entre un programme qui résiste aux audits et aux changements de personnel, et un programme qui se dégrade inexorablement dès qu’un collaborateur part ou que l’activité s’intensifie.
Utilisez des cycles de déploiement, plutôt qu'un déploiement 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 : 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 précédé d'une période d'attente avant le début du suivant, durant laquelle la surveillance permet de détecter tout problème lié au correctif.
Cette méthode élimine 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 mettra d'un seul coup toute l'organisation à l'arrêt. Le second est l'approche consistant à « corriger 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 anneaux vous offrent la rapidité de l'automatisation tout en garantissant la sécurité d'un déploiement par étapes.
Une structure initiale raisonnable consiste en trois phases : 5 à 10 % de l'environnement comme phase pilote, 25 à 35 % comme phase de validation à plus grande échelle, et le reste comme déploiement final. Des 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 un simple exercice d'urgence
Le rollback est une pratique que tout le monde approuve, mais que la plupart des équipes n’ont jamais vraiment testée. Le moment idéal pour découvrir que votre procédure de rollback ne fonctionne pas, ce n’est pas le lendemain matin, après qu’un correctif défectueux a mis hors service 4 000 terminaux.
Pour qu'une fonctionnalité de restauration soit efficace, trois éléments sont indispensables : 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 la restauration 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.
L'impact est modéré plutôt que é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 des 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 plus 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 le responsable 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 avec la politique. Trois états, pas de flou. La plupart des équipes découvrent, lorsqu'elles effectuent cet exercice pour la première fois, que la majeure partie de leur « non-conformité persistante » provient d'un petit groupe stable d'appareils : des ordinateurs portables de déplacement dont le redémarrage n'est pas systématique, des systèmes hérités que leurs propriétaires hésitent à modifier, et des segments de développement ou de laboratoire fonctionnant en dehors du périmètre de mise à jour de production. La liste est finie. S'y attaquer de manière ciblée 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 divisions ou, dans le cas des 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 conformité.
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 version inefficace se résume à 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 efficace 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, fixe les créneaux de maintenance, établit la procédure d'exception et fait l'objet d'une révision trimestrielle.
C'est dans la mise en pratique que réside le caractère « réel et effectif » d'une politique. Une politique qui ne correspond pas à ce que fait réellement l'équipe est pire que l'absence totale 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 les pratiques changent, soit à adapter les pratiques pour qu'elles correspondent à 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 pris en compte, mais ne vous attendez pas à ce qu'ils changent grand-chose à 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 d'informer les utilisateurs finaux des fenêtres de maintenance pour entretenir de bonnes relations avec l'entreprise, mais cela ne modifie en rien votre niveau de sécurité.
- L'uniformisation 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 intervention de leur part. Le comportement des utilisateurs a davantage d'importance dans le cadre du phishing que pour l'application des correctifs.
Si ces conseils figurent sur toutes les listes, c’est parce qu’ils sont faciles à noter et difficiles à contester. S’ils se trouvent en bas de celle-ci, c’est parce que les appliquer à la lettre 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 :
- 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.
- Pourcentage du parc informatique conforme au contrat de niveau de service (SLA) en matière de correctifs, ventilé par niveau de priorité des correctifs (critique, élevé, modéré).
- Âge moyen des vulnérabilités non corrigées encore présentes dans l'environnement.
- Nombre d'appareils se trouvant dans un état d'exception documenté, avec une date de révision à jour.
- Nombre d'incidents liés aux correctifs par cycle, servant d'indicateur 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 empirent malgré les efforts déployés, cela signifie qu'une des pratiques mentionnées ci-dessus n'est pas mise en œuvre comme prévu.
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 délais de conservation 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 des logiciels de gestion des correctifs destinés 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, autant d'éléments indispensables aux pratiques décrites ci-dessus. Datto RMM, qui fait partie de la famille Kaseya RMM, est l'option native du cloud pour les é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 dans la section « à fort impact » ci-dessus. Choisissez-en une pour ce trimestre, mettez-la en œuvre correctement et mesurez les résultats.
