@intlayer/docs 9.5.5 → 9.5.7

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
 

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

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl vs @intlayer/next-intl : Même API, Bundle différent"
 description: Ce qui change quand les imports de next-intl d'une application Next.js sont servies par l'adaptateur de compatibilité @intlayer/next-intl. Taille du bundle, fuites, taille des composants et hydratation mesurés sur le même code, plus ce que l'adaptateur conserve, ignore et ne peut pas remplacer.
 keywords:
@@ -26,6 +26,8 @@ author: aymericzip
 
 # next-intl VS @intlayer/next-intl | Même API, Bundle différent
 
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `@intlayer/next-intl` est un adaptateur de compatibilité : il expose l'API `next-intl` (`useTranslations`, `getTranslations`, `useLocale`, `t.rich()`, pluriels ICU, `NextIntlClientProvider`...) et la sert à partir de dictionnaires compilés par Intlayer. Le code de l'application ne change pas. Le bundle, lui, change.
 
 Cet article compare les deux sur la même application Next.js, construite une fois avec `next-intl` et une fois avec l'adaptateur. Les chiffres proviennent de [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), une suite open-source qui enregistre ce que le navigateur télécharge réellement. Si vous voulez la comparaison `next-intl` vs Intlayer en tant que bibliothèques, consultez [next-intl vs Intlayer](https://intlayer.org/blog/next-intl-vs-intlayer). Celui-ci traite de ce que l'adaptateur change lorsque vous conservez vos composants tels qu'ils sont.
@@ -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/>
+
 | Setup                     | Strategy       | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity |   Hydration |
 | ------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | ----------: |
 | **base** (no i18n)        | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |     11.8 ms |
@@ -129,6 +135,15 @@ Pour chaque build, la suite enregistre :
 - **L'hydratation est 2 ms plus rapide** (12.8 vs 14.7 ms) : il n'y a pas d'objet de message à désérialiser de la charge utile RSC avant que React puisse hydrater.
 - **L'adaptateur n'est pas le runtime natif.** `next-intlayer` s'élève à **141.3 KB**, +0.3 KB par rapport à l'app de base, avec un runtime de 5.5 KB. L'adaptateur transporte la surface API de `next-intl` (`useFormatter`, `t.rich`, le résolveur ICU) au-dessus du noyau d'Intlayer, d'où 8.0 KB et +6 KB par page. C'est le pont, pas la destination.
 
+<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 (`use-intl`)
 
 `use-intl` est le noyau framework-agnostique de `next-intl`. Son adaptateur, `@intlayer/use-intl`, suit le même design avec un plugin Vite (`@intlayer/use-intl/plugin`).
@@ -152,11 +167,24 @@ Pour chaque build, la suite enregistre :
 - **Le changement de locale est plus rapide.** Les configurations `use-intl` optimisées prennent **13-21 ms** pour mettre à jour `html[lang]`; l'adaptateur prend **4-9 ms**. Moins de composants se re-rendent, et rien n'est re-sélectionné dans un arbre de messages.
 - **`static` conserve chaque locale.** La ligne `static` de l'adaptateur affiche une fuite de locale de 49.7%, la même que celle d'Intlayer natif en mode `static` : toutes les locales sont bundlées, seuls les dictionnaires de la page le sont. Une ligne de config (`importMode: 'dynamic'`) la supprime.
 
+<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 les nombres changent
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Rien dans le composant n'a changé, donc les gains proviennent entièrement de ce à quoi `useTranslations` est lié.
 
