@intlayer/docs 9.5.3 → 9.5.4-canary.0

package/blog/fr/how_to_pick_vue_i18n_library.md

@@ -0,0 +1,442 @@
+---
+createdAt: 2026-09-16
+updatedAt: 2026-09-16
+title: "Comment choisir la bonne bibliothèque i18n Vue en 2026"
+description: Un guide de décision pour l'internationalisation de Vue et Nuxt. Les questions à se poser avant de comparer vue-i18n, @nuxtjs/i18n, fluent-vue, Paraglide et Intlayer, et ce que chaque choix coûte en taille de bundle, typage et payload SSR.
+keywords:
+  - vue i18n
+  - internationalisation vue
+  - vue-i18n
+  - nuxt i18n
+  - fluent-vue
+  - Paraglide
+  - Intlayer
+  - comparaison bibliothèques i18n
+slugs:
+  - blog
+  - how-to-pick-vue-i18n-library
+author: aymericzip
+---
+
+# Comment choisir la bonne bibliothèque i18n pour Vue
+
+"Vue i18n" est à la fois un terme générique et le nom de la bibliothèque que presque tout le monde installe. C'est à la fois pratique et trompeur : `vue-i18n` est un choix par défaut tout à fait convenable, mais ce n'est pas la seule option, et les questions qui devraient guider votre choix (SSR ou non, nombre de pages, qui rédige les traductions) sont rarement posées avant d'exécuter `npm install`.
+
+Ce guide pose d'abord ces questions, puis fait correspondre les réponses aux bibliothèques adaptées, pour Vite + Vue standard et pour Nuxt.
+
+![Écosystème des bibliothèques i18n pour Vue](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
+
+## Table des matières
+
+<TOC/>
+
+## Six questions à se poser avant de comparer les bibliothèques
+
+1. **Vite SPA ou Nuxt ?** Dans une SPA, le coût du catalogue est un problème de bundle JS. Dans Nuxt, c'est aussi un problème de payload HTML, car les messages sont sérialisés dans l'état SSR puis hydratés. La plupart des retours disant que "vue-i18n est lent" proviennent d'applications Nuxt pour cette raison.
+2. **Qui rédige les traductions ?** Des développeurs, un TMS, une agence fournissant des chaînes ICU, ou un pipeline IA. `vue-i18n` utilise sa propre syntaxe de pluriel séparée par des barres verticales (`|`), et non ICU. Cela a son importance si les chaînes proviennent de l'extérieur.
+3. **Combien de locales et de pages ?** Deux locales et cinq pages peuvent tout embarquer d'un coup. Dix locales et quarante routes ne le peuvent pas, et la stratégie de chargement devient le coût principal.
+4. **Avez-vous besoin du typage sur les clés ?** `t("cart.totl")` compile dans `vue-i18n` à moins de passer un generic de schéma de message, et ce schéma entre en conflit avec les catalogues chargés en lazy loading.
+5. **Que contient votre contenu ?** Uniquement des libellés d'interface utilisateur, ou du markdown, des liens au milieu des phrases et des blocs spécifiques à chaque locale ? C'est avec le contenu riche que le retour sous forme de chaîne de caractères de `t()` devient fastidieux.
+6. **Le CSP est-il une contrainte ?** Le build par défaut de `vue-i18n` compile les messages dans le navigateur avec `new Function`. Les builds runtime-only nécessitent `@intlify/unplugin-vue-i18n` pour précompiler au moment du build.
+
+Notez vos réponses. Tout ce qui suit y fait référence.
+
+## Le paysage en une image
+
+L'écosystème Vue compte moins de bibliothèques i18n que React, et elles sont issues de différentes vagues architecturales.
+
+![Histoire des bibliothèques i18n JavaScript](https://github.com/aymericzip/intlayer/blob/main/docs/assets/history_i18n.webp?raw=true)
+
+<AccordionGroup>
+<Accordion header="Dictionnaires au runtime (2015 à 2019) : vue-i18n, @nuxt/i18n">
+
+`vue-i18n` est apparu en 2015 et est resté le choix par défaut depuis. `@nuxt/i18n` l'encapsule avec le routing par locale, les balises SEO et le lazy loading par locale. Les messages sont compilés en fonctions de rendu, au moment du build si vous ajoutez l'unplugin, dans le navigateur sinon.
+
+</Accordion>
+<Accordion header="Formats alternatifs (2020) : fluent-vue">
+
+Les fichiers `.ftl` de Mozilla Fluent ont apporté une syntaxe de message plus conviviale avec des variantes grammaticales. Pas de typage sur les clés, et le plugin Vite charge chaque locale dans chaque page.
+
+</Accordion>
+<Accordion header="Compilateur et contenu colocalisé (2024 à 2026) : Paraglide, Intlayer">
+
+Paraglide génère une fonction par message et laisse le bundler éliminer le reste via tree-shaking. Intlayer déclare le contenu par composant dans des fichiers `.content.ts`, génère les types, et n'embarque que ce qu'une route affiche.
+
+</Accordion>
+</AccordionGroup>
+
+L'[histoire de l'i18n JavaScript](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/history_of_i18n.md) détaille chaque vague en profondeur.
+
+## La décision la plus importante : où vit le contenu et quand se charge-t-il
+
+Deux choix structurels expliquent la majeure partie des différences de taille de bundle entre les configurations :
+
+- **Contenu centralisé ou scopé.** Un seul `locales/fr.json` pour toute l'application, ou une déclaration par composant.
+- **Import statique ou dynamique.** Tout charger au démarrage, ou récupérer la locale active (et idéalement la route active) à la demande.
+
+Le graphique estime le payload pour une application théorique de 1 à 10 pages, traduite en 1 à 10 locales, avec environ 30 Ko de texte par page.
+
+![Fuite théorique de contenu par architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
+`vue-i18n` prend en charge l'axe dynamique : appeler `setLocaleMessage` après un `import()` vous évite d'expédier neuf locales que personne ne lit. Ce qu'il ne permet pas, c'est l'axe de la page. Un catalogue de locale est un objet unique, et le charger charge les textes de chaque page. Dans une SPA, personne ne s'en aperçoit. Dans Nuxt, avec `@nuxtjs/i18n` et plus de dix pages, chaque route transporte les chaînes de toutes les autres routes, en double : dans le chunk JS et dans le payload SSR.
+
+Le [benchmark Vue](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/benchmark/vue.md) mesure cela sous forme de "fuite des autres routes" et "fuite des autres locales". Si votre réponse à la question 3 était "beaucoup de pages", cette section l'emporte sur toute préférence d'API. L'article sur l'[i18n par composant vs centralisée](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/per-component_vs_centralized_i18n.md) aborde la maintenance de ce même compromis.
+
+## Les candidats
+
+Les tailles des bibliothèques sont issues du [benchmark Vue](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/benchmark/vue.md) : plugin plus composable dans un composant vide, après bundling, tree-shaking et minification, sur une application de 10 pages et 10 locales. Le contenu est mesuré séparément.
+
+| Bibliothèque   | Modèle de contenu                                             | Sûreté des types                      | Format de message                   | Découpage par route   | Taille de la bibliothèque                                  |
+| :------------- | :------------------------------------------------------------ | :------------------------------------ | :---------------------------------- | :-------------------- | :--------------------------------------------------------- |
+| `vue-i18n`     | Catalogues centraux par locale, blocs SFC `<i18n>` optionnels | 2/5 — Optionnel via generic de schéma | Propre (pluriels pipe)              | Non                   | ~24.3 Ko                                                   |
+| `@nuxtjs/i18n` | Identique à `vue-i18n`, plus routing et balises SEO           | 2/5 — Identique                       | Identique                           | Non, par locale seule | ~24.3 Ko                                                   |
+| `fluent-vue`   | Fichiers `.ftl` (Mozilla Fluent)                              | 1/5 — Aucun                           | Fluent                              | Non                   | ~29.7 Ko                                                   |
+| Paraglide      | Projet inlang, fonctions générées                             | 3.5/5 — Générés                       | Propre                              | Via tree-shaking      | Proche de zéro (grâce au code généré dans la base de code) |
+| Intlayer       | Un fichier `.content.ts` par composant                        | 5/5 — Générés, activés par défaut     | Intlayer (+ ICU, i18next, vue-i18n) | Oui, par composant    | ~3.9 Ko                                                    |
+
+> Les chiffres représentent un instantané basé sur les versions du benchmark. Exécutez-le sur votre propre application avant de décider uniquement sur la taille.
+> Sûreté des types : 5/5 signifie que les clés, les paramètres et chaque locale sont vérifiés sans configuration manuelle, y compris le formateur d'URL et les helpers.
+
+La taille quasi nulle de la bibliothèque Paraglide découle de sa conception : le runtime est généré dans votre repository, ce qui implique une étape de regénération avant chaque push et des conflits de fusion sur les fichiers générés. Intlayer nécessite `vite-intlayer` (ou le module Nuxt), il ne peut donc pas fonctionner sans étape de build.
+
+## Associez vos réponses à une bibliothèque
+
+<AccordionGroup>
+<Accordion header="Vite SPA, petite équipe, peu de locales">
+
+`vue-i18n` en mode Composition (`legacy: false`), avec `@intlify/unplugin-vue-i18n` pour ne livrer que le build runtime-only. Chargez les locales en lazy loading avec `import()`. Cela couvre la plupart des petites applications et les réponses de la communauté sont disponibles partout. Les blocs SFC `<i18n>` colocalisent les messages avec le composant, ce qui aide, mais les outils d'extraction et de TMS qui les entourent sont plus limités que pour les catalogues JSON, décidez donc tôt de ce que l'équipe utilisera.
+
+</Accordion>
+<Accordion header="Nuxt avec routing par locale, sitemap et hreflang">
+
+`@nuxtjs/i18n` vous offre la stratégie de routing, les balises `hreflang` et la détection de la locale sans écrire de code, ce qui justifie à lui seul son choix pour des sites de contenu avec une poignée de pages. Sa limite réside dans le catalogue par locale : au-delà d'une dizaine de pages, le payload SSR transporte les textes de chaque route. Si tel est votre cas, configurez `vue-i18n` à la main avec des messages par route, ou passez à un contenu scopé. L'article sur [Nuxt i18n](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/list_i18n_technologies/frameworks/nuxt.md) guide d'abord le choix de la stratégie de routing.
+
+</Accordion>
+<Accordion header="Les traductions proviennent d'un TMS ou d'une agence fournissant de l'ICU">
+
+La syntaxe de pluriel de `vue-i18n` (`"aucun article | un article | {count} articles"`) n'est pas compatible ICU et n'est pas portable. Les traducteurs doivent en être informés, et un export TMS ne la produira pas. Mettez-vous d'accord sur le format avant la création du premier catalogue, ou choisissez une bibliothèque dont le format correspond à votre prestataire. Le support d'ICU par Intlayer est partiel, donc si vous recevez des chaînes ICU aujourd'hui, considérez cela également comme un point bloquant.
+
+</Accordion>
+<Accordion header="Grande application, nombreuses routes, budget bundle ou payload SSR strict">
+
+Privilégiez le contenu scopé compilé au moment du build. Paraglide y parvient grâce au tree-shaking, qui fonctionne comme annoncé sur Vite. Intlayer y parvient grâce aux déclarations par composant et n'expédie que ce que la route affiche. Avec `vue-i18n`, vous pouvez découper les messages par route manuellement, mais rien ne l'impose et un composant partagé important un namespace global peut discrètement annuler ces efforts.
+
+</Accordion>
+<Accordion header="Le typage strict est non négociable">
+
+`vue-i18n` peut être typé en passant un generic de schéma à `createI18n`. Cela fonctionne, mais se brise dès que les catalogues sont chargés en lazy loading, car le schéma décrit des messages qui ne sont potentiellement pas encore là. Si vous ne souhaitez pas maintenir cela, optez pour une bibliothèque dont les types sont générés à partir du contenu : Paraglide ou Intlayer. L'article sur la [détection des traductions manquantes](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/detecting_missing_translations.md) compare ce que chacune détecte au moment du build.
+
+</Accordion>
+<Accordion header="Le contenu est plus complexe que de simples libellés d'interface">
+
+Pages en markdown, phrases contenant un `<RouterLink>` au milieu, composants par locale. `vue-i18n` propose `<i18n-t>` pour l'interpolation de composants, ce qui fonctionne mais s'avère verbeux. Les nœuds de contenu d'Intlayer acceptent directement du markdown, du HTML et des objets imbriqués, ce qui convient mieux lorsque l'application est riche en contenu.
+
+</Accordion>
+<Accordion header="Les traductions seront produites par l'IA">
+
+Dans ce cas, le JSON centralisé n'a plus d'intérêt pour le justifier. Un contenu colocalisé couplé à une CLI qui remplit les locales manquantes représente le chemin le plus court. La commande `fill` d'Intlayer s'exécute avec votre propre clé API (OpenAI, Anthropic, Mistral, Gemini) et ne retraduit que ce qui a été modifié.
+
+</Accordion>
+</AccordionGroup>
+
+## Les limites de chaque bibliothèque
+
+- **`vue-i18n`** : la plus lourde du groupe, format de pluriel propriétaire, types optionnels et fragiles avec le lazy loading, pas de découpage par route, accumulation silencieuse de clés mortes. Laisser `legacy: true` dans une application Vue 3 conserve la couche de compatibilité Vue 2 et fait perdre le typage de `useI18n()`.
+- **`@nuxtjs/i18n`** : hérite de tous les points ci-dessus, et le payload SSR transporte les chaînes de chaque page dès qu'on dépasse une douzaine de routes.
+- **`fluent-vue`** : syntaxe de message agréable, pas de typage sur les clés, et le plugin Vite charge tout le contenu dans toutes les langues sur chaque page. La plus lourde du benchmark.
+- **Paraglide** : fichiers générés commités dans le repo, regénération avant chaque push, et la locale est lue depuis un cookie ou le storage à chaque appel de message plutôt que depuis un store réactif, ce qui entraîne un surcoût lors des changements de locale.
+- **Intlayer** : plugin de build obligatoire, écosystème plus restreint, support partiel d'ICU, et contenu réparti dans toute la codebase par conception, ce qui nécessite des outils pour exporter un JSON unique destiné à un traducteur.
+
+## Ce que chaque option donne en code
+
+Le même composant, un récapitulatif de panier avec un titre et un pluriel, écrit avec chaque candidat. La partie intéressante n'est pas le template, mais l'endroit où réside le contenu et ce que `vue-tsc` en sait.
+
+<Tabs defaultTab="vue-i18n">
+  <Tab label="vue-i18n" value="vue-i18n">
+
+  <Tabs group="locale">
+  <Tab value="en" label="Anglais">
+
+```json fileName="src/locales/en.json"
+{
+  "cart": {
+    "title": "Your cart",
+    "items": "no item | one item | {count} items"
+  }
+}
+```
+
+  </Tab>
+  <Tab value="fr" label="Français">
+
+```json fileName="src/locales/fr.json"
+{
+  "cart": {
+    "title": "Votre panier",
+    "items": "aucun article | un article | {count} articles"
+  }
+}
+```
+
+  </Tab>
+  <Tab value="es" label="Espagnol">
+
+```json fileName="src/locales/es.json"
+{
+  "cart": {
+    "title": "Tu carrito",
+    "items": "ningún artículo | un artículo | {count} artículos"
+  }
+}
+```
+
+  </Tab>
+  </Tabs>
+
+```vue fileName="src/components/CartSummary.vue"
+<script setup lang="ts">
+import { useI18n } from "vue-i18n";
+
+const props = defineProps<{ count: number }>();
+const { t } = useI18n();
+</script>
+
+<template>
+  <section>
+    <h2>{{ t("cart.title") }}</h2>
+    <p>{{ t("cart.items", { count: props.count }, props.count) }}</p>
+  </section>
+</template>
+```
+
+Les pluriels séparés par des barres verticales (`|`) sont un format propre à vue-i18n, pas du standard ICU. `t` accepte n'importe quelle chaîne, à moins de passer un generic de schéma de message à `createI18n`.
+
+  </Tab>
+  <Tab label="fluent-vue" value="fluent-vue">
+
+  <Tabs group="locale">
+  <Tab value="en" label="Anglais">
+
+```ftl fileName="src/locales/en.ftl"
+cart-title = Your cart
+cart-items = { $count ->
+    [one] { $count } item
+   *[other] { $count } items
+}
+```
+
+  </Tab>
+  <Tab value="fr" label="Français">
+
+```ftl fileName="src/locales/fr.ftl"
+cart-title = Votre panier
+cart-items = { $count ->
+    [one] { $count } article
+   *[other] { $count } articles
+}
+```
+
+  </Tab>
+  <Tab value="es" label="Espagnol">
+
+```ftl fileName="src/locales/es.ftl"
+cart-title = Tu carrito
+cart-items = { $count ->
+    [one] { $count } artículo
+   *[other] { $count } artículos
+}
+```
+
+  </Tab>
+  </Tabs>
+
+```vue fileName="src/components/CartSummary.vue"
+<script setup lang="ts">
+import { useFluent } from "fluent-vue";
+
+const props = defineProps<{ count: number }>();
+const { $t } = useFluent();
+</script>
+
+<template>
+  <section>
+    <h2>{{ $t("cart-title") }}</h2>
+    <p>{{ $t("cart-items", { count: props.count }) }}</p>
+  </section>
+</template>
+```
+
+La syntaxe de Fluent gère très bien les pluriels et les variantes grammaticales. Les identifiants de messages sont des chaînes non typées, et le plugin Vite intègre chaque locale dans chaque page.
+
+  </Tab>
+  <Tab label="Paraglide" value="paraglide">
+
+  <Tabs group="locale">
+  <Tab value="en" label="Anglais">
+
+```json fileName="messages/en.json"
+{
+  "cart_title": "Your cart",
+  "cart_items": "{count} items"
+}
+```
+
+  </Tab>
+  <Tab value="fr" label="Français">
+
+```json fileName="messages/fr.json"
+{
+  "cart_title": "Votre panier",
+  "cart_items": "{count} articles"
+}
+```
+
+  </Tab>
+  <Tab value="es" label="Espagnol">
+
+```json fileName="messages/es.json"
+{
+  "cart_title": "Tu carrito",
+  "cart_items": "{count} artículos"
+}
+```
+
+  </Tab>
+  </Tabs>
+
+```vue fileName="src/components/CartSummary.vue"
+<script setup lang="ts">
+import { m } from "../paraglide/messages.js";
+
+const props = defineProps<{ count: number }>();
+</script>
+
+<template>
+  <section>
+    <h2>{{ m.cart_title() }}</h2>
+    <p>{{ m.cart_items({ count: props.count }) }}</p>
+  </section>
+</template>
+```
+
+Chaque message est une fonction typée générée, une clé manquante provoque donc une erreur d'import. Le dossier `paraglide/` est généré dans votre repo et regénéré à chaque modification.
+
+  </Tab>
+  <Tab label="Intlayer" value="intlayer">
+
+```ts fileName="src/components/cartSummary.content.ts"
+import { plural, t, type Dictionary } from "intlayer";
+
+const cartSummaryContent = {
+  key: "cart-summary",
+  content: {
+    title: t({ fr: "Votre panier", en: "Your cart", es: "Tu carrito" }),
+    items: t({
+      fr: plural({ one: "{{count}} article", other: "{{count}} articles" }),
+      en: plural({ one: "{{count}} item", other: "{{count}} items" }),
+      es: plural({ one: "{{count}} artículo", other: "{{count}} artículos" }),
+    }),
+  },
+} satisfies Dictionary;
+
+export default cartSummaryContent;
+```
+
+```vue fileName="src/components/CartSummary.vue"
+<script setup lang="ts">
+import { useIntlayer } from "vue-intlayer";
+
+const props = defineProps<{ count: number }>();
+const { title, items } = useIntlayer("cart-summary");
+</script>
+
+<template>
+  <section>
+    <h2><title /></h2>
+    <p>{{ items(props.count) }}</p>
+  </section>
+</template>
+```
+
+Toutes les locales réunies dans un seul fichier à côté du composant. Les types sont générés au build, `title` bénéficie donc de l'autocomplétion et une faute de frappe fait échouer `vue-tsc`. `<title />` effectue le rendu d'un nœud ciblable par l'éditeur visuel ; `{{ items(props.count) }}` retourne la chaîne brute.
+
+  </Tab>
+</Tabs>
+
+Vous utilisez déjà `vue-i18n` ? L'[adaptateur de compatibilité `@intlayer/vue-i18n`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/compat/vue-i18n.md) crée un alias du package au niveau du bundler, de sorte que `useI18n()`, `$t`, les pluriels pipe et `v-t` continuent de fonctionner pendant qu'Intlayer sert le contenu. Le [guide de migration](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/migration_from_vue-i18n_to_intlayer.md) explique comment se détacher de l'adaptateur par la suite, et il existe un [guide spécifique à Nuxt](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/migration_from_nuxtjs_i18n_to_intlayer.md).
+
+## Avant de vous engager
+
+Un tableau de fonctionnalités indique ce qu'une bibliothèque fait aujourd'hui. Les points suivants expliquent à quoi ressemblera votre quotidien avec elle.
+
+**Vérifiez l'activité du repository.**
+
+Commits, temps de réponse sur les issues, et si la dernière release mineure date de cette année. Une conception solide sans mainteneur est une future migration forcée.
+
+**Ne choisissez pas en fonction des téléchargements npm.**
+
+La bibliothèque la plus installée est celle qui est sortie en premier, pas nécessairement celle qui convient à une codebase Vue en 2026. Les téléchargements mesurent l'ancienneté, pas l'adéquation.
+
+![Tier list des bibliothèques i18n JavaScript](https://github.com/aymericzip/intlayer/blob/main/docs/assets/alphabet_rank_i18n_lib.webp?raw=true)
+
+**Renseignez-vous sur qui finance le mainteneur et ce qu'il vend.**
+
+`vue-i18n` est soutenu par Crowdin, tout comme `next-intl` et `svelte-i18n`. `i18next` est soutenu par Locize. Tolgee, Paraglide (inlang) et Intlayer gèrent chacun leur propre plateforme. Un fournisseur dont les revenus reposent sur l'hébergement des traductions a peu d'intérêt à rendre la traduction gratuite au sein de votre toolchain. Intlayer est le seul de la liste à intégrer la traduction par IA via la CLI avec votre propre clé API, ainsi qu'un CMS que vous pouvez auto-héberger.
+
+**Est-il prêt pour les agents IA ?**
+
+Les agents rencontrent encore des difficultés avec l'i18n : ils oublient des locales, inventent des clés et mélangent les syntaxes de messages. La bibliothèque fournit-elle des [Agent Skills](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/agent_skills.md) ou un [serveur MCP](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/mcp_server.md) pour permettre à l'agent de lister, compléter et tester le contenu ? Et le chargement du contenu est-il optimisé par défaut, ou quelqu'un doit-il auditer les namespaces et les imports lazy chaque trimestre ?
+
+**Typage strict dès l'installation.**
+
+Pas un simple "peut être typé avec de la configuration supplémentaire", mais "une mauvaise clé fait échouer `tsc` sur une installation neuve". Regardez ce qui se produit avec une clé inexistante, ainsi qu'avec une locale à laquelle il manque une traduction.
+
+**Détection du contenu inutilisé.**
+
+Les catalogues ne font que grossir. Le build d'Intlayer purge les champs inutilisés et les consigne (`build.purge`). Paraglide y parvient par architecture, puisqu'une fonction de message non appelée est éliminée via tree-shaking. Tout le reste vous laisse le soin de faire le ménage.
+
+**Expérience développeur.**
+
+Le temps de configuration jusqu'à la première chaîne traduite, un [LSP](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/lsp.md) ou une [extension VS Code](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/vs_code_extension.md) qui affiche la traduction au survol et renvoie vers la déclaration, une [CLI](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/cli/index.md) pour compléter, tester et synchroniser (push), un [compilateur](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/compiler.md) ou extracteur qui extrait les chaînes codées en dur de vos composants pour ne pas tout gérer clé par clé, et un moyen pour les non-développeurs d'éditer le contenu ([éditeur visuel](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/intlayer_visual_editor.md) ou [CMS](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/intlayer_CMS.md)) sans pull request.
+
+## Foire Aux Questions
+
+<FAQ>
+
+<Question title="vue-i18n est-il toujours le bon choix par défaut en 2026 ?">
+
+Pour la plupart des applications Vue, oui. L'écosystème est le plus large, la documentation est complète, et les coûts sont prévisibles : un runtime lourd, un format de pluriel propriétaire, et un découpage par route que vous devez concevoir et maintenir vous-même.
+
+</Question>
+
+<Question title="Dois-je utiliser @nuxtjs/i18n ou configurer vue-i18n manuellement dans Nuxt ?">
+
+Utilisez le module, à moins que votre routing soit inhabituel ou que votre application ne compte que peu de pages. Une configuration manuelle implique de recréer vous-même les routes par locale, les middlewares, `hreflang` et le sitemap, ce qui s'avère plus complexe qu'il n'y paraît.
+
+</Question>
+
+<Question title="Ai-je besoin d'une bibliothèque basée sur un compilateur ?">
+
+Seulement si la taille du bundle, le payload SSR, les types générés ou la vérification des clés manquantes au build sont de réelles exigences. L'article sur l'[i18n basée sur compilateur vs déclarative](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/compiler_vs_declarative_i18n.md) explique ce que les compilateurs apportent et les pièges potentiels.
+
+</Question>
+
+<Question title="Le choix de la bibliothèque influence-t-il le SEO ?">
+
+Indirectement. Les robots d'indexation s'intéressent au routing, au `hreflang`, à `<html lang>` et à la présence du texte dans le HTML rendu côté serveur. Consultez le [guide hreflang](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/hreflang_guide_multilingual_seo.md).
+
+</Question>
+
+</FAQ>
+
+## Pour aller plus loin
+
+- [Benchmark Vue i18n : taille de bundle, fuites et temps de changement de locale](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/benchmark/vue.md)
+- [Vue i18n : comment fonctionne vue-i18n et ses points faibles](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/list_i18n_technologies/frameworks/vue.md) et l'[article sur Nuxt i18n](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/list_i18n_technologies/frameworks/nuxt.md)
+- [vue-i18n vs Intlayer, fonctionnalité par fonctionnalité](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/vue-i18n_vs_intlayer.md) et le [benchmark vue-i18n vs Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/vue-i18n_vs_intlayer_benchmark.md)
+- [vue-i18n est-il obsolète ?](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/is_vue-i18n_outdated.md)
+- [L'histoire de l'i18n JavaScript](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/history_of_i18n.md)
+- [i18n basée sur compilateur vs déclarative](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/compiler_vs_declarative_i18n.md)
+- [i18n par composant vs centralisée](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/per-component_vs_centralized_i18n.md)
+- [Configurer l'i18n dans une application Vite + Vue](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/intlayer_with_vite+vue.md) et dans une [application Nuxt](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/intlayer_with_nuxt.md)
+- Le même guide pour [React](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/how_to_pick_react_i18n_library.md), [Svelte](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/how_to_pick_svelte_i18n_library.md) et [Solid](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/how_to_pick_solid_i18n_library.md)

package/blog/fr/is_i18next_outdated.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-02
-updatedAt: 2026-09-02
+updatedAt: 2026-09-16
 title: i18next est-il obsolète en 2026 ?
 description: 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.
 keywords:
@@ -125,6 +125,10 @@ Sur Next.js, `next-i18next` ajoute **76.7 Ko gzippés** par rapport au projet de
 
 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.
+
+![Fuite de contenu théorique selon l'architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
 **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é.

package/blog/fr/is_next-intl_outdated.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-02
-updatedAt: 2026-09-02
+updatedAt: 2026-09-16
 title: next-intl est-il obsolète en 2026 ?
 description: next-intl est devenu le choix privilégié pour Next.js App Router. Pourtant, il impose encore un surpoids de bundle runtime et une gestion manuelle fastidieuse des namespaces.
 keywords:
@@ -127,6 +127,10 @@ Puisque `messages` est fourni au client provider à la racine, le navigateur re
 
 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.
 
+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.
+
+![Fuite de contenu théorique selon l'architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
 Intlayer règle ce problème par analyse statique : le [compilateur Intlayer](https://intlayer.org/fr/doc/compiler) 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

package/blog/fr/is_vue-i18n_outdated.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-02
-updatedAt: 2026-09-02
+updatedAt: 2026-09-16
 title: vue-i18n est-il obsolète en 2026 ?
 description: 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.
 keywords:
@@ -116,6 +116,12 @@ Par défaut, **90% des textes traduits** envoyés à une route appartiennent à
 
 Les composants compilés avec des portées locales ont atteint une moyenne de 196 Ko sous `vue-i18n` en raison de catalogues dupliqués, contre seulement **6.5 Ko** avec Intlayer.
 
+**Comment la fuite évolue :**
+
+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.
+
+![Fuite de contenu théorique selon l'architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
 ## Pourquoi vue-i18n est-il lourd ?
 
 ### Un compilateur AST embarqué dans le navigateur

package/blog/fr/next-i18next_vs_next-intl_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2025-08-23
-updatedAt: 2026-05-31
+updatedAt: 2026-09-16
 title: "next-i18next vs next-intl vs Intlayer - Guide complet pour traduire next-i18next vs next-intl vs Intlayer: 2026 Comparison"
 description: Meilleure solution pour la taille du bundle, le SEO, les performances & la maintenabilité. Rendez votre Next.js site web multilingue en 2026, traduction LLM, Agent Skills & MCP.
 keywords:
@@ -22,7 +22,7 @@ author: aymericzip
 
 <TOC/>
 
-![next-i18next VS next-intl VS intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.png?raw=true)
+![next-i18next VS next-intl VS intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
 
 Examinons les similitudes et différences entre trois options i18n pour Next.js : next-i18next, next-intl, et Intlayer.
 
@@ -136,6 +136,10 @@ Deux problèmes importants :
 
   > Si je suis sur la page `/fr/about`, je ne veux pas charger le contenu de la page `/en/about`
 
+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.
+
+![Fuite de contenu théorique selon l'architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
 Encore une fois, les trois solutions sont conscientes de ces problèmes et permettent de gérer ces optimisations. La différence entre les trois solutions réside dans l'expérience développeur (DX).
 
 `next-intl` et `next-i18next` utilisent une approche centralisée pour gérer les traductions, permettant de fractionner les fichiers JSON par locale et par sous-fichiers. Dans `next-i18next`, nous appelons ces fichiers JSON des « namespaces » ; `next-intl` permet de déclarer des messages. Dans `intlayer`, nous appelons ces fichiers JSON des « dictionnaires ».
@@ -158,9 +162,9 @@ Dans le cas de `next-intl` et `next-i18next`, la bibliothèque nécessite de cha
 
 Voici un exemple de l'impact de l'optimisation de la taille du bundle en utilisant `intlayer` dans une application vite + react :
 
-| Bundle optimisé                                                                                      | Bundle non optimisé                                                                                                      |
-| ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
-| ![bundle optimisé](https://github.com/aymericzip/intlayer/blob/main/docs/assets/bundle.png?raw=true) | ![bundle non optimisé](https://github.com/aymericzip/intlayer/blob/main/docs/assets/bundle_no_optimization.png?raw=true) |
+| Bundle optimisé                                                                                       | Bundle non optimisé                                                                                                       |
+| ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
+| ![bundle optimisé](https://github.com/aymericzip/intlayer/blob/main/docs/assets/bundle.webp?raw=true) | ![bundle non optimisé](https://github.com/aymericzip/intlayer/blob/main/docs/assets/bundle_no_optimization.webp?raw=true) |
 
 ## TypeScript & sécurité
 

package/blog/fr/per-component_vs_centralized_i18n.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2025-09-10
-updatedAt: 2025-09-10
+updatedAt: 2026-09-16
 title: "i18n par composant vs. i18n centralisé : une nouvelle approche avec Intlayer"
 description: 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.
 keywords:
@@ -63,6 +63,7 @@ Cependant, dans le monde React, on observe principalement différentes approches
 - affiner la récupération du contenu par clé ou par composant.
 
   </Column>
+
 </Columns>
 
 > Dans ce blog, je ne me concentrerai pas sur les solutions basées sur un compilateur, que j'ai déjà abordées ici : [Compilateur vs i18n déclaratif](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/compiler_vs_declarative_i18n.md).
@@ -79,6 +80,10 @@ Donc, de manière générale, la décision se résume ainsi :
 
 Bien sûr, les auteurs des bibliothèques sont conscients de ces limites et proposent des solutions de contournement. Parmi elles : scinder en namespaces, charger dynamiquement des fichiers JSON (`await import()`), ou purger le contenu lors du build.
 
+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.
+
+![Fuite de contenu théorique selon l'architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
 En même temps, vous devez savoir que lorsque vous chargez dynamiquement votre contenu, vous introduisez des requêtes supplémentaires vers votre serveur. Chaque `useState` supplémentaire ou hook signifie une requête serveur supplémentaire.
 
 > Pour résoudre ce point, Intlayer suggère de regrouper plusieurs définitions de contenu sous une même clé ; Intlayer fusionnera ensuite ce contenu.
@@ -111,9 +116,9 @@ Bien sûr, et c'est une avancée majeure. Regardons la comparaison de la taille
 
 Le premier exemple n'inclut pas de traductions chargées à la demande par locale et aucune séparation en namespaces. Le second inclut une purge du contenu + chargement dynamique des traductions.
 
-| Bundle optimisé                                                                                                          | Bundle non optimisé                                                                                  |
-| ------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- |
-| ![bundle non optimisé](https://github.com/aymericzip/intlayer/blob/main/docs/assets/bundle_no_optimization.png?raw=true) | ![bundle optimisé](https://github.com/aymericzip/intlayer/blob/main/docs/assets/bundle.png?raw=true) |
+| Bundle optimisé                                                                                                           | Bundle non optimisé                                                                                   |
+| ------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
+| ![bundle non optimisé](https://github.com/aymericzip/intlayer/blob/main/docs/assets/bundle_no_optimization.webp?raw=true) | ![bundle optimisé](https://github.com/aymericzip/intlayer/blob/main/docs/assets/bundle.webp?raw=true) |
 
 Donc, grâce aux namespaces, nous sommes passés de cette structure :
 

package/blog/fr/react-i18next_vs_react-intl_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2025-01-02
-updatedAt: 2025-06-29
+updatedAt: 2026-09-16
 title: react-i18next vs react-intl vs Intlayer
 description: Intégrer react-i18next avec next-intl et Intlayer pour l'internationalisation (i18n) d'une application React
 keywords:
@@ -104,6 +104,10 @@ Nous évaluons :
 
 **Pourquoi c'est important :** Des bundles plus petits et moins de chaînes inutilisées améliorent les performances au démarrage et lors de la navigation.
 
+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.
+
+![Fuite de contenu théorique selon l'architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
 ### 6) DX, outils & maintenance
 
 - **react-intl / react-i18next** : Large écosystème communautaire ; pour les flux éditoriaux, vous adoptez généralement des plateformes de localisation externes.