L'exploit n'est plus le goulot : avec l'IA, le délai de correction fixe votre risque

Le 5 novembre 2026, Asaf Ezra et Stephenie Zhang, associés d'Andreessen Horowitz (a16z), ont publié The Exploit Was the Bottleneck¹. Leur thèse : pendant vingt ans, ce qui limitait les attaques n'était pas de trouver une faille mais d'en tirer un exploit qui fonctionne. L'IA a rendu cette étape rapide et bon marché, la correction n'a pas accéléré, et le goulot est passé du côté du défenseur. Les auteurs écartent la catastrophe (« le réseau électrique ne va pas s'éteindre ») et décrivent un risque qui se concentre sur ce qui se corrige lentement. Notre lecture, pour une DSI : le délai de correction devient un indicateur de risque métier, et le code que vous êtes seul à pouvoir corriger passe en tête de liste.

L'exploit s'écrit en heures, la correction prend toujours des semaines

En 2017, une étude de la RAND Corporation portant sur plus de 200 failles zero-day mesurait une médiane de 22 jours pour qu'un professionnel écrive un exploit fonctionnel². Cette compétence rare réglait le rythme des attaques.

Mandiant suit le délai moyen entre la sortie du correctif d'une faille et sa première exploitation, avant ou après cette sortie. Il était de 63 jours en moyenne en 2018-2019, de 44 jours entre 2020 et début 2021, de 32 jours en 2021-2022, puis de 5 jours en 2023³. Ce dernier chiffre exclut quinze valeurs extrêmes : avec elles, la moyenne remonte à 47 jours, précise Mandiant. Dans M-Trends 2026, publié en mars 2026, la moyenne estimée pour 2025 tombe à moins 7 jours : en moyenne, l'exploitation précède le correctif⁴. VulnCheck arrive au même constat par un autre chemin : 28,96 % des 884 vulnérabilités exploitées recensées en 2025 l'ont été le jour de la publication de leur CVE ou avant⁵.

Les laboratoires d'IA documentent la suite. En mars 2026, Anthropic indiquait que Claude Opus 4.6 avait produit deux exploits contre Firefox en plusieurs centaines d'essais, pour environ 4 000 dollars de crédits d'API⁶. Anthropic les qualifie de rudimentaires : ils ne fonctionnaient que dans un environnement de test privé de certaines protections du navigateur, dont le bac à sable. En juin, Claude Mythos Preview écrivait, à partir d'un correctif publié, un premier exploit contre SpiderMonkey, le moteur JavaScript de Firefox, en un peu moins d'une heure, puis huit en douze heures environ. Sur le noyau Windows, sans accès au code source, il produisait huit escalades de privilèges pour 15 700 dollars, soit environ 2 000 dollars chacune⁷. L'AI Security Institute britannique mesurait en mai 2026 que la longueur des tâches cyber que les modèles mènent seuls double tous les 4,7 mois depuis fin 2024, en précisant que cette tendance ne vaut pas prédiction⁸.

Côté correction, la courbe est plate. En 2003, Qualys mesurait une demi-vie de 30 jours pour les vulnérabilités critiques : le temps qu'il faut pour corriger la moitié des systèmes exposés⁹. Sur les données de 2008, elle était toujours de 30 jours¹⁰. Le Data Breach Investigations Report 2026 de Verizon fixe à 43 jours le délai médian pour corriger entièrement une vulnérabilité du catalogue KEV de la CISA (les failles dont l'exploitation est avérée), contre 32 jours dans l'édition précédente ; 26 % seulement de ces failles avaient été entièrement corrigées, contre 38 % un an plus tôt¹¹. Dans l'industrie, Dragos relève que 26 % des avis de sécurité de 2025 ne s'accompagnaient d'aucun correctif ni d'aucune mesure d'atténuation de l'éditeur¹².

PaperCut : quatre heures et un modèle qui n'était pas frontier

