AWS a publié le 15 octobre 2026 un billet qui a fait réagir une bonne partie du secteur de la cybersécurité cloud. Signé par Dazhi Zhang et Hamed Soleimani, le texte détaille un test mené sur un agent de sécurité autonome, capable de découvrir et d’exploiter des vulnérabilités sans intervention humaine directe à chaque étape. Résultat annoncé par AWS : 33 vulnérabilités exploitées avec succès sur un lot de 37 failles réelles et récemment divulguées, soit un taux proche de 89%. L’outil, baptisé AWS Security Agent, est désormais intégré à une offre plus large nommée AWS Continuum. Pour un secteur qui investit des dizaines de milliards de dollars chaque année dans la détection de vulnérabilités, ce chiffre mérite d’être examiné de près, avec ses forces et ses zones d’ombre.

Ce que révèle l’annonce d’AWS sur son agent de sécurité autonome

Le principe du test est simple à décrire mais technique à exécuter. AWS a réuni 37 CVE réelles, toutes récemment publiées, puis les a converties en cibles conteneurisées jouables. Chaque conteneur reproduit l’environnement vulnérable d’une application réelle, avec un drapeau (flag) placé exactement à l’endroit où la faille devient exploitable, ce que les chercheurs en sécurité appellent le “sink” de la vulnérabilité. L’agent ne reçoit, selon les éléments relayés par une synthèse indépendante de l’annonce, qu’une URL de point d’entrée et un indice d’une seule ligne. À partir de là, il doit explorer la cible, repérer la faille, construire un exploit fonctionnel, puis extraire le drapeau pour prouver la compromission.

Sur les 37 cibles, l’agent a réussi 33 fois. AWS n’a publié ni le temps moyen nécessaire par cible, ni le coût de calcul associé, ni le nom du modèle de langage sous-jacent. Cette absence de détails techniques limite la portée scientifique du résultat, mais elle n’empêche pas l’entreprise de revendiquer une avancée dans l’automatisation du test d’intrusion. Le mot “autonome” n’est pas choisi au hasard. AWS insiste sur le fait que l’agent fonctionne sans supervision humaine étape par étape, contrairement aux scanners de vulnérabilités classiques qui se contentent de signaler des correspondances de signatures connues.

AWS Continuum et l’AWS Security Agent : de quoi parle-t-on exactement

AWS Continuum n’est pas un produit isolé mais une famille d’agents coordonnés. Selon la description publiée sur le blog sécurité d’AWS, le système couvre trois étapes distinctes : la découverte des vulnérabilités, leur validation par exploitation réelle, puis la remédiation du code source tout en préservant le comportement fonctionnel testé. Cette architecture en plusieurs agents spécialisés rappelle les pipelines DevSecOps classiques, sauf qu’ici chaque étape est pilotée par un modèle capable de raisonner et d’agir plutôt que d’appliquer des règles statiques.

L’AWS Security Agent constitue la brique offensive de cet ensemble. C’est lui qui joue le rôle du pentester, celui qui attaque activement une cible pour prouver qu’une faille est réellement exploitable et pas seulement théorique. Cette distinction compte beaucoup dans le métier. Un scanner qui détecte un millier de failles potentielles sans les confirmer génère un travail de tri énorme pour les équipes sécurité. Un agent qui prouve l’exploitation, lui, élimine une grande partie du bruit. C’est précisément l’argument commercial que pousse AWS auprès des équipes de sécurité débordées par le volume d’alertes quotidiennes.

Voici un schéma simplifié illustrant le déroulé type d’un test de ce genre, à titre pédagogique et non comme une reproduction du code réel d’AWS.

Cible : conteneur avec CVE connue
Entrée fournie à l'agent :
  - URL du point d'entrée (endpoint)
  - Indice d'une ligne sur la nature de la faille

Déroulé :
  1. Reconnaissance de la surface d'attaque
  2. Identification du point d'injection ou du sink
  3. Construction d'un exploit fonctionnel
  4. Exécution et extraction du drapeau (flag)
  5. Rapport de validation

Résultat observé sur 37 cibles réelles : 33 drapeaux extraits

Le protocole de test : 37 CVE réelles, des cibles conteneurisées, un drapeau caché

Le choix de conteneuriser chaque CVE change la donne par rapport aux anciens benchmarks académiques. Beaucoup de tests de sécurité reposent sur des jeux de données synthétiques ou volontairement simplifiés, où les failles sont introduites artificiellement dans du code d’exemple. Ici, AWS affirme avoir utilisé des vulnérabilités réellement divulguées, ce qui rapproche le test des conditions de terrain. Un conteneur reproduit la pile logicielle complète où la faille a été découverte, avec ses dépendances, ses versions et son comportement réseau.

