Introduction

Je vais commencer par une anecdote. En 2017, un vendredi après-midi, j’ai reçu un appel d’un client que j’accompagnais depuis deux ans sur son infra VMware. Le responsable IT était en panique : une trentaine de serveurs venaient de tomber en cascade, les écrans affichaient un message de rançon, et personne ne comprenait ce qui se passait.

C’était WannaCry.

Le patch qui corrigeait la faille exploitée — MS17-010, pour ceux qui s’en souviennent — avait été publié par Microsoft deux mois avant l’attaque. Deux mois. Soixante jours pendant lesquels ce correctif était disponible, téléchargeable, documenté. Et il n’avait pas été appliqué, parce que « on ne patche pas en période de clôture comptable ».

Depuis ce jour-là, quand quelqu’un me dit que le patch management est un sujet secondaire, je repense à ces écrans rouges.

Le patching, c’est pas sexy. Mais c’est vital.

Soyons honnêtes : dans la hiérarchie des sujets qui passionnent un ingénieur infra, le patch management se situe quelque part entre la gestion des tickets de niveau 1 et l’inventaire des licences. C’est répétitif, c’est contraignant, ça oblige à planifier des fenêtres de maintenance à 3h du matin, et quand tout se passe bien… personne ne le remarque.

Et pourtant, si on regarde les incidents de sécurité majeurs de ces dernières années, le constat est accablant. La grande majorité des attaques réussies exploitent des vulnérabilités connues pour lesquelles un correctif existait. Pas des zero-days sophistiqués. Pas de l’ingénierie sociale digne d’un film d’espionnage. Non : des failles documentées, référencées dans les bases CVE, avec un patch disponible depuis des semaines ou des mois.

Le problème n’est presque jamais technique. Le problème, c’est l’organisation.

Les vraies raisons pour lesquelles on ne patche pas les vraies raisons pour lesquelles on ne patche pas

En quinze ans de missions sur des infrastructures de toutes tailles — de la PME industrielle avec ses trois serveurs dans un placard à climatisation douteuse, au grand compte avec 8 000 postes et une DSI de 200 personnes — j’ai entendu toutes les excuses. Et paradoxalement, les grands comptes ne sont pas meilleurs que les PME sur ce sujet. Parfois même pires, parce que la bureaucratie ajoute des couches de validation qui ralentissent tout.

« On n’a pas le temps »

C’est la raison numéro un. Les équipes infra sont noyées sous le run, les incidents du quotidien, les demandes métier. Le patching passe systématiquement en dernière priorité parce qu’il n’y a pas de ticket Jira urgent qui dit « appliquer le patch KB5034441 ». C’est un travail de fond, invisible, et les équipes sont évaluées sur la disponibilité du SI, pas sur sa sécurité.

« On a peur de casser la prod »

C’est la raison la plus légitime. On a tous vécu un patch Windows qui fait planter un applicatif métier, ou une mise à jour firmware qui rend un switch inaccessible. La peur du régressif est réelle, et elle est nourrie par des expériences traumatisantes. Sauf que cette peur conduit à un comportement irrationnel : on préfère un risque certain (la vulnérabilité non corrigée) à un risque incertain (la régression potentielle). C’est un biais cognitif classique, et il faut le nommer pour le combattre.

« Le métier refuse les fenêtres de maintenance »

Dans les secteurs où le SI tourne 24/7 — logistique, e-commerce, industrie, hôtellerie — obtenir un créneau de maintenance est un combat politique. J’ai vu des DSI attendre trois mois pour obtenir une fenêtre de 2h un dimanche à 4h du matin. Trois mois pendant lesquels une faille critique restait ouverte. La solution n’est pas de renoncer : c’est de négocier ces fenêtres en amont, de les inscrire au contrat de service, et d’avoir un environnement de pré-production qui permet de tester sans impacter le business.

« On n’a pas de visibilité sur notre parc »

Celui-là, c’est le plus triste. Combien de machines avez-vous ? Quelles versions d’OS ? Quels firmwares ? Si vous ne pouvez pas répondre à ces questions en moins de 10 minutes, vous avez un problème d’inventaire avant d’avoir un problème de patching. On ne peut pas patcher ce qu’on ne connaît pas.

