wip: Antidode 10 karcher corrections (#20)

* wip: Antidode 10 karcher corrections

* fix: uniform OpenAPI-Enforcer writing

* fix: typo in glossary

glossary.tex

@@ -111,7 +111,7 @@
     plural={mots-clés},
     description={
         Mot (ou groupe de mots) permettant de caractériser une ou plusieurs \gls{fiche}(s).
-        Un mot clé est toujours lié à une \gls{tagCat}.
+        Un mot-clé est toujours lié à une \gls{tagCat}.
     }
 }
 
@@ -141,7 +141,7 @@
     text={ressource informatique},
     plural={ressources informatiques},
     description={
-        Désigne tout matériel ayant pour attrait le domaine de l'informatique. Exemple : des exercices de programmation, des tutoriels en informatique, des algorithmes, des slides, ...
+        Désigne tout matériel ayant pour attrait le domaine de l'informatique. Exemple : des exercices de programmation, des tutoriels en informatique, des algorithmes, des slides ...
     }
 }
 
@@ -172,7 +172,7 @@
     text={variable d'environnement},
     plural={variables d'environnement},
     description={
-        Ce terme désigne, comme expliqué par Wikipédia\cite{envvarDef}, "une variables dynamique utilisée par les différents processus d’un système d’exploitation".
+        Ce terme désigne, comme expliqué par Wikipédia\cite{envvarDef}, "une variable dynamique utilisée par les différents processus d’un système d’exploitation".
     }
 }
 
@@ -181,7 +181,7 @@
     name={Déploiement},
     text={déploiement},
     description={
-        Ensemble d'activités permettant la mise en service du logiciel afin qu'il soit pret à être utilisé.
+        Ensemble d'activités permettant la mise en service du logiciel afin qu'il soit prêt à être utilisé.
     }
 }
 
@@ -201,6 +201,6 @@
         Abréviation anglophone pour "Continuous integration / Continuous Delivery", ce qui peut se traduire comme intégration continue / \gls{deploiement} continu.
         Il s'agit donc de l'association de ces 2 concepts.
         L'intégration continue consistant à vérifier que chaque modification du code source n'engendre pas de défauts, notamment par l'usage de tests.
-        Le \gls{deploiement} continu consistant à réaliser le \gls{deploiement} à chaque modification du code source, par le billet d'un système automatisé.
+        Le \gls{deploiement} continu consistant à réaliser le \gls{deploiement} à chaque modification du code source, par le biais d'un système automatisé.
     }
 }

sections/chapters/analyseCritique/index.tex

@@ -211,7 +211,7 @@ \subsection{Statistiques}
     \end{itemize}
     \item Nombre de pull requests résolues (frontend + backend) : 49 + 79 = 128
     \begin{itemize}
-        \item Nous avons beaucoup utilisé les pull requests avec GitHub car nous voulions garder une trace des mises à jour importantes effectuées. Elles ont aussi été extrêmement utiles avec l'intégration continue de \textit{Docker} qui nous permettait de rapidement tester l'application avec l'une d'elles.
+        \item Nous avons beaucoup utilisé les pull requests avec GitHub, car nous voulions garder une trace des mises à jour importantes effectuées. Elles ont aussi été extrêmement utiles avec l'intégration continue de \textit{Docker} qui nous permettait de rapidement tester l'application avec l'une d'elles.
     \end{itemize}
 \end{itemize}
 
