Stratégie de localisation pour l’app

1. Pourquoi réfléchir à la localisation précisément dans une app ChatGPT

Si vous avez déjà construit des applications web classiques, la localisation vous évoquait sans doute l’i18n traditionnel : chaînes d’interface, quelques formats de dates et de nombres, dictionnaires — et vous traduisez prudemment l’ensemble. Dans une app ChatGPT, c’est plus subtil : un troisième acteur entre en scène — le modèle LLM lui‑même. Il lit vos descriptions d’outils, vos prompts, vos résultats, il en tire des conclusions et prend des décisions.

Autrement dit, la langue n’est pas seulement « comment afficher joliment le texte à l’utilisateur », mais aussi « comment le modèle comprend ce que fait votre outil, quand l’appeler et quels arguments lui passer ». Le bouton « Acheter » peut être traduit approximativement, l’utilisateur s’en sortira. Mais si vous décrivez de façon floue un tool qui effectue un paiement, dans un mélange de russe et d’anglais, le modèle peut soit ne jamais l’appeler, soit l’appeler d’une manière très différente de ce que vous attendiez.

Autre point : ChatGPT transmet déjà à votre serveur MCP des indices sur la locale et la localisation de l’utilisateur — _meta["openai/locale"] et _meta["openai/userLocation"]. Cela se fait au niveau des requêtes MCP vers les outils, afin que vous puissiez adapter le texte et les données à la langue et à la région de l’utilisateur. Autrement dit, la plateforme vous « insuffle » déjà le contexte, et la tâche du développeur est d’en faire un usage réfléchi.

C’est pourquoi, dans ce module, nous considérons la localisation comme un aspect architectural d’une app ChatGPT, et non comme « on a traduit l’UI et basta ».

2. Couches à localiser

Regardons l’app comme un mille‑feuille de couches. Chaque couche peut (et doit souvent) être localisée. Pour ne pas nous noyer, commençons par une carte.

Vue d’ensemble des couches

D’abord — un tableau général, puis nous détaillerons pièce par pièce.

C’est en fait la première couche de notre carte de localisation : nous ajouterons ensuite de la profondeur (cosmétique/sémantique), les langues et des éléments concrets.

Passons ensuite couche par couche.

Widget UI

La couche la plus évidente — l’interface du widget. Dans GiftGenius, cela comprend :

• les titres des blocs ;
• les libellés des champs (« Destinataire », « Budget », « Centres d’intérêt ») ;
• les boutons (« Trouver un cadeau », « Réinitialiser les filtres ») ;
• les placeholders dans les inputs (« par exemple, collègue, maman… ») ;
• les messages d’erreur et d’états vides (« Aucun cadeau trouvé »).

Dans une application React classique, ce sont les premiers candidats à extraire dans des dictionnaires. Ici, c’est la même chose, avec la nuance que l’UI n’est pas toute l’app, mais seulement l’une de ses faces.

Un peu plus loin dans le module, nous mettrons en place une architecture i18n correcte pour le widget, mais il est déjà important de fixer ceci : il ne doit pas y avoir de chaînes en dur dans le JSX. Même si vous ne prenez en charge qu’une seule langue pour l’instant, il est utile de structurer d’emblée les textes d’UI.

Mini‑exemple avec notre GiftGenius (sans vraie bibliothèque i18n pour l’instant) :

type Locale = "en" | "ru";

const uiText = {
  en: {
    title: "GiftGenius: find a perfect present",
    recipientLabel: "Recipient",
  },
  ru: {
    title: "GiftGenius: trouvez le cadeau idéal",
    recipientLabel: "Destinataire",
  },
};

function GiftForm({ locale }: { locale: Locale }) {
  const t = uiText[locale];

  return (
    <div>
      <h2>{t.title}</h2>
      <label>{t.recipientLabel}</label>
      {/* autres champs */}
    </div>
  );
}

Ici, nous ne faisons pas encore de « vraie » localisation, mais nous mettons déjà en évidence la couche des textes d’UI.

Textes GPT et prompts

La couche suivante — les textes système et auxiliaires, invisibles directement pour l’utilisateur, mais qui influencent fortement le comportement du modèle :