Ce format de test en conteneur isolé présente aussi un avantage pratique. Il permet de rejouer le même scénario plusieurs fois, de mesurer la reproductibilité du résultat, et de limiter les risques si l’agent se comporte de façon inattendue. Le sujet n’est pas neutre, car un agent capable de construire des exploits fonctionnels soulève des questions de double usage évidentes. Un outil qui aide à sécuriser une infrastructure peut, dans d’autres mains, servir à l’attaquer. AWS ne détaille pas publiquement les garde-fous mis en place pour empêcher ce type de détournement, ce qui reste l’une des zones d’ombre de l’annonce.

33 vulnérabilités sur 37 : comment lire ce taux de 89%

Un taux de réussite de 89,2%, arrondi à 89% dans plusieurs reprises de l’annonce, paraît impressionnant isolément. Il faut cependant le replacer dans son contexte statistique. Un échantillon de 37 cibles reste petit à l’échelle d’un marché qui traite plusieurs milliers de nouvelles CVE chaque année. Un tel échantillon ne permet pas de généraliser le taux de succès à toutes les familles de vulnérabilités, ni à tous les langages de programmation ou frameworks. Une faille d’injection SQL classique et une faille de désérialisation complexe n’exigent pas le même niveau de raisonnement de la part d’un agent automatisé.

Le chiffre doit aussi se comparer à ce que l’on sait des capacités humaines sur ce type d’exercice. Un pentester expérimenté réussit en général à exploiter la grande majorité des CVE publiques dans un cadre de test contrôlé, à condition d’avoir le temps nécessaire. L’intérêt d’un agent automatisé ne réside donc pas forcément dans un taux de réussite supérieur à celui d’un humain, mais dans la vitesse et le volume. Un agent peut, en théorie, tester des centaines de cibles en parallèle là où une équipe humaine en couvre quelques-unes par semaine. C’est ce changement d’échelle, plus que le taux brut de 89%, qui constitue l’argument central d’AWS.

Les chiffres clés du benchmark AWS Continuum

Le tableau ci-dessous résume les données chiffrées confirmées par AWS autour de cette annonce, en distinguant le test sur les 37 CVE conteneurisées du second benchmark, CyberGym-E2E, mentionné séparément par l’entreprise.

IndicateurValeurSource
CVE réelles testées (cibles conteneurisées)37AWS Security Blog, 15 octobre 2026
CVE exploitées avec succès par l’agent33AWS Security Blog
Taux de réussite calculé89,2% (arrondi à 89%)Calcul 33/37, repris par une synthèse tierce
Tâches CyberGym-E2E réussies819 sur 920AWS Continuum, billet dédié
Taux de réussite CyberGym-E2E89,0%AWS Continuum
Record public précédent sur CyberGym-E2E65,9%AWS Continuum
Limite de temps par tâche CyberGym-E2E90 minutesAWS Continuum
Date de publication de l’annonce15 octobre 2026AWS Security Blog

CyberGym-E2E : le deuxième benchmark qui change la donne

Le test sur 37 CVE n’est pas le seul chiffre qu’AWS avance. Dans un billet distinct consacré à AWS Continuum, l’entreprise rapporte un score de 819 tâches réussies sur 920 dans le cadre du benchmark CyberGym-E2E, soit un taux de 89,0%, à exécuter dans une limite de 90 minutes par tâche. CyberGym-E2E ne se limite pas à la découverte d’une faille. Il évalue la capacité d’un système à trouver la vulnérabilité, produire une preuve de concept fonctionnelle, puis corriger le code source sans casser le comportement attendu par les tests existants. C’est un exercice nettement plus complet qu’une simple exploitation, puisqu’il ajoute la dimension de remédiation.

AWS situe ce résultat de 89,0% par rapport à un précédent record public de 65,9% sur le même benchmark, soit un gain de 23,1 points de pourcentage. Ce bond mérite d’être pris au sérieux, même s’il faut garder en tête qu’un benchmark conçu par un éditeur pour mettre en valeur son propre produit n’a pas la même valeur probante qu’une évaluation indépendante menée par un tiers neutre. Aucune évaluation contradictoire de CyberGym-E2E réalisée par un laboratoire extérieur n’a pu être identifiée à ce stade.

Historique : du pentest manuel à l’audit piloté par IA

