Introduction à l’internationalisation (i18n)

1. Pourquoi internationaliser son application ?

Dans un contexte numérique où les utilisateurs proviennent de différents horizons culturels et linguistiques, l’internationalisation, souvent abrégée i18n, constitue une étape incontournable. Elle consiste à préparer une application pour qu’elle puisse s’adapter facilement à plusieurs langues et formats régionaux, sans nécessiter de refonte structurelle.

L’enjeu n’est pas uniquement de traduire quelques chaînes de texte. Il s’agit d’offrir une expérience complète qui respecte les préférences de l’utilisateur : affichage de l’interface dans sa langue, formats de date et de monnaie adaptés, et parfois même gestion de variantes culturelles au sein d’une même langue. Une telle approche améliore considérablement l’accessibilité et la perception de qualité d’un projet.

Next.js propose un support intégré pour les routes localisées, ce qui signifie qu’il peut générer automatiquement des chemins distincts selon la langue active (par exemple /fr/ pour le français, /en/ pour l’anglais). En revanche, il ne fournit pas directement de mécanisme de traduction du contenu. Pour gérer cette partie, il est nécessaire d’intégrer une bibliothèque complémentaire telle que next-intl ou i18next. Ces outils assurent la définition, le chargement et l’utilisation des messages traduits dans les composants de l’application.

En résumé, internationaliser son application permet :

de toucher une audience...

Intégration de next-intl et architecture App Router

1. Ajout du provider global dans app/[locale]/layout.tsx

L’étape suivante consiste à intégrer les fichiers de traduction dans l’application. Avec l’App Router, la gestion des langues passe par la création d’un segment dynamique [locale] dans l’arborescence du dossier app/. Ce paramètre d’URL permet d’indiquer la langue en cours et de charger automatiquement les messages correspondants.

Pour que les traductions soient accessibles à l’ensemble des composants enfants, il faut envelopper l’application dans un provider fourni par next-intl. Celui-ci met à disposition les messages traduits via le contexte React, permettant aux composants de récupérer facilement les textes localisés.

Exemple d’implémentation :

// app/[locale]/layout.tsx 
import { NextIntlClientProvider, useMessages } from 'next-intl'; 
 