• le system‑prompt de votre app (« Tu es un assistant de sélection de cadeaux… ») ;
• les modèles d’explications que vous donnez au modèle (« Rédige un court résumé du choix ») ;
• des follow‑ups pré‑écrits et des aides pour le modèle (« propose à l’utilisateur de préciser le budget si… »).

Ces textes peuvent (et devraient souvent) être localisés. Exemple simple : si l’utilisateur écrit en russe et que votre system‑prompt est entièrement en anglais, le modèle s’en sortira, mais vous perdez un contrôle précis sur le style et les formulations pour cette langue.

Un peu plus tard, dans les leçons sur les outils de localisation des prompts et des descriptions (prompts/descriptions), nous verrons comment jouer proprement avec des system‑prompts multilingues. Ici, l’important est de poser que les prompts sont une couche localisable au même titre que l’UI.

Données et contenu

Ensuite viennent vos données. Pour GiftGenius, c’est le catalogue des cadeaux : noms, descriptions, catégories, parfois des conseils d’utilisation. Pour une app commerciale, ce sont aussi les prix, les devises, les unités de mesure, les formats de dates, etc. Dans les spécifications du product feed pour ChatGPT (le format avec lequel vous décrivez vos produits et services à la plateforme), ces champs textuels (title, description) et les prix sont explicitement mis en avant pour pouvoir être affichés correctement aux utilisateurs dans ChatGPT.

Si vous visez une app globale, votre catalogue de cadeaux soulève au moins les questions suivantes :

• stocke‑t‑on les noms/descriptions dans plusieurs langues ?
• comment choisit‑on la langue à renvoyer à l’utilisateur ?
• que fait‑on si la traduction n’est pas encore prête (fallback) ?
• comment affiche‑t‑on les devises et formats de dates/prix selon les régions ?

Petit exemple typé pour le catalogue :

type Locale = "en" | "ru";

interface LocalizedString {
  en: string;
  ru: string;
}

interface Gift {
  id: string;
  title: LocalizedString;
  description: LocalizedString;
  priceCents: number;
  currency: "USD" | "EUR" | "RUB";
}

function getLocalizedTitle(gift: Gift, locale: Locale) {
  return gift.title[locale] ?? gift.title.en;
}

Autrement dit, la localisation n’est pas qu’une affaire de frontend, mais aussi de structure de données dans la base et de ressources MCP. Nous y reviendrons lorsque nous parlerons du Gateway (la passerelle entre ChatGPT et vos services) et du serveur MCP.

Descriptions des tools et JSON Schema

Quatrième couche — les descriptions des outils et de leurs arguments. C’est précisément via celles‑ci que le modèle comprend quand appeler votre tool et quels arguments lui passer. En MCP, il s’agit de title, de la description de l’outil et de la description des champs du JSON Schema.

La documentation de l’Apps SDK souligne que le modèle utilise les noms, descriptions et la documentation des paramètres pour choisir les outils et construire les arguments.

Exemple hypothétique d’outil GiftGenius dans un serveur MCP TypeScript :

server.registerTool(
  "suggest_gifts",
  {
    title: "Suggest gifts",
    description: "Suggest 3–5 gift ideas based on recipient profile.",
    inputSchema: {
      type: "object",
      properties: {
        recipient: {
          type: "string",
          description: "Who is the gift for (e.g. mother, colleague)?",
        },
      },
      required: ["recipient"],
    },
  },
  async ({ input }) => { /* ... */ }
);

Ici, tout est en anglais, le modèle comprend très bien. Mais si l’utilisateur écrit en russe ? Il pourra tout de même associer « mama » à recipient, mais avec des champs complexes et des termes métier, le risque d’erreur augmente. Dans la leçon sur les stratégies de localisation des descriptions, nous discuterons séparément de : descriptions unifiées en anglais vs descriptions localisées.

À ce stade, sur la carte de localisation, il faut simplement noter que les descriptions des tools et du JSON Schema peuvent aussi être localisées, et cela influence le comportement du modèle.

Commerce et partie juridique

