@intlayer/docs 9.5.5 → 9.5.7

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
 

package/blog/fr/transform_existing_vite_react_app_using_compiler.md

@@ -282,7 +282,9 @@ const pathList = [
   { path: "/about", changefreq: "monthly", priority: 0.7 },
 ];
 
-const sitemapXml = generateSitemap(pathList, { siteUrl: SITE_URL });
+const sitemapXml = generateSitemap(pathList, {
+  siteUrl: "https://example.com",
+});
 fs.writeFileSync(path.join(__dirname, "public", "sitemap.xml"), sitemapXml);
 
 const getAllMultilingualUrls = (urls) =>
@@ -295,7 +297,7 @@ const robotsTxt = [
   "Allow: /",
   ...disallowedPaths.map((path) => `Disallow: ${path}`),
   "",
-  `Sitemap: ${SITE_URL}/sitemap.xml`,
+  `Sitemap: https://example.com/sitemap.xml`,
 ].join("\n");
 
 fs.writeFileSync(path.join(__dirname, "public", "robots.txt"), robotsTxt);

package/blog/fr/vue-i18n_vs_intlayer-vue-i18n.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "vue-i18n vs @intlayer/vue-i18n: Même API, Bundle différent"
 description: Ce qui change quand une application Vue 3 garde ses appels vue-i18n mais les exécute via l'adaptateur de compatibilité @intlayer/vue-i18n. JavaScript par page, taille d'exécution, taille de composant et fuites mesurées sur le même code Vite + Vue, plus ce que l'adaptateur conserve, ignore et ne peut pas remplacer.
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # vue-i18n VS @intlayer/vue-i18n | Même API, Bundle différent
 
