@intlayer/docs 9.5.6 → 9.5.7

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/lingui_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "Lingui vs Intlayer: Benchmark & Comparaison 2026"
 description: Deux bibliothèques i18n basées sur compiler mesurées sur Next.js et TanStack Start. Taille du bundle, fuite de contenu, taille du composant, hydratation, réactivité du changement de locale et expérience développeur.
 keywords:
@@ -24,6 +24,8 @@ author: aymericzip
 
 # Lingui VS Intlayer | Benchmark d'Internationalization (i18n) React & Next.js
 
+![JavaScript i18n library ecosystem](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
+
 Lingui et Intlayer sont les deux bibliothèques de ce benchmark qui s'appuient sur un **compilateur** plutôt que sur un runtime pur. Lingui extrait les messages des macros au moment de la compilation et compile les catalogues par locale. Intlayer compile les dictionnaires par composant et les tree-shake par locale. Sur le papier, ils devraient être proches. Les chiffres montrent où ils divergent.
 
 Les données proviennent de [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), une suite open-source qui construit la même application avec chaque bibliothèque et enregistre ce que le navigateur télécharge et exécute réellement.
@@ -96,6 +98,10 @@ Pour chaque build, la suite enregistre :
 
 ### Résultats sur Next.js
 
+Sélectionnez les métriques et les bibliothèques qui vous intéressent :
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Library              | Strategy       | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity | Hydration |
 | -------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | --------: |
 | **base** (sans i18n) | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |   11.8 ms |
@@ -114,6 +120,15 @@ Pour chaque build, la suite enregistre :
 - **La source-locale fallback fuit.** Même dans les configurations optimisées, **3-15% des chaînes `en` sont incluses dans les pages `fr`**. Les macros Lingui conservent le message source disponible comme fallback, ce qui se retrouve dans le bundle à côté de la traduction. Intlayer résout les fallbacks au moment de la compilation et ne livre que la locale active.
 - **La taille du composant explose en `scoped-dynamic`.** Chaque composant compilé isolément fait en moyenne **152.6 KB**, car le catalog de chaque route est accessible depuis le composant qui l'importe. Le même composant avec `useIntlayer()` fait en moyenne **6.9 KB**.
 
+<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
 
 | Library                     | Strategy       | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity | Hydration |
@@ -135,8 +150,19 @@ Pour chaque build, la suite enregistre :
 - **La ligne `static` d'Intlayer a déjà 0% de fuite de page** car seuls les dictionnaires importés par les composants de la page sont regroupés. Une ligne de config (`importMode: 'dynamic'`) supprime aussi la fuite de locale.
 - **`@intlayer/lingui`** conserve la syntaxe des macros de Lingui et les sert à partir des dictionnaires Intlayer. Il échange une taille de page plus importante (137 KB, puisque le runtime des macros reste) pour des composants plus petits (12.8 KB) et une hydratation plus rapide que Lingui natif. C'est une étape de migration, pas la destination.
 
+<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 l'écart ? Deux compilateurs, deux unités de travail
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Les deux bibliothèques compilent. La différence est **ce qu'** elles compilent.
 
 **Lingui compile des catalogues.** Les macros dans votre source sont extraites dans un fichier `.po` par locale, puis compilées dans un module JS par locale. L'unité est la **locale**. Diviser davantage, par route ou par composant, signifie créer plusieurs catalogues, configurer `lingui.config.ts` pour extraire chacun d'un ensemble différent de fichiers, et charger le bon dans chaque route. L'instance `I18n` au runtime est globale ; chaque appel `useLingui()` souscrit le composant à celle-ci.
@@ -176,7 +202,9 @@ Les deux bibliothèques compilent. La différence est **ce qu'** elles compilent
             └── about.content.ts
 ```
 
-C'est pourquoi le pattern `scoped-dynamic` est une sortie de build pour Intlayer et une configuration de projet pour Lingui.
+C'est pourquoi le pattern `scoped-dynamic` est une sortie de build pour Intlayer et une configuration de projet pour Lingui. L'écart se creuse 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)
 
 > Pour obtenir les numéros de la ligne `dynamic`, définissez `dictionary.importMode: 'dynamic'` dans `intlayer.config.ts`. Voir la [documentation d'optimisation du bundle](https://intlayer.org/doc/fr/concept/bundle-optimization).
 
@@ -184,7 +212,8 @@ C'est pourquoi le pattern `scoped-dynamic` est une sortie de build pour Intlayer
 
 ### Configuration
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```ts fileName="lingui.config.ts"
 import { defineConfig } from "@lingui/cli";
@@ -215,7 +244,8 @@ export const loadCatalog = async (locale: string) => {
 
 Puis ajoutez `@lingui/babel-plugin-lingui-macro` (ou `@lingui/swc-plugin`) au bundler, exécutez `lingui extract` après avoir modifié la source, `lingui compile` avant de construire, et enveloppez l'arborescence dans `<I18nProvider i18n={i18n}>`.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -232,9 +262,12 @@ export default config;
 
 Ajoutez `intlayer()` à `vite.config.ts` (ou `withIntlayer()` à `next.config.ts`) et enveloppez l'arborescence dans `<IntlayerProvider>`. Aucune étape d'extraction ou de compilation : les dictionnaires sont construits lors de l'exécution du bundler.
 
+</Tab>
+</Tabs>
 ### Composant
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```tsx fileName="src/components/Counter.tsx"
 import { useState } from "react";
@@ -258,7 +291,8 @@ export const Counter = () => {
 
 Le texte anglais se trouve dans le composant ; le texte français se trouve dans `src/locales/fr/messages.po` sous un ID haché, après l'exécution de `lingui extract`. Oublier de l'exécuter ou d'exécuter `compile` bascule silencieusement vers l'anglais.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -297,11 +331,14 @@ export const Counter = () => {
 
 Les deux locales se trouvent dans un seul fichier à côté du composant. Une valeur `fr` manquante est une erreur de build, une clé incorrecte est une erreur TypeScript.
 
+</Tab>
+</Tabs>
 ### En dehors des composants
 
 Métadonnées, loaders, fonctions serveur : partout sans arborescence React.
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```ts fileName="src/routes/$locale/about.tsx"
 import { setupI18n } from "@lingui/core";
@@ -324,7 +361,8 @@ export const loader = async ({ params }: { params: { locale: string } }) => {
 
 Une nouvelle instance `I18n` par appel, le bon catalogue chargé manuellement, et `msg` + `i18n._()` au lieu de `t`. Comme le [benchmark le note](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md), savoir quand utiliser `t`, `` t` ` ``, `i18n.t()`, `msg` ou `<Trans>` « n'est pas intuitif ».
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/routes/$locale/about.tsx"
 import { getIntlayer } from "intlayer";
@@ -336,6 +374,9 @@ export const loader = async ({ params }: { params: { locale: string } }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Conservez les macros Lingui, obtenez les dictionnaires Intlayer
 
 `@intlayer/lingui` est un adaptateur prêt à l'emploi pour `@lingui/core` et `@lingui/react`. Les macros continuent de se compiler comme avant ; le runtime `i18n._()` qu'elles compilent est servi à partir des dictionnaires Intlayer, avec des plugins de synchronisation `.po` qui maintiennent vos catalogues existants comme source de vérité. Les pluriels et sélections ICU s'affichent de manière identique.
@@ -353,16 +394,82 @@ Conservez `@lingui/babel-plugin-lingui-macro` / `@lingui/swc-plugin` dans la bui
 
 ## Quand choisir quoi ?
 
-- **Choisir Lingui** si vous voulez **ICU MessageFormat** avec des macros typées, vos traducteurs travaillent en **`.po`** avec un pipeline TMS existant, vous préférez les chaînes source inline en JSX, et votre équipe est à l'aise avec la gestion du workflow extract / compile / catalog-splitting. Son JS par page est compétitif une fois le lazy loading configuré.
-- **Choisir Intlayer** si vous voulez du **contenu scoped au composant**, du **TypeScript strict**, des **erreurs de clés manquantes au build-time**, du **tree-shaking et lazy loading sans effort**, de petits composants, une hydratation rapide, un changement de locale instantané, et des outils éditoriaux intégrés (Visual Editor, CMS, traduction IA, serveur MCP). Particulièrement pertinent pour les grandes codebases modulaires et les design systems.
-- **Choisir `@intlayer/lingui`** si vous êtes sur Lingui et souhaitez migrer progressivement vers les dictionnaires Intlayer sans modifier les macros.
+<AccordionGroup>
+<Accordion header="Choisir Lingui">
+
+Vous voulez **ICU MessageFormat** avec des macros typées, vos traducteurs travaillent en **`.po`** avec un pipeline TMS existant, vous préférez les chaînes sources en ligne dans JSX, et votre équipe est à l'aise avec la gestion du workflow extraction / compilation / division des catalogues. Son JS par page est compétitif une fois le lazy loading configuré.
+
+</Accordion>
+<Accordion header="Choisir Intlayer">
+
+Vous voulez du **contenu scopé au composant**, du **TypeScript strict**, des **erreurs de clés manquantes au build**, du **tree-shaking et lazy loading sans effort**, des composants légers, une hydratation rapide, un changement de locale instantané, et des outils éditoriaux intégrés ([Visual Editor](https://intlayer.org/fr/doc/concept/editor), [CMS](https://intlayer.org/fr/doc/concept/cms), [traduction par 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 volumineuses et les design systems.
+
+</Accordion>
+<Accordion header="Choisir @intlayer/lingui">
+
+Vous utilisez déjà Lingui et souhaitez migrer vers les dictionnaires Intlayer progressivement sans toucher aux macros. Vos catalogues `.po` restent la source de vérité grâce au [plugin de synchronisation PO](https://intlayer.org/fr/doc/compatibility/lingui). Mesuré côte à côte dans [Lingui vs @intlayer/lingui](https://intlayer.org/fr/blog/lingui-vs-intlayer-lingui).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Lingui compile également. Pourquoi la sortie est-elle si différente ?">
+
+Parce que l'unité de compilation diffère. Lingui compile **un catalogue par locale** : tout ce qui est en dessous (catalogues par route, lazy loading, exclusion du fallback du bundle) relève de la configuration. Intlayer compile **un dictionnaire par composant**, donc le découpage par route découle directement du build. C'est pourquoi un composant Lingui compilé isolément pèse 58-153 KB contre 6-8 KB pour Intlayer.
+
+</Question>
+
+<Question title="Pourquoi la fuite de locale n'atteint-elle jamais 0% avec Lingui ?">
+
+Les macros gardent le message source disponible comme solution de repli (fallback) au runtime, de sorte que la chaîne anglaise est envoyée à côté de sa traduction. Le benchmark mesure **3-15% de chaînes `en` dans les pages `fr`** dans chaque configuration optimisée. Intlayer résout les fallbacks au build et ne livre que la locale active.
+
+</Question>
+
+<Question title="Le JavaScript par page de Lingui est-il vraiment compétitif ?">
+
+Oui, et sur TanStack Start il l'emporte d'un cheveu : 115.2 KB en `dynamic` contre 118.6 KB pour Intlayer. Les catalogues compilés avec des identifiants hachés sont compacts. Le coût apparaît ailleurs : hydratation à 28-34 ms contre 11-14 ms, et un changement de locale à **42 ms** dans la configuration `scoped-dynamic`.
+
+</Question>
+
+<Question title="Dois-je renoncer aux macros pour migrer ?">
+
+Non. `@intlayer/lingui` permet de compiler `` t`...` ``, `<Trans>`, `msg`, `plural`, `select` et `selectOrdinal` comme avant ; seul le mécanisme de résolution sous-jacent de `i18n._()` change. Conservez `@lingui/babel-plugin-lingui-macro` ou `@lingui/swc-plugin` dans le build. Voir la [documentation de compatibilité Lingui](https://intlayer.org/fr/doc/compatibility/lingui).
+
+</Question>
+
+<Question title="Qu'en est-il des étapes d'extraction et de compilation ?">
+
+Elles restent nécessaires pour les macros, mais disparaissent pour le contenu propre à Intlayer. Les dictionnaires `.content.ts` sont créés lors de l'exécution du bundler, sans commande CLI distincte, et [`intlayer test`](https://intlayer.org/fr/doc/concept/cli) fait échouer la CI en cas de clé manquante au lieu de basculer silencieusement sur la chaîne source.
+
+</Question>
+
+</FAQ>
 
 ## Comparaisons associées
 
-- [next-intl vs Intlayer](https://intlayer.org/blog/next-intl-vs-intlayer) (même benchmark)
-- [i18next vs Intlayer](https://intlayer.org/blog/i18next-vs-intlayer) (même benchmark)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark) (même benchmark)
-- [Compiler vs declarative i18n](https://intlayer.org/blog/compiler-vs-declarative-i18n)
+Même benchmark, autres bibliothèques :
+
+- [next-intl vs Intlayer](https://intlayer.org/fr/blog/next-intl-vs-intlayer)
+- [i18next vs Intlayer](https://intlayer.org/fr/blog/i18next-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 :
+
+- [Lingui vs @intlayer/lingui](https://intlayer.org/fr/blog/lingui-vs-intlayer-lingui), l'adaptateur mesuré sur la même application
+- [Compiler-driven vs declarative i18n](https://intlayer.org/fr/blog/compiler-vs-declarative-i18n)
+- [Per-component vs centralized i18n](https://intlayer.org/fr/blog/per-component-vs-centralized-i18n)
+- [ICU message format explained](https://intlayer.org/fr/blog/icu-message-format)
+
+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)
+- [Compat adapter: Lingui](https://intlayer.org/fr/doc/compatibility/lingui)
+- [Optimisation du bundle](https://intlayer.org/fr/doc/concept/bundle-optimization) et [le compilateur Intlayer](https://intlayer.org/fr/doc/compiler)
 
 ## Étoiles GitHub