Comment rendre un site Next.js multilingue avec next-intl : retour d'expérience

Cet article fait partie de la série "Refonte de site web avec l'IA". Si vous n'avez pas lu le premier épisode, commencez par là.

Le problème

Mon site était 100% en français. Pas de sélecteur de langue, pas de structure multilingue, rien. Pourtant, une bonne partie de mon réseau professionnel est anglophone, et mes origines brésiliennes me poussaient depuis longtemps à ajouter le portugais.

L'internationalisation d'un site Next.js App Router, c'est le chantier que tout le monde repousse. Et pour cause : ça touche absolument tout. Les routes, les layouts, les métadonnées, les composants, le contenu. Chaque fichier est impacté.

Le socle technique : next-intl et le middleware

Première étape : installer next-intl et créer l'infrastructure de routing multilingue. Claude Code a généré le middleware.ts avec la détection automatique de la langue du navigateur et la redirection vers la locale appropriée. Il a créé le fichier i18n/routing.ts pour configurer les locales (fr, en, pt) avec le français comme langue par défaut, ainsi que i18n/request.ts pour le chargement dynamique des fichiers de traduction selon la locale active.

La migration de toutes les routes

C'est la partie la plus délicate. Chaque page du site a dû être déplacée dans un dossier app/[locale]/. La page d'accueil app/page.tsx est devenue app/[locale]/page.tsx. La page blog app/blog/page.tsx est devenue app/[locale]/blog/page.tsx. Et ainsi de suite pour chaque route du site.

Mais ce n'est pas un simple déplacement de fichiers. Chaque page devait être modifiée pour recevoir le paramètre locale depuis les props, utiliser useTranslations() ou getTranslations() pour les textes, et générer des métadonnées SEO dans la bonne langue.

Plus de 385 clés de traduction par langue

Claude Code a créé trois fichiers de traduction complets : messages/fr.json, messages/en.json et messages/pt.json. Chacun contient plus de 385 clés couvrant la navigation (menu principal, liens, breadcrumbs), les pages de service (Sprint, SaaS, Labs avec chaque section, titre et paragraphe), la page d'accueil (hero, services, témoignages, FAQ), le blog (filtres, catégories, temps de lecture, pagination), le SEO (title, description, OpenGraph pour chaque page) et toute l'interface utilisateur (boutons, formulaires, page 404, footer).

Le tout cohérent entre les trois langues, pas du mot-à-mot mais une vraie localisation adaptée à chaque culture.

Le LanguageSwitch

Un composant dans le footer qui permet de basculer entre les langues. Simple en apparence, mais avec une subtilité technique : quand vous êtes sur un article de blog, le switch doit vous amener vers la version traduite de cet article (si elle existe) plutôt que vers la page d'accueil de la langue cible.

Claude Code a implémenté un système de résolution de slugs alternatifs via un AlternatePathProvider qui track la correspondance entre les articles et leurs traductions.

Le piège des slugs multilingues

Un problème qu'on ne voit pas venir : certains articles ont des slugs différents selon la langue. Quand vous êtes sur /fr/blog/2022/thibault-jaime et que vous passez en anglais, l'URL doit devenir /en/blog/2022/thibault-jaime. Mais que faire si le fichier anglais a un slug différent ?

Claude Code a résolu ça en ajoutant un système de détection qui cherche le fichier .en.mdx ou .pt.mdx correspondant au même id dans le frontmatter, quelle que soit la convention de nommage du fichier.

Le résultat

Chaque page du site est désormais accessible en 3 langues, avec des URLs propres (/fr/blog/..., /en/blog/..., /pt/blog/...), des métadonnées SEO localisées pour chaque page et chaque langue, une détection automatique de la langue du navigateur, une navigation fluide entre les versions linguistiques, et un filtrage du contenu par locale pour que chaque visiteur ne voie que les articles dans sa langue.

Le tout sans casser aucune URL existante grâce aux redirections du middleware.

Le temps passé

Ce chantier i18n a représenté environ 2 heures de travail effectif. Pour mettre ça en perspective : la dernière fois que j'ai fait une internationalisation from scratch sur un projet Next.js, ça m'avait pris une semaine entière.

La différence ? Je n'ai pas eu à écrire une seule clé de traduction manuellement. Je n'ai pas eu à migrer les routes fichier par fichier. Je n'ai pas eu à débugger les edge cases du middleware un par un. Claude Code a fait tout ça, et moi je reviewais et je guidais.

Demain, on passe à un autre genre de défi : transformer 13 épisodes de podcast en 50 articles de blog. Comment une IA peut-elle recycler vos podcasts en contenu SEO de qualité ? La réponse pourrait vous surprendre.