Discuter en français avec son LLM, quel impact ?

En bref

1. Tout en français coûte 30 à 48% plus cher en tokens. Un coût qui se multiplie dans les pipelines agentiques avec de nombreux appels enchaînés.
2. La stratégie hybride est le meilleur compromis : infrastructure (system prompts, skills, configs) en anglais, conversation en français. Le surcoût tombe à ~10–15% tout en conservant la clarté de pensée native.
3. Le français réduit les hallucinations liées à la traduction interne pour les tâches à forte charge sémantique : jusqu'à 44% des erreurs sur certains benchmarks proviennent de ce phénomène « Lost in Translation ».
4. Penser en français plutôt que traduire préserve la richesse sémantique des concepts métier, juridiques et organisationnels spécifiques au contexte francophone. Une précision qu'aucune traduction ne peut totalement restituer.

Introduction

Travailler avec un LLM dans son IDE ou en ligne de commande soulève une question que beaucoup ignorent encore : la langue dans laquelle on rédige ses instructions, ses fichiers de configuration et ses conversations n'est pas neutre. Elle a un impact direct sur les coûts, la qualité des raisonnements et même la précision des réponses obtenues. Cet article explore quatre dimensions essentielles pour tout développeur francophone qui utilise des outils comme Claude Code, Cline, Aider, ou n'importe quel CLI agentique.

1. Tout en français : une « taxe linguistique » silencieuse

Pourquoi le français coûte plus de tokens

Les tokenizers des grands modèles de langage ont été entraînés sur des corpus de données majoritairement anglophones. L'anglais bénéficie d'une tokenisation favorable : les mots courants existent comme tokens uniques, complets. Le français, lui, est fragmenté. Un mot comme compréhension ou réglementation sera découpé en plusieurs sous-tokens là où son équivalent anglais n'en nécessite qu'un ou deux.

Ce déséquilibre se traduit concrètement par une surconsommation systématique :

• +15 à 30% de tokens supplémentaires pour un texte français équivalent à un texte anglais (estimation basse, mesurée sur des corpus techniques)
• +48% de coût moyen observé sur Claude, ChatGPT et Gemini dans des benchmarks récents de 2026
• Un email de 300 mots en anglais génère environ 400 tokens ; le même contenu en français en génère 500 à 550

L'effet multiplicateur dans un pipeline agentique

Dans un IDE agentique, chaque appel au modèle embarque bien plus que la simple conversation : le system prompt, les fichiers de skill, les fichiers d'agent, l'historique de contexte, les retours d'outils. Si tout ce contenu est en français, le surcoût s'applique à chaque composant, à chaque appel, à chaque étape du pipeline.

Sur un workflow avec dix appels d'outils enchaînés, une surfacturation de 30 à 48% se répercute mécaniquement à chaque step. Sur une journée de travail intensive avec un outil agentique, cela peut représenter une différence de coût énorme.

Les tokenizers les plus récents réduisent partiellement l'écart grâce à des vocabulaires plus larges et multilingues, mais ne l'éliminent pas. La parité réelle entre anglais et français en termes de tokenisation n'existe pas encore dans les modèles grand public.

2. La stratégie hybride : conversation en français, infrastructure en anglais

Le bon compromis coût / expérience

L'approche la plus raisonnable pour un développeur francophone n'est pas de tout traduire en anglais. C'est de distinguer les composants selon leur nature et leur fréquence d'utilisation. Les fichiers de configuration, les prompts système, les skills et les agents sont chargés dans le contexte à chaque appel. La conversation utilisateur, elle, représente généralement une part très minoritaire du contexte total.

Garder l'infrastructure en anglais et la conversation en français réduit le surcoût de ~48% à environ 10–15% par rapport au tout-anglais. C'est le meilleur rapport entre économie de tokens et confort cognitif.

Recommandation par composant

• System prompt / instructions d'agent → Anglais : Tokenisation optimale, exécuté à chaque appel

• Fichiers de skill → Anglais : Chargés dans le contexte à chaque tour

• Fichiers de configuration (AGENTS.md…) → Anglais : Impact fort sur la fenêtre de contexte

• Conversation utilisateur (chat instruct) → Français : Clarté de pensée, pas de traduction mentale

