@intlayer/docs 9.4.1 → 9.4.3

package/docs/fr/bundle_optimization.md

@@ -43,139 +43,6 @@ Par exemple, une application avec 10 pages traduites en 10 langues peut entraîn
 
 <TOC />
 
-## Analyser votre bundle
-
-L'analyse de votre bundle est la première étape pour identifier les fichiers JSON "lourds" et les opportunités de fractionnement de code (code-splitting). Ces outils génèrent une carte arborescente (treemap) visuelle du code compilé de votre application, vous permettant de voir exactement quelles bibliothèques consomment le plus d'espace.
-
-<Tabs>
- <Tab value="vite">
-
-### Vite / Rollup
-
-Vite utilise Rollup sous le capot. Le plugin `rollup-plugin-visualizer` génère un fichier HTML interactif montrant la taille de chaque module dans votre graphique.
-
-```bash
-npm install -D rollup-plugin-visualizer
-```
-
-```typescript fileName="vite.config.ts"
-import { defineConfig } from "vite";
-import { visualizer } from "rollup-plugin-visualizer";
-
-export default defineConfig({
-  plugins: [
-    visualizer({
-      open: true, // Ouvre automatiquement le rapport dans votre navigateur
-      filename: "stats.html",
-      gzipSize: true,
-      brotliSize: true,
-    }),
-  ],
-});
-```
-
- </Tab>
- <Tab value="nextjs (turbopack)">
-
-### Next.js (Turbopack)
-
-Pour les projets utilisant l'App Router et Turbopack, Next.js fournit un analyseur expérimental intégré qui ne nécessite aucune dépendance supplémentaire.
-
-```bash packageManager='npm'
-npx next experimental-analyze
-```
-
-```bash packageManager='yarn'
-yarn next experimental-analyze
-```
-
-```bash packageManager='pnpm'
-pnpm next experimental-analyze
-```
-
-```bash packageManager='bun'
-bun next experimental-analyze
-```
-
- </Tab>
- <Tab value="nextjs (Webpack)">
-
-### Next.js (Webpack)
-
-Si vous utilisez le bundler Webpack par défaut dans Next.js, utilisez l'analyseur de bundle officiel. Déclenchez-le en définissant une variable d'environnement lors de votre build.
-
-```bash packageManager='npm'
-npm install -D @next/bundle-analyzer
-```
-
-```bash packageManager='yarn'
-yarn add -D @next/bundle-analyzer
-```
-
-```bash packageManager='pnpm'
-pnpm add -D @next/bundle-analyzer
-```
-
-```bash packageManager='bun'
-bun add -d @next/bundle-analyzer
-```
-
-```javascript fileName="next.config.js"
-const withBundleAnalyzer = require("@next/bundle-analyzer")({
-  enabled: process.env.ANALYZE === "true",
-});
-
-module.exports = withBundleAnalyzer({
-  // Votre configuration Next.js
-});
-```
-
-**Utilisation :**
-
-```bash
-ANALYZE=true npm run build
-```
-
- </Tab>
- <Tab value="Webpack (CRA / Angular / etc)">
-
-### Webpack standard
-
-Pour Create React App (ejected), Angular ou les configurations Webpack personnalisées, utilisez le standard de l'industrie `webpack-bundle-analyzer`.
-
-```bash packageManager='npm'
-npm install -D webpack-bundle-analyzer
-```
-
-```bash packageManager='yarn'
-yarn add -D webpack-bundle-analyzer
-```
-
-```bash packageManager='pnpm'
-pnpm add -D webpack-bundle-analyzer
-```
-
-```bash packageManager='bun'
-bun add -d webpack-bundle-analyzer
-```
-
-```typescript fileName="webpack.config.ts"
-import { BundleAnalyzerPlugin } from "webpack-bundle-analyzer";
-
-export default {
-  plugins: [
-    new BundleAnalyzerPlugin({
-      analyzerMode: "static",
-      reportFilename: "bundle-analyzer.html",
-      openAnalyzer: false,
-    }),
-  ],
-};
-```
-
- </Tab>
-</Tabs>
-
 ## Comment ça fonctionne
 
 Intlayer utilise une **approche par composant**. Contrairement aux fichiers JSON globaux, votre contenu est défini à côté ou à l'intérieur de vos composants. Lors du processus de build, Intlayer :
