@intlayer/docs 9.4.1 → 9.4.3

package/blog/fr/is_vue-i18n_outdated.md

@@ -0,0 +1,338 @@
+---
+createdAt: 2026-09-02
+updatedAt: 2026-09-02
+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:
+  - vue-i18n
+  - Intlayer
+  - Internationalisation
+  - i18n
+  - Vue
+  - Nuxt
+  - Taille de bundle
+  - Blog
+slugs:
+  - blog
+  - is-vue-i18n-outdated
+author: aymericzip
+---
+
+# vue-i18n est-il obsolète en 2026 ?
+
+Dans l'écosystème Vue, peu de projets sont aussi populaires que `vue-i18n`. Maintenu par Kazupon depuis Vue 2, il équipe `@nuxtjs/i18n` et sert d'outil par défaut pour la quasi-totalité des projets Vue multilingues.
+
+Pourtant, nos benchmarks 2026 ont mis en lumière un résultat inattendu : **`vue-i18n` est le runtime d'internationalisation le plus volumineux parmi tous les frameworks frontend testés.**
+
+Sur une application de base Vite + Vue très légère de 31.5 Ko, l'ajout de `vue-i18n` fait bondir le JavaScript moyen par page à **136.4 Ko**, multipliant la charge utile par plus de quatre.
+
+Comment un framework réputé pour sa légèreté en est-il arrivé à un coût i18n aussi élevé ? Et son architecture classique d'exécution a-t-elle encore du sens aujourd'hui ?
+
+<TOC/>
+
+## Points clés
+
+**Le runtime le plus lourd testé :**
+
+À **24.3 Ko gzippés (83.2 Ko minifiés)** avant même l'ajout de contenu, `vue-i18n` est environ **9 fois plus lourd** que le runtime d'`intlayer` (2.7 Ko).
+
+**Surpoids de 330% sur la charge utile :**
+
+`vue-i18n` a fait passer une page Vue de 31.5 Ko à 136.4 Ko. Intlayer stabilise la page à 59.3 Ko, soit une **charge utile 56% plus compacte**.
+
+**Un compilateur embarqué dans le navigateur :**
+
+Par défaut, sans configuration spécifique d'alias au niveau du bundler, `vue-i18n` expédie un compilateur complet dans le navigateur pour analyser les chaînes à la volée.
+
+**Rythme de maintenance :**
+
+Sur l'année écoulée, `vue-i18n` a enregistré environ 259 commits, concentrés sur des correctifs de bugs et l'alignement avec les versions de Vue.
+
+**Absence d'outillage moderne natif :**
+
+Pas de support officiel pour serveurs de langage (LSP), serveurs MCP d'IA ou commandes de traduction automatique en CLI.
+
+## Maintenance ou outillage moderne
+
+| Répertoire            | Étoiles                                                                                                                                                | Commits totaux                                                                                                                                                      | Commits / an                                                                                                                                                       | Dernier commit                                                                                                                               |
+| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- |
+| `intlify/vue-i18n`    | [![stars](https://img.shields.io/github/stars/intlify/vue-i18n?style=for-the-badge&label=stars)](https://github.com/intlify/vue-i18n/stargazers)       | [![commits](https://img.shields.io/github/commit-activity/t/intlify/vue-i18n?style=for-the-badge&label=commits)](https://github.com/intlify/vue-i18n/commits)       | [![yearly](https://img.shields.io/github/commit-activity/y/intlify/vue-i18n?style=for-the-badge&label=%2Fyear)](https://github.com/intlify/vue-i18n/commits)       | [![last](https://img.shields.io/github/last-commit/intlify/vue-i18n?style=for-the-badge)](https://github.com/intlify/vue-i18n/commits)       |
+| `aymericzip/intlayer` | [![stars](https://img.shields.io/github/stars/aymericzip/intlayer?style=for-the-badge&label=stars)](https://github.com/aymericzip/intlayer/stargazers) | [![commits](https://img.shields.io/github/commit-activity/t/aymericzip/intlayer?style=for-the-badge&label=commits)](https://github.com/aymericzip/intlayer/commits) | [![yearly](https://img.shields.io/github/commit-activity/y/aymericzip/intlayer?style=for-the-badge&label=%2Fyear)](https://github.com/aymericzip/intlayer/commits) | [![last](https://img.shields.io/github/last-commit/aymericzip/intlayer?style=for-the-badge)](https://github.com/aymericzip/intlayer/commits) |
+
+Activité sur les douze derniers mois :
+
+- `intlify/vue-i18n` : **259 commits** (maintenance continue pour Vue 3 et Nuxt).
+- `aymericzip/intlayer` : **4 343 commits** (optimisations de compilation, intégrations LSP et outillage pour agents IA).
+
+[![Star History Chart](https://api.star-history.com/chart?repos=intlify%2Fvue-i18n%2Caymericzip%2Fintlayer&type=date&legend=top-left)](https://www.star-history.com/#intlify/vue-i18n&aymericzip/intlayer)
+
+Une bibliothèque éprouvée a l'avantage de la maturité. Cependant, les stacks modernes s'appuient sur la transformation AST au build, l'élimination du code mort et la localisation assistée par IA. Un système reposant principalement sur l'exécution dynamique peine à intégrer ces gains.
+
+## Mesure des performances avec Vite + Vue
+
+Benchmark réalisé sur une application de 10 pages et 10 langues avec Vite et Vue 3 :
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Tests réalisés dans de vrais navigateurs avec compression gzip. Données exhaustives dans la [documentation du benchmark Vue](https://intlayer.org/fr/doc/benchmark/vue).
+
+### Poids initial des bibliothèques
+
+Surcharge initiale avant l'ajout des textes de traduction :
+
+| Bibliothèque      | Gzippé     | Minifié    |
+| ----------------- | ---------- | ---------- |
+| `vue-i18n@11.4.0` | 24.3 Ko    | 83.2 Ko    |
+| `intlayer@8.7.12` | **2.7 Ko** | **7.6 Ko** |
+
+Le moteur de `vue-i18n` pèse **24.3 Ko gzippés**, soit presque le poids du cœur de Vue lui-même. Intlayer n'ajoute que **2.7 Ko**.
+
+### Poids des pages et dispersion des contenus
+
+| Configuration    | JS moyen / page (gz) | Fuite de langues | Fuite autres pages | Composant moyen (gz) |
+| ---------------- | -------------------- | ---------------- | ------------------ | -------------------- |
+| Base (sans i18n) | 31.5 Ko              | 0.0%             | 90.0%              | 0.9 Ko               |
+| `vue-i18n`       | **136.4 Ko**         | 50.2%            | 90.0%              | 196.0 Ko             |
+| Intlayer         | **59.3 Ko**          | 51.1%            | **0.0%**           | **6.5 Ko**           |
+
+### Principaux constats
+
+**Gonflement proportionnel marquant :**
+
+Comme la base Vue est très épurée (~31 Ko), l'impact de `vue-i18n` multiplie par plus de quatre la charge utile globale.
+
+**Fuite vers d'autres pages :**
+
+Par défaut, **90% des textes traduits** envoyés à une route appartiennent à d'autres pages. Intlayer élimine complètement cette fuite pour atteindre **0.0%**.
+
+**Poids des composants isolés :**
+
+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.
+
+## Pourquoi vue-i18n est-il lourd ?
+
+### Un compilateur AST embarqué dans le navigateur
+
+`vue-i18n` intègre son propre compilateur de messages. Les règles de pluriel et les interpolations sont analysées en arbres syntaxiques abstraits directement lors de l'exécution.
+
+Pour contourner ce surcoût, il faut configurer des alias bundler vers `vue-i18n/dist/vue-i18n.runtime.esm-bundler.js` et précompiler les catalogues via `@intlify/unplugin-vue-i18n`. Beaucoup de projets omettent cette étape et livrent sans le savoir un compilateur complet à leurs utilisateurs.
+
+### Un périmètre monolithique
+
+`vue-i18n` regroupe des moteurs de dates, de nombres, des ponts pour l'Options API legacy (`$t`, `v-t`) et des proxys réactifs. Même pour afficher de simples textes dans `<script setup>`, l'ensemble de ces briques est chargé.
+
+### Les clés dynamiques bloquent le tree-shaking
+
+Puisque `"home.hero.title"` est une chaîne résolue au runtime, les bundlers ne peuvent pas vérifier quelles traductions sont réellement utilisées. Les textes inutilisés ne peuvent donc pas être supprimés.
+
+<Tabs defaultTab="intlayer" group="techno">
+  <Tab label="vue-i18n" value="vue-i18n">
+
+```vue fileName="Hero.vue"
+<script setup>
+import { useI18n } from "vue-i18n";
+
+const { t } = useI18n();
+</script>
+
+<template>
+  <h1>{{ t("home.hero.title") }}</h1>
+</template>
+```
+
+  </Tab>
+  <Tab label="Intlayer" value="intlayer">
+
+```vue fileName="Hero.vue"
+<script setup>
+import { useIntlayer } from "vue-intlayer";
+
+const { title } = useIntlayer("hero");
+</script>
+
+<template>
+  <h1>{{ title }}</h1>
+</template>
+```
+
+  </Tab>
+</Tabs>
+
+Le [compilateur Intlayer](https://intlayer.org/fr/doc/compiler) trace précisément les propriétés invoquées et élimine le contenu non utilisé avant l'assemblage des bundles clients. Voir [l'optimisation de bundle](https://intlayer.org/fr/doc/concept/bundle-optimization) pour approfondir.
+
+## Expérience développeur
+
+### Catalogues distants ou co-localisation
+
+Avec `vue-i18n`, les traductions sont regroupées dans un répertoire `locales/` distant. Intlayer co-localise les fichiers de contenu directement à côté des composants :
+
+<Tabs defaultTab="intlayer" group="techno">
+  <Tab label="vue-i18n" value="vue-i18n">
+
+```json fileName="locales/en.json"
+{
+  "hero": {
+    "title": "Ship in every language"
+  }
+}
+```
+
+```json fileName="locales/fr.json"
+{
+  "hero": {
+    "title": "Livrez dans toutes les langues"
+  }
+}
+```
+
+```vue fileName="Hero.vue"
+<script setup>
+import { useI18n } from "vue-i18n";
+
+const { t } = useI18n();
+</script>
+
+<template>
+  <h1>{{ t("hero.title") }}</h1>
+</template>
+```
+
+  </Tab>
+  <Tab label="Intlayer" value="intlayer">
+
+```ts fileName="Hero.content.ts"
+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;
+```
+
+```vue fileName="Hero.vue"
+<script setup>
+import { useIntlayer } from "vue-intlayer";
+
+const { title } = useIntlayer("hero");
+</script>
+
+<template>
+  <h1>{{ title }}</h1>
+</template>
+```
+
+  </Tab>
+</Tabs>
+
+Lorsque `Hero.vue` est supprimé ou renommé, son fichier de contenu est déplacé ou supprimé simultanément.
+
+### Autocomplétion ou validation stricte de l'exhaustivité
+
+`DefineLocaleMessage` fournit l'autocomplétion IDE sur la base du schéma canonique. Il ne garantit toutefois pas que toutes les langues soient complètes. Oublier une clé dans `fr.json` ne déclenche aucune erreur TypeScript au build.
+
+Avec Intlayer, les dictionnaires sont validés strictement. L'activation du [`strictMode`](https://intlayer.org/fr/doc/concept/configuration) bloque la compilation dès qu'une traduction fait défaut.
+
+### Outillage pour les IDEs et l'IA
+
+| Fonctionnalité               | `vue-i18n`         | Intlayer                                                                    |
+| ---------------------------- | ------------------ | --------------------------------------------------------------------------- |
+| **Extension VS Code**        | Tierce (i18n Ally) | ✅ [Extension officielle](https://intlayer.org/fr/doc/vs-code-extension)    |
+| **Serveur de langage (LSP)** | ❌ Aucun           | ✅ [LSP intégré](https://intlayer.org/fr/doc/lsp)                           |
+| **Serveur MCP pour l'IA**    | ❌ Aucun           | ✅ [Serveur MCP inclus](https://intlayer.org/fr/doc/mcp-server)             |
+| **Compétences agents**       | ❌ Aucune          | ✅ [Compétences autonomes](https://intlayer.org/fr/doc/agent_skills)        |
+| **CMS visuel en contexte**   | ❌ Aucun           | ✅ [CMS gratuit et open source](https://intlayer.org/fr/doc/concept/editor) |
+
+## Pipelines de traduction
+
+`vue-i18n` n'intègre pas de commande de traduction native. Les équipes doivent exporter leurs fichiers vers des solutions tierces comme Crowdin ou Phrase.
+
+Intlayer intègre ces fonctionnalités directement :
+
+**Traduction automatique par IA locale (`intlayer fill`) :**
+
+Complète automatiquement les traductions absentes grâce à vos clés API OpenAI, Anthropic, Mistral ou Gemini.
+
+**CMS visuel auto-hébergeable :**
+
+Déployez le [CMS Intlayer](https://intlayer.org/fr/doc/concept/cms) pour permettre aux équipes éditoriales de modifier le contenu avec validation directe dans Git.
+
+**Licence libre et ouverte :**
+
+L'ensemble de la suite est sous licence Apache 2.0.
+
+## Dans quels cas vue-i18n reste-t-il pertinent ?
+
+<AccordionGroup>
+<Accordion header="Projets Nuxt 2 ou Nuxt 3 existants">
+
+Si votre routage est intimement lié à `@nuxtjs/i18n`, une refonte n'est pas toujours prioritaire.
+
+</Accordion>
+<Accordion header="Besoins pointus en ICU">
+
+Si votre produit utilise des formats de dates avancés, des messages liés ou des règles de pluriels très particulières.
+
+</Accordion>
+<Accordion header="Projets personnels modestes">
+
+Si la taille finale du bundle n'est pas un facteur déterminant pour vous.
+
+</Accordion>
+</AccordionGroup>
+
+## Comment améliorer ma configuration vue-i18n existante ?
+
+Intlayer propose des packages de compatibilité prêts à l'emploi qui reprennent à l'identique les signatures de fonctions de `vue-i18n` et `@nuxtjs/i18n` (`useI18n`, `$t`, `<i18n-t>`). Vous n'avez pas besoin de réécrire vos templates ou vos composables pour profiter d'une architecture légère optimisée par la compilation.
+
+L'installation s'effectue en une seule commande :
+
+```bash packageManager="npm"
+npx intlayer init --interactive
+```
+
+```bash packageManager="pnpm"
+pnpm dlx intlayer init --interactive
+```
+
+```bash packageManager="yarn"
+yarn dlx intlayer init --interactive
+```
+
+```bash packageManager="bun"
+bunx intlayer init --interactive
+```
+
+Cette CLI interactive :
+
+1. Installe le package de compatibilité `@intlayer/vue-i18n` ou `@intlayer/nuxt-i18n`.
+2. Configure les alias du bundler (Vite ou Nuxt) afin que vos imports et balises de template habituels soient redirigés vers Intlayer, vous permettant de retirer `vue-i18n` de votre `package.json`.
+3. Active immédiatement le support du serveur de langage (LSP), élimine le parseur AST de 24 Ko de votre bundle client et débloque les flux de traduction IA locale sans refactorisation complexe.
+
+Pour des instructions détaillées étape par étape, consultez nos guides dédiés :
+
+- **Compatibilité directe :** Conservez vos templates actuels avec la [couche de compatibilité `vue-i18n`](https://intlayer.org/fr/doc/compatibility/vue-i18n) ou [`@nuxtjs/i18n`](https://intlayer.org/fr/doc/compatibility/nuxtjs-i18n).
+- **Guides de migration automatisée :** Convertissez vos fichiers JSON vers des dictionnaires typés grâce à nos guides : [depuis vue-i18n](https://intlayer.org/fr/doc/migration/vue-i18n) ou [depuis @nuxtjs/i18n](https://intlayer.org/fr/doc/migration/nuxtjs-i18n).
+- **Configuration hybride :** Conservez `vue-i18n` à l'exécution tout en [utilisant Intlayer avec vue-i18n](https://intlayer.org/fr/blog/intlayer-with-vue-i18n) pour bénéficier du typage strict et de la traduction locale par IA.
+
+Évaluez le volume de transfert et les fuites de votre application avec le [scanner SEO i18n gratuit](https://intlayer.org/i18n-seo-scanner) :
+
+<ClickToOpenIframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Lectures complémentaires
+
+- [Benchmark i18n Vue & Vite : analyse complète des performances](https://intlayer.org/fr/doc/benchmark/vue)
+- [vue-i18n vs Intlayer : comparatif point par point](https://intlayer.org/fr/blog/vue-i18n-vs-intlayer)
+- [next-intl est-il obsolète en 2026 ?](https://intlayer.org/fr/blog/is-next-intl-outdated)
+- [Internationalisation par compilation vs déclarative](https://intlayer.org/fr/blog/compiler-vs-declarative-i18n)

package/blog/fr/list_i18n_technologies/build-tools/vite.md

@@ -0,0 +1,179 @@
+---
+createdAt: 2026-09-02
+updatedAt: 2026-09-02
+title: "Vite i18n : imports glob, chunks et messages au build"
+description: Ce qui est réellement spécifique à Vite dans l'i18n. Catalogues asynchrones avec import.meta.glob, découpage par route, limites du HMR et plugins au build.
+keywords:
+  - vite i18n
+  - import.meta.glob
+  - vite code splitting
+  - lazy load traductions
+  - vite plugin i18n
+  - rollup chunks
+slugs:
+  - blog
+  - i18n-technologies
+  - build-tools
+  - vite
+author: aymericzip
+---
+
+# Vite i18n : les mécanismes propres à Vite, pas à votre framework
+
+La plupart des tutoriels "Vite i18n" sont en réalité des guides React ou Vue qui se trouvent utiliser Vite. Cet article s'intéresse à la couche sous-jacente : comment les catalogues sont importés, ce que Rollup en fait et pourquoi le lazy loading que vous avez écrit n'est probablement pas si asynchrone que vous le croyez.
+
+## Table des matières
+
+<TOC/>
+
+## L'import statique est le choix par défaut, et il est synchrone
+
+La configuration la plus intuitive importe chaque catalogue au sommet d'un module.
+
+```ts fileName="src/i18n.ts"
+import en from "./locales/en.json";
+import fr from "./locales/fr.json";
+import ja from "./locales/ja.json";
+```
+
+Cela place trois catalogues dans le chunk d'entrée initial, sur chaque page, pour chaque visiteur. C'est tolérable pour deux locales et une centaine de chaînes. Dès dix locales, c'est le surcoût évitable le plus lourd de votre bundle.
+
+## `import.meta.glob` et l'option que tout le monde configure mal
+
+L'import par motif (glob import) de Vite constitue la solution habituelle.
+
+```ts
+const catalogs = import.meta.glob("./locales/*.json");
+
+export const loadCatalog = async (locale: string) => {
+  const load = catalogs[`./locales/${locale}.json`];
+  return (await load()) as Record<string, string>;
+};
+```
+
+Le chargement asynchrone (lazy) est activé par défaut : chaque entrée est une fonction renvoyant un import dynamique, et Rollup génère un chunk par fichier. Ajouter `{ eager: true }` incorpore tout le contenu directement dans le module appelant, ce qui annule précisément l'optimisation visée.
+
+```ts
+// Toutes les locales dans le chunk d'entrée. Presque jamais ce que l'on souhaite.
+const catalogs = import.meta.glob("./locales/*.json", { eager: true });
+```
+
+Le piège est que les deux variantes fonctionnent parfaitement en dev, car Vite sert les modules de manière non empaquetée. La différence n'apparaît que dans le dossier `dist`. Vérifiez avec `npx vite build && npx vite preview`, puis examinez ce que contient réellement le chunk d'entrée.
+
+## Le découpage par route découpe rarement comme prévu
+
+Voici un comportement qui surprend fréquemment. Vous organisez vos catalogues par page :
+
+```
+locales/en/home.json
+locales/en/checkout.json
+```
+
+Puis deux routes distinctes importent toutes deux `checkout.json`, et Rollup hisse ce fichier dans un chunk commun chargé par les deux pages. La stratégie de découpage de Rollup est guidée par le graphe de dépendances, et non par le nom de vos dossiers : un module accessible depuis plusieurs points d'entrée devient partagé. Ajouter une troisième route qui l'utilise ne change rien, et une quatrième peut réorganiser la répartition différemment.
+
+Le découpage par route ne tient donc que si votre graphe d'importation est strictement disjoint. Si cela compte pour votre budget de performance, mesurez-le plutôt que de le supposer :
+
+```bash
+npx vite build && npx vite-bundle-visualizer
+```
+
+Si vous devez impérativement forcer la frontière de découpage, `build.rollupOptions.output.manualChunks` constitue la porte de sortie, au prix d'une maintenance manuelle.
+
+## Les catalogues ne bénéficient pas du rechargement à chaud (HMR)
+
+Modifiez un composant, Vite le met à jour instantanément. Modifiez `locales/fr.json` et, selon la manière dont il est importé, rien ne se passe. Le JSON importé dynamiquement ne possède pas de frontière HMR native, de sorte que le graphe de modules ne sait pas comment invalider les consommateurs.
+
+Les développeurs contournent souvent cela en redémarrant le serveur de dev à chaque modification de texte, sans réaliser que cela peut être évité. La solution incombe au plugin i18n : il doit intercepter la mise à jour HMR et injecter les nouveaux messages dans l'application en cours d'exécution. Lors du choix d'une bibliothèque, vérifiez si son plugin Vite gère cela, car c'est un point de friction quotidien.
+
+## `define` fige la locale dans le marbre
+
+Il est tentant de résoudre la locale par défaut au moment du build :
+
+```ts fileName="vite.config.ts"
+export default defineConfig({
+  define: {
+    __DEFAULT_LOCALE__: JSON.stringify(process.env.LOCALE ?? "en"),
+  },
+});
+```
+
+`define` procède à un remplacement textuel pur exécuté à la compilation. La valeur injectée au build est celle qui sera livrée, ce qui vous contraint à un build séparé par langue. C'est une stratégie légitime, et c'est exactement ce que propose l'i18n officielle d'Angular. Mais ce n'est pas ce que vous cherchez si un déploiement unique doit servir toutes les langues.
+
+Pour les valeurs qui doivent varier à chaque requête, évitez `define` et résolvez-les au runtime.
+
+## Déplacer l'analyse des messages au build
+
+Toute solution mature dans cet écosystème converge vers le même principe : cesser de parser les messages dans le navigateur.
+
+| Plugin                       | Ce qu'il déplace au build                                               |
+| :--------------------------- | :---------------------------------------------------------------------- |
+| `@intlify/unplugin-vue-i18n` | Compile les messages vue-i18n en fonctions de rendu (build runtime pur) |
+| Lingui (macro + plugin)      | Extrait et compile les catalogues, remplace les macros par des IDs      |
+| Paraglide (inlang)           | Compile chaque message en sa propre fonction tree-shakable              |
+| `vite-intlayer`              | Construit les dictionnaires par composant, purge et minifie l'inutilisé |
+
+Le bénéfice est double : le compilateur de messages au runtime n'est plus embarqué dans le bundle, et les entrées inutilisées deviennent supprimables statiquement. Le coût associé est que votre serveur de dev et votre CI doivent tous deux exécuter le plugin, et un simple `tsc` ou un exécuteur de tests non-Vite nécessitera une configuration d'alias supplémentaire.
+
+vue-i18n illustre parfaitement le premier bénéfice. Sans `@intlify/unplugin-vue-i18n`, vous livrez un compilateur qui fait appel à `new Function`, ce qui représente à la fois des octets superflus et un problème de Content Security Policy (CSP).
+
+## SSR : ne stockez jamais la locale dans l'état d'un module
+
+Si vous utilisez le SSR, que ce soit via un framework ou `vite-plugin-ssr`, la règle absolue est la suivante : une variable au niveau du module contenant la locale courante est partagée entre toutes les requêtes concurrentes sur ce processus serveur.
+
+```ts
+// Sans danger dans un navigateur. Une fuite de données entre requêtes sur un serveur.
+export let currentLocale = "en";
+```
+
+Deux utilisateurs interrogeant le serveur simultanément vont entrer en concurrence, et l'un recevra la langue de l'autre. Le problème est invisible en développement local car vous êtes le seul visiteur. Résolvez la locale par requête et transmettez-la explicitement via le contexte ou le stockage local de requête de votre framework.
+
+## Le plugin Vite d'Intlayer
+
+Intlayer intègre un plugin unique qui prend en charge la compilation des dictionnaires, l'observation des modifications en dev et le pipeline d'optimisation.
+
+```ts fileName="vite.config.ts"
+import react from "@vitejs/plugin-react";
+import { defineConfig } from "vite";
+import { intlayer } from "vite-intlayer";
+
+export default defineConfig({
+  plugins: [react(), intlayer()],
+});
+```
+
+La réécriture d'imports, la purge et la minification sont activées par défaut. Les deux options clés se trouvent dans `intlayer.config.ts` :
+
+```ts fileName="intlayer.config.ts"
+import type { IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  build: {
+    purge: true, // supprime les champs qu'aucun composant ne lit
+    minify: true, // renomme les clés en alias courts
+  },
+};
+
+export default config;
+```
+
+Puisque le contenu est déclaré par composant plutôt que dans de gros fichiers globaux par langue, la passe de purge s'appuie sur le graphe de modules, ce qui sécurise l'élagage. Le compromis reste le même : le plugin devient requis partout où le code est compilé, y compris en CI et dans les runners de tests. Détails dans [l'optimisation de bundle](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/bundle_optimization.md).
+
+## Erreurs courantes
+
+- **`{ eager: true }` sur un glob que l'on pensait charger à la demande.** Fonctionne en dev, livre toutes les langues en production.
+- **Croire que la structure des dossiers détermine les chunks.** Rollup suit les imports, pas l'arborescence. Mesurez votre build.
+- **Redémarrer le serveur de dev pour voir un changement de texte.** C'est le symptôme d'un gestionnaire HMR absent, pas un comportement normal.
+- **Mettre la locale dans `define`.** Vous vous engagez à devoir créer un build par langue.
+- **État de locale au niveau du module en SSR.** Fuite de données entre requêtes indétectable en local.
+- **Prendre le serveur de dev comme référence de performance.** Les modules non empaquetés ne reflètent en rien la réalité du bundle de production.
+
+## Pour aller plus loin
+
+- [Optimisation du bundle : purge, minification et ce qui parvient au navigateur](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/bundle_optimization.md)
+- [Rapports de benchmark entre frameworks](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/benchmark/index.md)
+- [Référence de configuration](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/configuration.md)
+- [Configurer Intlayer avec Vite et React](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/intlayer_with_vite+react.md)
+- [Adaptateur de compatibilité i18next](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/compat/i18next.md)
+- [React i18n : fonctionnement du modèle de providers](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/list_i18n_technologies/frameworks/react.md)
+- [Vue i18n : son fonctionnement et ses limites](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/list_i18n_technologies/frameworks/vue.md)
+- [i18n par composant vs i18n centralisée](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/per-component_vs_centralized_i18n.md)

package/blog/fr/list_i18n_technologies/frameworks/angular.md

@@ -25,8 +25,6 @@ Dans un monde interconnecté d'aujourd'hui, proposer votre site web en plusieurs
 
 ---
 
-![i18n illustration](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18n.webp)
-
 ## Qu'est-ce que l'internationalisation (i18n) ?
 
 L'internationalisation, souvent appelée i18n, est le processus de conception et de préparation de votre application pour prendre en charge plusieurs langues et contextes culturels. Dans Angular, cela implique de configurer votre application afin que le texte, les dates, les nombres et même les mises en page de l'interface utilisateur puissent s'adapter de manière transparente à différents locales. Établir correctement cette base garantit que l'intégration de futures traductions reste organisée et efficace.

package/blog/fr/list_i18n_technologies/frameworks/react-native.md

@@ -25,8 +25,6 @@ Dans un marché global de plus en plus concurrentiel, proposer votre application
 
 ---
 
-![illustration i18n](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18n.webp)
-
 ## Qu'est-ce que l'internationalisation (i18n)?
 
 L'internationalisation, ou i18n, implique la structuration d'une application afin qu'elle puisse facilement s'adapter à différentes langues, formats régionaux et normes culturelles. Dans React Native, l'i18n inclut la gestion des chaînes de caractères pour les boutons et les étiquettes, ainsi que le formatage des dates, des heures, des devises, et plus encore en fonction de la locale de l'utilisateur. Des applications React Native correctement préparées vous permettent d'intégrer facilement des langues supplémentaires et des comportements spécifiques à une locale ultérieurement, sans nécessiter de refontes massives.

package/blog/fr/list_i18n_technologies/frameworks/react.md

@@ -25,8 +25,6 @@ Dans le paysage numérique d'aujourd'hui, étendre la portée de votre site web
 
 ---
 
-![i18n illustration](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18n.webp)
-
 ## Qu'est-ce que l'Internationalisation (i18n) ?
 
 L'internationalisation, abrégée en i18n, est le processus de conception et de préparation de votre site web pour prendre en charge plusieurs langues et contextes culturels. Dans React, cela signifie configurer votre application de manière à ce que les chaînes, les formats de date, les formats de nombre, et même la mise en page puissent être facilement adaptés pour les utilisateurs de différentes régions. Préparer votre application React pour l'i18n pose les bases d'une intégration propre des traductions et d'autres fonctionnalités de localisation.

package/blog/fr/list_i18n_technologies/frameworks/svelte.md

@@ -25,8 +25,6 @@ Au fur et à mesure que le web continue de connecter les gens à travers le mond
 
 ---
 
-![illustration i18n](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18n.webp)
-
 ## Qu'est-ce que l'internationalisation (i18n)?
 
 L'internationalisation, couramment abrégée en i18n, est le processus de conception et de construction de votre application de manière à ce qu'elle puisse facilement s'adapter à diverses langues, régions et conventions culturelles. Dans Svelte, cela signifie généralement la mise en place de chaînes de traduction, la localisation des dates, heures et nombres, et garantir que l'interface utilisateur peut passer dynamiquement d'une locale à l'autre sans réécritures majeures du code.

package/blog/fr/list_i18n_technologies/frameworks/vue.md

@@ -25,8 +25,6 @@ Dans un paysage numérique de plus en plus mondialisé, étendre la portée de v
 
 ---
 
-![illustration i18n](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18n.webp)
-
 ## Qu'est-ce que l'internationalisation (i18n) ?
 
 L'internationalisation (i18n) est la pratique de préparer une application logicielle (ou un site Web) pour plusieurs langues et conventions culturelles. Dans l'écosystème Vue.js, cela inclut l'établissement de la manière dont le texte, les dates, les nombres, la monnaie et d'autres éléments localisables peuvent être adaptés à diverses locales. En configurant l'i18n depuis le début, vous assurez une structure organisée et évolutive pour ajouter de nouvelles langues et gérer les futurs besoins en localisation.

package/blog/fr/what_is_internationalization.md

@@ -20,8 +20,6 @@ author: aymericzip
 
 # Qu'est-ce que l'internationalisation (i18n) ? Définition et défis
 
-![illustration de l'i18n](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18n.webp)
-
 ## Comprendre l'internationalisation (i18n)
 
 **L'internationalisation**, souvent abrégée en **i18n**, est le processus de conception et de préparation d'une application pour prendre en charge plusieurs langues, cultures et conventions régionales **sans** changements majeurs dans le code. Le nom i18n est dérivé du fait qu'il y a 18 lettres entre le **i** et le **n** dans le mot “internationalisation”.