Review syntaxical and ortho-typo mistakes on design-sprintt

README.md

@@ -24,20 +24,20 @@ On peut considérer cette méthode comme du Design piloté par des tests (Test D
 ## Travail préparatoire
 Avant le début du Design Sprint, le client doit trouver 5 personnes pour des tests utilisateurs que nous pratiquerons dans la dernière phase.
 
-Il doit également faire un travail de recherche pour rassembler et identifier précisément le problème que le produit doit résoudre, les produits comparables ou concurrents, et receuillir des témoignages ou métriques pour illustrer le marché potentiel.
+Il doit également faire un travail de recherche pour rassembler et identifier précisément le problème que le produit doit résoudre, les produits comparables ou concurrents, et recueillir des témoignages ou métriques pour illustrer le marché potentiel.
 
 Nous effectuons de notre côté aussi ces recherches là, et pouvons même être amenés à effectuer des interviews d'utilisateurs ou des sondages en amont.
 
 ## Comprendre
-Durant cette phase, nous devons réussir a comprendre, en faisant preuve d'empathie, les utilisateurs finaux, ainsi que les besoins business du produit.
+Durant cette phase, nous devons réussir à comprendre en faisant preuve d'empathie, les utilisateurs finaux, ainsi que les besoins business du produit.
 
 Nous prenons des notes, sur un grand tableau ou sur des post-its qu'on colle sur les murs de la pièce.
 
-Avant chaque phase, le client commence par nous faire un "[pitch](https://en.wikipedia.org/wiki/Elevator_pitch)" de son produit, ce qui va l'exercer à présenter très rapidement son produit comme si nous étions des investisseurs qu'il devait convaincre. Ca nous aide à identifier le segment d'utilisateurs ciblés, leur problème, et la valeur que le produit doit leur apporter. Cela nous permet également de commencer à identifier le vocabulaire du domaine.
+Avant chaque phase, le client commence par nous faire un "[pitch](https://en.wikipedia.org/wiki/Elevator_pitch)" de son produit, ce qui va l'exercer à présenter très rapidement son produit comme si nous étions des investisseurs qu'il devait convaincre. Ça nous aide à identifier le segment d'utilisateurs ciblés, leur problème et la valeur que le produit doit leur apporter. Cela nous permet également de commencer à identifier le vocabulaire du domaine.
 
-Ensuite, nous analysons ensemble les ressources extraites du travail de recherche préalablement effectué. Ca nous permet de comprendre les besoins des utilisateurs du segment, le [Tunnel d'achat](https://en.wikipedia.org/wiki/Purchase_funnel), et la taille du marché représenté par le segment ciblé.
+Ensuite, nous analysons ensemble les ressources extraites du travail de recherche préalablement effectué. Ça nous permet de comprendre les besoins des utilisateurs du segment, le [Tunnel d'achat](https://en.wikipedia.org/wiki/Purchase_funnel), et la taille du marché représenté par le segment ciblé.
 
-Enfin, nous élaborons et représentons ce sur quoi nous allons travailler pendant le reste du Design Sprint : [le chemin critique](https://en.wikipedia.org/wiki/Critical_path_method) du produit. Nous essayons de rester "haut niveau" en spécifiant le minimum de détails possible. Une bonne question à se poser pour aider à élaborer le chemin critique est : Qu'est ce que vos utilisateurs essaient d'accomplir ?
+Enfin, nous élaborons et représentons ce sur quoi nous allons travailler pendant le reste du Design Sprint : [le chemin critique](https://en.wikipedia.org/wiki/Critical_path_method) du produit. Nous essayons de rester "haut niveau" en spécifiant le minimum de détails possible. Une bonne question à se poser pour aider à élaborer le chemin critique est : Qu'est ce que vos utilisateurs essaient de déléguer au produit ?
 >[What job is the user hiring the product to do?](https://www.youtube.com/watch?v=f84LymEs67Y)
 
 ![Chemin Critique](http://playbook.thoughtbot.com/images/criticalpath.jpg)
@@ -51,12 +51,12 @@ Avant cette phase, nous prenons du temps pour relire les post-its, les schémas,
 
 Nous commençons la séance par un nouveau pitch, illustrant le chemin critique.
 
-Chacun dessine ensuite une dizaine d'interfaces utilisateurs et imaginons les enchainements entre celles-ci.
+Chacun dessine ensuite une dizaine d'interfaces utilisateurs et imagine les enchaînements entre celles-ci.
 Nous les accrochons ensuite aux murs et prenons le temps de les observer et de les analyser de manière individuelle. Nous collons des pastilles sur les interfaces et enchaînements d'interfaces que nous aimons. Cela aide à identifier visuellement les meilleurs idées.
 
 Nous discutons ensuite ensemble pendant ~3 minutes de chacune d'entre elles de manière objective et argumentée.
 
-Le client va ensuite effectuer un "super vote" pour l'idée qu'il pense être la meilleure. Cela nous aide à comprendre la façon dont il prend des décisions et lui permet "d'affirmer son autorité".
+Le client va ensuite effectuer un "super vote" pour l'idée qu'il pense être la meilleure. Cela nous aide à comprendre la façon dont il prend des décisions et cela lui permet aussi "d'affirmer son autorité".
 
 ## Converger
 Dans cette phase, nous arrêtons d'imaginer de nouvelles solutions et nous convergeons sur celle que nous pensons être la meilleure.
@@ -65,9 +65,9 @@ Nous commençons par identifier et lister toutes les hypothèses que nous faison
 
 ![Tableau d'hypothèses](http://playbook.thoughtbot.com/images/assumptions.jpg)
 
-Nous regardons ensuite s'il existe des conflits entre les notes et post-its restants, et les interfaces et leur enchainement que nous avons retenu.
+Nous regardons ensuite s'il existe des conflits entre les notes et post-its restants, les interfaces et les enchaînement que nous avons retenu.
 
-Nous décidons ensuite si nous nous concentrons sur un seul prototype ("best shot"), ou plusieurs ("battle royale"). Réaliser plusieurs prototypes représente plus de travail initial mais peuvent permettre de mettre en lumière plus de choses et de se rendre compte plus rapidement de la viabilité du produit.
+Nous décidons ensuite si nous nous concentrons sur un seul prototype ("best shot"), ou plusieurs ("battle royal"). Réaliser plusieurs prototypes représente plus de travail initial mais peuvent permettre de mettre en lumière plus de choses et de se rendre compte plus rapidement de la viabilité du produit.
 
 Puis nous réalisons des [storyboards](https://en.wikipedia.org/?title=Storyboard) pour chaque prototype. Ce sont des sortes de BD illustrant un utilisateur parcourant le chemin critique.
 
@@ -95,7 +95,7 @@ Nous pouvons, pour une application web classique, réaliser une première versio
 
 Cette première version permet d'apprendre beaucoup de choses, et d'essayer de valider ou pas la viabilité du produit et de son business model.
 
-Si le business model n'est pas viable, que le problème qu'il résout n'est pas un problème suffisament douloureux, que la valeur qu'il apporte n'est pas suffisante, ou que trop de nos hypothèses sont fausses, cela peut être considéré comme un échec, mais en réalité c'est un succès. Du temps et de l'argent ont été économisés, car nous nous en serons rendu compte rapidement.
+Si le business model n'est pas viable, que le problème résolu par le produit n'est pas assez important, que la valeur qu'il apporte n'est pas suffisante, ou que trop de nos hypothèses sont fausses, cela peut être considéré comme un échec, mais en réalité c'est un succès. Du temps et de l'argent ont été économisés, car nous nous en serons rendu compte rapidement.
 
 # Plateformes
 ## Applications Web