Nous avons détruit 11,7 milliards de jetons pour trouver le meilleur modèle d'IA cybernétique

Nous avons détruit 11,7 milliards de jetons afin d'évaluer les capacités cybernétiques de 10 modèles d'IA, en effectuant trois essais pour chacun d'entre eux, avec pour mission de redécouvrir 32 vulnérabilités récentes disponibles dans le commerce.

Ce benchmark est une évolution de notre précédent benchmark « known-CVE »: il s'appuie sur un nouvel ensemble de données plus complexe, intègre davantage de modèles et examine de plus près leurs résultats, la fiabilité de leurs détections, ainsi que leurs particularités et leurs compromis.

Nous ajoutons ainsi les modèles GLM-5.3, DeepSeek V4 Pro 0813, DeepSeek V4 Flash 0731, Qwen3.8-Max, Kimi K3 et Grok 4.6 à notre gamme.

TL;DR :

• C'est DeepSeek V4 Pro 0813 qui détecte le plus grand nombre de vulnérabilités. En cumulant les résultats de trois exécutions, on atteint 28 vulnérabilités sur 32.
• Il n'est pas nécessaire d'opter pour le modèle le plus cher. Trois exécutions de DeepSeek Pro coûtent environ 295 dollars et surpassent les performances d'Opus 5, de Grok 4.6 ou de Sol. Trois exécutions de Flash coûtent 108 dollars et atteignent 24 correspondances, soit le meilleur résultat obtenu par Grok lors d'un passage individuel, pour moins d'un quart du prix.
• Les modèles présentent des incohérences au niveau du taux de rappel ; la répétition permet d'y remédier. Une seule exécution ne permet pas de saisir toute l'étendue des résultats, mais le regroupement des résultats de plusieurs exécutions comble cette lacune. DeepSeek Pro détecte 17 vulnérabilités lors de son premier passage, mais 28 au total sur trois passages.
• Les modèles open source surpassent désormais la frontière publique. DeepSeek V4 Pro s'est classé en tête de tous les modèles fermés publics que nous avons testés en termes de taux de rappel global des vulnérabilités. Qwen, Kimi et GLM-5.3 suivent, avec une grande cohérence des résultats sans perte de taux de rappel. Utilisés à bon escient, les modèles open source peuvent désormais rivaliser directement avec les modèles fermés de pointe.
• Le prix à payer pour une couverture peu coûteuse, c’est le bruit. Les modèles ouverts ont rattrapé la frontière à des coûts bien inférieurs, mais ont également généré le plus grand nombre de pistes erronées que le pipeline a dû rejeter.

Comment fonctionne le benchmark

Nous avons sélectionné 32 vulnérabilités issues de dépôts réels et avons demandé à chaque modèle de les redécouvrir à partir de la source.

Chaque modèle a exécuté l'ensemble complet des 32 cas à trois reprises, soit un total de 96 exécutions. Cela nous permet de mesurer le nombre de vulnérabilités qu'un modèle est capable de détecter, ainsi que le nombre de celles qu'il détecte de manière fiable. 

Le cadre de test était une version restreinte du « harness » présenté sur notre page analyse de code par IA. Nous avons remplacé le modèle de l'étape primaire, chargé de l'exploration du code et du raisonnement, par chacun de nos candidats, et avons accordé à l'agent un maximum de 30 tours. Les modèles ne disposaient par ailleurs d'aucun accès à Internet.

Nous avons veillé à ce que les ensembles de données soient à jour. Les 32 vulnérabilités ont été sélectionnées parmi les CVE récemment divulguées afin de réduire le risque que les modèles aient déjà été confrontés à la vulnérabilité, à la description ou au correctif pendant l'entraînement. L'objectif était de tester la capacité de raisonnement face aux vulnérabilités plutôt que la mémorisation de bogues bien connus. Les cas, les consignes, les outils et la politique d'évaluation ont tous été figés d'une exécution à l'autre.

Commençons par établir quelques définitions, que nous utiliserons tout au long de cet article :

• Rappel - Combien de vulnérabilités le modèle a-t-il réellement détectées ?
• Précision – Combien des résultats rapportés ont été acceptés ? 
• Pass - Une exécution complète d'un modèle sur notre ensemble de données comprenant 32 vulnérabilités

