Le rapport 2026 d’Azul sur l’écart en matière de vulnérabilités de l’IA révèle que l’application des correctifs en entreprise peine à suivre le rythme des menaces liées à l’IA

Le rapport 2026 sur l’écart en matière de vulnérabilités de l’IA d’Azul met en évidence un décalage entre la rapidité que les responsables de la sécurité attribuent aux attaquants dotés d’IA et le temps dont leurs organisations ont besoin pour déployer des correctifs. Dans une enquête menée auprès de 300 responsables de la sécurité aux États-Unis, 69 % estimaient que les attaquants pouvaient élaborer un exploit fonctionnel en trois jours, tandis que 44 % indiquaient que leur organisation avait besoin de quatre jours ou plus pour corriger une vulnérabilité critique en environnement de production.

Le résultat le plus frappant du rapport concerne l’expérience que les répondants associent à ces retards : 85 % ont signalé un incident, un incident présumé ou un incident évité de justesse attribuable à la lenteur de l’application des correctifs. Ce chiffre reflète les expériences rapportées, et non un taux de compromission vérifié de manière indépendante — il ne permet pas non plus d’établir que l’IA a causé ces événements.

Commandée par Azul et réalisée par Censuswide, l’étude porte sur des organisations qui déploient largement Java. Son message général est d’ordre opérationnel : repérer une vulnérabilité n’est qu’un début. Un correctif doit passer les tests, atteindre les systèmes concernés et éliminer l’exposition dans un parc que les équipes ne voient peut-être pas entièrement.

Deux horloges qui ne sont pas synchronisées

L’enquête distingue les attentes des responsables quant aux attaquants des capacités de déploiement de leurs propres organisations :

• 69 % pensent que les attaquants dotés d’IA peuvent élaborer un exploit en trois jours ou moins, et 22 % estiment que ce délai est inférieur à 24 heures.
• 56 % déclarent pouvoir déployer un correctif critique en production dans les trois jours : 13 % en moins de 24 heures et 43 % en un à trois jours.
• 44 % ont besoin de plus de temps : 32 % nécessitent quatre à six jours et 12 %, davantage encore.

Il s’agit de répartitions des réponses à l’enquête, et non de mesures d’attaquants qui s’en prendraient à des organisations précises en exploitant les mêmes vulnérabilités. Cet écart justifie des inquiétudes quant à la préparation, mais il ne faut pas l’interpréter comme une fenêtre d’exposition précise de trois jours pour chaque entreprise.

Le même déséquilibre apparaît au seuil d’un jour : 22 % s’attendent à ce que les attaquants agissent aussi vite, contre 13 % qui déclarent que leur organisation peut déployer un correctif dans ce délai. Par ailleurs, 59 % reconnaissent être davantage exposés aux outils d’attaque alimentés par l’IA, sans avoir modifié leur posture de sécurité.

Les tests contribuent largement aux délais

Dans 58 % des organisations interrogées, les tests des mises à jour des environnements d’exécution Java ajoutent au moins quatre jours au cycle d’application des correctifs. Parmi elles, 36 % signalent un délai de quatre à six jours et 22 %, d’une semaine ou plus. Par ailleurs, 33 % indiquent un délai d’un à trois jours et 9 %, de moins de 24 heures. Aucun répondant n’a déclaré que les tests avaient été omis.

Les changements apportés aux environnements d’exécution peuvent avoir des répercussions sur de nombreuses applications ; les tests ont donc une utilité concrète : une mise à jour de sécurité qui perturbe un service essentiel crée un autre problème opérationnel. Selon le rapport, l’ampleur des mises à jour contribue à cette charge, car les versions trimestrielles complètes d’OpenJDK peuvent inclure des changements non liés à la sécurité en plus des correctifs de vulnérabilités.

Azul a par ailleurs évalué 26 mises à jour trimestrielles d’OpenJDK sur une période de plus de six ans et a classé six d’entre elles comme ayant provoqué une régression grave. Ce chiffre de 23 % correspond à l’évaluation des versions par le fournisseur ; il ne s’agit pas d’une estimation, fondée sur l’enquête, de la fréquence à laquelle l’application d’un client donné risque de cesser de fonctionner.

Parmi les principaux obstacles signalés à une application plus rapide des correctifs, 44 % citent l’ampleur des tests, 40 % la complexité ou l’ancienneté des systèmes concernés et 36 % le manque de visibilité sur les vulnérabilités connues. Les retards de correctifs du fournisseur sont mentionnés par 25 % des répondants. Ce constat montre qu’une grande partie des difficultés de remédiation tient au processus de déploiement propre à l’entreprise.

