Auteur:
    Aymeric PINEAU
    Création:2026-09-02Dernière mise à jour:2026-09-02

    next-intl est-il obsolète en 2026 ?

    Lorsque Vercel a introduit l'App Router et retiré l'i18n native du Pages Router, next-intl s'est rapidement imposé. Grâce à une documentation soignée de Jan Amann et un support précoce de l'App Router, la bibliothèque est devenue la référence par défaut de la communauté.

    Pourquoi alors s'interroger sur son adéquation aujourd'hui ?

    L'écosystème frontend s'est profondément transformé ces trois dernières années, alors que le modèle fondamental de next-intl est resté statique.

    Tandis que Next.js adoptait les React Server Components (RSC), le streaming et l'optimisation par le compilateur, next-intl traite toujours l'internationalisation comme une tâche d'exécution : transmission de volumineux objets JSON aux providers clients, analyseurs ICU embarqués dans les scripts du navigateur et gestion manuelle des namespaces pour tenter de réduire la taille des bundles.

    Points clés

    Ralentissement des évolutions :

    Sur les 12 derniers mois, next-intl a enregistré environ 187 commits, principalement dédiés aux ajustements de compatibilité Next.js et aux correctifs de maintenance.

    Coût runtime côté client :

    Monter NextIntlClientProvider avec useTranslations() ajoute environ 12.8 Ko gzippés (51 Ko minifiés) avant même d'afficher le premier mot, soit environ 3 fois plus que next-intlayer (4.3 Ko).

    Fuite de contenu de près de 90% :

    Dans les configurations habituelles, 89.8% des données de traduction chargées sur une page appartiennent à d'autres routes. Arriver sur /contact télécharge également les textes de /pricing et /dashboard.

    Gestion manuelle des namespaces :

    Éviter le gonflement des bundles impose de découper manuellement chaque namespace par page, augmentant le risque d'oublis en production.

    Partenariat commercial :

    En tant que partenaire officiel de Crowdin, la bibliothèque a peu d'intérêt à concevoir une commande de traduction IA locale et gratuite directement dans la CLI.

    Maintenance ou outillage moderne

    Activité des commits sur les douze derniers mois :

    Répertoire Étoiles Commits totaux Commits / an Dernier commit
    amannn/next-intl stars commits yearly last
    aymericzip/intlayer stars commits yearly last

    Activité sur les 12 derniers mois :

    • amannn/next-intl : 187 commits (essentiellement montées de dépendances et correctifs légers).
    • aymericzip/intlayer : 4 343 commits (développement continu sur les compilateurs, extensions IDE, serveurs MCP et moteurs de traduction).

    Star History Chart

    Une bibliothèque établie peut être stable. Mais l'i18n frontend progresse : les compilateurs retirent les traductions non référencées au moment du build, les LLMs automatisent la localisation en CI et les développeurs s'appuient sur des serveurs LSP et des agents IA. Une architecture cantonnée au runtime peine à suivre ce rythme.

    Mesure des performances sur Next.js 16 App Router

    Benchmark réalisé sur une application App Router standard avec 10 routes et 10 langues :

    Chargement JSON dynamique

    Charge les traductions à la volée

    JSON scopé (espaces de noms)

    Espaces de noms de traduction par page

    Benchmark de Performance I18n

    Quelle est cette métrique ?

    La taille totale compressée en gzip du bundle de la bibliothèque d’internationalisation. Elle n’inclut que le fournisseur et la logique de récupération de contenu après tree-shaking et minification.

    Pourquoi est-ce important ?

    Une taille de bibliothèque plus petite réduit la charge utile JavaScript initiale, ce qui accélère le téléchargement et le temps d’exécution sur le client.

    Voir comme

    Tests exécutés dans de vrais navigateurs avec compression gzip de production. Détails dans le rapport de benchmark Next.js.

    Empreinte de base des bibliothèques

    Poids côté client avant d'ajouter le moindre texte :

    Bibliothèque Gzippé Minifié
    next-intl@4.9.1 12.8 Ko 51.0 Ko
    next-intlayer@8.7.12 4.3 Ko 13.3 Ko

    Poids des pages et fuites de données

    Configuration JS moyen / page (gz) Fuite de langues Fuite autres pages Composant moyen (gz)
    Base (sans i18n) 150.8 Ko 0.0% 0.0% 0.7 Ko
    next-intl (statique) 163.5 Ko 4.2% 89.8% 20.5 Ko
    next-intl (dynamique) 163.4 Ko 9.7% 89.9% 20.5 Ko
    next-intlayer 152.1 Ko 0.0% 0.0% 7.2 Ko

    Origine des fuites entre pages

    Dans les architectures next-intl classiques, le layout racine charge la totalité des messages dès le départ :

    app/[locale]/layout.tsx
    export default async function RootLayout({ children, params }) {
  const messages = await getMessages();

  return (
    <html>
      <body>
        <NextIntlClientProvider messages={messages}>
          {children}
        </NextIntlClientProvider>
      </body>
    </html>
  );
}

    Puisque messages est fourni au client provider à la racine, le navigateur reçoit l'intégralité du dictionnaire sur chaque URL. Ouvrir la page /login oblige l'utilisateur à télécharger les textes de la FAQ, de la documentation et du tableau de bord.

    Il est possible de contourner cela en découpant les fichiers JSON en plusieurs namespaces chargés au cas par cas. Mais maintenir manuellement cette correspondance route par route s'avère lourd et fragile.

    Intlayer règle ce problème par analyse statique : le compilateur Intlayer inclut exclusivement les textes réellement appelés sur chaque route, ramenant la fuite entre pages à 0.0%.

    Pourquoi next-intl résiste au tree-shaking

    L'API s'appuie sur des résolutions de chaînes textuelles au runtime :

    UserProfile.tsx
    "use client";