Tirer parti de la variance des résultats des modèles

Les performances des modèles de langage à grande échelle (LLM) dépendent en grande partie du problème à résoudre. En général, les problèmes pénalisent la variance des résultats fournis par le modèle lorsque la reproductibilité ou la fiabilité de ces résultats est requise.

Si l'on confie la même tâche à un agent au cours de trois sessions distinctes, il se peut qu'il la résolve en adoptant trois approches différentes. Aucune de ces approches n'est nécessairement « erronée », mais cette variation rend le système imprévisible, ce qui n'est généralement pas souhaitable, car on a alors la même entrée, le même système, mais un résultat différent.

Cependant, la détection des vulnérabilités est un problème pour lequel il est possible de tirer parti de cette propriété des grands modèles de langage (LLM), plutôt que de la subir. Fondamentalement, il s’agit d’un problème d’espace de recherche, et les problèmes de recherche peuvent tirer parti de cette variance. Dans le cadre des audits de sécurité, la mise en commun des résultats de plusieurs exécutions peut, comme vous le verrez, conduire à de meilleurs résultats.

L'incohérence entre les modèles est source de diversité, ce qui peut potentiellement améliorer le taux de rappel. Si une exécution détecte des bogues qu'une autre ne repère pas, vous pouvez conserver les deux.

DeepSeek Pro a détecté 17 vulnérabilités lors de son premier passage. Si cela avait été le seul passage, ce serait le résultat final.

Mais ses deuxième et troisième passages ont permis de détecter des failles que les passages précédents avaient laissées de côté. En cumulant les trois résultats, DeepSeek a atteint un score de 28/32, remportant ainsi la première place de notre test de performance.

La même chose s'est produite ailleurs. Qwen est passé de 19 lors de son premier passage à 26 au classement général. Kimi est passé de 17 à 25. Grok est passé de 24 à 26.

Les modèles exploratoires ont énormément tiré profit de la répétition, car chaque exécution explorait des voies utiles différentes. Grok en a beaucoup moins profité, car il identifiait déjà à peu près les mêmes vulnérabilités à chaque fois.

Chaque modèle a identifié au moins une fois 17 cas. L'un d'entre eux a réussi à les identifier tous les dix. Les 14 cas restants sont ceux pour lesquels les modèles ont cessé de donner des résultats interchangeables.

DeepSeek a affiché le taux de rappel global le plus élevé. Grok s'est montré le plus régulier.

DeepSeek a détecté le plus grand nombre de vulnérabilités, mais ses résultats n'étaient pas très réguliers d'un test à l'autre. Sur trois tests, le V4 Pro 0813 a finalement détecté 28 des 32 CVE, ce qui lui a valu le meilleur résultat global du test de performance. Cependant, seules 10 d'entre elles ont été détectées à chaque test.

Grok s’est montré plus prudent. Il a détecté un peu moins de vulnérabilités au total (26 sur 32), mais lorsqu’il en identifiait une, il avait beaucoup plus de chances de la retrouver. Il a détecté 21 CVE lors des trois séries de tests, ce qui en fait le modèle le plus constant parmi ceux que nous avons testés, surpassant tous les autres.

Opus 5 a également détecté 26 éléments sur 32 et a enregistré le meilleur résultat individuel avec 25, dont 19 détectés de manière constante lors des trois passages. Sol a détecté 25 éléments sur 32 avec la même régularité (19 cas) et a produit certains des rapports les plus précis.

‍

Les modèles DeepSeek ont également généré un nombre bien plus important de résultats potentiels que les autres modèles. Cette exploration intensive a permis d'améliorer leur taux de rappel, mais elle a également entraîné un nombre plus important de fausses pistes que le reste du processus a dû filtrer.

On observe une tendance claire : le surcoût lié aux frontières se traduit par une réduction des coûts liés au triage a posteriori et par une meilleure cohérence.

Dans les coulisses de l'enquête