-**Avec `next-intl`**, la liaison est le fournisseur. `NextIntlClientProvider` reçoit l'objet `messages` complet pour la locale ; chaque `useTranslations("about")` le lit depuis celui-ci. Le bundler voit un composant important un hook qui lit un contexte, et ne peut pas savoir que seule la branche `about` est utilisée. Les routes ci-dessous partagent toutes le même objet message, donc la colonne page-leak affiche ~90% jusqu'à ce que vous divisiez le fichier vous-même.
+**Avec `next-intl`**, la liaison est le fournisseur. `NextIntlClientProvider` reçoit l'objet `messages` complet pour la locale ; chaque `useTranslations("about")` le lit depuis celui-ci. Le bundler voit un composant important un hook qui lit un contexte, et ne peut pas savoir que seule la branche `about` est utilisée. Les routes ci-dessous partagent toutes le même objet message, donc la colonne page-leak affiche ~90% jusqu'à ce que vous divisiez le fichier vous-même, et le gaspillage 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)
 
 ```bash
 .
@@ -280,25 +308,106 @@ export default withIntlayer(nextConfig);
 
 ## Limites à connaître avant de commencer
 
-- **La configuration du routage se déplace vers `intlayer.config.ts`.** `createNavigation(routing)` et `createMiddleware(routing)` conservent leur signature mais ignorent l'argument : les locales, la locale par défaut et la stratégie de préfixe proviennent de la configuration `routing` d'Intlayer. Si vous utilisez les `pathnames` localisés de `next-intl` (`/about` → `/a-propos`), l'adaptateur ne les interpole pas ; `routing.rewrite` d'Intlayer couvre ce cas mais c'est une modification séparée.
-- **`useTranslations()` sans namespace n'est pas lié.** La passe d'optimisation a besoin d'un namespace statique pour savoir quel dictionnaire importer. Un appel nu fonctionne quand même, via un registre runtime qui référence chaque dictionnaire, ce qui est exactement la fuite que vous tentiez d'éliminer. Passez le namespace.
-- **L'adaptateur n'est pas gratuit.** 8.0 KB de runtime contre 5.5 KB pour `next-intlayer`, et +6-7 KB par page par rapport au build natif. C'est le prix de la surface API `next-intl`. Si vous en arrivez au point où chaque composant a été déplacé vers `useIntlayer`, abandonnez l'adaptateur.
-- **`messages`, `timeZone`, `now` sur le provider sont ignorés.** Les formateurs sont soutenus par `Intl` natif et seule la locale influence leur sortie; si vous comptiez sur un fuseau horaire forcé ou un `now` fixe pour des dates stables à l'hydratation, gérez-le au site d'appel.
+<AccordionGroup>
+<Accordion header="La configuration de routage se déplace dans intlayer.config.ts">
+
+`createNavigation(routing)` et `createMiddleware(routing)` conservent leur signature mais ignorent l'argument : les locales, la locale par défaut et la stratégie de préfixe proviennent de la configuration `routing` d'Intlayer. Si vous utilisez les `pathnames` localisés de `next-intl` (`/about` vers `/a-propos`), l'adaptateur ne les interpole pas ; `routing.rewrite` d'Intlayer couvre ce cas mais constitue un changement distinct.
+
+</Accordion>
+<Accordion header="useTranslations() sans namespace n'est pas lié">
+
+La passe d'optimisation a besoin d'un namespace statique pour savoir quel dictionnaire importer. Un appel nu fonctionne toujours, via un registre d'exécution qui référence chaque dictionnaire, ce qui correspond exactement à la fuite que vous essayiez de supprimer. Passez le namespace.
+
+</Accordion>
+<Accordion header="L'adaptateur n'est pas gratuit">
+
+8.0 KB de runtime contre 5.5 KB pour `next-intlayer`, et +6-7 KB par page par rapport au build natif. Il paie pour la surface d'API de `next-intl`. Si vous atteignez le point où chaque composant a été migré vers `useIntlayer`, supprimez l'adaptateur.
+
+</Accordion>
+<Accordion header="messages, timeZone et now sur le provider sont ignorés">
+
+Les formateurs s'appuient sur l'API native `Intl` et seule la locale influence leur résultat. Si vous comptez sur un fuseau horaire forcé ou un `now` fixe pour des dates stables à l'hydratation, gérez-le au niveau du site d'appel. Consultez [formatage de dates, heures et nombres](https://intlayer.org/fr/blog/date-time-number-formatting-locales).
+
+</Accordion>
+</AccordionGroup>
 
 ## Quand utiliser quoi?
 
-- **Restez sur `next-intl`** si votre app est petite, votre bundle n'est pas une préoccupation, et votre équipe est à l'aise pour posséder les namespaces et `pick()` par page.
-- **Utiliser `@intlayer/next-intl`** si vous êtes actuellement sur `next-intl` et souhaitez les gains en termes de bundle, de fuite mémoire et d'hydratation, des clés typées et les outils CLI / CMS sans réécriture. C'est le point d'entrée recommandé pour toute base de code `next-intl` existante.
-- **Opter pour la solution native (`next-intlayer`)** pour les nouveaux projets, ou une fois que l'adapter a rempli son rôle. C'est la plus légère des trois (5,5 KB, +0,3 KB par page) et déverrouille les composants serveur synchrones, les fichiers `.content.ts` par composant et l'ensemble complet des fonctionnalités.
+<AccordionGroup>
+<Accordion header="Rester sur next-intl">
+
+Votre application est petite, votre bundle n'est pas une préoccupation, et votre équipe est à l'aise avec la gestion des namespaces et de `pick()` par page.
+
+</Accordion>
+<Accordion header="Utiliser @intlayer/next-intl">
+
+Vous utilisez déjà `next-intl` aujourd'hui et souhaitez bénéficier des gains de bundle, de fuite et d'hydratation, des clés typées et des outils CLI / CMS sans réécriture. C'est le point d'entrée recommandé pour toute codebase `next-intl` existante.
+
+</Accordion>
+<Accordion header="Passer en natif (next-intlayer)">
+
+Pour les nouveaux projets, ou une fois que l'adaptateur a fait son travail. C'est le plus léger des trois (5.5 KB, +0.3 KB par page) et il débloque les composants serveur synchrones, les fichiers `.content.ts` par composant et l'ensemble des fonctionnalités. Commencez avec [Intlayer avec Next.js](https://intlayer.org/fr/doc/environment/nextjs).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Le code de mon application reste-t-il vraiment intact ?">
+
+Sur Next.js, oui pour les composants : le build de benchmark n'a modifié que `next.config.ts` et `intlayer.config.ts`. `getRequestConfig` dans `src/i18n.ts`, la prop `messages` sur le provider et les appels `pick()` par page deviennent du code mort que vous pouvez supprimer par la suite.
+
+</Question>
+
+<Question title="Qu'advient-il des messages ICU ?">
+
+Ils continuent de fonctionner. `t("key", { count })`, `t.rich()`, `t.markup()`, `select`, `selectordinal`, `#` et `{ts, date, long}` sont résolus par le résolveur ICU d'Intlayer. Consultez [format de message ICU](https://intlayer.org/fr/blog/icu-message-format).
+
+</Question>
+
+<Question title="Pourquoi l'adaptateur est-il plus lourd que next-intlayer natif ?">
+
+Il transporte la surface d'API de `next-intl` au-dessus du cœur d'Intlayer : `useFormatter`, `t.rich`, le résolveur ICU, les helpers de navigation. Cela représente 8.0 KB contre 5.5 KB, et +6 KB par page. C'est le pont, pas la destination.
+
+</Question>
+
+<Question title="Puis-je migrer composant par composant ?">
+
+Oui. N'importe quel composant peut passer de `useTranslations("about")` à `useIntlayer("about")` avec un fichier `.content.ts` co-localisé. Les dictionnaires JSON et `.content.ts` coexistent et fusionnent, il n'y a donc pas de rupture brutale.
+
+</Question>
+
+<Question title="Les pathnames localisés fonctionnent-ils ?">
+
+Pas via les `pathnames` de `next-intl` : l'adaptateur les accepte pour le typage mais ne les interpole pas. Utilisez plutôt `routing.rewrite` d'Intlayer, qui émet les littéraux localisés dans le registre de types.
+
+</Question>
+
+</FAQ>
 
 ## Comparaisons connexes
 
