Comment construire un site web Next.js en 10 langues (Guide App Router 2026)

La création d'un site web multilingue est l'un des investissements les plus rentables que vous puissiez faire en matière de SEO et de conversion. Soixante-seize pour cent des acheteurs en ligne préfèrent acheter des produits dont les informations sont dans leur langue maternelle (CSA Research, 2020), pourtant moins de 5 % des sites web actifs prennent en charge plus de trois langues. Nous avons récemment lancé Frida Marketing en 10 langues sur Next.js 15 App Router — sans next-intl, sans SaaS de traduction, et sans 10 bases de code distinctes. Voici exactement comment nous l'avons construit.

Points Clés

• 76 % des acheteurs préfèrent acheter dans leur langue maternelle ; 40 % n'achèteront jamais sur des sites qui ne l'offrent pas (CSA Research, 2020)
• L'anglais ne couvre que 49,7 % du contenu web mondial — la création multilingue débloque les 50,3 % restants (W3Techs, juin 2026)
• Un segment dynamique [lang] + un calcul de préfixe d'API servent 10 langues à partir d'un seul ensemble de fichiers de page
• Gemini 2.5 Flash traduit un article HTML complet de 3 000 mots par langue en moins de 90 secondes à un coût quasi nul

Pourquoi la création multilingue est moins chère que vous ne le pensez

L'argument du coût contre les sites multilingues est presque toujours exagéré. Next.js 15 App Router gère l'intégralité de la couche de routage via un segment dynamique unique. La couche de contenu — titres, corps, métadonnées — provient de votre API par langue. Et la couche de traduction peut être entièrement automatisée.

L'anglais représente 49,7 % de tout le contenu des sites web par langue. L'espagnol et l'allemand détiennent chacun 6,0 %, le japonais 5,0 % et le français 4,6 % (W3Techs, juin 2026). Le support des cinq principales langues non-anglaises à lui seul couvre environ 70 % du contenu web mondial indexé. Next.js est utilisé sur 2,7 % de tous les sites web dans le monde et 17,9 % des développeurs interrogés l'utilisent (Stack Overflow Developer Survey, 2024) — ce qui signifie que les outils et le support communautaire pour Next.js multilingue n'ont jamais été aussi bons.

Le vrai coût n'est pas le code — c'est le contenu. Une fois votre routage en place, l'ajout d'une langue est un appel API par article publié. Nous avons publié 7 articles dans 10 langues sans aucun coût de maintenance par langue. La décision architecturale est l'investissement ; l'exécution est gratuite.

96 % des entreprises ayant investi dans la localisation ont déclaré un ROI positif, 65 % ayant atteint un retour d'au moins 3x (DeepL Business Survey, 2024). Le cas commercial est solide. La barrière technique est bien plus basse que ce que la plupart des développeurs attendent.

Comment structurer votre segment dynamique [lang]

Next.js App Router transforme votre système de fichiers en votre routeur. Créez un répertoire src/app/[lang]/ et chaque route à l'intérieur de celui-ci obtient params.lang automatiquement. Ce paramètre unique est la base de tout un site en 10 langues.

`` src/app/ ├── page.tsx ← English homepage (/) ├── blog/[slug]/page.tsx ← English blog posts ├── admin/layout.tsx ← English admin └── [lang]/ ├── page.tsx ← All other language homepages (/fi, /fr, /de…) ├── blog/[slug]/page.tsx ← Language blog posts └── admin/ └── layout.tsx ← Language admin (same file, reads params.lang) ``

L'anglais réside à la racine. Chaque autre langue réside sous [lang]. Vous écrivez un seul fichier et laissez params.lang piloter la logique — jamais de copies de pages spécifiques à une langue.

Définissez votre configuration linguistique dans un fichier canonique :

```typescript // src/lib/languages.ts export const LANGUAGES = [ { code: 'fi', urlPrefix: 'fi', apiPrefix: 'fi_', name: 'Finnish' }, { code: 'fr', urlPrefix: 'fr', apiPrefix: 'fr_', name: 'French' }, { code: 'de', urlPrefix: 'de', apiPrefix: 'de_', name: 'German' }, { code: 'it', urlPrefix: 'it', apiPrefix: 'it_', name: 'Italian' }, { code: 'no', urlPrefix: 'no', apiPrefix: 'no_', name: 'Norwegian' }, { code: 'ch', urlPrefix: 'ch', apiPrefix: 'pt_', name: 'Swiss German' }, // ⚠️ API uses pt_ { code: 'sr', urlPrefix: 'sr', apiPrefix: 'sr_', name: 'Serbian' }, { code: 'es', urlPrefix: 'es', apiPrefix: 'es_', name: 'Spanish' }, { code: 'sw', urlPrefix: 'sv', apiPrefix: 'sw_', name: 'Swedish' }, // ⚠️ URL uses sv ];

export const LANG_CODES = LANGUAGES.map(l => l.code); ```