• Documentation technique dans le dépôt → Anglais : Compatibilité écosystème, tokens économisés

• Commentaires de code → Au choix de l'équipe : Impact marginal sur les tokens

• Spécifications métier complexes → Français : Précision sémantique native, évite les erreurs de traduction

3. Hallucinations et raisonnement : le français comme bouclier contre les erreurs de traduction

Le phénomène « Lost in Translation »

Selon une recherche publiée sur arXiv "The Reasoning Lingua Franca: A Double-Edged Sword for Multilingual AI" le résultat est jugé contre-intuitif : le raisonnement en anglais produit en moyenne de meilleures performances, avec des traces de pensée plus riches (sub-goal setting, vérification). Mais ce même raisonnement en anglais souffre d'un défaut structurel baptisé LiT (Lost in Translation) : lorsque le modèle reçoit une instruction en français et traduit intérieurement vers l'anglais pour raisonner, des erreurs sémantiques sont introduites à ce stade, qui n'auraient pas eu lieu en raisonnant directement en français.

Pour le français (considéré comme une langue « haute ressource »), le taux LiT atteint 0,30 à 0,44, ce qui signifie que jusqu'à 44% des erreurs produites en mode « raisonnement anglais » sur des benchmarks comme GPQA Diamond auraient pu être évitées en raisonnant directement en français.

L'apport de la recherche française : l'étude Pensez

L'étude Pensez: Less Data, Better Reasoning démontre qu'un modèle 7B fine-tuné sur seulement 2 000 exemples bilingues 50/50 anglais-français de haute qualité gagne fortement en raisonnement mathématique avancé, sans aucune dégradation des performances en anglais. La conclusion est claire : ce n'est pas le français qui est intrinsèquement mauvais pour le raisonnement, c'est la sous-représentation du français dans les données d'entraînement qui crée l'écart artificiel.

Implication pratique pour le développeur

Pour des tâches à forte charge de réflexion, comme la spécification d'architecture, la description de logique métier complexe, ou la rédaction de règles métier ambiguës, formuler la demande directement en français peut diminuer la perte sémantique introduite par la traduction mentale humaine ou d'un outil de traduction: dans certain cas, elle peut être plus importante que celle du mécanisme interne du LLM qui l'effectue silencieusement. Si en revanche le développeur est sur et certain de son vocabulaire et de sa traduction en anglais, alors écrire en anglais est ici pertinant. C'est le débat du point 4 si dessous.

4. La richesse du français : penser directement plutôt que traduire

La « taxe cognitive » de la traduction mentale

Quand un développeur francophone pense une idée en français, la traduit mentalement en anglais, l'écrit, puis reçoit une réponse en anglais qu'il retraduit en français, chaque passage d'une langue à l'autre est une opportunité de perte sémantique. Ce n'est pas une question de maîtrise de l'anglais : même un locuteur bilingue perd des nuances dans l'aller-retour.

Le français dispose de termes techniques, juridiques et organisationnels qui n'ont pas d'équivalent exact en anglais. Des mots comme traçabilité, découplage, réglementation, cloisonnement, ou des expressions comme maîtrise d'ouvrage / maîtrise d'œuvre sont soit absents, soit approximatifs en anglais. Les formuler directement en français dans l'instruction garantit que le modèle reçoit le concept précis, pas une paraphrase appauvrie.

Le poids de la représentation dans les données d'entraînement

Le français représente environ 0,16% des données d'entraînement des LLM grand public. C'est structurellement peu. Mais c'est aussi suffisant pour que les modèles modernes comprennent correctement le français courant. La question n'est donc pas de savoir si le modèle comprend, mais si le modèle raisonne aussi bien en français qu'en anglais. Et là, les études répondent clairement : pas encore, mais l'écart se réduit, et le passage en français évite des erreurs de traduction interne qui ne se produiraient pas autrement. Une question intéressante à se poser et donc l'utilité ou non à long terme de construire des LLM en langue native, ou des nouvelles formes d'outils de reflexion ou de cohabitation de langage pour l'avenir.

Sources

The Reasoning Lingua Franca: A Double-Edged Sword for Multilingual AI

Pensez: Less Data, Better Reasoning – Rethinking French LLM

MultiNRC

Benchmark de coût par langue sur Claude / ChatGPT / Gemini