Quand le remède crée une nouvelle vulnérabilité
L’intelligence artificielle est en train de bouleverser la cybersécurité. Depuis quelques années, les annonces se multiplient : des modèles d’IA découvrent des vulnérabilités, analysent automatiquement des millions de lignes de code et commencent même à identifier des failles que les humains n’avaient pas détectées.
Mais une question beaucoup moins médiatisée se pose : que se passe-t-il après la découverte de la vulnérabilité ?
Trouver une faille est une chose. La corriger proprement en est une autre.
Et les résultats scientifiques les plus récents montrent un paradoxe intéressant : l’IA devient capable de générer rapidement des correctifs, mais ces correctifs peuvent être incomplets, traiter le symptôme plutôt que la cause profonde, modifier involontairement le comportement du logiciel… voire introduire de nouvelles vulnérabilités.
Nous entrons donc peut-être dans une nouvelle phase de la cybersécurité automatisée : après l’IA qui détecte, puis l’IA qui corrige, il va falloir développer l’IA — et les méthodes — qui vérifient les corrections.
L’IA sait désormais trouver… et corriger
Il serait faux d’affirmer que l’intelligence artificielle est incapable de corriger des vulnérabilités.
Les résultats de l’AI Cyber Challenge organisé par la DARPA en 2025 sont à ce titre impressionnants. Les systèmes autonomes en compétition ont travaillé sur des dizaines de millions de lignes de code. Ils ont découvert 54 vulnérabilités synthétiques différentes et réussi à en corriger 43.
Plus intéressant encore : ils ont découvert 18 vulnérabilités réelles dans des projets open source et proposé 11 correctifs pour celles-ci.
La DARPA considère d’ailleurs la qualité du patch comme un élément central de l’exercice : les résultats de la compétition montrent que l’objectif n’est plus seulement de détecter automatiquement une vulnérabilité, mais de produire une correction exploitable.
C’est une évolution majeure.
Pendant longtemps, l’automatisation de la cybersécurité s’est principalement concentrée sur la détection. Désormais, on commence à imaginer une chaîne presque entièrement automatisée :
Détection → Analyse → Génération du patch → Validation → Déploiement.
Le problème se situe précisément entre les trois dernières étapes.
Un patch qui fonctionne n’est pas nécessairement un patch sûr
Lorsqu’un développeur corrige une vulnérabilité, son objectif n’est pas simplement de faire disparaître le message d’erreur ou de réussir un test.
Un véritable correctif doit supprimer la cause de la vulnérabilité tout en préservant le comportement attendu du logiciel.
C’est beaucoup plus difficile.
Les travaux récents sur la réparation automatique par LLM commencent justement à montrer cette différence.
En juin 2026, des chercheurs ont publié MPC-Patch-Bench, un benchmark destiné à évaluer les capacités des LLM à réparer du code utilisé dans le calcul multipartite sécurisé.
Le meilleur modèle testé réussissait fonctionnellement 22,9 % des tâches.
Mais lorsque les chercheurs ajoutaient des vérifications spécifiques portant sur la sécurité cryptographique et la fidélité numérique, le taux de réussite descendait à 17,1 %.
Plus spectaculaire encore : jusqu’à 40 % des patches qui réussissaient les tests fonctionnels étaient ensuite rejetés par les contrôles supplémentaires de sécurité ou de correction numérique.
Autrement dit :
« Les tests passent » ne signifie pas nécessairement « le logiciel est sûr ».
Corriger le symptôme plutôt que la maladie
Une autre étude publiée en mai 2026 met en évidence une difficulté encore plus subtile.
Dans Root-Cause-Driven Automated Vulnerability Repair, des chercheurs ont étudié la capacité des agents basés sur des LLM à identifier la véritable origine d’une vulnérabilité.
Ils observent que ces agents peuvent avoir tendance à effectuer des modifications superficielles : le comportement qui provoquait l’échec disparaît, mais la cause profonde du problème n’est pas nécessairement éliminée.
Les auteurs ont évalué leur approche sur 178 vulnérabilités C/C++.
Leur conclusion méthodologique est particulièrement importante : les tests automatiques traditionnels ne permettent pas toujours de distinguer un véritable correctif d’un patch qui a simplement réussi à satisfaire les tests.
Ils ont donc ajouté une évaluation par experts humains destinée à déterminer si le correctif traite réellement la cause profonde de la vulnérabilité.
Voilà un problème fondamental pour l’avenir du patching automatisé.
Une IA peut apprendre à satisfaire un test. Ce n’est pas nécessairement la même chose que comprendre pourquoi le logiciel était vulnérable.
Et parfois… le correctif introduit une nouvelle faille
C’est probablement le résultat le plus contre-intuitif.
Demander à une IA de sécuriser du code n’est pas une opération neutre.
En août 2026, des résultats rapportés à partir de travaux de 1Password / Off-by-1 Labs ont porté sur 6 080 patches générés par IA à partir de six CVE récemment divulguées.
Seulement 26 % des correctifs générés résolvaient complètement le problème dans cette expérimentation.
Près de la moitié — 49,3 % — laissaient au moins un chemin d’exploitation non corrigé.
20,1 % corrigeaient le problème initial mais modifiaient également le comportement de l’application.
Plus préoccupant encore, 2,3 % introduisaient de nouveaux problèmes de sécurité, tandis que 2,2 % ne corrigeaient pas correctement la vulnérabilité initiale tout en créant de nouveaux chemins d’exploitation.
Les chercheurs utilisent une expression assez parlante pour désigner ces résultats :
FLAWED — “Fix-Like Artifacts With Embedded Defects”.
Autrement dit : des artefacts qui ressemblent à des correctifs, mais qui contiennent encore des défauts.
Cela ne signifie évidemment pas que l’IA est inutile pour le patching.
Au contraire, l’étude montre également que la qualité du contexte fourni au modèle change considérablement ses performances. Mais elle rappelle quelque chose d’essentiel : un patch convaincant à la lecture n’est pas nécessairement un patch sûr.
On peut même attaquer… l’IA chargée de réparer le logiciel
Le problème peut aller encore plus loin.
En 2025, des chercheurs ont étudié une nouvelle surface d’attaque : les rapports de bugs malveillants.
L’idée est ingénieuse.
Si un agent IA reçoit automatiquement un rapport de bug et modifie ensuite le logiciel pour le corriger, pourquoi ne pas rédiger volontairement un rapport destiné à manipuler l’agent ?
Les chercheurs ont créé 51 rapports de bugs adversariaux destinés à pousser des systèmes de réparation automatique vers des modifications malveillantes.
Dans leur expérimentation, 90 % de ces rapports ont déclenché des patches conformes à l’objectif de l’attaquant.
Le système chargé de réparer le logiciel devient alors lui-même une surface d’attaque.
C’est une évolution particulièrement importante à anticiper si demain des agents autonomes sont autorisés à modifier directement des dépôts logiciels.
L’industrie commence à comprendre que « découvrir » ne suffit plus
Cette question n’est plus uniquement académique.
En juin 2026, OpenAI et Trail of Bits ont lancé l’initiative Patch the Planet.
La philosophie annoncée est particulièrement intéressante : accélérer la découverte de vulnérabilités avec l’IA ne suffit pas. Les découvertes doivent être accompagnées d’une analyse, de correctifs et de tests avant d’être transmises aux mainteneurs.
Autrement dit, la valeur n’est plus uniquement dans la découverte.
Elle se déplace progressivement vers la remédiation vérifiable.
GitHub suit une logique comparable avec son Agentic Autofix.
Depuis juillet 2026, le système peut explorer plusieurs fichiers d’un dépôt, proposer une modification puis relancer l’analyse de sécurité afin de vérifier que l’alerte ayant déclenché le processus a effectivement disparu avant d’ouvrir une pull request.
Cette boucle est importante :
Détecter → Corriger → Tester → Vérifier → Faire revoir.
Et probablement recommencer si nécessaire.
Le prochain problème : une avalanche de vulnérabilités ?
Il existe enfin une conséquence plus générale.
Supposons que l’IA devienne extrêmement performante pour découvrir des vulnérabilités.
Nous pourrions alors nous retrouver avec des milliers, voire beaucoup plus, de nouvelles vulnérabilités identifiées automatiquement.
Mais si notre capacité à les corriger et à valider les correctifs ne progresse pas à la même vitesse, nous ne résolvons qu’une moitié du problème.
Nous accélérons la production de connaissances sur nos vulnérabilités sans accélérer suffisamment leur élimination.
Le véritable goulot d’étranglement pourrait donc progressivement se déplacer :
hier : trouver les vulnérabilités ;
demain : produire, vérifier et déployer suffisamment vite leurs correctifs.
L’IA, formidable assistant… mais pas encore réparateur autonome auquel faire confiance aveuglément
Les résultats actuels ne justifient ni l’enthousiasme aveugle ni le pessimisme.
L’IA sait déjà produire de vrais correctifs. Les résultats de la DARPA le démontrent à une échelle impressionnante.
Mais un correctif de sécurité n’est pas simplement du code qui compile.
Un véritable patch doit simultanément :
- éliminer tous les chemins d’exploitation de la vulnérabilité ;
- traiter sa cause profonde ;
- préserver le comportement fonctionnel du logiciel ;
- ne pas introduire une nouvelle vulnérabilité ;
- fonctionner dans l’architecture complète de l’application ;
- réussir les tests fonctionnels, de sécurité et de régression ;
- et finalement être revu puis effectivement déployé.
La prochaine frontière de l’IA appliquée à la cybersécurité ne sera donc peut-être pas seulement l’IA qui trouve des failles.
Ce sera l’écosystème capable de transformer automatiquement ces découvertes en correctifs fiables, vérifiables et déployables.
Et, paradoxalement, plus l’IA deviendra performante pour écrire les patches, plus nous aurons besoin de mécanismes indépendants capables de vérifier que l’IA n’a pas créé un nouveau problème en essayant de résoudre le précédent.
Sources
DARPA, AI Cyber Challenge marks pivotal inflection point for cyber defense, août 2025.
Zhang, Zheng & Lou, MPC-Patch-Bench: Security-Aware LLM Code Patch for Multi-Party Computation, juin 2026.
Wang et al., Root-Cause-Driven Automated Vulnerability Repair, mai 2026.
1Password / Off-by-1 Labs, résultats sur l’évaluation de 6 080 patches générés par IA, rapportés en août 2026.
Przymus, Happe & Cito, Adversarial Bug Reports as a Security Risk in Language Model-Based Automated Program Repair, 2025.
NIST / IEEE Computer, Can AI Fix Buggy Code? Exploring the Use of Large Language Models in Automated Program Repair, 2025.
OpenAI & Trail of Bits, Patch the Planet, juin 2026.
GitHub, Agentic Autofix for code scanning alerts, juillet 2026.
