@DeadalusDev's review

Author: maxirozay

src/v2/cookbook/dockerize-vuejs-app.md

@@ -4,9 +4,9 @@ type: cookbook
 order: 13
 ---
 
-## Simple exemple
+## Exemple simple
 
-Vous avez construit votre app Vue.js en utilisant le magnifique [Vue.js webpack template](https://github.com/vuejs-templates/webpack) et maintenant vous voulez vraiment impressionner vos collègues en montrant que vous pouvez aussi la déployer dans un container Docker.
+Vous avez construit votre app Vue.js en utilisant le magnifique [Vue.js webpack template](https://github.com/vuejs-templates/webpack) et maintenant vous voulez vraiment impressionner vos collègues en montrant que vous pouvez aussi l'exécuter dans un container Docker.
 
 Commençons par créer un `Dockerfile` dans le dossier racine de notre projet.
 
@@ -35,7 +35,7 @@ EXPOSE 8080
 CMD [ "http-server", "dist" ]
 ```
 
-Il peut sembler redondant de copier `package.json` et `package-lock.json` et ensuite tous les fichiers et dossiers du projet en deux étapes différentes mais il y a [une très bonne raison pour ça](http://bitjudo.com/blog/2014/03/13/building-efficient-dockerfiles-node-dot-js/) (résumé: ça nous permet de prendre avantage des Docker layers cachés)
+Il peut sembler redondant de copier `package.json` et `package-lock.json` et ensuite tous les fichiers et dossiers du projet en deux étapes différentes mais il y a [une très bonne raison pour ça](http://bitjudo.com/blog/2014/03/13/building-efficient-dockerfiles-node-dot-js/) (résumé: ça nous permet de prendre avantage de la mise en cache des `Docker layers`)
 
 Maintenant on peut construire l'image Docker de notre app Vue.js :
 
@@ -62,7 +62,7 @@ Néanmoins, pour un réel et complexe cas de production, il serait plus sage de
 Modifions notre `Dockerfile` pour utiliser NGINX:
 
  ```docker
-# étape de construction
+# étape de build
 FROM node:9.11.1-alpine as build-stage
 WORKDIR /app
 COPY package*.json ./
@@ -102,33 +102,33 @@ Si vous lisez ce tutoriel, il y a des chances que vous savez déjà pourquoi vou
 
 La tendance actuelle est de créer des applications en utilisant l'approche [Cloud-Native](https://pivotal.io/cloud-native) qui tourne autour des mots suivant :
 * Microservices
-* DevOps
+* DevOps (Développement Opérationnel)
 * Continuous Delivery
 
 Regardons comment ces concepts affectent notre décision de dockeriser notre app Vue.js.
 
 ### Les effets des microservices
 
-En adoptant le [style d'architectural des microservices](https://martinfowler.com/microservices/), on finit par construire une seule application comme une suite de petits services, chaque service est lancé de manière indépendante et communique avec des mécanismes léger. Ces services sont construit autour des besoins du business et sont déployés indépendamment par des méthodes de déploiement automatisées.
+En adoptant le [style d'architectural des microservices](https://martinfowler.com/microservices/), on finit par construire une seule application comme une suite de petits services, chaque service est lancé de manière indépendante et communique avec des mécanismes léger. Ces services sont construits autour des besoins du business et sont déployés indépendamment via des méthodes de déploiement automatisées.
 
-Alors, utiliser cette approche d'architecture implique dans la plupart des cas de développer et délivrer notre front-end comme un service indépendant.
+Alors, utiliser cette approche architecturale implique dans la plupart des cas de développer et livrer notre front-end comme un service indépendant.
 
 ### Les effets du DevOps
 
-L'adoption de la culture, des outils et des pratiques d’ingénierie agile [DevOps](https://martinfowler.com/bliki/DevOpsCulture.html) a, entre autres, le bon effet d'augmenter la collaboration entre les rôles de développement et des opérations. Un des principaux problèmes dans le passé (mais aussi aujourd'hui parfois) est que l'équipe de développement tend à être intéressée par les opérations et la maintenance du système une fois que ça a été donné à l'équipe d'opération (ops), et cette dernière tend à ne pas être vraiment au courant du but du système, et donc, réticent à satisfaire les besoins opérationnels du système (aussi appelé "les caprices des développeur")
+L'adoption de la culture, des outils et des pratiques d’ingénierie agile [DevOps](https://martinfowler.com/bliki/DevOpsCulture.html) a, entre autres, le bon effet d'augmenter la collaboration entre les rôles de développement et des opérations. Un des principaux problèmes dans le passé (et encore aujourd'hui parfois) est que l'équipe de développement tend à être intéressée par les opérations et la maintenance du système une fois que ça a été donné à l'équipe d'intégration (DevOps), et cette dernière tend à ne pas être vraiment au courant du but du système, et donc est réticente à satisfaire les besoins opérationnels du système (aussi appelé "les caprices des développeurs")
 
-Délivrer notre app Vue.js avec une image Docker aide à réduire, sinon supprimer totalement, les différences entre lancer le service sur l'ordinateur d'un développeur, un environnement de production ou n'importe quel autre environnement.
+livrer notre app Vue.js avec une image Docker aide à réduire, sinon supprimer totalement, les différences entre lancer le service sur l'ordinateur d'un développeur, un environnement de production ou n'importe quel autre environnement.
 
 ### Les effets du déploiement continue (Continuous Delivery)
 
-En utilisant la [déploiement continue](https://martinfowler.com/bliki/ContinuousDelivery.html) on construit nos logiciels de manière à ce qu'ils peuvent potentiellement être déployer en production n'importe quand. Ces pratiques d'ingénierie sont permit grâce à ce qui est normalement appelé le [pipeline de déploiement continue](https://martinfowler.com/bliki/DeploymentPipeline.html). Le but d'un pipeline de déploiement continue est de fragmenté notre construction en plusieurs étapes (par exemple : la compilation, les tests unitaires, les tests d’intégration, les tests de performance, etc) et laissé chaque étape vérifier notre artefact de construction quand notre logiciel change. Chaque étape augmente notre confiance dans la stabilité de la construction de notre artefact, et donc, réduit le risque de casser quelque chose en production (ou n'importe quel autre environnement).
+En utilisant le [déploiement continue](https://martinfowler.com/bliki/ContinuousDelivery.html) on construit nos logiciels de manière à ce qu'ils puissent potentiellement être déployés en production n'importe quand. Ces pratiques d'ingénierie sont permises grâce à ce qui est normalement appelé le [pipeline de déploiement continue](https://martinfowler.com/bliki/DeploymentPipeline.html). Le but d'un pipeline de déploiement continue est de fragmenté notre build en plusieurs étapes (par exemple : la compilation, les tests unitaires, les tests d’intégration, les tests de performance, etc) et laisser chaque étape vérifier notre artefact de build quand notre logiciel change. Chaque étape augmente notre confiance dans la stabilité du build de notre artefact, et donc, réduit le risque de casser quelque chose en production (ou n'importe quel autre environnement).
 
-Alors, créer une image Docker pour notre app Vue.js est une bonne chose car ça représente notre artefact de construction final, le même artefact qui va être utilisé localement pour le développement et qui peut être utilisé pour le déploiement en production avec confiance.
+Alors, créer une image Docker pour notre app Vue.js est une bonne chose car ça représente notre artefact de build final, le même artefact qui va être utilisé localement pour le développement et qui peut être utilisé pour le déploiement en production avec confiance.
 
 ## Modèles alternatifs
 
-Si votre entreprise n'est pas encore intéressée par Docker et Kubernetes ou vous voulez simplement déployer votre MVP, peut être que votre app Vue.js n'est pas ce qu'il vous faut.
+Si votre entreprise n'est pas encore intéressée par Docker et Kubernetes ou que vous voulez simplement déployer votre MVP, peut être que dockeriser votre app Vue.js n'est pas ce qu'il vous faut.
 
 Il existe d'autres alternatives comme :
 * utiliser une plateforme tout-en-un comme [Netlify](https://www.netlify.com/);
-* héberger votre SPA sur [Amazon S3](https://aws.amazon.com/s3/) et la servir avec [Amazon CloudFront](https://aws.amazon.com/cloudfront/) (voir [ce](https://serverless-stack.com/chapters/deploy-the-frontend.html) pour un guide détaillé).
+* héberger votre SPA sur [Amazon S3](https://aws.amazon.com/s3/) et la servir avec [Amazon CloudFront](https://aws.amazon.com/cloudfront/) (voir [ici](https://serverless-stack.com/chapters/deploy-the-frontend.html) pour un guide détaillé).