diff --git a/sections/chapters/analyseCritique/index.tex b/sections/chapters/analyseCritique/index.tex
index 6ba83ed..0a24003 100644
--- a/sections/chapters/analyseCritique/index.tex
+++ b/sections/chapters/analyseCritique/index.tex
@@ -15,7 +15,7 @@ \section{Conclusion}
 Cela nous conforte dans l'idée que notre plateforme a des chances de devenir mature et utilisable par une communauté. 
 Quoi qu'il en soit, notre projet est \textit{Open Source} et pourra donc toujours évoluer avec sa communauté. 
 C'est d'ailleurs notre plus grand souhait pour cette plateforme.
-La qualité technique du code est assurée par les différentes métriques énoncés précédemment (cf. section \ref{section:codeMetrics}).\\
+La qualité technique du code est assurée par les différentes métriques énoncées précédemment (cf. section \ref{section:codeMetrics}).\\
 
 Au niveau du planning, il semble que nous ayons respecté ce qui était initialement mis en place au vu de nos graphes d'activité. 
 Nous avons tenté d'être constants tout au long du projet, car ce dernier demande beaucoup d'investissement en matière de recherche et de développement. 
diff --git a/sections/chapters/analyseCritique/validationExterne.tex b/sections/chapters/analyseCritique/validationExterne.tex
index 6f0c9d0..03fa437 100644
--- a/sections/chapters/analyseCritique/validationExterne.tex
+++ b/sections/chapters/analyseCritique/validationExterne.tex
@@ -105,7 +105,7 @@ \subsection*{Points faibles}
 
 \begin{enumerate}
     \item \texttt{SourceCode} pourra très rapidement posséder une riche bibliothèque de \glspl{resinfo} rien qu'avec les exercices stockés sur la plateforme \textit{INGInious}. Avec la promotion de la plateforme auprès d'autres institutions scolaires, \texttt{SourceCode} pourrait alors prétendre à une popularité certaine dans le monde des ressources partagées. Il s'agit alors de savoir vendre son produit avec les bons arguments...
-    \item Nous n'avions pas pensé à cela pour le prototype. Nous voulions d'abord créer un système cohérent et fonctionnel au niveau de la gestion des \glspl{resinfo} et \glspl{tag}. Les différents statuts attribuables à ces mêmes \glspl{resinfo} et \glspl{tag} jouent déjà un rôle majeur dans la gestion (ex: trier les \glspl{resinfo} non valides ou en attente de validation ...). En termes d'améliorations, nous pourrions automatiser le processus de validation afin que les administrateurs ne soient pas débordés (cf. chapitre \ref{chapter:pourAllerPlusLoin}).
+    \item Nous n'avions pas pensé à cela pour le prototype. Nous voulions d'abord créer un système cohérent et fonctionnel au niveau de la gestion des \glspl{resinfo} et \glspl{tag}. Les différents statuts attribuables à ces mêmes \glspl{resinfo} et \glspl{tag} jouent déjà un rôle majeur dans la gestion (ex. trier les \glspl{resinfo} non valides ou en attente de validation,...). En termes d'améliorations, nous pourrions automatiser le processus de validation afin que les administrateurs ne soient pas débordés (cf. chapitre \ref{chapter:pourAllerPlusLoin}).
     \item C'est un point intéressant pour nous. \texttt{SourceCode} est une application qui tente de faciliter le plus possible la recherche et la gestion de \glspl{resinfo} (système de filtres, historique, favoris ...). Malheureusement, ajouter une pléthore de fonctionnalités peut aussi devenir une barrière à l'utilisation, car l'utilisateur doit d'abord apprendre à les maîtriser. Une des premières solutions que nous avons mises en place était la création d'une section tutoriel sur la plateforme, mais cela n'est qu'une solution de contournement. Une autre idée serait de prévoir une interface en fonction du public ciblé (débutant, "tech savvy" ...).
 \end{enumerate}
 
diff --git a/sections/chapters/analyseCritique/validationInterne.tex b/sections/chapters/analyseCritique/validationInterne.tex
index 4bfd968..5bc96d6 100644
--- a/sections/chapters/analyseCritique/validationInterne.tex
+++ b/sections/chapters/analyseCritique/validationInterne.tex
@@ -17,7 +17,7 @@ \subsection{Statistiques}
     \end{itemize}
     \item Nombre de tests fonctionnels (\gls{backend}) : 48
     \begin{itemize}[nosep,noitemsep,topsep=0pt,partopsep=0pt,after=\vspace*{2pt}]
-        \item Plutôt que de tester individuellement chaque partie de l'application (comme le ferait des tests 
+        \item Plutôt que de tester individuellement chaque partie de l'application (comme le feraient des tests 
         unitaires\footnote{
             \href{https://fr.wikipedia.org/wiki/Test\_unitaire}{https://fr.wikipedia.org/wiki/Test\_unitaire}
         }), nous avons choisi cette approche, de type boîte noire (c.-à-d. sans connaitre le code source), qui consiste à vérifier si les spécifications (cf. section \ref{section:analyseFonctionnelle}) sont respectées par le logiciel ainsi développé.