Ce que coûte réellement le non-patching

Je ne vais pas vous noyer sous les statistiques. Juste trois chiffres qui parlent d’eux-mêmes.

Le coût médian d’une attaque par ransomware en France en 2024, selon le dernier rapport de l’ANSSI, dépasse les 250 000 euros pour une ETI. Ce chiffre inclut la remise en état, la perte d’exploitation, et les frais juridiques. Il n’inclut pas l’impact réputationnel, qui est souvent pire.

Le temps moyen entre la publication d’un patch critique et son exploitation active par les attaquants est passé de 45 jours en 2020 à moins de 15 jours en 2025. Quinze jours. C’est le délai que vous avez pour patcher avant que la faille ne soit utilisée dans la nature. Et ce délai se réduit chaque année, en partie à cause de l’IA qui accélère le développement d’exploits.

Dernièrement, la directive NIS2 — qui s’applique désormais à un périmètre bien plus large d’entreprises françaises — fait explicitement référence à la gestion des vulnérabilités comme obligation. Ne pas patcher, ce n’est plus seulement un risque technique : c’est un risque de non-conformité réglementaire.

Comment mettre en place un vrai processus de patch management

Le patching n’est pas un projet. C’est un processus continu, et il doit être traité comme tel. Voici comment je recommande de structurer ça, après l’avoir déployé chez une vingtaine de clients.

1. Connaître son parc — exhaustivement

Avant de parler de patching, il faut un inventaire fiable. Pas un fichier Excel maintenu à la main qui date de 2019. Un vrai outil de découverte qui scanne le réseau et remonte les OS, les versions, les firmwares, les applicatifs. GLPI, Lansweeper, SCCM, ou même un bon vieux script Nmap — peu importe l’outil, ce qui compte c’est la rigueur de l’inventaire.

J’insiste sur les équipements réseau et les firmwares. On parle beaucoup du patching Windows et Linux, mais j’ai vu des compromissions passer par des switchs Cisco avec un firmware de 2018 ou des appliances de sécurité (ironie…) jamais mises à jour. Les firewalls Fortinet, les VPN Pulse Secure, les ESXi VMware — tout ce qui est exposé au réseau doit être dans le périmètre de patching.

2. Prioriser par criticité et exposition

Tous les patchs ne se valent pas. Il y a le patch nice to have qui corrige un bug d’affichage, et il y a le correctif critique pour une faille RCE sur un serveur exposé à Internet. Les deux n’appellent pas le même niveau d’urgence.

Ma règle de terrain : les vulnérabilités avec un score CVSS supérieur à 9 et un exploit public doivent être traitées en 72h maximum sur les équipements exposés. Les vulnérabilités CVSS 7-9 ont un délai de 15 jours. Le reste suit le cycle mensuel. C’est simple, c’est compréhensible par le management, et ça fonctionne.

3. Tester avant de déployer — mais vite

Le pré-production est non négociable. On ne déploie pas un patch critique un vendredi soir directement sur le serveur de facturation. On le teste d’abord sur un environnement représentatif, on vérifie que les applicatifs métier ne tombent pas, et ensuite on déroule.

Mais attention au piège : certaines organisations ont transformé la phase de test en excuse pour ne jamais déployer. « On est en phase de validation » devient un statut permanent. La règle : si le test dure plus de 5 jours ouvrés, c’est qu’il y a un problème de processus, pas un problème technique.

4. Automatiser ce qui peut l’être

Sur un parc de 200 machines, vous pouvez encore patcher à la main (même si c’est une mauvaise idée). Au-delà de 500, c’est humainement impossible sans automatisation. WSUS ou SCCM pour Windows, Ansible ou SaltStack pour Linux, les consoles constructeurs pour le firmware réseau — les outils existent et sont matures.