Enfin, la couche à laquelle on pense souvent en dernier — tout ce qui concerne l’argent et les textes juridiques :

• noms des SKU et des plans d’abonnement ;
• champs title/description dans les feeds commerce (produits, services, abonnements) ;
• Terms of Service, Privacy Policy, Refund Policy ;
• emails et notifications (email, push), si l’app envoie quelque chose en dehors de ChatGPT ;
• statuts des commandes et erreurs de paiement que vous affichez à l’utilisateur (« Paiement refusé », « Indisponible dans votre région »).

Ici, deux aspects : l’UX et la loi. L’utilisateur doit comprendre, dans sa langue, à quoi il consent et ce qu’il paie. En même temps, les traductions doivent être juridiquement correctes : parfois, les juristes exigent que seuls les textes dans une langue (par exemple l’anglais) fassent foi juridiquement, et que les autres traductions n’aient qu’une valeur de référence.

Sur notre carte de localisation, nous marquons impérativement le contenu commerce et juridique comme une couche à part, car il requiert souvent un autre processus (juristes, conformité, validation des textes avec le marketing).

3. Profondeur de la localisation : « cosmétique » vs « sémantique »

Quand on dit « localiser une app », il est utile de distinguer deux niveaux de profondeur : cosmétique et sémantique.

Localisation cosmétique

La cosmétique — tout ce qui modifie l’apparence et la lisibilité, mais ne change quasiment pas le comportement du système. Exemples :

• titres et libellés des boutons traduits ;
• placeholders traduits dans les inputs ;
• messages d’erreur « humains » dans l’UI ;
• texte localisé d’une bannière marketing dans le widget.

Pour les applications web classiques, on s’arrête souvent là. Dans une app ChatGPT, c’est important, mais ce n’est que la partie émergée de l’iceberg.

Localisation sémantique

La sémantique — ce qui modifie le comportement du modèle et la logique de l’app. Ici, la langue influe sur :

• l’outil que le modèle choisira ;
• la manière de remplir les arguments de l’outil ;
• les données qu’il considérera comme « correctes » pour l’utilisateur donné.

Exemples de localisation sémantique :

• un system‑prompt dans la langue de l’utilisateur, qui fixe le style et les règles d’échange ;
• des descriptions des tools et de leurs champs dans la langue de l’utilisateur ;
• des textes d’aide/instructions différents selon le contexte culturel ;
• des paramètres de formats de dates/devises qui influencent le parsing et la génération (31.12.2025 vs 12/31/2025).

Si vous n’avez localisé que la cosmétique mais pas la sémantique, votre app peut sembler localisée tout en se comportant comme « anglophone » sous le capot. Sur la carte de localisation, il est utile d’indiquer explicitement les éléments critiques pour le comportement du modèle.

Pour notre GiftGenius, par exemple :

• la description du champ budget dans le JSON Schema (« Budget in the user’s currency ») — sémantique ;
• le libellé du bouton « Trouver un cadeau » — cosmétique (important pour l’UX, mais invisible pour le modèle).

Maintenant que nous distinguons cosmétique et sémantique, il est logique de répondre à la question : dans combien de langues souhaitez‑vous que l’app fonctionne.

4. App ChatGPT monolingue vs multilingue

Avant d’esquisser la carte, clarifiez vos ambitions : faites‑vous une app strictement monolingue ou visez‑vous un public multilingue ?

App monolingue

Une app monolingue — vous soutenez délibérément une seule langue. Par exemple, uniquement l’anglais.

Le widget UI, les prompts, les descriptions d’outils et les données — tout est dans une seule langue. Cela simplifie grandement la vie :

• une seule base de code sans branchement par langues ;
• un seul schéma de catalogue (sans title_en, title_ru, etc.) ;
• maintenance et tests plus simples.

Mais l’audience est limitée. Pour une app ChatGPT, cela signifie aussi que si un utilisateur arrive avec une autre locale, ChatGPT peut tout de même afficher votre app, mais il devra constamment « transcoder » la langue de l’utilisateur en la langue interne de l’app. Dans certains domaines, c’est acceptable, mais pour un service grand public de cadeaux — probablement pas.