Le cas qui sert de fil à l'article d'a16z est documenté par GreyNoise le 9 septembre 2026¹³. Le 27 août, PaperCut, éditeur de logiciels de gestion d'impression très répandus dans les écoles et les bureaux, publie un avis pour deux failles : CVE-2026-81578, un contournement d'authentification, et CVE-2026-82078. Le 31 août, un opérateur ouvre un espace de travail et lance des centaines d'agents dans le harnais Codex d'OpenAI, animés par un modèle DeepSeek et non par un modèle OpenAI, précise GreyNoise. En un peu moins de quatre heures, il obtient une première exécution de code à distance chez une vraie victime. Le 1er septembre, la campagne compromet au moins onze organisations en 26 secondes.

Le bilan de GreyNoise : au moins 440 serveurs PaperCut compromis, appartenant à 395 organisations identifiées dans 48 pays. L'enseignement représente 204 de ces 440 serveurs, surtout aux États-Unis, ce qui peut refléter la clientèle de PaperCut, note GreyNoise. L'opérateur avait tenté d'épargner 28 pays ; la consigne n'a pas toujours été respectée. Il n'a obtenu les droits d'administrateur de domaine que dans douze organisations. a16z arrondit ces chiffres (« la moitié des écoles », « 12 des 440 victimes ») ; nous reprenons ceux de la source.

Deux leçons. L'attaque n'a pas eu besoin d'un modèle frontier : a16z souligne qu'il ne s'agissait pas d'un modèle d'un laboratoire américain de pointe, et tout ce que l'on dira du contrôle d'accès aux modèles les plus puissants ne change rien à ce scénario. Ensuite, l'exploitation a rarement mené à la prise de contrôle du domaine : 12 organisations sur 395 ont perdu le contrôle de leur réseau.

Plus personne n'est trop petit pour être ciblé

L'argument le plus utile du texte porte sur l'économie de l'attaque. « Les petites organisations n'ont jamais échappé aux attaques de masse, mais elles échappaient aux attaques menées à la main », écrivent les auteurs¹. Une intrusion manuelle coûtait trop de temps humain pour ce qu'une PME pouvait rapporter. L'IA baisse le coût de chaque étape, de la reconnaissance à la monétisation, et a16z s'attend à ce que le seuil de rentabilité descende jusqu'aux cabinets dentaires, aux collectivités et aux petits industriels.

Les prix suivent. Selon Chainalysis, sur des données de Darkweb IQ, le prix moyen d'un accès au réseau d'une victime est passé d'environ 1 427 dollars au premier trimestre 2023 à 439 dollars au premier trimestre 2026 . Les rançons payées en 2025 ont dépassé 820 millions de dollars, en baisse de 8 % sur 2024, alors que le nombre de victimes revendiquées sur les sites de fuite a augmenté de 50 % ; a16z y lit le signe d'attaques qui descendent vers des cibles plus petites¹⁴. Le DBIR 2025 de Verizon trouvait déjà un rançongiciel dans 88 % des incidents touchant des PME, contre 39 % dans les grandes organisations¹⁵. Dans la santé, Comparitech a compté 306 attaques sur le secteur au troisième trimestre 2026, soit 3,33 par jour, un plus haut ; 192 visaient des hôpitaux, cliniques et autres établissements de soins, dont 40 confirmées¹⁶.

Le texte signale un second déplacement, plus discret. Pour un État, rappelle a16z, le frein à une attaque contre un réseau électrique a toujours été l'intention. Hacktivistes, groupes terroristes et faux-nez avaient l'intention ; il leur manquait la capacité, et l'IA la leur apporte. Les auteurs s'attendent à davantage d'attaques destructrices : « un wiper ne demande rien », et les montants de rançon sous-estimeront alors les dégâts.

Les limites de l'article d'a16z

a16z ne prédit pas d'effondrement. Les auteurs rappellent que Metasploit en 2003 et Shodan en 2009 devaient armer tous les amateurs, et qu'internet a survécu aux deux. WannaCry a frappé 59 jours après la publication du correctif et perturbé 81 des 236 groupements hospitaliers anglais¹⁷. Les grandes plateformes savent réagir : selon a16z, pendant PHP2Shell, hébergeurs et réseaux de diffusion ont bloqué les attaques en bordure en moins d'une journée, pour des millions de sites. Le risque se loge dans la longue traîne : hôpitaux, collectivités, PME, systèmes industriels.

