L’IA a rendu la chasse aux failles presque bon marché. Bonne nouvelle : plus de bugs remontent, plus tôt 🧯. Mauvaise nouvelle : le rythme de correction, lui, reste humain, donc lent. Résultat : les RSSI se retrouvent à gérer un stock de vulnérabilités qui grossit, pendant que les cycles de mises à jour s’emballent.
Quand l’IA repère les failles plus vite que leur correction : pourquoi les RSSI perdent la bataille du tempo
Avant, une équipe sécurité pouvait vivre avec l’idée qu’il y aurait “quelques” failles critiques à traiter vite. Le reste passait par des fenêtres de maintenance, des gel de versions, et des priorités lisibles. Cette époque se ferme, parce que l’IA a cassé l’économie de la découverte 🔎.
Le changement n’a rien de magique : un modèle peut lire, tester, fuzz-er, et recracher des rapports à la chaîne. Là où un humain choisissait ses cibles, une machine arrose large. Et l’écart se creuse : la détection accélère, le tri et la correction s’étouffent.
Le point dur n’est pas “trouver des failles”. C’est décider lesquelles comptent, lesquelles sont exploitables, et lesquelles vont brûler ton week-end si tu patches trop vite.
Le cas Apple : même les gros finissent submergés par les rapports générés par IA
Quand une entreprise de la taille d’Apple commence à freiner, ça en dit long. Au début de l’été, Apple a prévenu des chercheurs : limitation du volume de signalements soumis à l’équipe sécurité interne. Si un chercheur tombe sur une vulnérabilité grave mais dépasse le quota… retour à la case départ le mois suivant ⏳.
Ça ne veut pas dire “Apple s’en fiche”. Ça dit plutôt : le goulot d’étranglement se déplace vers l’attention humaine. Lire un rapport, le reproduire, vérifier qu’il ne s’agit pas d’un doublon, puis décider d’une correction, ça ne se parallélise pas à l’infini.
Et pour une entreprise “normale”, l’écart est pire. Tu n’es ni Google ni Apple : pas la même force de frappe, pas la même capacité à patcher un navigateur ou un OS à cadence industrielle.
Ce frein côté éditeurs se répercute partout : entreprises, administrations, et utilisateurs. Quand le robinet de rapports s’ouvre, le reste de la chaîne reçoit la pression.
La vague des correctifs en 2026 : Patch Tuesday, Linux et l’inflation des CVE
La meilleure preuve, c’est la taille des bulletins. En juillet, Microsoft a livré un Patch Tuesday à 570 correctifs, dont trois zero-day 🧨. Record, et probablement pas le dernier, parce que Microsoft l’a dit clairement : l’IA aide à trouver plus de failles, donc les clients verront des lots de mises à jour plus épais.
Ça ne signifie pas “Windows est moins sûr qu’avant”. Ça signifie que les méthodes de découverte ont changé. La surface analysée est plus grande, et le coût marginal de “tester une piste” baisse.
Le noyau Linux comme baromètre public : 432 CVE en deux jours
Linux a une particularité : beaucoup de discussions se voient, parce que les mainteneurs sont identifiés et parlent ouvertement. En juillet, 432 CVE signalées en deux jours sur le noyau ont servi d’électrochoc ⚡.
Ce n’est pas “un problème Linux”. C’est juste plus visible. Côté logiciels propriétaires, le volume existe aussi, mais il est noyé dans des notes de version vagues, ou des correctifs empaquetés.
Le signal à retenir : les scores de gravité perdent de leur valeur quand tout est “élevé” ou “critique”. À la fin, le RSSI doit juger l’exploitabilité réelle dans son contexte.
Et quand la fenêtre entre découverte et exploitation se ferme, la pression monte encore. Le sujet suivant, c’est le temps.
Exploitation avant correctif : le nouveau cauchemar des RSSI quand l’IA s’en mêle
Jim Zemlin (Linux Foundation) a lâché une phrase qui pique : le délai moyen d’exploitation est passé de 63 jours à -7 jours. Autrement dit, l’exploit arrive avant le patch 🚨. Ce n’est plus une course, c’est un départ en retard.
Dans cette situation, “attendre quelques jours avant d’installer une mise à jour” devient un luxe. Sur Windows, beaucoup avaient pris l’habitude de temporiser après certains patchs bancals, comme ceux qui ont mal tourné en janvier. Mais face aux zero-day qui circulent vite, serrer les dents et redémarrer devient parfois le moindre mal.
Greg Kroah-Hartman résume l’esprit du moment : si tu n’es pas sur une version stable à jour, tu n’es pas en sécurité. Ça s’applique désormais à peu près partout : OS, navigateurs, extensions, et applis.
Étude de cas : l’extension Acrobat dans Chrome et WhatsApp Web, la fuite “sans clic”
Un exemple concret aide à mesurer le risque. Une vulnérabilité dans une extension Chrome liée à Adobe Acrobat, connue sous le nom d’HermeticReader, a exposé des données WhatsApp Web à la simple visite d’une page piégée. Pas de clic, pas de téléchargement : la page déclenche un code dormant dans l’extension.
Les données récupérées ? liste de discussions, contacts, messages, nom de profil, contenu de conversation ouverte 📩. Bref, presque tout ce qui peut ruiner une vie privée ou une enquête interne.
Le détail qui fait froid : l’attaque a été construite en combinant trois vulnérabilités pour obtenir une écriture non authentifiée dans le stockage de l’extension depuis n’importe quelle page. Et l’automatisation a ensuite été facilitée via un modèle (DeepSeek) branché sur un framework agentique (Hermes Agent). Adobe a corrigé vite, mais ce scénario ne se terminera pas toujours aussi bien.
La leçon est simple : l’IA ne sert pas qu’à trouver des failles. Elle sert aussi à industrialiser leur exploitation.
Le vrai coût : le triage des rapports IA, et la fatigue qui s’installe dans les équipes
Un rapport faux n’est pas “gratuit”. Il faut le lire, tenter de le reproduire, vérifier les conditions, puis prouver qu’il ne tient pas. Ce temps-là, c’est de l’attention experte, et c’est ce qui manque le plus 🧠.
Le pire, c’est le flou : beaucoup de rapports générés par machine ont l’air crédibles. Ils exigent donc une vérification, même quand ils sont bancals, redondants, ou basés sur des hypothèses inapplicables.
Dans les entreprises, ça crée une boucle toxique : plus de rapports → plus de validation → moins de corrections structurelles → donc plus de surface d’attaque.
Tableau de bord RSSI : ce qui change concrètement entre “avant” et “après” la vague IA
| 📌 Sujet | 🕰️ Avant | ⚙️ Maintenant | 🎯 Risque RSSI |
|---|---|---|---|
| 🔎 Découverte de failles | Volume limité, recherche ciblée | Détection massive à faible coût via IA | Backlog qui gonfle et perte de visibilité |
| 🧪 Validation | Moins de bruit, plus de signal | Rapports crédibles mais souvent incomplets | Temps humain consommé par des faux positifs |
| 🧯 Patch management | Fenêtres de maintenance planifiables | Lots énormes (ex. 570 correctifs) et urgences | Instabilité, redémarrages, dette opérationnelle |
| ⏱️ Exploitation | Fenêtre de réaction de plusieurs semaines | Exploitation avant patch (jusqu’à -7 jours) | Risque d’incident malgré “bonnes pratiques” |
Et ce tableau a une conséquence directe : les équipes ne peuvent plus “traiter tout ce qui est critique” au sens CVSS. Il faut des signaux plus proches du terrain : exploit public, exposition Internet, privilèges, données touchées.
Pourquoi l’IA ne corrige pas tout : patchs risqués, régressions, et vulnérabilités ajoutées
La question revient souvent : si l’IA trouve, pourquoi elle ne répare pas ? Parce que corriger est plus difficile que détecter. Une correction touche au design, au comportement, et aux effets de bord. Un scanner, lui, peut se contenter de crier “danger” 🔔.
Une étude universitaire sur plus de 20 000 correctifs générés a montré un point gênant : des LLM grand public peuvent introduire près de neuf fois plus de nouvelles vulnérabilités que des développeurs humains. Et certaines suivent des schémas “nouveaux”, donc difficiles à repérer avec les règles classiques.
Même les outils spécialisés s’en sortent mieux sans être parfaits. Sur Python, un outil de correction automatique type PatchitPy tourne autour de 80% de réussite. C’est utile, mais pas assez pour lancer en prod sans garde-fous.
Trois règles de triage qui évitent de s’auto-saboter (inspirées des pratiques Google) ✅
- 🎯 Réduire le périmètre : demander des changements minimes (“mettre à jour la dépendance X en version Y”), pas “supprimer la vulnérabilité”.
- 🧪 Séparer correction et vérification : relancer scanners, fuzzers et tests ciblés après patch, pas juste “ça compile”.
- 👀 Garder l’humain sur le complexe : auth, droits, traitement de données, refactor multi-fichiers. L’IA fait un brouillon, l’ingénieur signe.
Ben Hawkes (ex-Projet Zero) résume bien le piège : une même faille peut être critique dans un déploiement, moyenne dans un autre, et quasi neutre ailleurs. Le contexte métier décide, pas la fiche CVE.
La réputation en jeu : ignorer les rapports ou paniquer sur chacun, le piège des deux côtés
Un RSSI marche sur un fil. Si les signalements sont ignorés, l’entreprise a l’air négligente 🧨. Si chaque rapport “qui ressemble à un vrai” déclenche une alerte maximale, les équipes s’épuisent et les vraies corrections glissent.
Ça touche aussi les utilisateurs. Sur Mac, iPhone ou iPad, la tentation existe de repousser une mise à jour par peur d’un bug, d’une app cassée, ou d’une autonomie en baisse. Sauf que dans un monde où l’exploitation peut devancer le correctif, repousser devient un pari.
Le fil conducteur, c’est l’opérationnel : les vulnérabilités sont un problème d’organisation autant que de code. Et l’IA a rendu la facture visible d’un coup.
Ce que les directions n’aiment pas entendre : le blocage vient souvent du budget, pas des talents 💶
Les entreprises disent chercher des pros sécurité, mais les embauches n’ont pas retrouvé le niveau d’avant le ralentissement du marché. Et les enquêtes sectorielles ont fait remonter un signal dur : les contraintes budgétaires pèsent désormais plus que la “pénurie de profils”.
ISACA observe la même dynamique : même avec des candidats sur le marché, les équipes restent sous-dimensionnées. Dans ce contexte, l’IA agit comme un amplificateur : plus de découvertes, mais pas plus de bras pour absorber.
La prochaine étape logique n’est pas une “IA plus forte”. C’est des règles internes plus strictes : déduplication, scoring d’exploitabilité, exigences de preuve, et une politique de divulgation qui évite l’embouteillage. Sinon, le stock de failles gagnera toujours.
Pour le lecteur côté Apple, la morale est simple : mises à jour plus fréquentes, extensions à surveiller, et méfiance vis-à-vis des “petits outils” dans le navigateur. La sécurité se joue désormais autant dans les détails du quotidien que dans les grosses annonces.
Journaliste tech depuis dix ans, Florian dirige la rédaction de tablet spirit. Passionné d’iPad et d’écosystème Apple, il teste les produits sur la durée et refuse la langue de bois face aux marques.