L’agent IA d’AWS annonce 89 % de bugs corrigés, mais ne répare la faille visée que dans 37,8 % des cas
AWS Continuum, passé en disponibilité générale le 22 octobre 2026, affiche 89 % de réussite sur le benchmark CyberGym-E2E, contre 65,9 % pour le précédent record public. Le chiffre cache une limite : l’agent ne répare la vulnérabilité historique précise que dans 37,8 % des cas, sur un benchmark qu’AWS a exécuté seul.
5 octobre 2026. AWS publie le benchmark de son agent Continuum : 819 tâches réussies sur 920, soit 89,0 % de succès de bout en bout sur CyberGym-E2E. 22 octobre 2026. Le service passe en disponibilité générale dans us-east-1 et us-west-2. 24 octobre 2026. La presse spécialisée décortique le chiffre et trouve la ligne fine : l’agent ne répare la faille précise que le benchmark visait que dans 37,8 % des cas.
Pour un RSSI ou un responsable de la sécurité applicative, la leçon tient en une phrase : un score de benchmark vaut ce que vaut sa définition de « corrigé », et ici le chiffre vedette et la métrique qui compte ne racontent pas la même histoire.
Ce que fait réellement Continuum
AWS Continuum for code vulnerabilities est un service qui trouve et valide les vulnérabilités de code, puis livre des correctifs sous forme de patchs automatisables ou de pull requests. Il confirme qu’une remontée de scanner est exploitable dans votre environnement, la classe par impact métier, et propose un correctif pour chacune. Un collecteur lit les ressources AWS Config et la configuration réseau pour juger si une faille est atteignable ; un graphe de contexte identifie les systèmes critiques — données clients, pipelines de paiement, services d’authentification — et classe chaque problème selon la proximité de son chemin d’attaque.
Chaque correctif exige une approbation humaine : Continuum ouvre une pull request, l’équipe la relit et la fusionne. La société promet qu’à terme, des garde-fous permettront d’automatiser certaines classes de remédiation une fois la confiance établie. Le positionnement est clair : ce n’est pas un agent autonome qui pousse du code, c’est un assistant de triage qui réduit le backlog des findings.
Le benchmark et sa ligne fine
CyberGym-E2E donne à un agent 90 minutes pour trouver et corriger une vulnérabilité dans l’un des 139 projets open source du jeu, sans description du bug, sans preuve de concept, sans crash log et sans patch existant. L’agent doit identifier la faille, la déclencher, puis produire un correctif qui arrête le crash sans casser les tests. Toutes les tâches concernent des bugs de memory safety en C ou C++ — un périmètre qu’AWS reconnaît explicitement, et qui exclut d’autres langages et d’autres types de vulnérabilités.
La notation se déroule en quatre étapes cumulatives. Continuum a trouvé et reproduit un bug dans 92,5 % des tâches, arrêté le crash dans 89,6 %, et conservé les tests au vert dans 89,0 %. La quatrième étape vérifie si le patch corrige aussi la vulnérabilité historique que le benchmark avait sélectionnée en amont. Là, le score tombe à 37,8 %, contre 26,2 % pour le précédent record public.
L’astuce est subtile et légitime : l’agent n’est jamais informé de la faille précise que le benchmark vise, il doit juste réparer une faille réelle. Un dépôt peut en contenir plusieurs, et en corriger une autre ne rend pas le travail inutile — ce qui explique en partie l’écart entre 89 % et 37,8 %. Mais la question que personne n’a encore tranchée est celle qui intéresse un client : que donne Continuum quand une équipe lui confie une vulnérabilité spécifique à corriger ?
Un marché où chaque éditeur publie ses propres chiffres
L’épisode Continuum s’inscrit dans un mouvement plus large. Depuis que l’IA accélère la découverte de vulnérabilités — l’affaire PHP2Shell, en octobre 2026, a montré une faille PHP critique dénichée avant les mainteneurs — les éditeurs se disputent le segment de la correction automatisée. Google, Microsoft et plusieurs startups vendent des assistants qui transforment une remontée de scanner en patch relisable, et chacun publie son propre benchmark, sur son propre corpus, avec sa propre définition du succès.
Le problème est structurel : sans tiers de confiance ni corpus commun, ces chiffres ne sont pas comparables entre eux. CyberGym-E2E a le mérite d’être public et de simuler une tâche réaliste — trouver et corriger une faille sans aucune information préalable — mais il mesure ce que l’éditeur choisit de mesurer. Tant que les benchmarks resteront auto-administrés, le 89 % de Continuum et le X % d’un concurrent ne diront rien de leur valeur relative pour votre parc d’applications.
Les réserves qui pèsent sur le chiffre
Trois limites tempèrent le 89 %. D’abord, AWS a exécuté le benchmark elle-même : le protocole et les outils sont publics, mais les résultats publiés sont les siens, et aucun tiers n’a encore reproduit la performance. La société affirme avoir respecté les règles, notamment les limites d’accès internet, et vérifié que l’agent ne se contentait pas de recopier des correctifs déjà publics. Elle précise qu’avec plus de temps, le score monte à 93,7 %.
Ensuite, le périmètre est étroit : uniquement des bugs de memory safety en C/C++, sur un corpus de 139 projets. Un portefeuille d’applications en Python, Java ou Go, ou des vulnérabilités de logique métier, ne bénéficie d’aucune garantie de transfert du chiffre.
Enfin, le calendrier interroge. Corey Quinn, économiste cloud en chef chez Duckbill Group, a suggéré sur X que l’annonce aurait pu être avancée depuis une keynote re:Invent, sans apporter de preuve. Matt Garman, CEO d’AWS, défend de son côté un score « supérieur à tout autre agent IA » sur le test et juge l’IA « réellement transformatrice pour les défenseurs ». Le benchmark publié le 5 octobre, plus de deux semaines avant la disponibilité générale, a donné au chiffre le temps de circuler avant que le service ne soit facturable.
Comment évaluer l’outil sans se fier au benchmark
Plutôt que de trancher sur un chiffre auto-déclaré, posez trois questions à l’éditeur avant un essai. Premièrement : le correctif corrige-t-il la faille que vous avez signalée, ou une faille trouvée au passage ? C’est la différence entre 89 % et 37,8 %, et elle se mesure en quelques jours sur vos propres dépôts. Deuxièmement : le benchmark couvre-t-il vos langages et vos classes de vulnérabilités, ou seulement la memory safety en C/C++ ? Troisièmement : qui a exécuté le benchmark, et un tiers indépendant a-t-il reproduit le score ? Un essai de deux semaines sur un dépôt critique répond à ces trois questions plus vite qu’une analyse du chiffre.
Verdict
Si votre parc est majoritairement en C ou C++ et que vous croulez sous les findings de memory safety, Continuum mérite un essai : un outil qui trouve et reproduit réellement une faille dans 92,5 % des cas, puis livre un patch relisible, réduit le triage manuel, même si la décision finale reste humaine.
Si votre code est écrit dans des langages memory-safe ou que vos vulnérabilités sont de la logique applicative, ne transposez pas le 89 % : le benchmark ne couvre pas votre cas, et personne d’autre qu’AWS n’a encore validé le chiffre. Exigez une évaluation sur vos propres dépôts et votre propre métrique de référence — idéalement le taux de correction de la faille que vous avez demandé de corriger, pas d’une faille trouvée au hasard. C’est la seule métrique qui compte pour un programme de remédiation, et c’est précisément celle qui plafonne à 37,8 %.