@intlayer/docs 9.5.5 → 9.5.7

package/blog/fr/i18next_vs_intlayer-i18next.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "i18next vs @intlayer/i18next : Même API, Bundle Différent"
 description: Ce qui change lorsqu'une application React ou Next.js conserve ses appels à i18next, react-i18next et next-i18next mais les exécute via les adaptateurs @intlayer/i18next. JavaScript par page, taille des composants, fuite de chaînes et hydratation mesurés sur le même code, ainsi que ce que les adaptateurs conservent, ignorent et ne peuvent pas remplacer.
 keywords:
@@ -28,6 +28,8 @@ author: aymericzip
 
 # i18next VS @intlayer/i18next | Même API, Bundle Différent
 
+![i18next VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `@intlayer/i18next`, `@intlayer/react-i18next` et `@intlayer/next-i18next` sont des adaptateurs de compatibilité. Ils exposent l'API `i18next` que votre code utilise déjà (`useTranslation`, `t()`, `<Trans>`, `i18n.changeLanguage()`, `getFixedT`, `serverSideTranslations`...) et la distribuent à partir de dictionnaires compilés par Intlayer. Les composants ne changent pas. Le runtime sous-jacent, lui, change.
 
 Cet article mesure ce remplacement sur la même application Next.js, construite une fois avec `next-i18next` et une fois avec `@intlayer/next-i18next`. Les chiffres proviennent de [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Pour comparer `i18next` et Intlayer en tant que bibliothèques distinctes, consultez [i18next vs Intlayer](https://intlayer.org/fr/blog/i18next-vs-intlayer). Celui-ci se concentre sur ce que l'adaptateur transforme lorsque vous conservez votre code tel quel.
@@ -109,6 +111,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/>
+
 | Configuration                | Stratégie      | Taille lib (gz) | JS page moy (gz) | Fuite locale | Fuite page | Composant moy (gz) | Réactivité E2E | Hydratation |
 | ---------------------------- | -------------- | --------------: | ---------------: | -----------: | ---------: | -----------------: | -------------: | ----------: |
 | **base** (sans i18n)         | -              |          0.0 Ko |         141.0 Ko |         0.0% |       0.0% |             0.9 Ko |        13.4 ms |     11.8 ms |
@@ -129,10 +135,21 @@ Pour chaque build, la suite enregistre :
 - **Hydratation et basculement plus rapides.** L'hydratation passe de 15.6 ms à **11.3 ms** (et de 27.7 ms dans la configuration `dynamic`, où l'appel backend se situe sur le chemin critique). Le basculement de locale passe de 15-16 ms à **11-12 ms**.
 - **L'adaptateur n'est pas le runtime natif.** `next-intlayer` atteint **141.3 Ko**, soit +0.3 Ko par rapport à l'application de base. L'adaptateur supporte la surface d'API de `i18next` (dialecte d'interpolation, résolution des pluriels et contextes, analyse des balises `<Trans>`) en surcouche du cœur d'Intlayer : 9.4 Ko et +9.4 Ko par page par rapport au natif. Il constitue une passerelle, non une fin en soi.
 
+<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).
+
 > L'adaptateur `react-i18next` sur Vite / TanStack Start n'a pas été inclus dans ce cycle de test. La référence pour `react-i18next` sur TanStack Start se trouve dans [i18next vs Intlayer](https://intlayer.org/fr/blog/i18next-vs-intlayer) : 127-184 Ko par page et 123-185 ms de temps de basculement de locale quand le backend est différé.
 
 ## Pourquoi ces écarts de métriques
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Rien n'a changé dans le dossier `components/` : les gains proviennent donc exclusivement de la cible à laquelle `useTranslation` est relié.
 
 **Avec `i18next`**, la liaison s'établit avec l'instance globale. Tout ce qui y a été chargé (toutes les locales en `static`, l'ensemble du namespace de la locale active en `dynamic`) est accessible depuis chaque composant appelant `useTranslation()`. Le bundler ne peut pas découper plus finement que ce que l'instance retient, et le runtime ne peut pas anticiper les clés demandées au rendu.
@@ -149,6 +166,10 @@ Rien n'a changé dans le dossier `components/` : les gains proviennent donc excl
     └── About.tsx                     # useTranslation(); t("about.title")
 ```
 
+Tout ce que l'instance contient est expédié sur chaque page, et le gaspillage croît sur deux axes, 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)
+
 **Avec `@intlayer/next-i18next`**, la liaison s'opère directement avec le dictionnaire. `syncJSON` convertit chaque fichier de namespace en dictionnaire ; la passe d'optimisation transmet au composant le dictionnaire correspondant sous forme d'un import que le bundler peut tracer et séparer par page et par locale.
 
 ```bash
@@ -297,26 +318,112 @@ export default defineConfig({
 
 ## Limites à connaître avant de démarrer
 
-- **Backends et détecteurs sont inertes.** `i18n.use(HttpBackend)` exécute le `init` du plugin et rien de plus. Si votre application dépendait de traductions rapatriées depuis un CMS au moment de la requête, ce flux n'existe plus ; utilisez le CMS d'Intlayer ou les commandes `intlayer pull` / `push`.
-- **`resources` est ignoré, non fusionné.** Contrairement à certains adaptateurs, `@intlayer/i18next` n'utilise pas `resources` inliné comme solution de repli. Chaque clé doit exister dans les dictionnaires synchronisés, ce que valide `intlayer test`.
-- **L'App Router nécessite la retouche du provider.** Un seul fichier, présenté ci-dessus. Le Pages Router avec `appWithTranslation` ne nécessite aucun ajustement.
-- **`next-i18next.config.js` n'est pas lu.** `localePath`, `fallbackLng`, `reloadOnPrerender` et équivalents n'ont pas d'effet direct ; les locales et le repli sont gérés dans `intlayer.config.ts`.
-- **L'adaptateur a un coût résiduel.** 9.4 Ko de runtime et +9.4 Ko par page par rapport à `next-intlayer`. Lorsque tous vos composants seront passés à `useIntlayer`, retirez-le.
+<AccordionGroup>
+<Accordion header="Les backends et détecteurs sont inertes">
+
+`i18n.use(HttpBackend)` appelle l'init du plugin et rien d'autre. Si votre application dépendait de la récupération de traductions depuis un CMS au runtime, ce flux disparaît ; utilisez le [CMS d'Intlayer](https://intlayer.org/fr/doc/concept/cms) ou les commandes `intlayer pull` / `push` à la place. La détection de locale devient la configuration de routage d'Intlayer (préfixe d'URL, cookie, en-tête).
+
+</Accordion>
+<Accordion header="resources est ignoré, pas fusionné">
+
+Contrairement à certains autres adaptateurs, `@intlayer/i18next` n'utilise pas les `resources` inline comme solution de repli. Chaque clé doit exister dans les dictionnaires synchronisés, ce que vérifie `intlayer test`.
+
+</Accordion>
+<Accordion header="L'App Router nécessite la modification du provider">
+
+Un seul fichier, montré ci-dessus. Le Pages Router avec `appWithTranslation` ne nécessite rien.
+
+</Accordion>
+<Accordion header="next-i18next.config.js n'est pas lu">
+
+`localePath`, `fallbackLng`, `reloadOnPrerender` et autres n'ont aucun équivalent ; les locales et le fallback proviennent de `intlayer.config.ts`.
+
+</Accordion>
+<Accordion header="L'adaptateur n'est pas gratuit">
+
+9.4 KB de runtime et +9.4 KB par page par rapport à `next-intlayer`. Une fois que chaque composant a migré vers `useIntlayer`, supprimez-le.
+
+</Accordion>
+</AccordionGroup>
 
 ## Quand choisir quelle solution ?
 
-- **Restez sur `i18next`** si votre application nécessite impérativement des backends au runtime (traductions servies par un CMS à la volée), l'écosystème spécifique de plugins, ou une cible hors React non couverte par les adaptateurs.
-- **Optez pour `@intlayer/*`** si vous utilisez `react-i18next` / `next-i18next` et souhaitez récupérer 68 Ko, obtenir des composants 8x plus légers, 0% de fuite, des clés typées et des contrôles en CI sans devoir tout réécrire. C'est le point d'entrée idéal pour une codebase `i18next` existante.
-- **Passez au natif (`next-intlayer` / `react-intlayer`)** pour les nouveaux projets ou une fois l'adaptateur assimilé. C'est la formule la plus légère (5.5 Ko, +0.3 Ko par page) qui débloque les Server Components synchrones et les fichiers de contenu `.content.ts` par composant.
+<AccordionGroup>
+<Accordion header="Rester sur i18next">
+
+Votre application dépend de backends au runtime (traductions servies par un CMS au moment de la requête), de l'écosystème de plugins, ou d'une cible non-React non couverte par les adaptateurs.
+
+</Accordion>
+<Accordion header="Utiliser @intlayer/*">
+
+Vous utilisez `react-i18next` / `next-i18next` et souhaitez économiser 68 KB, avoir des composants 8x plus petits, 0% de fuite, des clés typées et des vérifications CI sans réécriture. C'est le point d'entrée pour une codebase `i18next` existante.
+
+</Accordion>
+<Accordion header="Passer en natif (next-intlayer / react-intlayer)">
+
+Pour les nouveaux projets, ou une fois que l'adaptateur a fait son travail. Il possède le runtime le plus léger (5.5 KB, +0.3 KB par page) et débloque les Server Components synchrones et les fichiers `.content.ts` par composant. Commencez avec [Intlayer avec Next.js](https://intlayer.org/fr/doc/environment/nextjs) ou [avec Vite et React](https://intlayer.org/fr/doc/environment/vite-and-react).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="D'où viennent les 68 KB ?">
+
+De `resources: { en, fr, ... }`. La configuration naive de `next-i18next` importe le JSON de chaque locale dans `init()`, de sorte que chaque page transporte chaque namespace dans chaque langue : **218.5 KB** par page. L'adaptateur n'embarque jamais ce bloc ; il fournit à chaque composant le dictionnaire qu'il nomme, dans la locale active.
+
+</Question>
+
+<Question title="Mes composants <Trans> continuent-ils de fonctionner ?">
+
+Oui, avec `components`, les balises numérotées `<1>...</1>` et les `values`. De même pour `{{interpolation}}`, l'imbrication `$t(key)`, les pluriels `key_one` / `key_other` (évalués avec `Intl.PluralRules`), les suffixes de contexte et `returnObjects`.
+
+</Question>
+
+<Question title="Que faire si j'utilise un seul fichier translation.json par locale ?">
+
+Définissez `splitKeys: false` dans le plugin `syncJSON`. L'ensemble du fichier reste un dictionnaire unique et un simple appel à `useTranslation()` continue de s'y résoudre.
+
+</Question>
+
+<Question title="Est-ce la même chose que de migrer vers Intlayer ?">
+
+Non, c'est la passerelle. L'adaptateur conserve l'API `i18next` et coûte 9.4 KB de runtime ; `next-intlayer` natif coûte 5.5 KB et apporte les Server Components synchrones et les fichiers `.content.ts` colocalisés. Vous pouvez migrer composant par composant, car les dictionnaires JSON et `.content.ts` coexistent.
+
+</Question>
+
+<Question title="Les traducteurs peuvent-ils continuer à travailler comme aujourd'hui ?">
+
+Oui. `locales/{lng}/{ns}.json` reste la source de vérité : `syncJSON` le lit avec le dialecte i18next et réécrit les traductions lorsque la CLI ou le CMS les met à jour.
+
+</Question>
+
+</FAQ>
 
 ## Comparatifs associés
 
-- [i18next vs Intlayer](https://intlayer.org/fr/blog/i18next-vs-intlayer) (comparatif des bibliothèques, même benchmark)
-- [next-intl vs @intlayer/next-intl](https://intlayer.org/fr/blog/next-intl-vs-intlayer-next-intl) (même série d'adaptateurs)
-- [Lingui vs @intlayer/lingui](https://intlayer.org/fr/blog/lingui-vs-intlayer-lingui) (même série d'adaptateurs)
-- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/fr/blog/vue-i18n-vs-intlayer-vue-i18n) (même série d'adaptateurs)
-- 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)
-- Références des adaptateurs : [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)
+Même série d'adaptateurs :
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/fr/blog/next-intl-vs-intlayer-next-intl)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/fr/blog/lingui-vs-intlayer-lingui)
+- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/fr/blog/vue-i18n-vs-intlayer-vue-i18n)
+
+Les bibliothèques comparées directement :
+
+- [i18next vs Intlayer](https://intlayer.org/fr/blog/i18next-vs-intlayer), same 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)
+- [Is i18next outdated?](https://intlayer.org/fr/blog/is-i18next-outdated)
+
+Documentation de référence :
+
+- Compat adapters: [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)
+- Migration guides: [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)
+- [Next.js benchmark report](https://intlayer.org/fr/doc/benchmark/nextjs) and [TanStack Start benchmark report](https://intlayer.org/fr/doc/benchmark/tanstack)
+- [Bundle optimization](https://intlayer.org/fr/doc/concept/bundle-optimization) and [the Intlayer compiler](https://intlayer.org/fr/doc/compiler)
+- [Visual Editor](https://intlayer.org/fr/doc/concept/editor), [CMS](https://intlayer.org/fr/doc/concept/cms) and [AI translation](https://intlayer.org/fr/doc/concept/auto-fill)
 
 ## Conclusion
 

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