@@ -189,59 +56,6 @@ Cela garantit que :
 - Si un composant n'est pas importé, son contenu n'est pas inclus dans le bundle (Élimination de code mort).
 - Si un composant est chargé de manière paresseuse, son contenu l'est aussi.
 
-## Référence des plugins
-
-L'optimisation de build d'Intlayer est divisée en plusieurs plugins distincts, chacun ayant une responsabilité unique. Comprendre ce que fait chacun d'eux évite la confusion lors de leur configuration.
-
-### Plugins Babel (`@intlayer/babel`)
-
-Ceux-ci sont utilisés directement dans `babel.config.js` pour les configurations basées sur Webpack (Next.js avec Babel, CRA, Webpack personnalisé, etc.).
-
-Le tableau ci-dessous les liste dans leur ordre de pipeline requis (le même ordre dans lequel ils doivent apparaître dans `babel.config.js`) :
-
-| Plugin                        | Ce qu'il fait                                                                                                                                |
-| :---------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------- |
-| `intlayerExtractBabelPlugin`  | Analyse les fichiers `.content.ts` et écrit les dictionnaires compilés dans `.intlayer/`                                                     |
-| `intlayerPurgeBabelPlugin`    | Analyse tous les fichiers sources, supprime les **champs de contenu inutilisés** des fichiers de dictionnaire compilés `.intlayer/**/*.json` |
-| `intlayerMinifyBabelPlugin`   | **Renomme les clés des champs de contenu** par de courts alias alphabétiques (`title` → `a`) dans les fichiers JSON et le code source        |
-| `intlayerOptimizeBabelPlugin` | Réécrit `useIntlayer('key')` → `useDictionary(hash)` et injecte l'`import` du dictionnaire correspondant                                     |
-
-> **L'ordre des plugins a de l'importance.** Dans votre `babel.config.js`, les plugins de purge et de minification doivent apparaître **avant** le plugin d'optimisation. La passe d'optimisation remplace `useIntlayer('key')` par un appel opaque `useDictionary(hash)`, effaçant l'information de la clé du dictionnaire dont les passes de purge et de minification ont besoin pour identifier les champs utilisés.
-
-Chaque plugin Babel dispose d'un helper d'options correspondant qui lit votre `intlayer.config.ts` une fois lors du chargement de la configuration et renvoie les valeurs pré-résolues :
-
-| Helper d'options             | Utilisé avec                  |
-| :--------------------------- | :---------------------------- |
-| `getExtractPluginOptions()`  | `intlayerExtractBabelPlugin`  |
-| `getPurgePluginOptions()`    | `intlayerPurgeBabelPlugin`    |
-| `getMinifyPluginOptions()`   | `intlayerMinifyBabelPlugin`   |
-| `getOptimizePluginOptions()` | `intlayerOptimizeBabelPlugin` |
-
-### Plugins Vite (`vite-intlayer`)
-
-Les utilisateurs de Vite **ne configurent jamais ceux-ci directement**. Ils sont automatiquement mis en place lorsque vous appelez `withIntlayer()` dans `vite.config.ts`. Les drapeaux `build.purge` et `build.minify` dans `intlayer.config.ts` basculent le comportement correspondant sans aucune inscription supplémentaire de plugin.
-
-| Plugin Vite interne     | Comportement équivalent                                                                              |
-| :---------------------- | :--------------------------------------------------------------------------------------------------- |
-| Analyseur d'usage       | Identique à la passe d'analyse de `intlayerPurgeBabelPlugin`                                         |
-| Élagage de dictionnaire | Identique à la passe d'écriture JSON de `intlayerPurgeBabelPlugin`                                   |
-| Minification de dict.   | Identique à la passe d'écriture JSON de `intlayerMinifyBabelPlugin`                                  |
-| Transformation Babel    | Identique au renommage de code source de `intlayerMinifyBabelPlugin` + `intlayerOptimizeBabelPlugin` |
-
-### Plugin SWC (`@intlayer/swc`)
-
-Les utilisateurs de Next.js **ne configurent jamais ceux-ci directement** non plus. Depuis la **v9.2.1**, `withIntlayer()` dans `next.config.ts` exécute l'ensemble du pipeline — purge, minification et réécriture des imports — à partir des seuls drapeaux `build.purge` et `build.minify`.
-
-Le travail est réparti en deux, car un plugin SWC Wasm transforme un fichier à la fois, sans accès au système de fichiers :
-
-| Passe                                         | Où elle s'exécute           | Ce qu'elle fait                                                                                        |
-| :-------------------------------------------- | :-------------------------- | :----------------------------------------------------------------------------------------------------- |
-| Analyse d'usage + purge/minification JSON     | Node, dans `withIntlayer()` | Lit chaque fichier source de composant, réécrit `.intlayer/**/*.json`, produit les tables de renommage |
-| Réécriture du source (`content.title` → `.a`) | `@intlayer/swc` (Wasm)      | Applique les tables de renommage aux accès de propriétés correspondants dans votre code                |
-| Réécriture des imports (`useIntlayer` → dict) | `@intlayer/swc` (Wasm)      | Identique à `intlayerOptimizeBabelPlugin`                                                              |
-
-Déterminer _quels_ champs sont inutilisés et _quel_ alias attribuer à chacun nécessite un état inter-fichiers et des E/S fichier ; cette moitié s'exécute donc dans Node, et le plugin SWC ne reçoit que les tables résultantes.
-
 ## Configuration par plateforme
 
 <Tabs>
