Depuis 2024 et particulièrement en 2026, les modèles de langage (LLM) sont progressivement intégrés dans les opérations de cybersécurité des institutions financières. Ils sont utilisés comme assistants à l’analyse d’alertes, à la corrélation d’événements, à la recherche de menaces ou à l’aide à la réponse à incident.
Dans ce contexte, une question revient systématiquement chez les RSSI et les directions des risques : comment mesurer objectivement les capacités et les risques d’un LLM avant ou pendant son usage opérationnel ?
Pour répondre à ce besoin, plusieurs benchmarks spécialisés en cybersécurité ont émergé, parmi lesquels CyberSecEval (développé initialement par Meta et enrichi par la communauté) et CyberSOCEval, plus orienté usages SOC. Ces outils apportent des éléments de réponse, à condition de comprendre précisément ce qu’ils mesurent — et ce qu’ils ne mesurent pas.
CyberSecEval et CyberSOCEval : que mesurent réellement ces benchmarks ?
Les suites CyberSecEval (versions 2 à 4) évaluent principalement les risques offensifs et défensifs des LLM dans des scénarios cyber. Elles testent notamment :
la résistance aux prompt injections et contournements de garde-fous,
la capacité du modèle à générer du code vulnérable ou malveillant,
sa propension à fournir des informations exploitables dans un contexte d’attaque,
sa compréhension de scénarios de sécurité standards (authentification, chiffrement, contrôles d’accès).
CyberSOCEval, plus récent, se concentre sur des cas d’usage SOC :
triage d’alertes,
analyse de journaux,
raisonnement sur des incidents simulés,
priorisation d’événements de sécurité.
Ces benchmarks s’appuient sur des jeux de données contrôlés et des scénarios reproductibles, souvent inspirés de cadres reconnus (MITRE ATT&CK, OWASP, pratiques CERT). Ils constituent une base comparative utile pour observer des différences de comportement entre modèles.
Ce que disent les résultats… et ce qu’ils ne disent pas
Les résultats issus de ces benchmarks sont souvent présentés sous forme de scores ou de taux de réussite. Ils peuvent montrer, par exemple, qu’un modèle résiste mieux qu’un autre aux tentatives de prompt injection, ou qu’il génère moins fréquemment du code exploitable.
Cependant, plusieurs limites structurelles doivent être clairement posées :
Les scénarios sont décontextualisés : ils ne reflètent pas la complexité d’un SI bancaire réel, avec ses règles métiers, ses données sensibles et ses contraintes réglementaires.
Les données sont souvent synthétiques : elles ne reproduisent pas la variabilité ni les biais des flux réels traités par un SOC.
Les scores ne mesurent pas la gouvernance : un bon résultat ne dit rien sur les contrôles d’accès, la journalisation, la traçabilité ou la supervision humaine du modèle.
Les comportements en production peuvent diverger : un modèle performant en test peut se comporter différemment une fois intégré à des chaînes automatisées ou exposé à des entrées non prévues.
Autrement dit, un benchmark n’est pas une preuve de sécurité, mais un indicateur partiel.
Intérêt concret pour les banques et assurances
Utilisés avec discernement, ces benchmarks présentent néanmoins plusieurs intérêts opérationnels pour le secteur financier :
Comparer des modèles envisagés pour un usage SOC ou GRC, sur des critères homogènes.
Documenter les risques résiduels liés à l’usage d’un LLM, dans une logique proche de l’analyse de risques classique.
Structurer les échanges avec les régulateurs et auditeurs, en apportant des éléments factuels plutôt que des discours marketing.
Éclairer les choix d’architecture : degré d’autonomie du modèle, périmètre des tâches autorisées, nécessité de validations humaines.
Dans un contexte DORA, où la maîtrise des risques liés aux technologies critiques est exigée, ces outils peuvent contribuer à une démarche de justification et de traçabilité, sans se substituer aux contrôles organisationnels.
Intérêt concret pour les banques et assurances
Le principal danger réside dans une lecture excessive des scores. Plusieurs écueils sont régulièrement observés :
considérer un benchmark comme un label de sécurité,
supposer qu’un modèle « bien noté » peut être utilisé sans supervision,
ignorer les risques liés à l’intégration (API, données, droits, interconnexions),
sous-estimer l’importance du contexte métier et géopolitique dans l’analyse des alertes.
Dans le secteur financier, où les incidents ont des impacts systémiques, cette sur-interprétation peut conduire à une fausse impression de maîtrise.
Intégrer les benchmarks dans une gouvernance IA maîtrisée
L’approche la plus robuste consiste à intégrer ces benchmarks comme un outil parmi d’autres dans la gouvernance IA :
en complément d’analyses de risques classiques,
couplés à des tests internes contextualisés,
intégrés à des processus de validation continue,
associés à une supervision humaine explicite.
Cette logique est cohérente avec les exigences émergentes en matière de gouvernance de l’IA, telles qu’observées dans les travaux européens sur l’AI Act et dans les attentes des superviseurs financiers.
Une lecture commune plutôt qu’un verdict technologique
Du point de vue du Forum des Compétences, l’enjeu n’est pas de sacraliser ou de discréditer ces benchmarks, mais de proposer une lecture commune et partagée entre RSSI, DSI et directions des risques.
Les benchmarks comme CyberSecEval ou CyberSOCEval permettent d’objectiver certaines dimensions techniques des LLM. Ils ne remplacent ni l’expertise humaine, ni la compréhension fine des systèmes, ni la responsabilité organisationnelle.
Dans un environnement bancaire et assurantiel, la maturité ne consiste pas à chercher un score maximal, mais à savoir ce que l’on mesure, pourquoi on le mesure, et comment on en tient compte dans la décision.