Deux particularités à documenter immédiatement : ch (allemand suisse) utilise pt_ comme préfixe d'API pour des raisons de nommage historiques, et sw (suédois) utilise sv comme préfixe d'URL pour correspondre à la norme ISO. Ces incohérences ne causeront pas de bugs si vous centralisez la configuration, mais elles dérouteront tout développeur rejoignant le projet sans cette documentation.

Connecter les routes linguistiques à votre API backend

L'intégration complète de l'API multilingue est un seul calcul :

``typescript const prefix = params.lang ? ${params.lang}_ : ''; const posts = await fetch(${API_URL}/api/${prefix}posts); ``

Lorsque params.lang est 'fi', cela récupère /api/fi_posts. Lorsque c'est undefined (racine anglaise), cela récupère /api/posts. Chaque page, chaque appel de données, chaque opération d'administration utilise ce même modèle. Il n'y a pas d'aide de récupération par langue, pas d'instruction switch, pas de cas particulier.

Nous appliquons ce modèle à 10 langues et 5 types de contenu — articles, produits, pages, auteurs et catégories — en production. Le seul cas limite que nous avons rencontré : certains points d'API ont des structures différentes pour l'anglais par rapport aux versions spécifiques à la langue. Dans notre configuration, /api/{lang}_posts/by-url/{slug} existe pour chaque langue, mais l'équivalent anglais est un contrôleur complètement différent (/api/resolve-route?url=...). Vérifiez toujours vos routes d'API anglaises séparément — elles sont souvent structurées différemment des routes spécifiques à la langue, surtout sur les backends Laravel où les routes anglaises ont été construites en premier.

Le panneau d'administration utilise le même modèle de préfixe :

``typescript // src/app/[lang]/admin/posts/page.tsx export default function AdminPostsPage({ params }: { params: { lang?: string } }) { const prefix = params.lang ? ${params.lang}_ : ''; // Fetch from /api/${prefix}posts // Build edit/delete links with /${params.lang}/admin/edit-post/${id} } ``

Un seul composant AdminPostsPage dessert les 10 panneaux d'administration linguistiques. L'administration anglaise se trouve à /admin/posts ; l'administration finnoise à /fi/admin/posts. Même fichier.

Génération de pages statiques pour les 10 langues

La génération statique est l'endroit où les sites Next.js multilingues obtiennent leur avantage de performance. Utilisez generateStaticParams pour pré-rendre chaque variante linguistique au moment de la construction :

```typescript // src/app/[lang]/page.tsx — static language homepages export async function generateStaticParams() { return LANG_CODES.map(lang => ({ lang })); // Returns: [{lang:'fi'},{lang:'fr'},{lang:'de'},...] }

// src/app/[lang]/blog/[slug]/page.tsx — static blog posts per language export async function generateStaticParams({ params }: { params: { lang: string } }) { const prefix = params.lang ? ${params.lang}_ : ''; const res = await fetch(${API_URL}/api/${prefix}posts); const data = await res.json(); return data.data.map((post: { url: string }) => ({ slug: post.url })); } ```

Les pages statiques apparaissent comme ● dans la sortie de next build. Elles sont pré-rendues en HTML au moment du déploiement, poussées vers le CDN edge de Vercel et se chargent en millisecondes globalement. Pour un site en 10 langues, c'est la différence entre un TTFB de 50 ms et un accès à l'origine de 800 ms sur chaque requête.

Une règle à mémoriser : ne jamais combiner generateStaticParams avec des récupérations { cache: 'no-store' } sur la même page. Dans les builds de production de Next.js 15, cela génère Error: Page changed from static to dynamic at runtime — un bug qui n'apparaît qu'en production, pas en développement. Utilisez plutôt l'ISR :