@@ -28,13 +28,13 @@ \subsection{Statistiques}
         \item Il s'agit de mesurer la proportion du code source exécutée lors de tests\footnote{
             Vous pouvez consulter les résultats depuis \href{https://codecov.io/gh/SourceCodeOER/sourcecode\_api/branch/master}{https://codecov.io/gh/SourceCodeOER/sourcecode\_api/branch/master}
         } : nous considérons ici la définition générale, car celle-ci peut se décliner sous d'autres formes\footnote{
-            \href{https://fr.wikipedia.org/wiki/Couverture\_de\_code}{https://fr.wikipedia.org/wiki/Couverture\_de\_code}, \cite{concept_cfg}, ...
+            \href{https://fr.wikipedia.org/wiki/Couverture\_de\_code}{https://fr.wikipedia.org/wiki/Couverture\_de\_code}, \cite{concept_cfg},...
         }.
         Veuillez noter que nous avons exclu du calcul quelques lignes difficiles, voire impossibles à tester afin d'avoir un taux plus réaliste.
     \end{itemize}
     \item Note Codacy de qualité du code (\gls{backend} / \gls{frontend}) :  A / B
     \begin{itemize}[nosep,noitemsep,topsep=0pt,partopsep=0pt,after=\vspace*{2pt}]
-        \item Il s'agit d'une plateforme qui analyse le code source pour produire diverses mesures (pourcentage de code dupliqué, complexité du code ...).
+        \item Il s'agit d'une plateforme qui analyse le code source pour produire diverses mesures (pourcentage de code dupliqué, complexité du code,...).
         Elle vérifie / analyse également la lisibilité du code en fonction de conventions de codage courantes\footnote{
             Vous pouvez consulter ces rapports sur \href{https://app.codacy.com/gh/SourceCodeOER/sourcecode\_api/dashboard}{https://app.codacy.com/gh/SourceCodeOER/sourcecode\_api/dashboard} et
             \href{https://app.codacy.com/gh/SourceCodeOER/sourcecode-front/dashboard}{https://app.codacy.com/gh/SourceCodeOER/sourcecode-front/dashboard}
diff --git a/sections/chapters/approche/index.tex b/sections/chapters/approche/index.tex
index db4a993..cb04250 100644
--- a/sections/chapters/approche/index.tex
+++ b/sections/chapters/approche/index.tex
@@ -120,13 +120,13 @@ \subsection*{Conception et implémentation}
 
 Le principal problème avec cette approche est la "compartimentation" qui favorise une connaissance limitée de la totalité des technologies utilisées. Ceci risque de provoquer un arrêt qui, temporairement ou non, nuit à la bonne réalisation de nos objectifs dans les délais fixés si un membre de notre équipe se retrouve dans l'incapacité sa part de travail pour l'une ou l'autre raison. \\
 
-Une solution fréquemment utilisée en entreprise pour pallier à ce problème est d'impliquer plus d'acteurs sur chaque partie du développement ou la totalité du code (avec un système d'affectation des tâches, rotatif ou non). \\
+Une solution fréquemment utilisée en entreprise pour pallier ce problème est d'impliquer plus d'acteurs sur chaque partie du développement ou la totalité du code (avec un système d'affectation des tâches, rotatif ou non). \\
 
 Ce choix n'en est pas dénoué d'avantages, car en outre de permettre une haute maîtrise des technologies utilisées dans chaque partie, on a un interlocuteur unique à qui poser des questions spécifiques.
 
 \subsection*{Rédaction}
 
 
-L'écriture de ce présent manuscrit a rassemblé l'ensemble de notre équipe. En tant que document qui représente l'aboutissement du travail commun accompli, la présence de chacun est indispensable dans sa réalisation. Dès le départ, nous avons accordé une grande importance à celui-ci lors de la planification du travail (représenté par la figure \ref{pic:ganttChart}) car l'ampleur de cette tâche ne s'improvise pas en dernière minute. \\
+L'écriture de ce présent manuscrit a rassemblé l'ensemble de notre équipe. En tant que document qui représente l'aboutissement du travail commun accompli, la présence de chacun est indispensable dans sa réalisation. Dès le départ, nous avons accordé une grande importance à celui-ci lors de la planification du travail (représenté par la figure \ref{pic:ganttChart}), car l'ampleur de cette tâche ne s'improvise pas en dernière minute. \\
 
 L'élaboration de ce document s'est faite par étapes. Tout d'abord, nous avons réalisé un plan de rédaction simplifiée consistant à représenter les divers sujets et points du contenu à aborder autour d'un fil rouge conducteur. Ensuite, un premier jet à réaliser a été attribué au mémorant des différentes parties sous sa responsabilité. Enfin, nous sommes passés par un laborieux processus répété de relecture et d'améliorations continues du texte, notamment orientés par les nombreux commentaires de nos promoteurs.
\ No newline at end of file
diff --git a/sections/chapters/cahierDesCharges/index.tex b/sections/chapters/cahierDesCharges/index.tex
index 66ec58c..9a47e26 100644
--- a/sections/chapters/cahierDesCharges/index.tex
+++ b/sections/chapters/cahierDesCharges/index.tex
@@ -138,7 +138,7 @@ \subsection*{Recherche par \glspl{tag}}
 \textbf{FNC}\footnote{
     Forme normale conjonctive - 
     \url{https://fr.wikipedia.org/wiki/Forme\_normale\_conjonctive}
-}. De ce fait, nous pouvons ainsi exprimer respectivement par une forme non ambigue les exemples de requêtes précédentes \footnote{
+}. De ce fait, nous pouvons ainsi exprimer respectivement par une forme non ambiguë les exemples de requêtes précédentes \footnote{
     Par souci de simplicité, nous n'allons pas introduire de nouvelles notations pour les littéraux : M\textbf{X} devant ici est compris comme "la fiche dispose du \gls{tag} n°X"
 } :
 
@@ -228,7 +228,7 @@ \subsection*{Sécurité}
 consistant en 3 piliers : 
 
 \begin{description}
-    \item[Authentification :] Il s'agit du fait de prouver l'utilisateur que l'on prétend être. Une manière fréquemment utilisée sur de nombreux sites consiste en association d'un nom d'utilisateur et d'un mot de passe.
+    \item[Authentification :] Il s'agit du fait de prouver l'utilisateur que l'on prétend être. Une manière fréquemment utilisée sur de nombreux sites consiste en l'association d'un nom d'utilisateur et d'un mot de passe.
     \item[Autorisation :] Il s'agit du fait de vérifier quelles ressources accessibles et les opérations (par exemple les \Gls{crud}) permises sur celles-ci pour l'utilisateur authentifié.
     \item[Traçabilité :] Il s'agit du fait d'enregistrer tous les faits et gestes des utilisateurs authentifiés. Les informations ainsi collectées permettent principalement de prévenir/comprendre des problèmes. 
 \end{description}
@@ -243,7 +243,7 @@ \subsection*{Ergonomie}
 
 Une application web à destination d'un public varié et conséquent se doit d'avoir une interface simple et efficace pour ne pas perdre ses utilisateurs et gagner en popularité. On pourrait considérer que le design d'une application est subjectif, mais un point à ne sûrement pas négliger se situe autour de l'ergonomie. La question à se poser pour chaque interface est alors de savoir comment disposer les éléments afin de rendre la navigation la plus claire possible. Nous nous sommes donc concentrés sur cette problématique en élaborant un patchwork que vous pouvez consulter à la fin de la section \ref{section:problem}.\\
 
-Au fur et à mesure de nos meetings avec le \textit{Pr. Kim Mens} et \textit{Olivier Goletti}, les conseils et recommandations ont souvent été pris en compte pour améliorer l'expérience utilisateur. Par la même occasion, nous avons fait tester l'application à différents utilisateurs (amis, designer) tout au long de la phase de développement afin de nous faire part de leur ressenti.
+Au fur et à mesure de nos meetings avec le professeur \textit{Kim Mens} et \textit{Olivier Goletti}, les conseils et recommandations ont souvent été pris en compte pour améliorer l'expérience utilisateur. Par la même occasion, nous avons fait tester l'application à différents utilisateurs (amis, designer) tout au long de la phase de développement afin de nous faire part de leur ressenti.
 
 \pagebreak
 \section {Contraintes}
diff --git a/sections/chapters/introduction/index.tex b/sections/chapters/introduction/index.tex
index 4643e82..78d79ca 100644
--- a/sections/chapters/introduction/index.tex
+++ b/sections/chapters/introduction/index.tex
@@ -15,7 +15,7 @@ \section*{Problématique}
 
 \section*{Motivation}
 
-Ce mémoire, réalisé dans le cadre de notre formation, nous permet de mettre en oeuvre ce qui a été enseigné durant notre cursus académique. Partant de rien, si ce n'est qu'avec la vision et les objectifs de nos promoteurs, nous devons en toute autonomie sortir de notre zone de confort pour apporter une solution au problème des \glspl{resinfo} partagées.\\
+Ce mémoire, réalisé dans le cadre de notre formation, nous permet de mettre en œuvre ce qui a été enseigné durant notre cursus académique. Partant de rien, si ce n'est qu'avec la vision et les objectifs de nos promoteurs, nous devons en toute autonomie sortir de notre zone de confort pour apporter une solution au problème des \glspl{resinfo} partagées.\\
 
 Projet axé développement oblige, nous sommes donc confrontés à choisir et utiliser des technologies pour créer la plateforme. En ce sens, nous apprenons au travers de ce mémoire à parfaire nos compétences en développement et à nous familiariser avec de nouveaux outils de développement.
 Enfin, nous espérons que notre travail puisse être profitable au domaine des ressources partagées. Afin de renforcer cette volonté, ce projet est totalement Open Source.
@@ -32,7 +32,7 @@ \section*{Approche}
 
 Après cette phase d'analyse, nous nous sommes attelés à l'architecture de \texttt{SourceCode} à l'aide d'un patchwork présentant les fonctionnalités essentielles de l'application côté \gls{frontend} et de schémas UML pour la base de données.\\
 
-Nous avons ensuite pu travailler sur l'implémentation de \texttt{SourceCode} pour intégrer les fonctionnalités listées dans l'analyse fonctionnelle. Cette phase s'est déroulée durant quasiment toute l'année académique, sous l'oeil avisé de nos promoteurs pour garantir une cohérence dans notre travail.\\
+Nous avons ensuite pu travailler sur l'implémentation de \texttt{SourceCode} pour intégrer les fonctionnalités listées dans l'analyse fonctionnelle. Cette phase s'est déroulée durant quasiment toute l'année académique, sous l'œil avisé de nos promoteurs pour garantir une cohérence dans notre travail.\\
 
 L'étape finale fut la validation du projet, où nous avions convié des utilisateurs pour tester l'application dans son entièreté. Nous voulions nous assurer que notre mémoire fasse sens et soit utile pour la problématique que nous visons. Suite aux diverses remarques, nous avons pu effectuer une dernière itération de développement afin de prendre en considération les commentaires reçus.
 
diff --git a/sections/chapters/pourAllerPlusLoin/index.tex b/sections/chapters/pourAllerPlusLoin/index.tex
index e156f04..78a0abb 100644
--- a/sections/chapters/pourAllerPlusLoin/index.tex
+++ b/sections/chapters/pourAllerPlusLoin/index.tex
@@ -45,6 +45,6 @@ \section{Liste des améliorations}
     \item Intégrer GraphQL à l'\gls{api} pour permettre de charger les données que l'on souhaite, sans forcément multiplier les endpoints en REST.
 \end{itemize}
 
-Nous avons pris plaisir à développer cette plateforme web pour une cause qui nous concerne dans le domaine informatique : le partage, comme pour les projets Open Source. Durant l'année académique, le temps fut notre ennemi mais nous avons fait en sorte de fournir une plateforme fonctionnelle, à défaut qu'elle ne soit pas totalement complète.\\
+Nous avons pris plaisir à développer cette plateforme web pour une cause qui nous concerne dans le domaine informatique : le partage, comme pour les projets Open Source. Durant l'année académique, le temps fut notre ennemi, mais nous avons fait en sorte de fournir une plateforme fonctionnelle, à défaut qu'elle ne soit pas totalement complète.\\
 
-La liste évoquée plus haut peut donc être considérée comme un prochain roadmap de développement. Il y a encore pas mal à réaliser mais nous insistons sur le fait que ce projet est Open Source et utilise des technologies connues (cf. \ref{section:choixTechnologiques}) afin que ça ne devienne pas une barrière au développement.
\ No newline at end of file
+La liste évoquée plus haut peut donc être considérée comme un prochain roadmap de développement. Il y a encore pas mal à réaliser, mais nous insistons sur le fait que ce projet est Open Source et utilise des technologies connues (cf. \ref{section:choixTechnologiques}) afin que ça ne devienne pas une barrière au développement.
\ No newline at end of file
diff --git a/sections/chapters/problematique/index.tex b/sections/chapters/problematique/index.tex
index a971702..cf20ad8 100644
--- a/sections/chapters/problematique/index.tex
+++ b/sections/chapters/problematique/index.tex
@@ -39,7 +39,7 @@ \section{Situation actuelle}
     \label{table:compPlateforme}
 \end{table}
 
-Avant d'aller plus loin, nous tenons à mentionner l'outil \href{https://oer.uclouvain.be/}{OER UCLouvain} hors du champ de notre analyse. En effet, notre projet est une version simplifiée de leur application, car nous ne traitons qu'un seul domaine des \gls{oer} : les \glspl{resinfo}. Par conséquent, le système de recherche que le site propose ne correspond pas à la vision que nous avons pour notre type de plateforme étant donné qu'il est beaucoup plus complexe que ce que nous voulons mettre en place : Un catalogue de \glspl{resinfo}. Néanmoins, nous avons pu discuter avec \textit{Christine Jacqmot}, membre du \textit{Louvain Learning Lab}, afin de lui présenter notre projet et de voir comment se comporte l'outil \href{https://oer.uclouvain.be/}{OER UCLouvain} côté administration. Ses conseils nous ont aidé à améliorer notre prototype et dans le cas échéant, à rajouter dans le chapitre \ref{chapter:pourAllerPlusLoin} des précieuses pistes d'améliorations.
+Avant d'aller plus loin, nous tenons à mentionner l'outil \href{https://oer.uclouvain.be/}{OER UCLouvain} hors du champ de notre analyse. En effet, notre projet est une version simplifiée de leur application, car nous ne traitons qu'un seul domaine des \gls{oer} : les \glspl{resinfo}. Par conséquent, le système de recherche que le site propose ne correspond pas à la vision que nous avons pour notre type de plateforme étant donné qu'il est beaucoup plus complexe que ce que nous voulons mettre en place : Un catalogue de \glspl{resinfo}. Néanmoins, nous avons pu discuter avec \textit{Christine Jacqmot}, membre du \textit{Louvain Learning Lab}, afin de lui présenter notre projet et de voir comment se comporte l'outil \href{https://oer.uclouvain.be/}{OER UCLouvain} côté administration. Ses conseils nous ont aidés à améliorer notre prototype et dans le cas échéant, à rajouter dans le chapitre \ref{chapter:pourAllerPlusLoin} des précieuses pistes d'améliorations.
 \pagebreak
 \subsection*{Practice-it}
 
@@ -80,7 +80,7 @@ \subsubsection*{Qualité(s)}
     \item Le tableau de bord est séparé en plusieurs sections pratiques :
     \begin{itemize}
         \item Compétences de l'utilisateur
-        \item Les différentes compétences proposées (langage de programmation, mathématiques, ...)
+        \item Les différentes compétences proposées (langage de programmation, mathématiques,...)
         \item Tutoriel
     \end{itemize}
     \item Une barre de recherche est disponible pour trouver des exercices / challenges par leur titre.
@@ -137,7 +137,7 @@ \subsubsection*{Défaut(s)}
 
 \begin{itemize}
     \item Malgré un choix varié de \glspl{tag}, ces derniers ne sont pas classés dans des catégories différentes.
-    \item Les \glspl{tag} ne sont pas directement accessibles depuis l'interface car il faut scroller.
+    \item Les \glspl{tag} ne sont pas directement accessibles depuis l'interface, car il faut scroller.
     \item Aucune spécificité au niveau des langages de programmation (exemple: des exercices en C pour la gestion de la mémoire).
     \item Il faut obligatoirement se connecter pour s'exercer avec la plateforme.
 \end{itemize}
@@ -205,14 +205,14 @@ \subsubsection*{Défaut(s)}
 
 \begin{itemize}
     \item Pas de barre de recherche pour trouver un exercice en fonction de son titre.
-    \item Classification sommaire des \glspl{tag} (les langages de programmation sont mélangés avec les thématiques, ...).
+    \item Classification sommaire des \glspl{tag} (les langages de programmation sont mélangés avec les thématiques,...).
 \end{itemize}
 
 \subsection*{Conclusion sur l'analyse}
 
 Cette analyse nous a permis de partir sur de bonnes bases pour la création de notre application web. Nous voulions nous inspirer de certaines interfaces proposant de bonnes idées au niveau de la recherche pure, car cette dernière sera l'une des fonctionnalités principales de \texttt{SourceCode}. \\
 
-Certaines fonctionnalités comme l'espace de discussion sur un challenge spécifique ou encore la soumission de sa solution directement sur la plateforme demeurent de bonnes idées, mais pas nécessaires à l'élaboration d'une application comme \texttt{SourceCode} car l'objectif premier est le référencement de \glspl{resinfo} avant tout. Dans une perspective future, l'intégration de ce genre de fonctionnalités pourrait bien sûr être envisageable, ce qui rendrait ce projet encore plus flexible.\\
+Certaines fonctionnalités comme l'espace de discussion sur un challenge spécifique ou encore la soumission de sa solution directement sur la plateforme demeurent de bonnes idées, mais pas nécessaires à l'élaboration d'une application comme \texttt{SourceCode}, car l'objectif premier est le référencement de \glspl{resinfo} avant tout. Dans une perspective future, l'intégration de ce genre de fonctionnalités pourrait bien sûr être envisageable, ce qui rendrait ce projet encore plus flexible.\\
 
 Avec le support de cette analyse, nous avons pu constituer une liste des éléments importants devant être intégrés au projet. Cela a aussi servi à mettre sur papier nos idées à travers un patchwork que vous pourrez consulter dans la section \ref{section:problem}.
 
@@ -222,21 +222,21 @@ \section{Problème}
 
 Compte tenu de l'analyse des plateformes précédentes, nous allons nous intéresser aux obstacles à franchir pour créer une plateforme de partage de \glspl{resinfo}, en particulier la nôtre.\\
 
-La recherche de \glspl{resinfo} demeure la base de \texttt{SourceCode}. Par conséquent, l'élaboration d'une \textbf{bibliothèque} proposant une recherche efficace et pratique est un premier jalon à traverser. Il faut que l'utilisateur comprenne assez rapidement comment interagir avec l'interface pour trouver des \glspl{resinfo} correspondant à ses critères de recherche (exemples : exercices avec le langage C, thématique sur les pointeurs, ...).\\
+La recherche de \glspl{resinfo} demeure la base de \texttt{SourceCode}. Par conséquent, l'élaboration d'une \textbf{bibliothèque} proposant une recherche efficace et pratique est un premier jalon à traverser. Il faut que l'utilisateur comprenne assez rapidement comment interagir avec l'interface pour trouver des \glspl{resinfo} correspondant à ses critères de recherche (exemples : exercices avec le langage C, thématique sur les pointeurs,...).\\
 
 Se pose ensuite la question du \textbf{contenu d'une \gls{fiche}}. Cette dernière contiendrait probablement un titre et une description (énoncé d'un exercice, tutoriel), mais le plus important reste son \textbf{référencement} à travers l'application. Il s'agirait alors d'intégrer un système de \glspl{tag} cohérent permettant de retrouver rapidement une \gls{fiche} dans la bibliothèque.\\
 
-\textbf{Le système de \glspl{tag}} serait incontestablement le cœur de l'interface de recherche de \glspl{resinfo}. Non seulement il devrait être facilement accessible dans l'interface (ergonomie), mais il devrait aussi proposer une \textit{taxonomie} compréhensible par les utilisateurs de la plateforme. Nous entendons par \textit{taxonomie}, une catégorisation des différents \glspl{tag} pour faciliter la recherche (exemples : difficulté, cours, langage, ...).\\
+\textbf{Le système de \glspl{tag}} serait incontestablement le cœur de l'interface de recherche de \glspl{resinfo}. Non seulement il devrait être facilement accessible dans l'interface (ergonomie), mais il devrait aussi proposer une \textit{taxonomie} compréhensible par les utilisateurs de la plateforme. Nous entendons par \textit{taxonomie}, une catégorisation des différents \glspl{tag} pour faciliter la recherche (exemples : difficulté, cours, langage ...).\\
 
-Pour qu'une application de cette envergure soit facilement maintenable en termes de contenu, un autre besoin à satisfaire serait la création d'une \textbf{interface de gestion} permettant d'ajouter des ressources, de créer des \glspl{tag},... Sans cette interface, l'intérêt de la plateforme serait moindre, car l'ajout de ressources serait rendu difficile, voire impossible à réaliser pour le grand public.\\
+Pour qu'une application de cette envergure soit facilement maintenable en termes de contenu, un autre besoin à satisfaire serait la création d'une \textbf{interface de gestion} permettant d'ajouter des ressources, de créer des \glspl{tag} ... Sans cette interface, l'intérêt de la plateforme serait moindre, car l'ajout de ressources serait rendu difficile, voire impossible à réaliser pour le grand public.\\
 
 Étant donné qu'une multitude d'utilisateurs ajouteraient du contenu sur la plateforme, un système de \textbf{modération} semble important à mettre en place. Dans cette perspective, il est alors question de déterminer une organisation sous \textit{différents types d'utilisateurs} avec des privilèges propres (simple visiteur, utilisateur avec un compte, administrateur). Sans cette modération, la plateforme ne pourrait pas prétendre à du contenu de qualité, car tout type de ressource serait alors publié dans la bibliothèque.\\
 
-Pour poursuivre avec le critère de \textit{qualité} du contenu, il serait judicieux d'élaborer un \textbf{système de statuts} pour les ressources publiées. Les ressources validées seraient ainsi visibles dans la bibliothèque (accessible à tout public) tandis que les autres (non valides, en attente, ...) seraient uniquement visibles depuis les interfaces de gestion. Reste à déterminer le nombre de statuts et leur utilité.\\
+Pour poursuivre avec le critère de \textit{qualité} du contenu, il serait judicieux d'élaborer un \textbf{système de statuts} pour les ressources publiées. Les ressources validées seraient ainsi visibles dans la bibliothèque (accessible à tout public) tandis que les autres (non valides, en attente,...) seraient uniquement visibles depuis les interfaces de gestion. Reste à déterminer le nombre de statuts et leur utilité.\\
 
 Toujours dans l'optique d'améliorer la qualité du contenu de la plateforme, un \textbf{système de vote} devrait être mis en place afin de laisser la communauté s'exprimer sur la pertinence d'une \gls{resinfo}. La modération est une première instance de validation des \glspl{resinfo} ajoutées sur la plateforme, mais nous estimons que la communauté doit aussi pouvoir donner son avis. Cela permettrait d'une part au créateur de la \gls{resinfo} d'améliorer sa \gls{fiche} et d'autre part aux administrateurs d'émettre une nouvelle évaluation de la \gls{resinfo}.\\
 
-Afin de vous donner une petite idée de ce que nous avons imaginé après la première analyse des plateformes, nous vous proposons quelques illustrations de notre patchwork pour la partie bibliothèque et la consultation d'une \gls{fiche}. \textbf{Ceci n'est pas un design final de \texttt{SourceCode}} mais plutôt une mise sur papier de notre conception de l'application web au vu des critères exposés précédemment.\\
+Afin de vous donner une petite idée de ce que nous avons imaginé après la première analyse des plateformes, nous vous proposons quelques illustrations de notre patchwork pour la partie bibliothèque et la consultation d'une \gls{fiche}. \textbf{Ceci n'est pas un design final de \texttt{SourceCode}}, mais plutôt une mise sur papier de notre conception de l'application web au vu des critères exposés précédemment.\\
 
 \begin{figure}[H]
     \includegraphics[width=\textwidth,height=\textheight,keepaspectratio]{images/library.JPG}
@@ -266,8 +266,8 @@ \section{Défis à relever}
 Après avoir formalisé les besoins d'une application de partage de \glspl{resinfo}, nous allons maintenant lister ce que nous allons mettre en place pour réaliser notre plateforme. Notez que cette liste est introductive à l'analyse fonctionnelle relatée dans la section \ref{section:analyseFonctionnelle}, mais nous avions besoin de cette étape pour avoir une vue au global de \texttt{SourceCode} avant d'aller un peu plus dans les détails.
 
 \begin{itemize}
-    \item Proposer une interface simple et ergonomique à destination d'un public varié. Pour rappel, la cible principale est l'équipe pédagogique (professeurs, doctorants, formateurs, ...), le reste étant majoritairement des étudiants. Peu importe le type d'utilisateur, l'outil doit être suffisamment clair que pour comprendre les fonctionnalités clés de l'application (recherche de \glspl{resinfo}, création de \glspl{fiche}, gestion des favoris,...).
-    \item Créer un système de \glspl{tag} évolutif et extensible. Nous entendons par là la possibilité de créer/modifier/proposer des \glspl{tag}, créer/modifier des \glspl{tagCat}, ... . Cela permettra ainsi de ne pas figer l'application sur une poignée de \glspl{tag} mais aussi de s'adapter à de nouvelles conventions en renommant certains d'entre eux.
+    \item Proposer une interface simple et ergonomique à destination d'un public varié. Pour rappel, la cible principale est l'équipe pédagogique (professeurs, doctorants, formateurs,...), le reste étant majoritairement des étudiants. Peu importe le type d'utilisateur, l'outil doit être suffisamment clair que pour comprendre les fonctionnalités clés de l'application (recherche de \glspl{resinfo}, création de \glspl{fiche}, gestion des favoris ...).
+    \item Créer un système de \glspl{tag} évolutif et extensible. Nous entendons par là la possibilité de créer/modifier/proposer des \glspl{tag}, créer/modifier des \glspl{tagCat},... . Cela permettra ainsi de ne pas figer l'application sur une poignée de \glspl{tag}, mais aussi de s'adapter à de nouvelles conventions en renommant certains d'entre eux.
     \item Proposer une interface de modération complète pour gérer les \glspl{tag}, les \glspl{tagCat}, les \glspl{resinfo} et les utilisateurs. En outre, les interfaces d'administration ne seraient disponibles qu'à partir du moment où l'utilisateur possède un compte éligible d'administrateur. Les autres interfaces de gestion pour ses propres \glspl{resinfo} devraient être accessibles aux utilisateurs possédant un simple compte utilisateur.
     \item La recherche de \glspl{resinfo} doit fonctionner de manière efficace. À ce propos, le site \textit{coderByte} propose une bonne façon de rechercher des exercices, avec un panneau latéral comportant des \glspl{tag} rangés dans des catégories. Nous allons donc nous inspirer de cette pratique pour naviguer dans la bibliothèque, tout en ajoutant une barre de recherche pour naviguer dans les titres des \glspl{resinfo}.
     \item Créer et intégrer à l'application un outil pour importer/exporter rapidement des \glspl{resinfo}, des \glspl{tag} et \glspl{tagCat}. Ajouter des \glspl{resinfo} peut être chronophage dans le cas où il y aurait quelques dizaines de \glspl{fiche} à créer depuis l'interface de gestion. Nous souhaitons donc automatiser le processus de création en proposant un format d'import acceptant les éléments précédemment cités. À l'inverse, exporter des \glspl{resinfo} depuis notre plateforme devrait être rendu possible afin de partager les ressources avec d'autres plateformes par exemple.
@@ -279,4 +279,4 @@ \section{Défis à relever}
 
 Chaque page doit être réfléchie en matière d'ergonomie et de design pour que l'utilisateur ait envie de continuer à naviguer sur la plateforme. Côté développement, l'ensemble du code doit être suffisamment modulaire afin d'apporter de nouvelles fonctionnalités de manière aisée (évolution de l'application). Au plus du temps sera investi dans un tel projet, au plus ce dernier sera mature et agréable à prendre en main pour chaque classe d'utilisateur, car nous aurons appris à comprendre leurs besoins. Nous pensons particulièrement à la recherche de \glspl{resinfo} et à la gestion de ces mêmes \glspl{resinfo}, \glspl{tag}, \glspl{tagCat}.\\
 
-\texttt{SourceCode} n'aura pas la prétention d'être en version finale, il se positionnera plus sur la dénomination de \textbf{prototype}. En effet, notre volonté principale est avant tout de contribuer au domaine des ressources partagées, car nous pensons que ce dernier est porteur d'une riche communauté d'entre-aide. C'est pourquoi le titre de notre mémoire contient les mots \textbf{\textit{open source}} car nous prenons exemple sur ce mode d'organisation pour créer cet outil de partage.
+\texttt{SourceCode} n'aura pas la prétention d'être en version finale, il se positionnera plus sur la dénomination de \textbf{prototype}. En effet, notre volonté principale est avant tout de contribuer au domaine des ressources partagées, car nous pensons que ce dernier est porteur d'une riche communauté d'entre-aide. C'est pourquoi le titre de notre mémoire contient les mots \textbf{\textit{open source}}, car nous prenons exemple sur ce mode d'organisation pour créer cet outil de partage.
diff --git a/sections/chapters/solution/api/index.tex b/sections/chapters/solution/api/index.tex
index 98698d6..a5bca3c 100644
--- a/sections/chapters/solution/api/index.tex
+++ b/sections/chapters/solution/api/index.tex
@@ -94,7 +94,7 @@ \subsection{Structure du projet}
 \end{itemize}
 
 \pagebreak
-\subsection{Points clés de l'implémention}
+\subsection{Points clés de l'implémentation}
 
 \subsubsection{Paramétrisation de l'\Gls{api}}
 \label{section:apiConfig}
diff --git a/sections/chapters/solution/choixTechno/index.tex b/sections/chapters/solution/choixTechno/index.tex
index a861caa..77e47be 100644
--- a/sections/chapters/solution/choixTechno/index.tex
+++ b/sections/chapters/solution/choixTechno/index.tex
@@ -33,7 +33,7 @@ \subsection*{Choix de l'environnement de programmation}
 \begin{itemize}
     \item Une fois compilé, on ne peut plus changer le programme (contrairement à l'interprétation)
     \item En cas d'erreur(s) dans le programme, la compilation les affiche dans la phase "compilation" contrairement à l'interprétation qui les affiche à l'exécution. 
-    \item La compilation permet d'optimiser les performances d'un programme (car disposant de l'intégralité du code source au départ) mais nécessite un certain temps pour traduire le programme en code machine.
+    \item La compilation permet d'optimiser les performances d'un programme (car disposant de l'intégralité du code source au départ), mais nécessite un certain temps pour traduire le programme en code machine.
     \item L'interprétation possède moins d'étapes que la compilation.
 \end{itemize}
 
@@ -125,7 +125,7 @@ \subsubsection*{Framework pour le front-end}
 
 Le choix entre ces trois frameworks s'apparente à une décision plus que subjective, car ce sont tous les trois d'excellents outils de développement. \\
 
-Puisqu'il fallait bien trancher, \textit{Vue.js} a été la solution retenue pour la partie front-end car nous l'avions déjà utilisé par le passé. Ce framework est aussi populaire qu'\textit{Angular} mais moins que \textit{React}. Vue détient cependant le plus grand nombre de "\textit{stars}" sur GitHub, ceci traduisant un intérêt non négligeable pour ce framework au sein de la communauté des développeurs.\\
+Puisqu'il fallait bien trancher, \textit{Vue.js} a été la solution retenue pour la partie front-end car nous l'avions déjà utilisé par le passé. Ce framework est aussi populaire qu'\textit{Angular}, mais moins que \textit{React}. Vue détient cependant le plus grand nombre de "\textit{stars}" sur GitHub, ceci traduisant un intérêt non négligeable pour ce framework au sein de la communauté des développeurs.\\
 
 % Temporairement on va changer le style de footnote, pour éviter une confusion
 \renewcommand{\thefootnote}{\alph{footnote}}
diff --git a/sections/chapters/solution/client/index.tex b/sections/chapters/solution/client/index.tex
index 1da6b6a..df3a0ff 100644
--- a/sections/chapters/solution/client/index.tex
+++ b/sections/chapters/solution/client/index.tex
@@ -194,7 +194,7 @@ \subsubsubsection{Système de vote}
 
 Sur la \gls{fiche} de la \gls{resinfo}, vous pouvez donner une note sur la qualité de la ressource sur 5 étoiles. Il suffit de cliquer sur une des étoiles pour donner un score (seulement si vous possédez un compte).\\
 
-Là aussi, le vote joue un rôle important dans le référencement de la \gls{resinfo} car les utilisateurs peuvent filtrer les \glspl{resinfo} en fonction de leur note.\\
+Là aussi, le vote joue un rôle important dans le référencement de la \gls{resinfo}, car les utilisateurs peuvent filtrer les \glspl{resinfo} en fonction de leur note.\\
 
 Nous avons choisi un système de vote sur 5 étoiles, car notre analyse (section \ref{section:situation}) a révélé cette caractéristique commune sur de nombreux sites. La plateforme \textit{Hackerrank} utilise d'ailleurs ce système.
 
@@ -458,7 +458,7 @@ \subsubsubsection{Actions supplémentaires}
 
 \subsubsubsection{Champ supplémentaire dans le tableau des ressources} 
 
-Le créateur de la \gls{resinfo}. À ce stade du développement, nous ne pouvons pas contacter l'utilisateur directement depuis la plateforme. C'est définitivement une piste que nous allons explorer dans le chapitre \ref{chapter:pourAllerPlusLoin} car nous aurions voulu intégrer un système de tickets complétant la validation par statut d'une ressource.\\
+Le créateur de la \gls{resinfo}. À ce stade du développement, nous ne pouvons pas contacter l'utilisateur directement depuis la plateforme. C'est définitivement une piste que nous allons explorer dans le chapitre \ref{chapter:pourAllerPlusLoin}, car nous aurions voulu intégrer un système de tickets complétant la validation par statut d'une ressource.\\
 
 \subsubsection{L'importation de \glspl{resinfo}}
 
@@ -529,7 +529,7 @@ \subsubsubsection{Création/modification de \glspl{tag}}
 
 \subsubsection{La gestion des \glspl{tagCat}}
 
-La gestion des \glspl{tagCat} se limite uniquement à la modification du titre ou à la création d'une nouvelle catégorie. La suppression est réservée au super-administrateur car elle implique la suppresion de tous les \glspl{tag} qui se rapportent à cette catégorie (opération dangereuse et irréversible).
+La gestion des \glspl{tagCat} se limite uniquement à la modification du titre ou à la création d'une nouvelle catégorie. La suppression est réservée au super-administrateur car elle implique la suppression de tous les \glspl{tag} qui se rapportent à cette catégorie (opération dangereuse et irréversible).
 
 \subsubsection{La gestion des utilisateurs}
 
diff --git a/sections/preambule.tex b/sections/preambule.tex
index 0bc2790..a777fc3 100644
--- a/sections/preambule.tex
+++ b/sections/preambule.tex
@@ -13,7 +13,7 @@ \chapter*{Résumé}
 
 L'ensemble de notre prototype est disponible sur GitHub sous un compte spécialement dédié à ce mémoire : 
 \href{https://github.com/SourceCodeOER}{SourceCodeOER} (\href{https://github.com/SourceCodeOER}{https://github.com/SourceCodeOER}). 
-Notre prototype est hébergée par l'UCLouvain en mode démonstration à l'adresse suivante : \href{http://tfe-dewit-yakoub.info.ucl.ac.be/}{http://tfe-dewit-yakoub.info.ucl.ac.be/} \\
+Notre prototype est hébergé par l'UCLouvain en mode démonstration à l'adresse suivante : \href{http://tfe-dewit-yakoub.info.ucl.ac.be/}{http://tfe-dewit-yakoub.info.ucl.ac.be/} \\
 
 \iffalse