From d9e589b98f1244c3e051510e66925dedd2e733d5 Mon Sep 17 00:00:00 2001
From: Bruno Lesieur <bruno.lesieur@gmail.com>
Date: Thu, 16 Mar 2017 08:51:15 +0100
Subject: [PATCH 1/6] =?UTF-8?q?D=C3=A9but=20de=20traduction=20de=20ssr.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>
---
 src/v2/guide/ssr.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/v2/guide/ssr.md b/src/v2/guide/ssr.md
index cfe70e53cf..7ed89ea2f7 100644
--- a/src/v2/guide/ssr.md
+++ b/src/v2/guide/ssr.md
@@ -1,5 +1,5 @@
 ---
-title: Server-Side Rendering
+title: Rendu côté serveur
 type: guide
 order: 24
 ---

From c90dbadb4dc4edb444752032a89a249f110f5d0a Mon Sep 17 00:00:00 2001
From: Bruno Lesieur <bruno.lesieur@gmail.com>
Date: Thu, 16 Mar 2017 18:23:14 +0100
Subject: [PATCH 2/6] Update ssr.md translation

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>
---
 src/v2/guide/ssr.md | 158 ++++++++++++++++++++++----------------------
 1 file changed, 79 insertions(+), 79 deletions(-)

diff --git a/src/v2/guide/ssr.md b/src/v2/guide/ssr.md
index 7ed89ea2f7..23b8581002 100644
--- a/src/v2/guide/ssr.md
+++ b/src/v2/guide/ssr.md
@@ -4,38 +4,38 @@ type: guide
 order: 24
 ---
 
-## Do You Need SSR?
+## Avez-vous besoin d'un rendu côté serveur ?
 
