Vulnérabilités trouvées par l'IA : un correctif sur vingt, et la DSI qui n'a rien vu venir
Un programme de signalement des vulnérabilités trouvées par l'IA affiche un taux de correction de 6 %. Rapporté à l'arborescence de dépendances d'une entreprise type et au délai de quatorze jours qu'impose le référentiel britannique Cyber Essentials pour les correctifs critiques, ce chiffre transforme chaque sortie d'un modèle frontière en une vague de correctifs que la plupart des DSI françaises n'ont pas les effectifs pour absorber.
Fin mai 2026, environ 6 % des vulnérabilités signalées par un programme de découverte assisté par l'IA avaient été corrigées. Le chiffre provient d'une audition devant la commission de la sécurité intérieure de la Chambre des représentants des États-Unis, qui posait ouvertement la question de savoir si les systèmes de divulgation peuvent suivre le rythme de chaque nouvelle génération de modèles. C'est la donnée la plus utile publiée à ce jour sur la façon dont l'IA bouleverse la découverte des vulnérabilités et la gestion des correctifs, car elle transforme une inquiétude diffuse en arithmétique que l'on peut appliquer à ses propres systèmes. Cet article fait ce calcul.
Comment l'IA transforme-t-elle la découverte des vulnérabilités et la gestion des correctifs ?
La divulgation coordonnée a été conçue pour un monde de rareté. Un chercheur trouve une faille, la signale discrètement, l'éditeur dispose d'un délai fixe (90 jours, à quelques ajustements près) pour publier un correctif, puis l'avis devient public. Tout ce mécanisme suppose que les découvertes arrivent au compte-gouttes.
La découverte à l'échelle des machines brise ces hypothèses d'un seul coup. La Cloud Security Alliance a examiné les affirmations d'un éditeur selon lesquelles un unique modèle aurait mis au jour des milliers de vulnérabilités jusque-là inconnues, y compris des failles dormant depuis des décennies dans du code open source pourtant abondamment audité. La CSA n'a pas été en mesure de vérifier ces affirmations de façon indépendante, il convient donc de traiter les totaux avancés avec prudence. Le taux de correction de 6 %, lui, ne souffre d'aucune réserve de ce type : quel que soit le rythme réel de découverte, le taux de correction est documenté, et il est calamiteux. La découverte s'automatise. La correction, non.
Quelle est votre part du retard accumulé ?
Commençons par la forme d'une arborescence de dépendances moderne. Une étude de l'écosystème npm présentée à USENIX Security a établi qu'installer un paquet moyen revient à faire implicitement confiance à 79 autres paquets et 39 mainteneurs. Une entreprise de taille intermédiaire avec quelques dizaines de dépendances directes s'appuie donc sur plusieurs centaines, voire un millier de composants distincts, pour la plupart jamais lus par ses développeurs. Une scale-up bien financée, issue de la French Tech ou hébergée à Station F, ne fait pas exception : son socle technique repose sur la même pile de dépendances non auditées.
Posons maintenant des chiffres sur une vague de signalements. Supposons, prudemment, qu'un événement de divulgation à l'échelle des machines touche 2 % d'une arborescence de 1 000 composants : vingt composants concernés. Au taux de correction rapporté devant la commission américaine, environ un de ces vingt composants disposera d'un correctif de l'éditeur le jour de la sortie. Les dix-neuf autres sont à votre charge : à atténuer, isoler ou remplacer.
Au Royaume-Uni, le référentiel Cyber Essentials impose que les mises à jour de sécurité critiques et à haut risque soient appliquées sous quatorze jours, et la certification conditionne l'accès à de nombreux marchés publics britanniques. Aucun équivalent chiffré unique n'existe en France, mais l'ordre de grandeur sert de repère utile pour toute DSI soumise à des obligations de sécurité comparables (RGS, ISO 27001, exigences contractuelles de grands donneurs d'ordre). Dix-neuf atténuations au niveau composant en quatorze jours, cela revient à en traiter 1,4 par jour, en continu pendant deux semaines, en plus de l'activité courante.
Comparons avec la réalité mesurée. L'analyse du code tiers menée par Veracode a montré que 79 % des bibliothèques ne sont jamais mises à jour après leur intégration dans une base de code, si bien que le débit de correction réel de la plupart des équipes avoisine zéro. Si le seuil de 2 % paraît élevé, refaites le calcul à 0,5 % : cinq composants en deux semaines dépassent encore ce qu'une équipe livrant une mise à jour de dépendance par semaine peut absorber. La conclusion résiste à toute hypothèse raisonnable. Une vague de signalements modeste dépasse d'un ordre de grandeur la capacité de correctif habituelle.
Qui est corrigé avant vous ?
Un laboratoire assis sur une masse de failles non publiées doit bien le dire à quelqu'un avant de le dire à tout le monde. Les garder pour lui est indéfendable, les déverser publiquement est pire, et briefer discrètement des milliers de projets concernés est impossible. Le choix rationnel consiste à prévenir en amont un cercle restreint : les plus grandes plateformes, dotées d'équipes de sécurité en mesure d'absorber un flux confidentiel massif. Cela relève du tri, et constitue aussi, selon toute définition commerciale, un statut à plusieurs vitesses. L'intervalle entre la correction privée réservée à ce cercle et la disponibilité publique du modèle est une fenêtre d'exposition programmée, avec une date de début à peu près prévisible et une liste d'invités que vous ne maîtrisez pas.
En dehors de ce cercle, la charge retombe sur les maillons les moins outillés de la chaîne. Le recensement Census II des logiciels libres et open source de la Linux Foundation a montré que les bibliothèques les plus utilisées reposent sur une poignée de mainteneurs, souvent bénévoles. Il n'existe pas d'astreinte pour le bénévole qui entretient seul une bibliothèque d'analyse syntaxique vieille de vingt ans, et aucun consortium ne viendra corriger par anticipation vos dépendances transitives. Le chiffre de 6 % est ce à quoi ressemble une découverte qui s'échelle comme un logiciel, pendant que la correction continue de s'échelle comme des personnes.
À quoi ressemble un pilotage du pic de correctifs au jour de sortie ?
Traitez les sorties annoncées de modèles frontières comme les équipes d'exploitation traitent les alertes tempête : des échéances datées qui déclenchent une réponse répétée à l'avance. Ce modèle comporte quatre volets.
La responsabilité. Le pic revient à qui possède la chaîne de déploiement, généralement la direction technique ou les opérations informatiques. Le rôle de la sécurité est de trier et de prioriser ; celui de l'ingénierie est de livrer. Un plan de pic porté par une équipe incapable de déployer n'est qu'un document.
Une base de référence mesurée. Comptez, à partir de l'historique réel des changements et non de la mémoire collective, le nombre de mises à jour de dépendances testées et déployées par votre équipe chaque semaine au cours du dernier trimestre. Ce chiffre est votre véritable capacité de pic, et il doit figurer dans votre stratégie technique, aux côtés d'un inventaire des dépendances qui signale les composants qu'aucun éditeur ne corrigera jamais pour vous.
Des seuils. Dimensionnez le pic avec l'arithmétique développée plus haut : taille de l'arborescence, multipliée par un taux de contact estimé, multipliée par les 94 % de signalements que vous devez supposer non corrigés, divisée par quatorze jours. Si le résultat tient dans votre capacité mesurée, répétez l'exercice et passez à autre chose. S'il la dépasse, ce qui sera le cas pour la plupart des entreprises de taille intermédiaire, prévoyez à l'avance des mesures d'atténuation qui ne dépendent pas d'un correctif : patchs virtuels en périphérie de réseau, isolation réseau des composants à risque, interrupteurs d'arrêt par bascule de fonctionnalité, et une liste hiérarchisée des vingt dépendances que vous défendriez en priorité. Concevoir des composants que l'on peut isoler sans faire tomber le produit relève de la même discipline que nous défendons pour sécuriser les systèmes agentiques.
Des conséquences écrites noir sur blanc. Outre-Manche, la perte de la certification Cyber Essentials peut exclure une entreprise de marchés publics entiers, et une faille exploitée touchant des données personnelles déclenche l'obligation de notification sous 72 heures du régulateur britannique, calquée sur celle de l'article 33 du RGPD que la CNIL fait appliquer en France. Les assureurs cyber, y compris les acteurs français, interrogent systématiquement la cadence de correctifs à chaque renouvellement de police. Ces trois conséquences ont leur place dans le dossier d'achat avant même de bâtir quoi que ce soit sur un modèle frontière, ce qui constitue le versant peu glamour de la préparation à l'IA.
Le cercle des privilégiés gardera sa liste et les dates de sortie continueront de s'enchaîner. De tous les chiffres cités ici, le débit de correctifs mesuré est le seul que vous maîtrisiez, et la prochaine date de sortie est déjà inscrite dans l'agenda de quelqu'un. Mesurez le vôtre cette semaine.
Questions fréquentes
Qu'est-ce qu'une fenêtre de divulgation des vulnérabilités, et pourquoi devient-elle plus dangereuse ?
C'est l'intervalle entre le signalement discret d'une faille et sa divulgation publique. Historiquement, il protégeait les utilisateurs le temps qu'un correctif soit publié. Quand un modèle d'IA génère à la fois les découvertes et devient disponible publiquement à une date connue, cette fenêtre devient un compte à rebours vers le moment où les organisations non corrigées croisent, en plein jour, un puissant outil de découverte.
Comment calculer sa capacité de correctifs pour le jour de sortie d'un modèle ?
Multipliez la taille de votre arborescence de dépendances par un taux de contact supposé (0,5 % à 2 % est une fourchette raisonnable pour la planification), retranchez la faible part de signalements susceptibles d'avoir un correctif de l'éditeur, puis divisez par quatorze jours. Vous obtenez le rythme quotidien d'atténuation nécessaire. Comparez-le à votre débit réel, mesuré sur votre historique de changements, et comblez l'écart avec des mesures préconvenues (isolation, interrupteurs d'arrêt) plutôt qu'avec de l'optimisme.
L'open source mature et largement audité protège-t-il des failles trouvées par l'IA ?
Moins qu'avant. Les affirmations en cours d'examen concernent des failles ayant survécu des décennies dans du code pourtant abondamment revu, et les données de correction pointent vers la capacité des mainteneurs, non l'ancienneté du code, comme véritable goulot d'étranglement. Le recensement Census II a montré que les bibliothèques les plus utilisées reposent sur une poignée de mainteneurs, si bien que la popularité concentre l'exposition du jour de sortie plutôt qu'elle ne la dilue.
À lire aussi
- La prime de souveraineté : pourquoi les entreprises paient plus cher une IA qu'aucun gouvernement étranger ne pourra couper
- Washington désigne son propre laboratoire d'IA comme risque stratégique : ce que cela change pour votre dépendance fournisseur
- Les pilotes d'IA en entreprise ne calent pas sur la technologie, mais sur la confiance
- Security & Trust
Rédigé par un persona éditorial IA du système éditorial propriétaire d'Abyshire et relu par notre équipe.