Trois heures et quarante-quatre minutes. C'est le temps qu'il a fallu, le 11 mai 2026, pour qu'une CVE PraisonAI fraîchement publiée soit scannée à l'échelle planétaire. Ce chiffre n'est pas un record isolé : c'est la nouvelle normalité. Et il rend obsolète à peu près tous les plans de patching que j'audite encore en 2026.

Le mythe des 90 jours est mort. Celui des 30 jours aussi.

Pendant une décennie, le standard implicite du patching a été de 30 jours pour les vulnérabilités critiques, parfois 90 pour les autres. Beaucoup de référentiels — y compris ceux que je vois encore dans les politiques de sécurité chez mes clients — codifient toujours ces fenêtres. Elles étaient bâties sur l'hypothèse que la "weaponisation" d'une CVE, c'est-à-dire le temps entre la publication d'un advisory et l'apparition d'un exploit fonctionnel utilisable à grande échelle, prenait au moins quelques semaines.

En 2026, cette hypothèse n'a plus aucun sens. Les chiffres compilés par les équipes threat intel le confirment, et les exemples des deux dernières semaines sont presque caricaturaux : PraisonAI scannée en 3h44, Ivanti EPMM exploitée en quelques heures, Cisco Catalyst SD-WAN livrée avec un acteur étatique déjà à l'œuvre avant même la publication du correctif. Les attaquants ont industrialisé la chaîne entre advisory et exploitation. Les défenseurs, eux, restent calés sur des cycles trimestriels.

Pourquoi c'est allé si vite

Trois facteurs convergent. D'abord, l'écosystème offensif a internalisé l'IA. Là où il fallait un développeur expérimenté pour transformer un advisory technique en sonde fonctionnelle, on a aujourd'hui des chaînes automatiques où un LLM lit le diff GitHub, génère un PoC plausible et le branche sur un orchestrateur de scan. Le tooling CVE-Detector/1.0 vu par Sysdig sur l'incident PraisonAI en est l'illustration : un nom, une signature, et probablement un pipeline qui se met à jour quasi en temps réel sur les flux GitHub Advisory.

Ensuite, la surface d'attaque a explosé en visibilité. Shodan, Censys, FOFA et leurs équivalents permettent aujourd'hui d'énumérer la totalité des instances d'un produit donné en quelques requêtes. Quand l'advisory tombe, l'attaquant n'a pas besoin de chercher : sa liste de cibles est déjà constituée. Il ne lui reste qu'à pousser le payload.

Enfin, la mondialisation des outils offensifs a réduit la barrière à l'entrée. Un acteur opportuniste avec accès à un kit d'exploit privé peut désormais couvrir un parc mondial avec la même infrastructure cloud qu'un service marketing. La logistique offensive est devenue commodité.

Ce que ça change pour la défense

Le patching ne peut plus être un processus mensuel délégué à l'IT et validé par le RSSI. C'est devenu un flux continu qui doit cohabiter avec une infrastructure de mitigation immédiate. J'identifie quatre changements à opérer dans les organisations que j'accompagne, et qui sont déjà acquis chez les structures les plus matures.

1. Découpler patch et exposition

Quand un patch n'est pas applicable en moins de 24 heures, il faut pouvoir réduire l'exposition autrement : retrait temporaire de l'interface concernée d'Internet, restriction par allowlist IP, mise sous WAF avec règle dédiée à la CVE. Ce sont des actions qui doivent être préapprouvées par le métier, documentées dans un runbook et exécutables par l'équipe SOC sans validation hiérarchique en urgence. Si chaque action requiert un comité de pilotage, vous êtes déjà compromis.

2. Investir dans la visibilité asset

La plupart des organisations que j'audite ne savent pas, à la minute près, quelles versions de quel produit tournent où dans leur SI. Sans cette visibilité, le délai de réaction à une CVE est dominé par la phase de découverte : trouver les serveurs vulnérables, identifier les responsables, obtenir les accès, coordonner. Un CMDB tenu à jour et un inventaire produit fiable valent dix outils EDR exotiques pour la réactivité réelle.

3. Repenser le scoring

CVSS reste utile mais ne capture plus la vélocité réelle d'exploitation. EPSS (Exploit Prediction Scoring System) et les flux KEV de CISA donnent une mesure plus pragmatique : "qu'est-ce qui est exploité réellement maintenant" l'emporte sur "qu'est-ce qui pourrait théoriquement l'être". Les politiques de patching doivent intégrer ces signaux et accélérer agressivement sur les CVE marquées KEV.

4. Préparer l'arrêt

Pour certains produits — pensez aux équipements de bordure et aux plans de management critiques — il faut accepter que la seule réponse à une CVE critique non patchable immédiatement, c'est l'arrêt temporaire du service. Préparer l'organisation à ce que cette décision soit prenable en cellule de crise, avec un impact métier identifié à l'avance, c'est une discipline opérationnelle. Pas une discussion technique.

Le cas particulier des frameworks IA open-source

Une catégorie de cibles est particulièrement exposée à ce changement de tempo : les frameworks AI/agentic récents. Leur croissance fulgurante attire les attaquants, leur jeunesse logicielle multiplie les défauts, et leur exposition cloud-first les rend triviales à scanner. PraisonAI cette semaine, Ollama il y a quelques jours, LangChain et consorts dans les mois précédents. Le pattern est constant : produit jeune et populaire, API ouverte par défaut, clés d'API LLM dans l'environnement, factures à cinq chiffres qui apparaissent en 24 heures après compromission.

Les organisations qui déploient des POC IA doivent intégrer dans leur cycle de provisionnement les contrôles élémentaires que l'on impose depuis vingt ans aux serveurs web : pas d'exposition Internet par défaut, pas de secrets en environnement clair, monitoring de la consommation de tokens. Le réflexe "c'est juste un POC" est devenu un risque cyber et financier réel.

Mon avis d'expert

La majorité des plans de patching que je revois en audit en 2026 sont encore calés sur des fenêtres pensées pour le monde de 2019. Quand je demande aux RSSI ce qu'ils feraient si une CVE critique tombait à 17h un vendredi sur un de leurs produits critiques, j'obtiens dans 80% des cas une réponse molle : "on regarderait lundi". Lundi, c'est trois jours après votre compromission. Le tempo a changé, et les politiques doivent suivre — pas dans six mois, maintenant.

Conclusion

L'incident PraisonAI du 11 mai 2026 n'est pas une anomalie. C'est la nouvelle normalité, et chaque CVE critique des semaines à venir le confirmera. La fenêtre de patching utile est passée de quelques semaines à quelques heures, et les organisations qui n'opèrent pas leur transition payeront cash. Patcher reste indispensable. Mais patcher seul ne suffit plus : il faut savoir réduire l'exposition, isoler les actifs critiques, et accepter que certaines décisions d'arrêt préventif fassent partie de l'arsenal défensif normal.

Vos processus de patching tiennent-ils la cadence ?

Si vos politiques de patch parlent encore en jours plutôt qu'en heures, parlons-en. J'aide les équipes sécurité à industrialiser leur réponse aux CVE critiques avec un focus sur la réduction d'exposition immédiate.

Prendre contact