Un article intitulé The Fragility of Jailbreak Robustness Across Operational States, accepté à EMNLP 2026 Findings, avance une thèse étroite et dérangeante : le score de robustesse d’un modèle est une propriété de la configuration dans laquelle il a été mesuré, et non du modèle lui-même. En gardant l’attaque inchangée et en ne modifiant qu’un simple system prompt — sans lien avec la sécurité — le taux de réussite de l’attaque est passé, dans un cas, de 2 % à 58 %, soit un écart de 56 points. Le résultat couvre sept modèles alignés et trois attaques représentatives.

Le mécanisme proposé

Les auteurs relient cet effet à la position des représentations cachées le long de ce qu’ils appellent un refusal axis. Une projection sur cet axe permet de prédire si un jailbreak donné réussit — ce qui présente un system prompt opérationnel comme quelque chose qui fait discrètement évoluer le modèle dans une direction liée à la sécurité, sans aucune intention adversariale de la part de la personne qui l’a rédigé.

Ce que l’article ne dit pas

Il ne prétend pas que les modèles sont devenus moins sûrs, et un titre du type « les modèles sont faciles à jailbreaker » inverse l’argument. Le constat porte sur la mesure : présenter la robustesse sous la forme d’un simple chiffre d’ASR dans une configuration standard crée un faux sentiment de confiance, car ce nombre ne résiste pas au contact d’un prompt opérationnel. C’est une critique d’une méthodologie utilisée dans les safety cards des fournisseurs et dans les benchmarks publics, pas une nouvelle attaque.

Deux précisions à bien distinguer

L’acceptation concerne Findings, et non le track principal d’EMNLP — une distinction que les résumés de presse omettent souvent. Et la date arXiv renvoie au dépôt d’une version précise : il s’agit de v1, soumise le 31 août, sans révision ultérieure ; ce n’est donc pas un ancien travail ressorti sous une nouvelle date de mise en ligne.

Pourquoi les praticiens devraient s’en soucier

En production, le system prompt est rédigé par l’intégrateur, et non par le laboratoire. Si la robustesse mesurée avec le prompt par défaut du labo ne se transfère pas, alors chaque chiffre de sécurité présenté à un acheteur décrit une configuration qui n’existera pas dans son produit. L’implication pratique est que le red-teaming doit être mené sur le prompt réel de production, puis répété à chaque modification de ce prompt — une opération aujourd’hui traitée comme une simple retouche éditoriale.