Le test d’intrusion manuel reste la référence historique de la sécurité offensive depuis les années 1990, porté par des cabinets spécialisés et des certifications comme l’OSCP. Les scanners automatisés de signatures, type Nessus ou Qualys, sont arrivés dans les années 2000 pour couvrir le volume que les humains ne pouvaient pas traiter seuls, mais au prix d’un taux élevé de faux positifs. La décennie 2010 a vu l’essor du DevSecOps et des outils d’analyse statique intégrés aux pipelines CI/CD, qui déplacent la détection en amont du déploiement plutôt qu’après coup.

L’étape suivante, amorcée depuis 2024, consiste à confier à des agents fondés sur des grands modèles de langage la tâche de raisonner sur une cible comme le ferait un humain, plutôt que de chercher des motifs connus. Cette évolution s’inscrit dans un mouvement plus large de la sécurité cloud, où les fournisseurs tentent de réduire le délai entre la divulgation d’une faille et sa remédiation effective. L’enjeu dépasse la seule prouesse technique. Chaque jour gagné entre la publication d’une CVE et son correctif réduit la fenêtre d’exposition des entreprises qui dépendent du logiciel concerné.

Paysage concurrentiel : où se situe AWS face aux ténors de la sécurité cloud

AWS n’est pas seul sur ce terrain, loin de là. Le marché de la sécurité cloud reste dominé par des acteurs installés depuis longtemps. Selon l’étude MarketsAndMarkets, Microsoft et Palo Alto Networks figurent parmi les principaux acteurs du marché mondial de la sécurité cloud. Ces deux groupes investissent eux aussi massivement dans l’automatisation par IA de la détection et de la réponse aux incidents, via Microsoft Defender et Palo Alto Networks Cortex. La bataille se joue donc moins sur l’existence d’un agent IA, que tous les grands fournisseurs développent en parallèle, que sur la rapidité de mise en production et la transparence des résultats publiés.

Pour l’instant, AWS choisit de communiquer des chiffres de performance sans détailler l’architecture du modèle utilisé, une approche qui tranche avec certains concurrents plus enclins à publier des analyses techniques détaillées. Cette retenue peut s’expliquer par une volonté de protéger un avantage compétitif, mais elle complique l’évaluation indépendante du résultat par la communauté de la recherche en sécurité. Dans un marché encore jeune, la crédibilité se construit autant sur la transparence méthodologique que sur le taux de réussite affiché.

Deux lectures du marché de la sécurité cloud en 2026

La taille réelle du marché de la sécurité cloud varie fortement selon le cabinet d’études et la définition retenue. Le tableau suivant met en regard deux estimations publiées en 2026, qui illustrent à quel point les contours du secteur restent flous selon qu’on y inclut ou non les outils de conformité, de gestion des identités ou de protection des charges de travail.

Cabinet d’étudesMarché 2026Projection 2031Croissance annuelle (CAGR)
Mordor Intelligence (marché logiciel sécurité cloud)56,83 Md$106,6 Md$13,42%
MarketsAndMarkets (marché sécurité cloud)34,37 Md$59,34 Md$11,5%

L’écart entre les deux estimations, qui dépasse 20 milliards de dollars sur la seule année 2026, montre bien que le périmètre du marché n’est pas stabilisé. Ce qui reste constant dans les deux études, c’est la trajectoire de croissance à deux chiffres sur cinq ans, portée par la multiplication des charges de travail cloud, l’essor des architectures conteneurisées et la pression réglementaire croissante en Europe comme aux États-Unis. C’est dans ce contexte de croissance soutenue qu’il faut lire l’annonce d’AWS. Elle vise à capter une part d’un marché qui devrait grossir de plusieurs dizaines de milliards de dollars d’ici 2031, quelle que soit l’estimation retenue.

AWS re:Invent 2026 : la sécurité absorbe re:Inforce

L’annonce du 15 octobre s’inscrit dans un calendrier particulier. Pour la première fois, AWS a choisi de fusionner la programmation sécurité de sa conférence re:Inforce avec celle de re:Invent 2026, selon les informations relayées par la page d’événement echo.ai consacrée à re:Invent 2026. Cette fusion crée un parcours sécurité élargi qui couvre l’IA agentique, la gestion des identités, la détection et la réponse aux incidents, la gouvernance, la conformité, la sécurité de la chaîne logicielle et la sécurité des conteneurs. Le regroupement de ces deux événements en un seul traduit une volonté d’AWS de présenter la sécurité non plus comme un sujet à part, mais comme un fil conducteur de l’ensemble de son offre cloud.

Ce choix de calendrier n’est pas neutre pour les équipes IT européennes qui suivent ces annonces à distance. Une conférence unifiée signifie des annonces produits concentrées sur une période plus courte, ce qui complique le suivi pour les responsables sécurité qui doivent évaluer rapidement si une nouveauté concerne leur périmètre. Les équipes qui gèrent déjà des outils AWS de détection de menaces se retrouveront probablement avec un nouvel agent à intégrer dans une pile déjà chargée.