App multilingue

Une app multilingue — c’est déjà un choix architectural. Ici :

• l’UI et les textes s’affichent correctement en fonction de la locale de l’utilisateur ;
• les données (catalogues, descriptions produits) sont liées à la langue/région ;
• les descriptions des tools et les system‑prompts peuvent varier selon la langue ;
• les scénarios commerce tiennent compte des devises locales, taxes, restrictions.

Dans ce cas, un simple if (locale === "ru") éparpillé dans tout le code est clairement insuffisant. Il faut une architecture : dictionnaires, ressources localisables, un endroit unique où sont stockés et traités locale et userLocation, des conventions entre le widget et le serveur MCP.

La documentation de l’Apps SDK souligne explicitement que ChatGPT vous transmet locale et userLocation via _meta lors de l’appel à vos outils, précisément pour que vous puissiez, côté serveur, choisir la bonne langue et le bon format de données. C’est le « carburant » d’une app multilingue.

Petit comparatif

Pour la clarté — mini‑comparatif :

Dans ce cours, nous partons du principe que GiftGenius devient multilingue (au minimum EN/RU), pour montrer un schéma « mûr ». Mais beaucoup d’astuces seront utiles aussi pour une app monolingue bien pensée, si vous voulez rester prêt à étendre.

5. Où la langue influence réellement le modèle

Identifions maintenant les points où la langue influence directement le comportement de ChatGPT.

Langue de l’entrée utilisateur vs langue des descriptions des tools

Imaginons :

• l’utilisateur écrit : « Trouve un cadeau pour un collègue pour 50 euros » ;
• votre tool suggest_gifts n’est décrit qu’en anglais ;
• les champs du schéma : recipient, budget, currency, interests.

Le modèle doit :

1. décider qu’il faut appeler suggest_gifts ;
2. extraire recipient = "colleague", budget = 50, currency = "EUR" ;
3. sérialiser correctement cela dans les arguments JSON.

Si les descriptions sont laconiques et dans une autre langue, le modèle peut gérer, mais la probabilité de remplir les champs de travers est plus élevée. Par exemple, confondre budget et price_limit ou envoyer du texte dans interests parce que la description du champ disait quelque chose de vague comme « Any extra info about the gift ».

Avec un texte utilisateur en russe et des descriptions en anglais, le modèle « saute » en permanence entre les langues.

Variante avec schéma localisé :

const locale = _meta?.["openai/locale"] ?? "en"; // transmis par ChatGPT 
const isRu = locale.startsWith("ru");

server.registerTool(
  "suggest_gifts",
  {
    title: isRu ? "Sélection de cadeaux" : "Suggest gifts",
    description: isRu
      ? "Propose 3 à 5 idées de cadeaux sur la base du profil du destinataire."
      : "Suggest 3–5 gift ideas based on recipient profile.",
    inputSchema: { /* ... */ },
  },
  async ({ input }) => { /* ... */ }
);

Ici c’est simplifié : en réalité, il vaut mieux générer les descriptions une fois au démarrage du serveur plutôt qu’à chaque appel, mais l’idée est claire. Nous pouvons renvoyer des descriptions différentes à ChatGPT selon la locale, pour faciliter la compréhension de l’utilisateur par le modèle.

Langue des données vs langue de la requête

Si votre catalogue de cadeaux n’est qu’en anglais et que l’utilisateur interagit en russe, le modèle choisira des noms et descriptions en anglais. Parfois c’est acceptable, parfois non. Mais plus important est la manière dont vous formatez la sortie :

• affichez‑vous à l’utilisateur les titles/description originaux venant du serveur ?
• ou le modèle les reformule‑t‑il dans la langue de l’utilisateur dans son propre texte ?
• ou votre tool renvoie‑t‑il déjà un texte localisé en fonction de la locale ?

Dans l’Apps SDK, le structured content (données structurées renvoyées par vos tools) et la réponse textuelle peuvent vivre séparément. Vous pouvez renvoyer des données structurées (p. ex. un JSON avec des champs produit) et un texte distinct pour l’utilisateur, et le modèle décidera comment les rendre ou les reformuler.

