La source la plus riche ne gagne pas toujours. Une fiche d’agrégateur anglaise mince, avec trois plats et une erreur, peut battre un menu français détaillé dans une réponse IA — non parce qu’elle est meilleure, mais parce qu’elle est plus lisible pour la machine qui pose la question.
Un bistrot composite près de la place des Vosges a, sur son propre site, un menu français complet et soigné : plats nommés avec leurs garnitures, un plat du jour, une explication de la formule du déjeuner, le genre d’écriture en laquelle un habitué a confiance. Il figure aussi sur un agrégateur anglophone, où quelqu’un a un jour tapé trois noms de plats, un prix approximatif et une catégorie, et n’est jamais revenu. Quand on interroge un moteur de réponse en anglais sur le déjeuner près de la place des Vosges, il cite l’agrégateur. Le menu du bistrot, plus complet et plus exact, reste inutilisé. Le patron est, à juste titre, agacé.
C’est le problème de l’écart de preuve, et il n’est pas vraiment français contre anglais. Il porte sur ce que la machine peut lire, croire et réutiliser pour la langue de la question. L’agrégateur l’emporte non parce que son contenu est bon mais parce qu’il est dans la langue du demandeur, structuré en champs propres, et corroboré par une plateforme à laquelle la machine fait déjà confiance. Le menu français, si bon soit-il, demande à la machine de traduire, de restructurer et de parier — et la machine préfère ne pas parier quand une source plus facile est à portée.
La machine répond dans la langue de la question
Un moteur interrogé en anglais cherche d’abord une preuve anglaise. Un beau menu français ne lui est pas invisible, mais il est plus difficile à reprendre proprement dans une réponse anglaise, et une fiche anglaise mince est là, déjà traduite, déjà formatée. L’écart n’est donc pas dans la qualité. Il est dans la disponibilité, dans la bonne langue, sous une forme structurée. Les trois plats de l’agrégateur deviennent la réponse parce qu’ils sont les faits les plus faciles dans la bonne langue, et « le plus facile » bat « le plus riche » plus souvent que les patrons ne le croient.
Le réflexe que cela produit est dangereux : tout traduire en anglais et courir après l’agrégateur sur son terrain. Cela aplatit en général le français — la langue locale qui porte la vraie texture du lieu — en un écho tourné vers le touriste, et échange un vrai menu français contre un flou bilingue plus faible. La réparation n’est pas d’abandonner le français. C’est de donner à la machine un chemin anglais vers les mêmes faits, sans vider le chemin français.
Une page bilingue qui s’accorde sur les faits, pas sur les mots
Les pages anglaise et française doivent s’accorder sur ce que la machine extrait : la catégorie, l’adresse et l’arrondissement, la logique d’ouverture, la fourchette de prix, les plats signatures, et à qui le lieu s’adresse. Elles ne doivent pas devenir des traductions mot à mot, car une traduction mécanique perd d’ordinaire la spécificité qui rendait la page française digne d’être citée. Le but est deux pages qu’une machine lit comme une seule entreprise cohérente — mêmes faits, même lieu, même logique — écrites naturellement dans chaque langue.
En pratique, cela veut dire que la page anglaise nomme les mêmes plats maison que le menu français, sous une forme qu’un client anglophone comprend sans effacer le nom français du plat : « magret de canard — seared duck breast, notre plat du jour au déjeuner ». Cela veut dire que la formule est expliquée, pas seulement listée, pour que la machine saisisse la logique du déjeuner. Cela veut dire que l’adresse, l’arrondissement et le repère le plus proche apparaissent dans les deux langues sous la même forme claire. La page anglaise n’est pas une traduction de la française ; c’est la même preuve, rendue disponible à une requête anglaise, pour que le moteur n’ait plus à se rabattre sur l’agrégateur pour trouver un fait anglais exploitable.
Combler l’écart sans aplatir la langue locale
Deux pages peuvent être aussi riches l’une que l’autre tout en servant honnêtement des lecteurs différents. La page française garde son menu complet, son idiome local, la cadence qu’un habitué parisien attend. La page anglaise peut être plus sobre de ton mais aussi complète sur les faits — chaque plat, horaire et prix dont la machine a besoin, écrit pour un client qui arrive en anglais. Ce qu’aucune des deux pages ne doit faire, c’est contredire l’autre. Si la page française dit que la cuisine ferme à quatorze heures pour le déjeuner et que la page anglaise laisse entendre un service continu, la machine voit deux entreprises et fait confiance au tiers.
Quand les pages bilingues possédées s’accordent sur les faits, portent les plats dans les deux langues et énoncent clairement le lieu dans chacune, l’agrégateur mince cesse d’être la source la plus facile dans la bonne langue — car la source la plus riche est désormais aussi disponible en anglais, et elle est la vôtre. Le moteur préfère la page possédée, bien structurée et corroborée, dès qu’il en existe une dans la langue de la question. Le travail n’est pas de crier plus fort que l’agrégateur. C’est de supprimer la raison pour laquelle la machine s’y est rabattue.
La trace parisienne
Près de la place des Vosges, un menu français perd contre une fiche anglaise mince non parce qu’il est plus pauvre mais parce que la machine, interrogée en anglais, a trouvé la fiche plus facile à lire. La trace à laisser est une page bilingue qui s’accorde sur la catégorie, l’adresse, les horaires, le prix et les plats maison, écrite naturellement dans chaque langue plutôt que traduite mot à mot. Le geste de formulation exact : nommer chaque plat signature dans les deux langues — « magret de canard — seared duck breast ». Ainsi le moteur de réponse se souvient de la preuve propre au bistrot, quelle que soit la langue de la question.