Trois réserves. Les résultats des laboratoires « viennent surtout des développeurs d'IA eux-mêmes et sont obtenus sans défenseurs actifs », reconnaissent les auteurs : ils expliquent une tendance, ils ne la prouvent pas. Plusieurs chiffres de l'article s'écartent de leur source : outre PaperCut, les huit escalades Windows d'Anthropic n'ont pas été obtenues « en 18 heures » (la page d'Anthropic ne donne aucune durée totale), et le « record » de Comparitech porte sur le secteur de la santé dans son ensemble, pas sur les 192 attaques contre les établissements de soins. Enfin, c'est un fonds d'investissement qui écrit ; le texte annonce un prochain article sur ce qu'il faudra faire. Les mentions légales d'a16z rappellent que certaines informations viennent de sociétés de son portefeuille, sans détailler lesquelles.

Le constat central tient pourtant sans a16z : les séries de Mandiant, de VulnCheck, de Qualys et de Verizon suffisent à le dessiner.

Défragiliser : réduire ce qui attend un correctif

a16z propose deux réponses. Corriger à la vitesse de la machine, mais seulement là où une mise à jour coûte peu à appliquer et peu à annuler : logiciels opérés par l'éditeur, navigateurs et téléphones qui se mettent à jour seuls. Ailleurs, quand corriger impose d'arrêter un procédé physique ou de recertifier un dispositif médical, rendre la vulnérabilité inaccessible : isolation, segmentation, protection au niveau du réseau, et repli manuel sûr quand tout cela échoue. Aller vite a ses propres risques : en juillet 2024, une mise à jour défectueuse de CrowdStrike a touché 8,5 millions de machines Windows, selon Microsoft¹⁸. Corriger vite suppose un retour arrière testé.

a16z oublie une troisième catégorie : votre propre code. L'article raisonne sur des logiciels d'éditeurs : une faille publiée, un correctif livré, un délai pour l'appliquer. Votre code interne n'a pas d'éditeur. Personne ne publiera de CVE pour votre back-office, personne ne livrera de correctif pour l'application métier écrite il y a douze ans par un prestataire parti depuis. Votre délai de correction commence le jour où quelqu'un trouve la faille, et ce quelqu'un dispose désormais des mêmes agents que vous pour lire le code ou le binaire (voir ce que la rétro-ingénierie par agents change pour les équipes sécurité). Défragiliser ce code consiste à en réduire le stock de failles avant que quelqu'un d'autre ne les trouve.

Ce que vous exploitez	Exemples	Réponse
Logiciel mis à jour de façon centralisée	SaaS, navigateurs, postes et mobiles gérés	Corriger en heures, avec un retour arrière testé
Logiciel d'éditeur lent ou impossible à corriger	Appliances exposées, systèmes industriels, dispositifs médicaux	Rendre la faille inaccessible : segmentation, isolation, filtrage, procédure manuelle de repli
Code que vous possédez	Legacy, applicatifs internes, code sous-traité	Chercher et corriger avant un autre : relecture en boîte blanche par agents, preuve de chaque faille par un test, correctif livré

Ce travail sort du patch management. Google propose CodeMender, Anthropic Claude Mythos, et des modèles à poids ouverts tournent sur place quand le code ne doit pas sortir. Bank of America a mobilisé 1 000 prestataires pour corriger ce que ces modèles ont trouvé : la recherche va plus vite, mais corriger, tester et livrer reste un travail d'ingénierie, et votre délai en dépend.

Ce que ça change pour vous

DSI et direction générale

Le délai médian de correction des failles exploitées devient un chiffre à suivre au comité de direction, au même titre qu'une disponibilité. a16z en fait un de ses indicateurs : sous 30 jours dans le DBIR 2028, les défenseurs se seront adaptés ; au-dessus de 60, la fenêtre d'exposition décidera de tout. Mesurez le vôtre, par catégorie de système, avant de le comparer aux 43 jours de Verizon.

RSSI