+![Vue i18n library ecosystem](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
+
 `@intlayer/vue-i18n` est un adaptateur de compatibilité : il expose l'API `vue-i18n` (`createI18n`, `useI18n`, `t()`, `d()`, `n()`, `$t`, `v-t`, `i18n.global.locale`...) et la sert à partir des dictionnaires compilés par Intlayer. Vos fichiers `.vue` ne changent pas. Ce à quoi `t("footer.github")` est lié, si.
 
 Cet article mesure ce changement sur la même application Vite + Vue 3, compilée une fois avec `vue-i18n` et une fois avec l'adaptateur. Les chiffres proviennent de [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Pour `vue-i18n` et Intlayer comparés en tant que bibliothèques, lisez [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) et le [benchmark vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark). Celui-ci porte sur ce que l'adaptateur change lorsque vous conservez vos composants tels qu'ils sont.
@@ -105,6 +107,10 @@ Pour chaque build, la suite enregistre :
 
 ### Résultats sur Vite + Vue 3
 
+Sélectionnez les métriques et les bibliothèques qui vous intéressent :
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
 | Configuration            | Stratégie | Taille Lib (gz) | Taille Lib (min) | Moyenne Page JS (gz) | Fuite de locale | Fuite de page | Moyenne Component (gz) | Réactivité E2E | Chargement de page |
 | ------------------------ | --------- | --------------: | ---------------: | -------------------: | --------------: | ------------: | ---------------------: | -------------: | -----------------: |
 | **base** (no i18n)       | -         |          0.0 KB |           0.0 KB |              41.3 KB |            0.0% |             - |                 1.1 KB |         1.8 ms |            10.8 ms |
@@ -124,11 +130,24 @@ Pour chaque build, la suite enregistre :
 - **Réactivité et chargement de page.** Le changement de locale est peu coûteux pour les deux (1,5-2,8 ms) ; le système de réactivité de Vue le rend possible une fois que les messages sont en mémoire. Le chargement de page passe de 13,6 ms à **9,3 ms**, en ligne avec 88 KB de JavaScript en moins à analyser.
 - **À propos des lignes natives.** `vue-intlayer` dans cette exécution a regroupé chaque locale en mode `static` et a atteint 57,1 KB avec un runtime de 3,9 KB ; les dictionnaires synchronisés de l'adaptateur contenaient moins de chaînes de locale étrangère, d'où la figure inférieure par page. Le runtime natif reste le plus léger des trois, et son modèle `.content.ts` est l'équivalent des blocs SFC `<i18n>`.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Tableau complet, chaque bibliothèque et chaque stratégie, dans le [rapport de benchmark Vue](https://intlayer.org/fr/doc/benchmark/vue).
+
 ## Pourquoi les chiffres changent
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Rien dans `src/components/` n'a changé, donc les gains proviennent de ce à quoi `useI18n` est lié.
 
-**Avec `vue-i18n`**, la liaison est l'instance globale. `createI18n({ messages: { en, fr, ... } })` est une seule importation qui contient tout ; chaque composant qui appelle `useI18n()` peut y accéder en entier, donc le bundler ne peut pas diviser en dessous de l'instance. L'optimisation signifie que _vous_ divisez `en.json` par route, appelez `setLocaleMessage()` dans un garde de routeur, et gardez la carte route-vers-fichier correcte au fur et à mesure que les composants se déplacent.
+**Avec `vue-i18n`**, la liaison est l'instance globale. `createI18n({ messages: { en, fr, ... } })` est une seule importation qui contient tout ; chaque composant qui appelle `useI18n()` peut y accéder en entier, donc le bundler ne peut pas diviser en dessous de l'instance. L'optimisation signifie que _vous_ divisez `en.json` par route, appelez `setLocaleMessage()` dans un garde de routeur, et gardez la carte route-vers-fichier correcte au fur et à mesure que les composants se déplacent. 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
 .
@@ -238,6 +257,7 @@ export const i18n = createI18n({ locale: "en" });
 `vueI18nVitePlugin()` enveloppe `vite-intlayer` (surveillance du contenu, compilation du dictionnaire, l'étape d'optimisation) et crée un alias de `vue-i18n` vers l'adaptateur. La suppression de l'importation `messages` est ce qui réduit les 88 KB ; la laisser conserve le fonctionnement de l'application mais expédie les deux.
 
 </Step>
+</Steps>
 
 ### Ce que vous pouvez supprimer par la suite
 
@@ -257,26 +277,107 @@ export const i18n = createI18n({ locale: "en" });
 
 ## Limitations à connaître avant de commencer
 
-- **Les blocs SFC `<i18n>` ne sont pas lus.** Si vos messages se trouvent à l'intérieur des composants, ils doivent être déplacés vers les fichiers de locale (ou vers `.content.ts`, qui est la même idée avec les types).
-- **Le chargement des messages à l'exécution a disparu.** `setLocaleMessage()` et `mergeLocaleMessage()` avertissent et retournent. Les traductions récupérées d'un CMS à l'exécution nécessitent le CMS d'Intlayer, ou les commandes `intlayer pull` / `push`.
-- **`messages` est un fallback, pas gratuit.** Garder les imports JSON dans `createI18n()` maintient les 75 KB dans le bundle. Supprimez-les une fois que `intlayer test` passe.
-- **L'adaptateur n'est pas le runtime natif.** 7.9 KB contre 3.9 KB pour `vue-intlayer`. Une fois que chaque composant a migré vers `useIntlayer`, supprimez-le.
+<AccordionGroup>
+<Accordion header="Les blocs SFC <i18n> ne sont pas lus">
+
+Si vos messages se trouvent dans des composants, ils doivent être déplacés vers les fichiers de locale, ou vers un fichier `.content.ts`, ce qui est la même idée avec des types générés.
+
+</Accordion>
+<Accordion header="Le chargement de messages au runtime a disparu">
+
+`setLocaleMessage()` et `mergeLocaleMessage()` affichent un avertissement et retournent. Les traductions récupérées depuis un CMS au runtime nécessitent le [CMS d'Intlayer](https://intlayer.org/fr/doc/concept/cms), ou les commandes `intlayer pull` / `push`.
+
+</Accordion>
+<Accordion header="messages est une solution de repli, pas gratuite">
+
+Garder les imports JSON dans `createI18n()` conserve les 75 KB dans le bundle. Supprimez-les une fois que `intlayer test` réussit.
+
+</Accordion>
+<Accordion header="L'adaptateur n'est pas le runtime natif">
+
+7.9 KB contre 3.9 KB pour `vue-intlayer`. Une fois que chaque composant est passé à `useIntlayer`, supprimez-le.
+
+</Accordion>
+</AccordionGroup>
 
 ## Quand utiliser quoi ?
 
-- **Restez sur `vue-i18n`** si votre app dépend des blocs SFC `<i18n>`, des flux runtime `setLocaleMessage()`, ou si 90 KB par page n'est pas une préoccupation pour votre audience.
-- **Utilisez `@intlayer/vue-i18n`** si vous êtes sur `vue-i18n` et souhaitez les 88 KB économisés, les composants 23x plus petits, 0% de fuite de page, les clés typées et les vérifications CI sans éditer un fichier `.vue`. C'est le point d'entrée pour une codebase `vue-i18n` existante.
-- **Allez au natif (`vue-intlayer`)** pour les nouveaux projets, ou une fois que l'adaptateur a fait son travail. Il dispose du runtime le plus léger (3.9 KB) et du modèle `.content.ts` par composant qui remplace les blocs `<i18n>` par du contenu typé.
+<AccordionGroup>
+<Accordion header="Rester sur vue-i18n">
+
+Votre application dépend des blocs SFC `<i18n>`, des flux `setLocaleMessage()` au runtime, ou 90 KB par page n'est pas une préoccupation pour votre public.
+
+</Accordion>
+<Accordion header="Utiliser @intlayer/vue-i18n">
+
+Vous utilisez `vue-i18n` et souhaitez économiser 88 KB, avoir des composants 23x plus petits, 0% de fuite de page, des clés typées et des vérifications CI sans modifier un seul fichier `.vue`. C'est le point d'entrée pour une codebase `vue-i18n` existante.
+
+</Accordion>
+<Accordion header="Passer en natif (vue-intlayer)">
+
+Pour les nouveaux projets, ou une fois que l'adaptateur a fait son travail. Il possède le runtime le plus léger (3.9 KB) et le modèle `.content.ts` par composant qui remplace les blocs `<i18n>` par du contenu typé. Commencez avec [Intlayer avec Vue](https://intlayer.org/fr/doc/environment/vite-and-vue) ou [avec Nuxt](https://intlayer.org/fr/doc/environment/nuxt-and-vue).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Dois-je modifier mes fichiers .vue ?">
+
+Non. Le build de benchmark n'a modifié que `vite.config.ts`, `intlayer.config.ts` et une ligne dans `src/i18n.ts`, l'import de `messages`. Chaque appel à `useI18n()`, `$t`, `v-t` et l'Options API reste tel quel.
+
+</Question>
+
+<Question title="Pourquoi la taille des composants est-elle 23x plus petite ?">
+
+Parce que `useI18n()` ne fait plus référence à l'instance globale. `createI18n({ messages })` contient tous les messages de chaque locale, donc un composant compilé isolément embarque 196 KB. Avec l'adaptateur, il n'accède qu'à son propre dictionnaire : 8.4 KB.
+
+</Question>
+
+<Question title="Qu'en est-il du formatage avec d() et n() ?">
+
+Conservé. Les configurations `datetimeFormats` et `numberFormats` passées à `createI18n()` sont respectées, prises en charge par l'API native `Intl`. Consultez [formatage de dates, heures et nombres](https://intlayer.org/fr/blog/date-time-number-formatting-locales).
+
+</Question>
+
+<Question title="Fonctionne-t-il avec Nuxt ?">
+
+`@intlayer/vue-i18n` cible Vite + Vue. Pour `@nuxtjs/i18n`, utilisez l'[adaptateur de compatibilité Nuxt i18n](https://intlayer.org/fr/doc/compatibility/nuxtjs-i18n), et consultez [Intlayer avec Nuxt](https://intlayer.org/fr/doc/environment/nuxt-and-vue) pour l'installation native.
+
+</Question>
+
+<Question title="Puis-je migrer composant par composant ?">
+
+Oui. N'importe quel composant peut passer de `useI18n()` à `useIntlayer("footer")` avec un fichier de contenu colocalisé. Les dictionnaires JSON et `.content.ts` coexistent et fusionnent.
+
+</Question>
+
+</FAQ>
 
 ## Comparaisons associées
 
-- [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) (features et DX)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark) (les libraries, même benchmark)
-- [next-intl vs @intlayer/next-intl](https://intlayer.org/blog/next-intl-vs-intlayer-next-intl) (même série d'adapter)
-- [i18next vs @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) (même série d'adapter)
-- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (même série d'adapter)
-- [Guide de migration : vue-i18n vers Intlayer](https://intlayer.org/doc/migration/vue-i18n)
-- [Référence de l'adaptateur de compatibilité : vue-i18n](https://intlayer.org/doc/compatibility/vue-i18n), [Nuxt i18n](https://intlayer.org/doc/compatibility/nuxtjs-i18n)
+Même série d'adaptateurs :
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/fr/blog/next-intl-vs-intlayer-next-intl)
+- [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)
+
+Les bibliothèques comparées directement :
+
+- [vue-i18n vs Intlayer](https://intlayer.org/fr/blog/vue-i18n-vs-intlayer), features et DX
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/fr/blog/vue-i18n-vs-intlayer-benchmark)
+- [Is vue-i18n outdated?](https://intlayer.org/fr/blog/is-vue-i18n-outdated)
+- [How to pick a Vue i18n library](https://intlayer.org/fr/blog/how-to-pick-vue-i18n-library)
+
+Documentation de référence :
+
+- [Compat adapter: vue-i18n](https://intlayer.org/fr/doc/compatibility/vue-i18n) and [Nuxt i18n](https://intlayer.org/fr/doc/compatibility/nuxtjs-i18n)
+- [Guide de migration : vue-i18n vers Intlayer](https://intlayer.org/fr/doc/migration/vue-i18n)
+- [Rapport de benchmark Vue](https://intlayer.org/fr/doc/benchmark/vue)
+- [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
 
@@ -284,4 +385,4 @@ export const i18n = createI18n({ locale: "en" });
 
 Toutes les données brutes, les applications de test et les scripts se trouvent dans le [référentiel Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Exécutez-le vous-même.
 
-Reportez-vous à la [documentation 'Pourquoi Intlayer ?'](https://intlayer.org/doc/why) pour plus de détails.
+Reportez-vous à la [documentation 'Pourquoi Intlayer ?'](https://intlayer.org/fr/doc/why) pour plus de détails.