``typescript const res = await fetch(${API_URL}/api/${prefix}posts, { next: { revalidate: 3600 }, // Regenerate stale pages every hour }); export const dynamicParams = true; // Allow new slugs without a full rebuild ``

next-intl enregistre 2,3 millions de téléchargements npm hebdomadaires en juin 2026, ce qui en fait la bibliothèque dominante dans ce domaine. C'est le bon choix si vous avez besoin d'un formatage sensible à la locale ou d'une gestion de chaînes d'interface utilisateur codées en dur. Pour les sites CMS basés sur les données, c'est facultatif — le routage pur de l'App Router gère tout ce dont vous avez réellement besoin.

SEO pour un site en 10 langues : Hreflang et generateMetadata

Hreflang indique à Google quelle version linguistique servir à quel public. Sans cela, vos 10 pages linguistiques se concurrencent pour les mêmes requêtes. L'implémentation de l'App Router est propre :

```typescript // src/lib/hreflang.ts const HREFLANG_CODE: Record = { fi: 'fi', fr: 'fr', de: 'de', it: 'it', no: 'no', ch: 'de-CH', // Swiss German internal code → BCP 47 de-CH sr: 'sr', es: 'es', sw: 'sv', // Internal code sw → ISO sv (Swedish) };

export function getAlternates(routeKey: string, lang?: string) { const BASE = 'https://fridamarketing.com'; const enUrl = ${BASE}/${routeKey};

const languages: Record = { 'x-default': enUrl, en: enUrl, };

for (const [code, hreflang] of Object.entries(HREFLANG_CODE)) { const urlPrefix = code === 'sw' ? 'sv' : code; languages[hreflang] = ${BASE}/${urlPrefix}/${routeKey}; }

return { canonical: lang ? ${BASE}/${lang === 'sw' ? 'sv' : lang}/${routeKey} : enUrl, languages, }; } ```

Utilisez-le dans generateMetadata sur chaque page :

``typescript export async function generateMetadata({ params }: Props): Promise { const post = await fetchPost(params.lang, params.slug); return { title: post.meta_title, description: post.meta_description, alternates: getAlternates(blog/${post.url}, params.lang), }; } ``

Ceci génère un ensemble hreflang complet pour chaque page — x-default, en, et les 9 variantes linguistiques — sans aucune maintenance manuelle. Pas de blocs hreflang de sitemap XML à synchroniser ; Next.js les injecte comme balises dans le rendu.

Selon la recherche en SEO multilingue, les entreprises investissant dans la localisation constatent 300 à 500 % de trafic organique en plus provenant des marchés internationaux (MotionPoint, 2025). La couche hreflang est ce qui capte ce trafic. Sans elle, Google ignore les signaux linguistiques ou affiche la mauvaise version pour chaque locale.

Automatisation de la traduction : l'API Gemini dans votre pipeline de publication

La traduction manuelle en 10 langues est le mauvais modèle pour toute équipe sans budget de localisation dédié. La traduction humaine coûte entre 0,15 $ et 0,30 $ par mot — un article de 2 500 mots coûte entre 375 $ et 750 $ par langue, soit entre 3 375 $ et 6 750 $ pour les 9 (Seatongue, 2025). La post-édition de traduction automatique réduit ce coût de 50 à 70 %. Mais pour le contenu HTML structuré d'un CMS, une traduction API entièrement automatisée avec une invite précise est encore meilleure.

Voici l'appel de traduction principal que nous utilisons avec Gemini 2.5 Flash :

``javascript async function translatePost(content, targetLang) { const prompt = Translate the following JSON to ${targetLang}. Rules: - Translate all text values: title, intro, body, meta_title, meta_description - Preserve ALL HTML tags, attributes, and structure in body exactly as-is - Generate a URL-safe localized slug and return it as "url" - Keep brand names, code examples, and proper nouns in English - Return valid JSON only: { title, intro, body, meta_title, meta_description, url }

Content: ${JSON.stringify(content)}`;

const response = await gemini.generateContent(prompt); return JSON.parse(response.text()); } ```

Nous avons utilisé cela en production pour 7 articles publiés, chacun traduit automatiquement en 9 langues. La qualité est prête pour la publication pour le finnois, le français, l'allemand, l'espagnol et l'italien sans révision manuelle. Le norvégien et le suédois nécessitent des vérifications ponctuelles occasionnelles. Le serbe nécessite une relecture — Gemini est moins fiable avec le cyrillique dans des contextes HTML complexes. Pour un site à fort contenu, cette approche réduit les frais de traduction de plus de 90 % par rapport même aux flux de travail de post-édition de traduction automatique.

Le timing est important. Un article HTML de 3 000 mots prend à Gemini 2.5 Flash environ 60 à 90 secondes par langue. Cela représente 9 à 13 minutes pour les 9 traductions. Définissez toujours un délai d'expiration d'annulation de 150 secondes sur chaque appel API et implémentez une temporisation exponentielle — le modèle se bloque occasionnellement en cas de forte demande :

``javascript const controller = new AbortController(); const timeoutId = setTimeout(() => controller.abort(), 150000); try { const res = await fetch(GEMINI_URL, { signal: controller.signal, ...opts }); clearTimeout(timeoutId); return res; } catch (err) { clearTimeout(timeoutId); if (err.name === 'AbortError') { // Retry with exponential backoff await new Promise(r => setTimeout(r, Math.pow(2, attempt) * 5000)); } } ``

84 % des spécialistes du marketing affirment que la localisation de contenu a contribué à augmenter leurs revenus, et les entreprises qui ont investi dans la traduction étaient 1,5 fois plus susceptibles de constater une augmentation de leurs revenus (Redokun, 2025). L'automatisation supprime le dernier véritable obstacle — le coût opérationnel de l'exécution des traductions à grande échelle.

---

Vous construisez un site Next.js multilingue ? Nous concevons et construisons des sites web Next.js pour des audiences mondiales — routage i18n complet, SEO hreflang et pipelines de traduction automatisés inclus. Découvrez nos services de développement Next.js ou contactez-nous pour discuter de votre projet.

---

Foire Aux Questions

Ai-je besoin de next-intl pour construire un site Next.js multilingue ?

Non. Next.js 15 App Router gère le routage multilingue nativement via un segment dynamique [lang]. Des bibliothèques comme next-intl ajoutent de la valeur pour le formatage sensible à la locale (dates, devises, pluralisation) et la gestion des chaînes d'interface utilisateur codées en dur. Si votre contenu provient d'un CMS ou d'une API, vous n'en avez pas besoin pour le routage, la génération statique ou le SEO.

Comment mapper les préfixes de langue d'URL aux points d'API dans Next.js ?

Calculez un préfixe à l'exécution : const prefix = params.lang ? \`${params.lang}_\` : '';. Utilisez-le dans chaque appel de récupération — par exemple, /api/${prefix}posts. Ce modèle gère les 10 langues à partir d'un seul fichier de page partagé. Pas de pages spécifiques à une langue, pas d'instructions switch, pas de cas particuliers.

Quelle est la meilleure façon de traduire automatiquement un site Next.js en plusieurs langues ?

Utilisez Gemini 2.5 Flash ou GPT-4 dans votre pipeline de publication. Envoyez le contenu anglais sous forme de JSON avec une invite système pour traduire toutes les valeurs textuelles tout en préservant les balises HTML et en générant un slug d'URL localisé. Ajoutez un délai d'expiration de 150 secondes et une temporisation exponentielle. La post-édition de traduction automatique coûte 50 à 70 % moins cher qu'une traduction humaine complète (Seatongue, 2025), et l'automatisation complète de l'API réduit encore ce coût.

Comment ajouter des balises hreflang à un site Next.js 15 App Router ?

Créez une fonction getAlternates(routeKey, lang) qui renvoie un objet alternates de Next.js. Mappez les codes d'URL internes aux codes de langue BCP 47 — sw → sv pour le suédois, ch → de-CH pour l'allemand suisse — et incluez x-default pointant vers le canonique anglais. Retournez-le depuis alternates.languages à l'intérieur de l'export generateMetadata de chaque page.

Combien de langues mon site web devrait-il prendre en charge ?

Commencez par 2 à 3 qui correspondent à vos principales sources de trafic, puis étendez. L'anglais ne couvre que 49,7 % du contenu web mondial (W3Techs, juin 2026), donc toute deuxième langue ouvre une nouvelle audience adressable avec un coût marginal quasi nul une fois votre routage et votre pipeline de traduction en place. Les entreprises investissant dans la localisation déclarent un ROI positif de 96 %, 65 % atteignant un retour d'au moins 3x (DeepL, 2024).

Conclusion

Un site Next.js en 10 langues n'est pas 10 fois plus de travail. C'est un segment dynamique [lang], un calcul de préfixe d'API, un aide hreflang et un script de traduction — multipliés à travers votre pipeline de publication. Nous l'avons construit pour Frida Marketing et il fonctionne en production dans 10 langues sans frais de maintenance par langue et sans abonnement à un SaaS de localisation.

Le routage est le travail d'une matinée. Le hreflang est celui d'un après-midi. Le pipeline de traduction est un projet de week-end. Et le gain — atteindre les 50,3 % du web qui ne sont pas en anglais — est permanent.

Commencez par le segment [lang] aujourd'hui. Ajoutez le hreflang cette semaine. Connectez l'API de traduction Gemini ce mois-ci.