La localisation peut se faire au niveau du serveur (données) ou au niveau du modèle (reformulation dans la langue voulue). Lors de la conception de la carte, il est utile de décider où vous placez la « dernière instance ».

System‑prompt et follow‑ups

Si votre system‑prompt est uniquement en anglais alors que l’utilisateur est russophone, le modèle va constamment jongler entre deux langues. Cela peut convenir, mais parfois vous voulez fixer fermement le ton : par exemple, dans la version russe de l’app, vous souhaitez un style plus informel, et dans la version anglaise — plus formel.

En conséquence, sur la carte de localisation, il faut noter :

• system‑prompt EN ;
• system‑prompt RU ;
• modèles de follow‑ups (EN/RU) ;
• toutes les indications « dures » dans le prompt pour les outils.

6. Carte de localisation pour GiftGenius

Assemblons maintenant tout ce que nous avons évoqué — couches, profondeur et langues — en une carte de localisation explicite pour GiftGenius. Faisons ce que vous devrez faire pour votre app : construire une carte de localisation. L’idée est simple : un tableau, avec en colonnes la couche et le type d’entité, et en lignes les éléments concrets.

Exemple de carte

Voici une carte simplifiée pour GiftGenius (EN/RU) :

suggest_gifts.description

budget.description

À gauche, nous groupons par couches, puis — les éléments concrets. La dernière colonne aide à comprendre ce qu’il ne faut pas modifier sans accord avec le prompt designer/spécialiste modèle : tout ce qui est marqué « sémantique » influe sur le comportement de GPT.

Petit brouillon de code

Pour relier la carte au code, on peut définir un type simple pour les entités localisables :

type LocalizedTextKey =
  | "ui.title"
  | "ui.recipient_label"
  | "error.no_gifts"
  | "prompt.summary_intro";

type Locale = "en" | "ru";

type Messages = Record<Locale, Record<LocalizedTextKey, string>>;

const messages: Messages = {
  en: {
    "ui.title": "GiftGenius: find a perfect present",
    "ui.recipient_label": "Recipient",
    "error.no_gifts": "No gifts found",
    "prompt.summary_intro": "Here’s why these gifts fit:",
  },
  ru: {
    "ui.title": "GiftGenius: trouvez le cadeau idéal",
    "ui.recipient_label": "Destinataire",
    "error.no_gifts": "Aucun cadeau trouvé",
    "prompt.summary_intro": "Voici pourquoi ces cadeaux conviennent:",
  },
};

Ces mêmes clés peuvent ensuite être utilisées à la fois dans le widget et lors de la formation des prompts côté serveur (à condition de faire passer la locale à travers toute la pile — ce sera l’objet de la prochaine leçon). Ainsi, votre « carte de localisation » devient peu à peu un dictionnaire typé, et non un ensemble disparate de chaînes.

7. Pratique : créez la carte de localisation de votre app

Avant d’approfondir les techniques d’i18n et l’architecture Gateway/MCP, il est important de faire un exercice ennuyeux mais très utile : décrire honnêtement ce que vous allez localiser.

Bonne approche : ouvrez n’importe quel éditeur (Google Sheets, Notion, etc.) et créez un tableau avec les colonnes :

• catégorie/couche (UI, prompts, données, tools, commerce et juridique, erreurs) ;
• élément (bouton concret, description d’un champ, endpoint concret avec texte) ;
• exemple de valeur EN ;
• exemple de valeur dans la deuxième langue (si déjà disponible, ou au moins un brouillon) ;
• marqueur « cosmétique/sémantique/juridiquement important » ;
• propriétaire (qui est responsable des modifications : frontend, serveur MCP, product, juriste).

Parcourez ensuite votre app et dressez honnêtement la liste de tout ce qui contient du texte ou où la langue influence le format des données.

Pour GiftGenius, on obtiendrait à peu près une version étendue du tableau ci‑dessus. En chemin, vous découvrirez presque à coup sûr quelques points « cachés » :

