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 maximal | 51 % | 1 400 $ |
| Meilleur rapport coût/résultat | 42 % | 209 $ |
| Milieu de tableau | 20–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
- Kasten, Shalev, Fradlis, Dancig, Padnos (Novee) — PWNBench-v0.1: Evaluating Frontier Models for Web Application Pentesting, 20 août 2026, mis à jour le 2 septembre 2026.
- Chiffres relevés le 6 octobre 2026. Le benchmark n'est pas publié en source ouverte ; les valeurs citées proviennent de la publication des auteurs.