DeepSeek Pro s'est révélé être le modèle le plus « gourmand » du test de performance. C'est lui qui a utilisé le plus de budget d'exploration, avec une médiane de 24 tours sur la limite maximale de 30 tours que nous accordons à nos agents.

Opus était la plus impitoyable de toutes les frontières fermées. Les recherches qui ne donnaient aucun candidat prenaient en moyenne 29 tours, tandis que celles qui aboutissaient à un candidat n'en prenaient que 19.

Sol a enregistré en moyenne environ 2,74 problèmes potentiels par enquête et a produit certaines des conclusions les plus claires que nous ayons observées, en veillant généralement à ce que le chemin menant de l'entrée contrôlée par l'attaquant à l'impact sur la sécurité reste facile à suivre.

Qwen, ouf. Ce modèle m'a donné une impression de déjà-vu avec les CVE. 

Dans 95 des 96 exécutions, après avoir identifié le code source, l'algorithme a passé plusieurs itérations à analyser les vulnérabilités (CVE) plus anciennes, déjà rendues publiques, présentes dans le code source, en s'appuyant sur ses connaissances acquises lors de l'apprentissage. 

Ces vulnérabilités avaient déjà été corrigées dans la version du code source sur laquelle nous avions effectué nos tests de performance ; la majeure partie de ce budget alloué à l’enquête a donc été gaspillée avant que l’on ne revienne finalement à l’analyse du code.

Parfois, c'est un sentiment de « déjà-vu » qui sert d'indice. D'autres fois, il s'agit simplement d'une visite touristique, mais quoi qu'il en soit, Qwen s'adonnait à une activité bien plus proche de l'analyse autonome de variantes que de la simple recherche de correspondances, sans qu'on le lui ait demandé. 

Malgré cette particularité, il a considérablement grimpé dans le classement, égalant Opus et Grok en termes de rappel groupé « pass@3 », se plaçant juste derrière DeepSeek, en tête.

Parmi tous les participants, Kimi présentait le profil d’exploration le plus court, avec une médiane de 12 itérations. Ses tracés convergeaient souvent de manière explicite, éliminaient les théories les moins solides et aboutissaient à une conclusion bien plus tôt dans le processus d’investigation que ceux de ses pairs.

Il affichait également une précision globale de 92,3 %, supérieure à celle de tous les autres modèles « open-weight » que nous avons testés. Moins de résultats erronés et moins de faux positifs.

GLM comble le fossé entre les régions frontalières

Non, nous n'avons pas oublié la version GLM-5.3. En fait, nous avons passé toute la nuit à travailler dessus (littéralement !). 

Grâce à Z.AI, nous avons eu l'occasion de travailler en étroite collaboration avec leur équipe en tant que partenaire d'évaluation précoce du GLM-5.3, en le soumettant à notre test de référence en matière de cybersécurité et en leur faisant part de nos commentaires tout au long du processus de pré-lancement.

Au cours de l'évaluation, nous avons testé deux versions de GLM-5.3 : une version préliminaire et la version finale commercialisée.

La version GLM-5.3-preview a surpassé GPT 5.6 Terra en termes de rapport coût-performance à pass@3. Elle a redécouvert 75 % des CVE tout en coûtant 40 % moins cher et s'est également révélée être le modèle à poids ouvert le plus constant, avec 14 CVE détectées sur 32 lors des trois séries de tests.

La version finale de GLM a apporté des améliorations à cette base et a gagné plusieurs points en termes de rappel et de cohérence, tout en conservant à peu près la même précision.

Elle s'est avérée nettement plus persistante que la version précédente, ce qui a entraîné une augmentation de la médiane du nombre de tours utilisés, qui est passée de 18 à 23.

Dans l'ensemble, les résultats montrent une exploration plus large et plus approfondie. Recall est passé de 24/32 à 25/32, se plaçant au coude à coude avec GPT Sol tout en étant 65,5 % moins cher. Il a également surpassé GPT-5.6 Terra, GPT-5.6 Luna et DeepSeek Flash 0731, et a terminé à seulement 1 CVE derrière Opus 5, tout en restant 69,8 % moins cher.