@@ -405,6 +219,59 @@ module.exports = {
  </Tab>
 </Tabs>
 
+## Référence des plugins
+
+L'optimisation de build d'Intlayer est divisée en plusieurs plugins distincts, chacun ayant une responsabilité unique. Comprendre ce que fait chacun d'eux évite la confusion lors de leur configuration.
+
+### Plugins Babel (`@intlayer/babel`)
+
+Ceux-ci sont utilisés directement dans `babel.config.js` pour les configurations basées sur Webpack (Next.js avec Babel, CRA, Webpack personnalisé, etc.).
+
+Le tableau ci-dessous les liste dans leur ordre de pipeline requis (le même ordre dans lequel ils doivent apparaître dans `babel.config.js`) :
+
+| Plugin                        | Ce qu'il fait                                                                                                                                |
+| :---------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------- |
+| `intlayerExtractBabelPlugin`  | Analyse les fichiers `.content.ts` et écrit les dictionnaires compilés dans `.intlayer/`                                                     |
+| `intlayerPurgeBabelPlugin`    | Analyse tous les fichiers sources, supprime les **champs de contenu inutilisés** des fichiers de dictionnaire compilés `.intlayer/**/*.json` |
+| `intlayerMinifyBabelPlugin`   | **Renomme les clés des champs de contenu** par de courts alias alphabétiques (`title` → `a`) dans les fichiers JSON et le code source        |
+| `intlayerOptimizeBabelPlugin` | Réécrit `useIntlayer('key')` → `useDictionary(hash)` et injecte l'`import` du dictionnaire correspondant                                     |
+
+> **L'ordre des plugins a de l'importance.** Dans votre `babel.config.js`, les plugins de purge et de minification doivent apparaître **avant** le plugin d'optimisation. La passe d'optimisation remplace `useIntlayer('key')` par un appel opaque `useDictionary(hash)`, effaçant l'information de la clé du dictionnaire dont les passes de purge et de minification ont besoin pour identifier les champs utilisés.
+
+Chaque plugin Babel dispose d'un helper d'options correspondant qui lit votre `intlayer.config.ts` une fois lors du chargement de la configuration et renvoie les valeurs pré-résolues :
+
+| Helper d'options             | Utilisé avec                  |
+| :--------------------------- | :---------------------------- |
+| `getExtractPluginOptions()`  | `intlayerExtractBabelPlugin`  |
+| `getPurgePluginOptions()`    | `intlayerPurgeBabelPlugin`    |
+| `getMinifyPluginOptions()`   | `intlayerMinifyBabelPlugin`   |
+| `getOptimizePluginOptions()` | `intlayerOptimizeBabelPlugin` |
+
+### Plugins Vite (`vite-intlayer`)
+
+Les utilisateurs de Vite **ne configurent jamais ceux-ci directement**. Ils sont automatiquement mis en place lorsque vous appelez `withIntlayer()` dans `vite.config.ts`. Les drapeaux `build.purge` et `build.minify` dans `intlayer.config.ts` basculent le comportement correspondant sans aucune inscription supplémentaire de plugin.
+
+| Plugin Vite interne     | Comportement équivalent                                                                              |
+| :---------------------- | :--------------------------------------------------------------------------------------------------- |
+| Analyseur d'usage       | Identique à la passe d'analyse de `intlayerPurgeBabelPlugin`                                         |
+| Élagage de dictionnaire | Identique à la passe d'écriture JSON de `intlayerPurgeBabelPlugin`                                   |
+| Minification de dict.   | Identique à la passe d'écriture JSON de `intlayerMinifyBabelPlugin`                                  |
+| Transformation Babel    | Identique au renommage de code source de `intlayerMinifyBabelPlugin` + `intlayerOptimizeBabelPlugin` |
+
+### Plugin SWC (`@intlayer/swc`)
+
+Les utilisateurs de Next.js **ne configurent jamais ceux-ci directement** non plus. Depuis la **v9.2.1**, `withIntlayer()` dans `next.config.ts` exécute l'ensemble du pipeline — purge, minification et réécriture des imports — à partir des seuls drapeaux `build.purge` et `build.minify`.
+
+Le travail est réparti en deux, car un plugin SWC Wasm transforme un fichier à la fois, sans accès au système de fichiers :
+
+| Passe                                         | Où elle s'exécute           | Ce qu'elle fait                                                                                        |
+| :-------------------------------------------- | :-------------------------- | :----------------------------------------------------------------------------------------------------- |
+| Analyse d'usage + purge/minification JSON     | Node, dans `withIntlayer()` | Lit chaque fichier source de composant, réécrit `.intlayer/**/*.json`, produit les tables de renommage |
+| Réécriture du source (`content.title` → `.a`) | `@intlayer/swc` (Wasm)      | Applique les tables de renommage aux accès de propriétés correspondants dans votre code                |
+| Réécriture des imports (`useIntlayer` → dict) | `@intlayer/swc` (Wasm)      | Identique à `intlayerOptimizeBabelPlugin`                                                              |
+
+Déterminer _quels_ champs sont inutilisés et _quel_ alias attribuer à chacun nécessite un état inter-fichiers et des E/S fichier ; cette moitié s'exécute donc dans Node, et le plugin SWC ne reçoit que les tables résultantes.
+
 ## Configuration
 
 Vous pouvez contrôler la façon dont Intlayer optimise votre bundle via la propriété `build` de votre `intlayer.config.ts`.
@@ -650,3 +517,136 @@ const content = useDictionaryAsync({
 | **Requêtes réseau**            | 0 requête supplémentaire                        | 1 requête par clé de dictionnaire                |
 | **Tree Shaking**               | Niveau composant                                | Niveau composant + Niveau langue                 |
 | **Meilleur cas d'utilisation** | Composants UI, petites applications             | Pages avec beaucoup de texte, nombreuses langues |
+
+## Analyser votre bundle
+
+L'analyse de votre bundle est le moyen le plus direct d'identifier les fichiers JSON "lourds" et les opportunités de fractionnement de code (code-splitting). Ces outils génèrent une carte arborescente (treemap) visuelle du code compilé de votre application, vous permettant de voir exactement quelles bibliothèques consomment le plus d'espace.
+
+<Tabs>
+ <Tab value="vite">
+
+### Vite / Rollup
+
+Vite utilise Rollup sous le capot. Le plugin `rollup-plugin-visualizer` génère un fichier HTML interactif montrant la taille de chaque module dans votre graphique.
+
+```bash
+npm install -D rollup-plugin-visualizer
+```
+
+```typescript fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import { visualizer } from "rollup-plugin-visualizer";
+
+export default defineConfig({
+  plugins: [
+    visualizer({
+      open: true, // Ouvre automatiquement le rapport dans votre navigateur
+      filename: "stats.html",
+      gzipSize: true,
+      brotliSize: true,
+    }),
+  ],
+});
+```
+
+ </Tab>
+ <Tab value="nextjs (turbopack)">
+
+### Next.js (Turbopack)
+
+Pour les projets utilisant l'App Router et Turbopack, Next.js fournit un analyseur expérimental intégré qui ne nécessite aucune dépendance supplémentaire.
+
+```bash packageManager='npm'
+npx next experimental-analyze
+```
+
+```bash packageManager='yarn'
+yarn next experimental-analyze
+```
+
+```bash packageManager='pnpm'
+pnpm next experimental-analyze
+```
+
+```bash packageManager='bun'
+bun next experimental-analyze
+```
+
+ </Tab>
+ <Tab value="nextjs (Webpack)">
+
+### Next.js (Webpack)
+
+Si vous utilisez le bundler Webpack par défaut dans Next.js, utilisez l'analyseur de bundle officiel. Déclenchez-le en définissant une variable d'environnement lors de votre build.
+
+```bash packageManager='npm'
+npm install -D @next/bundle-analyzer
+```
+
+```bash packageManager='yarn'
+yarn add -D @next/bundle-analyzer
+```
+
+```bash packageManager='pnpm'
+pnpm add -D @next/bundle-analyzer
+```
+
+```bash packageManager='bun'
+bun add -d @next/bundle-analyzer
+```
+
+```javascript fileName="next.config.js"
+const withBundleAnalyzer = require("@next/bundle-analyzer")({
+  enabled: process.env.ANALYZE === "true",
+});
+
+module.exports = withBundleAnalyzer({
+  // Votre configuration Next.js
+});
+```
+
+**Utilisation :**
+
+```bash
+ANALYZE=true npm run build
+```
+
+ </Tab>
+ <Tab value="Webpack (CRA / Angular / etc)">
+
+### Webpack standard
+
+Pour Create React App (ejected), Angular ou les configurations Webpack personnalisées, utilisez le standard de l'industrie `webpack-bundle-analyzer`.
+
+```bash packageManager='npm'
+npm install -D webpack-bundle-analyzer
+```
+
+```bash packageManager='yarn'
+yarn add -D webpack-bundle-analyzer
+```
+
+```bash packageManager='pnpm'
+pnpm add -D webpack-bundle-analyzer
+```
+
+```bash packageManager='bun'
+bun add -d webpack-bundle-analyzer
+```
+
+```typescript fileName="webpack.config.ts"
+import { BundleAnalyzerPlugin } from "webpack-bundle-analyzer";
+
+export default {
+  plugins: [
+    new BundleAnalyzerPlugin({
+      analyzerMode: "static",
+      reportFilename: "bundle-analyzer.html",
+      openAnalyzer: false,
+    }),
+  ],
+};
+```
+
+ </Tab>
+</Tabs>

package/docs/fr/configuration.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-13
-updatedAt: 2026-08-22
+updatedAt: 2026-08-29
 title: Configuration
 description: Apprenez à configurer Intlayer pour votre application. Comprenez les différents paramètres et options disponibles pour personnaliser Intlayer selon vos besoins.
 keywords:
@@ -1124,3 +1124,101 @@ Paramètres qui contrôlent le compilateur Intlayer, qui extrait les dictionnair
 | Champ     | Description                           | Type               |
 | --------- | ------------------------------------- | ------------------ |
 | `plugins` | Liste des plugins Intlayer à activer. | `IntlayerPlugin[]` |
+
+## Questions fréquentes
+
+<FAQ>
+
+<Question title="Où doit se trouver le fichier intlayer.config.ts ?">
+
+À la racine de votre projet, à côté de `package.json`. Intlayer accepte aussi `intlayer.config.js`, `intlayer.config.mjs`, `intlayer.config.cjs` et le JSON, afin que le fichier corresponde au système de modules utilisé par votre projet.
+
+</Question>
+
+<Question title="Quel poids l'i18n ajoute-t-elle à la taille de mon bundle ?">
+
+Bien moins qu'une configuration basée sur des espaces de noms, car une page ne télécharge jamais un catalogue qu'elle n'affiche pas. Le balisage rendu côté serveur résout son contenu sur le serveur, et le compilateur au moment du build remplace les appels `useIntlayer` par les entrées de dictionnaire exactes qu'un composant utilise, si bien que les clés inutilisées et les langues inutilisées sont éliminées. Les [dictionnaires dynamiques](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/dynamic_dictionaries/index.md) répartissent le reste par locale. Mesuré face aux alternatives habituelles, Intlayer réduit la taille du bundle et des pages jusqu'à 50 %. Voir l'[optimisation du bundle](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/bundle_optimization.md) et le [benchmark](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/benchmark/index.md).
+
+</Question>
+
+<Question title="Puis-je migrer depuis `i18next`, `next-intl` ou `react-i18next` sans réécrire mes composants ?">
+
+Oui, et il existe deux voies. Vous pouvez migrer le contenu progressivement avec le [guide de migration i18next](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/migration_from_i18next_to_intlayer.md) ou le [guide de migration next-intl](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/migration_from_next-intl_to_intlayer.md). Ou vous pouvez conserver entièrement votre API actuelle : les [adaptateurs de compatibilité](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/compat/index.md) exposent exactement la même API que `i18next`, `react-i18next`, `next-intl`, `next-i18next`, `react-intl`, `use-intl`, `vue-i18n` et `Lingui`, mais servie par des dictionnaires Intlayer : seuls les imports changent, pas le code des composants.
+
+</Question>
+
+<Question title="Puis-je conserver mes fichiers de traduction JSON existants ?">
+
+Oui. Le [plugin de synchronisation JSON](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/plugins/sync-json.md) conserve vos fichiers `/messages/{locale}/{namespace}.json` comme source de vérité et génère les dictionnaires Intlayer à partir d'eux, dans les deux sens. Un [plugin de synchronisation PO](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/plugins/sync-po.md) fait de même pour les catalogues gettext, et les [fichiers par locale](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/per_locale_file.md) permettent de séparer le contenu par langue au lieu de regrouper les locales dans un seul fichier.
+
+</Question>
+
+<Question title="Dois-je déplacer mon contenu clé par clé ?">
+
+Non. Lancez `npx intlayer extract` et Intlayer lit vos fichiers source, en extrait les chaînes destinées aux utilisateurs et écrit un fichier `.content` à côté de chacun, de sorte que vous relisez un diff plutôt que de copier des chaînes dans un catalogue une par une. Voir la [commande extract](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/cli/extract.md).
+
+Pour un pipeline entièrement automatisé, le [compilateur Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/compiler.md) fait la même chose au moment du build sur du code source JSX, TSX, Vue et Svelte, en générant les dictionnaires à chaque changement, de sorte qu'il n'y a aucune clé à maintenir à la main. Il fonctionne par analyse statique : les chaînes qui n'existent qu'à l'exécution restent hors de portée, et il a besoin de quelques annotations pour distinguer le texte destiné aux utilisateurs de la logique applicative.
+
+</Question>
+
+<Question title="Quels outils d'éditeur et d'agent IA sont disponibles ?">
+
+Cinq éléments, tous optionnels :
+
+- **[Extension VS Code](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/vs_code_extension.md)** : passez d'une clé `useIntlayer` au fichier de contenu qui la déclare, extrayez du contenu depuis un composant, et lancez build, fill, test, push et pull depuis la palette de commandes ou un onglet Intlayer dédié.
+- **[Serveur LSP](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/lsp.md)** : la même connaissance dans tout éditeur qui parle LSP, avec aller à la définition, rechercher toutes les références, aperçus au survol d'une valeur traduite, autocomplétion des clés et des champs, et un avertissement lorsqu'une clé n'est déclarée nulle part. Il résout aussi les appels `i18next`, `react-i18next`, `next-intl` et `use-intl`, ce qui aide pendant la migration.
+- **[Serveur MCP](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/mcp_server.md)** : expose la documentation et la CLI d'Intlayer à Cursor, VS Code, Claude Desktop, Claude Code et ChatGPT, afin qu'un assistant réponde à partir de la documentation actuelle au lieu de deviner, et puisse exécuter lui-même des commandes telles que `intlayer fill`.
+- **[Compétences d'agent](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/agent_skills.md)** : des compétences ciblées telles que `intlayer-config`, `intlayer-cli` et `intlayer-content`, plus une par framework, qui apprennent à un agent votre configuration de routage et les types de nœuds de contenu.
+- **[Plugin ESLint](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/eslint.md)** : `no-raw-text` signale les chaînes codées en dur, avec d'autres règles pour les clés de dictionnaire statiques et le contenu inutilisé.
+
+</Question>
+
+<Question title="Comment ajouter une nouvelle langue à mon application ?">
+
+Ajoutez la locale à `internationalization.locales`, puis lancez `npx intlayer fill` pour traduire le contenu existant vers celle-ci. Les types générés se mettent à jour en même temps, si bien que tout fichier de contenu auquel il manque la nouvelle locale devient une erreur de type plutôt qu'un repli silencieux.
+
+</Question>
+
+<Question title="Comment retirer le préfixe de locale de mes URL ?">
+
+Définissez `routing.mode`. La valeur par défaut `"prefix-no-default"` donne `/about` pour la locale par défaut et `/fr/about` pour les autres. `"prefix-all"` préfixe toutes les locales. `"no-prefix"` maintient la locale entièrement hors du chemin et la résout à partir d'un cookie, d'un en-tête ou d'un domaine. `"search-params"` la place dans la chaîne de requête sous la forme `/about?locale=fr`.
+
+</Question>
+
+<Question title="Puis-je servir chaque langue depuis son propre domaine ?">
+
+Oui. `routing.domains` associe une locale à un nom d'hôte, par exemple `{ fr: 'example.fr', en: 'example.com' }`. Le domaine identifie la locale, donc aucun préfixe n'est ajouté au chemin, et `getLocalizedUrl` renvoie une URL absolue sur le bon domaine.
+
+</Question>
+
+<Question title="Comment la langue de l'utilisateur est-elle détectée ?">
+
+Via `routing.storage`, qui liste les sources à lire dans l'ordre, généralement l'URL, puis un cookie, puis l'en-tête `Accept-Language`. Un choix explicite de l'utilisateur est persisté afin qu'il l'emporte à la visite suivante.
+
+</Question>
+
+<Question title="Que fait routing.enableProxy ?">
+
+Il contrôle le proxy de routage de locale, le middleware qui résout les préfixes et effectue les redirections. Laissé non défini, le proxy s'exécute mais les serveurs de développement et de prévisualisation ignorent la locale stockée comme source de redirection, ce qui évite d'être renvoyé vers une langue que vous ne testez pas ; la production se comporte comme si sa valeur était `true`. Réglez-le sur `false` pour gérer vous-même le routage de locale.
+
+</Question>
+
+<Question title="Quelle est la différence entre importMode static, dynamic et fetch ?">
+
+`"static"`, la valeur par défaut, importe les dictionnaires de manière statique afin qu'ils soient inclus dans le bundle et lus de manière synchrone. `"dynamic"` les importe via Suspense, si bien qu'une locale n'est téléchargée que lorsqu'un composant l'affiche, ce qui est ce que vous voulez pour de grands ensembles de contenu. `"fetch"` les récupère depuis l'API de synchronisation en direct et se replie sur `"dynamic"` en cas d'échec. Voir l'[optimisation du bundle](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/bundle_optimization.md) et les [dictionnaires dynamiques](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/dynamic_dictionaries/index.md).
+
+</Question>
+
+<Question title="Où définir le fournisseur d'IA et la clé d'API pour la traduction automatique ?">
+
+Soit dans le fichier de configuration, soit en ligne de commande avec `--provider`, `--model` et `--api-key`. La clé reste la vôtre : les appels de traduction partent de votre machine ou de votre runner CI vers le fournisseur que vous avez choisi, si bien que rien ne transite par un tiers. Voir la [commande fill](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/cli/fill.md).
+
+</Question>
+
+<Question title="Dois-je redémarrer le serveur de développement après avoir changé la configuration ?">
+
+En général non. Le watcher d'Intlayer surveille `intlayer.config.ts` lui-même : à l'enregistrement, il recharge la configuration et prépare de nouveau les dictionnaires, si bien qu'ajouter une locale ou changer un mode de routage est pris en compte comme un changement de contenu. Cependant, la configuration peut être mise en cache par les systèmes. Redémarrer votre application peut être une bonne solution.
+
+</Question>
+
+</FAQ>

package/docs/fr/dictionary/content_file.md

@@ -363,15 +363,15 @@ Transforme le dictionnaire en un dictionnaire par locale où chaque champ décla
 
 **Exemple :**
 
-```json
+```jsonc
 // Dictionnaire par langue
 {
   "key": "about-page",
   "locale": "en",
   "content": {
     "title": "About Us", // Ceci devient un nœud de traduction pour 'en'
-    "description": "Learn more about our company"
-  }
+    "description": "Learn more about our company",
+  },
 }
 ```
 
@@ -440,7 +440,7 @@ Instructions pour remplir automatiquement le contenu du dictionnaire à partir d
 
 **Exemples :**
 
-```json
+```jsonc
 // Activer pour toutes les locales
 {
   "autoFill": true

package/docs/fr/dictionary/markdown.md

@@ -51,6 +51,7 @@ Vous pouvez déclarer du contenu Markdown en utilisant la fonction `md` ou simpl
 
 <Tabs>
   <Tab label=".content.md" value=".content.md">
+
     Depuis la version `8.10.0`, vous pouvez déclarer du contenu Markdown directement dans des fichiers `.content.md`. Intlayer détectera et analysera automatiquement le contenu Markdown.
 
     ```md fileName="markdown-file.en.content.md"
@@ -96,6 +97,7 @@ Vous pouvez déclarer du contenu Markdown en utilisant la fonction `md` ou simpl
     ```
 
   </Tab>
+
   <Tab label="Fichiers Externes" value="external-files">
     Importez des fichiers `.md` directement en utilisant la fonction `file`.
 
@@ -129,6 +131,7 @@ Vous pouvez déclarer du contenu Markdown en utilisant la fonction `md` ou simpl
     ```
 
   </Tab>
+
 </Tabs>
 
 ## Rendu Markdown
@@ -957,7 +960,21 @@ Le `MarkdownProvider` (ou son équivalent dans un framework) configure le pipeli
   </Tab>
   <Tab label="Angular" value="angular">
 
-> MDX est supporté — tout nom de composant utilisé dans votre Markdown (par exemple `<MyCustomJSXComponent />`) est résolu par rapport au mapping `components`.
+    ```typescript fileName="app.config.ts"
+    import { createIntlayerMarkdownProvider } from "angular-intlayer/markdown";
+
+    export const appConfig: ApplicationConfig = {
+      providers: [
+        createIntlayerMarkdownProvider({
+          components: {
+            h1: { class: "text-2xl font-bold" },
+          },
+        }),
+      ],
+    };
+    ```
+
+    > MDX est supporté — tout nom de composant utilisé dans votre Markdown (par exemple `<MyCustomJSXComponent />`) est résolu par rapport au mapping `components`.
 
 Vous pouvez également utiliser votre propre moteur de rendu Markdown :
 

package/docs/fr/dictionary/plurial.md

@@ -35,9 +35,12 @@ Contrairement à [`enu`](https://github.com/aymericzip/intlayer/blob/main/docs/d
 
 ## Quand utiliser `plural` vs `enu`
 
-To use plural content inside a React component, retrieve it via the `useIntlayer` hook and call it with a count. The active locale and the count are combined to pick the matching CLDR category.
+| Cas d'usage                                                               | Helper   |
+| ------------------------------------------------------------------------- | -------- |
+| Formes plurielles grammaticales selon la locale (une pomme / deux pommes) | `plural` |
+| Plages numériques personnalisées (`<5`, `>=10`) ou catégories hors CLDR   | `enu`    |
 
-To use plural content in Next.js Client Components, retrieve it via the `useIntlayer` hook and call it with a count. Here's an example:
+Si vous ne ciblez que l'anglais (qui n'a que `one` / `other`), les deux conviennent. Pour toute langue ayant des distinctions `few` / `many` / `two`, préférez `plural`.
 
 ## Configuration du contenu au pluriel