• des constantes textuelles dans le code des serveurs MCP (p. ex. des messages d’erreur) ;
• des valeurs par défaut dans le structuredContent (p. ex. des catégories que vous n’affichiez pas dans l’UI) ;
• des anciens libellés de tools qui ne correspondent plus à leur comportement réel.

Cet exercice est particulièrement utile à faire avant de relier la localisation à un vrai processus métier (paiements, activations d’abonnements, documents juridiques). Renommer le tool charge_user dans un système multilingue avec ACP et textes juridiques est ensuite bien plus douloureux.

Globalement, si vous dessinez la carte de localisation en amont et notez honnêtement ce que vous allez supporter et dans quelles langues, vous vous épargnez bien des soucis dans les modules suivants — quand entreront en jeu MCP, Gateway, commerce et Store.

8. Erreurs typiques lors de la planification de la localisation

Erreur n° 1 : penser que localisation = « traduire des boutons ».
Scénario très courant : l’équipe extrait soigneusement toutes les chaînes de l’UI dans des dictionnaires, les traduit et s’en réjouit. Pendant ce temps, le system‑prompt reste uniquement en anglais, les descriptions des tools aussi, et le catalogue ne contient que des noms en anglais. Résultat : l’app a l’air localisée, mais le modèle continue de « vivre en anglais » à l’intérieur, et le comportement reste anglocentré. En pratique, cela se manifeste par des recommandations étranges et des erreurs dans les arguments des tools.

Erreur n° 2 : ne pas distinguer cosmétique et sémantique.
Parfois, un product demande de « légèrement retoucher la formulation » dans la description d’un outil ou dans le system‑prompt, et un développeur change le texte comme s’il s’agissait d’un simple libellé d’UI. Mais la description d’un champ JSON Schema ou une phrase dans un system‑prompt — c’est une partie du contrat avec le modèle. Ces changements peuvent modifier radicalement la manière dont GPT appelle votre tool. Si vous ne marquez pas à l’avance les éléments sémantiques sur la carte de localisation, vous risquez de casser involontairement le comportement de l’app.

Erreur n° 3 : démarrer un bazar multilingue sans architecture.
Très tentant au début de saupoudrer le code de if (locale === "ru") et d’injecter des chaînes russes où nécessaire. Au bout de quelques semaines, l’application devient « l’enfer de la localisation » : dans un composant les chaînes viennent d’un dictionnaire, dans un autre elles sont en dur dans le JSX, sur le serveur — troisième schéma de nommage des clés. Plus tard, brancher un vrai système i18n et harmoniser le tout devient bien plus difficile.

Erreur n° 4 : oublier les données et l’argent.
Même des équipes expérimentées commencent souvent par traduire l’UI et les prompts, mais omettent que les catalogues produits, prix, devises et textes juridiques doivent aussi tenir compte de la locale et de la userLocation. Dans les spécifications du product feed pour ChatGPT, il est précisément indiqué quels champs textuels et quels prix sont nécessaires pour un affichage correct des produits. Si vous ne prévoyez pas le multilingue au niveau des données, vous devrez ensuite soit dupliquer le feed, soit faire des migrations douloureuses.

Erreur n° 5 : ignorer les signaux de la plateforme sur la locale et la localisation.
ChatGPT transmet déjà dans les appels MCP _meta["openai/locale"] et _meta["openai/userLocation"], pour que vous compreniez dans quelle langue et depuis quelle région on vous parle. Certains développeurs demandent pourtant à l’utilisateur « Choisissez la langue de l’interface » au premier lancement et n’utilisent aucunement ces signaux pour le choix des ressources et des prix. Résultat : l’UX en pâtit, et l’architecture devient plus complexe que nécessaire.

Erreur n° 6 : ne pas désigner des « propriétaires » des éléments localisables.
Une fois en production, on découvre que les traductions sont dispersées entre différentes personnes : les frontenders modifient les textes d’UI, les backenders — les descriptions des tools, le spécialiste ML — le system‑prompt, et les juristes envoient des Terms corrigés. Si la carte de localisation n’indique pas qui est responsable de chaque couche, les changements entrent en conflit, et certains textes sont mis à jour à un endroit mais pas à un autre.