@intlayer/docs 9.5.6 → 9.5.7

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
 

package/blog/fr/next-intl_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl vs Intlayer: Benchmark et Comparaison 2026"
 description: Taille du bundle, fuite de contenu, réactivité du changement de locale et expérience développeur mesurés sur Next.js et TanStack Start. Quelle bibliothèque i18n devriez-vous choisir en 2026 ?
 keywords:
@@ -24,6 +24,8 @@ author: aymericzip
 
 # next-intl VS Intlayer | Benchmark d'Internationalization (i18n) Next.js
 
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `next-intl` est la bibliothèque i18n la plus populaire pour Next.js. Intlayer est une alternative basée sur un compilateur et scoped au niveau des composants. Les deux localisent une application App Router. La question est ce que chacune coûte une fois que l'application est construite.
 
 Cet article n'est pas un tutoriel. C'est une comparaison étayée par des chiffres provenant de [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), une suite de benchmark open-source qui construit la même application avec chaque bibliothèque et mesure 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 (App Router)
 
+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 |
@@ -116,6 +122,15 @@ Pour chaque build, la suite enregistre :
 - **Taille des composants.** Un composant qui appelle `useTranslations()` compile à 21.8 KB en moyenne ; le même composant avec `useIntlayer()` compile à 6.9 KB. Dans la configuration `scoped-static`, les composants `next-intl` sautent à 80.1 KB car chacun intègre son catalogue de namespaces.
 - **Réactivité et hydratation** sont dans le même ordre de grandeur pour les deux bibliothèques sur Next.js (15-18 ms). Aucune n'est un goulot d'étranglement ici.
 
+<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 cœur indépendant du framework de `next-intl`. Même API, même format de message. Le comparer à `intlayer` sur TanStack Start supprime les parties spécifiques à Next.js de l'équation.
@@ -139,8 +154,19 @@ Pour chaque build, la suite enregistre :
 - **La taille du composant montre où se trouve l'architecture** : 76-87 KB par composant avec `use-intl` versus 6-8 KB avec Intlayer. `useTranslations()` lie chaque composant à l'arborescence de messages globale ; `useIntlayer()` le lie à son propre dictionnaire.
 - **Le changement de locale** est 2 à 4 fois plus rapide avec Intlayer (3 ms contre 7-21 ms).
 
+<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 cet écart ? Catalogues centralisés 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)
+
 `next-intl` suit le modèle classique : un JSON par locale, chargé dans `getRequestConfig`, poussé dans un `NextIntlClientProvider`, lu via `t("namespace.key")`.
 
 ```bash
@@ -162,6 +188,10 @@ Pour chaque build, la suite enregistre :
 
 Le runtime ne peut pas connaître les clés qu'une page utilisera, donc la valeur par défaut sûre est d'envoyer l'ensemble du catalogue. Optimiser signifie **que vous** divisez le catalogue en namespaces, **que vous** décidez quels namespaces chaque page a besoin, et **que vous** mainteniez cette correspondance synchronisée lorsque les composants se déplacent. La ligne `scoped-dynamic` du benchmark est la récompense pour ce travail, et la plupart des équipes n'y arrivent jamais.
 
+Le coût de ne pas y parvenir 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)
+
 Intlayer inverse la responsabilité. Le contenu est déclaré à côté du composant :
 
 ```bash