Ce que cela change pour la sécurité des conteneurs

Le choix de conteneuriser les 37 cibles de test n’est pas un détail technique anodin. Il confirme que les conteneurs restent le terrain d’exercice privilégié pour évaluer des outils de sécurité automatisés, à la fois parce qu’ils sont faciles à isoler et à reproduire, et parce qu’ils représentent désormais la majorité des charges de travail cloud en production. Un agent capable de trouver et d’exploiter une faille dans un conteneur peut, en théorie, être redirigé vers l’audit continu des images déployées par une entreprise, avant même leur mise en production.

Cette logique rejoint une tendance observée sur plusieurs plateformes cloud concurrentes, où l’isolation entre charges de travail et la détection de failles dans les images de conteneurs sont devenues des priorités affichées. La différence avec AWS Continuum tient au positionnement. Il ne s’agit plus seulement de scanner une image à la recherche de bibliothèques obsolètes, mais de prouver activement qu’une faille détectée est exploitable, ce qui change la nature du rapport remis aux équipes de sécurité. Un faux positif coûte du temps d’investigation, un vrai positif prouvé par exploitation réelle économise ce temps.

Les zones d’ombre du benchmark : ce qu’AWS ne dit pas

Plusieurs informations manquent pour évaluer pleinement la portée de l’annonce. AWS ne précise pas le temps moyen nécessaire à l’agent pour exploiter une cible, une donnée pourtant centrale pour juger de l’intérêt économique de l’outil face à un pentester humain. Le coût de calcul associé à chaque test n’est pas non plus communiqué, ce qui empêche de comparer le prix d’un audit automatisé à celui d’une prestation de pentest classique facturée à la journée. Enfin, le nom du modèle de langage ou de la famille de modèles utilisée par l’agent n’apparaît pas dans les éléments publiés, ce qui limite la capacité des chercheurs externes à reproduire ou contester le résultat.

À cela s’ajoute la question de la représentativité de l’échantillon. Trente-sept CVE, même réelles et récentes, ne couvrent qu’une fraction infime des catégories de vulnérabilités répertoriées chaque année dans des bases publiques. Rien ne garantit que le taux de 89% se maintienne sur des familles de failles plus rares ou plus complexes, par exemple des vulnérabilités liées à la logique métier d’une application plutôt qu’à une erreur de validation d’entrée classique. Les entreprises qui envisagent d’adopter ce type d’outil devraient donc le considérer comme un complément à leurs audits existants, pas comme un remplacement intégral du travail humain.

Impact pour les entreprises européennes et la conformité

Pour les entreprises basées en France et en Europe, cette annonce arrive dans un contexte réglementaire déjà chargé. La directive NIS2 impose aux opérateurs de services essentiels et à de nombreuses entreprises de taille moyenne de renforcer leurs capacités de détection et de réponse aux incidents, avec des obligations de notification sous des délais stricts. Un outil capable de valider automatiquement l’exploitabilité réelle d’une faille présente un intérêt direct pour prioriser les correctifs face à des équipes de sécurité souvent en sous-effectif, un problème récurrent chez les ETI françaises et européennes.

Reste la question de la localisation des données traitées par ce type d’agent. Un outil qui explore activement une infrastructure, construit des exploits et manipule potentiellement des données sensibles pour valider une faille soulève des interrogations légitimes sur le lieu de traitement de ces informations et sur la conformité au RGPD. AWS propose des régions européennes pour l’essentiel de ses services, mais l’entreprise n’a pas précisé publiquement si AWS Continuum est, à ce stade, disponible dans ces régions ou réservé à un déploiement initial américain.

Cinq prédictions pour les 12 à 24 prochains mois

Plusieurs trajectoires semblent probables à la lecture de cette annonce et du contexte de marché qui l’entoure. D’abord, Microsoft et Google devraient publier leurs propres chiffres de performance sur des benchmarks comparables, par souci de parité concurrentielle face à AWS. Ensuite, la pression va monter pour qu’un laboratoire indépendant évalue ces outils dans des conditions neutres, plutôt que de se fier uniquement aux chiffres communiqués par les éditeurs eux-mêmes.