export default function LocaleLayout({ 
  children, 
  params: { locale }, 
}: {
  children: React.ReactNode; 
  params: { locale: string }; 
}) {
  const messages = useMessages(); 
 
  return (
    <html lang={locale}> 
      <body> 
        <NextIntlClientProvider locale={locale} messages={messages}> 
          {children} ...

Redirections automatiques et expérience multilingue

1. Middleware pour la détection automatique de langue

L’internationalisation ne se limite pas à la simple mise à disposition de routes localisées. Dans de nombreux projets, il est pertinent d’aller plus loin en redirigeant automatiquement l’utilisateur vers la langue la plus appropriée dès son arrivée sur le site. Cette logique peut s’appuyer sur différents critères, le plus courant étant l’en-tête HTTP Accept-Language envoyé par le navigateur.

Next.js permet d’implémenter ce type de comportement au moyen d’un middleware. Positionné à la racine du projet, ce dernier intercepte chaque requête avant que la page cible ne soit servie, ce qui le rend particulièrement adapté pour décider de la locale à appliquer.

Le principe est le suivant :

on vérifie si l’URL demandée contient déjà une locale connue (/fr, /en, etc.) ;
si ce n’est pas le cas, on détermine la langue préférée de l’utilisateur à partir de ses en-têtes ;
enfin, on redirige vers la version correspondante de la route.

Exemple d’implémentation minimaliste avec next-intl :

// middleware.ts 
import { NextResponse } from 'next/server'; 
import...

Localisation complète des routes et du contenu

1. Objectif : une expérience multilingue cohérente

L’internationalisation d’une application ne s’arrête pas à la traduction de l’interface utilisateur. Pour offrir une expérience réellement cohérente et convaincante, il est nécessaire d’aller plus loin et de veiller à ce que tous les aspects du parcours utilisateur soient localisés. Cela inclut non seulement les textes affichés dans l’interface, mais également :

les segments d’URL, qui doivent refléter la langue active afin de renforcer la compréhension et d’optimiser le référencement naturel (par exemple /en/about pour l’anglais contre /fr/a-propos pour le français) ;
les pages dynamiques telles que les articles de blog ou les fiches produits, dont les contenus doivent être chargés et présentés dans la langue du visiteur ;
les titres, métadonnées et contenus récupérés côté serveur, qui doivent être adaptés au contexte linguistique pour garantir une continuité dans l’expérience.

L’objectif est donc de mettre en place une architecture où les routes, les liens et les données sont pleinement intégrés dans la logique multilingue, afin d’assurer une expérience homogène dans toutes les langues supportées par l’application.

2. Traduction des segments de routes

Par défaut, Next.js ne traduit pas automatiquement les segments d’URL. Autrement dit, si une application dispose d’une page /about, celle-ci sera accessible sous le même chemin quel que soit le paramètre de langue. Or, dans une perspective de localisation complète et de SEO optimisé, il est souvent préférable que les segments reflètent la langue courante, par exemple :

/fr/a-propos pour la version française ;
/en/about pour la version anglaise.

Approche simple : une arborescence par langue

La méthode la plus directe consiste à créer une arborescence de fichiers distincte pour chaque langue :

/app 
  ├── fr 
  │   └── a-propos/page.tsx ...

Formatage dynamique des données (dates, nombres, langues)

1. Pourquoi formater dynamiquement ?

Traduire une interface utilisateur ne suffit pas à rendre une application réellement internationale. Une expérience cohérente passe aussi par l’adaptation des formats de données en fonction de la langue et de la culture de l’utilisateur.

En effet, ce que l’on perçoit comme une convention universelle est souvent une habitude locale :

Dates : en France, le 1^er septembre 2025 s’écrit 01/09/2025, alors qu’aux États-Unis, il devient 09/01/2025.
Nombres et devises : un prix peut s’afficher 1 000,50 € en français, contre $1,000.50 en anglais américain.
Langues : un menu déroulant indiquera « français » pour un utilisateur francophone, mais « French » pour un anglophone.

Ces détails, qui peuvent sembler mineurs, contribuent en réalité fortement à la crédibilité et à la fluidité d’une application. Une interface qui affiche des formats non adaptés peut créer de la confusion, voire décrédibiliser le produit aux yeux d’un utilisateur international.

C’est pourquoi le formatage dynamique, basé sur la locale active, constitue un pilier de l’internationalisation. Une application qui gère correctement les conventions locales renforce non seulement son professionnalisme, mais aussi la confiance des utilisateurs, ce qui est essentiel pour toute solution destinée à un public global.

2. Utilisation de next-intl pour le formatage

Le formatage localisé repose sur l’API standard Intl de JavaScript, qui fournit des méthodes puissantes pour adapter dynamiquement l’affichage des dates, des nombres, des devises ou encore des noms de langues en fonction d’une locale donnée. Cependant, son usage direct peut rapidement devenir verbeux, surtout dans un projet où l’internationalisation est omniprésente.

C’est précisément là qu’intervient next-intl. Cette bibliothèque s’intègre naturellement dans l’écosystème Next.js et propose un ensemble de hooks et d’outils qui encapsulent Intl, en rendant son utilisation à...

Accessibilité universelle (a11y)

1. Pourquoi intégrer l’accessibilité ?

L’accessibilité, souvent abrégée en a11y, désigne l’ensemble des pratiques qui visent à rendre une application utilisable par le plus grand nombre, quelles que soient les capacités physiques, sensorielles ou cognitives des utilisateurs. Une application bien conçue doit pouvoir être parcourue et comprise aussi bien par un utilisateur voyant équipé d’une souris que par une personne malvoyante utilisant un lecteur d’écran, ou encore par quelqu’un qui navigue exclusivement au clavier.

L’intégration de l’accessibilité répond à plusieurs enjeux complémentaires :

Inclusion des utilisateurs : elle permet de concevoir une interface qui s’adapte aux besoins des personnes en situation de handicap, qu’il s’agisse de déficiences visuelles, motrices, auditives ou cognitives.
Conformité légale : dans de nombreux pays, et en particulier en Europe, les référentiels tels que le RGAA (Référentiel Général d’Amélioration de l’Accessibilité) ou les normes internationales WCAG 2.1 imposent des obligations aux services publics et, de plus en plus, aux entreprises privées.
Qualité technique et ergonomique : en respectant les bonnes pratiques d’accessibilité (structure HTML sémantique, labels explicites, navigation au clavier, contrastes adaptés), on renforce la robustesse globale de l’application.
Référencement naturel (SEO) : les moteurs de recherche valorisent les sites accessibles, car une structure claire et sémantique facilite l’indexation et améliore la visibilité dans les résultats.

En somme, l’accessibilité ne doit pas être envisagée comme une contrainte ou une simple case à cocher pour respecter la loi. Elle représente un investissement stratégique qui améliore l’expérience utilisateur pour tous, réduit les barrières à l’usage, et confère au projet une valeur durable, tant sur le plan humain que technique.

2. Principes fondamentaux

L’accessibilité repose sur un ensemble de principes...

Internationalisation, formatage et accessibilité