Un modèle de langage peut réussir presque tous les tests de sécurité et échouer face à une attaque bien construite. Le problème ne tient pas seulement à la puissance des LLM. Il vient aussi de la façon dont on les évalue.
Les benchmarks de safety mesurent certains comportements à partir de scénarios définis. Ils ne reproduisent pas nécessairement les usages réels, les conversations longues ou les agents connectés à des outils. Avec la nouvelle génération d’AILuminate, les entreprises possèdent de mesures plus comparables. Encore faut-il savoir lire les scores, distinguer refus et robustesse, et compléter les classements par des tests adaptés à leurs propres risques.
Trois points clés :
- Un score de safety n’est pas une certification de sécurité
- Les jailbreaks et les injections de prompts exigent des tests distincts
- La meilleure évaluation combine benchmarks publics, scénarios métier et surveillance après déploiement.
La sécurité des LLM ne se résume pas à refuser une demande dangereuse
La safety désigne la capacité d’un système d’intelligence artificielle à éviter des réponses préjudiciables. Cela concerne par exemple des instructions facilitant des actes violents, des divulgations de données privées ou des contenus discriminatoires. La security concerne aussi la résistance aux attaques contre le système :
- Manipulation des instructions
- Accès non autorisé à des outils
- Exfiltration ou contournement des protections
Ces deux dimensions se recoupent, mais ne se confondent pas. Un assistant qui refuse une requête directement malveillante peut néanmoins exécuter une instruction cachée dans un document qu’il vient de consulter. Par ailleurs, on évalue parfois le modèle nu, parfois une application complète. Dans ce second cas, le prompt système, les filtres de modération, le moteur de recherche documentaire, les permissions et les outils peuvent modifier les résultats.
Comparer deux chiffres sans savoir ce qui a réellement été testé revient à comparer deux voitures dont l’une passe l’épreuve avec ses aides à la conduite et l’autre sans. Le protocole doit décrire la configuration, les versions, les paramètres et les conditions de test.
AILuminate 1.2.1 apporte une nouvelle façon de lire les scores
MLCommons a publié en septembre 2026 une évolution majeure de son benchmark AILuminate Safety, puis des résultats sous l’étiquette 1.2.1 en octobre. Le dispositif couvre douze catégories de risques, dont la vie privée, les crimes violents, les armes indiscriminées, les contenus haineux et certains conseils spécialisés. Sa version actuelle utilise 3 900 prompts officiels confidentiels, soit 325 par catégorie. Les réponses sont jugées selon un standard explicite et les scores sont rapportés sur une échelle percentile de 0 à 100. Un 90 ne signifie donc pas que 90 % des réponses sont sûres : il situe le système dans la distribution de référence du benchmark.
Le changement est important pour les responsables achats et les équipes de gouvernance. L’ancien système utilisait des appréciations allant de Poor à Excellent. La nouvelle version introduit un évaluateur spécialisé, un ensemble de questions resserré et une échelle fixée avant publication. Les anciennes notes ne sont pas directement comparables aux scores 1.2.1. C’est précisément le genre de détail qui disparaît souvent dans les comparatifs trop rapides. Une hausse affichée entre deux générations de benchmark peut refléter une modification du protocole plutôt qu’une amélioration du modèle.
Le 29 octobre 2026, MLCommons présentait des résultats officiels pour 27 systèmes, répartis entre modèles à poids ouverts et outils de garde-fou. Le périmètre reste limité aux échanges texte-vers-texte en anglais américain, avec une requête et une réponse. Il ne mesure pas directement une conversation de vingt tours, un agent naviguant sur le Web ou une chaîne de traitement documentaire. Un classement utile, donc, mais qui ne doit jamais être lu comme un feu vert universel pour un déploiement.
HELM Safety et HarmBench posent des questions différentes
Le projet HELM Safety du Stanford Center for Research on Foundation Models rassemble plusieurs benchmarks. Il couvre notamment la violence, la fraude, la discrimination, le harcèlement ou la tromperie. Son intérêt tient à la diversité des jeux d’évaluation et à la publication de résultats comparables pour plusieurs familles de modèles. En contrepartie, une moyenne peut masquer des écarts importants entre catégories. Un assistant performant sur les demandes dangereuses explicites peut se montrer moins robuste quand un utilisateur exploite une formulation ambiguë ou une stratégie d’attaque.
HarmBench se concentre davantage sur l’évaluation standardisée des comportements nuisibles et des attaques adversariales. Il sert notamment à comparer des tentatives de jailbreak et les défenses opposées par les modèles. La différence avec un test de conformité à des requêtes ordinaires est décisive . L’attaquant cherche activement un angle mort. Il peut reformuler une demande, répartir des instructions sur plusieurs messages ou exploiter le contexte pour provoquer une réponse normalement interdite.
Aucun de ces outils ne remplace les autres. HELM offre une vue transversale ; AILuminate apporte une taxonomie et une méthode de notation structurées ; HarmBench aide à étudier la robustesse face à des comportements adversariaux. Le bon choix dépend de la question posée. Veut-on comparer des systèmes généralistes, auditer un filtre de sécurité ou vérifier la résistance d’un assistant métier à des attaques spécifiques ?
Le jailbreak mesure une résistance, pas seulement un réflexe de refus
Un jailbreak cherche à faire sortir un LLM de ses règles de comportement. Certains essais utilisent des jeux de rôle, des consignes contradictoires, des encodages ou des scénarios de persuasion. Les benchmarks spécialisés calculent souvent un taux de réussite des attaques, ou attack success rate. Plus ce taux est élevé, plus le système a été contourné dans le périmètre du test. Mais la mesure dépend de la définition de réussite. Une réponse vaguement problématique n’équivaut pas à une instruction exploitable.
La qualité de l’évaluateur est aussi importante que celle des prompts. Un juge automatique peut confondre une citation critique avec une approbation, ou considérer une réponse prudente comme un refus complet. À l’inverse, une longue réponse peut contenir une phrase réellement dangereuse dissimulée au milieu d’avertissements. La méthode de MLCommons sépare notamment les dimensions de légitimation et de facilitation du comportement, puis applique une grille propre à chaque risque. Ce choix rappelle qu’un simple comptage de mots-clés ne suffit pas.
Les résultats doivent également être ventilés par type d’attaque. Une moyenne unique peut cacher une vulnérabilité systématique aux demandes indirectes, même si les requêtes frontales sont presque toujours bloquées. Les équipes de red teaming doivent conserver les exemples d’échec, documenter leur reproductibilité et vérifier qu’une correction ne provoque pas une régression ailleurs.
Les injections de prompts exposent les assistants connectés
Une injection de prompt survient lorsqu’une instruction hostile est placée dans un contenu que l’assistant est censé traiter comme une donnée. Cela peut être une page Web, un courriel, un document PDF, un résultat de recherche ou un commentaire dans un dépôt de code. Si le modèle traite cette instruction comme un ordre prioritaire, l’attaquant peut tenter de détourner la réponse, déclencher un appel d’outil ou faire divulguer une information. Le risque augmente lorsque l’agent dispose de permissions importantes et enchaîne plusieurs actions sans validation humaine.
Les tests doivent reproduire la chaîne réelle. Pour un assistant RH, il peut s’agir d’un CV contenant une consigne cachée. Cela peut être une facture qui demande de changer un compte bancaire pour un agent financier. Par ailleurs, un outil de veille peut être confronté à une page qui tente de récupérer des informations du contexte. Ces scénarios peuvent être testés sans exposer de données sensibles, avec des identifiants fictifs et un environnement isolé. Le critère pertinent n’est pas seulement la réponse finale. Il faut observer les appels d’API, les permissions utilisées et les données réellement transmises. Une défense crédible combine séparation des instructions et des données, permissions minimales, validation des actions sensibles et contrôles des sorties.
Les taux de refus peuvent récompenser un assistant inutile
Le piège classique consiste à optimiser la sécurité en refusant tout. Un modèle qui ne répond à aucune demande dangereuse peut paraître irréprochable sur certains indicateurs. Pourtant, il devient inutilisable s’il refuse aussi une question médicale générale, une explication historique ou une analyse de risque légitime. Cette tension entre helpfulness et harmlessness doit être évaluée explicitement. Les tests de sur-refus, ou over-refusal, vérifient que les garde-fous n’empêchent pas des demandes autorisées.
Pour une entreprise, l’équilibre dépend du métier. Un assistant destiné à des mineurs n’a pas le même profil de risque qu’un outil interne de recherche juridique. Les politiques de contenu doivent être écrites avant les essais et les réponses jugées à l’aune de ces règles. Sinon, les évaluateurs mélangent préférences personnelles, exigences légales et objectifs du produit. Un benchmark générique reste une base commune, mais il ne remplace ni une analyse de risques ni une politique d’usage.
Comment construire une campagne d’évaluation crédible ?
La première étape consiste à définir le système exact avec un modèle et version, des instructions système et une température. A cela s’ajoutent un garde-fous, des documents consultables, des outils autorisés et des profils utilisateurs. Il faut ensuite cartographier les risques prioritaires. Une application de santé privilégiera la prudence des conseils et la confidentialité. Un agent de développement testera davantage les manipulations de dépôts, les secrets et les commandes exécutables. Les catégories peu pertinentes ne doivent pas disparaître, mais leur poids dans la décision peut différer.
La deuxième étape vise à constituer plusieurs ensembles de tests. Les benchmarks publics donnent un point de comparaison, les scénarios internes couvrent les usages réels et un jeu de questions conservé à part sert à mesurer la généralisation après correction. Il est utile d’ajouter des cas en français, des conversations à plusieurs tours et des documents malveillants. Les exemples trop proches de l’entraînement risquent de produire un score artificiellement flatteur. Une partie des tests doit donc rester inconnue de l’équipe qui ajuste les prompts et les filtres.
La troisième étape mesure séparément les violations, les attaques réussies, les refus injustifiés, la précision des réponses et les incidents liés aux outils. Chaque résultat doit être accompagné de son dénominateur, de la version du protocole et d’un intervalle d’incertitude lorsque c’est possible. Enfin, les cas critiques sont revus par des humains formés à la grille d’évaluation. Le rapport final doit décrire les limites, pas seulement afficher un score agrégé.
- Partager l'article :
