# General Translation Knowledge Base: Build, exécution ou proxy de traduction : comment livrer vos traductions ? URL: https://generaltranslation.com/fr/kb/build-time-vs-runtime-translation.mdx Docs index: https://generaltranslation.com/llms.txt Description: Utilisez General Translation pour générer les traductions connues de votre application avant la livraison, puis intégrez-les au bundle de votre code ou chargez-les depuis son CDN. Les bundles lient le texte à une livraison donnée ; les modifications publiées sur le CDN peuvent s’appliquer aux nouveaux rendus sans redéploiement du code. Utilisez la traduction à la requête pour le contenu dont un visiteur a besoin immédiatement, et un proxy lorsque vous ne pouvez pas modifier le code du site. Category: Internationalisation Last updated: 2026-11-12 Authors: Jackie Chen Published: 2026-11-12 Il existe quatre grandes façons de faire parvenir une traduction à un visiteur. Elle peut être intégrée au bundle de votre application lors du build, chargée depuis un réseau de diffusion de contenu (CDN) au moment de l’affichage de la page, traduite par une API pendant le traitement de la requête, ou insérée dans votre HTML par un proxy ou un script placé en amont de votre site. Ce choix détermine les dépendances de votre application en production, la manière dont une traduction corrigée parvient aux utilisateurs, et la capacité des moteurs de recherche à indexer chaque langue. Distinguez la génération d’une traduction de son chargement. Un CDN sert des traductions déjà générées ; il n’a pas besoin d’appeler un modèle d’IA à chaque visite. Pour les textes de l’application connus avant le déploiement, générez les traductions à l’avance et servez-les depuis le bundle ou un CDN. Le contenu ajouté par la suite peut être traduit au moment de sa publication ou dans une tâche en arrière-plan ; réservez la traduction à la requête aux cas où un visiteur a besoin d’un résultat immédiat. Un proxy convient aux sites dont vous ne pouvez pas, ou ne souhaitez pas, modifier le code. ## Comment les approches de livraison se comparent-elles ? | Approche | Fonctionnement | Dépendances en Production | Comment une traduction corrigée parvient aux utilisateurs | Cas d’usage | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | Intégration au bundle lors du build | Les fichiers de traduction sont générés avant la compilation et importés par paramètre régional | Rien d’autre que votre application | Au prochain déploiement | La plupart des applications, y compris les pages statiques, ISR et server-rendered | | Chargement depuis un CDN à l’exécution | L’application récupère les traductions générées pour chaque paramètre régional | Le CDN | Publiez la modification, puis actualisez les caches de traduction et de page ; le HTML entièrement statique doit être recompilé | Applications dont les relecteurs corrigent les textes entre deux livraisons | | Traduction à la requête | Le serveur demande le texte à une API de traduction pendant le traitement de la requête | L’API de traduction, pour les requêtes qui affichent du texte non traduit | Chaque requête traduit ce qu’elle affiche, à partir du texte et du contexte que vous envoyez | Traduction immédiate de publications d’utilisateurs, de réponses du support ou de contenus générés par IA | | Proxy ou surcouche par script ([Weglot](https://weglot.com/technical-presentation/), [Transifex Live](https://help.transifex.com/en/articles/6244596-introduction-to-transifex-live)) | Un proxy sert du HTML traduit ; une surcouche remplace le texte dans le navigateur | Le service de livraison du fournisseur, soumis à la mise en cache | Modifiée dans le tableau de bord du fournisseur, puis servie via sa couche de livraison | Sites finalisés que vous ne souhaitez pas modifier ; sites marketing | Optez pour l’intégration au bundle lors du build si vous souhaitez que le code et les textes soient relus et livrés ensemble. Choisissez un CDN si les relecteurs doivent pouvoir publier des corrections de texte entre deux livraisons de l’application. Par exemple, corriger le libellé allemand d’un bouton peut mettre à jour une application chargée depuis un CDN sans recompilation ; en revanche, ajouter un nouveau bouton nécessite toujours de déployer le composant. La génération à la requête ajoute de la latence par rapport à la lecture d’une traduction déjà prête : faites donc passer les textes connus de l’interface par le circuit prétraduit. ## Quelle approche privilégier pour le SEO ? Attribuez à chaque langue une URL stable et explorable, comme `/es/pricing`, et renvoyez le contenu traduit et les métadonnées à cette URL. Les pages server-rendered et générées statiquement le permettent, avec des traductions intégrées au bundle ou chargées depuis un CDN ; un proxy par sous-répertoire de langue le permet également. Google [recommande des URL distinctes pour chaque version linguistique](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites). Il sait [afficher le JavaScript](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics), mais une surcouche qui ne change la langue d'une URL qu'une fois que le visiteur a cliqué sur un sélecteur de langue ne fournit pas de pages distinctes par langue à explorer. Le [guide SEO multilingue pour Next.js](/kb/multilingual-nextjs-seo) traite de hreflang et des métadonnées. ## Quelle est la différence entre l'i18n avec rendu en périphérie et un proxy de traduction ? Avec l'i18n avec rendu en périphérie, votre application génère du HTML traduit sur un environnement d'exécution en périphérie (edge), à partir de ses propres routes et traductions. Un middleware de paramètres régionaux ne suffit pas à lui seul à assurer le rendu de la page en périphérie : l'environnement d'exécution du rendu relève d'un choix distinct de framework et d'hébergement. Vous gardez la maîtrise des routes localisées, du contenu rendu et de la mise en cache. Un proxy traduit la sortie plutôt que la source. Le [proxy inverse de Weglot](https://weglot.com/technical-presentation/) traduit chaque page au moment où elle est transmise au visiteur, met en cache les requêtes répétées et prend en compte le nouveau contenu au fur et à mesure qu'il est servi ; c'est dans son tableau de bord que vous modifiez les formulations. Le [guide pour les sites web](/kb/make-website-multilingual) en détaille la configuration initiale. Cette approche fonctionne avec un serveur d'origine qui renvoie son contenu sous forme de HTML, statique ou server-rendered. Le texte généré uniquement par le JavaScript côté navigateur est absent de la réponse de ce serveur d'origine. Un proxy voit la structure HTML rendue ; les composants source et les notes de contexte des développeurs ne lui sont pas transmis automatiquement. La [comparaison avec Weglot](/kb/general-translation-vs-weglot) présente les compromis de chaque approche. ## Comment fournir des traductions dans une application Next.js avec SSG, ISR ou SSR ? Générez les traductions avant la compilation : tous les modes de rendu pourront alors les utiliser. Avec `gt-next` de General Translation, exécutez [`npx gt translate`](/docs/cli/reference/commands/translate) avant `next build`. Le rendu côté serveur (SSR) peut prendre en compte une modification publiée sur le CDN lors d'un nouvel affichage, une fois les caches de traduction actualisés. La génération de sites statiques (SSG) intègre le texte traduit dans le HTML, qui reste inchangé jusqu'à une nouvelle compilation ou revalidation. Avec la régénération statique incrémentale (ISR), [la revalidation régénère ce HTML](https://nextjs.org/docs/app/guides/incremental-static-regeneration) ; une correction de formulation n'y apparaît qu'une fois le cache de traduction lui aussi mis à jour. Un export entièrement statique nécessite une nouvelle compilation. Pour prérendre une route par paramètre régional dans l'App Router, placez vos routes sous `app/[locale]` avec le middleware de paramètres régionaux de `gt-next`, puis renvoyez tous les paramètres régionaux depuis `generateStaticParams` : ```tsx title="app/[locale]/page.tsx" import { getLocales, T } from 'gt-next'; export function generateStaticParams() { return getLocales().map((locale) => ({ locale })); } export default function HomePage() { return Welcome to our site; } ``` Ceci suppose la configuration initiale du plugin et du fournisseur décrite dans le Démarrage rapide Next.js, un fichier `getLocale.ts` à la racine qui lit le paramètre `locale` racine, ainsi qu'un fichier `getRegion.ts` qui renvoie `undefined`. Consultez le [guide de génération statique avec l'App Router](/docs/react/nextjs/app-router-static-site-generation) pour connaître les versions de Next.js et les fichiers pris en charge. Le prérendu des routes dans un déploiement Next.js est différent de `output: 'export'`, qui nécessite en outre la configuration d'export statique décrite dans le guide. ## Comment traduire du contenu qui n'existe qu'à l'exécution ? Pour une note qui doit être traduite au moment où un visiteur l'ouvre, le composant [``](/docs/react/nextjs/reference/components/tx) et la fonction [`tx`](/docs/react/nextjs/reference/functions/tx) de General Translation appellent l'API de traduction depuis les composants serveur de l'App Router de Next.js. Dans cet exemple, on part du principe que le routage selon les paramètres régionaux est configuré et que `getNote` charge la note : ```tsx title="app/[locale]/notes/[id]/page.tsx" import { Tx } from 'gt-next/server'; import { getNote } from '@/lib/notes'; export default async function NotePage({ params, }: { params: Promise<{ id: string }>; }) { const { id } = await params; const note = await getNote(id); return {note.body}; } ``` En production, définissez `GT_API_KEY` côté serveur avec une clé de projet pour laquelle la **traduction à l’exécution** est activée, et ne l’exposez jamais au navigateur ([informations d’authentification de production](/docs/react/nextjs/config#credentials)). La traduction à la requête est facturée séparément de la traduction au moment du build ; consultez les [tarifs d’utilisation](https://generaltranslation.com/pricing/usage). En dehors des Composants serveur Next.js, par exemple dans une API Express, la fonction [`tx`](/docs/node/reference/functions/tx) de `gt-node` remplit le même rôle pour les chaînes. ## Comment General Translation livre-t-il les traductions ? General Translation génère les traductions à l'aide de sa CLI, puis votre application les récupère depuis l'un de ces deux emplacements : * **Fichiers locaux.** Définissez un chemin de sortie dans `gt.config.json`, exécutez [`npx gt translate`](/docs/cli/reference/commands/translate) avant la compilation et fournissez une fonction [`loadTranslations`](/docs/react/reference/functions/load-translations) qui importe chaque paramètre régional. Le rendu de ces traductions incluses dans le bundle n'envoie aucune requête à General Translation. [`gt init`](/docs/cli/reference/commands/init) recommande cette configuration (**Save locally**), et c'est la seule option disponible pour `gt-vue`. * **Le CDN de General Translation**, dans les SDK React et Next.js. Activez le CDN dans les paramètres de votre projet, exécutez [`npx gt translate --publish`](/docs/cli/reference/commands/translate) et fournissez au SDK votre [`projectId`](/docs/react/reference/config#project-id) sans loader local. Par défaut, le SDK charge les traductions depuis le CDN lorsqu'aucun loader local n'est configuré. La CLI enregistre la version source que la compilation doit charger. Les modifications publiées pour cette version peuvent apparaître dans les nouveaux rendus une fois les caches actualisés, sans redéployer le code de l'application. En revanche, les nouveaux textes sont toujours livrés avec le déploiement qui les introduit, et le HTML statique suit les règles de recompilation ou de revalidation décrites plus haut. La livraison via le CDN [est gratuite](https://generaltranslation.com/pricing/usage). Passer des fichiers locaux au CDN (ou inversement) ne nécessite qu'un changement de configuration ; vos composants restent inchangés. Le [guide sur le stockage des traductions](/docs/react/guides/storing-translations) présente le loader pour chaque framework React. ## Points clés * Générez les traductions connues de l'application avant de déployer. Intégrez-les au bundle de la livraison, ou chargez-les depuis un CDN si des corrections de formulation doivent apparaître dans les nouveaux rendus entre deux livraisons. * Traduisez le nouveau contenu dès sa publication, dans une tâche en arrière-plan ou à la demande, selon le moment où les utilisateurs en ont besoin. Conservez les clés de l'API de traduction côté serveur. * Un proxy ajoute des langues sans modifier le code, mais il traduit le HTML rendu et dépend du fournisseur pour chaque affichage d'une page traduite. * General Translation sert les mêmes composants [``](/docs/react/reference/components/t) depuis des fichiers locaux ou depuis son CDN, et ajoute [``](/docs/react/nextjs/reference/components/tx) pour le contenu traduit au moment de la requête. Commencez par le [Démarrage rapide Next.js](/docs/react/nextjs-quickstart). ## Related questions - [Comment rendre un site web multilingue ?](https://generaltranslation.com/fr/kb/make-website-multilingual.mdx): Choisissez où stocker les traductions (dans un proxy, un plugin de CMS, un constructeur de sites ou votre propre code), puis attribuez à chaque langue sa propre URL, comme le recommande Google. Traduisez les pages entières ainsi que les titres et les méta-descriptions, reliez les versions avec hreflang et proposez un sélecteur de langue plutôt que de rediriger automatiquement les visiteurs. - [Comment configurer le SEO d’une application Next.js multilingue ?](https://generaltranslation.com/fr/kb/multilingual-nextjs-seo.mdx): Attribuez à chaque langue sa propre URL préfixée, comme /en/about et /es/about, puis publiez html lang, une URL canonique autoréférente, des variantes localisées hreflang avec x-default, un titre et une description traduits, ainsi qu’une entrée de plan de site pour chaque langue publiée. Marquez les versions non publiées en noindex. Le package gt-next de General Translation associe chaque langue à sa propre URL et traduit les titres avec getGT. - [Quel est le meilleur outil de localisation continue pour les équipes qui livrent chaque jour ?](https://generaltranslation.com/fr/kb/best-continuous-localization-tools.mdx): Choisissez General Translation pour traduire les nouveaux textes avant chaque compilation, en s’appuyant sur le contexte du JSX balisé et sur une terminologie produit partagée. Votre équipe relit et corrige les formulations dans le tableau de bord, et Locadex ouvre des pull requests pour baliser les nouveaux textes d’IU à traduire. Vous pouvez adopter ce workflow tout en conservant votre configuration i18next ou next-intl existante. - [Alternatives à Weglot : General Translation vs Weglot](https://generaltranslation.com/fr/kb/general-translation-vs-weglot.mdx): Weglot est un service de traduction de sites web qui traduit les pages affichées via des plugins, un snippet ou un proxy, et Weglot 2.0 ajoute des flux de travail de traduction JSON dans GitHub. General Translation est une plateforme de localisation qui combine l’internationalisation du code source, la traduction de fichiers, un contexte partagé, la relecture dans le tableau de bord et le routage selon les paramètres régionaux. - [Redirections linguistiques et SEO : URL, cookie ou Accept-Language ?](https://generaltranslation.com/fr/kb/locale-routing-seo.mdx): Laissez l’URL déterminer la langue de chaque page que vous souhaitez faire indexer, car Googlebot n’envoie aucun en-tête Accept-Language et explore principalement depuis des adresses américaines. Ne vous servez du choix enregistré dans un cookie, puis d’Accept-Language, que pour décider vers où redirige une racine neutre comme /, avec une redirection temporaire 302 ou 307. ## Previous and next questions - Previous question: [Agent de codage IA ou pipeline de traduction : lequel doit automatiser votre localisation ?](https://generaltranslation.com/fr/kb/ai-coding-agent-vs-translation-pipeline.mdx) - Next question: [Quel est le meilleur outil de localisation continue pour les équipes qui livrent chaque jour ?](https://generaltranslation.com/fr/kb/best-continuous-localization-tools.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/fr/kb/sitemap.md) for every article.