Sa cohérence s’est également améliorée, passant de 14/32 à 18/32, un résultat constant sur l’ensemble des exécutions. Ces améliorations se sont accompagnées d’une augmentation du coût par CVE détectée, qui est passé de 14,77 $ à 19,65 $. Ce modèle reste toutefois nettement moins cher que Sol, Opus et Grok, tout en offrant des performances compétitives. Il a également affiché le taux de rappel « pass@1 » le plus élevé de tous les modèles ouverts.

Les « open weights » viennent de dépasser la limite publique

Lors de notre dernier test comparatif, on constatait que les stratégies « open weights » rattrapaient rapidement leur retard. Cette fois-ci, elles ont fait bien plus que rattraper leur retard. Correctement mises en œuvre, elles ont affiché des performances équivalentes, voire supérieures, à celles de la classe de référence.

DeepSeek a offert la meilleure couverture globale parmi tous les modèles, devançant Opus, Sol et Grok. GLM 5.3 a rattrapé son retard en termes de cohérence d’un exécution à l’autre, tandis que Qwen a maintenu ses performances en matière de précision et de rappel globaux. 

Les modèles fermés conservaient certes leurs propres avantages, mais l'ancienne hiérarchie, qui plaçait un modèle à frontière fermée au sommet et tout le reste en dessous, n'a pas résisté à ce test comparatif.

Ce test de performance évalue uniquement les versions accessibles au public des modèles « closed frontier ». Nous n'avons pas utilisé les modèles Mythos ni ceux de la classe GPT 5.6 Daybreak dans nos tests.

Cela signifie-t-il que l'on peut retirer le Sol/Opus de ses systèmes et le remplacer par n'importe quel modèle « open-weight » ?

Non, pas du tout.

Nous insistons sur l'expression « correctement harnachés ». Les modèles à poids libre sont redoutables, mais ils n'ont pas encore atteint le niveau requis pour remplacer une frontière sans un harnais soigneusement conçu.

À mesure que les modèles de pointe s'améliorent, on constate une tendance selon laquelle une utilisation minimale des paramètres est synonyme de meilleures performances. Le groupe des modèles « open-weights » est encore loin d'avoir atteint ce minimum.

Alors, quel modèle choisirions-nous ?

Avec environ 11,7 milliards de jetons, « Quel est le meilleur modèle ? » n'est pas la bonne question.

Il vaut mieux se demander où un modèle devrait s'intégrer dans votre système. Quel chercheur envoyez-vous en premier, lequel en deuxième, et qui vérifie le travail de qui ?

Il n'est pas nécessaire de se précipiter sur le modèle le plus cher. Trois cycles d'analyse avec DeepSeek V4 Pro 0813 ont coûté environ 295 dollars et ont permis de détecter 28 des 32 vulnérabilités, soit plus qu'un seul cycle d'analyse avec Opus 5, Grok 4.6 ou Sol, alors que chacun de ces cycles coûte entre 450 et 590 dollars environ. 

Même trois exécutions Flash ne coûtent que 108 dollars et permettent d'atteindre 24 correspondances, soit le meilleur résultat obtenu par Grok en un seul passage, pour moins d'un quart du prix. La répétition d'un modèle efficace peut offrir une meilleure couverture qu'un seul essai coûteux, mais elle s'accompagne de ses propres inconvénients. Le coût est répercuté sur les étapes ultérieures du pipeline. 

C'est précisément pour trouver le juste équilibre entre capacité de rappel et précision que l'ingénierie des harnais entre en jeu.

On est ravis de ces nouveautés ! Ça vaut bien de sacrifier quelques heures de sommeil. À la prochaine !

Ce benchmark évalue des modèles bruts. Aikido les transforme en résultats fiables concernant les vulnérabilités. Code Security Audit applique ce raisonnement à l'ensemble de votre code source. Considérez-le comme une IA agentique SAST . Aikido Attack envoie des agents autonomes vers votre application en cours d'exécution, en regroupant les résultats positifs et en écartant les fausses pistes, à l'instar de la manière dont le pipeline les a rejetées ici. Exploitez la puissance des modèles les plus récents et sécurisez vos systèmes. Découvrez-le sur aikido.dev.

P.S. Nous recrutons également. Venez rejoindre notre équipe.