Le vrai défi n’est pas l’outil. C’est la confiance dans l’automatisation. J’ai vu des équipes mettre en place Ansible pour le patching… puis valider manuellement chaque playbook avant exécution, annulant tout le bénéfice. Il faut accepter de déléguer à l’outil, quitte à prévoir des mécanismes de rollback automatiques en cas de problème.

5. Mesurer et rendre des comptes

Un KPI simple et efficace : le pourcentage de machines à jour par rapport aux patchs critiques publiés dans les 30 derniers jours. Si ce chiffre est en dessous de 90%, vous avez un problème. S’il est en dessous de 70%, vous êtes en zone rouge.

Ce KPI doit remonter au RSSI ou au DSI, pas rester enfoui dans un rapport technique que personne ne lit. Le patch management est un sujet de gouvernance, pas seulement un sujet d’exploitation.

Le cas particulier des environnements legacy

Je ne peux pas écrire un article sur le patching sans aborder l’éléphant dans la pièce : les systèmes en fin de vie.

Windows Server 2012 R2, qui a atteint sa fin de support en octobre 2023. ESXi 6.7, officiellement EOL. Des Debian 9 qui tournent encore en production. Des applications métier développées en interne il y a 15 ans, qui ne fonctionnent que sur Java 8 et refusent de tourner sur quoi que ce soit de plus récent.

Ces systèmes ne reçoivent plus de patchs. Ils sont exposés à toutes les vulnérabilités futures sans aucun correctif possible. Et pourtant, ils continuent de tourner, parce que le coût de migration est considéré comme trop élevé.

La réalité, c’est que le coût de ne PAS migrer est souvent supérieur. On le réalise juste trop tard, généralement quand le CERT-FR publie un avis critique qui concerne précisément cette vieille version qu’on aurait dû remplacer l’année dernière.

Pour les systèmes qui ne peuvent vraiment pas être migrés à court terme, la stratégie de confinement est la seule option raisonnable : segmentation réseau stricte, monitoring renforcé, désactivation des services inutiles, et un plan de migration avec une date de fin. Pas un « on verra l’année prochaine », une vraie date dans un vrai planning.

Un mot sur le contexte NIS2

Depuis la transposition de la directive NIS2, la gestion des vulnérabilités n’est plus une recommandation. C’est une obligation pour un périmètre élargi d’entreprises — incluant désormais de nombreuses ETI et des secteurs qui ne se sentaient pas concernés jusqu’ici (alimentation, gestion des déchets, fabrication…).

Concrètement, ça signifie que lors d’un audit de conformité, on vous demandera : quel est votre processus de patch management ? Quel est votre délai moyen d’application des correctifs critiques ? Pouvez-vous démontrer que vos équipements exposés sont à jour ?

Si la réponse est un silence gêné suivi de « on fait au mieux », c’est insuffisant. Les sanctions prévues par NIS2 peuvent atteindre 10 millions d’euros ou 2% du chiffre d’affaires mondial. Ce n’est plus un sujet optionnel.

En conclusion : patchez, ou soyez patchés

Le patch management n’est pas un sujet technique complexe. Les outils existent, les méthodologies sont documentées, et les bonnes pratiques sont connues depuis des années. Ce qui manque, dans l’écrasante majorité des cas, c’est la volonté organisationnelle de traiter ce sujet comme ce qu’il est : la première ligne de défense de votre infrastructure.

Quand je fais un audit d’infrastructure, la première chose que je regarde, avant même la topologie réseau ou les règles de firewall, c’est le niveau de patching du parc. C’est le thermomètre le plus fiable de la maturité sécuritaire d’une organisation. Un parc bien patché me dit que l’équipe est rigoureuse, que les processus sont en place, et que la direction a compris les enjeux. Un parc en retard de 6 mois me dit tout l’inverse.

Alors oui, c’est contraignant. Oui, ça demande du temps, de la rigueur, et parfois des négociations difficiles avec le métier. Mais l’alternative, c’est d’attendre le prochain WannaCry en croisant les doigts. Et les doigts croisés, ça n’a jamais été une stratégie de sécurité.

i-lead Consulting

Cabinet de conseil et d’expertise en infrastructure & cybersécurité

www.i-lead.fr