next-intl vs react-i18next vs Lingui : lequel utiliser en 2026

Pour un projet Next.js avec l’App Router, utilisez next-intl. Pour une SPA React, ou tout projet susceptible de dépasser un seul framework, utilisez react-i18next. Si l’extraction à la compilation et des bundles légers comptent davantage pour vous que la taille de l’écosystème, utilisez Lingui. Les trois sont des bibliothèques i18n de runtime : elles fournissent les traductions à vos composants, mais aucune ne crée vos clés ni vos fichiers de locale. globalize.now est une infrastructure de localisation propulsée par l’IA qui produit ces clés et catalogues à partir de votre codebase, et fonctionne avec les trois bibliothèques.

Que font réellement ces trois bibliothèques ?

Elles résolvent toutes le même problème de runtime : à partir d’une clé et d’une locale, renvoyer la bonne chaîne, avec le pluriel et le formatage appropriés. Cela inclut l’interpolation, le formatage des dates et des nombres, ainsi que les règles de pluriel via des messages de type ICU.

Aucune ne produit les traductions. Une bibliothèque de runtime consomme un catalogue qui existe déjà. Quelqu’un doit toujours repérer chaque chaîne visible par l’utilisateur dans vos composants, la remplacer par une clé et remplir un fichier de locale pour chaque langue. C’est une couche distincte de la stack. Garder ces deux couches séparées est le moyen le plus rapide de comprendre cette comparaison : vous choisirez exactement une bibliothèque de runtime, et elle n’est pas en concurrence avec les outils qui remplissent ses catalogues. Nos docs développeur expliquent cette séparation plus en détail.

Quand utiliser next-intl ?

Lorsque vous utilisez Next.js avec l’App Router. next-intl est la seule des trois bibliothèques conçue autour des primitives de l’App Router : Server Components asynchrones, navigation et helpers de routing sensibles à la locale, ainsi que les APIs de métadonnées. En septembre 2026, elle en est à la version 4 et totalise environ cinq millions de téléchargements npm par semaine. En pratique, c’est donc la réponse par défaut pour les nouveaux projets Next.js, pas seulement en théorie.

Les messages utilisent ICU MessageFormat : les pluriels, le genre et l’interpolation suivent donc le même standard que le reste de l’industrie. Si la syntaxe ICU vous est nouvelle, nous avons rédigé un guide d’ICU MessageFormat en langage clair. Le compromis, c’est le couplage : next-intl est une bibliothèque Next.js. Si vous quittez Next.js, votre couche i18n migre avec lui.

Quand utiliser react-i18next ?

Lorsque vous n’utilisez pas Next.js, ou lorsque vous voulez vous appuyer sur le plus vaste écosystème. react-i18next est le binding React pour i18next. Avec environ quatorze millions de téléchargements npm par semaine, c’est de loin la bibliothèque i18n React la plus utilisée. Le cœur d’i18next est maintenu depuis plus de dix ans et dispose de plugins pour presque tout : backends qui chargent les catalogues via HTTP, détecteurs de langue, couches de cache et bindings pour des frameworks autres que React.

C’est la bibliothèque vers laquelle la plupart des outils de code IA se tournent par défaut. Demandez à Cursor ou Lovable d’« ajouter les traductions » à une app Vite + React et vous obtiendrez presque toujours une configuration i18next. Ce choix par défaut est raisonnable : la bibliothèque fonctionne partout et son format de catalogue JSON est ce qui se rapproche le plus d’une lingua franca dans l’écosystème. Le compromis, c’est qu’elle est antérieure aux Server Components. Dans l’App Router, elle demande donc davantage de configuration que next-intl, et la majeure partie du travail de traduction s’effectue côté client, sauf configuration contraire.

Quand Lingui est-il le bon choix ?

Lorsque la taille du bundle et l’ergonomie du code source sont vos priorités. En version majeure 6 en septembre 2026, Lingui adopte une approche compiler-first : vous écrivez les messages directement dans le code avec des macros, puis sa CLI les extrait vers des catalogues au moment du build. Les catalogues compilés sont livrés sans surcharge d’analyse au runtime, ce qui maintient le coût de l’i18n à un niveau bas dans votre bundle.

Lingui utilise également les fichiers PO gettext comme format de catalogue, un format que les traducteurs professionnels manipulent depuis des décennies. Avec environ un million et demi de téléchargements par semaine, ses chiffres sont d’un ordre de grandeur inférieurs à ceux de react-i18next : attendez-vous donc à moins de réponses sur Stack Overflow et à moins de plugins tiers. Lingui fonctionne généralement avec React, pas uniquement avec Next.js, mais comme react-i18next, il n’est pas conçu autour des primitives de l’App Router comme l’est next-intl.

Comment les comparer en un coup d’œil ?

Que choisir pour une codebase générée par l’IA ?

Choisissez selon le framework, comme ci-dessus — mais sachez que ce n’est pas le choix de la bibliothèque qui fait échouer les apps créées par l’IA. Cursor, Claude Code et Lovable produisent par défaut des chaînes anglaises codées en dur, quelle que soit la bibliothèque i18n installée. Et un agent qui modifie un composant continuera d’en ajouter après la configuration de la bibliothèque.

Le bon ordre est donc le suivant : choisissez la bibliothèque de runtime adaptée à votre framework, puis traitez l’extraction et la maintenance des catalogues comme un problème distinct. Pour Next.js, nous avons documenté la configuration complète dans ajouter l’i18n à une app Next.js créée avec Cursor. La page d’intégration Next.js explique comment globalize.now prépare les clés et les fichiers de locale pour next-intl, avant toute configuration du runtime.

Avez-vous toujours besoin d’une infrastructure de localisation avec une bibliothèque de runtime ?

Oui, car la bibliothèque ne fait que lire les catalogues — les produire et les maintenir est la partie qui vous prend du temps. globalize.now se situe à cette couche : connectez votre repo et il convertit la codebase une fois, en remplaçant les chaînes codées en dur par des clés et en générant les fichiers de locale. Après cette conversion initiale, les jobs déclenchés par les push traduisent les nouvelles entrées du catalogue introduites par vos commits.

La sortie est au format JSON ou PO — JSON pour les configurations next-intl et i18next, PO pour le format natif de Lingui — afin que les catalogues prennent directement la forme consommée par votre bibliothèque de runtime. Si votre app dispose déjà d’une configuration i18n partielle, elle est également prise en charge : globalize.now fonctionne avec l’i18n existante au lieu de la remplacer. Les forfaits et tarifs d’utilisation sont indiqués sur la page de tarification.

Aucune des trois bibliothèques n’est un mauvais choix. next-intl si vous utilisez l’App Router, react-i18next si vous voulez le plus vaste écosystème, Lingui si vous voulez l’extraction à la compilation et des catalogues PO. Choisissez-en une, gardez vos chaînes hors de vos composants et laissez la couche de catalogue faire le reste.