@@ -189,7 +219,8 @@ Au moment de la compilation, le compilateur (`@intlayer/swc` / `@intlayer/babel`
 
 ### Composant client
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```json fileName="messages/en.json"
 {
@@ -224,7 +255,8 @@ export const Counter = () => {
 
 > N'oubliez pas d'inclure l'espace de noms `counter` dans les messages passés à `NextIntlClientProvider` sur chaque page qui rend ce composant.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -267,11 +299,15 @@ export const Counter = () => {
 
 Rien à enregistrer sur la page : le composant apporte son propre contenu.
 
+</Tab>
+</Tabs>
+
 ### Composant serveur synchrone
 
 Les éléments du design system (navbar, footer, cards) sont souvent des composants serveur rendus comme enfants de composants clients, ils ne peuvent donc pas être `async`.
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -289,7 +325,8 @@ export const ServerCounter = ({ t, formattedCount }: ServerCounterProps) => (
 
 La page doit `await getTranslations("counter")` et `await getFormatter()`, puis transmettre les résultats en tant que props. Le composant n'est plus autonome.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -308,9 +345,13 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ### Métadonnées
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import type { Metadata } from "next";
@@ -343,7 +384,8 @@ export const generateMetadata = async ({
 };
 ```
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import { getIntlayer, getMultilingualUrls } from "intlayer";
@@ -367,6 +409,9 @@ export const generateMetadata = async ({
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Conservez l'API next-intl, obtenez la sortie d'Intlayer
 
 Vous n'avez pas besoin de réécrire les composants pour obtenir les chiffres de benchmark ci-dessus. `@intlayer/next-intl` est un adaptateur clé en main : il conserve `useTranslations`, `getTranslations`, `useFormatter`, `t.rich()`, les pluriels ICU et les helpers `next-intl/navigation`, et les sert à partir des dictionnaires Intlayer compilés par le compilateur Intlayer.
@@ -388,17 +433,84 @@ Consultez le [guide de migration next-intl](https://intlayer.org/doc/migration/n
 
 ## Quand choisir lequel ?
 
-- **Choisissez next-intl** si vous voulez le standard de l'écosystème pour Next.js, vous dépendez d'ICU MessageFormat, votre application est de petite à moyenne taille, ou vous intégrez avec une plateforme de traduction (Crowdin, Phrase, Lokalise...) qui attend du JSON centralisé. Prévoyez du temps pour structurer les catalogues par namespace et sélectionner les messages par page si la performance compte.
-- **Choisissez Intlayer** si vous voulez du **contenu scoped au composant**, du **TypeScript strict**, des **erreurs de clés manquantes à la compilation**, du **tree-shaking et lazy loading sans effort**, des composants serveur synchrones, et des outils éditoriaux intégrés (Visual Editor, CMS, traduction IA, serveur MCP). Particulièrement pertinent pour les codebases volumineuses et modulaires et les design systems.
-- **Choisissez `@intlayer/next-intl`** si vous êtes déjà sur `next-intl` et voulez les gains de bundle sans réécriture complète.
+<AccordionGroup>
+<Accordion header="Choisir next-intl">
+
+Vous voulez le standard de l'écosystème pour Next.js, vous comptez sur ICU MessageFormat, votre application est de taille petite à moyenne, ou vous vous intégrez à une plateforme de traduction (Crowdin, Phrase, Lokalise...) qui attend du JSON centralisé. Prévoyez du temps pour structurer les catalogues par namespace et sélectionner les messages avec `pick()` par page si la performance compte.
+
+</Accordion>
+<Accordion header="Choisir Intlayer">
+
+Vous voulez **du contenu scopé au composant**, **un TypeScript strict**, **des erreurs de clés manquantes au build**, **du tree-shaking et lazy loading sans effort**, des composants serveur synchrones, 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 et volumineuses ainsi que les design systems.
+
+</Accordion>
+<Accordion header="Choisir @intlayer/next-intl">
+
+Vous utilisez déjà `next-intl` et souhaitez bénéficier des gains de bundle sans réécriture. L'[adaptateur de compatibilité](https://intlayer.org/fr/doc/compatibility/next-intl) conserve vos imports et votre fichier `messages/{locale}.json` comme source de vérité. Mesuré côte à côte dans [next-intl vs @intlayer/next-intl](https://intlayer.org/fr/blog/next-intl-vs-intlayer-next-intl).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="next-intl est-il plus lent qu'Intlayer ?">
+
+Pas au moment du rendu. La différence réside dans ce qui est envoyé : `next-intl` coûte **+12.6 KB gzip** de runtime sur chaque page et, dans les configurations courantes, envoie ~90% des chaînes des pages étrangères avec chaque page. Le changement de locale et l'hydratation sont comparables sur Next.js (15-18 ms) ; sur TanStack Start, `use-intl` prend 7-21 ms contre 3-4 ms pour Intlayer.
+
+</Question>
+
+<Question title="Puis-je atteindre 0% de fuite avec next-intl ?">
+
+Oui, avec la configuration `scoped-dynamic` : divisez `messages/{locale}.json` en un namespace par route, puis appliquez `pick(messages, [...])` sur chaque page et maintenez ce mapping à jour au fil des évolutions des composants. Les lignes `scoped-*` du benchmark reflètent précisément ce travail. Intlayer atteint 0% par défaut sans cela car le compilateur scope le contenu par composant. Voir [optimisation du bundle](https://intlayer.org/fr/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Dois-je réécrire mes composants pour migrer ?">
+
+Non. `@intlayer/next-intl` conserve `useTranslations`, `getTranslations`, `useFormatter`, `t.rich()`, les pluriels ICU et les helpers de navigation, en les servant depuis des dictionnaires compilés. Une seule ligne de plugin dans `next.config.ts`. Guide pas à pas dans le [guide de migration next-intl](https://intlayer.org/fr/doc/migration/next-intl).
+
+</Question>
+
+<Question title="Intlayer prend-il en charge ICU MessageFormat ?">
+
+Le support natif d'ICU est en cours de développement sur l'API native. Les adaptateurs de compatibilité (`@intlayer/next-intl`, `@intlayer/use-intl`) exécutent bien ICU : les pluriels, `select`, `selectordinal`, `#` et `{ts, date, long}` passent par le résolveur ICU d'Intlayer. Consultez [format de message ICU](https://intlayer.org/fr/blog/icu-message-format) pour plus de détails.
+
+</Question>
+
+<Question title="Puis-je conserver mes fichiers messages/{locale}.json ?">
+
+Oui. Le [plugin de synchronisation JSON](https://intlayer.org/fr/doc/compatibility/next-intl) les lit, sépare leurs clés racines en dictionnaires et réécrit les traductions dans les mêmes fichiers lorsque le CLI ou le CMS les met à jour. Le flux de travail de vos traducteurs ne change pas.
+
+</Question>
+
+</FAQ>
 
 ## Comparaisons connexes
 
-- [i18next vs Intlayer](https://intlayer.org/blog/i18next-vs-intlayer) (même benchmark)
-- [Lingui vs Intlayer](https://intlayer.org/blog/lingui-vs-intlayer) (même benchmark)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark) (même benchmark)
-- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/blog/next-i18next-vs-next-intl-vs-intlayer)
-- [Is next-intl outdated?](https://intlayer.org/blog/is-next-intl-outdated)
+Même benchmark, autres bibliothèques :
+
+- [i18next vs Intlayer](https://intlayer.org/fr/blog/i18next-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 next-intl :
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/fr/blog/next-intl-vs-intlayer-next-intl), l'adaptateur mesuré sur la même application
+- [Is next-intl outdated?](https://intlayer.org/fr/blog/is-next-intl-outdated)
+- [Using Intlayer with next-intl](https://intlayer.org/fr/blog/intlayer-with-next-intl)
+- [How to internationalize a Next.js app with next-intl](https://intlayer.org/fr/blog/nextjs-internationalization-using-next-intl)
+
+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)
+- [Adaptateur de compatibilité : next-intl](https://intlayer.org/fr/doc/compatibility/next-intl) et [guide de migration](https://intlayer.org/fr/doc/migration/next-intl)
+- [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)
 
 ## GitHub STARs