[Doc FR]: Global typo fixes and usage of 1990 rules for french graphie (#974)

* Review FR with officials terms

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>

* Update `NPM` to `npm`

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>

* la devient le (@flyusfly)

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>

* New core-concepts.md file

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>

* Update book.json using a copy/past from en version

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>

* Remove book.json

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>

* Add book.json

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>

* Add `createNamespacedHelpers` french translation

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>

* Change http link to https

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>

* September updates

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>

* Fix small errors

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>

* Review de @rspt

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>

docs/fr/actions.md

@@ -27,7 +27,7 @@ const store = new Vuex.Store({
 
 Les gestionnaires d'action reçoivent un objet contexte qui expose le même ensemble de méthodes et propriétés que l'instance du store, donc vous pouvez appeler `context.commit` pour acter une mutation, ou accéder à l'état et aux accesseurs via `context.state` et `context.getters`. Nous verrons pourquoi cet objet contexte n'est pas l'instance du store elle-même lorsque nous présenterons les [Modules](modules.md) plus tard.
 
-En pratique, nous utilisons souvent la [destructuration d'argument](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Op%C3%A9rateurs/Affecter_par_d%C3%A9composition) pour simplifier quelque peu le code (particulièrement si nous avons besoin d'appeler `commit` plusieurs fois) :
+En pratique, nous utilisons souvent la [déstructuration d'argument](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Op%C3%A9rateurs/Affecter_par_d%C3%A9composition) pour simplifier quelque peu le code (particulièrement si nous avons besoin d'appeler `commit` plusieurs fois) :
 
 ``` js
 actions: {
@@ -175,4 +175,4 @@ actions: {
 }
 ```
 
-> Il est possible pour un `store.dispatch` de déclencher plusieurs gestionnaires d'action dans différents modules. Dans ce genre de cas, la valeur retournée sera une Promesse qui se résoud quand tous les gestionnaires déclenchés ont été résolus.
+> Il est possible pour un `store.dispatch` de déclencher plusieurs gestionnaires d'action dans différents modules. Dans ce genre de cas, la valeur retournée sera une Promesse qui se résout quand tous les gestionnaires déclenchés ont été résolus.

docs/fr/api.md

@@ -52,7 +52,7 @@ const store = new Vuex.Store({ ...options })
 
     ```
     state,    // sera l'état local du module si défini dans un module.
-    getters   // indentique à `store.getters`
+    getters   // identique à `store.getters`
     ```
 
     Arguments spécifiques quand défini dans un module
@@ -88,7 +88,7 @@ const store = new Vuex.Store({ ...options })
     }
     ```
 
-    Chaque module peut contenir `state` et `mutations`, tout comme les options racine. L'état d'un module sera attaché à l'état racine du store en utilisant la clé du module. Les mutations et accesseurs d'un module recevront seulement l'état local du module en premier argument au lieu de l'état racine, et le `context.state` des actions du module pointeront également vers l'état local.
+    Chaque module peut contenir `state` et `mutations`, tout comme les options racines. L'état d'un module sera attaché à l'état racine du store en utilisant la clé du module. Les mutations et accesseurs d'un module recevront seulement l'état local du module en premier argument au lieu de l'état racine, et le `context.state` des actions du module pointeront également vers l'état local.
 
     [Plus de détails](modules.md)
 
@@ -96,7 +96,7 @@ const store = new Vuex.Store({ ...options })
 
   - type : `Array<Function>`
 
-    Un tableau de fonctions plugins qui seront appliquées au store. Un plugin reçoit simplement le store comme seul argument et peut soit écouter les mutations (pour la persistence de données, les logs ou le débogage) ou propager des mutations (pour les données internes, c.-à-d. websockets ou observables).
+    Un tableau de fonctions plugins qui seront appliquées au store. Un plugin reçoit simplement le store comme seul argument et peut soit écouter les mutations (pour la persistance de données, les logs ou le débogage) ou propager des mutations (pour les données internes, c.-à-d. websockets ou observables).
 
     [Plus de détails](plugins.md)
 
@@ -145,7 +145,7 @@ const store = new Vuex.Store({ ...options })
 
 - **`subscribe(handler: Function)`**
 
-  S'abonner aux mutations du store. Le `handler` est appelé après chaque mutation et reçoit le descripteur de mutation et l'état post-mutation comme arguments :
+  S'abonner aux mutations du store. Le `handler` est appelé après chaque mutation et reçoit le descripteur de mutation et l'état post mutation comme arguments :
 
   ``` js
   store.subscribe((mutation, state) => {
@@ -172,27 +172,27 @@ const store = new Vuex.Store({ ...options })
 
 - **`mapState(namespace?: string, map: Array<string> | Object): Object`**
 
-  Créer des propriétés calculées qui retournent le sous arbre du store Vuex au composant. [Plus de détails](state.md#le-helper-mapstate)
+  Créer des propriétés calculées qui retournent le sous-arbre du store Vuex au composant. [Plus de détails](state.md#le-helper-mapstate)
 
-  Le premier argument peut être de façon optionnel une chaîne d'espace de nom. [Plus de détails](modules.md#Fonctions-utilitaires-liées-avec-espace-de-nom)
+  Le premier argument peut être de façon optionnelle une chaine d'espace de nom. [Plus de détails](modules.md#Fonctions-utilitaires-liées-avec-espace-de-nom)
 
 - **`mapGetters(namespace?: string, map: Array<string> | Object): Object`**
 
   Créer des propriétés calculées qui retournent la valeur calculée d'un accesseur. [Plus de détails](getters.md#la-function-utilitaire-mapgetters)
 
-  Le premier argument peut être de façon optionnel une chaîne d'espace de nom. [Plus de détails](modules.md#Fonctions-utilitaires-liées-avec-espace-de-nom)
+  Le premier argument peut être de façon optionnelle une chaine d'espace de nom. [Plus de détails](modules.md#Fonctions-utilitaires-liées-avec-espace-de-nom)
 
 - **`mapActions(namespace?: string, map: Array<string> | Object): Object`**
 
   Créer des méthodes de composant qui propagent une action. [Plus de détails](actions.md#propager-des-actions-dans-les-composants)
 
-  Le premier argument peut être de façon optionnel une chaîne d'espace de nom. [Plus de détails](modules.md#Fonctions-utilitaires-liées-avec-espace-de-nom)
+  Le premier argument peut être de façon optionnelle une chaine d'espace de nom. [Plus de détails](modules.md#Fonctions-utilitaires-liées-avec-espace-de-nom)
 
 - **`mapMutations(namespace?: string, map: Array<string> | Object): Object`**
 
   Créer des méthodes de composant qui actent une mutation. [Plus de détails](mutations.md#acter-des-mutations-dans-les-composants)
 
-  Le premier argument peut être de façon optionnel une chaîne d'espace de nom. [Plus de détails](modules.md#Fonctions-utilitaires-liées-avec-espace-de-nom)
+  Le premier argument peut être de façon optionnelle une chaine d'espace de nom. [Plus de détails](modules.md#Fonctions-utilitaires-liées-avec-espace-de-nom)
 
 - **`createNamespacedHelpers(namespace: string): Object`**
 

docs/fr/getters.md

@@ -12,7 +12,7 @@ computed: {
 
 Si plus d'un composant a besoin d'utiliser cela, il nous faut ou bien dupliquer cette fonction, ou bien l'extraire dans une fonction utilitaire séparée et l'importer aux endroits nécessaires. Les deux idées sont loin d'être idéales.
 
-Vuex nous permet de définir des accesseurs (« getters ») dans le store. Voyez-les comme les propriétés calculées des stores. Comme pour les propriétés calculées, le résultat de l'accesseur est mis en cache en se basant sur ses dépendances et il ne sera ré-évalué quand l'une de ses dépendances aura changé.
+Vuex nous permet de définir des accesseurs (« getters ») dans le store. Voyez-les comme les propriétés calculées des stores. Comme pour les propriétés calculées, le résultat de l'accesseur est mis en cache en se basant sur ses dépendances et il ne sera réévalué quand l'une de ses dépendances aura changé.
 
 Les accesseurs prennent l'état en premier argument :
 

docs/fr/intro.md

@@ -27,13 +27,13 @@ new Vue({
 })
 ```
 
-C'est une application auto-suffisante avec les parties suivantes :
+C'est une application autosuffisante avec les parties suivantes :
 
 - L'**état**, qui est la source de vérité qui pilotant votre application,
 - La **vue**, qui est une réflexion déclarative de l'**état**,
 - Les **actions**, qui sont les façons possibles pour l'état de changer en réaction aux actions utilisateurs depuis la **vue**.
 
-Voici une représentation extrèmement simple du concept de « flux de donnée unidirectionnel » :
+Voici une représentation extrêmement simple du concept de « flux de donnée unidirectionnel » :
 
 <p style="text-align: center; margin: 2em">
   <img style="width:100%;max-width:450px;" src="./images/flow.png">
@@ -56,8 +56,8 @@ Voilà l'idée de base derrière Vuex, inspiré par [Flux](https://facebook.gith
 
 ### Quand l'utiliser ?
 
-Bien que Vuex nous aide à gérer un état global partagé, il apporte aussi le coût de nouveaux concepts et _abstraction de code_ (« boilerplate »). C'est un compromis entre la productivité à court terme et à long terme.
+Bien que Vuex nous aide à gérer un état global partagé, il apporte aussi le cout de nouveaux concepts et _abstraction de code_ (« boilerplate »). C'est un compromis entre la productivité à court terme et à long terme.
 
-Si vous n'avez jamais créé une _application monopage_ à grande échelle et que vous sautez directement dans Vuex, cela peut paraître verbeux et intimidant. C'est parfaitement normal ; si votre application est simple, vous vous en sortirez sans doute très bien sans Vuex. Un simple [canal d'évènement global](https://fr.vuejs.org/v2/guide/components.html#Communication-non-parent-enfant) pourrait très bien vous suffire. Mais si vous devez créer une application monopage à moyenne ou grande échelle, il y a des chances que vous vous trouviez dans des situations qui vous feront vous interroger sur une meilleure gestion de l'état global, détaché de votre composant Vue, et Vuex sera naturellement la prochaine étape pour vous. Voici une bonne citation de Dan Abramov, l'auteur de Redux :
+Si vous n'avez jamais créé une _application monopage_ à grande échelle et que vous sautez directement dans Vuex, cela peut paraitre verbeux et intimidant. C'est parfaitement normal ; si votre application est simple, vous vous en sortirez sans doute très bien sans Vuex. Un simple [canal d'évènement global](https://fr.vuejs.org/v2/guide/components.html#Communication-non-parent-enfant) pourrait très bien vous suffire. Mais si vous devez créer une application monopage à moyenne ou grande échelle, il y a des chances que vous vous trouviez dans des situations qui vous feront vous interroger sur une meilleure gestion de l'état global, détaché de votre composant Vue, et Vuex sera naturellement la prochaine étape pour vous. Voici une bonne citation de Dan Abramov, l'auteur de Redux :
 
 > « Les librairies Flux, c'est comme les lunettes : vous saurez quand vous en aurez besoin. »

docs/fr/modules.md

@@ -2,7 +2,7 @@
 
 Du fait de l'utilisation d'un arbre d'état unique, tout l'état de notre application est contenu dans un seul et même gros objet. Cependant, au fur et à mesure que notre application grandit, le store peut devenir très engorgé.
 
-Pour y remédier, Vuex nous permet de diviser notre store en **modules**. Chaque module peut contenir ses propres état, mutations, actions, accesseurs. Il peut même contenir ses propres modules internes.
+Pour y remédier, Vuex nous permet de diviser notre store en **modules**. Chaque module peut contenir ses propres états, mutations, actions, accesseurs. Il peut même contenir ses propres modules internes.
 
 ``` js
 const moduleA = {
@@ -83,7 +83,7 @@ const moduleA = {
 
 Par défaut, les actions, mutations et accesseurs à l'intérieur d'un module sont toujours enregistrés sous l'**espace de nom global**. Cela permet à de multiples modules d'être réactifs au même type de mutation et d'action.
 
-Si vous souhaitez que votre module soit auto-suffisant et réutilisable, vous pouvez le ranger sous un espace de nom avec `namespaced: true`. Quand le module est enregistré, tous ses accesseurs, actions et mutations seront automatiquement basés sur l'espace de nom du module dans lesquels ils sont rangés. Par exemple :
+Si vous souhaitez que votre module soit autosuffisant et réutilisable, vous pouvez le ranger sous un espace de nom avec `namespaced: true`. Quand le module est enregistré, tous ses accesseurs, actions et mutations seront automatiquement basés sur l'espace de nom du module dans lesquels ils sont rangés. Par exemple :
 
 ```js
 const store = new Vuex.Store({
@@ -128,13 +128,13 @@ const store = new Vuex.Store({
 })
 ```
 
-Les accesseurs et actions sous espace de nom reçoivent des `getters`, `dispatch` et `commit` localisés. En d'autres termes, vous pouvez utiliser les paramètres de module sans écrire de prefix dans ce même module. Permuter entre un espace de nom ou non n'affecte pas le code à l'intérieur du module.
+Les accesseurs et actions sous espace de nom reçoivent des `getters`, `dispatch` et `commit` localisés. En d'autres termes, vous pouvez utiliser les paramètres de module sans écrire de préfixe dans ce même module. Permuter entre un espace de nom ou non n'affecte pas le code à l'intérieur du module.
 
 #### Accéder aux propriétés globales dans les modules à espace de nom
 
-Si vous voulez utiliser des états et accesseurs globaux, `rootState` et `rootGetters` sont passés en 3ième et 4ième arguments des fonctions d'accès et sont également exposés en tant que propriété de l'objet `context` passé aux fonctions d'action.
+Si vous voulez utiliser des états et accesseurs globaux, `rootState` et `rootGetters` sont passés en 3ᵉ et 4ᵉ arguments des fonctions d'accès et sont également exposés en tant que propriété de l'objet `context` passé aux fonctions d'action.
 
-Pour propager les actions ou les mutations actées dans l'espace de nom global, passez `{ root: true }` en 3ième argument à `dispatch` et `commit`.
+Pour propager les actions ou les mutations actées dans l'espace de nom global, passez `{ root: true }` en 3ᵉ argument à `dispatch` et `commit`.
 
 ``` js
 modules: {
@@ -143,7 +143,7 @@ modules: {
 
     getters: {
       // Les `getters` sont localisés dans le module des accesseurs
-      // vous pouvez utiliser `rootGetters` via le 4ième argument des accesseurs
+      // vous pouvez utiliser `rootGetters` via le 4ᵉ argument des accesseurs
       someGetter (state, getters, rootState, rootGetters) {
         getters.someOtherGetter // -> 'foo/someOtherGetter'
         rootGetters.someOtherGetter // -> 'someOtherGetter'
@@ -189,7 +189,7 @@ methods: {
 }
 ```
 
-Dans ces cas là, vous pouvez passer une chaîne de caractère représentant le nom d'espace en tant que premier argument aux fonctions utilitaires ainsi toutes les liaisons seront faites en utilisant le module comme contexte. Cela peut être simplifié comme ci-dessous :
+Dans ces cas-là, vous pouvez passer une chaine de caractère représentant le nom d'espace en tant que premier argument aux fonctions utilitaires ainsi toutes les liaisons seront faites en utilisant le module comme contexte. Cela peut être simplifié comme ci-dessous :
 
 ``` js
 computed: {
@@ -206,7 +206,7 @@ methods: {
 }
 ```
 
-De plus, vous pouvez créer des fonctions utilitaires liées avec espace de nom en utilisant `createNamespacedHelpers`. Cela retourne un objet qui a les nouvelles fonctions utilitaires ratachées à la valeur d'espace de nom fournie :
+De plus, vous pouvez créer des fonctions utilitaires liées avec espace de nom en utilisant `createNamespacedHelpers`. Cela retourne un objet qui a les nouvelles fonctions utilitaires rattachées à la valeur d'espace de nom fournie :
 
 ``` js
 import { createNamespacedHelpers } from 'vuex'
@@ -233,7 +233,7 @@ export default {
 
 #### Limitations pour les plugins des développeurs
 
-Vous devez faire attention au nom d'espace imprévisible pour vos modules quand vous créez un [plugin](plugins.md) qui fournit les modules et laisser les utilisateurs les ajouter au store de Vuex. Vos modules seront également sous espace de nom si l'utilisateur du plugin l'ajoute sous un module sous espace de nom. Pour vous adaptez à la situation, vous devez recevoir la valeur de l'espace de nom via vos options de plugin :
+Vous devez faire attention au nom d'espace imprévisible pour vos modules quand vous créez un [plugin](plugins.md) qui fournit les modules et laisser les utilisateurs les ajouter au store de Vuex. Vos modules seront également sous espace de nom si l'utilisateur du plugin l'ajoute sous un module sous espace de nom. Pour vous adapter à la situation, vous devez recevoir la valeur de l'espace de nom via vos options de plugin :
 
 ```js
 // passer la valeur d'espace de nom via une option du plugin
@@ -269,7 +269,7 @@ L'enregistrement dynamique de module permet aux autres plugins Vue de bénéfici
 
 Vous pouvez aussi supprimer un module enregistré dynamiquement avec `store.unregisterModule(moduleName)`. Notez que vous ne pouvez pas supprimer des modules statiques (déclarés à la création du store) avec cette méthode.
 
-### Ré-utiliser un module
+### Réutiliser un module
 
 Parfois nous devrons créer de multiples instances d'un module pour, par exemple :
 
@@ -289,4 +289,4 @@ const MyReusableModule = {
   },
   // mutations, actions, accesseurs...
 }
-```
+```

docs/fr/mutations.md

@@ -1,6 +1,6 @@
 # Mutations
 
-La seule façon de vraiment modifier l'état dans un store Vuex est d'acter une mutation. Les mutations Vuex sont très similaires aux évènements : chaque mutation a un **type** sous forme de chaîne de caractères et un **gestionnaire**. La fonction de gestion est en charge de procéder aux véritables modifications de l'état, et elle reçoit l'état en premier argument :
+La seule façon de vraiment modifier l'état dans un store Vuex est d'acter une mutation. Les mutations Vuex sont très similaires aux évènements : chaque mutation a un **type** sous forme de chaine de caractères et un **gestionnaire**. La fonction de gestion est en charge de procéder aux véritables modifications de l'état, et elle reçoit l'état en premier argument :
 
 ``` js
 const store = new Vuex.Store({
@@ -134,7 +134,7 @@ mutations: {
 }
 ```
 
-Maintenant imaginons que nous deboguons l'application et que nous regardons dans les logs de mutation des outils de développement (« devtools »). Pour chaque mutation enregistrée, le devtool aura besoin de capturer un instantané de l'état « avant » et un instantané « après ». Cependant, la fonction de rappel asynchrone de l'exemple ci-dessus rend l'opération impossible : la fonction de rappel n'est pas encore appelée lorsque la mutation est actée, et il n'y a aucun moyen pour le devtool de savoir quand la fonction de rappel sera véritablement appelée. Toute mutation d'état effectuée dans la fonction de rappel est essentiellement intraçable !
+Maintenant imaginons que nous déboguons l'application et que nous regardons dans les logs de mutation des outils de développement (« devtools »). Pour chaque mutation enregistrée, le devtool aura besoin de capturer un instantané de l'état « avant » et un instantané « après ». Cependant, la fonction de rappel asynchrone de l'exemple ci-dessus rend l'opération impossible : la fonction de rappel n'est pas encore appelée lorsque la mutation est actée, et il n'y a aucun moyen pour le devtool de savoir quand la fonction de rappel sera véritablement appelée. Toute mutation d'état effectuée dans la fonction de rappel est essentiellement intraçable !
 
 ### Acter des mutations dans les composants
 

docs/fr/plugins.md

@@ -7,7 +7,7 @@ const myPlugin = store => {
   // appelé quand le store est initialisé
   store.subscribe((mutation, state) => {
     // appelé après chaque mutation.
-    // Les mutation arrivent au format `{ type, payload }`.
+    // Les mutations arrivent au format `{ type, payload }`.
   })
 }
 ```
@@ -54,7 +54,7 @@ const store = new Vuex.Store({
 
 ### Prendre des instantanés de l'état
 
-Parfois un plugin peut vouloir recevoir des « instantanés » de l'état, et également comparer l'état post-mutation avec l'état pré-mutation. Pour faire ceci, vous aurez besoin d'effectuer une copie complète de l'état :
+Parfois un plugin peut vouloir recevoir des « instantanés » de l'état, et également comparer l'état post mutation avec l'état prémutation. Pour faire ceci, vous aurez besoin d'effectuer une copie complète de l'état :
 
 ``` js
 const myPluginWithSnapshot = store => {

docs/fr/state.md

@@ -22,11 +22,11 @@ const Counter = {
 }
 ```
 
-Lorsque `store.state.count` change, cela entraînera la ré-évaluation de la propriété calculée, et déclenchera les actions associées au DOM.
+Lorsque `store.state.count` change, cela entrainera la réévaluation de la propriété calculée, et déclenchera les actions associées au DOM.
 
 Cependant, ce modèle oblige le composant à compter sur le singleton global du store. Lorsqu'on utilise un système de module, il est nécessaire d'importer le store dans tous les composants qui utilisent l'état du store, et il est également nécessaire de le simuler lorsque l'on teste le composant.
 
-Vuex fournit un méchanisme pour « injecter » le store dans tous les composants enfants du composant racine avec l'option `store` (activée par `Vue.use(Vuex)`) :
+Vuex fournit un mécanisme pour « injecter » le store dans tous les composants enfants du composant racine avec l'option `store` (activée par `Vue.use(Vuex)`) :
 
 ``` js
 const app = new Vue({
@@ -58,10 +58,10 @@ const Counter = {
 
 ### La fonction utilitaire `mapState`
 
-Lorsqu'un composant a besoin d'utiliser plusieurs accesseurs ou propriétés de l'état du store, déclarer toutes ces propriétés calculées peut devenir répétitif et verbeux. Afin de palier à ça, nous pouvons utiliser la fonction utilitaire `mapState` qui génère des fonctions d'accession pour nous et nous épargne quelques coups de clavier :
+Lorsqu'un composant a besoin d'utiliser plusieurs accesseurs ou propriétés de l'état du store, déclarer toutes ces propriétés calculées peut devenir répétitif et verbeux. Afin de pallier à ça, nous pouvons utiliser la fonction utilitaire `mapState` qui génère des fonctions d'accession pour nous et nous épargne quelques coups de clavier :
 
 ``` js
-// dans la version complète, des fonctions utilitaires sont exposées tel que `Vuex.mapState`
+// dans la version complète, des fonctions utilitaires sont exposées telles que `Vuex.mapState`
 import { mapState } from 'vuex'
 
 export default {
@@ -81,7 +81,7 @@ export default {
 }
 ```
 
-Il est également possible de fournir un tableau de chaînes de caractères à `mapState` lorsque le nom de la propriété de l'état du store est le même que celui du composant.
+Il est également possible de fournir un tableau de chaines de caractères à `mapState` lorsque le nom de la propriété de l'état du store est le même que celui du composant.
 
 ``` js
 computed: mapState([
@@ -106,4 +106,4 @@ computed: {
 
 ### Les composants peuvent toujours avoir un état local
 
-Utiliser Vuex ne signifie pas que vous devez mettre **tout** votre état dans Vuex. Bien que le fait de mettre plus d'état dans Vuex rende vos mutation d'état plus explicites et plus débogable, parfois il peut aussi rendre le code plus verbeux et indirect. Si une partie de l'état appartient directement à un seul composant, il est parfaitement sain de la laisser dans l'état local. Assurez vous de prendre en compte les avantages et inconvénients d'une telle décision afin de vous adapter au mieux aux besoins de votre application.
+Utiliser Vuex ne signifie pas que vous devez mettre **tout** votre état dans Vuex. Bien que le fait de mettre plus d'états dans Vuex rende vos mutations d'état plus explicites et plus débogable, parfois il peut aussi rendre le code plus verbeux et indirect. Si une partie de l'état appartient directement à un seul composant, il est parfaitement sain de la laisser dans l'état local. Assurez-vous de prendre en compte les avantages et inconvénients d'une telle décision afin de vous adapter au mieux aux besoins de votre application.

docs/fr/strict.md

@@ -13,7 +13,7 @@ En mode strict, lorsque l'état de Vuex est modifié en dehors des gestionnaires
 
 ### Développement vs. production
 
-**N'activez pas le mode strict lorsque vous déployez en production !** Le mode strict lance une observation récursive de l'arbre d'état pour détecter des mutations inappropriées. Assurrez-vous de l'avoir désactivé en production pour éviter un coût sur les performances.
+**N'activez pas le mode strict lorsque vous déployez en production !** Le mode strict lance une observation récursive de l'arbre d'état pour détecter des mutations inappropriées. Assurez-vous de l'avoir désactivé en production pour éviter un cout sur les performances.
 
 Tout comme les plugins, nous pouvons laisser nos outils de build gérer ça :
 

docs/fr/structure.md

@@ -10,7 +10,7 @@ Vuex ne vous restreint pas quand à la structure de code à utiliser. Il impose
 
 Tant que vous suivez ces règles, c'est à vous de structurer votre projet. Si votre fichier de store devient trop gros, commencez dès lors à séparer les actions, mutations et accesseurs dans des fichiers séparés.
 
-Pour une application non-triviale, nous aurons probablement besoin de faire appel à des modules. Voici un exemple de structure de projet :
+Pour une application non triviale, nous aurons probablement besoin de faire appel à des modules. Voici un exemple de structure de projet :
 
 ``` bash
 ├── index.html
@@ -29,4 +29,4 @@ Pour une application non-triviale, nous aurons probablement besoin de faire appe
         └── products.js   # module de produit
 ```
 
-Vous pouvez jeter à un œil à l'[exemple de panier d'achat](https://github.com/vuejs/vuex/tree/dev/examples/shopping-cart).
+Vous pouvez jeter à un œil à l'[exemple de panier d'achats](https://github.com/vuejs/vuex/tree/dev/examples/shopping-cart).

docs/fr/testing.md

@@ -111,7 +111,7 @@ const testAction = (action, args, state, expectedMutations, done) => {
   // appeler l'action avec le store simulé et les arguments
   action({ commit, state }, ...args)
 
-  // vérifier qu'aucune mutations n'ai été propagée
+  // vérifier qu'aucune mutation n'ait été propagée
   if (expectedMutations.length === 0) {
     expect(count).to.equal(0)
     done()
@@ -163,7 +163,7 @@ describe('getters', () => {
     // accesseur simulé
     const filterCategory = 'fruit'
 
-    // obterir le résultat depuis l'accesseur
+    // obtenir le résultat depuis l'accesseur
     const result = getters.filteredProducts(state, { filterCategory })
 
     // tester le résultat