Depuis quelques années, choisir un modèle d’IA consistait souvent à rechercher les meilleurs scores aux benchmarks ou à sélectionner un fournisseur connu.
Les débats sur le modèle d’IA « meilleur » étaient devenus courants sur les réseaux sociaux parmi les chercheurs en sécurité de l’IA. Pour les équipes de sécurité qui évaluent l’IA pour détecter les vulnérabilités, ces critères ne suffisent plus.
Les capacités brutes du modèle ne représentent qu’une partie de la décision. Les équipes doivent savoir si un modèle peut détecter de véritables vulnérabilités sans submerger les analystes de bruit.
Le coût compte également, en particulier lorsque les tests de sécurité doivent être déployés à grande échelle sur d’importantes bases de code.
Les organisations doivent déterminer où le code sensible est traité et si des changements dans les politiques des fournisseurs pourraient perturber la continuité de son utilisation.
La question la plus pertinente n’est donc pas de savoir quel modèle domine un classement généraliste. Il s’agit de déterminer si l’approche dans son ensemble produit des résultats fiables pour l’organisation.
Cela implique d’évaluer le modèle avec le workflow qui l’entoure et de déterminer si le système obtenu répond aux exigences de sécurité de l’organisation.
Une facture de modèle moins élevée ne signifie pas un coût inférieur
Prenons l’exemple des vulnérabilités de type « insecure direct object reference » (IDOR). Ces failles de contrôle d’accès permettent aux utilisateurs d’accéder à des ressources ou de les modifier alors qu’ils ne devraient pas pouvoir le faire. Les IDOR figurent souvent parmi les premières vulnérabilités que les nouveaux testeurs d’intrusion apprennent à identifier, mais leur apparente simplicité peut être trompeuse.
Détecter une IDOR nécessite un raisonnement contextuel plutôt que la recherche d’une fonction manifestement dangereuse. Un modèle doit comprendre qui devrait avoir accès à une ressource et déterminer si le contrôle d’autorisation nécessaire fait défaut.
Le benchmark de détection des vulnérabilités de type IDOR de Semgrep confronte les modèles à de véritables vulnérabilités dans des bases de code open source. Les performances de détection sont mesurées à l’aide de la précision et du rappel, le score F1 équilibrant les deux pour fournir une mesure globale de la qualité. Semgrep suit également le coût de chaque vulnérabilité confirmée.
Lors d’un test récent, le modèle GLM-5.3 de Z.ai, basée en Chine, a obtenu un score F1 de 23,8 % pour 0,15 $ par vrai positif. Claude Opus 4.8 a produit un score F1 presque identique de 23,6 %, mais chaque vrai positif a coûté 1,04 $. Pour ce test particulier, les modèles ont donc fourni une qualité globale de détection similaire à des coûts très différents.
Cette différence peut devenir significative lorsque les équipes de sécurité des applications examinent d’importantes bases de code ou testent fréquemment de nouvelles modifications. Toutefois, le prix ne suffit pas à faire de GLM-5.3 le meilleur choix. Son rappel lors du même test n’était que de 13,9 %, ce qui signifie qu’il n’a pas détecté la plupart des IDOR connues du jeu de données.
GLM-5.3 a également obtenu de moins bons résultats que son prédécesseur, GLM-5.2. Les chercheurs de Semgrep soulignent que des tests supplémentaires étaient nécessaires pour déterminer si cette différence constituait une véritable régression ou une variation normale des tests.
En définitive, le coût par vrai positif n’a de sens que dans le contexte des performances de détection dont l’organisation a besoin. Un coût d’inférence inférieur présente peu d’intérêt si trop de vulnérabilités passent inaperçues ou si les analystes doivent consacrer beaucoup plus de temps à compenser les limites du modèle.
Le coût total inclut la revue humaine
Les faux positifs illustrent un autre problème. Deux modèles peuvent produire des scores agrégés similaires tout en créant des charges de travail très différentes pour les ingénieurs chargés de valider leurs résultats.
Un autre benchmark de Semgrep portant sur Kimi K3 a démontré ce compromis. Avec la même configuration de prompts guidés, Kimi a obtenu un score F1 de 34,0 %, proche de celui de GLM-5.2, à 34,5 %, et de Claude Opus 4.8, à 34,3 %. Cependant, la précision de Kimi était de 68,4 %, contre 86,3 % pour GLM-5.2 et 91,0 % pour Claude Opus 4.8. Les ingénieurs ont donc dû examiner et écarter une part plus importante de ses résultats en les considérant comme des faux positifs.
Les résultats au niveau du dépôt ont soulevé une autre inquiétude. Kimi a obtenu en moyenne un score F1 d’environ 6 % sur le plus grand dépôt de style entreprise du benchmark, contre environ 20 % pour GLM et les modèles de pointe. Un seul dépôt ne permet pas d’établir que la taille de la base de code est à l’origine de cette baisse, mais le résultat montre pourquoi les équipes devraient tester les modèles dans des environnements similaires aux leurs plutôt que de se fier uniquement aux scores agrégés.
Le coût réel de la sécurité assistée par l’IA va également au-delà de l’utilisation du modèle. Les organisations doivent prendre en compte l’infrastructure nécessaire au fonctionnement du système et les efforts d’ingénierie requis pour le maintenir.
Les vulnérabilités non détectées représentent un autre coût potentiel qui n’apparaîtra pas sur la page tarifaire d’un fournisseur. Ensemble, ces facteurs déterminent si un système est viable en pratique.
Le modèle lui-même n’est qu’un composant. Le harnais qui l’entoure peut avoir une incidence significative sur les performances de sécurité en déterminant la manière dont le modèle reçoit les informations et effectue son analyse.
Dans le même ensemble de benchmarks, le rappel de GPT-5.6 Sol est passé de 25 % avec un prompt guidé à 73 % dans le harnais multimodal de Semgrep. Le modèle sous-jacent restait identique, mais le système qui l’entourait produisait un résultat très différent.
Pour les responsables de la sécurité, cette différence modifie le processus d’évaluation. Savoir quel modèle utilise un produit est moins instructif que comprendre comment le système complet se comporte sur du code représentatif et quelle charge de travail ses résultats imposent aux équipes de sécurité.
La géographie change la donne
Un autre élément vient compliquer la situation. Certaines alternatives convaincantes ne proviennent pas exclusivement des laboratoires américains à la pointe.
GLM-5.2, par exemple, est disponible en poids ouverts, ce qui permet aux organisations de le télécharger et de l’exécuter sur leur propre infrastructure. Lors des tests de Semgrep, il a surpassé Claude sur un benchmark d’IDOR, pour un coût d’environ 0,17 $ par vulnérabilité détectée.
Pour les organisations qui traitent de la propriété intellectuelle sensible ou sont soumises à des exigences strictes en matière de données, le lieu où le code est traité peut compter autant que les performances aux benchmarks. Un modèle à poids ouverts exécuté dans l’environnement propre d’une organisation présente une proposition différente en matière de sécurité et de gouvernance d’un modèle fermé accessible via un fournisseur externe.
La résilience compte également. Les fournisseurs peuvent modifier la disponibilité ou le prix d’un modèle sans que les clients aient beaucoup de prise. Les politiques régissant l’accès peuvent elles aussi évoluer avec le temps. Construire un workflow de sécurité critique autour d’un seul fournisseur revient à accepter cette dépendance externe.
Rien de tout cela ne signifie que les modèles étrangers ou à poids ouverts doivent bénéficier d’un passe-droit. Les organisations doivent toujours évaluer l’origine d’un modèle et déterminer si son comportement est suffisamment fiable pour les tâches de sécurité. Elles doivent également vérifier si l’approche de déploiement répond à leurs exigences de sécurité. Le pays d’origine n’est pas un indicateur pertinent des capacités, pas plus qu’une marque américaine connue ne garantit qu’un modèle soit adapté.
La qualité croissante de modèles comme GLM et Kimi offre aux équipes de sécurité quelque chose de précieux : un levier et un choix.
Évaluez la tâche, pas la marque
Il est peu probable qu’un seul modèle d’IA soit le meilleur choix pour tous les programmes de sécurité des applications.
Une équipe qui privilégie la découverte d’un large éventail de vulnérabilités accordera peut-être davantage de poids au rappel. Une autre qui peine à gérer le volume d’alertes pourra privilégier la précision.
Une organisation soumise à des exigences strictes de résidence des données pourra privilégier l’hébergement sur sa propre infrastructure, tandis qu’une équipe qui examine de grandes quantités de code pourra accorder davantage d’importance au coût par résultat confirmé.
Une évaluation utile commence par des bases de code représentatives, y compris les plus grands dépôts que l’équipe prévoit de faire traiter par le système. Les équipes doivent mesurer la précision et le rappel tout en examinant les vulnérabilités qui passent inaperçues. Les calculs de coût doivent tenir compte des ressources nécessaires au fonctionnement du système ainsi que du temps requis pour examiner ses résultats.
Les tests doivent également refléter l’environnement réel qui entoure le modèle, plutôt que d’évaluer celui-ci isolément. Ces évaluations doivent être répétées à mesure que la technologie et les offres des fournisseurs évoluent.
Pour les responsables de la sécurité des applications, le choix d’un modèle devrait moins ressembler à une décision fondée sur un classement qu’à une évaluation d’ingénierie.
Le modèle le plus connu peut encore être le bon choix, mais il devrait s’imposer parce qu’il offre le meilleur résultat en matière de sécurité dans les limites de l’organisation, et non parce que son nom figure en tête du benchmark de quelqu’un d’autre.
Les modèles d’IA ne sont qu’une option pour détecter les failles de sécurité dans le code et l’infrastructure. Consultez notre guide des meilleurs outils d’analyse des vulnérabilités pour comparer d’autres approches de détection des vulnérabilités.