Troisièmement, le marché de la sécurité cloud devrait continuer sa progression à deux chiffres annoncée par les deux cabinets d’études cités plus haut, avec une accélération probable de la part consacrée aux outils d’audit piloté par IA au sein de ce total. Quatrièmement, les régulateurs européens, déjà mobilisés sur l’IA via l’AI Act, pourraient s’intéresser spécifiquement aux agents capables de construire des exploits fonctionnels, un cas d’usage à double tranchant qui n’a pas encore de cadre juridique dédié. Cinquièmement, les cabinets de pentest traditionnels devraient intégrer ce type d’agent comme outil de pré-tri plutôt que de le voir comme une menace existentielle pour leur activité, en se repositionnant sur la validation finale et le conseil stratégique plutôt que sur la découverte brute de failles.

Pourquoi ce chiffre de 89% ne doit pas être pris pour argent comptant

Il vaut la peine de resituer ce résultat dans la longue histoire des annonces marketing du secteur de la cybersécurité, où les taux de détection ou de réussite affichés par les éditeurs dépassent presque toujours ceux obtenus en conditions réelles de production. Un taux de 89% mesuré sur un échantillon choisi par l’éditeur lui-même, sur des cibles qu’il a lui-même conteneurisées, ne vaut pas un taux de 89% mesuré par un laboratoire tiers sur un échantillon aléatoire et plus large. Les entreprises qui évaluent AWS Continuum ou tout concurrent équivalent devraient exiger, avant tout déploiement en production, un test sur leur propre périmètre applicatif plutôt que de se fier uniquement au chiffre publié dans un billet de blog.

Cette prudence ne retire rien à l’intérêt réel de la démarche. Même avec ses limites, un agent qui automatise une partie du travail de validation d’exploitabilité répond à un besoin concret pour des équipes sécurité débordées. La question qui reste ouverte, et qui déterminera l’adoption réelle de ces outils dans les deux prochaines années, porte moins sur la performance brute que sur la confiance que les entreprises accorderont à un système qui agit de manière autonome sur leur infrastructure critique.

Foire aux questions

Qu’est-ce que l’AWS Security Agent ?

C’est un agent de sécurité autonome développé par AWS, capable de découvrir puis d’exploiter activement des vulnérabilités dans des cibles conteneurisées, sans nécessiter une supervision humaine à chaque étape. Il a été intégré à l’offre plus large AWS Continuum, annoncée publiquement le 15 octobre 2026.

Quel est le taux de réussite exact de l’agent sur les 37 CVE testées ?

AWS rapporte 33 exploitations réussies sur 37 cibles, soit un taux de 89,2%, généralement arrondi à 89% dans les reprises de l’annonce.

AWS Continuum est-il différent de l’AWS Security Agent ?

AWS Continuum désigne l’ensemble multi-agent qui couvre la découverte, la validation par exploitation et la remédiation du code. L’AWS Security Agent en est la composante offensive, celle qui prouve qu’une faille est exploitable en construisant un exploit fonctionnel.

Qu’est-ce que le benchmark CyberGym-E2E ?

C’est un protocole d’évaluation qui mesure la capacité d’un système à trouver une vulnérabilité, produire une preuve de concept fonctionnelle, puis corriger le code source sans casser les comportements déjà validés par des tests, dans une limite de 90 minutes par tâche. AWS Continuum y a obtenu 819 réussites sur 920 tâches, soit 89,0%.

Ce type d’outil peut-il remplacer un pentester humain ?

Rien dans les données publiées ne le suggère à ce stade. L’échantillon de test reste restreint, et AWS n’a pas communiqué le temps ni le coût nécessaires par exploitation. Le consensus actuel dans le secteur penche plutôt vers un usage de ces agents comme outil de pré-tri et de validation rapide, en complément du travail humain plutôt qu’en remplacement.

Quelle est la taille du marché de la sécurité cloud en 2026 ?

Les estimations varient selon le cabinet d’études. Mordor Intelligence évalue le marché logiciel de sécurité cloud à 56,83 milliards de dollars en 2026, avec une projection à 106,6 milliards de dollars en 2031. MarketsAndMarkets donne une estimation plus restrictive, à 34,37 milliards de dollars en 2026, avec une projection à 59,34 milliards de dollars en 2031.

Cet outil est-il disponible pour les entreprises européennes ?

AWS n’a pas précisé publiquement si AWS Continuum est disponible dans ses régions européennes au moment de l’annonce. Les entreprises françaises et européennes intéressées doivent donc vérifier la disponibilité régionale et les implications RGPD avant tout déploiement.

Pourquoi AWS a-t-il fusionné re:Inforce avec re:Invent 2026 ?

Cette fusion, inédite pour l’entreprise, vise à présenter la sécurité comme un fil conducteur transverse de l’offre AWS plutôt que comme un sujet isolé, en regroupant les annonces sur l’IA agentique, les identités, la détection et la réponse, la gouvernance et la sécurité des conteneurs au sein d’un seul événement.