Vos garde-fous LLM sont sourds au français. Les code talkers navajos expliquent pourquoi.

Vos garde-fous LLM affichaient « zéro menace ». L'agent a obéi quand même

Il y a quelques semaines, je testais un agent RAG de traitement de factures fournisseurs avant de le confier à un client. Le protocole était banal : glisser une instruction parasite dans un PDF et vérifier que les garde-fous LLM la bloquent. En anglais, le filtre a fait son travail : alerte levée, document écarté.

J'ai ensuite reformulé la même consigne en français soutenu, presque notarial. Le garde-fou est resté au vert, et l'agent a proposé de « mettre à jour » les coordonnées bancaires du fournisseur. Troisième essai : la consigne en allemand, logée dans une note de bas de page. « 0 menace détectée ».

Rien de spectaculaire. L'environnement était cloisonné, aucun virement n'est parti, une validation humaine attendait au bout de la chaîne. Mais la leçon était nette : le modèle avait compris les trois versions, et le garde une seule.

Je ne suis pas le seul à le constater. La veille sécurité de ces derniers mois revient avec insistance sur ces gardes d'agents qui « ratent le non-anglais ». Elle souligne aussi la rareté de la sanitisation structurelle dans les dépôts de code d'agents.

Ma thèse tient en une phrase. La faille ne vient pas d'une langue dangereuse, mais d'une asymétrie de compétence entre le modèle et celui qui le surveille. Tout ce que le modèle comprend et que le garde ne comprend pas devient un canal clandestin.

Le code que personne ne savait écouter

En 1942, Philip Johnston, fils de missionnaire élevé en pays navajo, soumet une idée aux Marines. Pourquoi chiffrer laborieusement les ordres, quand il suffit de les dire dans une langue que l'ennemi ne parle pas ? Le navajo n'était pratiqué par presque personne hors de la réserve.

Les Marines testent, puis recrutent. Environ quatre cents Navajos serviront comme code talkers dans le Pacifique, de Guadalcanal à Iwo Jima. Selon les Archives nationales américaines, le code ne fut jamais cassé.

L'idée n'était d'ailleurs pas neuve. Dès octobre 1918, en Argonne, des soldats choctaws transmettaient déjà des messages dans leur langue. Les Allemands, qui écoutaient les lignes, n'en tiraient rien.

Deux points méritent qu'on s'y arrête, car ils structurent tout le reste de cet essai.

Le premier : la sécurité ne reposait pas sur la complexité du message, mais sur l'absence de locuteurs chez l'adversaire. Aucun algorithme sophistiqué, aucune clé secrète. Le Japon ne disposait simplement de personne capable d'écouter.

Le second : ce n'était pas seulement une langue, c'était une langue doublée d'un code. Un char devenait une « tortue », un sous-marin un « poisson de fer ». La fiche pédagogique des Archives nationales cite le « colibri » pour l'avion de chasse et le chicken hawk, un rapace, pour le bombardier en piqué.

Un épisode montre la force de cette double couche. Joe Kieyoomia, soldat navajo fait prisonnier aux Philippines, fut sommé par ses geôliers de traduire des messages interceptés. Il reconnaissait les mots de sa langue, mais pas ce qu'ils désignaient.

Quand l'attaquant devient le code talker

Transposons la scène dans un agent IA. Le destinataire du message, c'est le modèle de langage. La sentinelle qui intercepte, c'est le garde-fou : classifieur d'injection, filtre de prompt, modèle de modération.

Dans le Pacifique, le destinataire comprenait et la sentinelle ennemie restait sourde. Dans un agent, l'attaquant reproduit cette configuration à son profit. Il écrit dans une langue que le modèle comprend parfaitement et que le garde comprend mal.

La morale historique se retourne donc. Un canal est sûr quand l'écoutant adverse ne comprend pas ; il devient dangereux quand c'est votre propre gardien qui ne comprend pas. Et la seconde leçon navajo s'applique aussi : une langue mal couverte, doublée d'un encodage ou d'une périphrase, épaissit encore le brouillard.

Anatomie d'une surdité

D'où vient l'asymétrie ? D'abord des données. Les corpus d'attaques qui servent à entraîner les classifieurs sont majoritairement anglophones, parce que la recherche en sécurité publie d'abord en anglais.

L'éditeur le dit lui-même. La documentation de Microsoft sur Prompt Shields indique que ses détecteurs d'attaques ont des capacités multilingues, mais sont principalement entraînés et évalués sur de l'anglais. Microsoft recommande de tester séparément prompts et documents, dans chaque langue de l'application.

Cette honnêteté est précieuse. Elle rappelle qu'un outil « multilingue » n'est pas un outil également performant dans toutes les langues. Capacité de traitement et compétence de détection sont deux choses distinctes.

La preuve expérimentale existe aussi. En 2023, Zheng-Xin Yong, Cristina Menghini et Stephen Bach (Brown University) publient « Low-Resource Languages Jailbreak GPT-4 ». En traduisant des requêtes nocives en zoulou, gaélique écossais, hmong ou guarani, ils obtiennent des réponses exploitables dans 79 % des cas, langues combinées, sur le benchmark AdvBench.

Ce chiffre exige de la rigueur. Il vaut pour ce protocole, ce modèle et ces langues peu dotées, pas pour toutes les situations. Les auteurs notent d'ailleurs des taux bien plus faibles pour les langues à ressources élevées — dont le français.

L'étude de Deng et ses coauteurs ajoute une distinction utile. Elle sépare le risque intentionnel, celui de l'attaquant, du risque involontaire, celui d'un utilisateur légitime qui contourne la sûreté sans le vouloir. Dans leur protocole, les langues peu dotées présentaient environ trois fois plus de contenus dangereux que les langues bien dotées.