@@ -236,11 +236,11 @@ \subsection{Graphe d'activité}
 \end{figure}
 
 
-Globalement, nous avons respecté le planning \ref{pic:ganttChart} que nous nous sommes imposés. Nous avons cependant effectué une dernière mise à jour prenant en compte un maximum des remarques relatées en section \ref{section:validationExterne}, car nous voulions prouver que \texttt{SourceCode} est capable de s'adapter aux besoins des utilisateurs.
+Globalement, nous avons respecté le planning \ref{pic:ganttChart} que nous nous sommes imposé. Nous avons cependant effectué une dernière mise à jour prenant en compte un maximum des remarques relatées en section \ref{section:validationExterne}, car nous voulions prouver que \texttt{SourceCode} est capable de s'adapter aux besoins des utilisateurs.
 
 \subsection{Conclusion}
 
-Ce chapitre était agréable à rédiger car nous avons pu constater si \texttt{SourceCode} est un projet qui tient la route à son stade de développement.\\
+Ce chapitre était agréable à rédiger, car nous avons pu constater si \texttt{SourceCode} est un projet qui tient la route à son stade de développement.\\
 
 La séance de validation nous a été extrêmement bénéfique, car les remarques étaient constructives. 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.\\
 

sections/chapters/approche/index.tex

@@ -49,18 +49,18 @@ \subsection*{Communication}
     \end{itemize}
     \item Quand on délivre le produit ?
     \begin{itemize}
-        \item Que reste-il à faire ?
+        \item Que reste-t-il à faire ?
         \item Comment estimer le temps/travail nécessaire pour réaliser les différentes tâches ?
     \end{itemize}
 \end{itemize}
 
-Pour y répondre, il convient d'utiliser des moyens/outils de communication suffisamment explicites pour tous les acteurs de ce projet. Étant donné que notre solution est hébergée sur Github, nous avons décidé d'utiliser les fonctionnalités suivantes de Github : le "Project Board" \footnote{\url{https://help.github.com/en/github/managing-your-work-on-github/about-project-boards}} et les issues \footnote{\url{https://help.github.com/en/github/managing-your-work-on-github/about-issues}}. (dont vous pourrez trouver une illustration respectivement aux figures \ref{pic:GithubBoard} et \ref{pic:GithubIssues} )\\
+Pour y répondre, il convient d'utiliser des moyens/outils de communication suffisamment explicites pour tous les acteurs de ce projet. Étant donné que notre solution est hébergée sur Github, nous avons décidé d'utiliser les fonctionnalités suivantes de Github : le "Project Board" \footnote{\url{https://help.github.com/en/github/managing-your-work-on-github/about-project-boards}} et les issues \footnote{\url{https://help.github.com/en/github/managing-your-work-on-github/about-issues}}. (dont vous pourrez trouver une illustration respectivement aux figures \ref{pic:GithubBoard} et \ref{pic:GithubIssues})\\
 
 Comme nous pouvons le voir, par l'usage de ces outils/moyens, l'état et la progression générale du projet sont accessibles au plus grand nombre : 
 \begin{itemize}
     \item Avec le "Project Board", on représente les tâches sous la forme de cartes amovibles dans un tableau, avec les caractéristiques suivantes :
     \begin{itemize}
-        \item Chaque tâche est catégorisée dans une colonne bien précise ( "to do"/ à réaliser, "in progress"/ en cours, "done" / réalisée, "enhancements" / améliorations  )
+        \item Chaque tâche est catégorisée dans une colonne bien précise ("to do"/ à réaliser, "in progress"/ en cours, "done" / réalisée, "enhancements" / améliorations)
         \item Une barre de progression nous notifie de l'avancement général du projet
     \end{itemize}
     \item Avec les issues (figure \ref{pic:GithubIssues}), chaque tâche/problème dispose des éléments suivants : 

sections/chapters/problematique/index.tex

@@ -275,6 +275,8 @@ \section{Défis à relever}
     \item Une piste non explorée par les différentes plateformes précédemment analysées est de proposer une recherche de \glspl{resinfo} plus attractive. Nous pensons donc à intégrer un historique et un système de favoris pour naviguer plus aisément dans les recherches effectuées antérieurement.
 \end{itemize}
 
+% Un pagebreak ici, puisque de toute facon, la page ne sera pas suffisant pour tout display
+\pagebreak
 Pour conclure ce chapitre et cette section, il est important de noter que la création d'une application web à destination d'un public varié demande un investissement conséquent en termes de temps. Il s'agit de créer une interface satisfaisant les attentes de chaque groupe d'utilisateurs tout en proposant un projet maintenable et évolutif pouvant satisfaire les besoins futurs.\\
 
 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}.\\

sections/chapters/solution/api/index.tex

@@ -24,8 +24,8 @@ \subsection{Structure du projet}
 % A voir s'il faut minimiser l'itemize
 % nosep,noitemsep,topsep=0pt,partopsep=0pt,after=\vspace*{2pt}
 \begin{itemize}
-    \item openapi : nos fichiers \Gls{oas}, utilisés par openapi-enforcer (cf. figure \ref{fig:OASEnforcer})
-    \item controllers : nos fichiers chargés de répondre aux requêtes \textbf{HTTP}, utilisés par openapi-enforcer (cf. figure \ref{fig:OASEnforcer})
+    \item openapi : nos fichiers \Gls{oas}, utilisés par OpenAPI-Enforcer (cf. figure \ref{fig:OASEnforcer})
+    \item controllers : nos fichiers chargés de répondre aux requêtes \textbf{HTTP}, utilisés par OpenAPI-Enforcer (cf. figure \ref{fig:OASEnforcer})
     \item tests : nos tests pour valider l'implémentation (cf. section \ref{section:validation})
     \item docs : la documentation de l'\Gls{api} en \textbf{HTML}\footnote{
         Celle-ci est automatiquement publiée sur 
@@ -66,7 +66,7 @@ \subsubsection{Documentation de l'\Gls{api}}
 \begin{itemize}
     \item Peut être utilisé par des outils divers pour de multiples finalités :
     \begin{itemize}[nosep,noitemsep,topsep=0pt,partopsep=0pt,after=\vspace*{2pt}]
-        \item apporter des fonctionnalités supplémentaires / construire un projet plus rapidement, comme OpenAPI-enforcer (cf. figure \ref{fig:OASEnforcer})
+        \item apporter des fonctionnalités supplémentaires / construire un projet plus rapidement, comme OpenAPI-Enforcer (cf. figure \ref{fig:OASEnforcer})
         \item pour générer de la documentation (cf. figure \ref{fig:exampleDoc}), comme Redoc\footnote{
             \url{https://github.com/Redocly/redoc}
         }
@@ -86,7 +86,7 @@ \subsubsection{\Glspl{middleware}}
 
 Pour rappel (cf. section \ref{section:choixTechnologiques}), Express a été le "squelette" sur lequel nous avons construit notre application.
 Une de ses particularités est l'usage de \glspl{middleware}\footnote{
-    Par exemple, ceux en section \ref{section:choixTechnologiques} : Passport.js et OpenAPI-enforcer
+    Par exemple, ceux en section \ref{section:choixTechnologiques} : Passport.js et OpenAPI-Enforcer
 } dont nous pouvons expliquer le fonctionnement général par le biais de cette illustration :
 
 \begin{figure}[H]
@@ -100,7 +100,7 @@ \subsubsection{\Glspl{middleware}}
     \item La requête est interceptée par le serveur.
     \item La requête traverse successivement chaque "couche" (\gls{middleware} 1, 2, ...) jusqu'à atteindre le cœur de l'application, 
     à condition qu'il n'y ait pas eu d'erreurs lors du parcours.
-    \item Quelque soit la situation, une réponse est toujours envoyée au client de la requête.
+    \item Quelle que soit la situation, une réponse est toujours envoyée au client de la requête.
 \end{itemize}
 
 La grande force de cette approche est qu'elle permet de déléguer\footnote{
@@ -179,7 +179,7 @@ \subsection{\texorpdfstring{\Gls{cli}}{CLI}}
     \url{https://inginious.info.ucl.ac.be/}
 }, disponibles via Git\footnote{
     \url{https://git-scm.com/}
-}), tout en conservant le même comportement, quelque soit la situation. 
+}), tout en conservant le même comportement, quelle que soit la situation. 
 
 Par respect de la norme que nous avons crée (cf. annexe \ref{annexe:AnalyseBiblio}), nous avons également adopté le \textbf{JSON} et les mêmes conventions d'écriture 
 pour les fichiers d'entrée / de sortie des différentes commandes, à quelques exceptions près que nous avons détaillé dans le fichier README.MD. 
@@ -209,7 +209,7 @@ \subsection{Docker}
 }
 
 Nous avons ainsi découpé notre application en 3 images\footnote{
-    Elles sont disponibles sur Dockerhub (\url{https://hub.docker.com/}) 
+    Elles sont disponibles sur Docker Hub (\url{https://hub.docker.com/}) 
     et générées sur base de fichiers Dockerfile, présents dans chaque repository Github.
     Notons enfin la présence dans le repository miscellaneous de fichiers docker-compose-***.yml pour déployer automatiquement l'entièreté de \texttt{SourceCode} avec Docker Compose, en fonction de l'environnement souhaité (plus d'informations dans le README.MD).
 } :
@@ -221,9 +221,9 @@ \subsection{Docker}
 \end{itemize}
 
 \begin{figure}[H]
-    \includegraphics[width=\textwidth,height=0.13\textheight]{images/serveur/dockerHub.PNG}
+    \includegraphics[width=\textwidth,height=0.15\textheight,keepaspectratio]{images/serveur/dockerHub.PNG}
     \centering
-    \caption{Docker - des images prêtes à l'emploi}
+    \caption{Docker Hub - des images prêtes à l'emploi}
     \label{fig:dockerImages}
 \end{figure}