Le catalogue KEV de la CISA ne suffit pas comme référence : en 2025, VulnCheck a recensé 884 vulnérabilités exploitées, quand la CISA en ajoutait 245 à son catalogue⁵. Croisez plusieurs sources de renseignement sur l'exploitation active. Puis trois inventaires : ce qui est exposé sur internet, ce qui ne se corrige pas en quelques jours, et le code maison que personne n'a relu depuis sa mise en production. Le deuxième appelle segmentation et procédures de repli, préparées avant l'incident ; un hôpital qui ne sait plus travailler sur papier n'a pas de repli. Le troisième appelle une campagne de relecture, legacy d'abord, à relancer à chaque nouveau modèle.

CTO et architectes

Un correctif livré en heures suppose une chaîne de livraison qui le permet : tests automatisés, déploiement progressif, retour arrière en un geste (voir une CI/CD ultra-robuste). Une application qui demande trois semaines de recette pour une ligne modifiée a déjà perdu la course, quelle que soit la vitesse à laquelle la faille a été trouvée.

Questions fréquentes

L'IA multiplie-t-elle les failles exploitées ou seulement leur vitesse ?

Surtout la vitesse, pour l'instant. VulnCheck comptait 639 vulnérabilités exploitées en 2023 et 884 en 2025. a16z fixe un seuil : au-dessus de 2 000 en 2027, l'effondrement du coût de l'attaque se verra aussi dans les volumes.

Faut-il un modèle frontier pour mener ce type d'attaque ?

Non. La campagne PaperCut a utilisé un modèle DeepSeek dans un harnais d'agents du commerce. Restreindre l'accès aux modèles les plus puissants ne protège pas contre ce scénario.

Corriger plus vite suffit-il ?

Là où la mise à jour est bon marché et réversible, oui, à condition de savoir revenir en arrière. Ailleurs, il faut rendre la faille inaccessible. Pour le code que vous possédez, il faut la trouver avant l'attaquant : aucun éditeur ne le fera pour vous.

Par où commencer ?

Par mesurer votre délai de correction réel sur les failles du catalogue KEV, puis par l'application interne la plus ancienne encore exposée.

Sources

1. Asaf Ezra et Stephenie Zhang (a16z), The Exploit Was the Bottleneck — a16z.com, 5 novembre 2026.
2. Lillian Ablon et Andy Bogart (RAND Corporation), étude sur plus de 200 zero-days, rapportée par phys.org, 9 mars 2017.
3. Mandiant (Google Threat Intelligence), How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends — cloud.google.com, 15 octobre 2024.
4. Mandiant, M-Trends 2026 — cloud.google.com, 23 mars 2026.
5. VulnCheck, State of Exploitation 2026 — vulncheck.com, 21 janvier 2026 ; chiffre 2023 : 2024 Exploitation Trends, février 2025.
6. Anthropic, Mozilla Firefox security — anthropic.com, 6 mars 2026.
7. Anthropic, n-days — anthropic.com, 8 juin 2026.
8. AI Security Institute, How fast is autonomous AI cyber capability advancing? — aisi.gov.uk, 13 mai 2026.
9. Qualys, communiqué sur les Laws of Vulnerabilities — qualys.com, 30 juillet 2003.
10. Qualys, Laws of Vulnerabilities 2.0 (données 2008), présenté par Wolfgang Kandek — qualys.com, 23 avril 2009.
11. Verizon, 2026 Data Breach Investigations Report — verizon.com.
12. Dragos, 2026 OT/ICS Cybersecurity Year in Review, communiqué — dragos.com, 17 février 2026.
13. GreyNoise, AI-orchestrated campaign against PaperCut NG/MF — greynoise.io, 9 septembre 2026.
14. Chainalysis, Crypto ransomware 2026 — chainalysis.com, 26 février 2026.
15. Infosecurity Magazine, sur le DBIR 2025 de Verizon — infosecurity-magazine.com, 24 avril 2025.
16. Comparitech, Healthcare ransomware roundup Q3 2026 — comparitech.com, mis à jour le 15 octobre 2026.
17. National Audit Office, Investigation: WannaCry cyber attack and the NHS — nao.org.uk, 2017.
18. David Weston (Microsoft), Helping our customers through the CrowdStrike outage — blogs.microsoft.com, 20 juillet 2024.