import { useTranslations } from "next-intl";

export function UserProfile() {
  const t = useTranslations("UserProfile");

  return <h2>{t("heading")}</h2>;
}
    UserProfile.tsx
    "use client";

import { useIntlayer } from "next-intlayer";

export function UserProfile() {
  const { heading } = useIntlayer("user-profile");

  return <h2>{heading}</h2>;
}

    Turbopack et Webpack ne peuvent pas déterminer quelles clés du namespace UserProfile sont effectivement invoquées pendant l'exécution. Pour prévenir les erreurs de clés manquantes, le bundler est forcé d'intégrer tout le namespace dans le bundle client. Grâce à la déstructuration d'Intlayer, le compilateur sait quelles propriétés sont utilisées et retire les champs superflus. Consultez l'optimisation de bundle pour approfondir.

    Expérience développeur

    Fichiers JSON isolés ou co-localisation

    Avec next-intl, les textes se trouvent dans des fichiers JSON regroupés dans un dossier messages/. Intlayer propose de co-localiser les déclarations de contenu juste à côté des composants :

    messages/en.json
    {
  "authModal": {
    "title": "Sign in to your account",
    "submitButton": "Continue"
  }
}
    messages/fr.json
    {
  "authModal": {
    "title": "Connectez-vous à votre compte",
    "submitButton": "Continuer"
  }
}
    AuthModal.tsx
    import { useTranslations } from "next-intl";

export const AuthModal = () => {
  const t = useTranslations("authModal");
  return (
    <form>
      <h2>{t("title")}</h2>
      <button type="submit">{t("submitButton")}</button>
    </form>
  );
};
    AuthModal.content.ts
    import { t, type Dictionary } from "intlayer";

export default {
  key: "auth-modal",
  content: {
    title: t({
      en: "Sign in to your account",
      fr: "Connectez-vous à votre compte",
    }),
    submitButton: t({
      en: "Continue",
      fr: "Continuer",
    }),
  },
} satisfies Dictionary;
    AuthModal.tsx
    import { useIntlayer } from "next-intlayer";

export const AuthModal = () => {
  const { title, submitButton } = useIntlayer("auth-modal");
  return (
    <form>
      <h2>{title}</h2>
      <button type="submit">{submitButton}</button>
    </form>
  );
};

    En supprimant ou restructurant AuthModal.tsx, ses contenus associés sont immédiatement réorganisés ou retirés.

    Autocomplétion ou contraintes de typage strictes

    L'extension de IntlMessages dans next-intl assure l'autocomplétion basée sur votre fichier linguistique de référence :

    global.d.ts
    import en from "./messages/en.json";

type Messages = typeof en;

