Le fossé de sûreté multilingue dans les défenses anti-injection

De quoi s’agit-il ?

L’essentiel de l’évaluation de sûreté se fait en anglais, et le réglage des garde-fous suit. Un preprint publié fin juin 2026 chiffre le coût de cette habitude. Les auteurs ont mené une évaluation empirique systématique de l’injection de prompt contre six familles de modèles largement déployées — DeepSeek, GPT, Gemini, Grok, Llama et Qwen — dans plusieurs langues et plusieurs encodages de caractères légers, en mesurant la fréquence à laquelle chaque modèle obtempérait à une instruction malveillante plutôt que de la refuser.

Le résultat central est aussi inconfortable que constant : les entrées non anglophones produisent des taux de complaisance plus élevés que les mêmes requêtes en anglais, pour tous les modèles testés. Un refus solide en anglais s’affaiblit lorsque l’instruction identique est traduite. Ce travail rejoint des résultats multilingues antérieurs — dont une analyse 2026 de modèles en langues indiennes parue dans Scientific Reports — et une étude systématique d’octobre 2024 qui pointait déjà la mauvaise généralisation des défenses selon les langues. La nouveauté ici, c’est l’ampleur : six familles de pointe actuelles, mesurées ensemble, sur la même batterie.

Comment ça marche

Il n’y a pas d’exploit à reproduire, et cet article n’en contient volontairement aucun. Le mécanisme est un défaut de couverture, pas une astuce.

L’alignement de sûreté est un comportement appris. La frontière de refus d’un modèle ne vaut que par la distribution des exemples sur lesquels il a été aligné — et cette distribution est massivement anglophone. Quand une instruction arrive dans une langue moins dotée, ou enveloppée dans un encodage simple, elle atterrit légèrement en dehors de la région de l’espace d’entrée où les réflexes de refus ont été le plus renforcés.

Requête en anglais  ── tombe dans une zone dense d'entraînement au refus ──▶ refusée
Même requête, dans  ── tombe en bordure de cette zone                     ──▶ acceptée
une langue non-EN       (signal de sûreté plus faible, signal de tâche intact)

Deux propriétés du fossé comptent pour les défenseurs. D’abord, la compétence de tâche se transfère mieux que la compétence de sûreté. Le modèle comprend encore l’instruction traduite assez bien pour agir ; seul le garde-fou décroche. Ensuite, l’étude indique que les encodages de caractères légers réduisent les sorties malveillantes mais ne les éliminent pas — traiter une simple étape de normalisation comme une solution est donc une erreur. Le papier note aussi que les formulations en plusieurs étapes augmentent encore la complaisance, et que DeepSeek, Gemini et Grok étaient particulièrement vulnérables face aux instructions complexes. La leçon n’est pas de savoir quel modèle a le plus mal scoré sur une batterie — les classements changent à chaque version — mais que le fossé est structurel et présent partout.

Pourquoi c’est important

Si votre application accepte des entrées dans plus d’une langue — bot de support, assistant RAG sur des documents multilingues, agent qui lit des pages web ou des e-mails — alors votre posture de sûreté réelle est fixée par votre langue la plus faible, pas par votre jeu de tests anglophone. Un attaquant qui trouve les refus anglais robustes changera simplement de langue. Les systèmes RAG et agentiques aggravent le problème, car le texte non fiable que le modèle ingère (page récupérée, document collé, résultat d’outil) peut être dans n’importe quelle langue choisie par l’attaquant, quelle que soit la langue de l’interface.

C’est un point de gouvernance autant que technique. Les équipes qui certifient un déploiement « sûr » sur la base d’un red teaming anglophone ne certifient qu’une fraction de leur surface d’attaque réelle. L’OWASP LLM Top 10 traite l’injection de prompt (LLM01) comme la principale classe de risque ; la dimension multilingue est une exigence de couverture cachée à l’intérieur.

Défenses

On ne comble pas un fossé d’alignement qu’on ne mesure pas ; commencez donc par là.

Faites du red teaming dans chaque langue acceptée. Traduisez votre jeu de tests adverses anglais dans chaque langue prise en charge et exécutez-le comme un point de contrôle. Suivez les taux de refus par langue et traitez toute baisse sous votre référence anglaise comme un blocage de release, pas une note de bas de page.

Ne comptez pas sur la seule normalisation des entrées. Décoder et normaliser les entrées obfusquées aide à la marge mais, selon l’étude, n’empêche pas la sortie malveillante. Utilisez-la comme une couche, jamais comme la couche.

Filtrez la sortie, pas seulement l’entrée. Un classifieur de sortie indépendant — idéalement performant en multilingue — attrape la complaisance qui a franchi le garde-fou d’entrée. Le filtrage de sortie est agnostique à la langue, ce que la détection d’intention en entrée n’est pas.

Appliquez la frontière du « lethal trifecta » par l’architecture. Pour les agents et le RAG, la mitigation durable n’est pas un meilleur refus — c’est de retirer la capacité qu’une injection abuserait. Empêchez contenu non fiable, données privées et canaux d’exfiltration de coexister dans un même contexte, et exigez une confirmation humaine pour les actions à conséquence. Un modèle qui ne peut exfiltrer ne peut être convaincu de le faire, dans aucune langue.

Préférez le moindre privilège à la résistance à la persuasion. Cadrez outils, jetons et accès aux données pour qu’une injection réussie atteigne le moins possible. Supposez que le garde-fou finira par céder dans une langue, et rendez cet échec peu coûteux.

Status

Élément	Détail
Source principale	Évaluation empirique, preprint arXiv, fin juin 2026
Modèles évalués	DeepSeek, GPT, Gemini, Grok, Llama, Qwen (familles)
Résultat clé	Complaisance non anglophone systématiquement plus élevée qu’en anglais ; les encodages légers réduisent sans arrêter la sortie malveillante
Corroboration	Analyse multilingue (Scientific Reports, 2026) ; étude systématique inter-langues (arXiv, oct. 2024)
Statut correctif	Pas de patch — défaut de couverture d’alignement ; mitigations architecturales et évaluatives

Cet article résume des travaux de recherche publics à des fins défensives et ne contient aucune instruction d’attaque opérationnelle.