diff --git a/LANGS.md b/LANGS.md
index 17534973..5f855067 100644
--- a/LANGS.md
+++ b/LANGS.md
@@ -1,4 +1,5 @@
 * [English](en/)
+* [Français](fr/)
 * [中文](zh/)
 * [Русский](ru/)
 * [한국어 (Korean)](ko/)
diff --git a/fr/README.md b/fr/README.md
new file mode 100644
index 00000000..8b455b84
--- /dev/null
+++ b/fr/README.md
@@ -0,0 +1,50 @@
+# Guide du rendu côté serveur avec Vue.js
+
+> **Note :** Ce guide nécessite les versions de Vue et de ses bibliothèques de support suivantes :
+> - vue & vue-server-renderer >= 2.3.0
+> - vue-router >= 2.5.0
+> - vue-loader >= 12.0.0 & vue-style-loader >= 3.0.0
+
+> Si vous avez déjà utilisé le rendu côté serveur (SSR pour *Server-Side Rendering*) avec Vue 2.2, vous vous apercevrez que la structure de code recommandée est maintenant [légèrement différente](./structure.md) (avec la nouvelle option [runInNewContext](./api.md#runinnewcontext) mise à `false`). Votre application devrait continuer à fonctionner, mais il est recommandé de migrer vers les nouvelles recommandations.
+
+## 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.
+
+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.
+
+## Pourquoi faire du SSR ?
+
+En comparaison des applications monopages traditionnelles (SPA pour *Single-Page Application*), l'avantage du SSR se manifeste dans :
+
+- De meilleures optimisations pour les moteurs de recherche (SEO pour *Search Engine Optimisations*), ainsi les moteurs d'indexation voient directement le rendu complet de la 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.
+
+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.
+
+- 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.
+
+Avant d'utiliser du SSR pour vos applications, la première question que vous devriez vous poser est si vous en avez réellement besoin. Cela dépendra de l'importance du temps d'accès au contenu pour votre application. Par exemple, si vous créez une interface d'administration avec un chargement initial de quelques secondes, cela n'a pas d'importance ; du SSR n'aurait pas de pertinence dans ce cas. Cependant, dans le cas où l'accès au contenu est une priorité absolue, du SSR peut vous aider à obtenir les meilleures performances de chargement initial.
+
+## 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 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).
+
+## À propos de ce guide
+
+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](http://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.
+
+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.
+
+Pour finir, notez que les solutions de ce guide ne sont pas définitives. Nous avons trouvé que cela fonctionnait bien pour nous, mais cela ne veut pas dire qu'il n'y a pas d'améliorations à faire. Nous pourrons les réviser dans le futur. N'hésitez donc pas à y contribuer en soumettant des pull requests !
diff --git a/fr/SUMMARY.md b/fr/SUMMARY.md
new file mode 100644
index 00000000..c3e396e8
--- /dev/null
+++ b/fr/SUMMARY.md
@@ -0,0 +1,27 @@
+- [Utilisation de base](basic.md)
+- [Écrire du code universel](universal.md)
+- [Structure de code](structure.md)
+- [Routage et scission du code](routing.md)
+- [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)
+- [Gestion des CSS](css.md)
+- [Gestion des entêtes (En)](head.md)
+- [Mise en cache](caching.md)
+- [Envoi par flux](streaming.md)
+- [Référence de l'API](api.md)
+  - [createRenderer](api.md#createrendereroptions)
+  - [createBundleRenderer](api.md#createbundlerendererbundle-options)
+  - [Class: Renderer](api.md#class-renderer)
+  - [Class: BundleRenderer](api.md#class-bundlerenderer)
+  - [Options de Renderer](api.md#renderer-options)
+    - [template](api.md#template)
+    - [clientManifest](api.md#clientmanifest)
+    - [inject](api.md#inject)
+    - [shouldPreload](api.md#shouldpreload)
+    - [runInNewContext](api.md#runinnewcontext)
+    - [basedir](api.md#basedir)
+    - [cache](api.md#cache)
+    - [directives](api.md#directives)
+  - [Plugins webpack](api.md#webpack-plugins)
diff --git a/fr/api.md b/fr/api.md
new file mode 100644
index 00000000..dd1a2f12
--- /dev/null
+++ b/fr/api.md
@@ -0,0 +1,236 @@
+# Référence de l'API
+
+## `createRenderer([options])`
+
+Crée une instance de [`Renderer`](#class-renderer) avec des [options](#renderer-options) optionnelles.
+
+``` js
+const { createRenderer } = require('vue-server-renderer')
+const renderer = createRenderer({ ... })
+```
+
+## `createBundleRenderer(bundle[, options])`
+
+Crée une instance de [`BundleRenderer`](#class-bundlerenderer) avec un paquetage serveur et des [options](#renderer-options) optionnelles.
+
+``` js
+const { createBundleRenderer } = require('vue-server-renderer')
+const renderer = createBundleRenderer(serverBundle, { ... })
+```
+
+L'argument `serverBundle` peut être l'un des éléments suivants :
+
+- Un chemin absolu pour générer un fichier de paquetage (`.js` ou `.json`). Doit commencer par `/` pour être considéré comme un chemin de fichier.
+
+- 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é).
+
+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.
+
+- #### `renderer.renderToStream(vm[, context])`
+
+  Fait le rendu d'une instance de Vue sous forme de flux. L'objet de contexte est optionnel. Voir l'[Envoi par flux](./streaming.md) pour plus de détails.
+
+## `Class: BundleRenderer`
+
+- #### `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.
+
+- #### `bundleRenderer.renderToStream([context])`
+
+  Fait le rendu d'un paquetage sous forme de flux. L'objet de contexte est optionnel. Voir l'[Envoi par flux](./streaming.md) pour plus de détails.
+
+## Options de `Renderer`
+
+- #### `template`
+
+  Fournit un modèle de page pour la page HTML complète. Le modèle de page devrait contenir en commentaire `<!--vue-ssr-outlet-->` qui permet de définir l'emplacement du contenu de chaque rendu de l'application.
+
+  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é.
+
+  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.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.
+
+  Vous pouvez désactiver toutes ces injections en passant `inject: false` au moteur de rendu.
+
+  Voir également :
+
+  - [Utiliser un modèle de page](./basic.md#utiliser-un-modele-de-page)
+  - [Injection manuelle des fichiers](./build-config.md#injection-manuelle-des-fichiers)
+
+- #### `clientManifest`
+
+  - 2.3.0+
+
+  Fournit un objet de build de manifeste généré par `vue-server-renderer/client-plugin`. Le manifeste client fournit le paquetage de moteur de rendu avec ses propres informations pour l'injection automatique de fichiers dans le modèle de page HTML. Pour plus de détails, consultez [Générer le `clientManifest`](./build-config.md#generer-le-clientmanifest).
+
+- #### `inject`
+
+  - 2.3.0+
+
+  Contrôle la manière d'exécuter des injections automatiques en utilisant `template`. Par défaut à `true`.
+
+  Voir aussi : [Injection manuelle des fichiers](./build-config.md#injection-manuelle-des-fichiers).
+
+- #### `shouldPreload`
+
+  - 2.3.0+
+
+  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.
+
+  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, {
+    template,
+    clientManifest,
+    shouldPreload: (file, type) => {
+      // le type est déduit en se basant sur l'extension du fichier.
+      // https://fetch.spec.whatwg.org/#concept-request-destination
+      if (type === 'script' || type === 'style') {
+        return true
+      }
+      if (type === 'font') {
+        // pré-charger uniquement les polices woff2
+        return /\.woff2$/.test(file)
+      }
+      if (type === 'image') {
+        // charger uniquement les images importantes
+        return file === 'hero.jpg'
+      }
+    }
+  })
+  ```
+
+- #### `runInNewContext`
+
+  - 2.3.0+
+  - 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.
+
+  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.
+
+  > 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 :
+
+  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.
+
+  Voir aussi : [Structure de code](./structure.md)
+
+- #### `basedir`
+
+  - 2.2.0+
+  - seulement utilisée avec `createBundleRenderer`
+
+  Déclarer explicitement le dossier de base du paquetage serveur afin de résoudre les dépendances `node_modules`. Cela est nécessaire si le fichier de paquetage généré est placé à un endroit différent de là où les dépendances externes npm sont installées, ou si `vue-server-renderer` est lié à npm dans votre projet courant.
+
+- #### `cache`
+
+  Fournit une implémentation de [Mise en cache au niveau du composant](./caching.md#mise-en-cache-au-niveau-du-composant). L'objet de cache doit implémenter l'interface suivante (utilisation des notations Flow) :
+
+  ``` js
+  type RenderCache = {
+    get: (key: string, cb?: Function) => string | void;
+    set: (key: string, val: string) => void;
+    has?: (key: string, cb?: Function) => boolean | void;
+  };
+  ```
+
+  Une utilisation typique est de passer un [objet de mise en cache qui supprime l'objet le plus récemment utilisé](https://github.com/isaacs/node-lru-cache) :
+
+  ``` js
+  const LRU = require('lru-cache')
+
+  const renderer = createRenderer({
+    cache: LRU({
+      max: 10000
+    })
+  })
+  ```
+
+  Notez que cet objet de mise en cache doit au moins implémenter `get` et `set`. De plus `get` et `set` peuvent être optionnellement asynchrone s'ils acceptent en second argument une fonction de rappel. Cela permet à la mise en cache d'utiliser des APIs. Par ex. un client Redis :
+
+  ``` js
+  const renderer = createRenderer({
+    cache: {
+      get: (key, cb) => {
+        redisClient.get(key, (err, res) => {
+          // gérer les erreur s'il y en a
+          cb(res)
+        })
+      },
+      set: (key, val) => {
+        redisClient.set(key, val)
+      }
+    }
+  })
+  ```
+
+- #### `directives`
+
+  Vous permet de fournir des implémentations côté serveur pour vos directives personnalisées :
+
+  ``` js
+  const renderer = createRenderer({
+    directives: {
+      example (vnode, directiveMeta) {
+        // transformer les vnode en directive de liaison de metadata
+      }
+    }
+  })
+  ```
+
+  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.
+
+## Plugins webpack
+
+Les pluging webpack sont fournis en fichiers autonomes et devraient être requis en direct :
+
+``` js
+const VueSSRServerPlugin = require('vue-server-renderer/server-plugin')
+const VueSSRClientPlugin = require('vue-server-renderer/client-plugin')
+```
+
+Les fichiers générés par défaut sont :
+
+- `vue-ssr-server-bundle.json` pour le plugin serveur,
+- `vue-ssr-client-manifest.json` pour le plugin client.
+
+Les noms de fichiers peuvent être personnalisés lors de la création des instances des plugins :
+
+``` js
+const plugin = new VueSSRServerPlugin({
+  filename: 'my-server-bundle.json'
+})
+```
+
+Voir la [Configuration de pré-compilation](./build-config.md) pour plus d'informations.
diff --git a/fr/basic.md b/fr/basic.md
new file mode 100644
index 00000000..b4723318
--- /dev/null
+++ b/fr/basic.md
@@ -0,0 +1,150 @@
+# Utilisation de base
+
+## Installation
+
+``` bash
+npm install vue vue-server-renderer --save
+```
+
+Nous allons utiliser npm tout au long de ce guide, n'hésitez pas à utiliser [Yarn](https://yarnpkg.com/en/) à la place.
+
+#### Notes
+
+- Il est recommandé d'utiliser une version 6 ou supérieur de Node.js
+- `vue-server-renderer` et `vue` doivent utiliser des numéros de version identiques.
+- `vue-server-renderer` utilise plusieurs modules Node.js natifs fournis uniquement par Node.js. Nous fournirons une version exécutable qui pourra tourner sur les autres moteurs JavaScript dans le futur.
+
+## Faire le rendu d'une instance de Vue
+
+``` js
+// Étape 1 : créer une instance de Vue
+const Vue = require('vue')
+const app = new Vue({
+  template: `<div>Hello World</div>`
+})
+
+// Étape 2 : créer un moteur de rendu
+const renderer = require('vue-server-renderer').createRenderer()
+
+// Étape 3 : faire le rendu de l'instance en HTML
+renderer.renderToString(app, (err, html) => {
+  if (err) throw err
+  console.log(html)
+  // => <div data-server-rendered="true">Hello World</div>
+})
+```
+
+## 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/) :
+
+``` bash
+npm install express --save
+```
+---
+``` js
+const Vue = require('vue')
+const server = require('express')()
+const renderer = require('vue-server-renderer').createRenderer()
+
+server.get('*', (req, res) => {
+  const app = new Vue({
+    data: {
+      url: req.url
+    },
+    template: `<div>L'URL visité est : {{ url }}</div>`
+  })
+
+  renderer.renderToString(app, (err, html) => {
+    if (err) {
+      res.status(500).end('Erreur interne du serveur')
+      return
+    }
+    res.end(`
+      <!DOCTYPE html>
+      <html lang="en">
+        <head><title>Bonjour</title></head>
+        <body>${html}</body>
+      </html>
+    `)
+  })
+})
+
+server.listen(8080)
+```
+
+## Utiliser un modèle de page
+
+Quand vous faites le rendu d'une application Vue, le moteur de rendu fournit uniquement les balises de votre application. Dans cet exemple, nous allons ajouter de part et d'autre la structure HTML nécessaire à toutes pages.
+
+Le plus simple est de directement fournir un modèle de page lors de la création du moteur de rendu. La plupart du temps, nous allons mettre le modèle de page dans son propre fichier. Par ex. `index.template.html` :
+
+``` html
+<!DOCTYPE html>
+<html lang="en">
+  <head><title>Bonjour</title></head>
+  <body>
+    <!--vue-ssr-outlet-->
+  </body>
+</html>
+```
+
+Notez que le commentaire `<!--vue-ssr-outlet-->` représente la zone où les balises de votre application vont être injectées.
+
+Nous allons ensuite lire et passer le contenu du fichier au générateur de rendu de Vue :
+
+``` js
+const renderer = createRenderer({
+  template: require('fs').readFileSync('./index.template.html', 'utf-8')
+})
+
+renderer.renderToString(app, (err, html) => {
+  console.log(html) // sera la page complète avec le contenu de l'application injecté.
+})
+```
+
+### Interpolation dans le modèle de page
+
+Le modèle de page supporte également une interpolation simple. Avec le modèle de page suivant :
+
+``` html
+<html>
+  <head>
+    <!-- utilisation de la double moustache pour l'interpolation avec HTML échapé -->
+    <title>{{ title }}</title>
+
+    <!-- utilisation de la triple moustache pour l'interpolation du HTML -->
+    {{{ meta }}}
+  </head>
+  <body>
+    <!--vue-ssr-outlet-->
+  </body>
+</html>
+```
+
+Nous pouvons fournir les données d'interpolation suivantes à travers un « objet de contexte de rendu » en tant que second argument de `renderToString` :
+
+``` js
+const context = {
+  title: 'Bonjour',
+  meta: `
+    <meta ...>
+    <meta ...>
+  `
+}
+
+renderer.renderToString(app, context, (err, html) => {
+  // le titre de la page sera « Bonjour »
+  // avec les balises `<meta>` injectées
+})
+```
+
+L'objet `context` peut également être partagé avec l'instance de l'application de Vue, permettant aux composants de dynamiquement fournir des données pour l'interpolation du modèle de page.
+
+De plus, le modèle de page supporte des fonctionnalités avancées comme :
+
+- l'injection automatique de CSS critique lors de l'utilisation de composants `*.vue`,
+- l'injection automatique de balises `<link>` avec l'utilisation de `clientManifest`,
+- l'injection automatique de l'état de Vuex pour l'hydratation cliente avec prévention XSS.
+
+Nous discuterons de cela quand nous introduirons ces concepts plus tard dans le guide.
diff --git a/fr/build-config.md b/fr/build-config.md
new file mode 100644
index 00000000..210d82e1
--- /dev/null
+++ b/fr/build-config.md
@@ -0,0 +1,216 @@
+# 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).
+
+## Configuration serveur
+
+La configuration serveur est destinée à générer le paquetage serveur qui va être passé à `createBundleRenderer`. Elle devrait ressembler à cela :
+
+``` js
+const merge = require('webpack-merge')
+const nodeExternals = require('webpack-node-externals')
+const baseConfig = require('./webpack.base.config.js')
+const VueSSRServerPlugin = require('vue-server-renderer/server-plugin')
+
+module.exports = merge(baseConfig, {
+  // Fichier d'entrée serveur de l'application
+  entry: '/path/to/entry-server.js',
+
+  // Cela permet à webpack de gérer les imports dynamiques d'une manière
+  // approprié pour Node.js, et dit également à `vue-loader` d'émettre un code approprié pour le serveur
+  // lors de la compilation du composant Vue.
+  target: 'node',
+
+  // Pour le support des sources maps des paquetages
+  devtool: 'source-map',
+
+  // Cela dit au paquetage serveur d'utiliser les exports au format Node.js
+  output: {
+    libraryTarget: 'commonjs2'
+  },
+
+  // https://webpack.js.org/configuration/externals/#function
+  // https://github.com/liady/webpack-node-externals
+  // Externalise les dépendances de l'application. Cela rend le build serveur plus rapide
+  // 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 devriez aussi lister des exceptions qui modifient `global` (par ex. les polyfills)
+    whitelist: /\.css$/
+  }),
+
+  // Ceci est le plugin qui va créer entièrement la sortie pour le build serveur
+  // dans un seul fichier JSON. Le fichier généré par défaut va être
+  // `vue-ssr-server-bundle.json`
+  plugins: [
+    new VueSSRServerPlugin()
+  ]
+})
+```
+
+Après que `vue-ssr-server-bundle.json` ai été généré, passez simplement le chemin du fichier à `createBundleRenderer` :
+
+``` js
+const { createBundleRenderer } = require('vue-server-renderer')
+const renderer = createBundleRenderer('/path/to/vue-ssr-server-bundle.json', {
+  // ...autre options pour le moteur
+})
+```
+
+Vous pouvez alternativement tout aussi bien passer le paquetage comme un objet à `createBundleRenderer`. Cela est utile pour le rechargement à chaud pendant le développement. Voyez la démo de HackerNews pour une [référence de mise en place](https://github.com/vuejs/vue-hackernews-2.0/blob/master/build/setup-dev-server.js).
+
+### 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.
+
+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.
+
+### 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.
+
+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 »).
+
+Pour tirer partie du manifeste client, la configuration cliente devrait ressembler à ça :
+
+``` js
+const webpack = require('webpack')
+const merge = require('webpack-merge')
+const baseConfig = require('./webpack.base.config.js')
+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
+    // 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({
+      name: "manifest",
+      minChunks: Infinity
+    }),
+    // Ce plugin génère le fichier `vue-ssr-client-manifest.json` dans
+    // le dossier de sortie.
+    new VueSSRClientPlugin()
+  ]
+})
+```
+
+Vous pouvez même utiliser le manifeste client généré conjointement avec un template de page :
+
+``` js
+const { createBundleRenderer } = require('vue-server-renderer')
+
+const template = require('fs').readFileSync('/path/to/template.html', 'utf-8')
+const serverBundle = require('/path/to/vue-ssr-server-bundle.json')
+const clientManifest = require('/path/to/vue-ssr-client-manifest.json')
+
+const renderer = createBundleRenderer(serverBundle, {
+  template,
+  clientManifest
+})
+```
+
+Avec cette mise en place, votre rendu HTML côté serveur pour un build avec scission de code va ressembler à quelque chose comme ci-dessous (tout étant auto-injecté) :
+
+``` html
+<html>
+  <head>
+    <!-- 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">
+    <!-- les fragments asynchrones non utilisés vont seulement être récupérés (priorité basse) -->
+    <link rel="prefetch" href="/1.js" as="script">
+  </head>
+  <body>
+    <!-- contenu de l'application -->
+    <div data-server-rendered="true"><div>async</div></div>
+    <!-- le fragment du manifeste devrait être le premier -->
+    <script src="/manifest.js"></script>
+    <!-- les fragments asynchrones sont injectés avant le fragment principal -->
+    <script src="/0.js"></script>
+    <script src="/main.js"></script>
+  </body>
+</html>`
+```
+
+### Injection manuelle des fichiers
+
+Par défaut, l'injection des fichiers est automatique quand vous fournissez l'option de rendu `template`. Mais parfois vous aurez besoin d'une granularité de contrôle plus fine en ce qui concerne la manière dont les templates seront injectés, ou peut-être que vous n'utiliserez pas de template du tout. Dans tous les cas, vous pouvez passer `inject: false` quand le moteur est créé et manuellement réaliser l'injection des fichiers.
+
+Dans la fonction de rappel de `renderToString`, l'objet `context` que vous passez va exposer les méthodes suivantes :
+
+- `context.renderStyles()`
+
+  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`)
+
+- `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 :
+
+  ``` js
+  context.renderState({
+    contextKey: 'myCustomState',
+    windowKey: '__MY_STATE__'
+  })
+
+  // -> <script>window.__MY_STATE__={...}</script>
+  ```
+
+- `context.renderScripts()`
+
+  - 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.
+
+- `context.renderResourceHints()`
+
+  - requiert `clientManifest`
+
+  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.
+
+  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.
+
+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`) :
+
+``` html
+<html>
+  <head>
+    <!-- utiliser les triples moustaches pour une interpolation sans HTML -->
+    {{{ renderResourceHints() }}}
+    {{{ renderStyles() }}}
+  </head>
+  <body>
+    <!--vue-ssr-outlet-->
+    {{{ renderState() }}}
+    {{{ renderScripts() }}}
+  </body>
+</html>
+```
+
+Si vous n'utilisez pas `template` du tout, vous pouvez concaténer les chaînes vous-mêmes.
diff --git a/fr/bundle-renderer.md b/fr/bundle-renderer.md
new file mode 100644
index 00000000..39dffda9
--- /dev/null
+++ b/fr/bundle-renderer.md
@@ -0,0 +1,52 @@
+# Introduction au moteur de dépaquetage
+
+## Problèmes basiques du SSR
+
+À ce point, nous supposons que le code empaqueté côté serveur sera directement utilisé via `require` :
+
+``` js
+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.
+
+## Le moteur de dépaquetage
+
+`vue-server-renderer` fournit une API appelée `createBundleRenderer` pour résoudre ce problème. Avec un plugin webpack personnalisé, le paquetage (« bundle ») serveur est généré comme un fichier JSON spécial qui peut être passé au moteur de dépaquetage (« bundle renderer »). Une fois que le moteur de dépaquetage est créé, l'usage est le même qu'un moteur de rendu, cependant le moteur de dépaquetage fournit les bénéfices suivants :
+
+- 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)
+
+- 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 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 :
+
+``` js
+const { createBundleRenderer } = require('vue-server-renderer')
+
+const renderer = createBundleRenderer(serverBundle, {
+  runInNewContext: false, // recommandé
+  template, // (optionnel) page de template
+  clientManifest // (optionnel) manifeste de build client
+})
+
+// à l'intérieur du gestionnaire serveur...
+server.get('*', (req, res) => {
+  const context = { url: req.url }
+  // 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...
+    res.end(html)
+  })
+})
+```
+
+Quand `renderToString` est appelé sur le moteur de dépaquetage, il va automatiquement exécuté la fonction exportée par le paquetage pour créer une instance de l'application (en passant `context` comme argument) puis va en faire le rendu.
+
+Notons qu'il est recommandé de mettre l'option `runInNewContext` à `false` ou à `'once'`. Plus de détails dans [la référence de l'API](./api.md#runinnewcontext).
diff --git a/fr/caching.md b/fr/caching.md
new file mode 100644
index 00000000..dd177a09
--- /dev/null
+++ b/fr/caching.md
@@ -0,0 +1,87 @@
+# 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.
+
+## 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.
+
+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.
+})
+
+const isCacheable = req => {
+  // implémentation d'un algorithme pour définir si une requête est spécifique à un utilisateur.
+  // seules les pages non spécifiques à un utilisateur peuvent être mises en cache
+}
+
+server.get('*', (req, res) => {
+  const cacheable = isCacheable(req)
+  if (cacheable) {
+    const hit = microCache.get(req.url)
+    if (hit) {
+      return res.end(hit)
+    }
+  }
+
+  renderer.renderToString((err, html) => {
+    res.end(html)
+    if (cacheable) {
+      microCache.set(req.url, html)
+    }
+  })
+})
+```
+
+Parce que le composant est mis en cache pour seulement une seconde, les utilisateurs ne verront pas le contenu déjà périmé. Cependant, cela signifie que le serveur a besoin de faire un rendu complet une seule fois par seconde pour chaque page mise en cache.
+
+## Mise en cache au niveau du composant
+
+`vue-server-renderer` a un support intégré pour la mise en cache de composant. Pour l'activer, vous avez besoin d'une [implémentation de mise en cache](./api.md#cache) quand vous créez le moteur de rendu. L'usage courant est de passer un [objet de mise en cache qui supprime l'objet le plus récemment utilisé](https://github.com/isaacs/node-lru-cache) :
+
+``` js
+const LRU = require('lru-cache')
+
+const renderer = createRenderer({
+  cache: LRU({
+    max: 10000,
+    maxAge: ...
+  })
+})
+```
+
+Vous pouvez aussi implémenter une mise en cache de composant avec une fonction `serverCacheKey` :
+
+``` js
+export default {
+  name: 'item', // requis
+  props: ['item'],
+  serverCacheKey: props => props.item.id,
+  render (h) {
+    return h('div', this.item.id)
+  }
+}
+```
+
+Notez que ce composant pouvant être mis en cache **doit aussi définir une option `name` unique**. Avec un nom unique, la clé de mise en cache est effective par composant : vous n'avez donc pas besoin de vous préoccuper de deux composants qui retourneraient la même clé.
+
+La clé retournée par `serverCacheKey` devrait contenir suffisamment d'informations pour représenter tous les résultats de rendu. L'exemple ci-dessus est une bonne implémentation si le résultat du rendu est uniquement déterminé par `props.item.id`. Cependant, si un élément avec le même identifiant change à chaque fois, ou si son rendu est lié au changement d'une autre prop, alors vous devez modifier votre implémentation `getCacheKey` pour prendre en compte ces variables.
+
+Retourner une constante va mener le composant à toujours être en cache, ce qui peut être une bonne chose pour les composants statiques.
+
+### 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 :
+
+- 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 :
+
+``` js
+serverCacheKey: props => props.item.id + '::' + props.item.last_updated
+```
diff --git a/fr/css.md b/fr/css.md
new file mode 100644
index 00000000..fa5a5e8b
--- /dev/null
+++ b/fr/css.md
@@ -0,0 +1,114 @@
+# Gestion des CSS
+
+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,
+- 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 :
+
+- Expérience de création universelle côté client et côté serveur.
+
+- 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>`.
+
+- 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`.
+
+## Activer l'extraction CSS
+
+Pour extraire le CSS des fichiers `*.vue`, utilisez l'option `extractCSS` du `vue-loader` (requiert `vue-loader>=12.0.0`) :
+
+``` js
+// webpack.config.js
+const ExtractTextPlugin = require('extract-text-webpack-plugin')
+
+// L'extraction CSS devrait uniquement être activée en production
+// ainsi vous pourriez utiliser le rechargement à chaud pendant le développement.
+const isProduction = process.env.NODE_ENV === 'production'
+
+module.exports = {
+  // ...
+  module: {
+    rules: [
+      {
+        test: /\.vue$/,
+        loader: 'vue-loader',
+        options: {
+          // activer l'extraction CSS
+          extractCSS: isProduction
+        }
+      },
+      // ...
+    ]
+  },
+  plugins: isProduction
+    // assurez-vous d'avoir ajouté le plugin !
+    ? [new ExtractTextPlugin({ filename: 'common.[chunkhash].css' })]
+    : []
+}
+```
+
+Notez que la configuration ci-dessus est uniquement appliquée pour les styles en provenance des fichiers `*.vue`, mais vous pouvez toujours utiliser `<style src="./foo.css">` pour importer des CSS externes dans des composants Vue.
+
+Si vous souhaitez importer des CSS depuis le JavaScript, par ex. avec `import 'foo.css'`, vous aurez besoin de configurer les loaders appropriés :
+
+``` js
+module.exports = {
+  // ...
+  module: {
+    rules: [
+      {
+        test: /\.css$/,
+        // important : utilisez `vue-style-loader` à la place de `style-loader`
+        use: isProduction
+          ? ExtractTextPlugin.extract({
+              use: 'css-loader',
+              fallback: 'vue-style-loader'
+            })
+          : ['vue-style-loader', 'css-loader']
+      }
+    ]
+  },
+  // ...
+}
+```
+
+## Importer des styles depuis les dépendances
+
+Quelques choses que vous devez prendre en note quand vous importez des CSS depuis des dépendances npm :
+
+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 :
+
+  ``` js
+  module.exports = {
+    // ...
+    plugins: [
+      // il est normal d'extraire un fragment tiers pour une meilleure mise en cache.
+      new webpack.optimize.CommonsChunkPlugin({
+        name: 'vendor',
+        minChunks: function (module) {
+          // un module est extrait dans un fragment tiers puis...
+          return (
+            // s'il est a l'intérieur d'un dossier node_modules
+            /node_modules/.test(module.context) &&
+            // ne pas l'externaliser si la requête est un fichier CSS
+            !/\.css$/.test(module.request)
+          )
+        }
+      }),
+      // extraction de l'exécuteur et du manifeste webpack
+      new webpack.optimize.CommonsChunkPlugin({
+        name: 'manifest'
+      }),
+      // ...
+    ]
+  }
+  ```
diff --git a/fr/data.md b/fr/data.md
new file mode 100644
index 00000000..1f179f2c
--- /dev/null
+++ b/fr/data.md
@@ -0,0 +1,316 @@
+# Récupération de données et état
+
+## 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**.
+
+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.
+
+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
+import Vue from 'vue'
+import Vuex from 'vuex'
+
+Vue.use(Vuex)
+
+// Supposons que nous ayons une API universelle retournant
+// des Promesses (« Promise ») et ignorons les détails de l'implémentation
+import { fetchItem } from './api'
+
+export function createStore () {
+  return new Vuex.Store({
+    state: {
+      items: {}
+    },
+    actions: {
+      fetchItem ({ commit }, id) {
+        // retournant la Promesse via `store.dispatch()`, nous savons
+        // quand les données ont été pré-chargées
+        return fetchItem(id).then(item => {
+          commit('setItem', { id, item })
+        })
+      }
+    },
+    mutations: {
+      setItem (state, { id, item }) {
+        Vue.set(state.items, id, item)
+      }
+    }
+  })
+}
+```
+
+Et mettons à jour `app.js`:
+
+``` js
+// app.js
+import Vue from 'vue'
+import App from './App.vue'
+import { createRouter } from './router'
+import { createStore } from './store'
+import { sync } from 'vuex-router-sync'
+
+export function createApp () {
+  // créer le routeur et l'instance du store
+  const router = createRouter()
+  const store = createStore()
+
+  // synchroniser pour que l'état de la route soit disponible en tant que donnée du store
+  sync(store, router)
+
+  // créer l'instance de l'application, injecter le routeur et le store
+  const app = new Vue({
+    router,
+    store,
+    render: h => h(App)
+  })
+
+  // exposer l'application, le routeur et le store.
+  return { app, router, store }
+}
+```
+
+## Collocation logique avec les composants
+
+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.
+
+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 :
+
+``` html
+<!-- Item.vue -->
+<template>
+  <div>{{ item.title }}</div>
+</template>
+
+<script>
+export default {
+  asyncData ({ store, route }) {
+    // retourner la Promesse depuis l'action
+    return store.dispatch('fetchItem', route.params.id)
+  },
+
+  computed: {
+    // afficher l'élément depuis l'état du store.
+    item () {
+      return this.$store.state.items[this.$route.params.id]
+    }
+  }
+}
+</script>
+```
+
+## Récupération de données côté serveur
+
+Dans `entry-server.js` nous pouvons obtenir les composants qui concordent avec une route grâce à `router.getMatchedComponents()`, et appeler `asyncData` si le composant l'expose. Nous avons ensuite besoin d'attacher l'état résolu au contexte de rendu.
+
+``` js
+// entry-server.js
+import { createApp } from './app'
+
+export default context => {
+  return new Promise((resolve, reject) => {
+    const { app, router, store } = createApp()
+
+    router.push(context.url)
+
+    router.onReady(() => {
+      const matchedComponents = router.getMatchedComponents()
+      if (!matchedComponents.length) {
+        return reject({ code: 404 })
+      }
+
+      // appeler `asyncData()` sur toutes les routes concordantes
+      Promise.all(matchedComponents.map(Component => {
+        if (Component.asyncData) {
+          return Component.asyncData({
+            store,
+            route: router.currentRoute
+          })
+        }
+      })).then(() => {
+        // 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
+        // être sérialisé et injecté dans le HTML en tant que `window.__INITIAL_STATE__`.
+        context.state = store.state
+
+        resolve(app)
+      }).catch(reject)
+    }, reject)
+  })
+}
+```
+
+En utilisant `template`, `context.state` va automatiquement être encapsulé dans le HTML final en tant qu'état `window.__INITIAL_STATE__`. Côté client, le store voudra récupérer cet état avant de monter l'application :
+
+``` js
+// entry-client.js
+
+const { app, router, store } = createApp()
+
+if (window.__INITIAL_STATE__) {
+  store.replaceState(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 :
+
+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.
+
+  ``` js
+  // entry-client.js
+
+  // ...omission du code sans rapport
+
+  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
+    // 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
+      let diffed = false
+      const activated = matched.filter((c, i) => {
+        return diffed || (diffed = (prevMatched[i] !== c))
+      })
+
+      if (!activated.length) {
+        return next()
+      }
+
+      // c'est ici qu'il faudrait lancer un indicateur de chargement si nous en avions un
+
+      Promise.all(activated.map(c => {
+        if (c.asyncData) {
+          return c.asyncData({ store, route: to })
+        }
+      })).then(() => {
+
+        // arrêt de l'indicateur de chargement
+
+        next()
+      }).catch(next)
+    })
+
+    app.$mount('#app')
+  })
+  ```
+
+2. **Récupérer les données après que les vues concordantes soient rendues :**
+
+  Cette stratégie place la logique de récupération de données côté client dans la fonction `beforeMount` de la vue du composant. Cela permet aux vues de changer instantanément quand un changement de route est enclenché, aussi l'application semblera un peu plus réactive. Cependant, la vue suivante n'aura pas l'intégralité de ses données disponibles lors du rendu. Il est donc nécessaire d'avoir un état de chargement conditionnel pour chaque vue de composant utilisant cette stratégie.
+
+  Cela peut être réalisé avec un mixin global uniquement côté client :
+
+  ``` js
+  Vue.mixin({
+    beforeMount () {
+      const { asyncData } = this.$options
+      if (asyncData) {
+        // assigner une opération de récupération de données à une Promesse
+        // ainsi tout ce que nous devons faire dans un composant est `this.dataPromise.then(...)`
+        // pour exécuter la suite des tâches une fois que les données sont prêtes
+        this.dataPromise = asyncData({
+          store: this.$store,
+          route: this.$route
+        })
+      }
+    }
+  })
+  ```
+
+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.
+
+``` js
+Vue.mixin({
+  beforeRouteUpdate (to, from, next) {
+    const { asyncData } = this.$options
+    if (asyncData) {
+      asyncData({
+        store: this.$store,
+        route: to
+      }).then(next).catch(next)
+    } else {
+      next()
+    }
+  }
+})
+```
+
+## 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 :
+
+``` js
+// store/modules/foo.js
+export default {
+  namespaced: true,
+  // IMPORTANT: l'état doit être une fonction sinon le module ne
+  // pourra pas être instancié de multiples fois
+  state: () => ({
+    count: 0
+  }),
+  actions: {
+    inc: ({ commit }) => commit('inc')
+  },
+  mutations: {
+    inc: state => state.count++
+  }
+}
+```
+
+Nous pouvons utiliser `store.registerModule` pour enregistrer ce module à la volée dans le hook `asyncData` du composant :
+
+``` html
+// inside a route component
+<template>
+  <div>{{ fooCount }}</div>
+</template>
+
+<script>
+// importer le module d'ici et non de `store/index.js`
+import fooStoreModule from '../store/modules/foo'
+
+export default {
+  asyncData ({ store }) {
+    store.registerModule('foo', fooStoreModule)
+    return store.dispatch('foo/inc')
+  },
+
+  // IMPORTANT: il faut éviter le double enregistrement de module côté client
+  // quand la route est visitée plusieurs fois.
+  destroyed () {
+    this.$store.unregisterModule('foo')
+  },
+
+  computed: {
+    fooCount () {
+      return this.$store.state.foo.count
+    }
+  }
+}
+</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.
+
+---
+
+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/fr/head.md b/fr/head.md
new file mode 100644
index 00000000..8b4cdbef
--- /dev/null
+++ b/fr/head.md
@@ -0,0 +1,90 @@
+# Gestion des entêtes
+
+Similaire à l'injection de fichier, la gestion des entêtes suit la même idée : nous pouvons dynamiquement attacher des données au rendu `context` dans le cycle de vie du composant, et interpoler ses données dans le template.
+
+> Dans la version 2.3.2+, vous pouvez directement accéder au contexte SSR du composant via `this.$ssrContext`. Dans les versions plus anciennes, vous devez injecter manuellement le contexte SSR en le passant à la fonction `createApp()` et ainsi l'exposer dans `$options` de l'instance racine — les composants enfants pouvant y accéder via `this.$root.$options.ssrContext`.
+
+Nous pouvons écrire un mixin simple pour effectuer la gestion du titre :
+
+``` js
+// title-mixin.js
+
+function getTitle (vm) {
+  // les composants doivent simplement fournir une option `title`
+  // pouvant être soit une chaîne de caractères soit une fonction
+  const { title } = vm.$options
+  if (title) {
+    return typeof title === 'function'
+      ? title.call(vm)
+      : title
+  }
+}
+
+const serverTitleMixin = {
+  created () {
+    const title = getTitle(this)
+    if (title) {
+      this.$ssrContext.title = title
+    }
+  }
+}
+
+const clientTitleMixin = {
+  mounted () {
+    const title = getTitle(this)
+    if (title) {
+      document.title = title
+    }
+  }
+}
+
+// `VUE_ENV` peut être injecté avec `webpack.DefinePlugin`
+export default process.env.VUE_ENV === 'server'
+  ? serverTitleMixin
+  : clientTitleMixin
+```
+
+Maintenant, un composant de route peut être utilisé ainsi pour contrôler le titre du document :
+
+``` js
+// Item.vue
+export default {
+  mixins: [titleMixin],
+  title () {
+    return this.item.title
+  }
+
+  asyncData ({ store, route }) {
+    return store.dispatch('fetchItem', route.params.id)
+  },
+
+  computed: {
+    item () {
+      return this.$store.state.items[this.$route.params.id]
+    }
+  }
+}
+```
+
+Et passé au moteur de rendu de paquetage dans le template.
+
+``` html
+<html>
+  <head>
+    <title>{{ title }}</title>
+  </head>
+  <body>
+    ...
+  </body>
+</html>
+```
+
+**Notes :**
+
+- Utilisez les doubles moustaches (interpolation de HTML échapé) 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.
+
+---
+
+En utilisant la même stratégie, vous pouvez facilement étendre votre mixin en une fonction utilitaire générique de gestion des entêtes.
diff --git a/fr/hydration.md b/fr/hydration.md
new file mode 100644
index 00000000..54555261
--- /dev/null
+++ b/fr/hydration.md
@@ -0,0 +1,32 @@
+# Hydratation côté client
+
+Dans `entry-client.js`, nous montons simplement l'application avec cette ligne :
+
+``` js
+// supposons que l'élément racine du template App.vue possède `id="app"`
+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.
+
+Si vous inspectez le rendu en sortie côté serveur, vous remarquerez que l'élément racine a un attribut spécial :
+
+``` js
+<div id="app" data-server-rendered="true">
+```
+
+L'attribut spécial `data-server-rendered` permet à Vue, depuis le côté client, de savoir quelle balise a été rendue par le serveur et d'être capable de monter l'application en mode hydratation.
+
+En mode développement, Vue va vérifier que le DOM virtuel généré côté client concorde avec la structure du DOM rendu par le serveur. S'il y a non concordance, il va bypasser l'hydratation, retirer le DOM existant et refaire le rendu depuis le début. **En mode production, ces vérifications sont désactivées pour des performances maximales.**
+
+### Limitation de l'hydration
+
+Une chose qu'il faut savoir est qu'en utilisant un SSR + une hydratation côté client il y a plusieurs structures HTML spéciales qui sont altérées par le navigateur. Par exemple, quand vous écrivez ceci dans un template Vue :
+
+``` html
+<table>
+  <tr><td>salut</td></tr>
+</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.
diff --git a/fr/routing.md b/fr/routing.md
new file mode 100644
index 00000000..df8fb9a2
--- /dev/null
+++ b/fr/routing.md
@@ -0,0 +1,156 @@
+# Routage et scission du code
+
+## 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 !
+
+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` :
+
+``` js
+// router.js
+import Vue from 'vue'
+import Router from 'vue-router'
+
+Vue.use(Router)
+
+export function createRouter () {
+  return new Router({
+    mode: 'history',
+    routes: [
+      // ...
+    ]
+  })
+}
+```
+
+Et modifier `app.js` :
+
+``` js
+// app.js
+import Vue from 'vue'
+import App from './App.vue'
+import { createRouter } from './router'
+
+export function createApp () {
+  // crée l'instance du routeur
+  const router = createRouter()
+
+  const app = new Vue({
+    // injecte le routeur dans l'instance de Vue
+    router,
+    render: h => h(App)
+  })
+
+  // retourne l'application et le routeur
+  return { app, router }
+}
+```
+
+Maintenant, il faut implémenter la logique des routes côté serveur dans `entry-server.js` :
+
+``` js
+// entry-server.js
+import { createApp } from './app'
+
+export default context => {
+  // vu qu'il peut potentiellement avoir des composants ou des hooks
+  // de routes asynchrones, on retourne une Promesse (« Promise ») de telle sorte que
+  // le serveur patiente jusqu'à ce que tout soit prêt pour le rendu.
+  return new Promise((resolve, reject) => {
+    const { app, router } = createApp()
+
+    // défini la location du routeur serveur
+    router.push(context.url)
+
+    // on attend que le routeur ait terminé de traiter avec les composants et
+    // hooks asynchrones
+    router.onReady(() => {
+      const matchedComponents = router.getMatchedComponents()
+      // pas de routes correspondantes, on rejette la requête avec une 404
+      if (!matchedComponents.length) {
+        return reject({ code: 404 })
+      }
+
+      // la Promise doit résoudre l'instance de l'application qui pourra
+      // ensuite être rendue
+      resolve(app)
+    }, reject)
+  })
+}
+```
+
+En assumant que le bundle serveur soit déjà fait (encore une fois, on ignore l'étape de configuration du build pour l'instant), l'usage de ce bundle ressemblerait à ça :
+
+
+``` js
+// server.js
+const createApp = require('/path/to/built-server-bundle.js')
+
+server.get('*', (req, res) => {
+  const context = { url: req.url }
+
+  createApp(context).then(app => {
+    renderer.renderToString(app, (err, html) => {
+      if (err) {
+        if (err.code === 404) {
+          res.status(404).end('Page non trouvée')
+        } else {
+          res.status(500).end('Erreur interne du serveur')
+        }
+      } else {
+        res.end(html)
+      }
+    })
+  })
+})
+```
+
+## Scission du code
+
+La scission du code, ou les parties chargées à la volée de votre application, aide à réduire la quantité de ressources qui a besoin d'être téléchargée par le navigateur pour le rendu initial, et peut grandement améliorer le TTI (time-to-interactive) pour les grosses applications. Le but est de « charger uniquement ce qui est nécessaire » pour l'écran initial.
+
+Vue permet de créer des composants asynchrones en respectant le concept d'[objet de première classe](https://fr.wikipedia.org/wiki/Objet_de_premi%C3%A8re_classe). En les combinant avec [le support de webpack 2 pour l'utilisation de l'importation dynamique pour scinder le code](https://webpack.js.org/guides/code-splitting-async/), tout ce que vous avez à faire est :
+
+``` js
+// changer ça :
+import Foo from './Foo.vue'
+
+// pour ça :
+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 :
+
+``` js
+// entry-client.js
+
+import { createApp } from './app'
+
+const { app, router } = createApp()
+
+router.onReady(() => {
+  app.$mount('#app')
+})
+```
+
+Un exemple de configuration de route avec des composants asynchrones :
+
+``` js
+// router.js
+import Vue from 'vue'
+import Router from 'vue-router'
+
+Vue.use(Router)
+
+export function createRouter () {
+  return new Router({
+    mode: 'history',
+    routes: [
+      { path: '/', component: () => import('./components/Home.vue') },
+      { path: '/item/:id', component: () => import('./components/Item.vue') }
+    ]
+  })
+}
+```
diff --git a/fr/streaming.md b/fr/streaming.md
new file mode 100644
index 00000000..4a91254a
--- /dev/null
+++ b/fr/streaming.md
@@ -0,0 +1,34 @@
+# Envoi par flux
+
+`vue-server-renderer` supporte nativement le rendu par flux (« stream »), aussi bien pour le moteur de rendu de base que pour le moteur de rendu de paquetage. Tout ce dont vous avez besoin est d'utiliser `renderToStream` à la place de `renderToString` :
+:
+
+``` js
+const stream = renderer.renderToStream(context)
+```
+
+La valeur retournée est un [flux Node.js](https://nodejs.org/api/stream.html) :
+
+``` js
+let html = ''
+
+stream.on('data', data => {
+  html += data.toString()
+})
+
+stream.on('end', () => {
+  console.log(html) // render complete
+})
+
+stream.on('error', err => {
+  // handle error...
+})
+```
+
+## Limitations de flux
+
+En mode de rendu par flux, la donnée est émise aussitôt que possible quand le moteur parcourt l'arbre du DOM virtuel. Cela signifie que l'envoi au client du « premier fragment » commence rapidement.
+
+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.
diff --git a/fr/structure.md b/fr/structure.md
new file mode 100644
index 00000000..a4ab7a64
--- /dev/null
+++ b/fr/structure.md
@@ -0,0 +1,123 @@
+# Structure de code
+
+## Eviter 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.
+
+Comme vu dans l'exemple de base, nous **créons une nouvelle instance de Vue principale pour chaque requête.** Cela est similaire au fait que chaque utilisateur utilise une nouvelle instance de l'application dans son propre navigateur. Si nous utilisons une instance partagée entre plusieurs requêtes, nous prenons le risque d'une pollution d'état entre requêtes.
+
+Ainsi, au lieu de créer directement une instance d'application, nous devons exposer une fonction de fabrique qui peut être exécutée à plusieurs reprises pour créer de nouvelles instances d'application pour chaque requête :
+
+``` js
+// app.js
+const Vue = require('vue')
+
+module.exports = function createApp (context) {
+  return new Vue({
+    data: {
+      url: context.url
+    },
+    template: `<div>L'URL visible est : {{ url }}</div>`
+  })
+}
+```
+
+Et notre code serveur devient :
+
+``` js
+// server.js
+const createApp = require('./app')
+
+server.get('*', (req, res) => {
+  const context = { url: req.url }
+  const app = createApp(context)
+
+  renderer.renderToString(app, (err, html) => {
+    // gérer l'erreur...
+    res.end(html)
+  })
+})
+```
+
+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.
+
+## Introduction à l'étape de build
+
+Jusqu'ici, nous n'avons pas encore discuté d'une méthode pour disposer de la même application Vue côté client. Pour cela, nous devons utiliser webpack pour fabriquer le bundle de notre application Vue. En fait, nous voulons probablement utiliser aussi webpack pour le bundle serveur, parce que :
+
+- Les applications typiques Vue sont construites avec webpack et `vue-loader`, et beaucoup d'autres fonctionnalités spécifiques à webpack telles que l'import de fichiers via `file-loader`, ou encore l'import de CSS avec `css-loader` qui ne fonctionneraient pas directement en Node.js.
+
+- Bien que la dernière version de Node.js supporte pleinement ES2015, nous avons toujours besoin de transpiler le code client pour prendre en charge les anciens navigateurs. Cela implique à nouveau une étape de build.
+
+L'idée de base est donc que nous utiliserons webpack pour empaqueter notre application à la fois pour le client et le serveur. Le bundle serveur sera nécessaire au serveur et utilisé pour le rendu côté serveur, alors que le bundle client sera envoyé au navigateur pour hydrater le DOM client.
+
+![architecture](https://cloud.githubusercontent.com/assets/499550/17607895/786a415a-5fee-11e6-9c11-45a2cfdf085c.png)
+
+Nous allons discuter des détails de la mise en place dans les prochaines sections. Pour l'instant, considérons que nous avons configuré le build et que nous pouvons écrire le code de notre application Vue avec webpack.
+
+## Structure du code avec webpack
+
+Maintenant que nous utilisons webpack pour développer l'application à la fois côté serveur et côté client, la majorité de notre code source peut être écrite d'une manière universelle, avec l'accès à toutes les fonctionnalités fournies par webpack. Pour autant, il y a [un certain nombre de choses](./universal.md) que vous devez garder à l'esprit en écrivant du code universel.
+
+Voici ce à quoi pourrait ressembler un projet :
+
+``` bash
+src
+├── components
+│   ├── Foo.vue
+│   ├── Bar.vue
+│   └── Baz.vue
+├── App.vue
+├── app.js # point d'entrée universel
+├── entry-client.js # code exécuté côté navigateur exclusivement
+└── entry-server.js # code exécuté côté serveur exclusivement
+```
+
+### `app.js`
+
+`app.js` est l'entrée universelle de notre application. Dans une application exclusivement client, nous aurions créé l'instance de Vue principale directement dans ce fichier, et elle aurait été attachée au DOM. Pour le SSR cette responsabilité est déplacée dans le fichier d'entrée réservé au client. `app.js` exporte simplement une fonction `createApp`:
+
+``` js
+import Vue from 'vue'
+import App from './App.vue'
+
+// exporte une fonction de fabrique pour créer de nouvelles instances
+// de l'application, du routeur et du store
+export function createApp () {
+  const app = new Vue({
+    // l'instance racine rend simplement le composant App.
+    render: h => h(App)
+  })
+  return { app }
+}
+```
+
+### `entry-client.js`:
+
+L'entrée client crée simplement l'application et l'attache au DOM :
+
+``` js
+import { createApp } from './app'
+
+// logique de démarrage spécifique au client
+
+const { app } = createApp()
+
+// nous partons du principe que l'élément racine du template App.vue a pour `id="app"`
+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.
+
+``` js
+import { createApp } from './app'
+
+export default context => {
+  const { app } = createApp()
+  return app
+}
+```
diff --git a/fr/universal.md b/fr/universal.md
new file mode 100644
index 00000000..427c8b5e
--- /dev/null
+++ b/fr/universal.md
@@ -0,0 +1,33 @@
+# Écrire du code universel
+
+Avant d'aller plus loin, prenons un moment pour discuter des contraintes lorsque l'on écrit du code « universel » ; c'est à dire du code qui s'exécute à la fois côté serveur et côté client. En raison des différences d'API entre les deux plateformes, le comportement de notre code ne sera pas exactement le même selon l'environnement. Nous allons examiner les points clés dont vous devez avoir connaissance.
+
+## Réactivité des données côté serveur
+
+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.
+
+## 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`.
+
+## Accès aux APIs spécifiques à la plateforme
+
+Le code universel ne peut pas accéder aux APIs spécifiques à une plateforme. Ainsi, si votre code utilise directement les variables globales exclusives au navigateur comme `window` ou `document`, elles lèveront des erreurs si elles sont exécutées sur Node.js, et vice-versa.
+
+Pour les tâches partagées entre le serveur et le client, mais qui utilisent des APIs différentes selon la plateforme, il est recommandé d'encapsuler le code spécifique à la plateforme dans une API universelle, ou d'utiliser des bibliothèques qui le font pour vous. Par exemple, [axios](https://github.com/mzabriskie/axios) est un client HTTP qui présente la même API côté serveur et côté client.
+
+Pour les APIs exclusives au navigateur, l'approche habituelle est de les utiliser dans les hooks de cycle de vie exclusifs au client.
+
+Notez que si une bibliothèque tierce n'est pas écrite avec l'objectif d'être universelle, cela peut être délicat de l'intégrer dans une application rendue côté serveur. Vous *devriez* être capable de la faire fonctionner en substituant certaines variables globales, mais cela serait cavalier et pourrait interférer avec du code de détection d'environnement des autres bibliothèques.
+
+## Directives personnalisées
+
+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)
+
+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