Big relecture

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. 

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}
 

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}

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.

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}

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.
 

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.
+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.