Le contenu multilingue face aux moteurs génératifs : FR, ES, EN sans dilution.

Un moteur génératif répond dans la langue du prompt, mais il ne choisit pas ses sources dans une seule langue

La réponse suit la langue de la question : un prompt en espagnol produit une réponse en espagnol. Les sources, elles, sont choisies dans un index qui mêle les langues. Dans nos relevés, menés en français, en espagnol et en anglais depuis Alicante, Valence, Madrid et Paris, la majorité des sources citées est dans la langue du prompt, mais des sources anglaises apparaissent régulièrement sur les sujets techniques et B2B, et une source française ou espagnole peut être reprise, traduite, pour une question posée dans l'autre langue quand aucun équivalent local n'existe.

Deux conséquences en découlent. La première : les versions linguistiques d'un même site ne sont pas indépendantes ; elles partagent une entité, des chiffres et une réputation, et le moteur les lit ensemble. La seconde : la dilution multilingue a une forme précise. Elle survient quand les versions disent des choses différentes, quand le nom de l'entité varie d'une langue à l'autre, ou quand une version n'est qu'une traduction mot à mot qui ne répond pas aux questions réellement posées sur son marché.

Cet article traite ces risques dans l'ordre : la langue des sources et ce qu'elle implique pour la rédaction, l'adaptation par marché, le signalement des versions par hreflang, la cohérence de l'entité entre langues, puis la mesure par langue. Il s'appuie sur la méthode complète, dont les quatre conditions, accessible, citable, identifiée, corroborée, s'appliquent à chaque version séparément.

Langue du prompt, langue des sources : ce qui se passe entre les deux

Le mécanisme est celui de toute recherche générative : le prompt est décomposé en sous-requêtes, chaque sous-requête ramène des passages, et le modèle rédige. La langue intervient à deux moments. Au moment des sous-requêtes, le moteur formule en général dans la langue du prompt, et parfois aussi en anglais pour les sujets dont la documentation est majoritairement anglophone. Au moment de la sélection, il retient de préférence un passage dans la langue de la réponse, parce qu'il pourra le citer sans le traduire ; un passage dans une autre langue est retenu s'il est nettement meilleur, ou s'il est seul.

Ce que cela implique pour la rédaction : chaque version linguistique doit être citable seule, avec ses propres passages de quarante à quatre-vingts mots, ses propres preuves et sa propre date. Une version espagnole qui renvoie à un tableau en français, ou une version anglaise qui cite un décret français sans l'expliquer, n'est pas un passage citable pour un prompt espagnol ou anglais. Les règles du passage citable s'appliquent à chaque langue, pas à la langue d'origine seulement.

Une précision sur l'anglais. Sur les sujets B2B et techniques, les sources anglophones sont surreprésentées dans les réponses, y compris à des prompts français ou espagnols. Une version anglaise de vos pages clés n'est donc pas seulement une porte vers le marché anglophone ; c'est parfois la version qui sera citée, traduite, pour une question posée en français.

Traduire ou adapter ? Chaque version doit répondre aux questions de son marché

La traduction mot à mot produit une version grammaticalement correcte qui répond aux questions du marché d'origine. Or les questions changent d'un marché à l'autre, même à intention égale. Un acheteur français demande « quel délai » ; un acheteur espagnol demande « cuánto tarda », mais aussi « qué documentación necesito », parce que les démarches diffèrent ; un acheteur anglophone commence souvent par le prix. Les titres-questions, les preuves et les exemples doivent venir du marché cible, pas de la version source.

Sur nos propres pages, produites en espagnol, en français et en anglais, nous procédons ainsi : la version source est écrite par un expert dans sa langue, puis chaque autre version est confiée à un locuteur natif qui connaît le métier et qui réécrit les questions, remplace les preuves et les exemples, et conserve les chiffres et la structure. Un premier jet automatique est admissible pour gagner du temps ; il n'est jamais publié sans cette réécriture.

Tableau : faites défiler horizontalement.

hreflang et URL : dire au moteur quelle version sert à qui

Le signal hreflang indique, pour chaque page, ses équivalents dans les autres langues. Il est documenté par Google. Pour les moteurs génératifs, aucun éditeur n'a, à notre connaissance, publié de règle spécifique ; ceux qui s'appuient sur l'index de Google ou de Bing en bénéficient indirectement, et les autres lisent au minimum l'attribut lang et la structure des URL. Le coût est faible, l'absence est coûteuse : sans hreflang, le moteur peut citer la version anglaise pour un prompt français, ou traiter trois pages équivalentes comme des doublons.

