diff --git a/en/README.md b/en/README.md
index 015fee08..ebf26de5 100644
--- a/en/README.md
+++ b/en/README.md
@@ -9,9 +9,9 @@
 
 ## Le rendu côté serveur ou SSR, qu'est-ce que c'est ?
 
-Vue.js est un framework pour créer des applications côté client. Par défaut, Vue génère en sortie un DOM manipulable dans le navigateur. Il est cependant également possible de faire le rendu des mêmes composants sous forme de chaîne de caractères HTML côté serveur, de les envoyer directement au navigateur et d'« hydrater » les balises statiques fournies en une application cliente pleinement interactive.
+Vue.js est un framework pour créer des applications côté client. Par défaut, Vue génère en sortie un DOM manipulable dans le navigateur. Il est cependant également possible de faire le rendu des mêmes composants sous forme de chaine de caractères HTML côté serveur, de les envoyer directement au navigateur et d'« hydrater » les balises statiques fournies en une application cliente pleinement interactive.
 
-Une application Vue.js rendue du côté serveur peut également être considérée comme « isomorphique » ou « universelle », dans le sens où la majorité du code est exécutable côté serveur **et** coté client.
+Une application Vue.js rendue du côté serveur peut également être considérée comme « isomorphique » ou « universelle », dans le sens où la majorité du code est exécutable côté serveur **et** côté client.
 
 ## Pourquoi faire du SSR ?
 