-<p class="tip">**Cette page est en cours de traduction française. Revenez une autre fois pour lire une traduction achevée ou [participez à la traduction française ici](https://github.com/vuejs-fr/vuejs.org).**</p>Before diving into SSR, let's explore what it actually does for you and when you might need it.
+Avant de plonger dans le SRR (pour *Server-side Rendering* soit Rendu côté serveur), explorons en quoi cela pourrait vous est utile et quand l'utiliser.
 
-### SEO
+### La SEO
 
-Google and Bing can index synchronous JavaScript applications just fine. _Synchronous_ being the key word there. If your app starts with a loading spinner, then fetches content via Ajax, the crawler will not wait for you to finish.
+Google et Bing peuvent parfaitement indéxer les applications JavaScript synchrones. _Synchrone_ est le mot-clé important ici. Si votre application démarre avec une animation de chargement, puis charge le contenu via des requêtes Ajax, les moteurs d'indexation n'attendrons que ces opérations soit fini.
 
-This means if you have content fetched asynchronously on pages where SEO is important, SSR might be necessary.
+Cela signifie que si vous avez du contenu qui s'affiche de manière asynchone sur des pages ou la SEO, Le SSR devient nécessaire.
 
-### Clients with a Slow Internet
+### Navigateurs avec connexion bas-débit
 
-Users might come to your site from a remote area with slow Internet - or just with a bad cell connection. In these cases, you'll want to minimize the number and size of requests necessary for users to see basic content.
+Les utilisateurs pourrait visiter votre site depuis des lieux avec une connexion Interne bas-débit – ou juste depuis une mauvaise connexion cellulaire. Dans ces cas, vous souhaitez mimimiser le nombre et la taille des requêtes nécéssaire à l'utilisateur pour afficher ce contenu minimal.
 
-You can use [Webpack's code splitting](https://webpack.js.org/guides/code-splitting-require/) to avoid forcing users to download your entire application to view a single page, but it still won't be as performant as downloading a single, pre-rendered HTML file.
+Vous pouvez utiliser l'[outil Webpack de découpe de code](https://webpack.js.org/guides/code-splitting-require/) pour ne pas forcer l'utilisateur à télécharger votre application entière pour voir une seule page, mais cela ne sera jamais aussi performant que de télécharger une seule page de contenu HTML à rendu statique.
 
-### Clients with an Old (or Simply No) JavaScript Engine
+### Navigateurs avec vieux (ou juste sans) moteur JavaScript
 
-For some demographics or areas of the world, using a computer from 1998 to access the Internet might be the only option. While Vue only works with IE9+, you may still want to deliver basic content to those on older browsers - or to hipster hackers using [Lynx](http://lynx.browser.org/) in the terminal.
+Pour plusieurs lieux autour du monde, utiliser un ordinateur avec 1998 pour accéder à Interne est encore la seule option possible. Puisque Vue ne fonctionne que pour des versions de IE9+, vous devez toujours délivrer un contenu minimal pour ses anciens navigateurs — ou pour les hackers hipsters utilisant [Lynx](http://lynx.browser.org/) depuis un terminal.
 
-### SSR vs Prerendering
+### SSR vs. Rendu statique
 
-If you're only investigating SSR to improve the SEO of a handful of marketing pages (e.g. `/`, `/about`, `/contact`, etc), then you probably want __prerendering__ instead. Rather than using a web server to compile HTML on-the-fly, prerendering simply generates static HTML files for specific routes at build time. The advantage is setting up prerendering is much simpler and allows you to keep your frontend as a fully static site.
+Si vous vous penchez sur le SSR pour améliorer la SEO d'une poignées de pages vitrines (ex. : `/`, `/about`, `/contact`, etc), alors vous voudriez probablement utiliser du __rendu statique__ à la place. Au lieu d'utiliser le serveur pour générer code HTML à la demande, le rendu statique utilise des pages générer en amont lors de la phase de *build* du site. L'avantage est que mettre en place du rendu statique est plus simple et vous permet de garder la partie frontale d'un site complètement statique.
 
-If you're using Webpack, you can easily add prerendering with the [prerender-spa-plugin](https://github.com/chrisvfritz/prerender-spa-plugin). It's been extensively tested with Vue apps - and in fact, the creator is a member of the Vue core team.
+Si vous utilisez Webpack, vous pouvez facilement générer du rendu statique avec [prerender-spa-plugin](https://github.com/chrisvfritz/prerender-spa-plugin). Il a beaucoup été testé avec des apps Vue — en fait, son créateur est un membre de l'équipe offcielle de Vue.
 
 ## Hello World
 
-If you've gotten this far, you're ready to see SSR in action. It sounds complex, but a simple node script demoing the feature requires only 3 steps:
+Si vous êtes arrivez jusqu'ici, vous êtes près pour voir le SSR en action. Ça semble complexe, mais un simple script node peut présenter la fonctionnalité en 3 étapes :
 
 ``` js
-// Step 1: Create a Vue instance
+// Étape 1: Créer une instance de Vue
 var Vue = require('vue')
 var app = new Vue({
   render: function (h) {
@@ -43,10 +43,10 @@ var app = new Vue({
   }
 })
 
-// Step 2: Create a renderer
+// Étape 2: Créer un générateur de rendu
 var renderer = require('vue-server-renderer').createRenderer()
 
-// Step 3: Render the Vue instance to HTML
+// Étape 3: Faire le rendu de l'instance de Vue en HTML
 renderer.renderToString(app, function (error, html) {
   if (error) throw error
   console.log(html)
@@ -54,26 +54,26 @@ renderer.renderToString(app, function (error, html) {
 })
 ```
 
-Not so scary, right? Of course, this example is much simpler than most applications. We don't yet have to worry about:
+Pas si effrayant, non ? Bien sûr, cette exemple est plus simple que la plupart de ceux des applications. Nous ne nous sommes pas encore préoccupé :
 
-- A Web Server
-- Response Streaming
-- Component Caching
-- A Build Process
-- Routing
-- Vuex State Hydration
+- du serveur web
+- de la réponse sous forme de flux
+- du cache du composant
+- du processus de build
+- du routage
+- de l'hydratation d'état avec Vuex
 
-In the rest of this guide, we'll walk through how to work with some of these features. Once you understand the basics, we'll then direct you to more detailed documentation and advanced examples to help you handle edge cases.
+Dans la suite de ce guide, nous allons voir comment fonctionne nombre de ces fonctionnalités. Une fois que vous serez familier avec les bases, nous vous orienterons vers de la documentation détaillé et des exemples avancés pour vous aider sur des cas plus concrets.
 
-## Simple SSR with the Express Web Server
+## SSR simple avec le serveur web Express
 
-It's kind of a stretch to call it "server-side rendering" when we don't actually have a web server, so let's fix that. We'll build a very simple SSR app, using only ES5 and without any build step or Vue plugins.
+C'est un peu simple d'appeler ça du « Server-side Rendering » quand nous n'avons pas de web serveur, alors réglons ça. Nous allons créer une application de SRR vraiment simple, en utilisant uniquement une syntaxe ES5 sans aucune étape de build ou de plugins Vue.
 
-We'll start off with an app that just tells the user how many seconds they've been on the page:
+Nous allons commencer avec une application qui va juste dire à l'utilisateur depuis combien de secondes il est sur la page :
 
 ``` js
 new Vue({
-  template: '<div>You have been here for {{ counter }} seconds.</div>',
+  template: '<div>Vous êtes ici depuis {{ counter }} seconde(s).</div>',
   data: {
     counter: 0
   },
@@ -86,26 +86,26 @@ new Vue({
 })
 ```
 
-To adapt this for SSR, there are a few modifications we'll have to make, so that it will work both in the browser and within node:
+Pour adapter ça au SSR, il y a quelques modifications à faire, cela permettra au code de fonctionner aussi bien côté navigateur que côté node :
 
-- When in the browser, add an instance of our app to the global context (i.e. `window`), so that we can mount it.
-- When in node, export a factory function so that we can create a fresh instance of the app for every request.
+- Quand chargé dans un navigateur : ajoute l'instance de l'application au contexte globale (c-à-d `window`), ainsi nous pouvons le monter.
+- Quand chargé dans node : exporte un générateur de fonction permettant de créer une nouvelle instance de Vue pour chaque requête.
 
-Accomplishing this requires a little boilerplate:
+Réaliser ces modifications demande un peu de fioritures :
 
 ``` js
 // assets/app.js
 (function () { 'use strict'
   var createApp = function () {
     // ---------------------
-    // BEGIN NORMAL APP CODE
+    // DÉBUT DU CODE STANDARD
     // ---------------------
 
     // Main Vue instance must be returned and have a root
     // node with the id "app", so that the client-side
     // version can take over once it loads.
     return new Vue({
-      template: '<div id="app">You have been here for {{ counter }} seconds.</div>',
+      template: '<div id="app">Vous êtes ici depuis {{ counter }} seconde(s).</div>',
       data: {
         counter: 0
       },
@@ -117,9 +117,9 @@ Accomplishing this requires a little boilerplate:
       }
     })
 
-    // -------------------
-    // END NORMAL APP CODE
-    // -------------------
+    // --------------------
+    // FIN DU CODE STANDARD
+    // --------------------
   }
   if (typeof module !== 'undefined' && module.exports) {
     module.exports = createApp
@@ -129,14 +129,14 @@ Accomplishing this requires a little boilerplate:
 }).call(this)
 ```
 
-Now that we have our application code, let's put together an `index.html` file:
+Maintenant que nous avons le code de notre application, mettons tout cela dans un fichier `index.html` :
 
 ``` html
 <!-- index.html -->
 <!DOCTYPE html>
 <html>
 <head>
-  <title>My Vue App</title>
+  <title>Mon application Vue</title>
   <script src="/assets/vue.js"></script>
 </head>
 <body>
@@ -147,9 +147,9 @@ Now that we have our application code, let's put together an `index.html` file:
 </html>
 ```
 
-As long as the referenced `assets` directory contains the `app.js` file we created earlier, as well as a `vue.js` file with Vue, we should now have a working single-page application!
+À supposer que le dossier `assets` contienne le fichier `app.js` créer précédemment, et que le fichier `vue.js` contiennent Vue, nous devrions avoir une application monopage fonctionnelle !
 
-Then to get it working with server-side rendering, there's just one more step - the web server:
+Maintenant, pour que cela fonctionne avec du rendu côté serveur, il y a juste une étape de plus — le serveur web :
 
 ``` js
 // server.js
@@ -158,103 +158,103 @@ Then to get it working with server-side rendering, there's just one more step -
 var fs = require('fs')
 var path = require('path')
 
-// Define global Vue for server-side app.js
+// Définir Vue de manière globale pour app.js côté serveur
 global.Vue = require('vue')
 
-// Get the HTML layout
+// Obtenir la présentation HTML
 var layout = fs.readFileSync('./index.html', 'utf8')
 
-// Create a renderer
+// Créer un générateur de rendu
 var renderer = require('vue-server-renderer').createRenderer()
 
-// Create an express server
+// Créer un serveur express
 var express = require('express')
 var server = express()
 
-// Serve files from the assets directory
+// Fournir les fichiers depuis le dossier des assets
 server.use('/assets', express.static(
   path.resolve(__dirname, 'assets')
 ))
 
-// Handle all GET requests
+// Prendre en charge toutes les requêtes GET
 server.get('*', function (request, response) {
-  // Render our Vue app to a string
+  // Faire le rendu de notre app Vue sous forme de chaîne de caractère
   renderer.renderToString(
-    // Create an app instance
+    // Créer une instance d'application
     require('./assets/app')(),
-    // Handle the rendered result
+    // Prendre en charge le rendu généré
     function (error, html) {
-      // If an error occurred while rendering...
+      // Si une erreur c'est produite pendant le rendu...
       if (error) {
-        // Log the error in the console
+        // Logguer l'erreur dans la console
         console.error(error)
-        // Tell the client something went wrong
+        // Puis dire au client que quelque chose c'est mal passé
         return response
           .status(500)
           .send('Server Error')
       }
-      // Send the layout with the rendered app's HTML
+      // Sinon envoyé la page HTML de l'application générée
       response.send(layout.replace('<div id="app"></div>', html))
     }
   )
 })
 
-// Listen on port 5000
+// Écouter sur le port 5000
 server.listen(5000, function (error) {
   if (error) throw error
-  console.log('Server is running at localhost:5000')
+  console.log('Le serveur est lancé sur localhost:5000')
 })
 ```
 
-And that's it! Here's [the full application](https://github.com/chrisvfritz/vue-ssr-demo-simple), in case you'd like to clone it and experiment further. Once you have it running locally, you can confirm that server-side rendering really is working by right-clicking on the page and selecting `View Page Source` (or similar). You should see this in the body:
+Et c'est tout ! Vous trouverez ici l'[application complète](https://github.com/chrisvfritz/vue-ssr-demo-simple), au cas ou vous souhaiteriez en faire un clone et de faire plus de tests. Une fois que vous l'aurez fait tourner dans votre environnement local, vous pourrez vérifier que le rendu côté serveur fonctionne réellement en faisant un clique droit sur la page et en sélectionnant « Afficher la source » (ou quelque chose d'équivalent). Vous devriez voir cela dans le corps de la réponse :
 
 ``` html
-<div id="app" server-rendered="true">You have been here for 0 seconds&period;</div>
+<div id="app" server-rendered="true">Vous êtes ici depuis {{ counter }} seconde(s).</div>
 ```
 
-instead of:
+au lieu de :
 
 ``` html
 <div id="app"></div>
 ```
 
-## Response Streaming
+## Réponse envoyée par flux
 
-Vue also supports rendering to a __stream__, which is preferred for web servers that support streaming. This allows HTML to be written to the response _as it's generated_, rather than all at once at the end. The result is requests are served faster, with no downsides!
+Vue supporte également le rendu sous forme de __flux__ (__stream__), ce qui est préférable pour les serveurs web supportant l'envoi par flux. Cela permet au HTML d'être écrit dans la réponse _aussitôt que généré_, au lieu de tout fournir à la fin de la réponse. Le résultat des requêtes est ainsi ré-envoyé plus vite, sans délais !
 
-To adapt our app from the previous section for streaming, we can simply replace the `server.get('*', ...)` block with the following:
+Pour adapter le code de notre précédente application pour une réponse sous forme de flux, nous pouvons simplement remplacé la structure `server.get('*', ...)` par le code suivant :
 
 ``` js
-// Split the layout into two sections of HTML
+// Fragmenter la présentation en trois parties distinctes
 var layoutSections = layout.split('<div id="app"></div>')
 var preAppHTML = layoutSections[0]
 var postAppHTML = layoutSections[1]
 
-// Handle all GET requests
+// Prendre en charge toutes les requêtes GET
 server.get('*', function (request, response) {
-  // Render our Vue app to a stream
+  // Faire le rendu de notre app Vue sous forme de chaîne de caractère
   var stream = renderer.renderToStream(require('./assets/app')())
 
-  // Write the pre-app HTML to the response
+  // Écrire la partie avant-application de notre réponse HTML
   response.write(preAppHTML)
 
-  // Whenever new chunks are rendered...
+  // Dès que le rendu d'un nouveau morceau a été fait...
   stream.on('data', function (chunk) {
-    // Write the chunk to the response
+    // Ajouter ce morceau dans la réponse
     response.write(chunk)
   })
 
-  // When all chunks are rendered...
+  // Si une erreur c'est produite pendant le rendu...
   stream.on('end', function () {
-    // Write the post-app HTML to the response
+    // Écrire la partie après-application de notre réponse HTML
     response.end(postAppHTML)
   })
 
   // If an error occurs while rendering...
   stream.on('error', function (error) {
-    // Log the error in the console
+    // Logguer l'erreur dans la console
     console.error(error)
-    // Tell the client something went wrong
+    // Puis dire au client que quelque chose c'est mal passé
     return response
       .status(500)
       .send('Server Error')
@@ -262,13 +262,13 @@ server.get('*', function (request, response) {
 })
 ```
 
-As you can see, it's not much more complicated than the previous version, even if streams may be conceptually new to you. We just:
+Comme vous pouvez le voir, ce n'est pas plus compliqué que la version précédente, même si le concepte de réponse sous forme de flux est nouveau pour vous. Nous avons juste :
 
-1. Set up the stream
-2. Write the HTML that comes before the app to the response
-3. Write the app HTML to the response as it becomes available
-4. Write the HTML that comes after the app to the response and end it
-5. Handle any errors
+1. Initialiser un flux
+2. Écrit le HTML à placer avant la réponse de l'application
+3. Écrit le HTML de l'application chaque fois que celui-ci est disponible
+4. Écrit le HTML à placer après la réponse de l'application et finir l'envoi
+5. Prendre en charge les éventuelles erreurs
 
 ## Component Caching
 

From f33367cbce29520fe702916cfe3f55b910676880 Mon Sep 17 00:00:00 2001
From: Bruno Lesieur <bruno.lesieur@gmail.com>
Date: Fri, 17 Mar 2017 16:21:41 +0100
Subject: [PATCH 3/6] Traduction de la partie restante

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>
---
 src/v2/guide/ssr.md | 58 ++++++++++++++++++++++-----------------------
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/src/v2/guide/ssr.md b/src/v2/guide/ssr.md
index 23b8581002..b93f8c53fc 100644
--- a/src/v2/guide/ssr.md
+++ b/src/v2/guide/ssr.md
@@ -10,13 +10,13 @@ Avant de plonger dans le SRR (pour *Server-side Rendering* soit Rendu côté ser
 
 ### La SEO
 
-Google et Bing peuvent parfaitement indéxer les applications JavaScript synchrones. _Synchrone_ est le mot-clé important ici. Si votre application démarre avec une animation de chargement, puis charge le contenu via des requêtes Ajax, les moteurs d'indexation n'attendrons que ces opérations soit fini.
+Google et Bing peuvent parfaitement indexer les applications JavaScript synchrones. _Synchrone_ est le mot-clé important ici. Si votre application démarre avec une animation de chargement, puis charge le contenu via des requêtes Ajax, les moteurs d'indexation n'attendrons que ces opérations soit fini.
 
-Cela signifie que si vous avez du contenu qui s'affiche de manière asynchone sur des pages ou la SEO, Le SSR devient nécessaire.
+Cela signifie que si vous avez du contenu qui s'affiche de manière asynchrone sur des pages ou la SEO, Le SSR devient nécessaire.
 
 ### Navigateurs avec connexion bas-débit
 
-Les utilisateurs pourrait visiter votre site depuis des lieux avec une connexion Interne bas-débit – ou juste depuis une mauvaise connexion cellulaire. Dans ces cas, vous souhaitez mimimiser le nombre et la taille des requêtes nécéssaire à l'utilisateur pour afficher ce contenu minimal.
+Les utilisateurs pourrait visiter votre site depuis des lieux avec une connexion Interne bas-débit – ou juste depuis une mauvaise connexion cellulaire. Dans ces cas, vous souhaitez minimiser le nombre et la taille des requêtes nécessaire à l'utilisateur pour afficher ce contenu minimal.
 
 Vous pouvez utiliser l'[outil Webpack de découpe de code](https://webpack.js.org/guides/code-splitting-require/) pour ne pas forcer l'utilisateur à télécharger votre application entière pour voir une seule page, mais cela ne sera jamais aussi performant que de télécharger une seule page de contenu HTML à rendu statique.
 
@@ -28,7 +28,7 @@ Pour plusieurs lieux autour du monde, utiliser un ordinateur avec 1998 pour acc
 
 Si vous vous penchez sur le SSR pour améliorer la SEO d'une poignées de pages vitrines (ex. : `/`, `/about`, `/contact`, etc), alors vous voudriez probablement utiliser du __rendu statique__ à la place. Au lieu d'utiliser le serveur pour générer code HTML à la demande, le rendu statique utilise des pages générer en amont lors de la phase de *build* du site. L'avantage est que mettre en place du rendu statique est plus simple et vous permet de garder la partie frontale d'un site complètement statique.
 
-Si vous utilisez Webpack, vous pouvez facilement générer du rendu statique avec [prerender-spa-plugin](https://github.com/chrisvfritz/prerender-spa-plugin). Il a beaucoup été testé avec des apps Vue — en fait, son créateur est un membre de l'équipe offcielle de Vue.
+Si vous utilisez Webpack, vous pouvez facilement générer du rendu statique avec [prerender-spa-plugin](https://github.com/chrisvfritz/prerender-spa-plugin). Il a beaucoup été testé avec des apps Vue — en fait, son créateur est un membre de l'équipe officielle de Vue.
 
 ## Hello World
 
@@ -101,9 +101,9 @@ Réaliser ces modifications demande un peu de fioritures :
     // DÉBUT DU CODE STANDARD
     // ---------------------
 
-    // Main Vue instance must be returned and have a root
-    // node with the id "app", so that the client-side
-    // version can take over once it loads.
+    // L'instance de Vue principale doit être retourné et un
+    // nœud racine avec l'id « app », ainsi la version côté client
+    // peut prendre le relais une fois chargée.
     return new Vue({
       template: '<div id="app">Vous êtes ici depuis {{ counter }} seconde(s).</div>',
       data: {
@@ -270,17 +270,17 @@ Comme vous pouvez le voir, ce n'est pas plus compliqué que la version précéde
 4. Écrit le HTML à placer après la réponse de l'application et finir l'envoi
 5. Prendre en charge les éventuelles erreurs
 
-## Component Caching
+## Mise en cache de composant
 
-Vue's SSR is very fast by default, but you can further improve performance by caching rendered components. This should be considered an advanced feature however, as caching the wrong components (or the right components with the wrong key) could lead to misrendering your app. Specifically:
+Le SSR de Vue est vraiment rapide par défaut, mais il est possible d'améliorer les performances du rendu des composants. Cela est considéré comme une fonctionnalité avancé cependant, car mettre en cache le mauvais composant (ou le bon composant avec la mauvaise clé) peut mener à de mauvais rendu d'application. Spécifiquement :
 
-<p class="tip">You should not cache a component containing child components that rely on global state (e.g. from a vuex store). If you do, those child components (and in fact, the entire sub-tree) will be cached as well. Be especially wary with components that accept slots/children.</p>
+<p class="tip">Vous ne devriez pas mettre en cache un composant contenant des composants enfants qui sont relié à l'état global (ex. : le store de vuex). Si vous le faites, ces composants enfants (et en fait, l'ensemble de leurs propre composants enfants) seront mis en cache. Soyez donc particulièrement attentif avec les composants qui accepte des slots/enfants.</p>
 
-### Setup
+### Mise en place
 
-With that warning out of the way, here's how you cache components.
+Avec cette avertissement pris en compte, voici comment faire de la mise en cache de composants.
 
-First, you'll need to provide your renderer with a [cache object](https://www.npmjs.com/package/vue-server-renderer#cache). Here's a simple example using [lru-cache](https://github.com/isaacs/node-lru-cache):
+Premièrement, vous devez fournir votre générateur de rendu avec un [objet de mise en cache](https://www.npmjs.com/package/vue-server-renderer#cache). Voici ici un simple exemple utilisant [lru-cache](https://github.com/isaacs/node-lru-cache) :
 
 ``` js
 var createRenderer = require('vue-server-renderer').createRenderer
@@ -291,14 +291,14 @@ var renderer = createRenderer({
 })
 ```
 
-That will cache up to 1000 unique renders. For other configurations that more closely align to memory usage, see [the lru-cache options](https://github.com/isaacs/node-lru-cache#options).
+Cela va mettre en cache le résultat pour les 1000 prochains rendus. Pour d'autres configurations plus proche de votre usage de la mémoire, voyez [les options de lru-cache](https://github.com/isaacs/node-lru-cache#options).
 
-Then for components you want to cache, you must provide them with:
+Maintenant pour les composants, que vous voulez mettre en cache, vous devez les fournir avec :
 
-- a unique `name`
-- a `serverCacheKey` function, returning a unique key scoped to the component
+- un `name` unique
+- une fonction `serverCacheKey`, retournant une clé unique limité à la portée du composant
 
-For example:
+Par exemple :
 
 ``` js
 Vue.component({
@@ -311,23 +311,23 @@ Vue.component({
 })
 ```
 
-### Ideal Components for Caching
+### Les composants idéales pour de la mise en cache
 
-Any "pure" component can be safely cached - that is, any component that is guaranteed to generate the same HTML given the same props. Common examples of these include:
+N'importe quel composant « pure » peut être mis en cache sans problème — c'est à dire n'importe quel composant qui assure que le HTML généré fournit toujours les mêmes props. Des exemple commun de cela sont :
 
-- Static components (i.e. they always generate the same HTML, so the `serverCacheKey` function can just return `true`)
-- List item components (when part of large lists, caching these can significantly improve performance)
-- Generic UI components (e.g. buttons, alerts, etc - at least those that accept content through props rather than slots/children)
+- Des composants statiques (c-à-d qu'il génère toujours le même HTML, aussie la fonction `serverCacheKey` à juste à retourner `true`)
+- Des composants de liste d'élément (dans de large liste, les mettre en cache peut significativement améliorer les performances)
+- Des composants d'interface utilisateur générique (c-à-d les boutons, alertes, etc — du moins ceux qui accepte leur contenu à travers les props plutôt que les slots/enfants)
 
-## Build Process, Routing, and Vuex State Hydration
+## Processus de build, routage, et hydratation d'état de Vuex
 
-By now, you should understand the fundamental concepts behind server-side rendering. However, as you introduce a build process, routing, and vuex, each introduces its own considerations.
+Maintenant, vous devriez comprendre le concept fondamental derrière le rendu côté serveur. Cependant, introduire un processus de build, du routage et vuex introduit également sont lots de considération propre.
 
-To truly master server-side rendering in complex applications, we recommend a deep dive into the following resources:
+Pour réellement maîtriser le rendu côté serveur dans des applications complexe, nous vous recommandons de plonger plus particulièrement les ressources suivantes :
 
-- [vue-server-renderer docs](https://www.npmjs.com/package/vue-server-renderer#api): more details on topics covered here, as well as documentation of more advanced topics, such as [preventing cross-request contamination](https://www.npmjs.com/package/vue-server-renderer#why-use-bundlerenderer) and [adding a separate server build](https://www.npmjs.com/package/vue-server-renderer#creating-the-server-bundle)
-- [vue-hackernews-2.0](https://github.com/vuejs/vue-hackernews-2.0): the definitive example of integrating all major Vue libraries and concepts in a single application
+- [documentations de vue-server-renderer](https://www.npmjs.com/package/vue-server-renderer#api): plus de détails sur les sujets que nous avons abordés ici, ainsi qu'une documentation de sujets plus avancés, comme [prévenir la contamination entre les requêtes](https://www.npmjs.com/package/vue-server-renderer#why-use-bundlerenderer) et [l'ajout d'un serveur de build séparé](https://www.npmjs.com/package/vue-server-renderer#creating-the-server-bundle)
+- [vue-hackernews-2.0](https://github.com/vuejs/vue-hackernews-2.0): l'exemple définitif intégrant toutes les bibliothèques et concepts majeurs de Vue dans une application unique.
 
 ## Nuxt.js
 
-Properly configuring all the discussed aspects of a production-ready server-rendered app can be a daunting task. Luckily, there is an excellent community project that aims to make all of this easier: [Nuxt.js](https://nuxtjs.org/). Nuxt.js is a higher-level framework built on top of the Vue ecosystem which provides an extremely streamlined development experience for writing universal Vue applications. Better yet, you can even use it as a static site generator (with pages authored as single-file Vue components)! We highly recommend giving it a try.
+Configurer proprement tous les aspects dont nous avons discuté pour un rendu côté serveur près à la production peut être une tâche qui incombe. Forte heureusement, il y a un excellent projet communautaire dont le but est de rendre tout cela plus simple : [Nuxt.js](https://nuxtjs.org/). Nuxt.js est un framework de haut niveau construit au dessus de l'écosystème de Vue et qui fournit une expérience de développement organisée pour écrire des applications Vue universelle. Encore mieux, vous pouvez vous en servir comme générateur de site web statique (avec des pages réalisées au format monofichier des composants Vue) ! Nous vous recommandons grandement de l'essayer.

From 8a559b3d150b63d862475adc58562a01ed6d94d3 Mon Sep 17 00:00:00 2001
From: Bruno Lesieur <bruno.lesieur@gmail.com>
Date: Sat, 18 Mar 2017 11:35:58 +0100
Subject: [PATCH 4/6] Relecture de la partie SSR

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>
---
 src/v2/guide/ssr.md | 66 ++++++++++++++++++++++-----------------------
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/src/v2/guide/ssr.md b/src/v2/guide/ssr.md
index b93f8c53fc..d7afe7aae7 100644
--- a/src/v2/guide/ssr.md
+++ b/src/v2/guide/ssr.md
@@ -6,33 +6,33 @@ order: 24
 
 ## Avez-vous besoin d'un rendu côté serveur ?
 
-Avant de plonger dans le SRR (pour *Server-side Rendering* soit Rendu côté serveur), explorons en quoi cela pourrait vous est utile et quand l'utiliser.
+Avant de plonger dans le SRR (pour *Server-side Rendering* soit Rendu côté serveur), explorons en quoi cela pourrait vous être utile et quand l'utiliser.
 
 ### La SEO
 
-Google et Bing peuvent parfaitement indexer les applications JavaScript synchrones. _Synchrone_ est le mot-clé important ici. Si votre application démarre avec une animation de chargement, puis charge le contenu via des requêtes Ajax, les moteurs d'indexation n'attendrons que ces opérations soit fini.
+Google et Bing peuvent parfaitement indexer les applications JavaScript synchrones. _Synchrone_ est le mot-clé important ici. Si votre application démarre avec une animation de chargement, puis charge le contenu via des requêtes Ajax, les moteurs d'indexation n'attendront pas que ces opérations soient finies.
 
-Cela signifie que si vous avez du contenu qui s'affiche de manière asynchrone sur des pages ou la SEO, Le SSR devient nécessaire.
+Cela signifie que si vous avez du contenu qui s'affiche de manière asynchrone sur des pages ou la SEO est importante, le SSR devient nécessaire.
 
-### Navigateurs avec connexion bas-débit
+### Clients avec une connexion bas-débit
 
-Les utilisateurs pourrait visiter votre site depuis des lieux avec une connexion Interne bas-débit – ou juste depuis une mauvaise connexion cellulaire. Dans ces cas, vous souhaitez minimiser le nombre et la taille des requêtes nécessaire à l'utilisateur pour afficher ce contenu minimal.
+Les utilisateurs pourraient visiter votre site depuis des lieux avec une connexion Internet bas-débit – ou juste depuis une mauvaise connexion cellulaire. Dans ces cas, vous souhaitez minimiser le nombre et la taille des requêtes nécessaire à l'utilisateur pour afficher ce contenu minimal.
 
-Vous pouvez utiliser l'[outil Webpack de découpe de code](https://webpack.js.org/guides/code-splitting-require/) pour ne pas forcer l'utilisateur à télécharger votre application entière pour voir une seule page, mais cela ne sera jamais aussi performant que de télécharger une seule page de contenu HTML à rendu statique.
+Vous pouvez utiliser l'[outil Webpack de découpe de code](https://webpack.js.org/guides/code-splitting-require/) pour ne pas forcer l'utilisateur à télécharger votre application entière pour voir une seule page, mais cela ne sera jamais aussi performant que de télécharger une seule page de contenu HTML au rendu statique.
 
-### Navigateurs avec vieux (ou juste sans) moteur JavaScript
+### Clients avec vieux (ou juste sans) moteur JavaScript
 
-Pour plusieurs lieux autour du monde, utiliser un ordinateur avec 1998 pour accéder à Interne est encore la seule option possible. Puisque Vue ne fonctionne que pour des versions de IE9+, vous devez toujours délivrer un contenu minimal pour ses anciens navigateurs — ou pour les hackers hipsters utilisant [Lynx](http://lynx.browser.org/) depuis un terminal.
+Il y a encore des endroits autour du monde où utiliser un ordinateur avec 1998 pour accéder à Internet est encore la seule option possible. Puisque Vue ne fonctionne que pour des versions de IE9+, vous devez toujours délivrer un contenu minimal pour ses anciens navigateurs — ou pour les hackers hipsters utilisant [Lynx](http://lynx.browser.org/) depuis un terminal.
 
 ### SSR vs. Rendu statique
 
-Si vous vous penchez sur le SSR pour améliorer la SEO d'une poignées de pages vitrines (ex. : `/`, `/about`, `/contact`, etc), alors vous voudriez probablement utiliser du __rendu statique__ à la place. Au lieu d'utiliser le serveur pour générer code HTML à la demande, le rendu statique utilise des pages générer en amont lors de la phase de *build* du site. L'avantage est que mettre en place du rendu statique est plus simple et vous permet de garder la partie frontale d'un site complètement statique.
+Si vous vous penchez sur le SSR pour améliorer la SEO d'une poignées de pages vitrines (ex. : `/`, `/about`, `/contact`, etc), alors vous voudriez probablement utiliser du __rendu statique__ à la place. Au lieu d'utiliser le serveur pour générer du code HTML à la demande, le rendu statique utilise des pages générés en amont lors de la phase de *build* du site. L'avantage est que mettre en place du rendu statique est plus simple et vous permet de garder la partie frontale d'un site complètement statique.
 
 Si vous utilisez Webpack, vous pouvez facilement générer du rendu statique avec [prerender-spa-plugin](https://github.com/chrisvfritz/prerender-spa-plugin). Il a beaucoup été testé avec des apps Vue — en fait, son créateur est un membre de l'équipe officielle de Vue.
 
 ## Hello World
 
-Si vous êtes arrivez jusqu'ici, vous êtes près pour voir le SSR en action. Ça semble complexe, mais un simple script node peut présenter la fonctionnalité en 3 étapes :
+Si vous êtes arrivez jusqu'ici, vous êtes prèt pour voir le SSR en action. Ça semble complexe, mais un simple script Node.js peut présenter la fonctionnalité en 3 étapes :
 
 ``` js
 // Étape 1: Créer une instance de Vue
@@ -54,7 +54,7 @@ renderer.renderToString(app, function (error, html) {
 })
 ```
 
-Pas si effrayant, non ? Bien sûr, cette exemple est plus simple que la plupart de ceux des applications. Nous ne nous sommes pas encore préoccupé :
+Pas si effrayant, non ? Bien sûr, cet exemple est plus simple que la plupart de ceux des applications. Nous ne nous sommes pas encore préoccupé :
 
 - du serveur web
 - de la réponse sous forme de flux
@@ -63,11 +63,11 @@ Pas si effrayant, non ? Bien sûr, cette exemple est plus simple que la plupart
 - du routage
 - de l'hydratation d'état avec Vuex
 
-Dans la suite de ce guide, nous allons voir comment fonctionne nombre de ces fonctionnalités. Une fois que vous serez familier avec les bases, nous vous orienterons vers de la documentation détaillé et des exemples avancés pour vous aider sur des cas plus concrets.
+Dans la suite de ce guide, nous allons voir comment fonctionne nombre de ces fonctionnalités. Une fois que vous serez familier avec les bases, nous vous orienterons vers de la documentation détaillée et des exemples avancés pour vous aider sur des cas plus concrets.
 
 ## SSR simple avec le serveur web Express
 
-C'est un peu simple d'appeler ça du « Server-side Rendering » quand nous n'avons pas de web serveur, alors réglons ça. Nous allons créer une application de SRR vraiment simple, en utilisant uniquement une syntaxe ES5 sans aucune étape de build ou de plugins Vue.
+C'est un peu simple d'appeler ça du « Server-side Rendering » quand nous n'avons pas de serveur web, alors réglons ça. Nous allons créer une application avec du SRR vraiment simple, en utilisant uniquement une syntaxe ES5 sans aucune étape de *build* ou de plugins Vue.
 
 Nous allons commencer avec une application qui va juste dire à l'utilisateur depuis combien de secondes il est sur la page :
 
@@ -86,10 +86,10 @@ new Vue({
 })
 ```
 
-Pour adapter ça au SSR, il y a quelques modifications à faire, cela permettra au code de fonctionner aussi bien côté navigateur que côté node :
+Pour adapter ça à du SSR, il y a quelques modifications à faire, cela permettra au code de fonctionner aussi bien côté navigateur que côté Node.js :
 
-- Quand chargé dans un navigateur : ajoute l'instance de l'application au contexte globale (c-à-d `window`), ainsi nous pouvons le monter.
-- Quand chargé dans node : exporte un générateur de fonction permettant de créer une nouvelle instance de Vue pour chaque requête.
+- Quand chargé dans un navigateur : ajout de l'instance de l'application au contexte globale (c-à-d `window`), ainsi nous pouvons faire le montage.
+- Quand chargé avec Node.js : export d'un générateur de fonction permettant de créer une nouvelle instance de Vue pour chaque requête.
 
 Réaliser ces modifications demande un peu de fioritures :
 
@@ -101,7 +101,7 @@ Réaliser ces modifications demande un peu de fioritures :
     // DÉBUT DU CODE STANDARD
     // ---------------------
 
-    // L'instance de Vue principale doit être retourné et un
+    // L'instance de Vue principale doit être retournée ainsi qu'un
     // nœud racine avec l'id « app », ainsi la version côté client
     // peut prendre le relais une fois chargée.
     return new Vue({
@@ -147,7 +147,7 @@ Maintenant que nous avons le code de notre application, mettons tout cela dans u
 </html>
 ```
 
-À supposer que le dossier `assets` contienne le fichier `app.js` créer précédemment, et que le fichier `vue.js` contiennent Vue, nous devrions avoir une application monopage fonctionnelle !
+À supposer que le dossier `assets` contienne le fichier `app.js` créer précédemment, et que le fichier `vue.js` contienne Vue, nous devrions avoir une application monopage fonctionnelle !
 
 Maintenant, pour que cela fonctionne avec du rendu côté serveur, il y a juste une étape de plus — le serveur web :
 
@@ -167,7 +167,7 @@ var layout = fs.readFileSync('./index.html', 'utf8')
 // Créer un générateur de rendu
 var renderer = require('vue-server-renderer').createRenderer()
 
-// Créer un serveur express
+// Créer un serveur Express.js
 var express = require('express')
 var server = express()
 
@@ -206,7 +206,7 @@ server.listen(5000, function (error) {
 })
 ```
 
-Et c'est tout ! Vous trouverez ici l'[application complète](https://github.com/chrisvfritz/vue-ssr-demo-simple), au cas ou vous souhaiteriez en faire un clone et de faire plus de tests. Une fois que vous l'aurez fait tourner dans votre environnement local, vous pourrez vérifier que le rendu côté serveur fonctionne réellement en faisant un clique droit sur la page et en sélectionnant « Afficher la source » (ou quelque chose d'équivalent). Vous devriez voir cela dans le corps de la réponse :
+Et c'est tout ! Vous trouverez ici l'[application complète](https://github.com/chrisvfritz/vue-ssr-demo-simple), au cas ou vous souhaiteriez en faire un clone et faire plus de tests. Une fois que vous l'aurez fait tourner dans votre environnement local, vous pourrez vérifier que le rendu côté serveur fonctionne réellement en faisant un clique droit sur la page et en sélectionnant « Afficher la source » (ou quelque chose d'équivalent). Vous devriez voir cela dans le corps de la réponse :
 
 ``` html
 <div id="app" server-rendered="true">Vous êtes ici depuis {{ counter }} seconde(s).</div>
@@ -220,9 +220,9 @@ au lieu de :
 
 ## Réponse envoyée par flux
 
-Vue supporte également le rendu sous forme de __flux__ (__stream__), ce qui est préférable pour les serveurs web supportant l'envoi par flux. Cela permet au HTML d'être écrit dans la réponse _aussitôt que généré_, au lieu de tout fournir à la fin de la réponse. Le résultat des requêtes est ainsi ré-envoyé plus vite, sans délais !
+Vue supporte également le rendu sous forme de __flux__ (__stream__), ce qui est préférable pour les serveurs web supportant l'envoi par flux. Cela permet au HTML d'être écrit dans la réponse _aussitôt que générée_, au lieu de tout fournir à la fin de la réponse. Le résultat des requêtes est ainsi ré-envoyé plus vite, sans délais !
 
-Pour adapter le code de notre précédente application pour une réponse sous forme de flux, nous pouvons simplement remplacé la structure `server.get('*', ...)` par le code suivant :
+Pour adapter le code de notre précédente application pour une réponse sous forme de flux, nous pouvons simplement remplacer la structure `server.get('*', ...)` par le code suivant :
 
 ``` js
 // Fragmenter la présentation en trois parties distinctes
@@ -244,13 +244,13 @@ server.get('*', function (request, response) {
     response.write(chunk)
   })
 
-  // Si une erreur c'est produite pendant le rendu...
+  // Quand le rendu de tous les morceaux a été fait...
   stream.on('end', function () {
     // Écrire la partie après-application de notre réponse HTML
     response.end(postAppHTML)
   })
 
-  // If an error occurs while rendering...
+  // Si une erreur c'est produite pendant le rendu...
   stream.on('error', function (error) {
     // Logguer l'erreur dans la console
     console.error(error)
@@ -264,15 +264,15 @@ server.get('*', function (request, response) {
 
 Comme vous pouvez le voir, ce n'est pas plus compliqué que la version précédente, même si le concepte de réponse sous forme de flux est nouveau pour vous. Nous avons juste :
 
-1. Initialiser un flux
+1. Initialisé un flux
 2. Écrit le HTML à placer avant la réponse de l'application
 3. Écrit le HTML de l'application chaque fois que celui-ci est disponible
-4. Écrit le HTML à placer après la réponse de l'application et finir l'envoi
+4. Écrit le HTML à placer après la réponse de l'application et fini l'envoi
 5. Prendre en charge les éventuelles erreurs
 
 ## Mise en cache de composant
 
-Le SSR de Vue est vraiment rapide par défaut, mais il est possible d'améliorer les performances du rendu des composants. Cela est considéré comme une fonctionnalité avancé cependant, car mettre en cache le mauvais composant (ou le bon composant avec la mauvaise clé) peut mener à de mauvais rendu d'application. Spécifiquement :
+Le SSR de Vue est vraiment rapide par défaut, mais il est possible d'améliorer les performances du rendu des composants. Cela est considéré comme une fonctionnalité avancée cependant, car mettre en cache le mauvais composant (ou le bon composant avec la mauvaise clé) peut mener à de mauvais rendu d'application. Spécifiquement :
 
 <p class="tip">Vous ne devriez pas mettre en cache un composant contenant des composants enfants qui sont relié à l'état global (ex. : le store de vuex). Si vous le faites, ces composants enfants (et en fait, l'ensemble de leurs propre composants enfants) seront mis en cache. Soyez donc particulièrement attentif avec les composants qui accepte des slots/enfants.</p>
 
@@ -296,7 +296,7 @@ Cela va mettre en cache le résultat pour les 1000 prochains rendus. Pour d'autr
 Maintenant pour les composants, que vous voulez mettre en cache, vous devez les fournir avec :
 
 - un `name` unique
-- une fonction `serverCacheKey`, retournant une clé unique limité à la portée du composant
+- une fonction `serverCacheKey`, retournant une clé unique limitée à la portée du composant
 
 Par exemple :
 
@@ -313,19 +313,19 @@ Vue.component({
 
 ### Les composants idéales pour de la mise en cache
 
-N'importe quel composant « pure » peut être mis en cache sans problème — c'est à dire n'importe quel composant qui assure que le HTML généré fournit toujours les mêmes props. Des exemple commun de cela sont :
+N'importe quel composant « pure » peut être mis en cache sans problème — c'est à dire n'importe quel composant qui assure que le HTML généré fournit toujours les mêmes props. Des exemples commun de cela sont :
 
-- Des composants statiques (c-à-d qu'il génère toujours le même HTML, aussie la fonction `serverCacheKey` à juste à retourner `true`)
+- Des composants statiques (c-à-d qu'il génère toujours le même HTML, aussi la fonction `serverCacheKey` à juste à retourner `true`)
 - Des composants de liste d'élément (dans de large liste, les mettre en cache peut significativement améliorer les performances)
 - Des composants d'interface utilisateur générique (c-à-d les boutons, alertes, etc — du moins ceux qui accepte leur contenu à travers les props plutôt que les slots/enfants)
 
 ## Processus de build, routage, et hydratation d'état de Vuex
 
-Maintenant, vous devriez comprendre le concept fondamental derrière le rendu côté serveur. Cependant, introduire un processus de build, du routage et vuex introduit également sont lots de considération propre.
+Maintenant, vous devriez comprendre le concept fondamental derrière le rendu côté serveur. Cependant, introduire un processus de build, du routage et vuex introduit également son lot de considérations propres.
 
-Pour réellement maîtriser le rendu côté serveur dans des applications complexe, nous vous recommandons de plonger plus particulièrement les ressources suivantes :
+Pour réellement maîtriser le rendu côté serveur dans des applications complexes, nous vous recommandons de vous intéresser plus particulièrement aux ressources suivantes :
 
-- [documentations de vue-server-renderer](https://www.npmjs.com/package/vue-server-renderer#api): plus de détails sur les sujets que nous avons abordés ici, ainsi qu'une documentation de sujets plus avancés, comme [prévenir la contamination entre les requêtes](https://www.npmjs.com/package/vue-server-renderer#why-use-bundlerenderer) et [l'ajout d'un serveur de build séparé](https://www.npmjs.com/package/vue-server-renderer#creating-the-server-bundle)
+- [documentations de vue-server-renderer](https://www.npmjs.com/package/vue-server-renderer#api) : plus de détails sur les sujets que nous avons abordés ici, ainsi qu'une documentation de sujets plus avancés, comme [prévenir la contamination entre les requêtes](https://www.npmjs.com/package/vue-server-renderer#why-use-bundlerenderer) et [l'ajout d'un serveur de build séparé](https://www.npmjs.com/package/vue-server-renderer#creating-the-server-bundle)
 - [vue-hackernews-2.0](https://github.com/vuejs/vue-hackernews-2.0): l'exemple définitif intégrant toutes les bibliothèques et concepts majeurs de Vue dans une application unique.
 
 ## Nuxt.js

From cb648087b3f5f1cbad0f57885d55360310d7aed4 Mon Sep 17 00:00:00 2001
From: Bruno Lesieur <bruno.lesieur@gmail.com>
Date: Mon, 27 Mar 2017 14:51:29 +0200
Subject: [PATCH 5/6] =?UTF-8?q?Impl=C3=A9mentations=20des=20corrections=20?=
 =?UTF-8?q?et=20proposition=20de=20sylvain?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>
---
 src/v2/guide/ssr.md | 136 ++++++++++++++++++++++----------------------
 1 file changed, 68 insertions(+), 68 deletions(-)

diff --git a/src/v2/guide/ssr.md b/src/v2/guide/ssr.md
index d7afe7aae7..de7c9f3fa9 100644
--- a/src/v2/guide/ssr.md
+++ b/src/v2/guide/ssr.md
@@ -6,33 +6,33 @@ order: 24
 
 ## Avez-vous besoin d'un rendu côté serveur ?
 
-Avant de plonger dans le SRR (pour *Server-side Rendering* soit Rendu côté serveur), explorons en quoi cela pourrait vous être utile et quand l'utiliser.
+Avant de plonger dans le SRR (pour *Server-side Rendering* soit « Rendu côté serveur »), explorons en quoi cela pourrait vous être utile et quand l'utiliser.
 
 ### La SEO
 
 Google et Bing peuvent parfaitement indexer les applications JavaScript synchrones. _Synchrone_ est le mot-clé important ici. Si votre application démarre avec une animation de chargement, puis charge le contenu via des requêtes Ajax, les moteurs d'indexation n'attendront pas que ces opérations soient finies.
 
-Cela signifie que si vous avez du contenu qui s'affiche de manière asynchrone sur des pages ou la SEO est importante, le SSR devient nécessaire.
+Cela signifie que si vous avez du contenu qui s'affiche de manière asynchrone sur des pages où la SEO (pour *Search Engine Optimization* soit « Optimisation pour les moteurs de recherche ») est importante, le SSR devient nécessaire.
 
 ### Clients avec une connexion bas-débit
 
-Les utilisateurs pourraient visiter votre site depuis des lieux avec une connexion Internet bas-débit – ou juste depuis une mauvaise connexion cellulaire. Dans ces cas, vous souhaitez minimiser le nombre et la taille des requêtes nécessaire à l'utilisateur pour afficher ce contenu minimal.
+Les utilisateurs pourraient visiter votre site depuis des lieux avec une connexion Internet bas-débit – ou juste depuis une mauvaise connexion cellulaire. Dans ces cas, vous souhaitez minimiser le nombre et la taille des requêtes nécessaires à l'utilisateur pour voir le contenu de base.
 
-Vous pouvez utiliser l'[outil Webpack de découpe de code](https://webpack.js.org/guides/code-splitting-require/) pour ne pas forcer l'utilisateur à télécharger votre application entière pour voir une seule page, mais cela ne sera jamais aussi performant que de télécharger une seule page de contenu HTML au rendu statique.
+Vous pouvez utiliser l'[outil Webpack de *code splitting*](https://webpack.js.org/guides/code-splitting-require/) pour ne pas forcer l'utilisateur à télécharger votre application entière pour voir une seule page, mais cela ne sera jamais aussi performant que de télécharger une seule page HTML pré-rendue.
 
-### Clients avec vieux (ou juste sans) moteur JavaScript
+### Clients avec un vieux (ou juste sans) moteur JavaScript
 
-Il y a encore des endroits autour du monde où utiliser un ordinateur avec 1998 pour accéder à Internet est encore la seule option possible. Puisque Vue ne fonctionne que pour des versions de IE9+, vous devez toujours délivrer un contenu minimal pour ses anciens navigateurs — ou pour les hackers hipsters utilisant [Lynx](http://lynx.browser.org/) depuis un terminal.
+Pour certaines populations ou endroits du monde, utiliser un ordinateur de 1998 pour accéder à Internet pourrait être la seule option. Puisque Vue ne fonctionne qu'avec IE9+, vous pourriez vouloir délivrer un contenu de base à ceux sur des anciens navigateurs — ou pour les hackers hipsters utilisant [Lynx](http://lynx.browser.org/) depuis un terminal.
 
-### SSR vs. Rendu statique
+### SSR vs. Pré-rendu
 
-Si vous vous penchez sur le SSR pour améliorer la SEO d'une poignées de pages vitrines (ex. : `/`, `/about`, `/contact`, etc), alors vous voudriez probablement utiliser du __rendu statique__ à la place. Au lieu d'utiliser le serveur pour générer du code HTML à la demande, le rendu statique utilise des pages générés en amont lors de la phase de *build* du site. L'avantage est que mettre en place du rendu statique est plus simple et vous permet de garder la partie frontale d'un site complètement statique.
+Si vous étudiez le SSR uniquement pour améliorer la SEO d'une poignée de pages vitrines (ex. : `/`, `/about`, `/contact`, etc), alors vous voudriez probablement utiliser du __pré-rendu__ à la place. Au lieu d'utiliser un serveur web pour compiler le HTML à la volée, le pré-rendu génère simplement des fichiers HTML statiques pour des routes spécifiques lors de la phase de *build*. L'avantage est que mettre en place le pré-rendu est beaucoup plus simple et vous permet de garder la partie frontale d'un site complètement statique.
 
-Si vous utilisez Webpack, vous pouvez facilement générer du rendu statique avec [prerender-spa-plugin](https://github.com/chrisvfritz/prerender-spa-plugin). Il a beaucoup été testé avec des apps Vue — en fait, son créateur est un membre de l'équipe officielle de Vue.
+Si vous utilisez Webpack, vous pouvez facilement ajouter le pré-rendu avec le plugin [prerender-spa-plugin](https://github.com/chrisvfritz/prerender-spa-plugin). Il a beaucoup été testé avec des applications Vue — en fait, son créateur est un membre de l'équipe du coeur de Vue.
 
 ## Hello World
 
-Si vous êtes arrivez jusqu'ici, vous êtes prèt pour voir le SSR en action. Ça semble complexe, mais un simple script Node.js peut présenter la fonctionnalité en 3 étapes :
+Si vous êtes arrivé jusqu'ici, vous êtes prêt pour voir le SSR en action. Cela semble complexe, mais un simple script Node.js peut présenter la fonctionnalité en seulement 3 étapes :
 
 ``` js
 // Étape 1: Créer une instance de Vue
@@ -43,7 +43,7 @@ var app = new Vue({
   }
 })
 
-// Étape 2: Créer un générateur de rendu
+// Étape 2: Créer un moteur de rendu
 var renderer = require('vue-server-renderer').createRenderer()
 
 // Étape 3: Faire le rendu de l'instance de Vue en HTML
@@ -54,20 +54,20 @@ renderer.renderToString(app, function (error, html) {
 })
 ```
 
-Pas si effrayant, non ? Bien sûr, cet exemple est plus simple que la plupart de ceux des applications. Nous ne nous sommes pas encore préoccupé :
+Pas si effrayant, non ? Bien sûr, cet exemple est plus simple que pour la plupart des applications. Nous n'avons pas encore à nous préoccuper de :
 
 - du serveur web
-- de la réponse sous forme de flux
-- du cache du composant
+- de la réponse streamée
+- de la mise en cache des composants
 - du processus de build
 - du routage
 - de l'hydratation d'état avec Vuex
 
-Dans la suite de ce guide, nous allons voir comment fonctionne nombre de ces fonctionnalités. Une fois que vous serez familier avec les bases, nous vous orienterons vers de la documentation détaillée et des exemples avancés pour vous aider sur des cas plus concrets.
+Dans la suite de ce guide, nous allons voir comment travailler avec certaines de ces fonctionnalités. Une fois que vous comprendrez les bases, nous vous orienterons vers de la documentation plus détaillée et des exemples avancés pour vous aider à gérer les cas particuliers.
 
 ## SSR simple avec le serveur web Express
 
-C'est un peu simple d'appeler ça du « Server-side Rendering » quand nous n'avons pas de serveur web, alors réglons ça. Nous allons créer une application avec du SRR vraiment simple, en utilisant uniquement une syntaxe ES5 sans aucune étape de *build* ou de plugins Vue.
+C'est un peu abuser que d'appeler ça du « Server-side Rendering » quand nous n'avons pas de serveur web, alors réglons ça. Nous allons créer une application très simple avec du SSR, en utilisant uniquement une syntaxe ES5 sans aucune étape de *build* ou plugin Vue.
 
 Nous allons commencer avec une application qui va juste dire à l'utilisateur depuis combien de secondes il est sur la page :
 
@@ -86,24 +86,24 @@ new Vue({
 })
 ```
 
-Pour adapter ça à du SSR, il y a quelques modifications à faire, cela permettra au code de fonctionner aussi bien côté navigateur que côté Node.js :
+Pour adapter ça au SSR, il y a quelques modifications à faire, afin que cela fonctionne aussi bien dans le navigateur qu'avec Node.js :
 
-- Quand chargé dans un navigateur : ajout de l'instance de l'application au contexte globale (c-à-d `window`), ainsi nous pouvons faire le montage.
-- Quand chargé avec Node.js : export d'un générateur de fonction permettant de créer une nouvelle instance de Vue pour chaque requête.
+- Quand chargé dans un navigateur, ajouter une instance de notre application au contexte global (c-à-d `window`), afin que nous puissions faire le montage.
+- Quand chargé avec Node.js, exporter une fonction de fabrique afin que nous puissions créer une nouvelle instance de Vue pour chaque requête.
 
-Réaliser ces modifications demande un peu de fioritures :
+Réaliser ces modifications nécessite une petite base de code :
 
 ``` js
 // assets/app.js
 (function () { 'use strict'
   var createApp = function () {
-    // ---------------------
-    // DÉBUT DU CODE STANDARD
-    // ---------------------
+    // -------------------------------
+    // DEBUT DU CODE NORMAL DE L'APPLI
+    // -------------------------------
 
-    // L'instance de Vue principale doit être retournée ainsi qu'un
-    // nœud racine avec l'id « app », ainsi la version côté client
-    // peut prendre le relais une fois chargée.
+    // L'instance de Vue principale doit être retournée et avoir
+    // un nœud racine avec l'id « app », afin que la version côté
+    // client puisse prendre le relais.
     return new Vue({
       template: '<div id="app">Vous êtes ici depuis {{ counter }} seconde(s).</div>',
       data: {
@@ -117,9 +117,9 @@ Réaliser ces modifications demande un peu de fioritures :
       }
     })
 
-    // --------------------
-    // FIN DU CODE STANDARD
-    // --------------------
+    // -----------------------------
+    // FIN DU CODE NORMAL DE L'APPLI
+    // -----------------------------
   }
   if (typeof module !== 'undefined' && module.exports) {
     module.exports = createApp
@@ -147,9 +147,9 @@ Maintenant que nous avons le code de notre application, mettons tout cela dans u
 </html>
 ```
 
-À supposer que le dossier `assets` contienne le fichier `app.js` créer précédemment, et que le fichier `vue.js` contienne Vue, nous devrions avoir une application monopage fonctionnelle !
+Tant que le répertoire `assets` mentionné contient le fichier `app.js` créé précédemment, ainsi qu'un fichier `vue.js` avec Vue, nous devrions avoir une application monopage fonctionnelle !
 
-Maintenant, pour que cela fonctionne avec du rendu côté serveur, il y a juste une étape de plus — le serveur web :
+Ensuite, pour le faire fonctionner avec du rendu côté serveur, il y a juste une étape de plus — le serveur web :
 
 ``` js
 // server.js
@@ -161,10 +161,10 @@ var path = require('path')
 // Définir Vue de manière globale pour app.js côté serveur
 global.Vue = require('vue')
 
-// Obtenir la présentation HTML
+// Récupérer la présentation HTML
 var layout = fs.readFileSync('./index.html', 'utf8')
 
-// Créer un générateur de rendu
+// Créer un moteur de rendu
 var renderer = require('vue-server-renderer').createRenderer()
 
 // Créer un serveur Express.js
@@ -178,22 +178,22 @@ server.use('/assets', express.static(
 
 // Prendre en charge toutes les requêtes GET
 server.get('*', function (request, response) {
-  // Faire le rendu de notre app Vue sous forme de chaîne de caractère
+  // Faire le rendu de notre application Vue sous forme de chaîne de caractères
   renderer.renderToString(
     // Créer une instance d'application
     require('./assets/app')(),
     // Prendre en charge le rendu généré
     function (error, html) {
-      // Si une erreur c'est produite pendant le rendu...
+      // Si une erreur s'est produite pendant le rendu...
       if (error) {
-        // Logguer l'erreur dans la console
+        // Loguer l'erreur dans la console
         console.error(error)
-        // Puis dire au client que quelque chose c'est mal passé
+        // Puis dire au client que quelque-chose s'est mal passé
         return response
           .status(500)
           .send('Server Error')
       }
-      // Sinon envoyé la page HTML de l'application générée
+      // Sinon envoyer la page HTML de l'application générée
       response.send(layout.replace('<div id="app"></div>', html))
     }
   )
@@ -206,7 +206,7 @@ server.listen(5000, function (error) {
 })
 ```
 
-Et c'est tout ! Vous trouverez ici l'[application complète](https://github.com/chrisvfritz/vue-ssr-demo-simple), au cas ou vous souhaiteriez en faire un clone et faire plus de tests. Une fois que vous l'aurez fait tourner dans votre environnement local, vous pourrez vérifier que le rendu côté serveur fonctionne réellement en faisant un clique droit sur la page et en sélectionnant « Afficher la source » (ou quelque chose d'équivalent). Vous devriez voir cela dans le corps de la réponse :
+Et c'est tout ! Vous trouverez ici l'[application complète](https://github.com/chrisvfritz/vue-ssr-demo-simple), au cas ou vous souhaiteriez en faire un clone et faire plus de tests. Une fois que vous l'aurez fait tourner dans votre environnement local, vous pourrez vérifier que le rendu côté serveur fonctionne en faisant un clic droit sur la page et en sélectionnant « Afficher la source » (ou quelque chose d'équivalent). Vous devriez voir cela dans le corps de la réponse :
 
 ``` html
 <div id="app" server-rendered="true">Vous êtes ici depuis {{ counter }} seconde(s).</div>
@@ -218,43 +218,43 @@ au lieu de :
 <div id="app"></div>
 ```
 
-## Réponse envoyée par flux
+## Réponse streamée
 
-Vue supporte également le rendu sous forme de __flux__ (__stream__), ce qui est préférable pour les serveurs web supportant l'envoi par flux. Cela permet au HTML d'être écrit dans la réponse _aussitôt que générée_, au lieu de tout fournir à la fin de la réponse. Le résultat des requêtes est ainsi ré-envoyé plus vite, sans délais !
+Vue supporte également le rendu sous forme de __flux__ (__stream__), ce qui est préférable pour les serveurs web supportant l'envoi par flux. Cela permet au HTML d'être écrit dans la réponse _dès qu'il est généré_, au lieu de tout fournir à la fin de la réponse. Le résultat est que les requêtes sont servies plus rapidement, sans inconvénients !
 
-Pour adapter le code de notre précédente application pour une réponse sous forme de flux, nous pouvons simplement remplacer la structure `server.get('*', ...)` par le code suivant :
+Pour streamer notre application de la section précédente, nous pouvons simplement remplacer la structure `server.get('*', ...)` par le code suivant :
 
 ``` js
-// Fragmenter la présentation en trois parties distinctes
+// Séparer la présentation en trois parties distinctes
 var layoutSections = layout.split('<div id="app"></div>')
 var preAppHTML = layoutSections[0]
 var postAppHTML = layoutSections[1]
 
 // Prendre en charge toutes les requêtes GET
 server.get('*', function (request, response) {
-  // Faire le rendu de notre app Vue sous forme de chaîne de caractère
+  // Faire le rendu de notre app Vue sous forme de chaîne de caractères
   var stream = renderer.renderToStream(require('./assets/app')())
 
-  // Écrire la partie avant-application de notre réponse HTML
+  // Écrire le HTML pré-applicatif dans la réponse
   response.write(preAppHTML)
 
-  // Dès que le rendu d'un nouveau morceau a été fait...
+  // À chaque fois que de nouveaux fragments ont été rendus...
   stream.on('data', function (chunk) {
-    // Ajouter ce morceau dans la réponse
+    // Ajouter ce fragment dans la réponse
     response.write(chunk)
   })
 
   // Quand le rendu de tous les morceaux a été fait...
   stream.on('end', function () {
-    // Écrire la partie après-application de notre réponse HTML
+    // Écrire le HTML post-applicatif dans la réponse
     response.end(postAppHTML)
   })
 
-  // Si une erreur c'est produite pendant le rendu...
+  // Si une erreur s'est produite pendant le rendu...
   stream.on('error', function (error) {
-    // Logguer l'erreur dans la console
+    // Loguer l'erreur dans la console
     console.error(error)
-    // Puis dire au client que quelque chose c'est mal passé
+    // Puis dire au client que quelque-chose s'est mal passé
     return response
       .status(500)
       .send('Server Error')
@@ -262,25 +262,25 @@ server.get('*', function (request, response) {
 })
 ```
 
-Comme vous pouvez le voir, ce n'est pas plus compliqué que la version précédente, même si le concepte de réponse sous forme de flux est nouveau pour vous. Nous avons juste :
+Comme vous pouvez le voir, ce n'est pas plus compliqué que la version précédente, même si le concept de streams puisse être nouveau pour vous. Nous avons juste :
 
 1. Initialisé un flux
 2. Écrit le HTML à placer avant la réponse de l'application
 3. Écrit le HTML de l'application chaque fois que celui-ci est disponible
 4. Écrit le HTML à placer après la réponse de l'application et fini l'envoi
-5. Prendre en charge les éventuelles erreurs
+5. Pris en charge des éventuelles erreurs
 
 ## Mise en cache de composant
 
-Le SSR de Vue est vraiment rapide par défaut, mais il est possible d'améliorer les performances du rendu des composants. Cela est considéré comme une fonctionnalité avancée cependant, car mettre en cache le mauvais composant (ou le bon composant avec la mauvaise clé) peut mener à de mauvais rendu d'application. Spécifiquement :
+Le SSR de Vue est très rapide par défaut, mais vous pouvez encore améliorer la performance en mettant en cache les composants après rendu. Cela peut être considéré comme une fonctionnalité avancée cependant, car mettre en cache le mauvais composant (ou le bon composant avec la mauvaise clé) peut amener à des erreurs de rendu de votre application. En particulier :
 
-<p class="tip">Vous ne devriez pas mettre en cache un composant contenant des composants enfants qui sont relié à l'état global (ex. : le store de vuex). Si vous le faites, ces composants enfants (et en fait, l'ensemble de leurs propre composants enfants) seront mis en cache. Soyez donc particulièrement attentif avec les composants qui accepte des slots/enfants.</p>
+<p class="tip">Vous ne devriez pas mettre en cache un composant contenant des composants enfants qui dépendent de l'état global (ex. : un store vuex). Si vous le faites, ces composants enfants (et en fait, toute l'arborescence sous-jacente) sera également mise en cache. Soyez donc particulièrement attentif avec les composants qui acceptent des slots/enfants.</p>
 
 ### Mise en place
 
-Avec cette avertissement pris en compte, voici comment faire de la mise en cache de composants.
+Avec cet avertissement pris en compte, voici comment vous mettez en cache des composants.
 
-Premièrement, vous devez fournir votre générateur de rendu avec un [objet de mise en cache](https://www.npmjs.com/package/vue-server-renderer#cache). Voici ici un simple exemple utilisant [lru-cache](https://github.com/isaacs/node-lru-cache) :
+Premièrement, vous devez fournir votre moteur de rendu avec un [objet de cache](https://www.npmjs.com/package/vue-server-renderer#cache). Voici un simple exemple utilisant [lru-cache](https://github.com/isaacs/node-lru-cache) :
 
 ``` js
 var createRenderer = require('vue-server-renderer').createRenderer
@@ -291,9 +291,9 @@ var renderer = createRenderer({
 })
 ```
 
-Cela va mettre en cache le résultat pour les 1000 prochains rendus. Pour d'autres configurations plus proche de votre usage de la mémoire, voyez [les options de lru-cache](https://github.com/isaacs/node-lru-cache#options).
+Cela va mettre en cache jusqu'à 1000 rendus uniques. Pour d'autres configurations s'alignant au plus proche avec l'utilisation de la mémoire, voyez [les options de lru-cache](https://github.com/isaacs/node-lru-cache#options).
 
-Maintenant pour les composants, que vous voulez mettre en cache, vous devez les fournir avec :
+Ensuite, pour les composants que vous voulez mettre en cache, vous devez leur fournir :
 
 - un `name` unique
 - une fonction `serverCacheKey`, retournant une clé unique limitée à la portée du composant
@@ -311,23 +311,23 @@ Vue.component({
 })
 ```
 
-### Les composants idéales pour de la mise en cache
+### Les composants idéaux pour de la mise en cache
 
-N'importe quel composant « pure » peut être mis en cache sans problème — c'est à dire n'importe quel composant qui assure que le HTML généré fournit toujours les mêmes props. Des exemples commun de cela sont :
+N'importe quel composant « pur » peut être mis en cache sans problème — c'est-à-dire n'importe quel composant qui garantit de générer le même HTML avec les mêmes props données. Des exemples classiques de ce type de composants :
 
-- Des composants statiques (c-à-d qu'il génère toujours le même HTML, aussi la fonction `serverCacheKey` à juste à retourner `true`)
-- Des composants de liste d'élément (dans de large liste, les mettre en cache peut significativement améliorer les performances)
-- Des composants d'interface utilisateur générique (c-à-d les boutons, alertes, etc — du moins ceux qui accepte leur contenu à travers les props plutôt que les slots/enfants)
+- Des composants statiques (c-à-d. qui génèrent toujours le même HTML, et donc la fonction `serverCacheKey` peut toujours retourner `true`)
+- Des composants d'éléments de liste (dans de longues listes, les mettre en cache peut significativement améliorer les performances)
+- Des composants génériques d'interface utilisateur (c-à-d les boutons, alertes, etc. — du moins ceux qui acceptent du contenu via les props plutôt que les slots/enfants)
 
 ## Processus de build, routage, et hydratation d'état de Vuex
 
-Maintenant, vous devriez comprendre le concept fondamental derrière le rendu côté serveur. Cependant, introduire un processus de build, du routage et vuex introduit également son lot de considérations propres.
+À présent, vous devriez comprendre les concepts fondamentaux derrière le rendu côté serveur. Cependant, à mesure que vous introduisez un processus de *build*, du routage ou vuex, cela introduit son propre lot de considérations.
 
 Pour réellement maîtriser le rendu côté serveur dans des applications complexes, nous vous recommandons de vous intéresser plus particulièrement aux ressources suivantes :
 
-- [documentations de vue-server-renderer](https://www.npmjs.com/package/vue-server-renderer#api) : plus de détails sur les sujets que nous avons abordés ici, ainsi qu'une documentation de sujets plus avancés, comme [prévenir la contamination entre les requêtes](https://www.npmjs.com/package/vue-server-renderer#why-use-bundlerenderer) et [l'ajout d'un serveur de build séparé](https://www.npmjs.com/package/vue-server-renderer#creating-the-server-bundle)
-- [vue-hackernews-2.0](https://github.com/vuejs/vue-hackernews-2.0): l'exemple définitif intégrant toutes les bibliothèques et concepts majeurs de Vue dans une application unique.
+- [Documentation de vue-server-renderer](https://www.npmjs.com/package/vue-server-renderer#api) : plus de détails sur les sujets que nous avons abordés ici, ainsi qu'une documentation sur les sujets plus avancés, comme [empêcher la contamination entre les requêtes](https://www.npmjs.com/package/vue-server-renderer#why-use-bundlerenderer) et [ajouter un serveur de build séparé](https://www.npmjs.com/package/vue-server-renderer#creating-the-server-bundle)
+- [vue-hackernews-2.0](https://github.com/vuejs/vue-hackernews-2.0): l'exemple final intégrant toutes les bibliothèques et concepts majeurs de Vue dans une seule application.
 
 ## Nuxt.js
 
-Configurer proprement tous les aspects dont nous avons discuté pour un rendu côté serveur près à la production peut être une tâche qui incombe. Forte heureusement, il y a un excellent projet communautaire dont le but est de rendre tout cela plus simple : [Nuxt.js](https://nuxtjs.org/). Nuxt.js est un framework de haut niveau construit au dessus de l'écosystème de Vue et qui fournit une expérience de développement organisée pour écrire des applications Vue universelle. Encore mieux, vous pouvez vous en servir comme générateur de site web statique (avec des pages réalisées au format monofichier des composants Vue) ! Nous vous recommandons grandement de l'essayer.
+Configurer proprement tous les aspects dont nous avons discuté pour un rendu côté serveur près à la production peut être intimidant. Fort heureusement, il y a un excellent projet communautaire dont le but est de rendre tout cela plus simple : [Nuxt.js](https://nuxtjs.org/). Nuxt.js est un framework de haut niveau construit par-dessus l'écosystème de Vue et qui fournit une expérience de développement toute tracée pour écrire des applications Vue universelle. Encore mieux, vous pouvez vous en servir comme générateur de sites web statiques (avec des pages écrites comme composants Vue monofichiers) ! Nous vous recommandons grandement de l'essayer.

From 914f20295b99d0e52b8112e1ffbf2c5aca4ea387 Mon Sep 17 00:00:00 2001
From: Bruno Lesieur <bruno.lesieur@gmail.com>
Date: Fri, 7 Apr 2017 15:05:02 +0200
Subject: [PATCH 6/6] Corretion provided by forresst

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>
---
 src/v2/guide/ssr.md | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/src/v2/guide/ssr.md b/src/v2/guide/ssr.md
index de7c9f3fa9..10b11a464f 100644
--- a/src/v2/guide/ssr.md
+++ b/src/v2/guide/ssr.md
@@ -16,19 +16,19 @@ Cela signifie que si vous avez du contenu qui s'affiche de manière asynchrone s
 
 ### Clients avec une connexion bas-débit
 
-Les utilisateurs pourraient visiter votre site depuis des lieux avec une connexion Internet bas-débit – ou juste depuis une mauvaise connexion cellulaire. Dans ces cas, vous souhaitez minimiser le nombre et la taille des requêtes nécessaires à l'utilisateur pour voir le contenu de base.
+Les utilisateurs pourraient visiter votre site depuis des lieux avec une connexion Internet bas-débit (ou juste depuis une mauvaise connexion cellulaire). Dans ces cas, vous souhaitez minimiser le nombre et la taille des requêtes nécessaires à l'utilisateur pour voir le contenu de base.
 
 Vous pouvez utiliser l'[outil Webpack de *code splitting*](https://webpack.js.org/guides/code-splitting-require/) pour ne pas forcer l'utilisateur à télécharger votre application entière pour voir une seule page, mais cela ne sera jamais aussi performant que de télécharger une seule page HTML pré-rendue.
 
 ### Clients avec un vieux (ou juste sans) moteur JavaScript
 
-Pour certaines populations ou endroits du monde, utiliser un ordinateur de 1998 pour accéder à Internet pourrait être la seule option. Puisque Vue ne fonctionne qu'avec IE9+, vous pourriez vouloir délivrer un contenu de base à ceux sur des anciens navigateurs — ou pour les hackers hipsters utilisant [Lynx](http://lynx.browser.org/) depuis un terminal.
+Pour certaines populations ou endroits du monde, utiliser un ordinateur de 1998 pour accéder à Internet pourrait être la seule option. Puisque Vue ne fonctionne qu'avec IE9+, vous pourriez vouloir délivrer un contenu de base à ceux qui utilisent d'anciens navigateurs (ou pour les hackers hipsters utilisant [Lynx](http://lynx.browser.org/) depuis un terminal).
 
 ### SSR vs. Pré-rendu
 
 Si vous étudiez le SSR uniquement pour améliorer la SEO d'une poignée de pages vitrines (ex. : `/`, `/about`, `/contact`, etc), alors vous voudriez probablement utiliser du __pré-rendu__ à la place. Au lieu d'utiliser un serveur web pour compiler le HTML à la volée, le pré-rendu génère simplement des fichiers HTML statiques pour des routes spécifiques lors de la phase de *build*. L'avantage est que mettre en place le pré-rendu est beaucoup plus simple et vous permet de garder la partie frontale d'un site complètement statique.
 
-Si vous utilisez Webpack, vous pouvez facilement ajouter le pré-rendu avec le plugin [prerender-spa-plugin](https://github.com/chrisvfritz/prerender-spa-plugin). Il a beaucoup été testé avec des applications Vue — en fait, son créateur est un membre de l'équipe du coeur de Vue.
+Si vous utilisez Webpack, vous pouvez facilement ajouter le pré-rendu avec le plugin [prerender-spa-plugin](https://github.com/chrisvfritz/prerender-spa-plugin). Il a beaucoup été testé avec des applications Vue — en fait, son créateur est un membre de l'équipe principale de Vue.
 
 ## Hello World
 
@@ -54,7 +54,7 @@ renderer.renderToString(app, function (error, html) {
 })
 ```
 
-Pas si effrayant, non ? Bien sûr, cet exemple est plus simple que pour la plupart des applications. Nous n'avons pas encore à nous préoccuper de :
+Pas si effrayant, non ? Bien sûr, cet exemple est plus simple que pour la plupart des applications. Nous n'avons pas encore à nous préoccuper :
 
 - du serveur web
 - de la réponse streamée
@@ -69,7 +69,7 @@ Dans la suite de ce guide, nous allons voir comment travailler avec certaines de
 
 C'est un peu abuser que d'appeler ça du « Server-side Rendering » quand nous n'avons pas de serveur web, alors réglons ça. Nous allons créer une application très simple avec du SSR, en utilisant uniquement une syntaxe ES5 sans aucune étape de *build* ou plugin Vue.
 
-Nous allons commencer avec une application qui va juste dire à l'utilisateur depuis combien de secondes il est sur la page :
+Nous allons commencer avec une application qui va juste dire à l'utilisateur depuis combien de secondes il se trouve sur la page :
 
 ``` js
 new Vue({
@@ -88,10 +88,10 @@ new Vue({
 
 Pour adapter ça au SSR, il y a quelques modifications à faire, afin que cela fonctionne aussi bien dans le navigateur qu'avec Node.js :
 
-- Quand chargé dans un navigateur, ajouter une instance de notre application au contexte global (c-à-d `window`), afin que nous puissions faire le montage.
-- Quand chargé avec Node.js, exporter une fonction de fabrique afin que nous puissions créer une nouvelle instance de Vue pour chaque requête.
+- Quand chargé dans un navigateur, ajoute une instance de notre application au contexte global (c-à-d `window`), afin que nous puissions faire le montage.
+- Quand chargé avec Node.js, exporte une fonction de fabrique afin que nous puissions créer une nouvelle instance de Vue pour chaque requête.
 
-Réaliser ces modifications nécessite une petite base de code :
+La réalisation de ces modifications nécessite une petite base de code :
 
 ``` js
 // assets/app.js
@@ -103,7 +103,7 @@ Réaliser ces modifications nécessite une petite base de code :
 
     // L'instance de Vue principale doit être retournée et avoir
     // un nœud racine avec l'id « app », afin que la version côté
-    // client puisse prendre le relais.
+    // client puisse prendre le relais une fois qu'elle est chargée.
     return new Vue({
       template: '<div id="app">Vous êtes ici depuis {{ counter }} seconde(s).</div>',
       data: {
@@ -149,7 +149,7 @@ Maintenant que nous avons le code de notre application, mettons tout cela dans u
 
 Tant que le répertoire `assets` mentionné contient le fichier `app.js` créé précédemment, ainsi qu'un fichier `vue.js` avec Vue, nous devrions avoir une application monopage fonctionnelle !
 
-Ensuite, pour le faire fonctionner avec du rendu côté serveur, il y a juste une étape de plus — le serveur web :
+Ensuite, pour le faire fonctionner avec du rendu côté serveur, il y a juste une étape de plus (le serveur web) :
 
 ``` js
 // server.js
@@ -319,7 +319,7 @@ N'importe quel composant « pur » peut être mis en cache sans problème — c'
 - Des composants d'éléments de liste (dans de longues listes, les mettre en cache peut significativement améliorer les performances)
 - Des composants génériques d'interface utilisateur (c-à-d les boutons, alertes, etc. — du moins ceux qui acceptent du contenu via les props plutôt que les slots/enfants)
 
-## Processus de build, routage, et hydratation d'état de Vuex
+## Processus de build, routage et hydratation d'état de Vuex
 
 À présent, vous devriez comprendre les concepts fondamentaux derrière le rendu côté serveur. Cependant, à mesure que vous introduisez un processus de *build*, du routage ou vuex, cela introduit son propre lot de considérations.
 
@@ -330,4 +330,4 @@ Pour réellement maîtriser le rendu côté serveur dans des applications comple
 
 ## Nuxt.js
 
-Configurer proprement tous les aspects dont nous avons discuté pour un rendu côté serveur près à la production peut être intimidant. Fort heureusement, il y a un excellent projet communautaire dont le but est de rendre tout cela plus simple : [Nuxt.js](https://nuxtjs.org/). Nuxt.js est un framework de haut niveau construit par-dessus l'écosystème de Vue et qui fournit une expérience de développement toute tracée pour écrire des applications Vue universelle. Encore mieux, vous pouvez vous en servir comme générateur de sites web statiques (avec des pages écrites comme composants Vue monofichiers) ! Nous vous recommandons grandement de l'essayer.
+Configurer proprement tous les aspects dont nous avons discuté pour un rendu côté serveur près à la production peut être intimidant. Fort heureusement, il y a un excellent projet communautaire dont le but est de rendre tout cela plus simple : [Nuxt.js](https://nuxtjs.org/). Nuxt.js est un framework de haut niveau construit par-dessus l'écosystème de Vue et qui fournit une expérience de développement toute tracée pour écrire des applications Vue universelle. Encore mieux, vous pouvez vous en servir comme générateur de sites web statiques (avec des pages écrites comme des composants Vue monofichiers) ! Nous vous recommandons grandement de l'essayer.