<!-- Dans le <head> de chaque version : les mêmes quatre liens, réciproques -->
<link rel="alternate" hreflang="fr" href="https://www.exemple.com/fr/entretien-pompe-a-chaleur/">
<link rel="alternate" hreflang="es" href="https://www.exemple.com/es/mantenimiento-bomba-de-calor/">
<link rel="alternate" hreflang="en" href="https://www.exemple.com/en/heat-pump-maintenance/">
<link rel="alternate" hreflang="x-default" href="https://www.exemple.com/en/heat-pump-maintenance/">

<!-- Et une seule langue déclarée par document -->
<html lang="es">

Tableau : faites défiler horizontalement.

Trois règles pratiques. Les liens hreflang sont réciproques sur chaque version. Chaque URL renvoie une seule langue, sans mélange, y compris dans le titre, la meta description et les données structurées. La version x-default désigne la page qui accueille les visiteurs dont la langue n'est pas servie, souvent l'anglais. Et une règle de robots : les agents de recherche IA arrivent sans préférence linguistique déclarée ; une redirection automatique selon la langue du navigateur ou l'adresse IP leur cache les autres versions, et parfois la bonne.

Une seule entité en trois langues : la cohérence qui fait la source

Le risque le plus discret du multilingue est la fragmentation de l'entité. Si le site français dit « SEO360 », le site espagnol « SEO360 Alicante » et un profil anglais « SEO 360 Agency », le moteur reconstruit trois organisations, chacune avec une partie des mentions et des preuves. La condition « identifiée » échoue trois fois. La règle est simple : un seul nom, une seule organisation, des descriptions équivalentes, et des bureaux rattachés à la même entité.

Dans le balisage, cela se traduit par une Organization unique, référencée par un @id identique depuis les trois versions, avec les mêmes sameAs et le même legalName ; seules les propriétés textuelles sont traduites, et chaque page déclare sa langue par inLanguage. La construction de l'entité, registres, profils, Wikidata, est traitée dans l'article sur l'entité de marque ; ici, l'essentiel est qu'elle soit une, quelle que soit la langue.

Les trois dilutions multilingues, et comment les éviter

Trois défauts reviennent dans nos audits de sites multilingues, et chacun se corrige par une règle de production plutôt que par un correctif technique.

1. La contradiction entre versions. Un délai de six semaines en français, de deux mois en espagnol ; un prix mis à jour sur une version et pas sur l'autre. Le moteur qui lit les deux voit une source incohérente et préfère un tiers. Remède : les chiffres sont centralisés, les trois versions sont mises à jour le même jour, et la note de mise à jour existe dans chaque langue.
2. La traduction automatique non relue. Elle produit un texte correct et générique, dont les titres ne correspondent à aucune question locale et dont les exemples sonnent étrangers. Remède : un locuteur natif qui connaît le métier réécrit chaque version, comme décrit plus haut.
3. La page mixte. Un corps en espagnol, des citations en anglais, des libellés d'interface en français, un titre resté dans la langue source. Le robot lit une page dont la langue n'est pas nette, et la sélection en pâtit. Remède : une langue par URL, y compris pour les éléments d'interface, les balises de titre et les données structurées.

Mesurer par langue : un panel par marché, pas une traduction du panel

La part de citation se mesure par langue, avec un panel construit dans chaque langue à partir des formulations réelles de chaque marché, et non en traduisant le panel français. Les questions diffèrent, les moteurs dominants diffèrent, les sources tierces aussi. Nous exécutons nos propres panels en français, en espagnol et en anglais, et les résultats d'une même marque varient fortement d'une langue à l'autre : présente sur un marché, absente sur l'autre, souvent parce que les sources tierces qui la corroborent n'existent que dans une langue. La construction du panel est détaillée dans l'article consacré au panel de prompts.

Deux lectures complètent la mesure. Par langue et par moteur, d'abord : ChatGPT, Perplexity, Gemini et Claude ne s'appuient pas sur les mêmes index et n'ont pas la même couverture selon les langues ; un marché peut être gagné sur l'un et perdu sur l'autre. Par langue des sources citées, ensuite : si les réponses espagnoles citent des sources anglaises, votre version anglaise est un levier pour le marché espagnol ; si elles citent des annuaires et des médias espagnols, c'est la corroboration locale qu'il faut travailler avant les pages.

Les erreurs multilingues les plus fréquentes

Les six erreurs ci-dessous se vérifient en une heure sur n'importe quel site à trois langues, et chacune coûte des citations sur au moins un marché.

• Un nom de marque décliné par pays, qui fragmente l'entité en autant d'organisations.
• Des versions traduites mot à mot, dont les titres ne correspondent à aucune question locale.
• Des chiffres ou des délais différents d'une langue à l'autre.
• Une redirection automatique selon l'adresse IP, qui cache les autres versions aux robots.
• Un hreflang non réciproque, ou absent des versions secondaires.
• Un panel de mesure traduit du français, qui mesure des questions que personne ne pose en espagnol.

Ce qu'il faut retenir