Chaque semaine, des dizaines de vulnérabilités sont découvertes dans des logiciels utilisés par des milliers d’entreprises. Windows, VMware, les firewalls, les applications métier. Personne n’est épargné. Le correctif existe souvent en quelques jours. Pourtant, dans beaucoup de PME romandes, il ne sera jamais appliqué. Pas par négligence, mais parce qu’il n’y a aucune règle qui dit qui s’en charge, quand, et comment.
C’est exactement ce qu’une politique de patch management est censée résoudre. Prenons le temps de comprendre ensemble à travers cet article.
Ce qu’on entend par « patch management »
Un patch, c’est un correctif logiciel. Il peut combler une faille de sécurité, corriger un bug, ou améliorer la stabilité d’un système. Le patch management, c’est le processus qui permet de les identifier, les tester et les déployer de manière contrôlée sur l’ensemble du parc informatique.
Sans processus défini, voici ce qui se passe concrètement : le responsable IT applique les mises à jour quand il a le temps, certaines machines sont oubliées, et personne ne sait réellement quel poste tourne sur quelle version.
Lors d’un audit chez un notaire à Nyon, on a découvert que deux serveurs n’avaient pas reçu de mises à jour de sécurité depuis dix-neuf mois. La personne en charge pensait sincèrement que les mises à jour automatiques étaient activées. Elles ne l’étaient pas.
Ce que contient une politique de patch management
Une politique, c’est un document court et opérationnel. Pas un cahier de 40 pages. Elle répond à quatre questions.
Quels systèmes sont couverts ? Postes de travail, serveurs, équipements réseau, applications cloud, téléphones professionnels. Si ce n’est pas listé, ce n’est pas géré.
Qui est responsable ? Un nom, pas un service. Dans une PME, c’est souvent l’infogérant externe ou un référent IT interne. L’ambiguïté de responsabilité est la première raison pour laquelle les patchs ne sont pas appliqués.
Dans quel délai ? Les correctifs critiques, ceux qui bouchent des failles activement exploitées, méritent un délai de 24 à 72 heures. Les mises à jour standard peuvent attendre un cycle mensuel. Cette distinction est importante : tout traiter de la même façon revient à ne rien prioriser.
Comment on valide avant de déployer ? Sur les postes bureautiques standards, on déploie souvent directement. Sur les serveurs de production, on teste d’abord dans un environnement séparé, ou on déploie hors des heures ouvrées avec un plan de retour arrière.
Pourquoi la mise à jour automatique ne suffit pas ?
C’est la réponse qu’on entend le plus souvent : « On a les mises à jour automatiques. » Elle rassure. Mais elle est insuffisante.
Les mises à jour automatiques de Windows ne couvrent pas les logiciels tiers, les drivers, les applications métier, ni les équipements réseau. Elles peuvent aussi se désactiver silencieusement après un incident système, une migration ou une intervention d’un tiers. Et elles ne produisent aucun rapport : impossible de savoir ce qui a été appliqué, ce qui a échoué, ce qui est en attente.
Une politique de patch management donne une visibilité centralisée que les mises à jour automatiques ne donnent pas. C’est la différence entre « je pense que c’est à jour » et « je peux vous montrer l’état de chaque machine ce matin ».
Le lien direct avec la cybersécurité
La majorité des attaques par ransomware exploitent des vulnérabilités connues et corrigées depuis plusieurs mois. Ce n’est pas une opinion : c’est ce que montrent les rapports post-incident année après année, notamment ceux de l’ANSSI, du NCSC ou encore de l’OFCS. Les attaquants ne cherchent pas les systèmes les plus complexes à compromettre. Ils cherchent ceux qui n’ont pas fait le minimum.
Une PME qui maintient son parc à jour réduit mécaniquement sa surface d’attaque. Ce n’est pas une garantie absolue, mais c’est l’une des mesures les plus efficaces par rapport à l’effort qu’elle demande.
Ce qu’on recommande chez Infologo
Chez Infologo, nous voyons deux erreurs récurrentes.
La première : ne rien formaliser du tout et s’en remettre aux automatismes. La deuxième : vouloir tout patcher immédiatement sur tous les systèmes sans phase de test, ce qui crée des interruptions de service et nourrit la méfiance envers les mises à jour.
La bonne approche pour une PME est pragmatique : un inventaire à jour du parc, une classification simple (postes / serveurs / réseau), des délais définis selon la criticité, et un outil de supervision qui centralise l’état des mises à jour.
Pour outiller ce processus, nous avons retenu Action1 comme solution de référence. C’est la plateforme que nous déployons chez nos clients en infogérance. Elle permet de superviser l’ensemble du parc depuis une console unique, de planifier les déploiements par groupe de machines, de gérer les logiciels tiers au même titre que Windows, et de générer des rapports de conformité consultables à tout moment. Les patchs critiques sont traités sous 48 heures, sans intervention nécessaire du côté du client.
Ce qui nous a convaincus chez Action1, c’est la lisibilité de la console et la granularité du contrôle : on peut décider machine par machine, ou par groupe, avec des fenêtres de déploiement configurables pour ne jamais intervenir en heures de production sans l’avoir prévu.
Ce n’est pas la seule solution du marché, mais c’est celle qui correspond le mieux aux contraintes réelles des PME que nous accompagnons : déploiement rapide, sans infrastructure lourde, et pilotable à distance.
Si vous ne savez pas précisément dans quel état se trouve votre parc aujourd’hui, contactez-nous pour un audit sans engagement.
