TL;DR
- GPT-5.6 obtient le meilleur score de rappel, avec un maximum de 23/26, devançant ainsi grok-4.5 (20), les modèles Claude Opus (de 15 à 18) et tous les autres modèles que nous avons testés. Cela signifie qu’il est capable de redétecter 88,5 % des CVE.
- Il n'est pas nécessaire d'opter pour la solution la plus coûteuse. Les variantes moins onéreuses du GPT-5 .6 affichent des résultats qui ne s'écartent que d'un ou deux résultats de ceux de son modèle phare, pour un coût bien inférieur, et le regroupement de quelques exécutions d'un modèle de milieu de gamme permet d'obtenir des résultats comparables à ceux d'un seul passage du modèle phare.
- Les résultats des simulations sont incohérents, mais leur agrégation permet d’obtenir de meilleurs résultats. Une simulation isolée peut passer à côté de bogues qu’une autre aurait détectés ; exécuter un modèle plusieurs fois et agréger les résultats (pass@3) donne systématiquement de meilleurs résultats qu’une seule exécution d’un modèle plus puissant et plus coûteux.
- L'approche « open weight » rattrape rapidement son retard. Le GLM-5 .2 parvient déjà à redécouvrir 59 % de l'ensemble des données (16/26), ce qui le place en milieu de peloton parmi les modèles propriétaires.
Chaque lancement d’un nouveau modèle de détection de failles s’accompagne désormais du même argument de cybersécurité : il détecte des vulnérabilités. Mais fonctionne-t-il sur un véritable bug dans un véritable dépôt de code, ou simplement sur un exemple soigneusement sélectionné ? Parmi la douzaine de modèles disponibles, lequel mérite-t-il qu’on lui confie code review? Et comme les modèles les plus performants coûtent dix fois plus cher, voire davantage, par exécution que les moins chers, que vous apporte réellement cette dépense supplémentaire en termes de bugs détectés ?
Il est facile de classer les modèles en fonction de leurs performances brutes et de désigner le plus cher comme le gagnant, mais la question la plus importante est de savoir si son prix en vaut la peine. Nous avons donc testé 13 des modèles parmi lesquels les équipes doivent aujourd’hui choisir, en les confrontant à 26 vulnérabilités répertoriées dans la base de données des avis de sécurité de GitHub. Ces vulnérabilités couvrent un large éventail de langages et de types de projets. Nous avons mesuré deux éléments : le nombre de bogues détectés par chaque modèle, et le coût de leur détection.
Fonctionnement de l'indice de référence
Nous avons sélectionné 26 vulnérabilités issues de la base de données des avis de sécurité de GitHub, choisies au hasard parmi différents langages et types de projets — allant d’une injection SQL dans un framework web à une vulnérabilité RCE par désérialisation dans une boîte à outils d’apprentissage automatique —, puis nous avons demandé à chaque modèle de les redécouvrir un dépôt à la fois au sein de la même analyse de code par IA que nous utilisons en production. Plutôt qu’une fenêtre de discussion, il s’agit d’un modèle doté d’outils réels qui explore le dépôt et analyse le code à la manière d’un auditeur.
C'est le « harnais » qui transforme un modèle linguistique en auditeur. Un assistant de programmation polyvalent est conçu pour une autre tâche : celle de prendre une tâche et de produire du code fonctionnel. Si vous le dirigez vers un dépôt de code et que vous lui demandez s'il est sécurisé, il se comporte comme un développeur qui passe le code au crible à la recherche d'une erreur manifeste, puis s'arrête dès qu'il a trouvé quelque chose de plausible. analyse de code par IA est conçu différemment. Il explore la base de code à la recherche de points d’entrée potentiels, examine en profondeur chaque flux suspect, puis trie les résultats afin que seules les véritables vulnérabilités soient retenues.
Comme nous savions où se trouvait chaque vulnérabilité, nous avons orienté chaque agent d’investigation directement vers l’extrait de code vulnérable. Ainsi, un échec reflète un problème de raisonnement plutôt qu’un gaspillage budgétaire lié à une exploration inutile d’une partie erronée de la base de code. Le modèle doit tout de même comprendre le flux, évaluer l’exploitabilité et la signaler correctement. Les consignes ont été maintenues courtes et indépendantes du modèle, afin qu’aucun fournisseur ne soit favorisé par la formulation.
Nous avons exécuté chaque modèle trois fois et avons regroupé les résultats. Un CVE est considéré comme « détecté » si le modèle le met en évidence lors d’une des exécutions (pass@3).
Nous avons sélectionné plusieurs modèles récents proposés par différents fabricants :
- OpenAI: gpt-5.4-nano, gpt-5.4-mini, gpt-5.5 et la série gpt-5.6 (luna / terra / sol)
- Anthropic : claude-haiku-4-5, claude-opus-4-7, claude-opus-4-8
- xAI : grok-4.5
- Google : gemini-3.1-pro, gemini-3.5-flash
- Poids ouvert : glm-5.2
Résultats par niveau de gravité et de vulnérabilité
Chaque modèle a permis de redécouvrir les deux vulnérabilités CVE critiques (une vulnérabilité RCE liée à la désérialisation et une vulnérabilité XSS stockée). La véritable différence apparaît au niveau des vulnérabilités de gravité élevée et moyenne.
Les CVE les plus difficiles et les plus faciles
Les deux failles critiques et plusieurs failles manifestes liées à l'injection de code et au contrôle d'accès ont été détectées par tous les modèles. Une poignée de chaînes spécifiques a permis de contourner la quasi-totalité d'entre elles.
Les vulnérabilités CVE détectées par tous les modèles suivent le même schéma : des entrées contrôlées par un attaquant déclenchent une opération dangereuse bien connue via un flux local court, comme un appel de désérialisation, l'exécution d'un shell, un « sink » HTML ou une vérification de signature défaillante. Il s'agit là de reconnaissance de schémas, et ce problème est résolu de manière efficace. Les modèles d'entrée de gamme comme les modèles haut de gamme obtiennent tous un score de 13/13, sans aucune distinction entre les capacités.
La véritable frontière, là où les capacités des modèles se distinguent réellement, réside dans la capacité à raisonner sur les vérifications qui font défaut et à suivre des chaînes complexes qu’aucune ligne ne permet à elle seule de détecter. L’exemple le plus parlant est l’injection SQL-1 de notre jeu de données, une injection indirecte via un alias de colonne que l’ORM n’échappe jamais. Seuls GPT-5.5 et les modèles GPT-5.6 les plus performants (sol et terra) l’ont détectée.
Ce que nous apprend la différence entre la moyenne et la médiane
La valeur la plus utile de ce test de performance est la distance entre le résultat moyen d'un modèle et l'union de ses résultats. Étant donné que chaque passage met en évidence un sous-ensemble différent de bogues, leur regroupement (pass@3) permet d'en détecter un nombre surprenant :
Prenons l'exemple de gpt-5.4-nano : aucun test individuel ne dépasse 14, mais trois tests combinés atteignent 18, soit un bond de quatre CVE, car chaque passage met en évidence des bogues différents. claude-haiku-4-5 illustre le cas le plus frappant de variance, avec un score de 7 lors d'un test et de 13 lors d'un autre, pour le même modèle et la même tâche.
Ce qu’il faut retenir ici, c’est qu’il n’est pas nécessaire de se précipiter sur le modèle le plus cher. Trois exécutions de gpt-5.4-nano coûtent environ 170 $ et atteignent un score de 18/26, soit autant que la moyenne obtenue en une seule exécution par un modèle phare comme le gpt-5.6-terra, pour une fraction du prix. Trois passages du gpt-5.4-mini (environ 460 $) permettent d’atteindre 20. Répéter un modèle de milieu de gamme performant surpasse un seul passage d’un modèle haut de gamme bien plus souvent que ne le laisse supposer la différence de prix.
Le raisonnement supérieur en vaut-il la peine ?
Nous avons exécuté les modèles concernés à deux niveaux de raisonnement : le niveau par défaut « high » et le niveau le plus élevé disponible (« xhigh » pour les modèles GPT-5.4/5.5 et Claude, « max » pour les modèles GPT-5.6, grok-4.5 et glm-5.2). Tous les chiffres correspondent à des unions « pass@3 », ce qui permet de les comparer directement.
Les gagnants incontestables sont le GPT-5.5 (+3 pour un coût 1,5 fois supérieur) et le GLM-5.2 (+3 pour un coût 1,3 fois supérieur). Le Claude-Opus-4-8 gagne +2, mais coûte deux fois plus cher. Partout ailleurs, les modèles de haut de gamme n’apportent qu’un seul résultat supplémentaire, voire aucun, et pour le GPT-5.6-Luna et le GPT-5.4-Nano, ce résultat est inférieur d’un point, ce qui reste dans la marge de variation d’une exécution à l’autre. Le GPT-5.6-Terra est le cas le plus flagrant de rendements décroissants : 2,2 fois le coût pour le même résultat de 23.
Les modèles Gemini ne disposant pas d'un réglage supérieur à « haut », ils ne sont pas pris en compte dans cette comparaison.
Conclusion
Il suffit de diriger un modèle Frontier vers une base de code, au sein d’un environnement de test conçu à cet effet, pour qu’il détecte à nouveau la plupart des vulnérabilités connues. Les bogues présentant une « sortie » dangereuse évidente sont résolus. Ceux qui continuent de diviser les modèles n’ont quant à eux aucune « sortie » vers laquelle pointer. Il peut s’agir d’un contrôle d’autorisation manquant, ou d’une injection à laquelle on ne peut accéder qu’en suivant une longue chaîne obscure traversant plusieurs fichiers.
Le niveau le plus onéreux justifie rarement son prix. En exécutant plusieurs fois un modèle moins coûteux et en regroupant les résultats, on obtient davantage, pour moins cher, qu’avec un seul passage d’un modèle phare, et cet avantage ne fait que s’accentuer à mesure que les modèles deviennent moins chers et plus performants. C’est toutefois le « harness » qui détermine si ce raisonnement cible dès le départ la bonne partie de la base de code.
