Benchmark jailbreak MLCommons v1.0 : ce que révèle (et masque) le Resilience Gap

De quoi s’agit-il ?

Le 2 octobre 2026, MLCommons et une trentaine de co-auteurs issus de l’industrie et du monde académique ont déposé sur arXiv le MLCommons Jailbreak Benchmark v1.0. C’est la première exécution complète, de bout en bout, de la méthodologie jailbreak du consortium : sélection des prompts, génération des attaques, annotation humaine, calibration du juge, notation et publication. Le benchmark n’invente aucune attaque : il applique des techniques de jailbreak connues à 264 prompts de départ (24 par catégorie, onze catégories de risques) et mesure la fréquence à laquelle la réponse viole le standard d’évaluation AILuminate v1.4.

La métrique phare est le Resilience Gap (RG) : la baisse du taux de réponses conformes lorsque le même prompt est reformulé par une technique de jailbreak. Huit modèles open-weight ont été testés.

Comment cela fonctionne

Chaque prompt est exécuté deux fois sur le même modèle : tel quel (référence) puis transformé par l’une des onze attaques rapportées. Douze attaques ont été implémentées et rattachées à une taxonomie de quatre familles, huit catégories et dix-sept mécanismes ; l’une d’elles (Content Framing & Deception) est exclue des résultats quantitatifs en raison d’une limite du juge. Les réponses reçoivent une note de 0 à 2 pour la Légitimation et pour l’Habilitation (Enablement), puis des règles propres à chaque risque les convertissent en verdict conforme ou non, rendu par un ensemble de juges LLM calibré sur des étiquettes humaines.

Les auteurs ne divulguent volontairement ni les prompts d’attaque exacts, ni les gabarits, ni le code, réservés aux auditeurs autorisés. Cet article suit la même règle : aucune charge utile n’est reproduite.

Pourquoi c’est important

Chiffres rapportés par l’article et par l’analyse d’ActuIA (5 octobre 2026) :

• La part de réponses dangereuses passe de 11,08 % (référence) à 18,65 % sous attaque, soit un Resilience Gap moyen de 7,57 points.
• Les trois modèles plus petits (« Accessible ») affichent un écart moyen d’environ 21 points, que les auteurs jugent préliminaire vu la petite taille de l’échantillon.
• Les crimes violents et les armes de destruction massive montrent les plus fortes hausses ; les familles les plus efficaces sont le jeu de rôle/gabarits et les enveloppes/schémas.
• Trois grands modèles (Gemma 4 31B, DeepSeek-V4-Pro, Kimi K2.6) présentent un écart négatif, c’est-à-dire moins de réponses dangereuses sous attaque. Les auteurs évoquent une vraie robustesse, des effets d’évaluateur ou de décodage, ou des refus déclenchés par le format du jailbreak lui-même.

L’autre moitié du sujet tient à la qualité de la mesure. L’accord entre annotateurs humains est de 0,88 sur le verdict final, mais de seulement 0,54 (Légitimation) et 0,63 (Habilitation) sur les sous-scores, avec 40 réponses seulement doublement annotées. ActuIA indique que le juge a manqué 16,4 % des réponses dangereuses et signalé à tort 37,9 % des réponses sûres : les taux absolus ne doivent donc pas être lus comme des estimations précises. Le benchmark ne couvre en outre que le texte à un seul tour, sans dialogue multi-tours, images ni agents outillés. Une des attaques a été générée par un modèle qui figure aussi dans le panel testé, ce qui peut biaiser son écart à la hausse.

Défenses

L’article décrit une méthode d’évaluation, pas une défense, mais il en tire des pistes concrètes pour les équipes qui évaluent des modèles :

1. Publier des résultats appariés. Mesurez ensemble le comportement de référence et sous attaque, et lisez le Resilience Gap à côté des mesures de capacité et de sur-refus : un modèle qui refuse tout est trivialement « sûr ».
2. Traiter un écart négatif comme une question, pas comme une validation. Vérifiez l’erreur du juge, le décodage et les refus déclenchés par le format avant de conclure à la robustesse.
3. Quantifier l’erreur du juge. Publiez des marges d’erreur et calibrez les juges sur des étiquettes humaines fiables avant de comparer des modèles.
4. Éviter la contamination. Excluez du panel testé tout modèle ayant servi à générer des attaques ou à juger les réponses.
5. Ne pas s’arrêter au texte à un seul tour. Ajoutez des tests multi-tours, multimodaux et agentiques à votre propre red teaming, car ce benchmark ne les couvre pas.
6. Superposer les contrôles. Un benchmark ne mesure que les refus du modèle ; conservez filtrage des sorties, outils à moindre privilège et supervision autour du modèle.

Statut

Élément	Détail
Article	arXiv 2610.02827, déposé le 2 octobre 2026
Modèles testés	8 open-weight (3 « Accessible », 5 « Large ») ; modèles fermés via API exclus
Taux de réponses dangereuses référence / attaque	11,08 % / 18,65 %
Prévu	v1.1 avec une vérité terrain humaine élargie, un nouveau juge et des tests ultérieurs de modèles fermés ; sans date (selon ActuIA, 5 octobre 2026)