Les signalements d’incidents et les lacunes de l’inventaire doivent être interprétés différemment

Cinquante-cinq pour cent des répondants signalent un incident confirmé attribuable à la lenteur de l’application des correctifs, et 53 % un incident évité de justesse. Les répondants pouvaient sélectionner plusieurs réponses ; ces chiffres se recoupent donc et ne doivent pas être additionnés. Le chiffre global de 85 % mis en avant comprend également les incidents présumés.

L’enquête n’établit pas que tous ces événements concernaient des vulnérabilités Java. Les participants travaillent dans des organisations qui utilisent largement Java, mais l’étude comprend aussi des questions générales sur l’application des correctifs logiciels, ainsi que des questions portant spécifiquement sur les environnements d’exécution Java.

L’inventaire constitue une deuxième difficulté. Seuls 19 % des répondants indiquent qu’au moins 90 % de leur parc d’environnements d’exécution Java en production dispose du niveau de correctifs de sécurité le plus récent. Cela signifie que 81 % se situent sous ce seuil, et non que 81 % n’ont aucun environnement d’exécution à jour. Environ un répondant sur cinq déclare que la moitié, ou moins, de son parc est à jour.

Par ailleurs, 51 % reconnaissent avoir une visibilité partielle ou limitée sur les environnements d’exécution Java critiques, notamment les instances intégrées, héritées et non gérées. Repérer un environnement d’exécution vulnérable dans une application empaquetée ou un conteneur peut être plus difficile que d’identifier une installation gérée de manière centralisée. Un correctif ne peut pas éliminer l’exposition d’un système que le processus de déploiement n’atteint jamais.

Ce que la technologie d’Azul apporte à la discussion

L’offre de mises à jour de sécurité d’Azul limite certaines versions aux correctifs de sécurité sur une base OpenJDK préalablement stabilisée. L’entreprise propose des mises à jour trimestrielles, mensuelles ciblées et hors cycle, dans le but de réduire la quantité de changements sans rapport que les entreprises doivent évaluer lorsqu’elles déploient un correctif urgent.

Il s’agit d’une intervention technique plus limitée que la suppression de la nécessité d’un contrôle des changements. Limiter les modifications du code peut réduire l’étendue des validations nécessaires, mais les vérifications propres à chaque application, la responsabilité du déploiement et la préparation d’un retour à la version précédente restent importantes. Azul est le commanditaire du rapport et vend des produits qui répondent aux problèmes qu’il mesure.

Ses outils d’inventaire Java et de détection des vulnérabilités répondent à l’autre volet du processus : recenser les environnements d’exécution et leurs versions, ainsi que leur exposition, afin de déterminer quels systèmes sont concernés par la divulgation d’une nouvelle vulnérabilité. Le rapport ne présente pas de comparaison contrôlée permettant de mesurer dans quelle mesure les organisations interrogées amélioreraient leur situation en adoptant ces produits.

« Nos recherches montrent que les responsables de la sécurité comprennent la menace : la sensibilisation n’est plus le problème, c’est la mise en œuvre », a déclaré Scott Sellers, cofondateur et PDG d’Azul.

Transformer l’intention de corriger en un processus mesurable

Pour l’année à venir, 32 % des répondants citent l’accélération et l’augmentation de la fréquence des correctifs comme leur principale stratégie pour réduire l’exposition, tandis que 26 % privilégient un meilleur inventaire des logiciels et des environnements d’exécution. En outre, 17 % accordent la priorité à la détection et à la réponse plutôt qu’à l’accélération des correctifs.

L’étude préconise de suivre l’ensemble du parcours, de la divulgation à la correction : quels systèmes sont concernés, qui en est responsable, quels tests sont nécessaires et si le correctif a effectivement été déployé en production. Une échéance n’est utile que si les équipes peuvent vérifier que l’opération est achevée sur l’ensemble du parc concerné.

Les résultats pour les États-Unis s’appuient sur un travail de terrain mené du 3 au 7 août 2026 auprès de responsables de la sécurité d’organisations comptant au moins 1 000 employés et utilisant largement Java/JVM en production. Il s’agit de réponses autodéclarées issues d’une population définie, et non d’un recensement des entreprises ni d’une mesure directe du développement d’exploits.

Le Rapport 2026 sur le fossé face aux vulnérabilités de l’IA présente en détail les résultats et la méthodologie. Il montre surtout qu’il faut améliorer à la fois la rapidité d’application des correctifs et la visibilité sur les environnements d’exécution : un correctif rapide n’a qu’une utilité limitée si l’organisation ne peut pas repérer chaque déploiement concerné ni confirmer que la mise à jour y a bien été appliquée.