-- [next-intl vs Intlayer](https://intlayer.org/blog/next-intl-vs-intlayer) (les bibliothèques, même benchmark)
-- [i18next vs @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) (même série d'adaptateurs)
-- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (même série d'adaptateurs)
-- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/blog/vue-i18n-vs-intlayer-vue-i18n) (même série d'adaptateurs)
-- [Guide de migration : next-intl vers Intlayer](https://intlayer.org/doc/migration/next-intl)
-- [Référence de l'adaptateur de compatibilité : next-intl](https://intlayer.org/doc/compatibility/next-intl)
+Même série d'adaptateurs :
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/fr/blog/i18next-vs-intlayer-i18next)
+- [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 :
+
+- [next-intl vs Intlayer](https://intlayer.org/fr/blog/next-intl-vs-intlayer), même benchmark
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/fr/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [Is next-intl outdated?](https://intlayer.org/fr/blog/is-next-intl-outdated)
+
+Documentation de référence :
+
+- [Compat adapter: next-intl](https://intlayer.org/fr/doc/compatibility/next-intl)
+- [Guide de migration : next-intl vers Intlayer](https://intlayer.org/fr/doc/migration/next-intl)
+- [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)
+- [Optimisation du bundle](https://intlayer.org/fr/doc/concept/bundle-optimization) et [le compilateur Intlayer](https://intlayer.org/fr/doc/compiler)
+- [Visual Editor](https://intlayer.org/fr/doc/concept/editor), [CMS](https://intlayer.org/fr/doc/concept/cms) et [traduction par IA](https://intlayer.org/fr/doc/concept/auto-fill)
 
 ## Conclusion