Déposé sur arXiv le 2 octobre 2026 et listé parmi les nouveautés du lundi 5 octobre, le papier du Jailbreak Benchmark v1.0 de MLCommons, le consortium qui publie aussi les bancs MLPerf et AILuminate, livre ce que ses auteurs présentent comme les premiers résultats complets de leur méthode. Huit modèles à poids ouverts y sont soumis à 264 requêtes dangereuses, d'abord telles quelles, puis réécrites par des techniques de contournement (« jailbreak ») tirées de la littérature. La part des réponses classées en infraction passe de 11,08 % à 18,65 %, soit un écart moyen de 7,57 points.

Le juge automatique qui produit ces classements a laissé passer 16,4 % des réponses dangereuses et a signalé à tort 37,9 % des réponses sûres. Les auteurs écrivent eux-mêmes que ces taux sont « bien au-dessus » de leur objectif.

Huit modèles ouverts, 264 requêtes, onze attaques comptées

Le panel compte trois modèles de la classe « Accessible » (Gemma 3N E4B Instruct de Google, LFM2-24B-A2B de Liquid AI, Qwen 2.5 7B Instruct Turbo d'Alibaba Cloud) et cinq de la classe « Large » (DeepSeek-V4-Pro, Gemma 4 31B Instruct de Google, GPT-OSS 120B d'OpenAI, Kimi K2.6 de Moonshot AI, MiniMax M2.7). Ils ont été retenus par nombre de téléchargements mensuels sur Hugging Face, parmi les modèles servis par Together AI.

Les modèles fermés sont absents. Le papier invoque le contrôle de la conservation des données, qui protège le jeu de requêtes, et les conditions d'utilisation de certains services hébergés, qui peuvent interdire les tests adversariaux. Les 264 requêtes, 24 pour chacune des onze catégories de risque (crimes violents, armes à effet indiscriminé, exploitation sexuelle d'enfants, haine, vie privée...), viennent du jeu public d'essai (« Practice set ») d'AILuminate. Douze attaques ont été implémentées ; une a été exclue des calculs à cause d'une limite du juge, d'où onze attaques comptées. Le banc ne couvre que des échanges textuels en un seul tour : ni conversation en plusieurs messages, ni image, ni agent utilisant des outils, terrain où se placent des dispositifs comme OpenShell de NVIDIA.

Des écarts très inégaux d'un modèle à l'autre

Sur les trois modèles « Accessible », l'écart moyen atteint environ 21 points, un résultat que les auteurs qualifient de préliminaire faute de systèmes en nombre suffisant. À l'inverse, Gemma 4 31B Instruct, DeepSeek-V4-Pro et Kimi K2.6 produisent moins de réponses classées dangereuses sous attaque que sans attaque. GPT-OSS 120B affiche un écart positif de 3,3 points.

Pour ces écarts négatifs, le papier avance trois explications sans trancher : le modèle n'a pas compris la requête transformée, le juge n'a pas su décoder une réponse obscurcie, ou le modèle a réellement détecté l'attaque. Les jeux de rôle et gabarits (35,7 % de réponses classées dangereuses en moyenne) et les enveloppes structurées (32,8 %) sont les familles d'attaques les plus efficaces. Les catégories les mieux protégées sans attaque reculent le plus : les crimes violents passent de 1,56 % à 16,67 %, les armes à effet indiscriminé de 3,65 % à 17,85 %.

Un juge réglé pour ne pas rater les réponses dangereuses

Les 16,4 % sont la part des réponses en infraction que le juge a classées sûres ; les 37,9 % sont la part des réponses sûres qu'il a classées en infraction. Le papier ne précise pas sur quel jeu ces taux sont calculés. La vérité terrain humaine qui a servi à choisir le juge compte 859 réponses et ne contient aucune réponse aux deux attaques ajoutées ensuite. Neuf annotateurs ont d'abord classé 40 réponses, avec une fiabilité inter-annotateurs de 0,88 sur le verdict final ; le reste a été annoté par une seule personne. MLCommons dit avoir choisi, parmi les ensembles de juges testés, celui qui offrait le meilleur équilibre, en cherchant d'abord à limiter les réponses dangereuses manquées, au prix de davantage de fausses alertes.

