@intlayer/docs 9.5.6 → 9.5.8

package/blog/fr/i18next_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "i18next vs Intlayer: Benchmark & Comparatif 2026"
 description: "react-i18next et next-i18next mesurés face à Intlayer sur Next.js et TanStack Start. Taille de bundle, fuites de contenu, réactivité au changement de langue et expérience développeur."
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # i18next VS Intlayer | Benchmark d'internationalisation (i18n) React & Next.js
 
+![i18next VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `i18next` est le framework d'i18n le plus utilisé de l'écosystème JavaScript. À travers `react-i18next` et `next-i18next`, il alimente une grande partie des applications React et Next.js. Intlayer est une alternative basée sur un compilateur, découpée par composant.
 
 Cet article les compare sur des mesures concrètes plutôt que sur des listes de fonctionnalités. Les chiffres proviennent de [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), une suite open source qui compile la même application avec chaque bibliothèque et enregistre ce que le navigateur télécharge réellement.
@@ -99,6 +101,10 @@ Pour chaque build, la suite enregistre:
 
 ### Résultats sur Next.js (`next-i18next`)
 
+Sélectionnez les métriques et les bibliothèques qui vous intéressent :
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Bibliothèque                      | Stratégie      | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | Réactivité E2E | Hydratation |
 | --------------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | ----------: |
 | **base** (sans i18n)              | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |     11.8 ms |
@@ -119,6 +125,15 @@ Pour chaque build, la suite enregistre:
 - **Taille des composants.** Un composant utilisant `useTranslation()` pèse entre 26 et 79 KB selon la configuration; le même composant avec `useIntlayer()` ne pèse que 6.9 KB.
 - **L'hydratation** monte à 27.7 ms dans la configuration `dynamic`: l'instance i18next s'initialise et résout son backend côté client avant que React ne puisse hydrater la page.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Tableau complet, chaque bibliothèque et chaque stratégie, dans le [rapport de benchmark Next.js](https://intlayer.org/fr/doc/benchmark/nextjs).
+
 ### Résultats sur TanStack Start (`react-i18next`)
 
 La même application de test sur TanStack Start avec `react-i18next` pur, ce qui isole les dépendances propres à Next.js.
@@ -141,8 +156,19 @@ La même application de test sur TanStack Start avec `react-i18next` pur, ce qui
 - La ligne `static` d'Intlayer présente déjà **0% de fuite de page** car seuls les dictionnaires importés par les composants de la page sont inclus dans le bundle. Activer `importMode: 'dynamic'` supprime également la fuite de locale.
 - **Taille des composants**: 24 à 27 KB par composant avec `react-i18next` contre 6 à 8 KB avec Intlayer. `useTranslation()` lie chaque composant à l'instance globale d'i18next.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Tableau complet dans le [rapport de benchmark TanStack Start](https://intlayer.org/fr/doc/benchmark/tanstack).
+
 ## Pourquoi un tel écart? Instance globale vs dictionnaires compilés
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 `i18next` a été pensé en 2012 comme un runtime: une instance globale conserve un dépôt de ressources, des plugins l'enrichissent, et `t()` résout les clés au rendu. C'est ce qui le rend si flexible (n'importe quel framework, backend ou format) et également ce qui le rend lourd:
 
 ```bash
@@ -166,7 +192,13 @@ La même application de test sur TanStack Start avec `react-i18next` pur, ce qui
                 └── page.tsx     # doit savoir qu'elle requiert ["common", "about"]
 ```
 
-L'instance ne peut pas anticiper les clés qu'un composant demandera, elle conserve donc tous les namespaces que vous lui demandez de charger. Optimiser signifie que **vous** devez découper les catalogues en namespaces, **vous** devez lister les namespaces nécessaires à chaque page, et **vous** devez maintenir cette liste à jour quand les composants se déplacent. Comme le soulignent les [notes du benchmark](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "maintenir la sécurité des types et savoir exactement quel namespace inclure sur quelle page est un cauchemar".
+L'instance ne peut pas anticiper les clés qu'un composant demandera, elle conserve donc tous les namespaces que vous lui demandez de charger. Optimiser signifie que **vous** devez découper les catalogues en namespaces, **vous** devez lister les namespaces nécessaires à chaque page, et **vous** devez maintenir cette liste à jour quand les composants se déplacent.
+
+La facture augmente sur deux axes à la fois, les pages et les locales :
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
+Comme le soulignent les [notes du benchmark](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "maintenir la sécurité des types et savoir exactement quel namespace inclure sur quelle page est un cauchemar".
 
 Intlayer élimine l'instance. Le contenu est déclaré à côté du composant, et le compilateur résout le graphe de dépendances au build:
 
@@ -193,7 +225,8 @@ Intlayer élimine l'instance. Le contenu est déclaré à côté du composant, e
 
 ### Configuration
 
-**next-i18next (App Router)**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```ts fileName="src/app/i18n/server.ts"
 import { createInstance } from "i18next";
@@ -228,7 +261,8 @@ export const initI18next = async (
 
 Il faut y ajouter un `I18nProvider` côté client qui recrée l'instance avec les mêmes options, un `generateStaticParams`, et une liste de `namespaces` sur chaque page.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -264,9 +298,13 @@ const LocaleLayout: NextLayoutIntlayer = async ({ children, params }) => {
 export default LocaleLayout;
 ```
 
+</Tab>
+</Tabs>
+
 ### Composant client
 
-**react-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="react-i18next" value="i18next">
 
 ```json fileName="src/locales/en/about.json"
 {
@@ -304,7 +342,8 @@ export const Counter = () => {
 
 > La page affichant ce composant doit charger le namespace `about`, et `t("counter.label")` reste une simple chaîne de caractères non typée à moins d'étendre `CustomTypeOptions`.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -345,9 +384,13 @@ export const Counter = () => {
 
 `label` et `increment` sont strictement typés; une faute de frappe déclenche une erreur TypeScript, et une valeur française manquante génère une erreur au build.
 
+</Tab>
+</Tabs>
+
 ### Composant serveur synchrone
 
-**next-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -366,7 +409,8 @@ export const ServerCounter = ({ t, locale, count }: ServerCounterProps) => (
 
 La page appelle `i18n.getFixedT(locale, "about")` et fait descendre `t` et `locale` en tant que props.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -385,6 +429,9 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Gardez l'API d'i18next, profitez des performances d'Intlayer
 
 Il n'est pas nécessaire de réécrire vos composants pour bénéficier des résultats du benchmark ci-dessus. `@intlayer/i18next`, `@intlayer/react-i18next` et `@intlayer/next-i18next` sont des adaptateurs prêts à l'emploi: `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, pluriels `_one` / `_other`, suffixes de contexte et `returnObjects` continuent de fonctionner, alimentés par les dictionnaires Intlayer compilés.
@@ -415,18 +462,85 @@ Consultez les guides de migration: [i18next](https://intlayer.org/fr/doc/migrati
 
 ## Quand choisir quelle solution?
 
-- **Choisissez i18next** si vous avez besoin de son écosystème de plugins (détecteurs, backends, ICU, Locize), si vous traduisez aussi en dehors de React (services Node, vanilla JS, autres frameworks), si votre équipe le maîtrise déjà, ou si une plateforme de traduction externe exige `locales/{lng}/{ns}.json`. Prévoyez le temps de découper vos catalogues en namespaces, de configurer un backend et de maintenir la table routes-namespaces si la performance compte.
-- **Choisissez Intlayer** si vous voulez **du contenu découpé par composant**, **un typage TypeScript strict**, **des erreurs au build en cas de clé manquante**, **du tree-shaking et lazy loading sans effort**, un changement de langue instantané, des composants serveur synchrones et des outils éditoriaux intégrés (Éditeur Visuel, CMS, traduction IA, serveur MCP). Particulièrement pertinent pour les codebases modulaires et les design systems.
-- **Choisissez les adaptateurs `@intlayer/*-i18next`** si vous utilisez déjà i18next et souhaitez obtenir les gains de bundle et de réactivité sans refactoriser vos composants.
+<AccordionGroup>
+<Accordion header="Choisir i18next">
+
+Si vous avez besoin de son écosystème de plugins (détecteurs, backends, ICU, Locize), si vous traduisez aussi en dehors de React (services Node, vanilla JS, autres frameworks), si votre équipe le maîtrise déjà, ou si une plateforme de traduction externe exige `locales/{lng}/{ns}.json`. Prévoyez le temps de découper vos catalogues en namespaces, de configurer un backend et de maintenir la table routes-namespaces si la performance compte.
+
+</Accordion>
+<Accordion header="Choisir Intlayer">
+
+Vous voulez **du contenu découpé par composant**, **un typage TypeScript strict**, **des erreurs au build en cas de clé manquante**, **du tree-shaking et lazy loading sans effort**, un changement de langue instantané, des composants serveur synchrones et des outils éditoriaux intégrés ([Éditeur Visuel](https://intlayer.org/fr/doc/concept/editor), [CMS](https://intlayer.org/fr/doc/concept/cms), [traduction IA](https://intlayer.org/fr/doc/concept/auto-fill), [serveur MCP](https://intlayer.org/fr/doc/mcp-server)). Particulièrement pertinent pour les codebases modulaires et les design systems.
+
+</Accordion>
+<Accordion header="Choisir les adaptateurs @intlayer/*-i18next">
+
+Vous utilisez déjà i18next et souhaitez obtenir les gains de bundle et de réactivité sans refactoriser vos composants. Vos fichiers `locales/{lng}/{ns}.json` restent la source de vérité. Mesuré côte à côte dans [i18next vs @intlayer/i18next](https://intlayer.org/fr/blog/i18next-vs-intlayer-i18next).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Pourquoi i18next est-il tellement plus lourd que les autres bibliothèques ?">
+
+Il a été conçu comme un runtime indépendant du framework : une instance globale, un pipeline de plugins, un magasin de ressources, un résolveur de clés. Cette flexibilité est compilée dans chaque bundle. Un composant vide qui n'importe que la bibliothèque coûte **19.7 KB gzip** avec `next-i18next` contre **5.5 KB** avec `next-intlayer`, et ce coût est payé sur chaque page quel que soit le poids de votre contenu.
+
+</Question>
+
+<Question title="Le lazy loading avec un backend résout-il le problème ?">
+
+Il réduit les octets, pas la latence. Passer à `i18next-resources-to-backend` économise ~49 KB par page mais ajoute un aller-retour réseau lors du changement de langue : **123 ms** dans la configuration `dynamic` et **185 ms** dans `scoped-static`, contre **3-4 ms** avec Intlayer. L'hydratation grimpe aussi à 27.7 ms car l'instance résout son backend avant que React ne puisse hydrater.
+
+</Question>
+
+<Question title="Puis-je atteindre 0% de fuite avec i18next ?">
+
+Oui, avec `scoped-dynamic` : un namespace par route, un backend de ressources et une table de correspondance pages-namespaces maintenue à la main. On arrive à 163.4 KB par page sur Next.js, soit toujours **+22 KB** par rapport aux 141.3 KB d'Intlayer qui n'a nécessité aucune configuration. Voir l'[optimisation du bundle](https://intlayer.org/fr/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Dois-je réécrire mes composants pour migrer ?">
+
+Non. `@intlayer/i18next`, `@intlayer/react-i18next` et `@intlayer/next-i18next` conservent `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, les pluriels `_one` / `_other`, les suffixes de contexte et `returnObjects`. Une seule ligne de plugin dans `next.config.ts` ou `vite.config.ts`. Guide pas à pas dans le [guide de migration next-i18next](https://intlayer.org/fr/doc/migration/next-i18next).
+
+</Question>
+
+<Question title="Qu'advient-il de mes plugins i18next ?">
+
+Les backends et détecteurs de langue sont acceptés mais inertes : il n'y a plus rien à charger ou détecter au runtime. La détection de locale devient la configuration de routage d'Intlayer (préfixe d'URL, cookie, en-tête). Si votre application récupère des traductions depuis un CMS au moment de la requête, utilisez le [CMS d'Intlayer](https://intlayer.org/fr/doc/concept/cms) ou `intlayer pull` / `push` à la place.
+
+</Question>
+
+</FAQ>
 
 ## Comparaisons associées
 
-- [next-intl vs Intlayer](https://intlayer.org/fr/blog/next-intl-vs-intlayer) (même benchmark)
-- [Lingui vs Intlayer](https://intlayer.org/fr/blog/lingui-vs-intlayer) (même benchmark)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/fr/blog/vue-i18n-vs-intlayer-benchmark) (même benchmark)
+Même benchmark, autres bibliothèques :
+
+- [next-intl vs Intlayer](https://intlayer.org/fr/blog/next-intl-vs-intlayer)
+- [Lingui vs Intlayer](https://intlayer.org/fr/blog/lingui-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/fr/blog/vue-i18n-vs-intlayer-benchmark)
 - [next-i18next vs next-intl vs Intlayer](https://intlayer.org/fr/blog/next-i18next-vs-next-intl-vs-intlayer)
 - [react-i18next vs react-intl vs Intlayer](https://intlayer.org/fr/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Pour aller plus loin sur i18next :
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/fr/blog/i18next-vs-intlayer-i18next), les adaptateurs mesurés sur la même application
 - [i18next est-il dépassé?](https://intlayer.org/fr/blog/is-i18next-outdated)
+- [Utiliser Intlayer avec i18next](https://intlayer.org/fr/blog/intlayer-with-i18next) et [avec react-i18next](https://intlayer.org/fr/blog/intlayer-with-react-i18next)
+- [Comment internationaliser une application Next.js avec next-i18next](https://intlayer.org/fr/blog/nextjs-internationalization-using-next-i18next)
+
+Documentation de référence :
+
+- [Rapport de benchmark Next.js](https://intlayer.org/fr/doc/benchmark/nextjs) et [rapport de benchmark TanStack Start](https://intlayer.org/fr/doc/benchmark/tanstack)
+- Adaptateurs de compatibilité : [i18next](https://intlayer.org/fr/doc/compatibility/i18next), [react-i18next](https://intlayer.org/fr/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/fr/doc/compatibility/next-i18next)
+- Guides de migration : [i18next](https://intlayer.org/fr/doc/migration/i18next), [react-i18next](https://intlayer.org/fr/doc/migration/react-i18next), [next-i18next](https://intlayer.org/fr/doc/migration/next-i18next)
+- [Optimisation du bundle](https://intlayer.org/fr/doc/concept/bundle-optimization) et [le compilateur Intlayer](https://intlayer.org/fr/doc/compiler)
+- [i18n par composant vs centralisée](https://intlayer.org/fr/blog/per-component-vs-centralized-i18n)
+- [i18n pilotée par compilateur vs déclarative](https://intlayer.org/fr/blog/compiler-vs-declarative-i18n)
 
 ## Étoiles GitHub
 

package/blog/fr/is_intlayer_lighter_than_paraglide.md

@@ -0,0 +1,284 @@
+---
+createdAt: 2026-09-23
+updatedAt: 2026-09-23
+title: Intlayer est-il plus léger que Paraglide ?
+description: Paraglide semble presque gratuit dans les benchmarks i18n car son code est généré dans votre repo. Voici où se trouve réellement ce poids, pourquoi les lectures de locale par nœud vous coûtent des ressources, et comment le chargement dynamique d'Intlayer n'envoie qu'une seule locale au lieu de toutes.
+keywords:
+  - Paraglide
+  - Intlayer
+  - Internationalisation
+  - i18n
+  - Bundle size
+  - Tree shaking
+  - Benchmark
+  - Blog
+slugs:
+  - blog
+  - is-intlayer-lighter-than-paraglide
+author: aymericzip
+---
+
+# Intlayer est-il plus léger que Paraglide ?
+
+Oui.
+
+`Paraglide` a la réputation d'être la solution i18n la plus légère du marché, et à première vue le [benchmark](https://intlayer.org/fr/doc/benchmark/tanstack) semble le confirmer : la taille de sa bibliothèque est proche de zéro. Mais une taille de bibliothèque égale à zéro ne signifie pas zéro octet envoyé au client. Cela signifie simplement que les octets se trouvent à un endroit que cette métrique n'analyse pas.
+
+<TOC/>
+
+## Points clés à retenir
+
+**La taille de la bibliothèque est cachée, pas éliminée :**
+
+Paraglide génère son runtime et ses fonctions de messages directement dans votre codebase. Ce code est bel et bien envoyé au navigateur, mais il est comptabilisé comme étant _votre_ code, et non celui de la bibliothèque.
+
+**L'absence de provider n'est pas un gain gratuit :**
+
+Chaque appel `m.my_key()` résout la locale de manière autonome, en lisant le cookie ou le storage pour chaque nœud rendu, au lieu de la lire une seule fois depuis un contexte.
+
+**Aucun chargement dynamique :**
+
+Paraglide importe chaque locale d'un message dans votre bundle client. Intlayer, avec `importMode: 'dynamic'` ou `'fetch'`, ne charge que la locale actuellement affichée.
+
+**Le tree shaking n'est pas garanti :**
+
+Dans certains de nos benchmarks, le tree shaking annoncé par Paraglide n'a pas fonctionné. Vérifiez vos propres bundles.
+
+## Où passe le poids de Paraglide ?
+
+Dans les rapports de benchmark, la métrique « taille de la bibliothèque » mesure le provider et les hooks de chaque bibliothèque i18n dans un composant vide, avant l'ajout de tout contenu.
+
+| Bibliothèque (TanStack Start) | Taille lib (gz) | Taille lib (min) |
+| ----------------------------- | --------------- | ---------------- |
+| `@inlang/paraglide-js@2.15.1` | 1.8 KB          | 4.5 KB           |
+| `react-intlayer@9.5.1`        | 5.0 KB          | 15.2 KB          |
+
+Isolé de tout contexte, Paraglide semble gagner. Mais Paraglide est un compilateur : il lit vos fichiers `messages/*.json` et écrit un dossier `paraglide/` dans votre dépôt, contenant un fichier `runtime.js` (détection de locale, stratégies de cookies et de storage, localisation des URLs) ainsi qu'une fonction JavaScript par message.
+
+```bash
+src/paraglide/
+├── runtime.js      # détection de locale, stratégies, helpers d'URL
+├── server.js
+├── messages.js     # réexporte chaque message
+└── messages/
+    ├── _index.js
+    ├── en.js
+    └── fr.js
+```
+
+Puisque ce code réside dans votre dossier `src/` et que vous l'importez avec un chemin relatif, le bundler l'attribue à votre application, et non à un package tiers dans `node_modules`. La colonne de taille de bibliothèque n'affiche donc presque rien, alors que la même logique est toujours envoyée dans le bundle de votre page.
+
+Générer du code n'est pas une mauvaise idée en soi : le runtime généré n'inclut que la logique requise par votre configuration (stratégie de préfixe, cookie vs. local storage, etc.). Intlayer parvient au même résultat différemment, en injectant des variables d'environnement au moment du build afin que le bundler élimine les branches non utilisées par votre configuration. Les deux approches s'avèrent de 3 à 10 fois plus légères qu'`i18next` ou `next-intl`.
+
+La comparaison équitable ne repose donc pas sur la taille de la bibliothèque. Elle repose sur **le JavaScript réellement envoyé par page**.
+
+## Poids par page, mesuré
+
+Application TanStack Start, 10 pages, mesuré sur les routes `en` et `fr`, compressé avec gzip :
+
+| Configuration                      | JS page moy (gz) | Au-dessus de la base | Fuite de locale | Fuite autres pages |
+| ---------------------------------- | ---------------- | -------------------- | --------------- | ------------------ |
+| Base (sans i18n)                   | 111.0 KB         | -                    | 0.0%            | 0.0%               |
+| `paraglide` (toutes stratégies)    | 125.1 KB         | +14.1 KB             | 49.7%           | 0.0%               |
+| `intlayer` (`importMode: static`)  | 125.8 KB         | +14.8 KB             | 50.0%           | 0.0%               |
+| `intlayer` (`importMode: dynamic`) | **118.6 KB**     | **+7.6 KB**          | **0.0%**        | **0.0%**           |
+
+Next.js 16 App Router, même application :
+
+| Configuration    | JS page moy (gz) | Au-dessus de la base |
+| ---------------- | ---------------- | -------------------- |
+| Base (sans i18n) | 141.0 KB         | -                    |
+| `paraglide-next` | 155.3 KB         | +14.3 KB             |
+| `next-intlayer`  | **141.3 KB**     | **+0.3 KB**          |
+
+<I18nBenchmark framework="tanstack" vertical/>
+
+> Données complètes dans le [rapport de benchmark TanStack Start](https://intlayer.org/fr/doc/benchmark/tanstack) et le [rapport de benchmark Next.js](https://intlayer.org/fr/doc/benchmark/nextjs). Chaque bundle peut être inspecté dans le [dépôt du benchmark](https://github.com/intlayer-org/benchmark-i18n).
+
+Deux constats majeurs s'imposent :
+
+- En mode `static`, Intlayer envoie pratiquement le même contenu que Paraglide (125.8 KB contre 125.1 KB). C'est attendu : les deux incluent chaque locale des messages utilisés par une page.
+- Paraglide reste à 125.1 KB quelle que soit la stratégie, car il ne propose aucun mode dynamique. Chaque ligne du tableau ci-dessus correspond à la version statique.
+
+## L'absence de Provider : une fausse bonne idée
+
+Paraglide n'utilise aucun provider. Vous importez un message et vous l'appelez :
+
+```tsx fileName="Hero.tsx"
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => (
+  <section>
+    <h1>{m.hero_title()}</h1>
+    <p>{m.hero_description()}</p>
+    <button>{m.hero_cta()}</button>
+  </section>
+);
+```
+
+Pas de contexte, pas de wrapper, pas de hook. Cela semble plus simple. Pourtant, la locale doit bien être obtenue quelque part. Chaque fonction de message générée ressemble approximativement à ceci (version simplifiée) :
+
+```js fileName="paraglide/messages/_index.js"
+export const hero_title = (inputs = {}, options = {}) => {
+  const locale = options.locale ?? getLocale(); // résolu à chaque appel
+
+  if (locale === "en") return en.hero_title(inputs);
+  if (locale === "fr") return fr.hero_title(inputs);
+  // ...une branche par locale
+};
+```
+
+Et `getLocale()` parcourt l'ensemble des stratégies configurées (cookie, local storage, URL, locale de base) pour trouver la locale active. Chaque nœud de texte affiché (`<>{m.my_key()}</>`) exécute sa propre résolution de locale, ce qui implique de lire `document.cookie` dans le navigateur. Une page avec 200 chaînes traduites résout la locale 200 fois par rendu, puis à nouveau à chaque nouveau rendu.
+
+Une bibliothèque reposant sur un provider lit la locale **une seule fois**, la stocke dans un contexte (ou un signal, ou un store), et chaque nœud lit une valeur déjà présente en mémoire. Le provider coûte quelques centaines d'octets. S'en passer coûte des cycles CPU à chaque rendu, et les résultats du benchmark le montrent bien : les temps de chargement de page et de changement de langue de Paraglide sont systématiquement en retrait par rapport à Intlayer sur TanStack Start (22.1 ms contre 14.6 ms pour le chargement de page, 4.3 ms contre 3.2 ms pour la réactivité E2E).
+
+## Expérience Développeur
+
+La source de vérité de Paraglide repose sur des fichiers JSON, mais vous n'importez jamais ces JSON directement. Vous importez le fichier `.js` généré :
+
+<Tabs defaultTab="intlayer" group="techno">
+  <Tab label="Paraglide" value="paraglide">
+
+```json fileName="messages/en.json"
+{
+  "hero_title": "Ship your app in every language"
+}
+```
+
+```json fileName="messages/fr.json"
+{
+  "hero_title": "Publiez votre app dans toutes les langues"
+}
+```
+
+```tsx fileName="Hero.tsx"
+// Existe uniquement après régénération par le compilateur à partir du JSON
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => <h1>{m.hero_title()}</h1>;
+```
+
+  </Tab>
+  <Tab label="Intlayer" value="intlayer">
+
+```ts fileName="Hero.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+export default {
+  key: "hero",
+  content: {
+    title: t({
+      fr: "Publiez votre app dans toutes les langues",
+      en: "Ship your app in every language",
+    }),
+  },
+} satisfies Dictionary;
+```
+
+```tsx fileName="Hero.tsx"
+import { useIntlayer } from "react-intlayer";
+
+export const Hero = () => {
+  const { title } = useIntlayer("hero");
+
+  return <h1>{title}</h1>;
+};
+```
+
+  </Tab>
+</Tabs>
+
+Cette boucle de travail a un coût :
+
+- Chaque modification apportée à un fichier JSON nécessite une régénération avant que l'importation ne soit résolue ou que les types ne soient mis à jour.
+- Le dossier généré `paraglide/` doit soit être commité, ce qui crée des conflits de fusion sur les fichiers générés à chaque PR modifiant du texte, soit être ignoré, ce qui impose une étape de génération avant chaque vérification de types, test ou job de CI.
+- Chaque chaîne devient un appel de fonction. Les constantes se transforment partout en `m.key()`, y compris là où une simple valeur suffirait.
+
+## Tree Shaking : vérifiez votre bundle
+
+La promesse principale de Paraglide est d'éliminer les messages non utilisés via le tree shaking, puisque chaque message est son propre export. Dans le benchmark Svelte + Vite, cela fonctionne comme prévu.
+
+Dans d'autres environnements, ce n'est pas le cas. Dans notre test sur [Next.js](https://intlayer.org/fr/doc/benchmark/nextjs), les pages Paraglide pèsent 14 KB de plus que l'application de base, là où `next-intlayer` n'ajoute que 0.3 KB. Des tests précédents sur TanStack Start ont également montré que des messages d'autres pages se retrouvaient inclus dans le bundle de la route.
+
+Le tree shaking dépend fortement de votre bundler (Turbopack, Rolldown, Rollup), de la manière dont les messages sont importés (`import { m }` vs. `import * as m`), et de l'analyse des effets de bord. Si vous choisissez Paraglide pour sa taille, ouvrez votre visualiseur de bundle et vérifiez son comportement réel dans votre application.
+
+## Pas de chargement dynamique
+
+Il s'agit d'une limite structurelle. Paraglide ne permet pas de charger une seule locale à la fois : chaque fonction de message importe statiquement l'implémentation de chaque langue, de sorte que toutes les langues finissent dans votre bundle client.
+
+Avec 2 langues, cela représente la moitié de votre payload de traduction gaspillée, ce qui correspond aux ~50% de fuite de locale mesurés plus haut. Avec 10 langues, c'est 90% de gaspillage. Avec 30 langues, 97%.
+
+Passer à un chargement dynamique ne résoudrait rien : avec une fonction par message, charger chaque fonction à la demande impliquerait des milliers de requêtes réseau.
+
+Intlayer vous laisse choisir, globalement ou par dictionnaire :
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  dictionary: {
+    importMode: "dynamic", // 'static' | 'dynamic' | 'fetch'
+  },
+};
+
+export default config;
+```
+
+| `importMode` | Ce qui est envoyé au client                               | vs. Paraglide                        |
+| ------------ | --------------------------------------------------------- | ------------------------------------ |
+| `static`     | Toutes les locales des dictionnaires utilisés             | Contenu théoriquement identique      |
+| `dynamic`    | Seulement la locale active, chargée à la demande          | **N fois plus léger** avec N langues |
+| `fetch`      | Seulement la locale active, récupérée via l'API Live Sync | **N fois plus léger** avec N langues |
+
+Grâce à la [transformation au build](https://intlayer.org/fr/doc/concept/bundle-optimization) et `importMode: 'static'`, Intlayer charge, en théorie, exactement le même contenu que Paraglide. Avec `'dynamic'` ou `'fetch'`, il ne charge que ce dont la locale actuelle a besoin : pour une application disponible en N langues, le payload de traduction est divisé par N par rapport à Paraglide.
+
+## Quand Paraglide reste-t-il pertinent ?
+
+<AccordionGroup>
+<Accordion header="Svelte + Vite avec peu de langues">
+
+Si votre stack repose sur Svelte avec Vite et que vous ne gérez que deux ou trois langues, le tree shaking fonctionne comme prévu et la surcharge liée aux langues reste minime.
+
+</Accordion>
+<Accordion header="Workflow inlang existant">
+
+Si votre équipe utilise déjà l'écosystème inlang (Fink, Sherlock, plugins de format de message), Paraglide s'y intègre nativement.
+
+</Accordion>
+</AccordionGroup>
+
+## Testez sur votre application
+
+Mesurez le payload et les fuites de locales de votre application en production avec l'[i18n SEO Scanner](https://intlayer.org/i18n-seo-scanner) gratuit :
+
+<ClickToOpenIframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+Pour installer Intlayer :
+
+```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
+```
+
+## Pour aller plus loin
+
+- [Benchmark i18n TanStack Start](https://intlayer.org/fr/doc/benchmark/tanstack)
+- [Benchmark i18n Next.js](https://intlayer.org/fr/doc/benchmark/nextjs)
+- [Optimisation de bundle et `importMode`](https://intlayer.org/fr/doc/concept/bundle-optimization)
+- [Comment choisir une bibliothèque i18n pour React](https://intlayer.org/fr/blog/how-to-pick-react-i18n-library)
+- [Pourquoi choisir une internationalisation basée sur un compilateur](https://intlayer.org/fr/blog/compiler-vs-declarative-i18n)