Aller au contenu
← Tous les articles

Mesure7 octobre 20266 min

Ce que les agents IA trouvent vraiment en test d'intrusion

On lit beaucoup que l'IA va remplacer le pentest. Un benchmark publié en août 2026 a mesuré onze modèles de pointe sur des applications web réelles. Le meilleur trouve la moitié des vulnérabilités, pour 1 400 dollars. Les chiffres méritent d'être regardés en face.

Le protocole

PWNBench, publié par l'équipe Novee, évalue onze modèles de huit laboratoires sur des applications open source de production — plateformes de développement, CRM, outils d'observabilité, ERP. Plus de 400 vulnérabilités de référence, majoritairement des failles inédites plutôt que des CVE connues, afin d'éviter que les modèles réussissent par simple mémorisation.

Le cadre est celui d'un test en boîte grise de bout en bout : découvrir, exploiter, rapporter. L'agent reçoit un compte ordinaire et une documentation limitée. Aucun indice sur les failles. Le même harnais technique est utilisé pour tous les modèles, afin que la comparaison porte sur le modèle et non sur l'outillage.

Les résultats

Modèle Vulnérabilités trouvées Coût
Le plus performant, effort maximal51 %1 400 $
Meilleur rapport coût/résultat42 %209 $
Milieu de tableau20–30 %200–600 $
Bas de tableau< 15 %—

Le chiffre à retenir : sur une application où les vulnérabilités existent par construction, le meilleur modèle du marché en trouve la moitié, pour le prix de plusieurs jours de prestation humaine.

Quatre enseignements qui comptent

La précision varie plus que la détection

Les auteurs mesurent séparément le taux de découverte et la précision — la proportion de rapports qui correspondent à de vraies vulnérabilités. L'écart entre modèles y est considérable : les meilleurs atteignent 78 à 82 %, les moins bons tournent entre 50 et 60 %. Deux modèles au taux de découverte comparable peuvent être séparés de 30 points de précision.

C'est l'angle mort des démonstrations enthousiastes. Un agent qui remonte beaucoup de choses dont la moitié est fausse ne fait pas gagner du temps : il en fait perdre, parce que quelqu'un doit trier.

Multiplier les tentatives vaut un changement de modèle

Augmenter l'effort de raisonnement ou lancer plusieurs tentatives en parallèle déplace un système sur la courbe résultat/coût « autant que changer de modèle ». Mais le gain croît de façon logarithmique : les exécutions successives trouvent en grande partie les mêmes choses.

C'est précisément ce qu'une mémoire corrige. Si le système sait ce qui a déjà été testé, la deuxième tentative n'est plus une répétition partielle de la première.

Trouver des bugs dans du code n'est pas attaquer un système

Les auteurs comparent leurs résultats à d'autres benchmarks et constatent que les classements ne se transposent pas. Un modèle qui excelle à repérer des failles en lisant du code source peut rester au niveau des autres quand il s'agit d'attaquer le même système de l'extérieur. « Repérer un bug dans du code est différent d'attaquer un système depuis l'extérieur. »

Ce que le benchmark ne mesure pas

Les auteurs sont explicites sur leurs limites : le harnais est volontairement simplifié, la base de référence est incomplète, et la variance entre applications est importante. Ils précisent que les scores absolus ne doivent pas être lus comme une performance de pentest réelle.

Surtout, trois facteurs sont neutralisés et donc jamais évalués : les outils mis à disposition de l'agent, sa mémoire, et le nombre de tours qu'on lui laisse. Ce sont pourtant les variables sur lesquelles un système opérationnel se construit.

Ce que nous en tirons

Ces chiffres fixent un cadre honnête. Un agent ne remplace pas un chercheur qui passe trois jours à comprendre la logique métier d'une application. Sur la profondeur, l'écart reste net.

L'avantage est ailleurs : dans la persistance. Un système automatisé peut travailler sur des dizaines d'actifs en continu, ne jamais rejouer un test déjà fait, et accumuler pendant des mois. Aucune équipe humaine ne tient ce rythme. La valeur n'est pas « il trouve mieux », elle est « il ne s'arrête pas et il n'oublie rien ».

Cela impose deux exigences de conception, directement issues des chiffres ci-dessus. D'abord la précision : puisque c'est elle qui sépare les systèmes utiles des systèmes bruyants, rien ne doit être remonté sans preuve d'exploitation. Ensuite la mémoire : puisque les tentatives répétées se recouvrent, le système doit savoir ce qu'il a déjà fait pour que chaque nouvelle heure apporte autre chose que la précédente.

En résumé : l'automatisation ne gagne pas sur la finesse. Elle gagne sur la durée, à condition de ne rapporter que du démontré et de ne jamais refaire deux fois le même test.

Sources