@intlayer/docs 9.5.1 → 9.5.2

package/docs/fr/benchmark/nextjs.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: La meilleure solution i18n pour Next.js en 2026 - Rapport de Benchmark
 description: Comparez les bibliothèques d'internationalisation (i18n) pour Next.js comme next-intl, next-i18next et Intlayer. Rapport de performance détaillé sur la taille du bundle, les fuites et la réactivité.
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "Mise à jour des résultats du benchmark"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Ajout du comparatif des étoiles GitHub"
@@ -56,7 +59,7 @@ Les bibliothèques d'internationalisation ont un impact lourd sur votre applicat
 
 À mesure que votre application grandit, la taille du bundle peut augmenter de manière exponentielle, ce qui peut nuire considérablement aux performances.
 
-Par exemple, pour les cas les plus critiques, une fois internationalisée, votre page peut finir par être près de 4 fois plus volumineuse.
+Par exemple, pour les cas les plus critiques, une fois internationalisée, votre page peut finir par être près de 2 fois plus volumineuse.
 
 Un autre impact des bibliothèques i18n est le ralentissement du développement. Transformer des composants en contenu multilingue à travers plusieurs langues prend du temps.
 
@@ -68,7 +71,7 @@ Intlayer tente d'optimiser l'ensemble de ces dimensions.
 
 - **Intlayer** & **next-translate** : Meilleurs choix pour la performance Next.js, offrant l'empreinte la plus faible et le meilleur support du rendu statique.
 - **next-intl** : L'option la plus tendance mais lourde et complexe à optimiser pour les grandes applications.
-- **next-i18next** : Populaire et riche en plugins, mais porte un poids de bundle significatif (~3× Intlayer).
+- **next-i18next** : Populaire et riche en plugins, mais porte un poids de bundle significatif (~3,5× Intlayer).
 - **À éviter** : **gt-next** et **lingo.dev** en raison de graves problèmes de performance, de verrouillage propriétaire et de bugs cassant le build.
 
 ## Testez votre application