@@ -21,13 +21,13 @@ En comparaison des applications monopages traditionnelles (SPA pour *Single-Page
 
   À noter qu'à présent, Google et Bing savent parfaitement indexer des applications JavaScript synchrones. Synchrone est le mot important ici. Si votre application débute avec une animation de chargement, puis va chercher le contenu via Ajax, l'indexeur n'attendra pas que cette action soit finie. Cela signifie que si vous avez du contenu asynchrone injecté sur des pages où la SEO est importante, du SSR serait nécessaire.
 
-- De meilleurs temps d'accès au contenu, en particulier pour les connexions Internet lentes ou les appareils lents. Le rendu des balises côté serveur n'a pas besoin d'attendre le chargement de tous les fichiers JavaScript pour que le code soit exécuté en vue d'être affiché. Ainsi votre utilisateur verra apparaître une page complètement rendue très tôt. Cela conduit généralement à une meilleure expérience utilisateur, ce qui peut-être critique pour les applications où le temps d'accès au contenu est directement lié au taux de conversion.
+- De meilleurs temps d'accès au contenu, en particulier pour les connexions Internet lentes ou les appareils lents. Le rendu des balises côté serveur n'a pas besoin d'attendre le chargement de tous les fichiers JavaScript pour que le code soit exécuté en vue d'être affiché. Ainsi votre utilisateur verra apparaitre une page complètement rendue très tôt. Cela conduit généralement à une meilleure expérience utilisateur, ce qui peut-être critique pour les applications où le temps d'accès au contenu est directement lié au taux de conversion.
 
 Il y a aussi des contraintes à prendre en considération quand on utilise du SSR :
 
-- Des contraintes de développement. Le code spécifique aux navigateurs ne peut être utilisé que dans certains hooks ; plusieurs bibliothèques nécessitent une utilisation particulière pour être capable d'être exécutées dans une application côté serveur.
+- Des contraintes de développement. Le code spécifique aux navigateurs ne peut être utilisé que dans certains hooks ; plusieurs bibliothèques nécessitent une utilisation particulière pour être capables d'être exécutées dans une application côté serveur.
 
-- Plus d'étapes de pré-compilation et de déploiement requises. Contrairement à une SPA qui peut être déployée sur un serveur de fichiers statiques, une application rendue côté serveur nécessite un environnement où un serveur Node.js peut tourner.
+- Plus d'étapes de précompilation et de déploiement requises. Contrairement à une SPA qui peut être déployée sur un serveur de fichiers statiques, une application rendue côté serveur nécessite un environnement où un serveur Node.js peut tourner.
 
 - Plus de charge côté serveur. Faire le rendu d'une application complète en Node.js est évidemment une tâche demandant plus de ressources CPU que de simplement renvoyer des fichiers statiques. Aussi si vous vous attendez à un fort trafic, préparez-vous un serveur tenant la charge et utilisez astucieusement des stratégies de mise en cache.
 
@@ -35,7 +35,7 @@ Avant d'utiliser du SSR pour vos applications, la première question que vous de
 
 ## Rendu côté serveur vs. pré-rendu
 
-Si vous envisagez d'utiliser du SSR seulement pour améliorer votre SEO sur des pages informatives à valeur ajoutée (par ex. `/`, `/about`, `/contact`, etc), alors vous devriez plutôt utiliser du pré-rendu. Plutôt que d'utiliser un serveur web pour compiler le HTML en temps réel, faites le simple pré-rendu de vos pages statiques en HTML pour des routes bien spécifiques lors d'une phase de pré-compilation. L'avantage est que faire du pré-rendu est plus simple et vous permet de garder un site avec une partie cliente statique.
+Si vous envisagez d'utiliser du SSR seulement pour améliorer votre SEO sur des pages informatives à valeur ajoutée (par ex. `/`, `/about`, `/contact`, etc.), alors vous devriez plutôt utiliser du pré-rendu. Plutôt que d'utiliser un serveur web pour compiler le HTML en temps réel, faites le simple pré-rendu de vos pages statiques en HTML pour des routes bien spécifiques lors d'une phase de précompilation. L'avantage est que faire du pré-rendu est plus simple et vous permet de garder un site avec une partie cliente statique.
 
 Si vous utilisez webpack, vous pouvez facilement ajouter du pré-rendu avec le plugin [prerender-spa-plugin](https://github.com/chrisvfritz/prerender-spa-plugin). Il a particulièrement bien été testé avec des applications Vue (en fait, [son créateur](https://github.com/chrisvfritz) est lui-même un membre de l'équipe principale de Vue).
 
@@ -43,7 +43,7 @@ Si vous utilisez webpack, vous pouvez facilement ajouter du pré-rendu avec le p
 
 Ce guide est dédié au rendu côté serveur des applications monopages utilisant Node.js en tant que serveur web. Utiliser le SSR de Vue avec une autre configuration serveur est un sujet qui ne sera pas abordé dans ce guide.
 
-Ce guide va réellement entrer dans le détail et présuppose que vous êtes déjà familiarisé avec Vue.js et que vous avez un niveau de connaissance correcte concernant Node.js et webpack. Si vous préférez une solution de haut niveau fournissant une expérience de développement prête à l'emploi, vous devriez probablement essayer [Nuxt.js](https://nuxtjs.org/). Il est construit par-dessus l'écosystème de Vue et vous fourni des éléments préconçus ainsi que des fonctionnalités supplémentaires pour générer des sites web statiques. Il ne vous conviendra cependant pas si vous souhaitez avoir un contrôle plus direct sur la structure de votre application. Dans tous les cas, il reste toujours intéressant de parcourir ce guide pour mieux comprendre comment chaque élément fonctionne avec le reste.
+Ce guide va réellement entrer dans le détail et présuppose que vous êtes déjà familiarisé avec Vue.js et que vous avez un niveau de connaissance correcte concernant Node.js et webpack. Si vous préférez une solution de haut niveau fournissant une expérience de développement prête à l'emploi, vous devriez probablement essayer [Nuxt.js](https://nuxtjs.org/). Il est construit par-dessus l'écosystème de Vue et vous fournit des éléments préconçus ainsi que des fonctionnalités supplémentaires pour générer des sites web statiques. Il ne vous conviendra cependant pas si vous souhaitez avoir un contrôle plus direct sur la structure de votre application. Dans tous les cas, il reste toujours intéressant de parcourir ce guide pour mieux comprendre comment chaque élément fonctionne avec le reste.
 
 Au fil de votre lecture, il peut être intéressant également de vous référer à la [démo HackerNews](https://github.com/vuejs/vue-hackernews-2.0/) qui utilise bon nombre des techniques expliquées dans ce guide.
 
diff --git a/en/SUMMARY.md b/en/SUMMARY.md
index f0e4713a..c5c054ba 100644
--- a/en/SUMMARY.md
+++ b/en/SUMMARY.md
@@ -5,7 +5,7 @@
 - [Récupération de données et état](data.md)
 - [Hydratation côté client](hydration.md)
 - [Introduction au moteur de dépaquetage](bundle-renderer.md)
-- [Configuration de pré-compilation](build-config.md)
+- [Configuration de précompilation](build-config.md)
 - [Gestion des CSS](css.md)
 - [Gestion des entêtes](head.md)
 - [Mise en cache](caching.md)
diff --git a/en/api.md b/en/api.md
index baaa972d..9b3a9f61 100644
--- a/en/api.md
+++ b/en/api.md
@@ -24,15 +24,15 @@ L'argument `serverBundle` peut être l'un des éléments suivants :
 
 - Un objet de paquetage généré par webpack + `vue-server-renderer/server-plugin`.
 
-- Une chaîne de caractères de code JavaScript (non recommandé).
+- Une chaine de caractères de code JavaScript (non recommandé).
 
-Voyez l'[Introduction au moteur de dépaquetage](./bundle-renderer.md) et la [Configuration de pré-compilation](./build-config.md) pour plus de détails.
+Voyez l'[Introduction au moteur de dépaquetage](./bundle-renderer.md) et la [Configuration de précompilation](./build-config.md) pour plus de détails.
 
 ## `Class: Renderer`
 
 - #### `renderer.renderToString(vm[, context], callback)`
 
-  Fait le rendu d'une instance de Vue sous forme de chaîne de caractères. L'objet de contexte est optionnel. La fonction de rappel est une fonction de rappel typique de Node.js avec en premier argument l'erreur potentielle et en second argument la chaîne de caractères du rendu.
+  Fait le rendu d'une instance de Vue sous forme de chaine de caractères. L'objet de contexte est optionnel. La fonction de rappel est une fonction de rappel typique de Node.js avec en premier argument l'erreur potentielle et en second argument la chaine de caractères du rendu.
 
 - #### `renderer.renderToStream(vm[, context])`
 
@@ -42,7 +42,7 @@ Voyez l'[Introduction au moteur de dépaquetage](./bundle-renderer.md) et la [Co
 
 - #### `bundleRenderer.renderToString([context, ]callback)`
 
-  Fait le rendu d'un paquetage sous forme de chaîne de caractères. L'objet de contexte est optionnel. La fonction de rappel est une fonction de rappel typique de Node.js avec en premier argument l'erreur potentielle et en second argument la chaîne de caractères du rendu.
+  Fait le rendu d'un paquetage sous forme de chaine de caractères. L'objet de contexte est optionnel. La fonction de rappel est une fonction de rappel typique de Node.js avec en premier argument l'erreur potentielle et en second argument la chaine de caractères du rendu.
 
 - #### `bundleRenderer.renderToStream([context])`
 
@@ -56,21 +56,21 @@ Voyez l'[Introduction au moteur de dépaquetage](./bundle-renderer.md) et la [Co
 
   Le modèle de page supporte également l'interpolation basique en utilisant le contexte du rendu :
 
-  - utilisez les double moustaches pour de l'interpolation avec HTML échappé et
-  - utilisez les triple moustaches pour de l'interpolation avec HTML non échappé.
+  - utilisez les doubles moustaches pour de l'interpolation avec HTML échappé et
+  - utilisez les triples moustaches pour de l'interpolation avec HTML non échappé.
 
   Le modèle de page injecte automatiquement le contenu quand certaines données sont trouvées dans le contexte du rendu :
 
   - `context.head`: (string) n'importe quelle balise d'entête qui devrait être injectée dans la balise `<head>` de la page.
 
-  - `context.styles`: (string) n'importe quelle CSS qui devrait être injectée dans la balide `<head>` de la page. Notez que cette propriété va automatiquement être injectée si vous utilisez `vue-loader` + `vue-style-loader` pour la CSS de vos composants.
+  - `context.styles`: (string) n'importe quelle CSS qui devrait être injectée dans la balise `<head>` de la page. Notez que cette propriété va automatiquement être injectée si vous utilisez `vue-loader` + `vue-style-loader` pour la CSS de vos composants.
 
   - `context.state`: (Object) L'état initial du store Vuex devrait être injecté dans la page sous la variable `window.__INITIAL_STATE__`. Le JSON en ligne est automatiquement désinfecté avec [serialize-javascript](https://github.com/yahoo/serialize-javascript) pour éviter les injections XSS.
 
   En plus, quand `clientManifest` est fourni, le modèle de page injecte automatiquement les éléments suivants :
 
   - JavaScript client et fichiers CSS nécessaires pour le rendu (avec les fragments asynchrones automatiquement déduits),
-  - utilisation optimal des indices de ressources `<link rel="preload/prefetch">` pour le rendu de la page.
+  - utilisation optimale des indices de ressources `<link rel="preload/prefetch">` pour le rendu de la page.
 
   Vous pouvez désactiver toutes ces injections en passant `inject: false` au moteur de rendu.
 
@@ -99,9 +99,9 @@ Voyez l'[Introduction au moteur de dépaquetage](./bundle-renderer.md) et la [Co
 
   Une fonction pour contrôler quels fichiers doivent avoir une ressource d'indice `<link rel="preload">` de générée.
 
-  Par défaut, seuls les fichiers JavaScript et les fichiers CSS seront pré-chargés, car ils sont absolument nécessaires pour le démarrage de l'application.
+  Par défaut, seuls les fichiers JavaScript et les fichiers CSS seront préchargés, car ils sont absolument nécessaires pour le démarrage de l'application.
 
-  Pour les autres types de fichiers comme les images et les polices, le pré-chargement pouvant gâcher de la bande passante inutilement et même baisser les performances, cela est laissé à votre appréciation. Vous pouvez contrôler précisément le pré-chargement en utilisant l'option `shouldPreload` :
+  Pour les autres types de fichiers comme les images et les polices, le préchargement pouvant gâcher de la bande passante inutilement et même baisser les performances, cela est laissé à votre appréciation. Vous pouvez contrôler précisément le préchargement en utilisant l'option `shouldPreload` :
 
   ``` js
   const renderer = createBundleRenderer(bundle, {
@@ -114,7 +114,7 @@ Voyez l'[Introduction au moteur de dépaquetage](./bundle-renderer.md) et la [Co
         return true
       }
       if (type === 'font') {
-        // pré-charger uniquement les polices woff2
+        // précharger uniquement les polices woff2
         return /\.woff2$/.test(file)
       }
       if (type === 'image') {
@@ -131,15 +131,15 @@ Voyez l'[Introduction au moteur de dépaquetage](./bundle-renderer.md) et la [Co
   - seulement utilisée avec `createBundleRenderer`
   - Requiert : `boolean | 'once'` (`'once'` est seulement supporté dans la 2.3.1+)
 
-  Par défaut, pour chaque rendu, le moteur de dépaquetage va créer un nouveau contexte V8 et ré-exécuter le paquetage complet. Cela a plusieurs bénéfices, comme par exemple, isoler le code de l'application des processus du serveur ce qui permet d'[Eviter les singletons d'état](./structure.md#eviter-les-singletons-detat) mentionnés dans la documentation. Cependant, ce mode a des coûts de performance importants car ré-exécuter le paquetage est quelque chose de coûteux, surtout quand l'application est grosse.
+  Par défaut, pour chaque rendu, le moteur de dépaquetage va créer un nouveau contexte V8 et réexécuter le paquetage complet. Cela a plusieurs bénéfices, par exemple, isoler le code de l'application des processus du serveur ce qui permet d'[Éviter les singletons d'état](./structure.md#eviter-les-singletons-detat) mentionnés dans la documentation. Cependant, ce mode a des couts de performance importants car réexécuter le paquetage est quelque chose de couteux, surtout quand l'application est grosse.
 
-  Cette option est par défaut à `true` pour la rétro-compatibilité, mais il est recommandé d'utiliser `runInNewContext: false` ou `runInNewContext: 'once'` si vous le pouvez.
+  Cette option est par défaut à `true` pour la rétrocompatibilité, mais il est recommandé d'utiliser `runInNewContext: false` ou `runInNewContext: 'once'` si vous le pouvez.
 
   > Dans la 2.3.0 cette option a un bogue car `runInNewContext: false` exécute toujours le paquetage en utilisant un contexte global séparé. Les informations suivantes sont donc valables pour la version 2.3.1+.
 
   Avec `runInNewContext: false`, le code de paquetage va tourner dans le même contexte `global` du processus serveur, donc faites attention au code qui modifie `global` dans le code de votre application.
 
-  Avec `runInNewContext: 'once'` (2.3.1+), le paquetage est évalué dans un contexte `global` séparé, cependant cela n'est effectué qu'au démarrage. Cela permet une meilleur isolation du code de l'application puisqu'il empêche le paquetage d'accidentellement polluer l'objet `global` du processus serveur. Les limitations sont les suivantes :
+  Avec `runInNewContext: 'once'` (2.3.1+), le paquetage est évalué dans un contexte `global` séparé, cependant cela n'est effectué qu'au démarrage. Cela permet une meilleure isolation du code de l'application puisqu'il empêche le paquetage d'accidentellement polluer l'objet `global` du processus serveur. Les limitations sont les suivantes :
 
   1. Les dépendances qui modifient l'objet `global` (ex. polyfills) ne peuvent être externalisées dans ce mode,
   2. Les valeurs retournées lors de l'exécution du paquetage utiliseront des constructeurs globaux différents. Par ex. une erreur levée à l'intérieur du paquetage ne sera pas une instance de `Error` dans le processus serveur.
@@ -184,7 +184,7 @@ Voyez l'[Introduction au moteur de dépaquetage](./bundle-renderer.md) et la [Co
     cache: {
       get: (key, cb) => {
         redisClient.get(key, (err, res) => {
-          // gérer les erreur s'il y en a
+          // gérer les erreurs s'il y en a
           cb(res)
         })
       },
@@ -209,7 +209,7 @@ Voyez l'[Introduction au moteur de dépaquetage](./bundle-renderer.md) et la [Co
   })
   ```
 
-  Consultez l'[implementation de `v-show` côté serveur](https://github.com/vuejs/vue/blob/dev/src/platforms/web/server/directives/show.js) en tant qu'exemple.
+  Consultez l'[implémentation de `v-show` côté serveur](https://github.com/vuejs/vue/blob/dev/src/platforms/web/server/directives/show.js) en tant qu'exemple.
 
 ## Plugins webpack
 
@@ -233,4 +233,4 @@ const plugin = new VueSSRServerPlugin({
 })
 ```
 
-Voir la [Configuration de pré-compilation](./build-config.md) pour plus d'informations.
+Voir la [Configuration de précompilation](./build-config.md) pour plus d'informations.
diff --git a/en/basic.md b/en/basic.md
index b4723318..015f74c3 100644
--- a/en/basic.md
+++ b/en/basic.md
@@ -36,7 +36,7 @@ renderer.renderToString(app, (err, html) => {
 
 ## Intégration avec un serveur
 
-Il est plus simple d'utiliser le code précédent avec un serveur Node.js, comme par exemple [Express](https://expressjs.com/) :
+Il est plus simple d'utiliser le code précédent avec un serveur Node.js, par exemple [Express](https://expressjs.com/) :
 
 ``` bash
 npm install express --save
@@ -110,7 +110,7 @@ Le modèle de page supporte également une interpolation simple. Avec le modèle
 ``` html
 <html>
   <head>
-    <!-- utilisation de la double moustache pour l'interpolation avec HTML échapé -->
+    <!-- utilisation de la double moustache pour l'interpolation avec HTML échappé -->
     <title>{{ title }}</title>
 
     <!-- utilisation de la triple moustache pour l'interpolation du HTML -->
diff --git a/en/build-config.md b/en/build-config.md
index 210d82e1..857ada91 100644
--- a/en/build-config.md
+++ b/en/build-config.md
@@ -1,6 +1,6 @@
-# Configuration de pré-compilation
+# Configuration de précompilation
 
-Nous allons suposez que vous savez déjà comment configurer webpack pour un projet uniquement client. La configuration pour un projet avec du SSR va être en grande partie similaire, mais nous vous suggérons de séparer vos configurations en trois fichiers : *base*, *client* et *server*. La configuration de base contient la configuration partagée par les deux environnements, comme les chemins de sortie, les aliases et les loaders. La configuration du serveur et la configuration du client peut simplement étendre la configuration de base en utilisant [webpack-merge](https://github.com/survivejs/webpack-merge).
+Nous allons supposez que vous savez déjà comment configurer webpack pour un projet uniquement client. La configuration pour un projet avec du SSR va être en grande partie similaire, mais nous vous suggérons de séparer vos configurations en trois fichiers : *base*, *client* et *server*. La configuration de base contient la configuration partagée par les deux environnements, comme les chemins de sortie, les aliases et les loaders. La configuration du serveur et la configuration du client peuvent simplement étendre la configuration de base en utilisant [webpack-merge](https://github.com/survivejs/webpack-merge).
 
 ## Configuration serveur
 
@@ -35,7 +35,7 @@ module.exports = merge(baseConfig, {
   // et génère un fichier de paquetage plus petit.
   externals: nodeExternals({
     // ne pas externaliser les dépendances qui ont besoin d'être traitées par webpack.
-    // vous pouvez ajouter plus de types de fichier ici, comme par ex. avec les fichiers `*.vue`
+    // vous pouvez ajouter plus de types de fichiers ici, comme par ex. avec les fichiers `*.vue`
     // vous devriez aussi lister des exceptions qui modifient `global` (par ex. les polyfills)
     whitelist: /\.css$/
   }),
@@ -54,7 +54,7 @@ Après que `vue-ssr-server-bundle.json` ai été généré, passez simplement le
 ``` js
 const { createBundleRenderer } = require('vue-server-renderer')
 const renderer = createBundleRenderer('/path/to/vue-ssr-server-bundle.json', {
-  // ...autre options pour le moteur
+  // ...autres options pour le moteur
 })
 ```
 
@@ -62,27 +62,27 @@ Vous pouvez alternativement tout aussi bien passer le paquetage comme un objet 
 
 ### Limitations externes
 
-Notons que dans l'option `externals` nous avons exclus les fichiers CSS. C'est parce que les fichiers CSS importés par dépendances doivent quand même être gérés par webpack. Si vous importez n'importe quels autres types de fichier également pris en charge par webpack (ex : `*.vue`, `*.styl`), vous pouvez également les ajouter à la liste des exceptions.
+Notons que dans l'option `externals` nous avons exclu les fichiers CSS. C'est parce que les fichiers CSS importés par dépendances doivent quand même être gérés par webpack. Si vous importez n'importe quels autres types de fichiers également pris en charge par webpack (ex : `*.vue`, `*.styl`), vous pouvez également les ajouter à la liste des exceptions.
 
 Si vous utilisez `runInNewContext: 'once'` ou `runInNewContext: true`, alors vous devrez également ajouter aux exceptions les polyfills qui modifient `global` comme par ex. `babel-polyfill`. Cela est dû au fait qu'en utilisant un nouveau mode de contexte, **le code à l'intérieur d'un paquetage serveur a son propre objet `global`.** Parce qu'il n'est plus nécessaire de faire cela côté serveur en utilisant Node.js 7.6+, c'est d'autant plus facile de ne les importer que côté client.
 
 ## Configuration cliente
 
-La configuration cliente peut être en grande partie la même grâce à la configuration de base. Bien sur vous devez faire pointer `entry` sur votre fichier d'entrée client. En plus de cela, si vous utilisez le plugin `CommonsChunkPlugin`, assurez-vous de ne l'utiliser que dans la configuration cliente car le paquetage serveur requiert un unique fragment d'entrée.
+La configuration cliente peut être en grande partie la même grâce à la configuration de base. Bien sûr vous devez faire pointer `entry` sur votre fichier d'entrée client. En plus de cela, si vous utilisez le plugin `CommonsChunkPlugin`, assurez-vous de ne l'utiliser que dans la configuration cliente car le paquetage serveur requiert un unique fragment d'entrée.
 
 ### Générer le `clientManifest`
 
 > requiert la version 2.3.0+
 
-En plus du paquetage serveur, nous pouvons également générer un build de manifeste client. Avec le manifeste client et le paquetage serveur, le moteur a maintenant les informations du build serveur *et* du build client, ainsi il peut automatiquement déduire et injecter les [directives pré-chargées et récupérées](https://css-tricks.com/prefetching-preloading-prebrowsing/) ainsi que les balises `<link>` / `<script>` dans le rendu HTML.
+En plus du paquetage serveur, nous pouvons également générer un build de manifeste client. Avec le manifeste client et le paquetage serveur, le moteur a maintenant les informations du build serveur *et* du build client, ainsi il peut automatiquement déduire et injecter les [directives préchargées et récupérées](https://css-tricks.com/prefetching-preloading-prebrowsing/) ainsi que les balises `<link>` / `<script>` dans le rendu HTML.
 
 Les bénéfices sont doubles :
 
 1. Il peut remplacer le plugin `html-webpack-plugin` pour l'injection correcte d'URL de fichiers quand il y a des hashs dans les noms de fichier générés.
 
-2. Lors du rendu d'un paquetage qui s'appuie sur les fonctionnalités de scission de code à la demande de webpack, nous pouvons être assuré que les fragments optimaux sont pré-chargés / récupérés, et que les balises `<script>` des fragments asynchrones nécessaires pour éviter la cascade de requête depuis le client sont intelligemment injectés. Cela améliore le TTI (« time-to-interactive »).
+2. Lors du rendu d'un paquetage qui s'appuie sur les fonctionnalités de scission de code à la demande de webpack, nous pouvons être assurés que les fragments optimaux sont préchargés / récupérés, et que les balises `<script>` des fragments asynchrones nécessaires pour éviter la cascade de requête depuis le client sont intelligemment injectées. Cela améliore le TTI (« time-to-interactive »).
 
-Pour tirer partie du manifeste client, la configuration cliente devrait ressembler à ça :
+Pour tirer parti du manifeste client, la configuration cliente devrait ressembler à ça :
 
 ``` js
 const webpack = require('webpack')
@@ -93,7 +93,7 @@ const VueSSRClientPlugin = require('vue-server-renderer/client-plugin')
 module.exports = merge(baseConfig, {
   entry: '/path/to/entry-client.js',
   plugins: [
-    // Important : cela scinde l'exécution de webpack en un fragment maître
+    // Important : cela scinde l'exécution de webpack en un fragment maitre
     // et des fragments asynchrones qui peuvent être injectés juste après lui.
     // cela permet également une meilleure mise en cache pour vos codes d'applications tierces.
     new webpack.optimize.CommonsChunkPlugin({
@@ -127,7 +127,7 @@ Avec cette mise en place, votre rendu HTML côté serveur pour un build avec sci
 ``` html
 <html>
   <head>
-    <!-- les fragments utilisés pour ce rendu vont être pré-chargés -->
+    <!-- les fragments utilisés pour ce rendu vont être préchargés -->
     <link rel="preload" href="/manifest.js" as="script">
     <link rel="preload" href="/main.js" as="script">
     <link rel="preload" href="/0.js" as="script">
@@ -156,13 +156,13 @@ Dans la fonction de rappel de `renderToString`, l'objet `context` que vous passe
 
   Cela va retourner une balise `<style>` contenant tout le CSS critique récupéré dans les composants `*.vue` et utilisés durant le rendu. Consultez [Gestion des CSS](./css.md) pour plus de détails.
 
-  Si un `clientManifest` est fourni, la chaîne retournée va également contenir la balise `<link rel="stylesheet">` pour les fichiers CSS emis par webpack (ex: CSS extrait avec `extract-text-webpack-plugin` ou importés avec `file-loader`)
+  Si un `clientManifest` est fourni, la chaine retournée va également contenir la balise `<link rel="stylesheet">` pour les fichiers CSS émis par webpack (ex: CSS extrait avec `extract-text-webpack-plugin` ou importés avec `file-loader`)
 
 - `context.renderState(options?: Object)`
 
   Cette méthode sérialise `context.state` et retourne une balise script qui contient l'état avec `window.__INITIAL_STATE__`.
 
-  La clé et la valeur de l'état peuvent être tous les deux passés dans l'objet d'option :
+  La clé et la valeur de l'état peuvent être toutes les deux passées dans l'objet d'option :
 
   ``` js
   context.renderState({
@@ -177,7 +177,7 @@ Dans la fonction de rappel de `renderToString`, l'objet `context` que vous passe
 
   - requiert `clientManifest`
 
-  Cette méthode retourne la balise `<script>` nécessaire pour que l'application cliente puisse démarrer. Lors de l'utilisation de la scission de code asynchrone dans le code de l'application, cette méthode va intélligemment trouver les fragments asynchrones correctes à inclure.
+  Cette méthode retourne la balise `<script>` nécessaire pour que l'application cliente puisse démarrer. Lors de l'utilisation de la scission de code asynchrone dans le code de l'application, cette méthode va intelligemment trouver les fragments asynchrones corrects à inclure.
 
 - `context.renderResourceHints()`
 
@@ -185,16 +185,16 @@ Dans la fonction de rappel de `renderToString`, l'objet `context` que vous passe
 
   Cette méthode retourne les balises `<link rel="preload/prefetch">` nécessaires au rendu optimisé de la page. Par défaut ce sera :
 
-  - Pré-chargement (récupération et exécution) des fichiers JavaScript et CSS requis par la page,
-  - Récupération asynchrones des fragments JavaScript qui seront nécessaires plus tard.
+  - Préchargement (récupération et exécution) des fichiers JavaScript et CSS requis par la page,
+  - Récupération asynchrone des fragments JavaScript qui seront nécessaires plus tard.
 
-  Les fichiers pré-chargés peuvent être personnalisés plus en profondeur avec l'option [`shouldPreload`](./api.md#shouldpreload).
+  Les fichiers préchargés peuvent être personnalisés plus en profondeur avec l'option [`shouldPreload`](./api.md#shouldpreload).
 
 - `context.getPreloadFiles()`
 
   - requiert `clientManifest`
 
-  Cette méthode ne retourne pas de chaîne de caractère. À la place elle retourne un tableau d'objets représentant les fichiers qui devraient être pré-chargés. Cela peut-être utilisé pour programmatiquement réaliser de l'augmentation serveur HTTP/2.
+  Cette méthode ne retourne pas de chaine de caractère. À la place elle retourne un tableau d'objets représentant les fichiers qui devraient être préchargés. Cela peut-être utilisé pour programmatiquement réaliser de l'augmentation serveur HTTP/2.
 
 Puisque le `template` passé à `createBundleRenderer` va être interpolé en utilisant le `context`, vous pouvez utiliser ces méthodes à l’intérieur de celui-ci (with `inject: false`) :
 
@@ -213,4 +213,4 @@ Puisque le `template` passé à `createBundleRenderer` va être interpolé en ut
 </html>
 ```
 
-Si vous n'utilisez pas `template` du tout, vous pouvez concaténer les chaînes vous-mêmes.
+Si vous n'utilisez pas `template` du tout, vous pouvez concaténer les chaines vous-mêmes.
diff --git a/en/bundle-renderer.md b/en/bundle-renderer.md
index 39dffda9..9f8a82c2 100644
--- a/en/bundle-renderer.md
+++ b/en/bundle-renderer.md
@@ -8,7 +8,7 @@
 const createApp = require('/path/to/built-server-bundle.js')
 ```
 
-Même si c'est simple, à chaque fois que vous éditez votre code source à ce stade, vous devez stopper et redémarrer votre serveur. Cela ralenti quelque peu la productivité pendant le développement. De plus, Node.js ne supporte pas les sources maps nativement.
+Même si c'est simple, à chaque fois que vous éditez votre code source à ce stade, vous devez stopper et redémarrer votre serveur. Cela ralentit quelque peu la productivité pendant le développement. De plus, Node.js ne supporte pas les sources maps nativement.
 
 ## Le moteur de dépaquetage
 
@@ -16,15 +16,15 @@ Même si c'est simple, à chaque fois que vous éditez votre code source à ce s
 
 - Support des sources maps inclus (avec `devtool: 'source-map'` dans la configuration de webpack)
 
-- Rechargement à chaud pendant la phase de développement et même de déploiement (en relisant le paquetage mis à jour et en re-créant l'instance du moteur)
+- Rechargement à chaud pendant la phase de développement et même de déploiement (en relisant le paquetage mis à jour et en recréant l'instance du moteur)
 
-- Injection CSS critique (en utilisant les fichiers `*.vue`) : insérer automatiquement dans la sortie le CSS nécéssaire pour les composants pendant le rendu. Voir la section [CSS](./css.md) pour plus de détails.
+- Injection CSS critique (en utilisant les fichiers `*.vue`) : insérer automatiquement dans la sortie le CSS nécessaire pour les composants pendant le rendu. Voir la section [CSS](./css.md) pour plus de détails.
 
-- Injection de fragments avec [clientManifest](./api.md#clientmanifest) : déduire automatiquement le pré-chargement et la récupération des directives, et les fragments scindés requis pour le rendu initial.
+- Injection de fragments avec [clientManifest](./api.md#clientmanifest) : déduire automatiquement le préchargement et la récupération des directives, et les fragments scindés requis pour le rendu initial.
 
 ---
 
-Nous allons discuter de la manière de configurer webpack pour générer les artefacts de build nécessaires au moteur de dépaquetage dans la prochaine section, mais pour le moment, imaginons que nous ayons déjà ce dont nous avons besoin. Voici comment créer et utiliser un moteur de dépaquetage :
+Nous allons discuter de la manière de configurer webpack pour générer les artéfacts de build nécessaires au moteur de dépaquetage dans la prochaine section, mais pour le moment, imaginons que nous ayons déjà ce dont nous avons besoin. Voici comment créer et utiliser un moteur de dépaquetage :
 
 ``` js
 const { createBundleRenderer } = require('vue-server-renderer')
@@ -41,7 +41,7 @@ server.get('*', (req, res) => {
   // Pas besoin de passer l'application ici car elle est automatiquement créée
   // à l'exécution du paquetage. Maintenant notre serveur est découplé de notre application Vue !
   renderer.renderToString(context, (err, html) => {
-    // gérér les erreurs...
+    // gérer les erreurs...
     res.end(html)
   })
 })
diff --git a/en/caching.md b/en/caching.md
index 6562e93f..a373c422 100644
--- a/en/caching.md
+++ b/en/caching.md
@@ -1,17 +1,17 @@
 # Mise en cache
 
-Même si le SSR de Vue est très rapide, il ne peut égaler les performances d'un rendu utilisant une chaîne de caractères pure du fait du coût de la création des instances de composants et des nœuds du DOM virtuel. Dans le cas ou les performances du SSR seraient critiques, il est conseillé d'utiliser une stratégie de mise en cache pour améliorer significativement le temps de réponse et réduire la charge du serveur.
+Même si le SSR de Vue est très rapide, il ne peut égaler les performances d'un rendu utilisant une chaine de caractères pure du fait du cout de la création des instances de composants et des nœuds du DOM virtuel. Dans le cas où les performances du SSR seraient critiques, il est conseillé d'utiliser une stratégie de mise en cache pour améliorer significativement le temps de réponse et réduire la charge du serveur.
 
 ## Mise en cache au niveau de la page
 
-Une application de rendu côté serveur est, dans la plupart des cas, liée à des données externes. Donc le contenu est dynamique par nature et ne peut pas être mis en cache pour des périodes étendues. Cependant, si le contenu n'est pas spécifique à un utilisateur (c.-à-d. qu'un même URL rend toujours un même contenu indépendamment des utilisateurs), nous pouvons mettre en place une stratégie appelée [micro-caching](https://www.nginx.com/blog/benefits-of-microcaching-nginx/) pour améliorer significativement la capacité de notre application à prendre en charge un fort trafique.
+Une application de rendu côté serveur est, dans la plupart des cas, liée à des données externes. Donc le contenu est dynamique par nature et ne peut pas être mis en cache pour des périodes étendues. Cependant, si le contenu n'est pas spécifique à un utilisateur (c.-à-d. qu'un même URL rend toujours un même contenu indépendamment des utilisateurs), nous pouvons mettre en place une stratégie appelée [micro-caching](https://www.nginx.com/blog/benefits-of-microcaching-nginx/) pour améliorer significativement la capacité de notre application à prendre en charge un fort trafic.
 
 Ceci est habituellement fait au niveau de la couche nginx, mais nous pouvons également l'implémenter en Node.js :
 
 ``` js
 const microCache = LRU({
   max: 100,
-  maxAge: 1000 // Important : les entrées expires après une seconde.
+  maxAge: 1000 // Important : les entrées expirent après une seconde.
 })
 
 const isCacheable = req => {
@@ -75,12 +75,12 @@ Retourner une constante va mener le composant à toujours être en cache, ce qui
 
 ### Quand utiliser de la mise en cache de composant ?
 
-Si le moteur de rendu trouve du cache pour un composant durant le rendu, il va directement utiliser ce cache comme résultat pour le sous arbre de composant complet. Cela signifie qu'il ne faut **PAS** mettre en cache un composant quand :
+Si le moteur de rendu trouve du cache pour un composant durant le rendu, il va directement utiliser ce cache comme résultat pour le sous-arbre de composant complet. Cela signifie qu'il ne faut **PAS** mettre en cache un composant quand :
 
 - Il possède des composants enfants liés à l'état global.
 - Il possède des composants enfants qui produisent des effets de bord sur le rendu de `context`.
 
-La mise en cache de composant doit donc être utilisée avec soin pour éviter les goulots d'étranglement de performance. Dans la plupart des cas, vous n'en aurez pas besoin et donc pas besoin de mettre en cache les instances de composants. Les types de composants les plus communs pour de la mise en cache sont ceux utilisant de grosses listes `v-for`. Comme ces composants sont généralement alimentés par des collections de base de données, ils peuvent utiliser une simple stratégie de mise en cache : générer leur clé de mise en cache en utilisant leur unique identifiant associé à un timestamp mis à jour :
+La mise en cache de composant doit donc être utilisée avec soin pour éviter les goulots d'étranglement de performance. Dans la plupart des cas, vous n'en aurez pas besoin et donc pas besoin de mettre en cache les instances de composants. Les types de composants les plus communs pour de la mise en cache sont ceux utilisant de grosses listes `v-for`. Comme ces composants sont généralement alimentés par des collections de bases de données, ils peuvent utiliser une simple stratégie de mise en cache : générer leur clé de mise en cache en utilisant leur unique identifiant associé à un timestamp mis à jour :
 
 ``` js
 serverCacheKey: props => props.item.id + '::' + props.item.last_updated
diff --git a/en/css.md b/en/css.md
index 4706a6c0..63080510 100644
--- a/en/css.md
+++ b/en/css.md
@@ -3,7 +3,7 @@
 La gestion recommandée pour l'utilisation des CSS est de simplement utiliser une balise `<style>` à l'intérieur d'un fichier de composant monopage `*.vue`. Cela permet :
 
 - une sortie CSS limitée au composant,
-- la possibilité d'utiliser des pré-processeurs ou PostCSS,
+- la possibilité d'utiliser des préprocesseurs ou PostCSS,
 - le rechargement à chaud pendant le développement.
 
 Plus important encore, `vue-style-loader`, le loader utilisé en interne par `vue-loader`, a plusieurs fonctionnalités pour le rendu côté serveur :
@@ -12,13 +12,13 @@ Plus important encore, `vue-style-loader`, le loader utilisé en interne par `vu
 
 - Création automatique de CSS critique lors de l'utilisation de `bundleRenderer`.
 
-  S'il est utilisé pendant le rendu côté serveur, un composant CSS peut être récupéré et injecté dans la source HTML (automatiquement pris en charge avec l'option `template`). Côté client, quand le composant est utilisé pour la première fois, `vue-style-loader` va vérifier s'il n'y a pas déjà une sortie CSS dans la source HTML pour ce composant ; si non, le CSS va être automatiquement injecté via une balise `<stlye>`.
+  S'il est utilisé pendant le rendu côté serveur, un composant CSS peut être récupéré et injecté dans la source HTML (automatiquement pris en charge avec l'option `template`). Côté client, quand le composant est utilisé pour la première fois, `vue-style-loader` va vérifier s'il n'y a pas déjà une sortie CSS dans la source HTML pour ce composant ; sinon, le CSS va être automatiquement injecté via une balise `<style>`.
 
 - Extraction de CSS commun.
 
   Cette mise en place supporte [`extract-text-webpack-plugin`](https://github.com/webpack-contrib/extract-text-webpack-plugin) pour extraire le CSS du fragment principal en un fichier CSS séparé (automatiquement injecté avec l'option `template`), ce qui permet au fichier d'être mis en cache individuellement. Cela est recommandé quand il y a beaucoup de CSS partagés.
 
-  Les CSS a l'intérieur des composants asynchrones vont être compilés en tant que chaîne de caractères JavaScript et pris en charge par `vue-style-loader`.
+  Les CSS a l'intérieur des composants asynchrones vont être compilés en tant que chaine de caractères JavaScript et pris en charge par `vue-style-loader`.
 
 ## Activer l'extraction CSS
 
@@ -85,7 +85,7 @@ Quelques choses que vous devez prendre en note quand vous importez des CSS depui
 
 1. Ils ne devraient pas être externalisés dans un build serveur.
 
-2. Si vous utilisez de l'extraction CSS + de l'extraction de CSS tierces avec `CommonsChunkPlugin`, `extract-text-webpack-plugin` va mal fonctionner si le CSS extrait est à l'intérieur d'un extrait de fragment tiers. Pour résoudre cela, évitez d'inclure des fichiers CSS dans un fragment tiers. Voici un exemple de configuration côté client avec webpack :
+2. Si vous utilisez de l'extraction CSS + de l'extraction de CSS tierce avec `CommonsChunkPlugin`, `extract-text-webpack-plugin` va mal fonctionner si le CSS extrait est à l'intérieur d'un extrait de fragment tiers. Pour résoudre cela, évitez d'inclure des fichiers CSS dans un fragment tiers. Voici un exemple de configuration côté client avec webpack :
 
   ``` js
   module.exports = {
diff --git a/en/data.md b/en/data.md
index 1f179f2c..6f5baeba 100644
--- a/en/data.md
+++ b/en/data.md
@@ -2,13 +2,13 @@
 
 ## Gestionnaire d'état des données
 
-Pendant le SSR, nous allons essentiellement faire le rendu d'un « instantané » de notre application, aussi si votre application est liée à des données asynchrones, **ces données vont devoir être pré-chargées et résolues avant de débuter la phase de rendu**.
+Pendant le SSR, nous allons essentiellement faire le rendu d'un « instantané » de notre application, aussi si votre application est liée à des données asynchrones, **ces données vont devoir être préchargées et résolues avant de débuter la phase de rendu**.
 
 Un autre point important côté client ; les mêmes données doivent être disponibles avant que l'application ne soit montée, autrement, l'application côté client va faire le rendu d'un état différent et l'hydratation va échouer.
 
-Pour résoudre cela, les données pré-chargées doivent vivre en dehors de la vue du composant, dans un gestionnaire de données, ou dans un « gestionnaire d'état ». Côté serveur, nous pouvons pré-charger et remplir les données dans le gestionnaire de données avant le rendu. De plus, nous allons sérialiser et injecter l'état dans le HTML. Le gestionnaire de données côté client pourra directement récupérer l'état depuis le HTML avant que l'application ne soit montée.
+Pour résoudre cela, les données préchargées doivent vivre en dehors de la vue du composant, dans un gestionnaire de données, ou dans un « gestionnaire d'état ». Côté serveur, nous pouvons précharger et remplir les données dans le gestionnaire de données avant le rendu. De plus, nous allons sérialiser et injecter l'état dans le HTML. Le gestionnaire de données côté client pourra directement récupérer l'état depuis le HTML avant que l'application ne soit montée.
 
-Nous allons utiliser le gestionnaire d'état officiel (« store ») de la bibliothèque [Vuex](https://github.com/vuejs/vuex/) pour cette partie. Créons un fichier `store.js`, avec divers jeux de logique pour pré-charger un élément en nous basant sur un identifiant :
+Nous allons utiliser le gestionnaire d'état officiel (« store ») de la bibliothèque [Vuex](https://github.com/vuejs/vuex/) pour cette partie. Créons un fichier `store.js`, avec divers jeux de logique pour précharger un élément en nous basant sur un identifiant :
 
 ``` js
 // store.js
@@ -29,7 +29,7 @@ export function createStore () {
     actions: {
       fetchItem ({ commit }, id) {
         // retournant la Promesse via `store.dispatch()`, nous savons
-        // quand les données ont été pré-chargées
+        // quand les données ont été préchargées
         return fetchItem(id).then(item => {
           commit('setItem', { id, item })
         })
@@ -76,9 +76,9 @@ export function createApp () {
 
 ## Collocation logique avec les composants
 
-Donc, où devons nous appeler le code en charge de l'action de récupération de données ?
+Donc, où devons-nous appeler le code en charge de l'action de récupération de données ?
 
-Les données que nous avons besoin de pré-charger sont déterminées par la route visitée, qui va aussi déterminer quels composants vont être rendus. En fait, les données nécessaires a une route donnée sont aussi les données nécessaires aux composants pour être rendus pour une route. Aussi il serait naturel de placer la logique de récupération de données à l'intérieur des composants de route.
+Les données que nous avons besoin de précharger sont déterminées par la route visitée, qui va aussi déterminer quels composants vont être rendus. En fait, les données nécessaires à une route donnée sont aussi les données nécessaires aux composants pour être rendus pour une route. Aussi il serait naturel de placer la logique de récupération de données à l'intérieur des composants de route.
 
 Nous allons exposer une fonction statique personnalisée `asyncData` sur nos composants de route. Notez que, puisque cette fonction va être appelée avant l'instanciation des composants, l'accès à `this` ne sera pas possible. Le store et les informations de route ont donc besoin d'être passés en tant qu'arguments :
 
@@ -134,7 +134,7 @@ export default context => {
           })
         }
       })).then(() => {
-        // Après que chaque hook de pré-chargement soit résolu, notre store est maintenant
+        // Après que chaque hook de préchargement soit résolu, notre store est maintenant
         // rempli avec l'état nécessaire au rendu de l'application.
         // Quand nous attachons l'état au contexte, et que l'option `template`
         // est utilisée pour faire le rendu, l'état va automatiquement être
@@ -162,13 +162,13 @@ if (window.__INITIAL_STATE__) {
 
 ## Récupération de données côté client
 
-Côté client, il y a deux différentes approches pour gérer du récapération de données :
+Côté client, il y a deux différentes approches pour gérer la récupération de données :
 
 1. **Résoudre les données avant de changer de route :**
 
   Avec cette stratégie, l'application va rester sur la vue courante jusqu'à ce que les données nécessaires à la vue suivante soient résolues. L'avantage est que la vue suivante pourra faire le rendu complet du contenu aussitôt qu'il sera prêt, mais si les données mettent trop de temps à charger, l'utilisateur va se sentir « bloquer » sur la vue courante. C'est pourquoi il est recommandé de fournir un indicateur de chargement si vous utilisez cette stratégie.
 
-  Nous pouvons implémenter cette stratégie côté client en vérifiant la concordance des composants et en exécutant leurs fonctions `asyncData` à l'intérieur du hook global du routeur. Notez que nous devrions enregistrer ce hook après que la route initiale ne soit prête et donc il n'est pas nécessaire de pré-charger de nouveau les données du serveur ayant déjà été pré-chargées.
+  Nous pouvons implémenter cette stratégie côté client en vérifiant la concordance des composants et en exécutant leurs fonctions `asyncData` à l'intérieur du hook global du routeur. Notez que nous devrions enregistrer ce hook après que la route initiale ne soit prête et donc il n'est pas nécessaire de précharger de nouveau les données du serveur ayant déjà été préchargées.
 
   ``` js
   // entry-client.js
@@ -177,15 +177,15 @@ Côté client, il y a deux différentes approches pour gérer du récapération
 
   router.onReady(() => {
     // Ajouter le hook du routeur pour gérer `asyncData`
-    // Cela étant fait après la résolution de la route initial, évitons une double récupération de données
+    // Cela étant fait après la résolution de la route initiale, évitons une double récupération de données
     // des données que nous avons déjà. Utilisation de `router.beforeResolve()`, ainsi tous
     // les composants asynchrones sont résolues.
     router.beforeResolve((to, from, next) => {
       const matched = router.getMatchedComponents(to)
       const prevMatched = router.getMatchedComponents(from)
 
-      // nous allons uniquement nous occuper des composants qui n'ont pas déjà été rendu
-      // aussi nous allons les comparer jusqu'à ce que deux éléments concordant diffères
+      // nous allons uniquement nous occuper des composants qui n'ont pas déjà été rendus
+      // aussi nous allons les comparer jusqu'à ce que deux éléments concordants diffèrent
       let diffed = false
       const activated = matched.filter((c, i) => {
         return diffed || (diffed = (prevMatched[i] !== c))
@@ -236,7 +236,7 @@ Côté client, il y a deux différentes approches pour gérer du récapération
   })
   ```
 
-Les deux stratégies conduisent à une expérience utilisateur singulièrement différente et doivent être choisis en fonction du scénario de l'application que vous construisez. Mais indépendamment de votre choix de stratégie, la fonction `asyncData` devrait également être appelée quand la route d'un composant est de nouveau utilisée (même route, mais avec des paramètres ou une demande « query » différente comme par ex. avec `utilisateur/1` et `utilisateur/2`). Nous pouvons également réaliser ceci avec un mixin global uniquement côté client.
+Les deux stratégies conduisent à une expérience utilisateur singulièrement différente et doivent être choisies en fonction du scénario de l'application que vous construisez. Mais indépendamment de votre choix de stratégie, la fonction `asyncData` devrait également être appelée quand la route d'un composant est de nouveau utilisée (même route, mais avec des paramètres ou une demande « query » différente comme par ex. avec `utilisateur/1` et `utilisateur/2`). Nous pouvons également réaliser ceci avec un mixin global uniquement côté client.
 
 ``` js
 Vue.mixin({
@@ -256,7 +256,7 @@ Vue.mixin({
 
 ## Scission de code du Store
 
-Dans une grosse application, notre store Vuex va très probablement être scinder dans de multiples modules. Bien sur, il est aussi possible de scinder le code de ces modules en fragments correspondant aux routes. Supposons que nous ayons le module store suivant :
+Dans une grosse application, notre store Vuex va très probablement être scindé dans de multiples modules. Bien sûr, il est aussi possible de scinder le code de ces modules en fragments correspondant aux routes. Supposons que nous ayons le module store suivant :
 
 ``` js
 // store/modules/foo.js
@@ -309,8 +309,8 @@ export default {
 </script>
 ```
 
-Parce que le module est maintenant une dépendance du composant de route, il peut a présent être déplacer dans un fragment de composant de route par webpack.
+Parce que le module est maintenant une dépendance du composant de route, il peut à présent être déplacé dans un fragment de composant de route par webpack.
 
 ---
 
-Fiou, cela fait pas mal de code ! Cela est dû au fait que le pré-chargement universel est probablement le problème le plus complexe d'une application avec rendu côté serveur et nous avons posé les bases pour un développement futur plus simple. Maintenant que cette base est mise en place, modifier des composants individuellement sera en fait plutôt agréable.
+Fiou, cela fait pas mal de code ! Cela est dû au fait que le préchargement universel est probablement le problème le plus complexe d'une application avec rendu côté serveur et nous avons posé les bases pour un développement futur plus simple. Maintenant que cette base est mise en place, modifier des composants individuellement sera en fait plutôt agréable.
diff --git a/en/head.md b/en/head.md
index b578baa0..2c215ef6 100644
--- a/en/head.md
+++ b/en/head.md
@@ -11,7 +11,7 @@ Nous pouvons écrire un mixin simple pour effectuer la gestion du titre :
 
 function getTitle (vm) {
   // les composants doivent simplement fournir une option `title`
-  // pouvant être soit une chaîne de caractères soit une fonction
+  // pouvant être soit une chaine de caractères soit une fonction
   const { title } = vm.$options
   if (title) {
     return typeof title === 'function'
@@ -81,7 +81,7 @@ Et passé au moteur de rendu de paquetage dans le template :
 
 **Notes :**
 
-- Utilisez les doubles moustaches (interpolation de HTML échapé) pour éviter les attaques XSS.
+- Utilisez les doubles moustaches (interpolation de HTML échappé) pour éviter les attaques XSS.
 
 - Vous devriez fournir un titre par défaut quand vous créez l'object `context` au cas ou aucun composant de définisse de titre durant le rendu.
 
diff --git a/en/hydration.md b/en/hydration.md
index 54555261..0cf53c55 100644
--- a/en/hydration.md
+++ b/en/hydration.md
@@ -7,7 +7,7 @@ Dans `entry-client.js`, nous montons simplement l'application avec cette ligne :
 app.$mount('#app')
 ```
 
-Parceque le serveur a déjà fait le rendu des balises, nous ne voulons évidemment pas tout jeter et recréer l'intégralité des éléments du DOM. À la place, nous voulons « hydrater » les balises statiques et les rendre intéractives.
+Parce que le serveur a déjà fait le rendu des balises, nous ne voulons évidemment pas tout jeter et recréer l'intégralité des éléments du DOM. À la place, nous voulons « hydrater » les balises statiques et les rendre interactives.
 
 Si vous inspectez le rendu en sortie côté serveur, vous remarquerez que l'élément racine a un attribut spécial :
 
@@ -29,4 +29,4 @@ Une chose qu'il faut savoir est qu'en utilisant un SSR + une hydratation côté
 </table>
 ```
 
-Le navigateur va automatiquement injecter `<tbody>` dans `<table>`. Le DOM virtuel généré par Vue ne va cependant pas contenir `<tbody>`, ce qui va causer une non concordance. Pour assurer une concordance correcte, assurez-vous d'écrire du HTML valide dans vos templates.
+Le navigateur va automatiquement injecter `<tbody>` dans `<table>`. Le DOM virtuel généré par Vue ne va cependant pas contenir `<tbody>`, ce qui va causer une non-concordance. Pour assurer une concordance correcte, assurez-vous d'écrire du HTML valide dans vos templates.
diff --git a/en/routing.md b/en/routing.md
index df8fb9a2..f8d2e437 100644
--- a/en/routing.md
+++ b/en/routing.md
@@ -2,9 +2,9 @@
 
 ## Routage avec `vue-router`
 
-Vous avez sans doute remarqué que notre code serveur utilise le handler `*` qui accepte n'importe quel URL. Cela nous permet de ré-utiliser la même configuration des routes pour le client et le serveur !
+Vous avez sans doute remarqué que notre code serveur utilise le handler `*` qui accepte n'importe quel URL. Cela nous permet de réutiliser la même configuration des routes pour le client et le serveur !
 
-Il est recommandé d'utiliser le routeur officiel de Vue `vue-router`. Commençons par créer un fichier où sera créé le routeur. De manière similaire à `createApp`, nous aurons besoin d'une nouvelle instance du routeur pour chaque requêtes, donc ce fichier exporte une fonction `createRouter` :
+Il est recommandé d'utiliser le routeur officiel de Vue `vue-router`. Commençons par créer un fichier où sera créé le routeur. De manière similaire à `createApp`, nous aurons besoin d'une nouvelle instance du routeur pour chaque requête, donc ce fichier exporte une fonction `createRouter` :
 
 ``` js
 // router.js
@@ -121,7 +121,7 @@ const Foo = () => import('./Foo.vue')
 
 Cela fonctionnera dans n'importe quel scénario si vous êtes en train de faire une application Vue uniquement pour le côté client. Toutefois, il y aura certaines limitations en l'utilisant avec du SSR. Premièrement, il faut résoudre tous les composants asynchrones à l'avance sur le serveur avant de faire le rendu, car sinon il y aura juste un emplacement vide dans le code HTML. Pour le côté client, il faut aussi faire cela avant de commencer l'hydratation des données, sinon il y aurait des erreurs d'incompatibilités sur le contenu.
 
-Tout cela rend un peu compliqué l'utilisation des composants asynchrones à des endroits spécifiques dans votre application (nous allons probablement améliorer cela dans le futur). Toutefois, **cela fonctionne parfaitement si vous le faites au niveau de la route** - c.-à-d. d'utiliser les composants asynchrones dans la configuration des routes - car `vue-router` ira automatiquement résoudre les composants asynchrones nécessaires au bon fonctionnement de la route. Vous devez être sûr d'utiliser `router.onReady` sur le serveur et le client. Nous l'avons déjà fait pour le fichier d'entrée du serveur, il ne nous reste plus maintenant qu'à faire de même pour le fichier d'entrée du client :
+Tout cela rend un peu compliquée l'utilisation des composants asynchrones à des endroits spécifiques dans votre application (nous allons probablement améliorer cela dans le futur). Toutefois, **cela fonctionne parfaitement si vous le faites au niveau de la route** - c.-à-d. d'utiliser les composants asynchrones dans la configuration des routes - car `vue-router` ira automatiquement résoudre les composants asynchrones nécessaires au bon fonctionnement de la route. Vous devez être sûr d'utiliser `router.onReady` sur le serveur et le client. Nous l'avons déjà fait pour le fichier d'entrée du serveur, il ne nous reste plus maintenant qu'à faire de même pour le fichier d'entrée du client :
 
 ``` js
 // entry-client.js
diff --git a/en/streaming.md b/en/streaming.md
index 4a91254a..600b1437 100644
--- a/en/streaming.md
+++ b/en/streaming.md
@@ -31,4 +31,4 @@ En mode de rendu par flux, la donnée est émise aussitôt que possible quand le
 
 Cependant, quand le premier fragment est émis, les composants enfants peuvent ne pas avoir encore été instanciés, et les hooks de leur cycle de vie ne seront jamais appelés. Cela signifie que si des composants enfants ont besoin d'attacher leurs données dans le contexte de rendu de leurs hooks de cycle de vie, elles ne seront pas accessibles au démarrage du flux. Comme beaucoup d'informations (comme les informations d'entête ou les CSS critiques injectées) ont besoin d'être insérées avant la balise de l'application, il est nécessaire d'attendre la fin du flux avant de commencer à utiliser ces données de contexte.
 
-Il n'est donc **PAS** recommandé d'utiliser de l'envoi par flux si les données de vos contextes sont injectés dans les hooks du cycle de vie.
+Il n'est donc **PAS** recommandé d'utiliser de l'envoi par flux si les données de vos contextes sont injectées dans les hooks du cycle de vie.
diff --git a/en/structure.md b/en/structure.md
index a4ab7a64..e35dc836 100644
--- a/en/structure.md
+++ b/en/structure.md
@@ -1,6 +1,6 @@
 # Structure de code
 
-## Eviter les singletons d'état
+## Éviter les singletons d'état
 
 Lors de l'écriture du code exclusif au client, nous sommes habitués au fait que notre code sera interprété dans un nouveau contexte à chaque fois. Cependant, un serveur Node.js est un processus qui reste actif. Quand notre code est appelé dans le processus, il sera interprété une fois et restera en mémoire. Cela signifie que si vous créez un singleton, il sera partagé entre chaque nouvelle requête.
 
@@ -41,7 +41,7 @@ server.get('*', (req, res) => {
 
 La même règle s'applique aussi bien aux instances de routeur, de store ou de canal d'évènements. Au lieu de l'exporter directement depuis un module et de l'importer dans votre application, vous devez créer une nouvelle instance dans `createApp` et l'injecter depuis l'instance de Vue principale.
 
-> Cette contrainte peut être éliminée en utilisant le moteur de rendu pré-compilé (« bundle renderer ») avec `{ runInNewContext: true }`, cependant il y aura un surcoût significatif en terme de performance lié à la création d'un nouveau contexte vm pour chaque requête.
+> Cette contrainte peut être éliminée en utilisant le moteur de rendu précompilé (« bundle renderer ») avec `{ runInNewContext: true }`, cependant il y aura un surcout significatif en termes de performance lié à la création d'un nouveau contexte vm pour chaque requête.
 
 ## Introduction à l'étape de build
 
@@ -111,7 +111,7 @@ app.$mount('#app')
 
 ### `entry-server.js`:
 
-L'entrée serveur utilise un export par défaut qui est une fonction pouvant être appelée de manière répétée à chaque rendu. Pour l'instant, le code ne fait pas grand chose de plus que créer et retourner une instance de l'application. Nous pourrons y intégrer plus tard la correspondance de route côté serveur et la logique de récupération des données.
+L'entrée serveur utilise un export par défaut qui est une fonction pouvant être appelée de manière répétée à chaque rendu. Pour l'instant, le code ne fait pas grand-chose de plus que créer et retourner une instance de l'application. Nous pourrons y intégrer plus tard la correspondance de route côté serveur et la logique de récupération des données.
 
 ``` js
 import { createApp } from './app'
diff --git a/en/universal.md b/en/universal.md
index 427c8b5e..3477ce21 100644
--- a/en/universal.md
+++ b/en/universal.md
@@ -6,13 +6,13 @@ Avant d'aller plus loin, prenons un moment pour discuter des contraintes lorsque
 
 Dans une application qui tourne exclusivement côté client, chaque utilisateur utilisera une nouvelle instance de l'application dans leur navigateur. Pour le rendu serveur nous voulons le même fonctionnement : chaque requête doit disposer d'une nouvelle instance d'application isolée. Ainsi il n'y aura pas de pollution liée à du partage d'état entre requêtes.
 
-Etant donné que le processus de rendu actuel doit être déterministe, nous allons aussi « pré-charger » les données sur le serveur. Cela signifie que l'état de notre application sera déjà disponible quand nous commençons le rendu. Cela signifie également que la réactivité des données est inutile côté serveur ; elle est donc désactivée par défaut. Désactiver la réactivité des données évite aussi le coût de performance d'une conversion de données en objets réactifs.
+Étant donné que le processus de rendu actuel doit être déterministe, nous allons aussi « précharger » les données sur le serveur. Cela signifie que l'état de notre application sera déjà disponible quand nous commençons le rendu. Cela signifie également que la réactivité des données est inutile côté serveur ; elle est donc désactivée par défaut. Désactiver la réactivité des données évite aussi le cout de performance d'une conversion de données en objets réactifs.
 
 ## Hooks de cycles de vie des composants
 
 Vu qu'il n'y a pas de mises à jour dynamiques, de tous les hooks de cycles de vie, seuls `beforeCreate` et `created` seront appelés pendant le rendu côté serveur. Cela signifie que tout code présent dans d'autres hooks tels que `beforeMount` ou `mounted` sera exécuté uniquement côté client.
 
-Une autre chose a noter est que vous devriez éviter la création d'effets de bord globaux dans `beforeCreate` et `created` comme ceux, par exemple, dus aux timers avec `setInterval`. Nous pouvons mettre en place des timers seulement dans du code côté client qui seront arrêtés pendant les phases `beforeDestroy` et `destroyed`. Cependant, comme ces hooks ne sont jamais appelés pendant le SSR, les timers vont continuer de tourner éternellement. Pour éviter cela, déplacez ce type d'effet de bord dans les hooks `beforeMount` ou `mounted`.
+Une autre chose à noter est que vous devriez éviter la création d'effets de bord globaux dans `beforeCreate` et `created` comme ceux, par exemple, dus aux timers avec `setInterval`. Nous pouvons mettre en place des timers seulement dans du code côté client qui seront arrêtés pendant les phases `beforeDestroy` et `destroyed`. Cependant, comme ces hooks ne sont jamais appelés pendant le SSR, les timers vont continuer de tourner éternellement. Pour éviter cela, déplacez ce type d'effet de bord dans les hooks `beforeMount` ou `mounted`.
 
 ## Accès aux APIs spécifiques à la plateforme
 
@@ -28,6 +28,6 @@ Notez que si une bibliothèque tierce n'est pas écrite avec l'objectif d'être
 
 La plupart des directives personnalisées manipulent directement le DOM, et vont ainsi provoquer des erreurs durant le rendu côté serveur. Il y a deux façons d'éviter cela :
 
-1. Préférer l'utilisation de composants comme mécanisme d'abstraction et travailler au niveau du DOM Virtuel (par ex. en utilisant des fonctions de rendu)
+1. Préférer l'utilisation de composants comme mécanisme d'abstraction et travailler au niveau du DOM virtuel (par ex. en utilisant des fonctions de rendu)
 
-2. Si vous avez une directive personnalisée qui ne peut être facilement remplacée par des composants, vous pouvez en fournir une « version serveur » qui utilise l'option [`directives`](./api.md#directives) lors de la création du rendu serveur.
\ No newline at end of file
+2. Si vous avez une directive personnalisée qui ne peut être facilement remplacée par des composants, vous pouvez en fournir une « version serveur » qui utilise l'option [`directives`](./api.md#directives) lors de la création du rendu serveur.