i18next est-il obsolète en 2026 ?

Lancé en 2011, bien avant l'avènement des composants React, du bundling Webpack ou de TypeScript, i18next s'est imposé grâce à sa flexibilité et son omniprésence. Il bénéficie d'une réponse sur StackOverflow pour presque chaque question et d'adaptateurs pour tous les frameworks.

Le projet n'est pas abandonné, des correctifs sont publiés de temps en temps. Cependant, maintenir un moteur ancien en état de marche diffère fondamentalement d'une évolution adaptée aux architectures frontend actuelles.

Ces dernières années, le frontend s'est orienté vers la compilation au build, les React Server Components (RSC), le tree-shaking agressif et les outils pilotés par l'IA. De son côté, le cœur d'i18next reste inchangé : un singleton runtime qui résout des clés textuelles côté client.

Points clés

Mode maintenance :

Au cours de l'année écoulée, next-i18next a enregistré environ 63 commits (près d'un par semaine) et react-i18next environ 157, principalement pour des montées de versions et des correctifs mineurs.

Poids runtime élevé :

react-i18next et next-i18next injectent environ 17 à 18 Ko gzippés (~60 Ko minifiés) avant même d'afficher le premier mot traduit, soit presque 4 fois plus que next-intlayer (~4.7 Ko).

Fuite importante de traductions :

Avec la configuration statique par défaut, jusqu'à 89.8% des données de traduction envoyées sur une page appartiennent en réalité à d'autres pages ou à des langues inutilisées.

Tree-shaking impossible :

Les clés dynamiques comme t("home.hero.title") ne peuvent pas être analysées par les bundlers, forçant l'inclusion intégrale des fichiers JSON dans le bundle client.

Alignement commercial :

Les mainteneurs exploitent Locize. Intégrer un pipeline de traduction par IA local et sans surcoût au sein de la CLI entrerait en concurrence directe avec leur service commercial payant.

Maintenance ou évolution active

Le nombre d'étoiles GitHub reflète une adoption historique plutôt qu'une dynamique technique moderne.

Afficher tout le contenu du tableau

Afficher tout le contenu du tableau

Ouvrir le tableau dans une fenêtre modale pour voir tout le contenu clairement

Répertoire	Étoiles	Commits totaux	Commits / an	Dernier commit
i18next/i18next
i18next/react-i18next
i18next/next-i18next
aymericzip/intlayer

Activité sur les douze derniers mois :

Une bibliothèque concise peut être mature et stable. Mais les outils d'i18n évoluent vite : les bundlers modernes éliminent le contenu inutile au build, les LLMs traduisent automatiquement en CI, et les éditeurs reposent sur des serveurs de langage (LSP) et des agents IA. L'architecture runtime d'i18next limite sa capacité à adopter ces nouveautés.

Évaluation de l'impact sur le bundle

Mesures effectuées sur un build de production avec 10 routes et 10 locales, compression gzip activée. Détails dans le rapport de benchmark i18n.

Poids initial des bibliothèques

Poids de base avant l'ajout du moindre contenu traduit :

Poids des pages et fuite de contenu

Testé sous React / TanStack Start (stratégie statique) :

Sur Next.js :

Constats majeurs

Poids des pages :

Sur Next.js, next-i18next ajoute 76.7 Ko gzippés par rapport au projet de base (+50%). next-intlayer n'ajoute que 1.3 Ko.

Fuites de contenu :

Par défaut, près de 90% des traductions envoyées sur une page concernent d'autres sections du site. La séparation manuelle par namespaces est fastidieuse et source d'erreurs.

Le graphique ci-dessous estime le poids du contenu pour une application théorique de 1 à 10 pages traduite en 1 à 10 langues, avec environ 30 Ko de texte par page. Charger le contenu dynamiquement par locale supprime l'axe des langues, scoper le contenu par composant ou par route supprime l'axe des pages, et seule la combinaison des deux garde un poids stable.

Temps d'hydratation :

L'hydratation des composants prend 85 ms avec react-i18next contre 24 ms avec Intlayer. Transmettre de volumineux arbres JSON aux composants ralentit la réactivité.

Pourquoi i18next est-il lourd ?

Accumulation de fonctionnalités au runtime

Fonctionner intégralement dans le navigateur oblige à charger l'ensemble des modules dès le départ : interpolation, règles de pluriels, gestion de contextes, formats et bus d'événements. Même une simple chaîne de texte embarque tout le moteur.