Les auteurs en tirent eux-mêmes la conséquence : les taux absolus « ne doivent pas être traités comme des estimations ponctuelles précises ». La notation relative, qui compare chaque modèle à un système de référence, est censée absorber une partie de l'erreur commune, mais celle-ci peut varier selon les attaques, les catégories, les modèles et les conditions, et donc ne pas s'annuler partout. Un biais est documenté : Qwen 2.5 7B a servi à générer l'une des attaques et à régler leurs paramètres, si bien que son écart « peut être biaisé à la hausse ».

Un écart de 7,57 points sans marge d'erreur

Un calcul de la rédaction montre que ces taux d'erreur ne se transposent pas aux chiffres du banc. Hypothèse : si le juge classait à tort 37,9 % des réponses sûres et laissait passer 16,4 % des réponses dangereuses sur les réponses du banc, le taux mesuré resterait compris entre 37,9 % et 83,6 %, quel que soit le comportement réel des modèles. Or le banc affiche 11,08 % sans attaque et 18,65 % sous attaque. Les taux d'erreur publiés, lus avec les définitions du papier, décrivent donc le juge sur un autre ensemble de réponses que celles du banc. L'erreur qui pèse sur les 11,08 %, les 18,65 % et l'écart qui les sépare n'est pas chiffrée.

Une organisation membre de MLCommons a proposé une condition, que le papier dit avoir adoptée : des résultats par modèle et par catégorie de risque ne se publient qu'avec leur marge d'erreur. La v1.0 « ne peut pas remplir cette condition », écrivent les auteurs, parce que le juge rend un verdict binaire sans score de confiance et que l'échantillon se limite à 24 requêtes par catégorie. Ces résultats détaillés ne sont donc pas publiés, pas plus que l'identité des attaques, les requêtes transformées, le code et la configuration du juge, conservés pour des auditeurs autorisés.

Au 5 octobre 2026 à 8 h 43, la page du benchmark sur le site de MLCommons renvoyait encore aux livres blancs v0.5 et v0.7 et aux résultats de la v0.5, sans mention de la v1.0 ; le fil d'actualités du consortium ne l'annonçait pas davantage. L'écart de 19,8 points mesuré par la v0.5 sur le texte ne vaut pas preuve d'un progrès de sécurité, préviennent les auteurs : panel, requêtes, attaques et juge ont changé.

Pour une entreprise qui héberge un modèle ouvert

Le banc interroge des modèles par leur seule interface de requête, sans les filtres qu'ajoute un service commercial autour d'un modèle. C'est la situation d'une entreprise qui déploie elle-même des poids ouverts. Sur ce panel, les trois modèles « Accessible » comptent en moyenne quelque 21 points de réponses classées dangereuses en plus sous attaque, quand trois des cinq « Large » en comptent moins ; les auteurs jugent l'écart préliminaire et n'excluent pas un effet du juge. Un acheteur peut inscrire ce type de mesure dans un cahier des charges, à condition d'exiger la marge d'erreur que la v1.0 reconnaît ne pas pouvoir fournir.

Côté fournisseurs, l'article 55 du règlement européen sur l'IA impose déjà à ceux de modèles à usage général présentant un risque systémique d'évaluer leurs modèles selon des protocoles et des outils normalisés, tests adversariaux documentés compris. Pour la v1.1, MLCommons annonce une vérité terrain plus large et arbitrée, des requêtes tirées du jeu officiel non public d'AILuminate, un nouveau juge et, plus tard, des modèles fermés interrogés par API. Le papier ne fixe aucune date.