Vous livrez un chatbot pour votre équipe allemande. L'interface utilisateur est allemande. La documentation source est en partie allemande, en partie anglaise. Les outils derrière l'assistant attendent des valeurs d'enum en anglais, des descriptions de fonctions en anglais, des noms de produits en anglais, tout en anglais.
Puis quelqu'un pose une question tout à fait normale en allemand, le modèle choisit le bon outil, passe un argument en allemand au lieu de l'anglais, et tout s'écroule tranquillement.
J'ai vu des versions de ce type suffisamment souvent pour ne plus penser qu'il s'agit d'un problème de traduction. **C'est un problème d'exécution.
Mon défaut actuel est simple : laisser les utilisateurs parler la langue qu'ils veulent, mais laisser le LLM faire son travail de recherche, de raisonnement et d'outil en anglais lorsque la fiabilité est réellement importante. Je localise ensuite la réponse en dehors de cette boucle.
Cela semble légèrement hérétique à première vue. C'est aussi, à mon avis, la chose la plus pratique que vous puissiez faire à l'heure actuelle.
La recherche commence à le dire haut et fort
Les chiffres ne sont plus subtils.
Dans le [benchmark MASSIVE-Agents] (https://aclanthology.org/2025.findings-emnlp.1099/), les chercheurs ont évalué l'appel de fonctions multilingues dans 52 langues, 47 020 échantillons et 21 modèles. Le meilleur score moyen pour l'ensemble des langues n'était que de 34,05 %. L'anglais a atteint 57,37 %. L'amharique est tombé à 6,81 %.
Il ne s'agit pas d'une petite baisse de qualité. Il s'agit d'une chute de fiabilité.
Ensuite, il y a [Lost in Execution] (https://arxiv.org/abs/2601.05366), qui se rapproche encore plus du problème des systèmes réels. L'article montre que de nombreux échecs d'appels d'outils multilingues se produisent après que le modèle a déjà compris l'intention et sélectionné l'outil correct. Le problème dominant est l'inadéquation linguistique de la valeur des paramètres. En clair, le modèle savait ce qu'il fallait faire, mais il a exprimé les bits exécutables dans la langue de l'utilisateur au lieu de la langue de l'interface, de sorte que l'appel a quand même échoué.
Et cela ne se limite pas à l'appel d'outils. Dans [Do Multilingual Language Models Think Better in English ?] (https://aclanthology.org/2024.naacl-short.46/), Etxaniz et ses collègues ont constaté que l'autotraduction en anglais l'emportait systématiquement sur l'inférence directe en langue autre que l'anglais dans le cadre de cinq tâches. Leur formulation est d'une franchise rafraîchissante : les modèles sont "incapables d'exploiter pleinement leur potentiel multilingue lorsqu'ils sont sollicités dans des langues autres que l'anglais".
Alors oui, les modèles multilingues sont impressionnants. Mais si votre barre n'est pas "sonne plutôt bien" mais plutôt "doit se comporter correctement en production", l'anglais reste remarquablement souvent la langue d'exploitation la plus sûre.
Pourquoi les RAG se cassent au même endroit
Les gens entendent généralement cet argument et pensent d'abord aux agents. Appel de fonction, sortie structurée, exécution d'API, ce genre de choses.
RAG a la même faiblesse, juste une couche plus tôt.
Si votre couche de recherche doit faire correspondre la formulation locale d'un utilisateur à un contenu rédigé dans des langues différentes, avec une terminologie incohérente, des noms de produits traduits et des étiquettes de taxonomie à moitié localisées, vous augmentez les risques de dérive du système avant même que la génération ne commence. Honnêtement, c'est de là que viennent beaucoup de plaintes du type "le modèle n'est pas fiable". Le modèle peut être bon. L'interface de contenu ne l'est pas.
Je préférerais normaliser tôt.
Traduire la question en anglais. Récupérer les données à partir d'un corpus canonique anglais. Laisser le modèle raisonner sur une couche terminologique stable. Générer une ébauche de réponse en anglais si nécessaire. Traduire ou localiser la réponse finale pour l'utilisateur.
Vous disposez ainsi d'un endroit où la dénomination reste stable :
- un titre de document canonique
- un vocabulaire de produit canonique
- un schéma d'outil canonique
- un ensemble canonique d'étiquettes de recherche
Il est toujours possible de prendre en charge toutes les langues des utilisateurs à l'extérieur. Il suffit d'arrêter de demander au chemin d'exécution principal d'être parfaitement multilingue à chaque étape.
Ce n'est pas de l'anti-localisation
Au contraire.
Une mauvaise architecture d'IA multilingue nuit généralement d'abord aux utilisateurs locaux. Ils bénéficient d'une belle interface localisée, puis le système caché centré sur l'anglais se comporte de manière incohérente et leur en fait payer le prix.
Une localisation correcte signifie qu'il faut être honnête sur les points où la langue doit fléchir et ceux où elle ne doit pas le faire.
Pour moi, la répartition est la suivante :
- Localiser l'interface utilisateur, les messages-guides, le texte d'aide, l'accueil et les réponses finales.
- Localiser le contenu source que les gens lisent directement lorsque ce contenu doit exister sur le marché.
- Conserver les définitions des outils internes, les identifiants canoniques, les étiquettes de recherche et les pivots de raisonnement en anglais s'il s'agit de la couche la plus stable.
- Ajoutez un post-traitement explicite ou une révision humaine lorsqu'un résultat localisé a un poids juridique, réglementaire ou contractuel.
Ce dernier point est plus important que les équipes ne veulent l'admettre. Si le modèle s'adresse à un être humain, la localisation est une décision liée à l'expérience utilisateur. Si le modèle s'adresse à un autre système, la langue est un contrat d'interface.
Ce n'est pas la même chose.
L'architecture à laquelle je fais le plus confiance en ce moment
C'est la version sur laquelle je miserais aujourd'hui pour les produits d'IA multilingues :
- L'utilisateur demande dans sa langue.
- Le système traduit ou normalise la demande en anglais.
- L'extraction, le raisonnement, le classement et les appels d'outils se font par rapport aux données canoniques anglaises.
- La réponse finale est localisée dans la langue de l'utilisateur.
- Les résultats à haut risque font l'objet d'une étape de validation supplémentaire avant de quitter le système.
Il ne s'agit pas d'une pureté philosophique. Elle est saine d'un point de vue opérationnel.
Ce qui est bien, c'est que des recherches récentes vont dans le même sens. [Lost in Execution] (https://arxiv.org/abs/2601.05366) a constaté que la pré-traduction des requêtes des utilisateurs permettait généralement de réduire les erreurs de concordance linguistique mieux que les corrections post-hoc, même si elle ne permettait pas encore de récupérer totalement les performances au niveau anglais. Cela correspond à ce que de nombreux constructeurs soupçonnent déjà dans la pratique. Si vous attendez la fin du projet pour corriger les incohérences multilingues, vous arrivez généralement trop tard.
Et oui, il y a des exceptions. Si vous construisez pour des langues à faibles ressources, des langues spécifiques à un domaine ou des formulations culturellement dépendantes, tout traduire en anglais peut introduire une dérive. L'article susmentionné met explicitement en garde à ce sujet. N'en faites donc pas un dogme.
Mais en tant que règle par défaut pour les copilotes d'entreprise, les assistants internes, les RAG multilingues et les agents utilisant des outils, je pense que la règle tient étonnamment bien la route.
Ce que cela signifie pour Rasepi
C'est exactement la raison pour laquelle je me soucie tant de la structure canonique du contenu.
Si votre base de connaissances dispose d'une couche source propre, d'une terminologie stable et d'une localisation contrôlée, il est plus facile de faire confiance à l'IA. Si chaque version linguistique dérive indépendamment à l'intérieur du chemin d'exécution, vous demandez au modèle d'improviser là où votre système devrait être précis.
Toute l'approche de Rasepi est construite autour de la séparation nette de ces préoccupations. Conserver un noyau canonique. Localiser délibérément. Repérer les variantes existantes. Ne pas prétendre que chaque couche de la pile doit être également multilingue simplement parce que l'interface utilisateur l'est.
J'avais l'habitude de penser que la meilleure expérience multilingue en matière d'IA signifiait "tout faire dans la langue de l'utilisateur". Ce n'est plus le cas aujourd'hui. Pas pour les systèmes qui doivent retrouver le bon paragraphe, choisir le bon outil et renvoyer quelque chose de fiable.
La règle pratique est simple : les utilisateurs doivent rester locaux, mais le chemin d'exécution du LLM doit rester stable. À l'heure actuelle, cela signifie généralement l'anglais au milieu et la localisation sur les bords**.
Cela changera avec le temps. J'espère que cela changera rapidement. Mais si vous expédiez aujourd'hui et que la fiabilité importe plus que l'esthétique, je laisserais le modèle penser en anglais et votre produit parler la langue de l'utilisateur.