declare global {
  interface IntlMessages extends Messages {}
}

    Cependant, seule la langue principale est contrôlée. Si une clé disparaît de fr.json, TypeScript ne signale aucune erreur. Votre CI passe alors au vert, tandis que vos utilisateurs francophones voient des textes manquants.

    Intlayer dérive les types de l'ensemble des déclarations de contenu. Activer le strictMode bloque le build dès qu'une traduction manque dans n'importe quelle langue configurée.

    Outillage et assistants IA

    Fonctionnalité next-intl Intlayer
    Extension VS Code ❌ Aucune ✅ Extension officielle
    Serveur de langage (LSP) ❌ Aucun ✅ LSP intégré
    Serveur MCP (pour agents IA) ❌ Aucun ✅ Serveur MCP inclus
    Compétences agents (Skills) ❌ Aucune ✅ Compétences documentées
    CMS visuel en contexte ❌ Aucun ✅ Gratuit et open source

    L'intégration d'un serveur LSP et d'un serveur MCP permet aux assistants de code intelligents de parcourir le graphe de contenu, de compléter les chaînes multilingues et d'actualiser les dictionnaires avec précision.

    Le partenariat avec Crowdin et l'outillage

    next-intl est officiellement partenaire de Crowdin. Les partenariats commerciaux soutiennent l'open source, mais influencent logiquement la feuille de route : conçu pour interagir avec des solutions TMS externes, next-intl n'a pas vocation à intégrer un outil de traduction IA gratuit et local.

    Intlayer fournit ces mécanismes nativement :

    Auto-remplissage local par IA (intlayer fill) :

    Identifie et traduit automatiquement les clés manquantes avec vos propres clés API (OpenAI, Anthropic, Mistral ou Gemini).

    CMS visuel auto-hébergeable :

    Utilisez le CMS Intlayer pour permettre aux équipes éditoriales de modifier les contenus avec validation directe dans Git.

    Licence open source permissive :

    L'ensemble de l'écosystème est sous licence Apache 2.0.

    Dans quels cas next-intl reste-t-il adapté ?

    Si votre application exploite des logiques complexes de pluriels imbriqués et de sélecteurs ordinaux, l'intégration ICU de next-intl est éprouvée.

    Pour les organisations dont le pipeline est déjà connecté à Crowdin, next-intl s'intègre naturellement.

    Si votre base de code donne satisfaction et que le poids du bundle respecte vos contraintes, une migration n'est pas impérative.

    Comment améliorer ma configuration next-intl existante ?

    Intlayer propose un package de compatibilité direct qui reproduit exactement les signatures de fonctions et hooks de next-intl (tels que useTranslations, getTranslations ou les utilitaires de navigation). Vous n'avez pas besoin de réécrire vos composants pour bénéficier des optimisations au niveau du compilateur.

    L'installation s'effectue en une seule commande :

    bash
    npx intlayer init --interactive

    Cette CLI interactive :

    1. Installe le package de compatibilité @intlayer/next-intl.
    2. Configure les alias du bundler afin que vos imports habituels (next-intl, next-intl/server) pointent directement vers Intlayer, vous permettant de retirer l'ancienne bibliothèque de votre package.json.
    3. Active immédiatement le support du serveur de langage (LSP), l'élimination des fuites de données entre routes (tree-shaking complet) et les flux de traduction IA locale sans refactorisation massive.

    Pour des instructions détaillées étape par étape, consultez nos guides dédiés :

    Évaluez le volume de chargement et les fuites de votre application Next.js grâce au scanner SEO i18n gratuit :

    Pour aller plus loin

    react-i18next vs react-intl vs Intlayeri18next est-il dépassé ?

    Commentaires

    Aucun commentaire pour le moment. Soyez le premier à partager vos pensées.

    Articles similaires

    SvelteKit i18n: routing, SSR, and shared state

    SvelteKit ships no i18n. How to wire locale routing with an optional param or the reroute hook, and why a module-level locale store leaks between SSR requests.

    Aymeric PINEAU

    SEO et Internationalisation

    Découvrez comment optimiser votre site multilingue pour les moteurs de recherche et améliorer votre SEO.

    Aymeric PINEAU

    Meilleures outils d'internationalisation (i18n) pour Svelte - Guide complet pour traduire Best Svelte i18n Libraries 2026 — Compared by DX & Bundle

    Meilleure solution pour la taille du bundle, le SEO, les performances & la maintenabilité. Rendez votre Svelte application multilingue en 2026, traduction LLM, Agent Skills & MCP.

    Aymeric PINEAU

    i18n par composant vs. i18n centralisé : une nouvelle approche avec Intlayer

    Une plongée approfondie dans les stratégies d'internationalisation en React, comparant les approches centralisée, par clé et par composant, et présentant Intlayer.

    Aymeric PINEAU

    Derniers articles

    i18next est-il obsolète en 2026 ?

    i18next propulse des millions de sites web, mais son architecture runtime de 2011 accuse son âge. Analyse du surpoids des bundles, des limites de tree-shaking et du manque d'innovations.

    Aymeric PINEAU

    vue-i18n est-il obsolète en 2026 ?

    vue-i18n est la référence des applications Vue et Nuxt depuis dix ans. Pourtant, nos benchmarks révèlent qu'il s'agit du runtime i18n le plus lourd du web. Explications.

    Aymeric PINEAU

    Next.js i18n - what the App Router makes you build

    The App Router dropped built-in i18n routing. What you now write yourself, why Server and Client Components split the problem, and how libraries compare.

    Aymeric PINEAU

    React Router i18n - locale routes that get indexed

    How to add locale-prefixed routes in React Router v7, why the answer differs between framework mode and SPA mode, and how to avoid hydration mismatches.

    Aymeric PINEAU