Reste un facteur structurel, souvent oublié : la taille. Un garde doit être rapide et bon marché, puisqu'il examine chaque échange. Il est donc presque toujours plus petit que le modèle qu'il surveille, et un modèle plus petit maîtrise moins de langues.

Les model cards le reflètent. Llama Guard 3, par exemple, annonce une couverture de huit langues. Les grands modèles généralistes, eux, comprennent souvent bien au-delà de leur liste officielle — et c'est précisément dans cet écart que loge le canal clandestin.

Une base RAG française, terrain idéal

On pourrait croire le problème exotique, réservé au zoulou et au hmong. Pour une entreprise française, c'est l'inverse. Le français est bien doté, certes, mais il n'est pas l'anglais, et surtout il n'arrive jamais seul.

Regardez un corpus RAG réel. Des contrats en français, des e-mails où l'on passe à l'anglais au milieu d'une phrase, des factures allemandes, des fiches techniques espagnoles. Votre base documentaire est exactement la zone où vos garde-fous sont le plus faibles.

Or c'est par là que passent les attaques qui comptent. L'injection indirecte ne vient pas de l'utilisateur, mais d'un document récupéré : un PDF fournisseur, une page web, une pièce jointe. Un seul fichier peut contaminer tout le contexte, comme le montre l'analyse de la revalidation continue du contexte d'un agent IA.

Beaucoup de déploiements ne filtrent que la requête de l'utilisateur. Les documents entrent dans le contexte sans inspection, ou avec un contrôle calibré sur l'anglais. Le garde surveille alors la porte d'entrée pendant que les fenêtres restent ouvertes.

Quatre gestes pour un garde qui entend vraiment

1. Mesurer le rappel langue par langue

Un score global de détection ne dit rien d'utile. Il faut mesurer le rappel — la part d'attaques réellement détectées — dans chaque langue de votre corpus. Construisez un jeu de test en français, en mélange franco-anglais et dans les langues de vos partenaires.

Ajoutez-y des contenus bénins, pour mesurer aussi les faux positifs. Un garde qui bloque toute facture allemande n'est pas sûr, il est inutilisable. Et répétez l'exercice : il faut tester ses garde-fous LLM en continu plutôt qu'une fois par an, car modèles et attaques évoluent.

2. Exiger la parité linguistique, ou normaliser en amont

La règle que j'applique est simple. Un garde ne se déploie pas sur une langue qu'il comprend moins bien que l'agent qu'il surveille. Si la parité est impossible, on restreint les langues admises ou l'on normalise les entrées.

Normaliser, c'est détecter la langue de chaque segment et décoder les encodages, comme le base64 ou le leetspeak. Le garde examine alors le texte tel que le modèle le comprendra, et non sa forme déguisée.

On me propose souvent la traduction systématique vers l'anglais. C'est une fausse bonne idée. Elle perd des nuances, ajoute coût et latence, et surtout introduit un nouveau modèle, lui-même vulnérable à l'injection.

3. Rendre la défense indépendante de la langue

C'est le geste décisif. Si un filtre textuel est la seule ligne de défense, vous jouerez toujours au chat et à la souris avec les langues. Mieux vaut une architecture où le contenu non fiable ne peut jamais déclencher une action, quelle que soit la langue employée.

En 2023, Simon Willison a décrit le dual LLM pattern. Un modèle privilégié détient les outils ; un modèle en quarantaine lit les contenus non fiables, sans aucun pouvoir d'agir. Ses notes sur CaMeL reconnaissent que cette version simple avait des faiblesses.

Google DeepMind a prolongé l'idée en 2025 avec CaMeL, « Defeating Prompt Injections by Design ». La requête fiable devient un plan structuré ; les données récupérées restent des données, étiquetées par leur provenance. Des politiques de flux d'information contrôlent ensuite chaque appel d'outil.

Dans ce schéma, une injection en allemand dans une note de bas de page peut être lue, mais pas obéie. Ce n'est pas une solution magique : définir les politiques demande du travail, et des limites résiduelles demeurent. Mais la défense cesse de dépendre du vocabulaire de l'attaquant.

Sans aller jusqu'à CaMeL, la séparation des privilèges fait déjà beaucoup. Mon agent de factures ne pouvait pas modifier un IBAN sans validation humaine, et c'est ce qui a tout sauvé. Dans les missions que je mène chez dac.consulting, c'est la première permission que je retire.

4. Journaliser les anomalies linguistiques

Certaines bizarreries méritent une alerte, même sans menace détectée :

• un changement de langue au milieu d'un document ;
• une langue inattendue pour une source donnée, comme de l'allemand chez un fournisseur lyonnais ;
• un bloc de texte encodé dans un document ordinaire ;
• du texte invisible ou minuscule dans un PDF.

Ces signaux ne prouvent rien. Ils indiquent où regarder, ce qui vaut mieux qu'un tableau de bord uniformément vert.

Le schibboleth, ou le garde qui sait ce qu'il écoute

Le Livre des Juges, au chapitre 12, raconte le plus ancien filtre linguistique connu. Aux gués du Jourdain, les hommes de Galaad demandent à chaque fugitif de prononcer « schibboleth ». Les Éphraïmites, qui disent « sibboleth », sont démasqués.

Ce filtre fonctionnait pour une seule raison : le garde maîtrisait parfaitement la différence qu'il testait. Les Japonais, face au navajo, n'avaient pas ce privilège. Vos guardrails, face au français mêlé d'anglais et d'allemand, ne l'ont pas toujours non plus.

La sécurité par l'incompréhension a contribué à gagner une guerre, à condition d'être du bon côté de l'incompréhension. D'où ma règle : vos garde-fous LLM doivent parler toutes les langues que comprend votre modèle, sinon ils gardent une porte et en laissent dix ouvertes.