Plus récent ne veut pas dire plus sûr : l'alignement de sécurité non monotone entre générations

De quoi s’agit-il ?

Un préprint déposé sur arXiv le 30 mai 2026 (2606.00813) formule une observation dérangeante : la sécurité d’une famille de modèles ne s’améliore pas de façon fiable d’une génération à la suivante. Les auteurs ont appliqué une sonde de red teaming automatisée à quatre générations de la famille ouverte Gemma de Google (environ 7B à 31B de paramètres) et ont constaté que la génération intermédiaire était nettement plus vulnérable aux jailbreaks que le modèle plus ancien qui la précédait comme que le modèle plus récent qui la suivait.

Les chiffres clés, tels que rapportés par le papier : Gemma 3 (12B) affiche un taux de réussite d’attaque (ASR) de 68,7 % ± 5,7 %, nettement supérieur à son prédécesseur Gemma 2 (45,5 % ± 7,2 %) et à son successeur Gemma 4 (33,9 % ± 1,8 %). Autrement dit, la courbe est montée avant de redescendre. Si vous aviez supposé « version plus récente = modèle plus sûr » et migré de Gemma 2 vers Gemma 3, vous seriez passé à un système plus facilement jailbreakable, et non l’inverse. C’est ce que les auteurs appellent l’alignement de sécurité non monotone.

Comment ça marche

L’étude utilise une recherche évolutionnaire dite qualité-diversité, MAP-Elites, comme moteur de red teaming. Au lieu d’optimiser un unique meilleur jailbreak, MAP-Elites maintient une « archive » de prompts variés qui réussissent chacun dans une région différente d’un espace de comportements d’attaque. Le résultat n’est pas un payload unique mais une cartographie de nombreuses attaques distinctes par modèle — c’est précisément ce qui rend la comparaison entre générations pertinente : on mesure une surface d’attaque large, et non une chaîne isolée chanceuse.

Le second résultat concerne le transfert. Les attaques évoluées contre une génération ont été rejouées contre les autres. Elles se transfèrent vers Gemma 3 à hauteur de 44–46 %, mais vers Gemma 4 seulement à 14–18 %. Cet écart est la partie encourageante du résultat : les gains de sécurité de Gemma 4 semblent généraliser au-delà des distributions d’attaques évoluées contre les modèles antérieurs, plutôt que de simplement mémoriser des correctifs pour des prompts connus. À noter aussi : certaines catégories de nuisance — le papier signale la reproduction de contenu sous copyright et certains prompts de cybercriminalité — atteignent près de 100 % de réussite sur toutes les générations, rappelant que l’ASR agrégé masque des catégories où l’alignement n’a quasiment pas bougé.

Aucune chaîne de jailbreak fonctionnelle n’est reproduite ici, et la valeur du papier est diagnostique plutôt qu’offensive : il s’agit d’une méthodologie de mesure, dans la lignée bien établie des travaux sur les attaques adverses transférables contre les modèles alignés (Zou et al., 2023).

Pourquoi c’est important

La plupart des décisions de mise à niveau supposent implicitement une amélioration monotone : la nouvelle version est meilleure sur les benchmarks, donc plus sûre, donc un remplacement sans risque. Ce papier montre que cette hypothèse n’est pas tenable. Une régression peut être introduite par un changement dans les données d’instruction-tuning, un nouveau gabarit de conversation, un saut de capacités qui dépasse l’entraînement de sécurité, ou un déplacement du comportement de refus — autant de facteurs invisibles sur un classement de capacités. Pour quiconque fige une version de modèle en production, « nous sommes passés à la dernière version » n’est pas une preuve de sécurité améliorée ; cela peut être l’inverse.

Ce résultat fragilise aussi l’habitude de n’évaluer que le modèle le plus récent. Si la sécurité est non monotone, votre modèle de menace doit tenir compte de la version précise que vous déployez — y compris des versions plus anciennes encore figées dans des systèmes de longue durée.

Défenses

• Re-testez à chaque montée de version. Traitez une mise à niveau de modèle comme un changement de code : exécutez votre suite d’évaluation jailbreaks et catégories de nuisance contre la version exacte que vous allez livrer, et conditionnez le déploiement aux résultats. N’héritez pas du feu vert sécurité de la version précédente.
• Mesurez une distribution, pas un prompt unique. Le red teaming conscient de la diversité (qualité-diversité / recherche par archive) expose des faiblesses larges qu’une attaque optimisée isolée manque. Conservez une archive de catégories fonctionnelles et rejouez-la contre chaque nouvelle version.
• Surveillez le transfert comme signal précurseur. Si les attaques de la génération précédente se transfèrent encore bien au nouveau modèle, ses gains de sécurité sont probablement superficiels. Un faible transfert est un indice faible de réelle généralisation.
• Suivez l’ASR par catégorie, pas seulement la moyenne. Les chiffres agrégés masquent des catégories (le papier signale le copyright et certains prompts de cybercriminalité) qui restent proches de 100 % d’une génération à l’autre. Défendez-les par des contrôles externes — filtres de sortie, gating des outils et du retrieval — plutôt que de faire confiance au refus au niveau du modèle.
• Figez et documentez la version. Notez exactement quelle build de modèle vous avez évaluée et déployée, afin qu’une mise à jour silencieuse côté fournisseur ne modifie pas discrètement votre posture de risque.

Statut

Élément	Détail
Papier	« Cross-Generational Transfer of Adversarial Attacks Reveals Non-Monotonic Safety Alignment in LLMs »
ID arXiv	2606.00813
Publié	30 mai 2026
Modèles étudiés	Google Gemma, quatre générations (~7B–31B)
Méthode	Red teaming qualité-diversité MAP-Elites
Résultat clé	Gemma 3 (12B) ASR 68,7 % > Gemma 2 45,5 %, > Gemma 4 33,9 %
Transfert inter-générations	44–46 % vers Gemma 3 ; 14–18 % vers Gemma 4
Nature	Étude de mesure défensive — aucun code d’exploitation publié