Les clés dynamiques bloquent le tree-shaking

Puisque la clé "hero.title" est résolue au runtime, les bundlers ne peuvent pas vérifier quelles chaînes sont réellement utilisées. Les textes inutilisés restent donc inclus dans les bundles clients.

const { t } = useTranslation("home");

return <h1>{t("hero.title")}</h1>;

const { title } = useIntlayer("hero");

return <h1>{title}</h1>;

Le compilateur Intlayer identifie ce que Hero.tsx utilise réellement et élimine les champs non référencés avant de produire les bundles clients. Consultez l'optimisation de bundle pour en savoir plus.

Expérience développeur

Fichiers JSON distants ou co-localisation

Avec i18next, les traductions sont dispersées dans des dossiers JSON séparés du code. Intlayer regroupe les déclarations de contenu directement à côté des composants.

{
  "title": "Ship in every language"
}

{
  "title": "Livrez dans toutes les langues"
}

import { useTranslation } from "react-i18next";

export const Hero = () => {
  const { t } = useTranslation("hero");
  return <h1>{t("title")}</h1>;
};

import { t, type Dictionary } from "intlayer";

export default {
  key: "hero",
  content: {
    title: t({
      en: "Ship in every language",
      fr: "Livrez dans toutes les langues",
    }),
  },
} satisfies Dictionary;

import { useIntlayer } from "react-intlayer";

export const Hero = () => {
  const { title } = useIntlayer("hero");
  return <h1>{title}</h1>;
};

Lorsque vous déplacez ou supprimez Hero.tsx, ses traductions suivent automatiquement.

Autocomplétion ou sécurité de typage stricte

L'extension de CustomTypeOptions offre l'autocomplétion des clés, mais ne garantit pas la présence effective des textes. La suppression d'une clé dans fr/home.json ne bloque pas votre build, elle entraîne simplement un fallback au runtime.

Intlayer déduit les types à partir des déclarations de contenu, et le strictMode convertit les traductions manquantes en erreurs strictes au build.

Comparatif d'outillage

Traduction et modèle économique de Locize

Locize est la plateforme commerciale officielle créée par les auteurs d'i18next. Bien que le financement de l'open source soit essentiel, ce modèle engendre un arbitrage : un projet monétisé via un SaaS de traduction a peu d'intérêt à fournir gratuitement un outil de traduction IA local et autonome dans sa CLI.

Intlayer privilégie un modèle ouvert :

• intlayer fill complète les traductions manquantes en local ou en CI avec vos propres clés API (OpenAI, Anthropic, Mistral, Gemini).
• Le CMS Intlayer est open source et auto-hébergeable via Docker Compose.
• Le compilateur, la CLI, l'éditeur et le CMS sont tous sous licence Apache 2.0.

Dans quels cas i18next reste-t-il pertinent ?

Comment améliorer ma configuration i18next existante ?

Intlayer propose des packages de compatibilité prêts à l'emploi qui reprennent à l'identique les signatures de fonctions des bibliothèques i18next (i18next, react-i18next et next-i18next). Vous n'avez pas besoin de réécrire vos composants pour bénéficier d'une architecture optimisée par compilateur.

L'installation s'effectue en une seule commande :

npx intlayer init --interactive

Cette CLI interactive :

1. Installe le package de compatibilité @intlayer/i18next.
2. Configure les alias du bundler afin que vos imports habituels (useTranslation, Trans, t) pointent directement vers Intlayer, permettant de retirer l'ancienne bibliothèque de votre package.json.
3. Active immédiatement le support du serveur de langage (LSP) dans l'IDE, l'optimisation du bundle (tree-shaking complet) et les flux de traduction IA locale.

Pour aller plus loin, consultez nos guides détaillés :

• Couches de compatibilité : Conservez votre code existant avec les adaptateurs pour i18next, react-i18next et next-i18next.
• Migration des dictionnaires : Convertissez vos catalogues JSON en structures typées : depuis i18next, depuis react-i18next ou depuis next-i18next.
• Approche hybride : Gardez votre runtime i18next tout en associant Intlayer à i18next pour générer, typer et traduire automatiquement vos dictionnaires.

Analysez votre site en production avec le scanner SEO i18n gratuit :

Lectures recommandées

• Benchmark i18n Next.js : analyse complète des performances
• react-i18next vs react-intl vs Intlayer
• next-intl est-il obsolète en 2026 ?
• Architecture de compilation vs i18n déclarative