@@ -109,19 +112,21 @@ Enfin, `Intlayer` applique une optimisation au moment du build afin que `useIntl
 Pour ce benchmark, nous avons comparé les bibliothèques suivantes :
 
 - `Base App` (Pas de bibliothèque i18n)
-- `next-intlayer` (v8.7.12)
-- `next-i18next` (v16.0.5)
-- `next-intl` (v4.9.1)
-- `@lingui/core` (v5.3.0)
-- `next-translate` (v3.1.2)
+- `next-intlayer` (v9.5.1)
+- [`@intlayer/next-intl`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/compat/next-intl.md) (v9.5.1)
+- [`@intlayer/next-i18next`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/compat/next-i18next.md) (v9.5.1)
+- `next-i18next` (v16.3.0)
+- `next-intl` (v4.14.2)
+- `@lingui/core` (v6.6.0)
+- `next-translate` (v3.2.0)
 - `next-international` (v1.3.1)
 - `@inlang/paraglide-js` (v2.15.1)
-- `@tolgee/react` (v7.0.0)
-- `@lingo.dev/compiler` (v0.4.0)
-- `wuchale` (v0.22.11)
-- `gt-next` (v6.16.5)
+- `@tolgee/react` (v7.2.0)
+- `@lingo.dev/compiler` (v0.4.12)
+- `wuchale` (v0.26.6)
+- `gt-next` (v11.1.24)
 
-J'ai utilisé `Next.js` en version `16.2.4` avec l'App Router.
+J'ai utilisé `Next.js` en version `16.3.4` avec l'App Router.
 
 J'ai construit une application multilingue avec **10 pages** et **10 langues**.
 
@@ -175,15 +180,15 @@ Certaines solutions, telles que `gt-next` ou `lingo.dev`, sont clairement à év
 
 Problèmes rencontrés :
 
-**(General Translation)** (`gt-next@6.16.5`) :
+**(General Translation)** (`gt-next@11.1.24`) :
 
-- Pour une application de 110 Ko, `gt-next` ajoute plus de 440 Ko supplémentaires.
+- Pour une application de 141 Ko, `gt-next` ajoute plus de 50 Ko supplémentaires.
 - `Quota Exceeded, please upgrade your plan` dès le tout premier build avec General Translation.
 - Les traductions ne sont pas rendues ; j'obtiens l'erreur `Error: <T> used on the client-side outside of <GTProvider>`, ce qui semble être un bug de la bibliothèque.
 - Lors de l'implémentation de **gt-next**, je suis également tombé sur un [problème](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) avec la bibliothèque : `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`, ce qui cassait l'application. Après avoir signalé ce problème, le mainteneur l'a corrigé sous 24 heures.
 - La bibliothèque bloque le rendu statique des pages Next.js.
 
-**(Lingo.dev)** (`@lingo.dev/compiler@0.4.0`) :
+**(Lingo.dev)** (`@lingo.dev/compiler@0.4.12`) :
 
 - Quota AI dépassé, bloquant entièrement le build - vous ne pouvez donc pas mettre en production sans payer.
 - Le compilateur ratait presque 40 % du contenu traduit. J'ai dû réécrire tous les `.map` en blocs de composants plats pour que cela fonctionne.
@@ -192,7 +197,7 @@ Problèmes rencontrés :
 
 ### 2 - Solutions expérimentales
 
-**(Wuchale)** (`wuchale@0.22.11`) :
+**(Wuchale)** (`wuchale@0.26.6`) :
 
 L'idée derrière `Wuchale` est intéressante mais pas encore viable. J'ai rencontré des problèmes de réactivité et j'ai dû forcer le re-rendu du provider pour faire fonctionner l'application. La documentation est également assez floue, ce qui rend l'adoption difficile.
 
@@ -202,21 +207,21 @@ L'idée derrière `Wuchale` est intéressante mais pas encore viable. J'ai renco
 Personnellement, je n'aime pas devoir régénérer des fichiers JS avant chaque push, ce qui crée un risque constant de conflit de fusion via les PRs. L'outil semble également plus axé sur Vite que sur Next.js.
 Enfin, par rapport aux autres solutions, Paraglide n'utilise pas de "store" (ex: contexte React) pour récupérer la langue actuelle afin de rendre le contenu. Pour chaque nœud analysé, il demandera la langue au localStorage / cookie etc. Cela conduit à l'exécution d'une logique inutile qui impacte la réactivité des composants.
 
-> Note sur paraglide : la solution injecte du code dans votre base de code à importer, par conséquent la métrique 'taille de la lib' dans le rapport de benchmark est presque de 0. La génération de code est une bonne chose, car la fonction utilisée n'inclura que la logique nécessaire (préfixe total vs pas de préfixe, cookie vs stockage etc). En comparaison, Intlayer procède à ce filtrage via des injections de variables d'environnement dans le build pour forcer le bundler à tree-shaker le contenu selon la logique. Grâce à cela, paraglide et intlayer finissent par être des solutions 6 à 10 fois plus légères que i18next ou next-intl.
+> Note sur paraglide : la solution injecte du code dans votre base de code à importer, par conséquent la métrique 'taille de la lib' dans le rapport de benchmark est presque de 0. La génération de code est une bonne chose, car la fonction utilisée n'inclura que la logique nécessaire (préfixe total vs pas de préfixe, cookie vs stockage etc). En comparaison, Intlayer procède à ce filtrage via des injections de variables d'environnement dans le build pour forcer le bundler à tree-shaker le contenu selon la logique. Grâce à cela, paraglide et intlayer finissent par être des solutions 3 à 8 fois plus légères que i18next ou next-intl.
 
 ### 3 - Solutions acceptables
 
-**(Tolgee)** (`@tolgee/react@7.0.0`) :
+**(Tolgee)** (`@tolgee/react@7.2.0`) :
 
 `Tolgee` traite bon nombre des problèmes mentionnés plus haut. Je l'ai trouvé plus difficile à adopter que des outils similaires. Il n'offre pas de sécurité de type (type safety), ce qui rend également plus difficile la détection des clés manquantes à la compilation. J'ai dû wrapper les fonctions de Tolgee avec les miennes pour ajouter la détection des clés manquantes.
 
-**(Next Intl)** (`next-intl@4.9.1`) :
+**(Next Intl)** (`next-intl@4.14.2`) :
 
-`next-intl` est l'option la plus à la mode et celle que les agents IA poussent le plus, mais à mon avis à tort. La mise en route est facile. En pratique, l'optimisation pour limiter les fuites est complexe. Combiner chargement dynamique + namespacing + types TypeScript ralentit beaucoup le développement. Le package est également assez lourd (env. 13 Ko pour `NextIntlClientProvider` + `useTranslations`, soit plus de 2 fois `next-intlayer`). **next-intl** bloquait auparavant le rendu statique des pages Next.js. Il fournit un helper nommé `setRequestLocale()`. Cela semble partiellement résolu pour les fichiers centralisés comme `en.json` / `fr.json`, mais le rendu statique casse toujours lorsque le contenu est divisé en namespaces tels que `en/shared.json` / `fr/shared.json` / `es/shared.json`.
+`next-intl` est l'option la plus à la mode et celle que les agents IA poussent le plus, mais à mon avis à tort. La mise en route est facile. En pratique, l'optimisation pour limiter les fuites est complexe. Combiner chargement dynamique + namespacing + types TypeScript ralentit beaucoup le développement. Le package est également assez lourd (env. 14,7 Ko pour `NextIntlClientProvider` + `useTranslations`, soit plus de 2,5 fois `next-intlayer`). **next-intl** bloquait auparavant le rendu statique des pages Next.js. Il fournit un helper nommé `setRequestLocale()`. Cela semble partiellement résolu pour les fichiers centralisés comme `en.json` / `fr.json`, mais le rendu statique casse toujours lorsque le contenu est divisé en namespaces tels que `en/shared.json` / `fr/shared.json` / `es/shared.json`.
 
-**(Next I18next)** (`next-i18next@16.0.5`) :
+**(Next I18next)** (`next-i18next@16.3.0`) :
 
-`next-i18next` est probablement l'option la plus populaire car elle fut l'une des premières solutions i18n pour les applications JavaScript. Elle dispose de nombreux plugins communautaires. Elle partage les mêmes inconvénients majeurs que `next-intl`. Le package est particulièrement lourd (env. 18 Ko pour `I18nProvider` + `useTranslation`, environ 3 fois `next-intlayer`).
+`next-i18next` est probablement l'option la plus populaire car elle fut l'une des premières solutions i18n pour les applications JavaScript. Elle dispose de nombreux plugins communautaires. Elle partage les mêmes inconvénients majeurs que `next-intl`. Le package est particulièrement lourd (env. 19,7 Ko pour `I18nProvider` + `useTranslation`, environ 3,5 fois `next-intlayer`).
 
 Les formats de messages diffèrent également : `next-intl` utilise ICU MessageFormat, tandis qu'i18next utilise son propre format.
 
@@ -224,17 +229,17 @@ Les formats de messages diffèrent également : `next-intl` utilise ICU MessageF
 
 `next-international` s'attaque également aux problèmes ci-dessus mais ne diffère pas beaucoup de `next-intl` ou `next-i18next`. Il inclut `scopedT()` pour les traductions spécifiques à un namespace, mais son utilisation n'a pratiquement aucun impact sur la taille du bundle.
 
-**(Lingui)** (`@lingui/core@5.3.0`) :
+**(Lingui)** (`@lingui/core@6.6.0`) :
 
 `Lingui` est souvent vanté. Personnellement, j'ai trouvé le workflow `lingui extract` / `lingui compile` plus complexe que les alternatives, sans avantage clair. J'ai également remarqué des syntaxes inconsistantes qui perturbent les IAs (ex: `t()`, `t''`, `i18n.t()`, `<Trans>`).
 
 ### 4 - Recommandations
 
-**(Next Translate)** (`next-translate@3.1.2`) :
+**(Next Translate)** (`next-translate@3.2.0`) :
 
-`next-translate` est ma recommandation principale si vous aimez une API de style `t()`. C'est élégant via `next-translate-plugin`, chargeant les namespaces via `getStaticProps` avec un loader Webpack / Turbopack. C'est aussi l'option la plus légère ici (env. 2,5 Ko). Pour le découpage en namespaces, la définition par page ou par route dans la config est bien pensée et plus facile à maintenir que les alternatives principales comme **next-intl** ou **next-i18next**. Dans la version `3.1.2`, j'ai noté que le rendu statique ne fonctionnait pas ; Next.js se repliait sur le rendu dynamique.
+`next-translate` est ma recommandation principale si vous aimez une API de style `t()`. C'est élégant via `next-translate-plugin`, chargeant les namespaces via `getStaticProps` avec un loader Webpack / Turbopack. C'est aussi l'une des options les plus légères ici (env. 3,5 Ko). Pour le découpage en namespaces, la définition par page ou par route dans la config est bien pensée et plus facile à maintenir que les alternatives principales comme **next-intl** ou **next-i18next**. Dans la version `3.1.2`, j'ai noté que le rendu statique ne fonctionnait pas ; Next.js se repliait sur le rendu dynamique.
 
-**(Intlayer)** (`next-intlayer@8.7.12`) :
+**(Intlayer)** (`next-intlayer@9.5.1`) :
 
 Je ne jugerai pas personnellement `next-intlayer` par souci d'objectivité, puisqu'il s'agit de ma propre solution.
 

package/docs/fr/benchmark/solid.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: La meilleure solution i18n pour Solid en 2026 - Rapport de Benchmark
 description: Comparez les bibliothèques d'internationalisation (i18n) pour Solid comme solid-primitives, solid-i18next et Intlayer. Rapport de performance détaillé sur la taille du bundle, les fuites et la réactivité.
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "Mise à jour des résultats du benchmark"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Ajout du comparatif des étoiles GitHub"
@@ -62,9 +65,9 @@ L'autre impact concerne l'expérience développeur (DX) : la façon dont vous d
 
 ## TL;DR
 
-- **Intlayer** : Choix recommandé pour les applications Solid professionnelles nécessitant des fonctionnalités avancées et une optimisation poussée (v8.7.12).
+- **Intlayer** : Choix recommandé pour les applications Solid professionnelles nécessitant des fonctionnalités avancées et une optimisation poussée (v9.5.0).
 - **@solid-primitives/i18n** : Excellente alternative légère pour les projets simples, bien qu'il manque de fonctionnalités avancées comme le lazy loading.
-- **solid-i18next** : Option standard mais lourde (~4.7× Intlayer) avec les mêmes inconvénients que React i18next.
+- **solid-i18next** : Option standard mais lourde (~3.5× Intlayer) avec les mêmes inconvénients que React i18next.
 - **Paraglide** : Approche innovante mais DX complexe et problèmes de tree-shaking dans certaines configurations.
 
 ## Testez votre application
@@ -97,10 +100,10 @@ Les syntaxes basées sur `t('a.b.c')` sont très pratiques mais encouragent souv
 Pour ce benchmark, nous avons comparé les bibliothèques suivantes :
 
 - `Base App` (Pas de bibliothèque i18n)
-- `solid-intlayer` (v8.7.12)
+- `solid-intlayer` (v9.5.0)
 - `@solid-primitives/i18n` (v2.2.1)
-- `solid-i18next` (v17.0.2)
-- `@inlang/paraglide-js` (v2.17.0)
+- `i18next` (v26.0.8) + `@mbarzda/solid-i18next` (v1.4.1)
+- `@inlang/paraglide-js` (v2.25.1)
 
 Le framework utilisé est `Solid` avec une application multilingue de **10 pages** et **10 langues**.
 
@@ -154,11 +157,11 @@ Les étoiles GitHub sont un indicateur fort de la popularité d'un projet, de la
 
 ### 2 - Solutions acceptables
 
-**(solid-i18next)** (`solid-i18next@17.0.2`) :
+**(solid-i18next)** (`i18next@26.0.8`) :
 
 `solid-i18next` est probablement l'option la plus populaire car elle fut l'une des premières à servir les besoins i18n des applications JS. Elle dispose également d'un large éventail de plugins communautaires pour des problèmes spécifiques.
 
-Le paquet est lourd (~14.6 Ko, soit environ 4.7× `solid-intlayer`).
+Le paquet est lourd (~14.9 Ko, soit environ 3.5× `solid-intlayer`).
 
 Pourtant, elle partage les mêmes inconvénients majeurs que les stacks basées sur `t('a.b.c')` : les optimisations sont possibles mais très gourmandes en temps, et les gros projets risquent de mauvaises pratiques (namespaces + chargement dynamique + types).
 
@@ -167,7 +170,7 @@ Pourtant, elle partage les mêmes inconvénients majeurs que les stacks basées
 Solid primitive est extrêmement léger et efficace. Je recommande cette solution pour les petits projets, mais elle peut rapidement manquer de fonctionnalités pour des solutions professionnelles incluant la gestion des cookies, la redirection proxy, les formateurs, etc.
 Elle manque également de lazy loading et de découpage des namespaces pour l'optimisation de la taille des pages.
 
-**(Paraglide)** (`@inlang/paraglide-js@2.17.0`) :
+**(Paraglide)** (`@inlang/paraglide-js@2.25.1`) :
 
 `Paraglide` propose une approche innovante et bien pensée. Pourtant, dans ce benchmark, le tree-shaking dont leur entreprise fait la publicité n'a pas fonctionné pour mon implémentation. Le workflow et la DX sont également plus complexes d'autres options.
 Personnellement, je n'aime pas devoir régénérer des fichiers JS avant chaque push, ce qui crée un risque constant de conflit de fusion via les PRs.
@@ -175,7 +178,7 @@ Enfin, par rapport à d'autres solutions, Paraglide n'utilise pas de store (ex:
 
 ### 3 - Recommandations
 
-**(Intlayer)** (`solid-intlayer@8.7.12`) :
+**(Intlayer)** (`solid-intlayer@9.5.0`) :
 
 Je ne jugerai pas personnellement `solid-intlayer` par souci d'objectivité, puisqu'il s'agit de ma propre solution.
 

package/docs/fr/benchmark/svelte.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: La meilleure solution i18n pour Svelte en 2026 - Rapport de Benchmark
 description: Comparez les bibliothèques d'internationalisation (i18n) pour Svelte comme svelte-i18n, Paraglide et Intlayer. Rapport de performance détaillé sur la taille du bundle, les fuites et la réactivité.
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "Mise à jour des résultats du benchmark"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Ajout du comparatif des étoiles GitHub"
@@ -62,9 +65,9 @@ L'autre impact concerne l'expérience développeur (DX) : la façon dont vous d
 
 ## TL;DR
 
-- **Intlayer** : Le choix le plus performant (v8.7.12) avec l'empreinte la plus faible.
+- **Intlayer** : Le choix le plus performant (v9.5.0) avec l'empreinte la plus faible.
 - **Paraglide** : Candidat sérieux pour le tree-shaking mais possède une expérience développeur plus complexe et un surcoût de réactivité.
-- **svelte-i18n** : Complet et standard pour Svelte, mais transporte un poids de bundle beaucoup plus important (~7× Intlayer).
+- **svelte-i18n** : Complet et standard pour Svelte, mais transporte un poids de bundle beaucoup plus important (~4.5× Intlayer).
 
 ## Testez votre application
 
@@ -96,9 +99,9 @@ Les syntaxes basées sur `t('a.b.c')` sont très pratiques mais encouragent souv
 Pour ce benchmark, nous avons comparé les bibliothèques suivantes :
 
 - `Base App` (Pas de bibliothèque i18n)
-- `svelte-intlayer` (v8.7.12)
+- `svelte-intlayer` (v9.5.0)
 - `svelte-i18n` (v4.0.1)
-- `@inlang/paraglide-js` (v2.17.0)
+- `@inlang/paraglide-js` (v2.25.1)
 
 Le framework utilisé est `Svelte` avec une application multilingue de **10 pages** et **10 langues**.
 
@@ -152,7 +155,7 @@ Les étoiles GitHub sont un indicateur fort de la popularité d'un projet, de la
 
 ### 2 - Solutions acceptables
 
-**(Paraglide)** (`@inlang/paraglide-js@2.17.0`) :
+**(Paraglide)** (`@inlang/paraglide-js@2.25.1`) :
 
 `Paraglide` propose une approche innovante et bien pensée. Dans le contexte d'une application Vite + Svelte, le tree-shaking dont leur entreprise fait la publicité fonctionne comme prévu, ce qui est excellent.
 Mais dans le cas de React + TanStack Start, le tree-shaking n'a pas fonctionné comme prévu, de même pour Next.js. Cela dit, l'usage de Paraglide dans un projet Svelte et TanStack Start mériterait d'être vérifié de près.
@@ -162,13 +165,13 @@ Enfin, par rapport à d'autres solutions, Paraglide n'utilise pas de store (ex:
 
 > Note sur paraglide : cette solution injecte du code dans votre base de code pour les imports, par conséquent, la métrique 'lib size' dans le rapport de benchmark est presque de 0. La génération de code est une bonne chose, car la fonction utilisée n'inclura que la logique nécessaire (préfixe partout vs pas de préfixe, cookie vs stockage, etc.). En comparaison, Intlayer effectue ce filtrage via des injections de variables d'environnement pendant le build pour forcer le bundler à tree-shaker le contenu en fonction de la logique. Grâce à cela, paraglide et intlayer finissent par être des solutions 6 à 10 fois plus légères qu'i18next ou next-intl.
 
-**(svelte-i18n)** (`svelte-i18n@3.4.0`) :
+**(svelte-i18n)** (`svelte-i18n@4.0.1`) :
 
-Cette solution répond à tous les besoins i18n dans un projet Svelte. Mais comme c'est le cas pour i18next ou d'autres solutions majeures, elle est un peu lourde (~15.9 Ko, soit environ 7× `svelte-intlayer`).
+Cette solution répond à tous les besoins i18n dans un projet Svelte. Mais comme c'est le cas pour i18next ou d'autres solutions majeures, elle est un peu lourde (~16.6 Ko, soit environ 4.5× `svelte-intlayer`).
 
 ### 3 - Recommandations
 
-**(Intlayer)** (`svelte-intlayer@8.7.12`) :
+**(Intlayer)** (`svelte-intlayer@9.5.0`) :
 
 Je ne jugerai pas personnellement `svelte-intlayer` par souci d'objectivité, puisqu'il s'agit de ma propre solution.
 

package/docs/fr/benchmark/tanstack.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: La meilleure solution i18n pour TanStack Start en 2026 - Rapport de Benchmark
 description: Comparez les bibliothèques d'internationalisation pour TanStack Start comme react-i18next, next-intl et Intlayer. Rapport de performance détaillé sur la taille du bundle, les fuites et la réactivité.
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-tanstack-start-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "Mise à jour des résultats du benchmark"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Ajout du comparatif des étoiles GitHub"
@@ -62,7 +65,7 @@ L'autre impact concerne l'expérience développeur (DX) : la façon dont vous d
 
 ## TL;DR
 
-- **Intlayer** : Fournit la meilleure performance et la plus petite taille de bundle (v8.7.12) pour TanStack Start.
+- **Intlayer** : Fournit la meilleure performance et la plus petite taille de bundle (v9.5.1) pour TanStack Start.
 - **react-i18next** & **next-intl** : Alternatives matures avec de grands écosystèmes, mais nettement plus lourdes et complexes à optimiser.
 - **Paraglide** : Idée innovante de tree-shaking qui ne fonctionne pas en pratique. DX complexe et surcoût de réactivité dans TanStack Start.
 - **À éviter** : **General Translation (GT)** et **Lingo.dev** en raison de graves problèmes de performance, des limites de quota AI et du verrouillage propriétaire (vendor lock-in).
@@ -97,16 +100,18 @@ Les syntaxes basées sur `const t = useTranslation()` + `t('a.b.c')` sont très
 Pour ce benchmark, nous avons comparé les bibliothèques suivantes :
 
 - `Base App` (Pas de bibliothèque i18n)
-- `react-intlayer` (v8.7.12)
-- `react-i18next` (v17.0.2)
-- `next-intl` (v4.9.1)
-- `@lingui/core` (v5.3.0)
+- `react-intlayer` (v9.5.1)
+- `@intlayer/use-intl` (v9.5.1)
+- [`@intlayer/lingui`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/compat/lingui.md) (v9.5.1)
+- `react-i18next` (v17.0.13)
+- `next-intl` (v4.14.2)
+- `@lingui/core` (v6.6.0)
 - `@inlang/paraglide-js` (v2.15.1)
-- `@tolgee/react` (v7.0.0)
-- `react-intl` (v10.1.1)
-- `wuchale` (v0.22.11)
-- `gt-react` (vlatest)
-- `lingo.dev` (v0.133.9)
+- `@tolgee/react` (v7.2.0)
+- `react-intl` (v10.1.26)
+- `wuchale` (v0.26.6)
+- `gt-react` (v10.18.3)
+- `lingo.dev` (v0.138.7)
 
 Le framework utilisé est `TanStack Start` avec une application multilingue de **10 pages** et **10 langues**.
 
@@ -160,15 +165,15 @@ Certaines solutions, telles que `gt-react` ou `lingo.dev`, sont clairement à fu
 
 Problèmes rencontrés :
 
-**(General Translation)** (`gt-react@latest`) :
+**(General Translation)** (`gt-react@10.18.3`) :
 
-- Pour une application d'environ 110 Ko, `gt-react` peut ajouter plus de 440 Ko supplémentaires (ordre de grandeur observé sur l'implémentation Next.js du même benchmark).
+- Pour une application d'environ 111 Ko, `gt-react` peut ajouter plus de 170 Ko supplémentaires (ordre de grandeur observé sur l'implémentation Next.js du même benchmark).
 - `Quota Exceeded, please upgrade your plan` dès le tout premier build avec General Translation.
 - Les traductions ne sont pas rendues ; j'obtiens l'erreur `Error: <T> used on the client-side outside of <GTProvider>`, ce qui semble être un bug de la bibliothèque.
 - Lors de l'implémentation de **gt-tanstack-start-react**, je suis également tombé sur un [problème](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) avec la bibliothèque : `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`, ce qui cassait l'application. Après avoir signalé ce problème, le mainteneur l'a corrigé sous 24 heures.
 - Ces bibliothèques utilisent un anti-pattern via la fonction `initializeGT()`, empêchant le bundle d'être tree-shaké proprement.
 
-**(Lingo.dev)** (`lingo.dev@0.133.9`) :
+**(Lingo.dev)** (`lingo.dev@0.138.7`) :
 
 - Quota AI dépassé (ou dépendance serveur bloquante), rendant le build / la production risqués sans payer.
 - Le compilateur ratait presque 40 % du contenu traduit. J'ai dû réécrire tous les `.map` en blocs de composants plats pour que cela fonctionne.
@@ -178,7 +183,7 @@ Problèmes rencontrés :
 
 ### 2 - Solutions expérimentales
 
-**(Wuchale)** (`wuchale@0.22.11`) :
+**(Wuchale)** (`wuchale@0.26.6`) :
 
 L'idée derrière `Wuchale` est intéressante mais ce n'est pas encore une solution viable. J'ai rencontré des problèmes de réactivité avec la bibliothèque et j'ai dû forcer le re-rendu du provider pour faire fonctionner l'application sur TanStack Start. La documentation est également assez floue, ce qui rend l'adoption difficile.
 
@@ -188,9 +193,9 @@ L'idée derrière `Wuchale` est intéressante mais ce n'est pas encore une solut
 
 `Paraglide` propose une approche innovante et bien pensée. Pourtant, dans ce benchmark, le tree-shaking dont leur entreprise fait la publicité n'a pas fonctionné pour mon implémentation Next.js ou pour TanStack Start. Le workflow et la DX sont également plus complexes d'autres options. Personnellement, je ne suis pas fan de devoir régénérer des fichiers JS avant chaque push, ce qui crée un risque constant de conflit de fusion pour les développeurs via les PRs.
 
-> Note sur paraglide : cette solution injecte du code dans votre base de code pour les imports, par conséquent, la métrique 'lib size' dans le rapport de benchmark est presque de 0. La génération de code est une bonne chose, car la fonction utilisée n'inclura que la logique nécessaire (préfixe partout vs pas de préfixe, cookie vs stockage, etc.). En comparaison, Intlayer effectue ce filtrage via des injections de variables d'environnement dans le build pour forcer le bundler à tree-shaker le contenu en fonction de la logique. Grâce à cela, paraglide et intlayer finissent par être des solutions 6 à 10 fois plus légères qu'i18next ou next-intl.
+> Note sur paraglide : cette solution injecte du code dans votre base de code pour les imports, par conséquent, la métrique 'lib size' dans le rapport de benchmark est presque de 0. La génération de code est une bonne chose, car la fonction utilisée n'inclura que la logique nécessaire (préfixe partout vs pas de préfixe, cookie vs stockage, etc.). En comparaison, Intlayer effectue ce filtrage via des injections de variables d'environnement dans le build pour forcer le bundler à tree-shaker le contenu en fonction de la logique. Grâce à cela, paraglide et intlayer finissent par être des solutions 3 à 10 fois plus légères qu'i18next ou next-intl.
 
-**(Tolgee)** (`@tolgee/react@7.0.0`) :
+**(Tolgee)** (`@tolgee/react@7.2.0`) :
 
 `Tolgee` traite bon nombre des problèmes mentionnés plus haut. Je l'ai trouvé plus difficile à prendre en main que d'autres outils aux approches similaires. Il n'offre pas de sécurité de type, ce qui rend également beaucoup plus difficile la détection des clés manquantes à la compilation. J'ai dû wrapper les APIs de Tolgee avec les miennes pour ajouter la détection des clés manquantes.
 
@@ -198,37 +203,37 @@ Le package est assez lourd (~11.1kb, ce qui est plus de 2× `react-intlayer`).
 
 Sur TanStack Start, j'ai également eu des problèmes de réactivité : au changement de locale, je devais forcer le provider à se re-rendre et souscrire aux événements de changement de locale pour que le chargement dans une autre langue se comporte correctement.
 
-**(next-intl)** (`next-intl@4.9.1`) :
+**(next-intl)** (`next-intl@4.14.2`) :
 
 `next-intl` est la pièce "intl" la plus à la mode dans l'écosystème React (même famille que `next-intl`) et est souvent poussée par les agents IA, mais à mon avis à tort dans un contexte privilégiant la performance. La mise en route est assez simple. En pratique, le processus pour optimiser et limiter les fuites est assez complexe. De même, combiner chargement dynamique + namespacing + types TypeScript ralentit beaucoup le développement.
 
 Sur TanStack Start, vous évitez les pièges spécifiques à Next.js (`setRequestLocale`, rendu statique), mais le problème de fond est le même : sans une discipline stricte, le bundle transporte rapidement trop de messages et la maintenance des namespaces par route devient pénible.
 
-**(react-i18next)** (`react-i18next@17.0.2`) :
+**(react-i18next)** (`react-i18next@17.0.13`) :
 
 `react-i18next` est probablement l'option la plus populaire car elle fut l'une des premières à servir les besoins i18n des applications JS. Elle dispose également d'un large éventail de plugins communautaires pour des problèmes spécifiques.
 
 Pourtant, elle partage les mêmes inconvénients majeurs que les stacks basées sur `t('a.b.c')` : les optimisations sont possibles mais très gourmandes en temps, et les gros projets risquent de mauvaises pratiques (namespaces + chargement dynamique + types).
 
-Le package est particulièrement lourd (~17.3kb, ce qui représente environ 3.5× `react-intlayer`).
+Le package est particulièrement lourd (~18.4kb, ce qui représente environ 3.5× `react-intlayer`).
 
 Les formats de messages divergent également : `next-intl` utilise ICU MessageFormat, tandis qu'i18next utilise son propre format - ce qui complique l'outillage ou les migrations si vous les mélangez.
 
-**(Lingui)** (`@lingui/core@5.3.0`) :
+**(Lingui)** (`@lingui/core@6.6.0`) :
 
 `Lingui` est souvent loué. Personnellement, j'ai trouvé le workflow autour de `lingui extract` / `lingui compile` plus complexe que d'autres approches, sans avantage clair dans ce benchmark TanStack Start. J'ai également remarqué des syntaxes inconsistantes qui perturbent les IAs (ex: `t()`, `t''`, `i18n.t()`, `<Trans>`).
 
-**(react-intl)** (`react-intl@10.1.1`) :
+**(react-intl)** (`react-intl@10.1.26`) :
 
 `react-intl` est une implémentation performante de l'équipe Format.js. La DX reste verbeuse : `const intl = useIntl()` + `intl.formatMessage({ id: "xx.xx" })` ajoute de la complexité, du travail JavaScript supplémentaire et lie l'instance globale i18n à de nombreux nœuds dans l'arbre React.
 
-Le package est également volumineux (~14.4kb, soit environ 3× `react-intlayer`).
+Le package est également volumineux (~15.3kb, soit environ 3× `react-intlayer`).
 
 ### 4 - Recommandations
 
 Ce benchmark TanStack Start n'a pas d'équivalent direct à `next-translate` (plugin Next.js + `getStaticProps`). Pour les équipes qui veulent vraiment une API `t()` avec un écosystème mature, `react-i18next` et `next-intl` restent des choix "raisonnables", mais attendez-vous à investir beaucoup de temps dans l'optimisation pour éviter les fuites.
 
-**(Intlayer)** (`react-intlayer@8.7.12`) :
+**(Intlayer)** (`react-intlayer@9.5.1`) :
 
 Je ne jugerai pas personnellement `react-intlayer` par souci d'objectivité, puisqu'il s'agit de ma propre solution.
 

package/docs/fr/benchmark/vue.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: La meilleure solution i18n pour Vue en 2026 - Rapport de Benchmark
 description: Comparez les bibliothèques d'internationalisation (i18n) pour Vue comme vue-i18n, fluent-vue et Intlayer. Rapport de performance détaillé sur la taille du bundle, les fuites et la réactivité.
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "Mise à jour des résultats du benchmark"
   - version: 8.9.8
     date: 2026-05-18
     changes: "Ajout du comparatif des étoiles GitHub"
@@ -62,7 +65,7 @@ L'autre impact concerne l'expérience développeur (DX) : la façon dont vous d
 
 ## TL;DR
 
-- **Intlayer** : La solution la plus légère (v8.7.12) avec découpage (scoping) et chargement dynamique natifs.
+- **Intlayer** : La solution la plus légère (v9.5.0) avec découpage (scoping) et chargement dynamique natifs.
 - **vue-i18n** : Le standard de l'industrie avec un riche écosystème, mais peut être nettement plus lourd et difficile à optimiser pour le code-splitting dans les grandes applications.
 - **fluent-vue** : Organisation innovante des messages mais manque de sécurité de type et s'avère extrêmement lourd.
 
@@ -96,7 +99,8 @@ Les syntaxes basées sur `const { t } = useI18n()` + `t('a.b.c')` sont très pra
 Pour ce benchmark, nous avons comparé les bibliothèques suivantes :
 
 - `Base App` (Pas de bibliothèque i18n)
-- `vue-intlayer` (v8.7.12)
+- `vue-intlayer` (v9.5.0)
+- [`@intlayer/vue-i18n`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/compat/vue-i18n.md) (v9.5.1)
 - `vue-i18n` (v11.4.0)
 - `fluent-vue` (v3.8.2)
 
@@ -156,14 +160,14 @@ Les étoiles GitHub sont un indicateur fort de la popularité d'un projet, de la
 
 - **vue-i18n** est sans conteste la bibliothèque i18n la plus utilisée pour Vue, elle possède énormément de fonctionnalités et un immense écosystème. Mais sous le capot, la solution est assez lourde. Même si vue-i18n intègre le lazy loading des messages, il lui manque une fonctionnalité de découpage (scoping). Dans le cas d'une application Vue SPA classique, cela ne pose pas de problème, mais pour une application Nuxt utilisant @nuxt/i18n, cela conduit à inclure les messages de toutes les pages dans une seule. Pour une grosse application Nuxt de plus de 10 pages, cela peut devenir vraiment problématique.
 
-Le paquet est très lourd (~24.3 Ko, soit environ 9× `vue-intlayer`).
+Le paquet est très lourd (~24.3 Ko, soit environ 6× `vue-intlayer`).
 
-**(fluent-vue)** (`fluent-vue@0.5.0`) :
+**(fluent-vue)** (`fluent-vue@3.8.2`) :
 
-- **fluent-vue** propose une tentative d'innovation via le format .ftl. L'organisation des messages est excellente, plus facile pour débuter. Mais en pratique, le manque de sécurité de type augmente le risque d'erreur et peut vite devenir chronophage à déboguer. De plus, cette solution charge les messages via un plugin vite qui force le chargement de tout le contenu dans toutes les langues dans chaque page. Enfin, c'est une solution extrêmement lourde (~92.7 Ko, soit environ 34× `vue-intlayer`).
+- **fluent-vue** propose une tentative d'innovation via le format .ftl. L'organisation des messages est excellente, plus facile pour débuter. Mais en pratique, le manque de sécurité de type augmente le risque d'erreur et peut vite devenir chronophage à déboguer. De plus, cette solution charge les messages via un plugin vite qui force le chargement de tout le contenu dans toutes les langues dans chaque page. Enfin, c'est une solution extrêmement lourde (~29.7 Ko, soit environ 7.5× `vue-intlayer`).
 
 ### 3 - Recommandations
 
-**(Intlayer)** (`vue-intlayer@8.7.12`) :
+**(Intlayer)** (`vue-intlayer@9.5.0`) :
 
 Je ne jugerai pas personnellement `vue-intlayer` par souci d'objectivité, puisqu'il s'agit de ma propre solution.

package/docs/fr/cli/build.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: Construire des Dictionnaires
 description: Apprenez à construire vos dictionnaires Intlayer à partir des fichiers de déclaration de contenu.
 keywords:
@@ -14,6 +14,9 @@ slugs:
   - cli
   - build
 history:
+  - version: 9.5.2
+    date: 2026-09-12
+    changes: "Ajout du drapeau `--ci`"
   - version: 8.1.5
     date: 2026-02-23
     changes: "Ajouter l'option checkTypes"
@@ -92,6 +95,10 @@ Cette commande trouvera par défaut vos fichiers de déclaration de contenu sous
 
   > Exemple : `npx intlayer build --no-cache`
 
+- **`--ci`** : Exécute la commande dans chaque projet Intlayer du monorepo (ou uniquement le projet courant si lancée depuis son répertoire). Des identifiants par projet peuvent être injectés via `INTLAYER_PROJECT_CREDENTIALS`, un objet JSON associant chaque chemin de projet à `{ "clientId", "clientSecret" }`.
+
+  > Exemple : `npx intlayer build --ci`
+
 - **`--check-types`**: Vérifie les types des fichiers de déclaration de contenu.
 
   > Exemple : `npx intlayer build --check-types`

package/docs/fr/cli/configuration.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: Gérer la Configuration
 description: Apprenez à récupérer et pousser votre configuration Intlayer vers le CMS.
 keywords:
@@ -51,6 +51,7 @@ bun x intlayer configuration get
 - **`--base-dir`** : Spécifie le répertoire de base pour le projet.
 - **`--verbose`** : Active la journalisation détaillée pour le débogage. (par défaut à true via la CLI)
 - **`--no-cache`** : Désactive le cache.
+- **`--ci`** : Exécute la commande dans chaque projet Intlayer du monorepo (ou uniquement le projet courant si lancée depuis son répertoire). Des identifiants par projet peuvent être injectés via `INTLAYER_PROJECT_CREDENTIALS`, un objet JSON associant chaque chemin de projet à `{ "clientId", "clientSecret" }`.
 
 ## Pousser la Configuration
 
@@ -84,5 +85,6 @@ bun x intlayer configuration push
 - **`--base-dir`** : Spécifie le répertoire de base pour le projet.
 - **`--verbose`** : Active la journalisation détaillée pour le débogage. (par défaut à true via la CLI)
 - **`--no-cache`** : Désactive le cache.
+- **`--ci`** : Exécute la commande dans chaque projet Intlayer du monorepo (ou uniquement le projet courant si lancée depuis son répertoire). Des identifiants par projet peuvent être injectés via `INTLAYER_PROJECT_CREDENTIALS`, un objet JSON associant chaque chemin de projet à `{ "clientId", "clientSecret" }`.
 
 En poussant la configuration, votre projet est entièrement intégré au CMS Intlayer, permettant une gestion fluide des dictionnaires entre les équipes.

package/docs/fr/cli/doc-review.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2026-06-17
+updatedAt: 2026-09-12
 title: Revue de Document
 description: Apprenez comment revoir les fichiers de documentation pour la qualité, la cohérence et l'exhaustivité à travers différentes locales.
 keywords:
@@ -16,6 +16,9 @@ slugs:
   - cli
   - doc-review
 history:
+  - version: 9.5.2
+    date: 2026-09-12
+    changes: "Ajout du drapeau `--ci`"
   - version: 9.0.0
     date: 2026-06-17
     changes: "Ajout de l'option --log"
@@ -136,6 +139,10 @@ Quel que soit le mode, l'exécution se termine par une synthèse listant les doc
 
   > Exemple : `npx intlayer doc review --base-dir ./docs --env-file .env.production.local`
 
+- **`--ci`** : Exécute la commande dans chaque projet Intlayer du monorepo (ou uniquement le projet courant si lancée depuis son répertoire). Des identifiants par projet peuvent être injectés via `INTLAYER_PROJECT_CREDENTIALS`, un objet JSON associant chaque chemin de projet à `{ "clientId", "clientSecret" }`.
+
+  > Exemple : `npx intlayer doc review --ci`
+
 **Options de journalisation :**
 
 - **`--verbose`** : Active la journalisation détaillée pour le débogage. (par défaut à true en utilisant la CLI)

package/docs/fr/cli/doc-translate.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: Traduire un document
 description: Apprenez à traduire automatiquement des fichiers de documentation en utilisant des services de traduction IA.
 keywords:
@@ -113,6 +113,10 @@ bun x intlayer doc translate
 
   > Exemple : `npx intlayer doc translate --base-dir ./docs --env-file .env.production.local`
 
+- **`--ci`** : Exécute la commande dans chaque projet Intlayer du monorepo (ou uniquement le projet courant si lancée depuis son répertoire). Des identifiants par projet peuvent être injectés via `INTLAYER_PROJECT_CREDENTIALS`, un objet JSON associant chaque chemin de projet à `{ "clientId", "clientSecret" }`.
+
+  > Exemple : `npx intlayer doc translate --ci`
+
 **Options de journalisation :**
 
 - **`--verbose`** : Active la journalisation détaillée pour le débogage. (par défaut à true en utilisant la CLI)

package/docs/fr/cli/extract.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: Extraire des chaînes
 description: Apprenez comment extraire des chaînes depuis vos composants dans un fichier .content proche du composant.
 keywords:
@@ -69,6 +69,7 @@ Cette commande analyse vos fichiers de code pour extraire les chaînes des compo
 - **`--env`**: Spécifie l'environnement.
 - **`--env-file`**: Fournit un fichier d'environnement personnalisé.
 - **`--verbose`**: Active la journalisation détaillée.
+- **`--ci`**: Exécute la commande dans chaque projet Intlayer du monorepo (ou uniquement le projet courant si lancée depuis son répertoire). Des identifiants par projet peuvent être injectés via `INTLAYER_PROJECT_CREDENTIALS`, un objet JSON associant chaque chemin de projet à `{ "clientId", "clientSecret" }`.
 
 **Plugins requis :**
 

package/docs/fr/cli/fill.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: Remplir les dictionnaires
 description: Apprenez à remplir, auditer et traduire vos dictionnaires en utilisant l'IA.
 keywords:
@@ -162,6 +162,10 @@ Affected dictionary keys for processing: app, comp-test, hello-world, lang-switc
 
   > Exemple : `npx intlayer build --no-cache`
 
+- **`--ci`** : Exécute la commande dans chaque projet Intlayer du monorepo (ou uniquement le projet courant si lancée depuis son répertoire). Des identifiants par projet peuvent être injectés via `INTLAYER_PROJECT_CREDENTIALS`, un objet JSON associant chaque chemin de projet à `{ "clientId", "clientSecret" }`.
+
+  > Exemple : `npx intlayer fill --ci`
+
 **Options de préparation :**
 
 - **`--build`** : Construire les dictionnaires avant de pousser pour s’assurer que le contenu est à jour. True forcera la construction, false sautera la construction, undefined permettra d’utiliser le cache de la construction.