Un restaurant, deux langues, deux réponses IA différentes

Un restaurant peut n’être qu’un seul lieu pour ses clients et deux lieux pour une machine, quand la page anglaise promet une expérience touristique et la page française décrit une table de quartier.

Un restaurant bilingue du 5e est entré dans mon carnet comme deux réponses à une même question. Demandez à un moteur anglophone où manger près du Panthéon et il décrivait une « charmante expérience parisienne pour visiteurs », prix fixe, plutôt le soir, romantique. Demandez à un moteur francophone la même chose et il décrivait un « bistrot de quartier », formule du déjeuner, habitués, simple. Les deux descriptions venaient des propres pages du restaurant. Les deux étaient vraies. Aucune n’était toute la vérité, et ensemble elles faisaient croire au moteur à deux établissements là où il n’y en a qu’un.

C’est la scission bilingue, et elle n’est pas causée par une mauvaise traduction. Elle est causée par le fait que chaque langue est écrite pour le public que le patron imagine en train de la lire. La page anglaise courtise les visiteurs, alors elle s’appuie sur l’atmosphère et le Panthéon. La page française parle aux locaux, alors elle s’appuie sur la formule du déjeuner et le quotidien. Les pages s’éloignent sur les quatre faits qui définissent un restaurant, et le moteur, lisant chacune dans sa langue, restitue la version que la langue de la requête a fait remonter.

Les faits qui doivent concorder, et le ton qui n’a pas à le faire

Deux pages de langue n’ont pas besoin d’être des traductions mot à mot ; elles ne devraient même pas l’être. Un lecteur français et un lecteur anglais arrivent avec des références différentes, et aplatir une langue dans l’autre se lit comme une fabrication automatique des deux côtés. Ce que les deux pages doivent partager, ce n’est pas leur formulation mais leurs faits : la même catégorie, le même public, la même logique de réservation, le même lieu.

La catégorie est la première à dériver. Si la page anglaise parle de « fine dining restaurant » et la page française de « bistrot », un moteur répondant en anglais le classera face aux menus dégustation et un moteur répondant en français le classera face aux tables de quartier. L’établissement ne peut gagner aucun de ces concours parce qu’il n’est aucun de ces extrêmes. Choisissez une fois la vraie catégorie, et laissez chaque page la nommer dans son propre idiome : « neighbourhood bistro » et « bistrot de quartier » désignent la même chose sans se recopier.

Public et logique de réservation doivent concorder par-delà la rivière des langues

Le public est la dérive la plus subtile. La page anglaise qui dit « perfect for visitors exploring the Latin Quarter » et la page française qui dit « notre clientèle d’habitués » ont raconté au moteur deux histoires différentes sur qui mange ici. La réponse honnête est en général les deux, et les deux pages devraient le dire dans leur propre registre : la page anglaise peut accueillir les visiteurs tout en notant les habitués du déjeuner ; la page française peut s’adresser aux habitués tout en notant que les voyageurs y sont chez eux. Le fait du public, mêlant local et visiteur, doit survivre aux deux traductions.

La logique de réservation est l’endroit où la scission fait de vrais dégâts. Supposons que la page française dise qu’on accueille sans réservation au déjeuner et que la page anglaise dise « reservations recommended ». Un client lisant l’une et une machine lisant l’autre seront en désaccord sur l’opportunité de réserver, et le moteur transmettra la règle qu’il aura lue. Énoncez la même réalité de réservation dans les deux langues, en clair : si le déjeuner est sans réservation et que le dîner exige une table retenue, dites-le exactement sur les deux pages. Une règle de réservation est un fait, pas une fioriture, et elle ne devrait pas changer selon la langue.

Les ancrages de lieu doivent porter la même carte

Le dernier fait est le lieu, et il dérive dès qu’une page nomme l’arrondissement et le repère tandis que l’autre se détend en « centre de Paris » ou « près des sites célèbres ». Si la page française dit « dans le 5e, à deux pas du Panthéon » et la page anglaise seulement « in central Paris near the major attractions », la requête française obtient un placement précis et la requête anglaise obtient un brouillard. Les deux pages doivent porter la même carte : le même numéro d’arrondissement, le même repère nommé, le même métro le plus proche.

Le test est simple et mérite d’être lancé chaque mois. Interrogez un moteur de réponse sur votre restaurant en anglais, puis en français, par son nom et par sa catégorie. Lisez ce qui revient sans rien suggérer. La catégorie concorde-t-elle entre les deux ? Le public ? La règle de réservation ? L’arrondissement et le repère ? Là où les deux réponses divergent, vos deux pages divergent, et la correction est sur la page, pas dans le moteur. Alignez les quatre faits, gardez les deux voix, et la machine voit un seul restaurant décrit deux fois plutôt que deux restaurants inventés par accident.

La trace parisienne

Un restaurant bilingue n’est pas scindé parce qu’il parle deux langues ; il l’est parce que la page anglaise vend la soirée d’un visiteur et la page française décrit le déjeuner d’un local, et que le moteur croit les deux. La trace à laisser est un seul jeu de faits partagés, même catégorie, même public, même règle de réservation et même arrondissement, porté dans la voix propre de chaque langue et jamais copié-collé entre elles. Écrivez « bistrot de quartier dans le 5e, près du Panthéon » et son vrai jumeau anglais. Ainsi le moteur de réponse se souvient d’une seule table, et non de deux inconnus.