Corrections diverses

annexes/glossary.tex

@@ -24,6 +24,7 @@
 \newacronym{vlan}{VLAN}{Virtual Local Area Network}
 \newacronym{iso}{ISO}{Organisation Internationale de Normalisation}
 \newacronym{iana}{IANA}{Internet Assigned Numbers Authority}
+\newacronym{dom}{DOM}{Document Object Model}
 
 \newglossaryentry{firewall}{
   name=firewall,

chapitres/conclusions/resultats.tex

@@ -10,10 +10,10 @@ Les différents modules suivi au cours de ma formation à la \acrshort{heig} m'o
 
 La mise en pratique du \gls{tdd} comme méthode de développement m'a également beaucoup apporté. Il est vite devenu très naturel de décrire le comportement attendu par un objet ou une méthode et d'écrire ensuite le code nécessaire à sa mise en place. Cela m'a permis de m'assurer que ce qui était fonctionnel l'est toujours après l'ajout de nouvelles fonctionnalités. Ces tests sont également la base qui rend possible la mise en place des mécanismes d'intégration continue. Grâce à Gitlab, il va facilement pouvoir exécuter les taches de vérification et ne déployer le code que si l'ensembles des tests est validé.
 
-Bien que le réalisation de la partie métier en Ruby est vite devenue intuitive, la partie frontend, elle, m'a posé beaucoup plus de problèmes. N'ayant jamais abordés cette partie là dans le cadre de ma formation, j'ai donc découvert ce milieu au cours du projet. La logique requise pour ce genre développement est vraiment différente et les langages utilisés également. J'ai aussi eu beaucoup plus de peine à réellement tester l'interface et à simuler les actions d'un utilisateur.
+Bien que le réalisation de la partie métier en Ruby est vite devenue intuitive, la partie frontend, elle, m'a posé beaucoup plus de problèmes. N'ayant jamais abordés ces technologies là dans le cadre de ma formation, j'ai donc découvert ce milieu au cours du projet. La logique requise pour ce genre développement est vraiment différente et les langages utilisés également. J'ai aussi eu beaucoup plus de peine à réellement tester l'interface et à simuler les actions d'un utilisateur.
 
-L'utilisation d'analyseur de code dès le début du projet m'a permis d'apprendre énormément sur les bonnes pratiques à utiliser en Ruby et avec le Javascript. Ces langages interprétés ont des syntaxes qui ont tendances à évoluer et à changer plus rapidement avec le temps. Ceci a pour effet de rendre plus rapidement obsolète la littérature à leur sujet. Grâce à ces analyseurs, j'ai pu m'assurer d'utiliser les syntaxes les plus a jour et de supprimer toutes utilisations de méthodes dépréciées. N'étant pas un développeur professionnel ni en Ruby ni en Javascript, suivre les recommandations validées par la communauté me semble être le meilleur choix pour avoir un code lisible et maintenable.
+L'utilisation d'analyseur de code dès le début du projet m'a permis d'apprendre énormément sur les bonnes pratiques à utiliser en Ruby et avec le Javascript. Ces langages interprétés ont des syntaxes qui ont tendances à évoluer et à changer souvent avec le temps. Ceci a pour effet de rendre plus rapidement obsolète la littérature à leur sujet. Grâce à ces analyseurs, j'ai pu m'assurer d'utiliser les syntaxes les plus a jour et de supprimer toutes utilisations de méthodes dépréciées. N'étant pas un développeur professionnel ni en Ruby ni en Javascript, suivre les recommandations validées par la communauté me semble être le meilleur choix pour avoir un code lisible et maintenable.
 
-L'utilisation de Gitlab tout au long du projet s'est trouvé être une bien meilleure idée que ce que j'imaginais au départ. Il m'a en effet permis de mettre en place des dépôts Git et d'appliquer la méthode Git Flow grâce notamment au \emph{merge request} intégrées. Mais il s'est avéré être un outil de qualité pour le suivi du projet de façon plus global. Définir les sprints (grâce aux \emph{milestones}) et ensuite y attribuer des taches (sous forme d'\emph{issues}) m'a permis de d'avoir en tout temps une vue globale sur l'avancement du projet. De plus, il est possible d'estimer le temps nécessaire à chaque tache et ensuite d'entrer le temps effectivement utilisé, ce qui permet ensuite d'avoir une vision précise du temps de travail. Enfin, les mécanismes intégré pour mettre facilement en place de l'intégration continue et du déploiement m'a permis de gagner beaucoup de temps tout au long du projet en mettant automatiquement à jour l'application.
+L'utilisation de Gitlab tout au long du projet s'est trouvé être une bien meilleure idée que ce que j'imaginais au départ. Il m'a en effet permis de mettre en place des dépôts Git et d'appliquer la méthode Git Flow grâce notamment au \emph{merge request} intégrées. Mais il s'est avéré être un outil de qualité pour le suivi du projet de façon plus global. Définir les sprints (grâce aux \emph{milestones}) et ensuite y attribuer des taches (sous forme d'\emph{issues}) m'a permis d'avoir en tout temps une vue globale sur l'avancement du projet. De plus, il est possible d'estimer le temps nécessaire à chaque tache et ensuite d'entrer le temps effectivement utilisé, ce qui permet ensuite d'avoir une vision précise du temps de travail. Enfin, les mécanismes intégrés pour mettre facilement en place de l'intégration continue et du déploiement m'a permis de gagner beaucoup de temps tout au long du projet en mettant automatiquement à jour l'application.
 
-Pour finir, j'ai eu du plaisir à mettre en place quelques éléments des méthodes Agile au cours du projet. Le contact régulier avec les utilisateurs permet vraiment de mieux comprendre la problématique et d'adapter le code au fur et à mesure. C'est surtout vrai pour l'interface web, car c'est ce que le client va utiliser au final et donc personne n'est mieux placé pour donner un avis à ce niveau-là. D'un point de vue personnel, c'est aussi encourageant de savoir que le travail effectué est apprécié et avoir des retours de qualité permet d'améliorer encore un peu cela. Aux cours des diverses discussions, plusieurs idées d'améliorations sont venues et il est maintenant certain que le projet continuera.
+Pour finir, j'ai eu du plaisir à instaurer quelques éléments des méthodes Agile au cours du projet. Le contact régulier avec les utilisateurs permet vraiment de mieux comprendre la problématique et d'adapter le code au fur et à mesure. C'est surtout vrai pour l'interface web, car c'est ce que le client va utiliser au final et donc personne n'est mieux placé pour donner un avis à ce niveau-là. D'un point de vue personnel, c'est aussi encourageant de savoir que le travail effectué est apprécié et avoir des retours de qualité permet d'améliorer encore un peu cela. Aux cours des diverses discussions, plusieurs idées d'améliorations sont venues et il est maintenant certain que le projet continuera.

chapitres/gestion/echeancier.tex

@@ -67,11 +67,11 @@ Certaines fonctionnalités requièrent du développement sur plusieurs parties d
     \caption{Détail des taches du sprint 1}
 \end{figure}
 
-Une grande partie de ce sprint a été dédié à la préparation de l'environnement de travail requis pour ce projet. Cela comprend notamment la mise en place d'un serveur de virtualisation pour pouvoir mettre en place une instance Gitlab\cite{gitlabsite} ainsi que d'autres machines virtuelles qui se sont occupés d'exécuter et valider les différents tests. Avec cela, un mécanisme de backup journalier du serveur a été configuré pour se protéger contre une éventuelle perte de données.
+Une grande partie de ce sprint a été dédié à la préparation de l'environnement de travail requis pour ce projet. Cela comprend notamment la mise en place d'un serveur de virtualisation pour pouvoir mettre en place une instance Gitlab\cite{gitlabsite} ainsi que d'autres machines virtuelles qui se sont occupées d'exécuter et de valider les différents tests. Avec cela, un mécanisme de backup journalier du serveur a été configuré pour se protéger contre une éventuelle perte de données.
 
 Le réseau de test (comme décrit dans la section sur le routage (\ref{subsec:network:ip:routing})) a ensuite été configuré pour simuler une architecture réseau utilisant les mêmes technologies que celles du CHUV. Ces équipements ont pu ensuite servir d'éléments de tests pertinents durant le développement de l'application.
 
-La seconde partie du sprint a servis à commencer le programme qui va permettre de pouvoir exécuter des requêtes sur les équipements Fortinet. 
+La seconde partie du sprint a servis à commencer le programme qui permet de pouvoir exécuter des requêtes sur les équipements Fortinet. 
 
 \newpage
 \subsection{Sprint 2}
@@ -84,7 +84,7 @@ La seconde partie du sprint a servis à commencer le programme qui va permettre
 
 Sprint principalement orienté sur la création du backend. Mise en place de l'application, création des modèles de classe et intégration du module pour interfacer les Fortinet. Apprentissage de l'utilisation des outils de tests Ruby et mise en place de structure dans le code.
 
-Travail de recherche sur les mécanismes utilisés quand on veut faire du chiffrement symétrique. Mise en place de la solution SyymetricEncryption\cite{symmetricencryption} pour chiffrer les mots de passes des identifiants dans la base de donnée.
+Travail de recherche sur les mécanismes utilisés quand on veut faire du chiffrement symétrique. Mise en place de la solution SymetricEncryption\cite{symmetricencryption} pour chiffrer les mots de passes des identifiants dans la base de donnée.
 
 Installation et configuration de objets pour pouvoir les stocker dans la base MongoDB. Utilisation de mongoid\cite{mongoid} également pour faire les tests de validation des attributs.
 
@@ -101,7 +101,7 @@ Première revue avec les futurs utilisateurs pour valider les trois premières u
 
 Finalisation de l'intégration des objets dans MongoDB qui a permit de développer l'algorithme pour rechercher efficacement une règle de sécurité dans un équipement. Pour cela, il a fallu faire quelques modifications sur certains objets et notamment la conversion décimale pour les objets de type \Colorbox{light-gray}{\lstinline|Address|}.
 
-Création du projet pour la partie frontend de l'application avec une interface de recherche sobre mais qui permet de démontrer le bon fonctionnement de l'algorithme de recherche. La seconde revue a permis de valider cette fonctionnalité et ainsi que des retours sur l'interface WEB.
+Création du projet pour la partie frontend de l'application avec une interface de recherche sobre mais qui permet de démontrer le bon fonctionnement de la recherche. La seconde revue a permis de valider cette fonctionnalité et ainsi que des retours sur l'interface WEB.
 
 \newpage
 \subsection{Sprint 4}
@@ -114,7 +114,7 @@ Création du projet pour la partie frontend de l'application avec une interface
 
 Sprint complètement concentré sur la partie frontend du projet et également la mise en place du chiffrement SSL pour utiliser le protocole HTTPS. L'aspect visuel de la recherche de règle, ainsi que l'affichage des résultats retournés par celle-ci, a été revue pour prendre en compte les retours de la revue précédente. Pour cela, la façon de formatter les polices de sécurité (\Colorbox{light-gray}{\lstinline|Policy|}) en JSON a été revue.
 
-L'interface WEB permet maintenant de voir les équipements gérés dans l'application et d'obtenir la liste des règles implémentées dans ceux-ci. La troisième revue a valider cette partie-là. Quelques retours supplémentaires sont arrivés concernant l'affichage des polices de sécurité.
+L'interface WEB permet maintenant de voir les équipements gérés dans l'application et d'obtenir la liste des règles implémentées dans ceux-ci. La troisième revue a valider cette partie-là et quelques retours supplémentaires sont arrivés concernant l'affichage des polices de sécurité.
 
 \newpage
 \subsection{Sprint 5}

chapitres/gestion/rendezvous.tex

@@ -8,7 +8,7 @@ Plusieurs rencontres ont eut lieu avec le conseiller durant la période de réal
 
 \begin{itemize}
     \item \textbf{16.07.2018 17h-18h30:} Discussions autour du \gls{tdd} et de comment le mettre en place dès le début du projet. Travail sur la structure du projet.
-    \item \textbf{11.08.2018:}  Email à destination du conseiller pour lui transmettre les informations pour accéder à un environnement Gitlab mis en place pour rendre disponible le code depuis internet. Retour sur l'état actuel du projet par email.
+    \item \textbf{11.08.2018:}  Email à destination du conseiller pour lui transmettre les informations pour accéder à un environnement Gitlab mis en place pour rendre disponible le code depuis internet. Retours sur l'état actuel du projet par email.
     \item \textbf{27.08.2018 17h30-18h30:} Échanges sur l'avancement du projet et travail spécifique sur la construction d'un schéma bloc du projet. Validation du résumé sur la plateforme GAPS.
     \item \textbf{11.09.2018 18h:} Signature et validation de l'affiche pour la mise à disposition sur GAPS.
 \end{itemize}

chapitres/introduction/introduction.tex

@@ -2,9 +2,9 @@
 
 \section{Le CHUV}
 
-Le \gls{chuv} emploie environ 11'000 personnes\cite{rapportActiviteChuv} dans des domaines divers et variés. Les trois missions qui lui sont confiées par l'État sont; les soins, la recherche et la formation. Chacune de ces entités a des besoins différents que ce soit d'un point de vue logistique, d'infrastructure ou d'informatique. Ce dernier est celui qui va évidemment nous intéresser le plus dans le cadre de ce travail de Bachelor et pour commencer dans cette pré-étude. 
+Le \gls{chuv} emploie environ 11'000 personnes\cite{rapportActiviteChuv} dans des domaines divers et variés. Les trois missions qui lui sont confiées par l'État sont; les soins, la recherche et la formation. Chacune de ces entités a des besoins différents que ce soit d'un point de vue logistique, d'infrastructure ou d'informatique. Ce dernier est celui qui va évidemment nous intéresser le plus dans le cadre de ce travail de Bachelor.
 
-Le profil des utilisateurs du système d'information sont bien différents et le niveau de confidentialité des données l'est aussi. Dans le milieu académique, les étudiants travaillent avec leur propre matériel et ne sont pas des employés du \acrshort{chuv}. A l'inverse, dans le secteur hospitalier, les équipements informatiques sont tous gérés et administrés en interne. De plus, les informations échangées sont par exemple des dossiers de patients dont la confidentialité doit être assurée. Pour pouvoir y arriver, l'équipe en charge de l'infrastructure réseau et de la sécurité (équipe dont je fais partie) a mis en place de la segmentation pour maintenir le meilleur niveau de sécurité possible entre les différents environnements de travail.
+Le profil des utilisateurs du système d'information sont bien différents et le niveau de confidentialité des données l'est aussi. Dans le milieu académique, les étudiants travaillent avec leur propre matériel et ne sont pas des employés du \acrshort{chuv}. A l'inverse, dans le secteur hospitalier, les équipements informatiques sont tous gérés et administrés en interne. De plus, les informations échangées sont par exemple des dossiers de patients dont la confidentialité doit être assurée. Pour pouvoir y arriver, l'équipe en charge de l'infrastructure réseau et de la sécurité (dont je fais partie) a mis en place de la segmentation pour maintenir le meilleur niveau de sécurité possible entre les différents environnements de travail.
 
 \section{La problématique}
 
@@ -14,11 +14,11 @@ Lorsqu'une nouvelle application doit être mise en production, l'équipe réseau
 
 \section{L'analyse du besoin}
 
-Pour définir précisément les besoins du projet, une série de cas d'utilisation ont été rédigées avec l'équipe qui sera amener à l'utiliser. Toutes ces \emph{User Stories} ont été formalisées et sont décrites dans la pré-étude de ce projet dans la partie 2 "Analyses et planification". Elles ont été ensuite priorisée par la personne responsable de l'équipe qui est également le mandant de ce projet. Il a été convenu qu'une séance de revue sur l'avancement du projet soit faite toutes les deux semaines tout au long de la durée de la réalisation du projet. Les détails sur le déroulement du projet se trouvent au chapitre "Dossier de gestion".
+Pour définir précisément les besoins du projet, une série de cas d'utilisation a été rédigé avec l'équipe qui sera amené à l'utiliser. Toutes ces \emph{User Stories} ont été formalisées et sont décrites dans la pré-étude de ce projet dans la partie 2 "Analyses et planification". Elles ont été ensuite priorisée par la personne responsable de l'équipe qui est également le mandant de ce projet. Il a été convenu qu'une séance de revue sur l'avancement du projet soit faite toutes les deux semaines tout au long de la durée de la réalisation du projet. Les détails sur le déroulement du projet se trouvent au chapitre "Dossier de gestion".
 
 \section{Découpage du projet}
 
-La réalisation de ce projet est découpée en plusieurs sous-projets différents qui correspondent à une partie de développement spécifique. Ce découpage permet notamment de tester ces différentes parties de façon indépendantes les unes des autres et d'être gérés dans des dépôts Git différents. Ce découpage correspond également à la structure des dossiers dans le CD annexe qui contient les codes sources.
+La réalisation de ce projet est découpée en plusieurs sous-projets distincts qui correspondent à une partie de développement spécifique. Ce découpage permet notamment de tester ces différentes parties de façon indépendantes les unes des autres et d'être gérés dans des dépôts Git isolé. Ce découpage correspond également à la structure des dossiers dans le CD annexe qui contient les codes sources.
 
 \begin{itemize}
     \item \textbf{backend:} Projet principal de l'application, c'est là qu'est écrit la partie métier du projet.
@@ -27,6 +27,6 @@ La réalisation de ce projet est découpée en plusieurs sous-projets différent
     \item \textbf{paltogem:} Module d'extension pour faire des requêtes sur les équipements PaloAlto$^{\mbox{\scriptsize{\textregistered}}}$
 \end{itemize}
 
-\section{Acronymes et définition}
+\section{Acronymes et définitions}
 
 Par expérience, le milieu des réseaux informatiques utilisent beaucoup d'acronymes. Il existe surtout beaucoup de standards et de protocoles qui font partie du vocabulaire courant lorsqu'on parle d'infrastructure réseau. Pour améliorer la compréhension de ce rapport, un glossaire de définitions et d'acronymes se trouvent à la fin de ce rapport. 

chapitres/introduction/network.tex

@@ -6,9 +6,9 @@ Pour être en mesure de comprendre le fonctionnement de l'analyse des règles de
 
 Le but d'un réseau informatique et d'acheminer des données sous forme de paquets \acrshort{ip} d'un n\oe{}ud A vers un ou plusieurs autres n\oe{}uds. Ces réseaux sont composés de plusieurs sortes d'équipements différents comme des routers, switches (commutateurs en français) mais aussi des équipements plus orienté sur la sécurité tels que des \glspl{firewall} ou \gls{proxy}. Tous ces équipements sont reliés ensemble via du câblages cuivre ou bien par du réseau optique. Ils forment ensemble le réseau physique. Son rôle est de faire transiter des trames ethernet d'un équipements à un autre, sans s'assurer qu'ils soient arrivés à destination.
 
-Contacter un n\oe{}ud réseau par son adresse physique (l'adresse \acrshort{mac}) peut vite s'avérer être un problème. Il faut être sur quelle soit unique dans l'entier du réseau, faute de quoi, la transmission ne pourra être faite. De plus, chaque changement d'équipement s'accompagne forcément d'un changement d'adresse matériel. Il n'est pas non plus possible d'isoler une machine d'une autre, ce qui rend impossible la mise en place de sécurité réseau. C'est notamment pour ces raisons qu'un réseau virtuel ou logique est configuré au dessus du réseau physique, réseau qui utilise les protocoles IP en version 4 ou 6. Ce système permet d'attribuer manuellement ou à la demande des adresses sur un no\oe{}ud indépandemment de son matériel. Il est également possible de créer plusieurs réseaux logiques sur un seul réseau physique (avec l'utilisation de VLAN), ce qui permet d'établier des règles de sécurité pour limiter les communications.
+Contacter un n\oe{}ud réseau par son adresse physique (l'adresse \acrshort{mac}) peut vite s'avérer être un problème. Il faut être sur quelle soit unique dans l'entier du réseau, faute de quoi, la transmission ne pourra être faite. De plus, chaque changement d'équipement s'accompagne forcément d'un changement d'adresse matériel. Il n'est pas non plus possible d'isoler une machine d'une autre, ce qui rend impossible la mise en place de sécurité réseau. C'est notamment pour ces raisons qu'un réseau virtuel ou logique est configuré au dessus du réseau physique, réseau qui utilise les protocoles IP en version 4 ou 6. Ce système permet d'attribuer manuellement ou à la demande des adresses sur un n\oe{}ud indépendamment de son matériel. Il est également possible de créer plusieurs réseaux logiques sur un seul réseau physique (avec l'utilisation de \acrshort{vlan}), ce qui permet d'établir des règles de sécurité pour limiter les communications.
 
-Bien que le protocole \acrshort{ip} amène un système d'adressage plus souple et modulaire, il ne s'assure pas que le paquet arrive correctement à destination. Il ne fournit pas non plus d'identifiant permettant à la machine distante de savoir quel processus doit traiter le paquet. Pour cela, deux protocoles principaux osnt utilisés aujourd'hui, il s'agit de \acrshort{tcp} et \acrshort{udp}. Ces deux protocoles vont attribuer un numéro de port aux segments échangés, afin que les systèmes d'exploitation soient en mesure de savoir quel programme doit traiter la requête.
+Bien que le protocole \acrshort{ip} amène un système d'adressage plus souple et modulaire, il ne s'assure pas que le paquet arrive correctement à destination. Il ne fournit pas non plus d'identifiant permettant à la machine distante de savoir quel processus doit traiter le paquet. Pour cela, deux protocoles principaux sont utilisés aujourd'hui, il s'agit de \acrshort{tcp} et \acrshort{udp}. Ces deux protocoles vont attribuer un numéro de port aux segments échangés, afin que les systèmes d'exploitation soient en mesure de savoir quel programme doit traiter la requête.
 
 Cette construction en couche superposée est standardisée par une structure connue sous le nom de modèle \acrshort{osi}\cite{wikiosi}.
 
@@ -137,11 +137,11 @@ Dans ce contexte là, pour qu'une machine du réseau Client 1 puisse communiquer
 
 Chaque entrée dans une table de routage indique un réseau (au format \acrshort{cidr}) et quel est le router suivant à qui envoyer le paquet afin de s'y rendre. En plus de cela, il existe des données supplémentaires qui permettent de déterminer quel est le meilleur chemin possible lorsque plusieurs route sont possibles. Dans le contexte de cette application, la table de routage correspond à la classe \Colorbox{light-gray}{\lstinline{RoutingTable}} (section \ref{sec:classe:routingtable}) et une route à la classe \Colorbox{light-gray}{\lstinline{Route}} (section \ref{sec:classe:route}).
 
-Dans les réseaux informatiques, les routers ont très souvent plusieurs liens vers d'autres routers afin d'assurer de la redondance en cas de perte de liens. Pour être capable de définir quel est le meilleur chemin possible, le router commence par déterminer quel est la route la plus précise. Admettons que l'on souhaite envoyer un paquet vers l'adresse 10.0.1.10, si on reprend la table de routage précédente, on peut voir qu'il existe une route vers le réseau 0.0.0.0/0 via le router 172.16.255.30 et une autre route pour le réseau 10.0.1.0/24 via le router 172.16.255.22. Ces deux routes sont valables pour l'adresse 10.0.1.10, mais la seconde route est plus précise dans le sens où le réseau de la route est plus petit. Au niveau du code, l'algorithme du choix de la route est fait avec la méthode \Colorbox{light-gray}{\lstinline{choosed_route}}.
+Dans les réseaux informatiques, les routers ont très souvent plusieurs liens vers d'autres routers afin d'assurer de la redondance en cas de perte de liens. Pour être capable de définir quel est le meilleur chemin possible, le router commence par déterminer quelle est la route la plus précise. Admettons que l'on souhaite envoyer un paquet vers l'adresse 10.0.1.10, si on reprend la table de routage précédente, on peut voir qu'il existe une route vers le réseau 0.0.0.0/0 via le router 172.16.255.30 et une autre route pour le réseau 10.0.1.0/24 via le router 172.16.255.22. Ces deux routes sont valables pour l'adresse 10.0.1.10, mais la seconde route est plus précise dans le sens où le réseau de la route est plus petit. Au niveau du code, l'algorithme du choix de la route est fait avec la méthode \Colorbox{light-gray}{\lstinline{choosed_route}} de l'objet \Colorbox{light-gray}{\lstinline{RoutingTable}}.
 
-Les routes peuvent avoir plusieurs types qui définissent une caractéristique propre aux routes qui s'appelle l'\emph{Administrative Distance}. Cet attribut définit la priorité d'un protocole sur un autre. Plus la valeur est basse, plus le type est prioritaire. Une route directement connectée (par exemple une adresse IP définie sur une interface du router), sera forcément prioritaire sur une route apprise par un quelconque protocole. Les routes moins prioritaires ne se voient pas dans la table de routage et il n'y a donc pas besoin de gérer cette partie là. Si deux routes ont la même \acrshort{ad}, c'est l'attribut \emph{Metric} qui sera utilisé pour évalué laquelle est la plus pertinente. Le calcul du metric et différent en fonction du protocole de routage utilisé, il s'agit souvent d'algorithmes assez complexes dont la compréhension n'est pas nécessaire dans le cadre du projet.
+Les routes peuvent avoir plusieurs types qui définissent une caractéristique propre aux routes qui s'appelle l'\emph{Administrative Distance}. Cet attribut définit la priorité d'un protocole sur un autre. Plus la valeur est basse, plus le type est prioritaire. Une route directement connectée (par exemple une adresse IP définie sur un interface du router), sera forcément prioritaire sur une route apprise par un quelconque protocole. Les routes moins prioritaires ne se voient pas dans la table de routage et il n'y a donc pas besoin de gérer cette partie là. Si deux routes ont la même \acrshort{ad}, c'est l'attribut \emph{Metric} qui sera utilisé pour évalué laquelle est la plus pertinente. Le calcul du metric et différent en fonction du protocole de routage utilisé, il s'agit souvent d'algorithmes assez complexes dont la compréhension n'est pas nécessaire dans le cadre du projet.
 
-La dernière caractéristique importante d'une route est son interface de sortie. C'est le port physique de l'équipement que le paquet va utiliser pour rejoindre le prochain router. Cette information est notamment utilisée par la méthode \Colorbox{light-gray}{\lstinline{crossed?}} (section \ref{sec:methodes:crossed}) afin de savoir si un flux va traverser le router. La logique utilisée dans ce cas découle directement de cet attribut, car un flux est définit par un réseau source et destination. Si l'interface de sortie pour ces deux réseaux est la même, cela signifie que l'équipement réseau ne sera jamais traversé par ce flux.
+La dernière caractéristique importante d'une route est son interface de sortie. C'est le port logique de l'équipement que le paquet va utiliser pour rejoindre le prochain router. Cette information est notamment utilisée par la méthode \Colorbox{light-gray}{\lstinline{crossed?}} (section \ref{sec:methodes:crossed}) afin de savoir si un flux va traverser le router. La logique utilisée dans ce cas découle directement de cet attribut, car un flux est définit par un réseau source et destination. Si l'interface de sortie pour ces deux réseaux est la même, cela signifie que l'équipement réseau ne sera jamais traversé par ce flux.
 
 \newpage
 \section{Couche 4 - Transport}
@@ -150,7 +150,7 @@ La dernière caractéristique importante d'une route est son interface de sortie
 
 Si la couche trois définit l'adressage logique qui fournit les outils pour acheminer les paquets dans un réseau, la couche quatre va permettre de définir comment ces communications sont gérées par les n\oe{}uds. Il existe plusieurs protocoles de transport différent mais en pratique, \acrshort{tcp} et \acrshort{udp} sont ceux qui sont le plus utilisés dans les réseaux internes d'entreprise. Ces deux protocoles ont comme point commun le fait d'utiliser un numéro de port pour identifier leurs communications. De la même façon qu'il y a une adresse IP source et destination, il y a aussi un port source et destination. Le port de destination est utilisé par le n\oe{}ud de destination pour savoir quel processus doit traiter cette requête. Le numéro de port est codé sur 16bits et bien que n'importe quel programme peut utiliser un port, les 1024 premiers sont considérés comme "well-known" et sont identifiés\cite{wellknownports} par l'\acrshort{iana}. Par exemple, le protocol HTTP utilisé pour les applications web utilisent le port 80 et sa version chiffrée, le HTTPS, le 443. Ces éléments s'appellent des services et correspondent dans cette application à la classe \Colorbox{light-gray}{\lstinline{Service}} (section \ref{sec:classe:service}) qui sont composés d'une liste de port \acrshort{tcp} et \acrshort{udp} qui sont représentés par la classe \Colorbox{light-gray}{\lstinline{PortRange}}.
 
-Lorsqu'un n\oe{}ud "client" ouvre une connexion vers un n\oe{}ud "serveur", il va utiliser un port source aléatoire géré par le système d'exploitation et le port de destination est définis par le programme utilisé. 
+Lorsqu'un n\oe{}ud "client" ouvre une connexion vers un n\oe{}ud "serveur", il va utiliser un port source aléatoire géré par le système d'exploitation et le port de destination est défini par le programme utilisé. 
 
 \vspace{3mm}
 \begin{figure}[H]
@@ -164,12 +164,12 @@ Lorsqu'un n\oe{}ud "client" ouvre une connexion vers un n\oe{}ud "serveur", il v
 \subsection{Firewall}
 \label{subsec:network:ip:firewall}
 
-Les \glspl{firewall} (classe \Colorbox{light-gray}{\lstinline|Device|}) sont des routers qui sont également capable de gérer les protocoles de la couche quatre. Ils sont utilisés pour filtrer les communications entre les réseaux en filtrant les échanges basé sur les ports destinations. Ces équipements de sécurité permettent donc de n'autoriser que les paquets à destination d'un n\oe{}ud spécifique et sur un ou plusieurs ports. Ces filtres sont représentés par des règles de sécurité qui correspondent ici à la classe \Colorbox{light-gray}{\lstinline|Policy|}.
+Les \glspl{firewall} (classe \Colorbox{light-gray}{\lstinline|Device|}) sont des routers qui sont également capable de gérer les protocoles de la couche quatre. Ils sont utilisés pour filtrer les communications entre les réseaux en analysant les échanges basé sur leurs ports de destinations. Ces équipements de sécurité permettent donc de n'autoriser que les paquets à destination d'un n\oe{}ud spécifique et sur un ou plusieurs ports. Ces filtres sont représentés par des règles de sécurité qui correspondent ici à la classe \Colorbox{light-gray}{\lstinline|Policy|}.
 
 \begin{table}[H]
     \centering
     \caption{Exemples de règles de sécurité}
-    \label{rules-tab}
+    \label{sec:rules:tab}
     \begin{tabular}{|l|l|l|l|l|l|l|}
         \hline
         \small{\textbf{Id}} &\small{\textbf{Int. source}} &\small{\textbf{Int. destination}} &\small{\textbf{Source}} &\small{\textbf{Destination}} &\small{\textbf{Service}} &\small{\textbf{Action}}   \\ \hline
@@ -181,6 +181,6 @@ Les \glspl{firewall} (classe \Colorbox{light-gray}{\lstinline|Device|}) sont des
     \end{tabular}
 \end{table}
 
-Les polices de sécurité sont analysées et évaluées de façon séquentielle, dès que les critères d'une règles sont tous respectés, l'action est effectuée. Par exemple, si un poste de travail avec une adresse IP 192.168.1.57 essaie de se connecter en HTTPS (port TCP/443) sur le serveur 10.0.1.2, sa requête va passé au travers du firewall qui va analyser le flux pour définir s'il doit être accepté ou non, en utilisant la liste de règles du tableau \refname{rules-tab} et en admettant que le réseau 192.168.1.0/24 est bien connu par l'interface "client" et le réseau 10.0.1.0/24 par l'interface "server".
+Les polices de sécurité sont analysées et évaluées de façon séquentielle, dès que les critères d'une règle sont tous respectés, l'action est effectuée. Par exemple, si un poste de travail avec une adresse IP 192.168.1.57 essaie de se connecter en HTTPS (port TCP/443) sur le serveur 10.0.1.2, sa requête va passé au travers du firewall qui va analyser le flux pour définir s'il doit être accepté ou non, en utilisant la liste de règles du tableau \refname{sec:rules:tab} et en admettant que le réseau 192.168.1.0/24 est bien connu par l'interface "client" et le réseau 10.0.1.0/24 par l'interface "server".
 
 La première règle décrit bien un flux provenant de l'interface "client" vers "server", la source est le réseau "192.168.1.0/24" dans lequel l'adresse IP source "192.168.1.57" se trouve, cependant la destination indique un réseau "10.0.1.1/32" qui ne correspond pas à notre serveur "10.0.1.2". Les conditions n'étant pas toutes validées, le firewall va passer à la seconde règle et recommencer la même analyse. Dans la seconde règle, la destination est "10.0.1.2/32" qui est bien la destination du flux analysé, il ne reste donc que le service à valider. Notre communication utilise le port de destination tcp/443 qui est bien dans la liste de la règle. Les conditions étant toutes validées, l'action est appliquée, ce qui correspond dans ce cas à laisser le flux passer. Ce processus est ainsi répété pour chaque nouvelle connexion passant au travers du firewall.

chapitres/model/classes.tex

@@ -2,7 +2,7 @@
 
 \section{Diagramme de classe}
 
-Les modèles décrit dans la section suivante sont liées à des collections dans la base de données MongoDB. C'est le module mongoid\cite{mongoid} qui va s'occuper de faire la corrélation entre ce qui est décrit dans la classe en ruby et le schéma de la base dans MongoDB. Dans une structure non-relationnelle comme c'est le cas ici, un objet peut en contenir un autre. C'est notamment le cas pour le modèle \Colorbox{light-gray}{\lstinline|Device|}, qui va contenir tous les objets qui lui sont propre. Cette architecture a pour avantage de pouvoir plus facilement décrire les contraintes sur certains objets. Typiquement, l'attribut "name" d'un objet \Colorbox{light-gray}{\lstinline|Address|} doit être unique, mais uniquement dans le contexte de l'équipement auquel il est attaché. Si on utilise un outil pour afficher le contenu de la base, on constate bien que chaque objet \lstinline|Device| contient les autres objets qui lui sont associés.
+Les modèles décrit dans la section suivante sont liées à des collections dans la base de données MongoDB. C'est le module mongoid\cite{mongoid} qui va s'occuper de faire la corrélation entre ce qui est décrit dans la classe en ruby et le schéma de la base dans MongoDB. Dans une structure non-relationnelle comme c'est le cas ici, un objet peut en contenir un autre. C'est notamment le cas pour le modèle \Colorbox{light-gray}{\lstinline|Device|}, qui va contenir tous les objets qui lui sont propre. Cette architecture a pour avantage de pouvoir plus facilement décrire les contraintes sur certains objets. Typiquement, l'attribut "name" d'un objet \Colorbox{light-gray}{\lstinline|Address|} doit être unique, mais uniquement dans le contexte de l'équipement auquel il est attaché. Si on utilise un outil pour afficher le contenu de la base, on constate bien que chaque objet \Colorbox{light-gray}{\lstinline|Device|} contient les autres objets qui lui sont associés.
 
 \vspace{3mm}
 \begin{figure}[h]
@@ -24,7 +24,7 @@ Cette structure est possible pour les objets qui n'ont de sens que dans le conte
 
 \subsection{Credential}
 
-Cette classe est utilisée pour sauvegarder les informations d'identifications pour accéder aux équipements et est identifiable par un nom unique. Le mot de passe est enregistré dans la base de donnée de façon chiffrée, mais avec un chiffrement symétrique, car il est nécessaire de pouvoir le réutiliser pour s'authentifier par la suite sur les équipements. Les fonctions pour chiffrer et déchiffrer le mot de passe sont fournit par l'attribut "password".
+Cette classe est utilisée pour sauvegarder les informations d'identification pour accéder aux équipements et est identifiable par un nom unique. Le mot de passe est enregistré dans la base de donnée de façon chiffrée, mais avec un chiffrement symétrique, car il est nécessaire de pouvoir le réutiliser pour s'authentifier par la suite sur les équipements. Les fonctions pour chiffrer et déchiffrer le mot de passe sont fournit par l'attribut "password".
 
 \vspace{3mm}
 \begin{lstlisting}[language=Ruby, title="app/model/credential.rb"]
@@ -44,13 +44,13 @@ Cette classe est utilisée pour sauvegarder les informations d'identifications p
 \end{lstlisting}
 \vspace{3mm}
 
-Les méthodes pour chiffrer et déchiffrer les mots de passe sont fournit par le module "Symmetric\-Encryption"\cite{symmetricencryption}. Ce dernier utilise un système de clés pour cela qui sont définies dans le fichier "backend/config/symmetric-encryption.yml". Ce fichier est volontairement exclu de Git afin que les clés ne se retrouve pas dans le dépot. Lors du premier développement, il faut générer un jeu de clés avec la commande précisée dans le "README.md" du projet. En production, le fichier doit être généré sur le serveur et utilise des mécanismes plus avancés pour assurer un meilleur niveau de chiffrement.
+Les méthodes pour chiffrer et déchiffrer les mots de passe sont fournit par le module "Symmetric\-Encryption"\cite{symmetricencryption}. Ce dernier utilise un système de clés pour cela qui sont définies dans le fichier "backend/config/symmetric-encryption.yml". Ce fichier est volontairement exclu de Git afin que les clés ne se retrouve pas dans le dépot. Lors du premier lancement de l'application, il faut générer un jeu de clés avec la commande précisée dans le "README.md" du projet. En production, le fichier doit être généré sur le serveur et utilise des mécanismes plus avancés pour assurer un meilleur niveau de chiffrement.
 
 \newpage
 \subsection{Address}
 \label{sec:classe:address}
 
-Il s'agit d'un élément d'une règle de sécurité (\Colorbox{light-gray}{\lstinline|Policy|}) qui décrit un objet réseau caractérisé par un réseau IPv4 au format \acrshort{cidr}. De ce réseau nous allons pouvoir en déduire la première et dernière adresse IP. Ces addresses seront ensuite converties en décimal pour pouvoir être indexé par la base de donnée. Ainsi \Colorbox{light-gray}{\lstinline|start_ip|} est la représentation numérique de la première adresse IP de ce réseau, et \Colorbox{light-gray}{\lstinline|end_ip|} la dernière. Dans le cas où le réseau ne contient qu'une seule adresse IP (masque réseau de 32 bits (cité la doc réseau au début)), ces deux valeurs seront identiques. Ces dernières sont calculées à chaque modifications de l'attribut network.
+Il s'agit d'un élément d'une règle de sécurité (\Colorbox{light-gray}{\lstinline|Policy|}) qui décrit un objet réseau caractérisé par un réseau IPv4 au format \acrshort{cidr}. De ce réseau nous allons pouvoir en déduire la première et dernière adresse IP. Ces addresses seront ensuite converties en décimal pour pouvoir être indexé par la base de donnée. Ainsi \Colorbox{light-gray}{\lstinline|start_ip|} est la représentation numérique de la première adresse IP de ce réseau, et \Colorbox{light-gray}{\lstinline|end_ip|} la dernière. Dans le cas où le réseau ne contient qu'une seule adresse IP (masque réseau de 32 bits), ces deux valeurs seront identiques. Ces dernières sont calculées à chaque modifications de l'attribut network.
 
 \vspace{3mm}
 \begin{lstlisting}[language=Ruby, title="app/model/address.rb"]
@@ -64,7 +64,7 @@ Il s'agit d'un élément d'une règle de sécurité (\Colorbox{light-gray}{\lsti
 \end{lstlisting}
 \vspace{3mm}
 
-Cette classe fournit également la méthode match? (section ) qui permet de savoir si un réseau exprimé au format \acrshort{cidr} est contenu dans l'objet en question. Pour cela, il suffit de vérifier que les adresses limites du réseau en paramètre soient comprises dans l'objet en question.
+Cette classe fournit également la méthode \Colorbox{light-gray}{\lstinline|match?|} qui permet de savoir si un réseau exprimé au format \acrshort{cidr} est contenu dans l'objet en question. Pour cela, il suffit de vérifier que les adresses limites du réseau en paramètre sont comprises dans l'objet en question.
 
 \vspace{3mm}
 \begin{lstlisting}[language=Ruby, title="app/model/address.rb"]
@@ -109,7 +109,7 @@ Il fournit également la méthode 'match?' qui va retourner 'true' si l'ensemble
 
 \subsection{ServiceGroup}
 
-Un groupe de service est simplement un objet dont l'attribut 'addresses' contient le nom de toutes les \Colorbox{light-gray}{\lstinline|Address|} qu'il contient.
+Un groupe de service est simplement un objet dont l'attribut 'services' contient le nom de toutes les \Colorbox{light-gray}{\lstinline|Service|} qu'il contient.
 
 \subsection{Zone}
 
@@ -128,18 +128,18 @@ La table de routage est un élément des équipement réseaux et est composée d
 \newpage
 \subsection{Policy}
 
-Une \Colorbox{light-gray}{\lstinline|Policy|} représente un règle de sécurité dans un équipement réseau. Elle décrit comment ce dernier doit se comporter lorsqu'il est traversé par des flux réseaux. En fonction de la source et de la destination du paquet (représenté sous forme d'\Colorbox{light-gray}{\lstinline|Address|} (section \ref{sec:classe:address}) ainsi que du protocol et de son numéro de port utilisé (représenté par le \Colorbox{light-gray}{\lstinline|Service|} (section \ref{sec:classe:service})), la règle va définir si la communication est autorisée où si elle doit être bloquée. 
+Une \Colorbox{light-gray}{\lstinline|Policy|} représente un règle de sécurité dans un équipement réseau. Elle décrit comment ce dernier doit se comporter lorsqu'il est traversé par des flux réseaux. En fonction de la source et de la destination du paquet (représenté sous forme d'\Colorbox{light-gray}{\lstinline|Address|} (section \ref{sec:classe:address}) ainsi que du protocol et de son numéro de port utilisé (représentés par le \Colorbox{light-gray}{\lstinline|Service|} (section \ref{sec:classe:service})), la règle va définir si la communication est autorisée où si elle doit être bloquée. 
 
-La source et la destination sont deux champs qui peuvent contenir un ou plusieurs nom de \Colorbox{light-gray}{\lstinline|Address|} et/ou \Colorbox{light-gray}{\lstinline|AddressGroup|}. Le champ service peut être composé de un ou plusieurs nom de \Colorbox{light-gray}{\lstinline|Service|} et/ou \Colorbox{light-gray}{\lstinline|ServiceGroup|}. En plus de cela, la règle de sécurité peut contenir le ou les interfaces source et destination. Il s'agit de l'interface par lequel le flux doit arriver pour que la règle soit évaluée. Il se peut qu'une interface face partie d'un groupe d'interfaces qui s'appelle dans ce cas là, une \Colorbox{light-gray}{\lstinline|Zone|}. 
+La source et la destination sont deux champs qui peuvent contenir un ou plusieurs nom de \Colorbox{light-gray}{\lstinline|Address|} et/ou \Colorbox{light-gray}{\lstinline|AddressGroup|}. Le champ service peut être composé de un ou plusieurs nom de \Colorbox{light-gray}{\lstinline|Service|} et/ou \Colorbox{light-gray}{\lstinline|ServiceGroup|}. En plus de cela, la règle de sécurité peut contenir le ou les interfaces source et destination. Il s'agit de l'interface par lequel le flux doit passer pour que la règle soit évaluée. Il se peut qu'une interface face partie d'un groupe d'interfaces qui s'appelle dans ce cas là, une \Colorbox{light-gray}{\lstinline|Zone|}. 
 
 Le dernier attribut d'une règle de sécurité est l'action à faire lorsqu'un flux correspond aux critères de la règle. Les deux seuls actions possibles sont "accept" ou "deny", qui vont respectivement laisser passer le flux, ou bien le bloquer.
 
 \subsection{Device}
 
-Les équipements de sécurité gérés dans l'application sont des objets de type \Colorbox{light-gray}{\lstinline|Device|}. Il s'agit de la classe principale de l'application étant donné que la plupart des autres objets dépendent directement d'un équipement. Il fournit la méthode \nameref{sec:methodes:matched_policies} qui permet de mettre en place la feature principale de l'application, soit la recherche de règles de sécurité.
+Les équipements de sécurité gérés dans l'application sont des objets de type \Colorbox{light-gray}{\lstinline|Device|}. Il s'agit de la classe principale de l'application étant donné que la plupart des autres objets dépendent directement d'un équipement. Il fournit la méthode \nameref{sec:methodes:matched_policies}(section \ref{sec:methodes:matched_policies}) qui permet de mettre en place la fonctionnalité principale de l'application, soit la recherche de règles de sécurité.
 
 \subsection{Task}
 
-Afin que les informations de configurations des équipements puissent être récupérées régulièrement, cela se fait sous forme de tâche qui vont être exécuter de façon asynchrone par le module Sidekiq\cite{sidekiq}. Une fois une tache valide créée, l'application va  l'ajouter en file d'attente pour qu'elle soit ensuite traitée par le programme d'exécution qui tourne en parallèle. Les différents files sont gérées avec le système de base de donnée en mémoire Redis\cite{redis}.
+Afin que les informations de configurations des équipements puissent être récupérées régulièrement, cela se fait sous forme de tâche qui vont être exécuter de façon asynchrone par le module Sidekiq\cite{sidekiq}. Une fois une tache valide créée, l'application va  l'ajouter en file d'attente pour qu'elle soit ensuite traitée par le programme d'exécution qui tourne en parallèle. Les différentes files sont gérées avec le système de base de donnée en mémoire Redis\cite{redis}.
 
 Il existe deux taches différentes, la \Colorbox{light-gray}{\lstinline|PolicyRetrievalJob|} et \Colorbox{light-gray}{\lstinline|RoutingTableRetrievalJob|}. La première va s'occuper de récupérer sur les équipements les polices de sécurité ainsi que les objets qui les composent. La seconde va obtenir l'état actuel de la table de routage de l'équipement pour mettre à la base. Ces deux tâches sont séparées afin de pouvoir les exécuter indépendament l'une de l'autre. En pratique, la table de routage d'un équipement peut évoluer sans intervention humaine, on souhaite donc pouvoir la mettre à jour plus fréquement que pour les règles de sécurité qui elles ne changent que lorsqu'une modification est faite.

chapitres/model/methodes.tex

@@ -2,7 +2,7 @@
 
 \subsection{route}
 
-La méthode "route" retourne la route (\Colorbox{light-gray}{\lstinline|Route|}), utilisée par l'équipement (\Colorbox{light-gray}{\lstinline|Device|}) pour atteindre le réseau spécifié. C'est une mise en application de ce qui est expliqué dans la section \ref{subsec:network:ip:routing}. Pour y arriver, il faut donc obtenir ceux dont les adresses limites du réseau comprennent celle du réseau voulu.
+La méthode "route" retourne la route (\Colorbox{light-gray}{\lstinline|Route|}), utilisée par l'équipement (\Colorbox{light-gray}{\lstinline|Device|}) pour atteindre le réseau spécifié. C'est une mise en application de ce qui est expliqué dans la section \ref{subsec:network:ip:routing}. Pour y arriver, il faut donc obtenir celles dont les adresses limites du réseau comprennent celle du réseau voulu.
 
 \vspace{3mm}
 \begin{lstlisting}[language=Ruby, title="app/model/routing\_table.rb"]
@@ -19,7 +19,7 @@ La méthode "route" retourne la route (\Colorbox{light-gray}{\lstinline|Route|})
 \end{lstlisting}
 \vspace{3mm}
 
-Une fois les routes possibles obtenues, il faut encore isolé celle qui est la plus précise. Pour cela, il suffit de calculer le nombre d'adresses maximum disponibles dans le réseau et de choisir celui qui en a le moins.
+Une fois les routes possibles obtenues, il faut encore isoler celle qui est la plus précise. Pour cela, il suffit de calculer le nombre d'adresses disponibles dans le réseau et de choisir celle qui en a le moins.
 
 \vspace{3mm}
 \begin{lstlisting}[language=Ruby, title="app/model/routing\_table.rb"]
@@ -116,4 +116,4 @@ Le but ici est de faire la requête de recherche et de retourner toutes les règ
   end
 \end{lstlisting}
 
-La requête sur la base de donnée qui permet d'obtenir les règles de sécurité voulues est définie dans la fonction ci-dessous. Pour cela, il faut commencer par isoler les adresses source et destination ainsi que les services. On cherche ici à comparer des tableaux de String entre eux et à savoir si au moins un des éléments de ce tableau se retrouvent dans l'autre tableau. La méthode utilisée pour cela est "any\_in"\cite{stackanyin} en lui précisant les paramètres.
+La requête sur la base de donnée qui permet d'obtenir les règles de sécurité voulues est définie dans la fonction ci-dessus. Pour cela, il faut commencer par isoler les adresses source et destination ainsi que les services. On cherche ici à comparer des tableaux de String entre eux et à savoir si au moins un des éléments de ce tableau se retrouvent dans l'autre tableau. La méthode utilisée pour cela est "any\_in"\cite{stackanyin} en lui précisant les paramètres.

chapitres/model/validation.tex

@@ -7,7 +7,7 @@ Pour valider le bon fonctionnement de l'application et mettre en place le \gls{t
 
 \subsection{QUnit}
 
-QUnit\cite{qunit} est un ensemble d'outil javascript qui permettent d'écrire des tests pour les applications WEB. Il peut simuler des cliques d'utilisateur sur des éléments de la page et de récupérer le contenu d'un DOM pour valider le bon fonctionnement des actions. Ce framework est utilisé nativement par EmberJS pour écrire les tests, les fichiers se trouvent dans le dossier \Colorbox{light-gray}{\lstinline|tests/|} à la racine du projet.
+QUnit\cite{qunit} est un ensemble d'outil javascript qui permettent d'écrire des tests pour les applications WEB. Il peut simuler des cliques d'utilisateur sur des éléments de la page et de récupérer le contenu d'un \acrshort{dom} pour valider le bon fonctionnement des actions. Ce framework est utilisé nativement par EmberJS pour écrire les tests, les fichiers se trouvent dans le dossier \Colorbox{light-gray}{\lstinline|tests/|} à la racine du projet.
 
 \subsection{ESLint}
 
@@ -41,4 +41,4 @@ Les tests se lancent avec la commande \Colorbox{light-gray}{\lstinline|bundle ex
 
 \subsection{Brakeman}
 
-Brakeman\cite{brakeman} est également un analyseur de code mais qui va plutôt chercher des vulnérabilités et des problèmes de sécurité dans le code. Les tests se lancent avec la commande \Colorbox{light-gray}{\lstinline|bundle exec brakeman|} depuis la racine du projet.
+Brakeman\cite{brakeman} est également un analyseur de code mais qui va plutôt chercher des vulnérabilités et des problèmes de sécurité dans le code. Les tests se lancent depuis la racine du projet avec la commande \Colorbox{light-gray}{\lstinline|bundle exec brakeman|}.

index.tex

@@ -50,8 +50,8 @@
 % Marges
 \usepackage{geometry}
 \geometry{
-  left=2cm,
+  left=2.5cm,
-  right=2.5cm,
+  right=2cm,
   top=2cm,
   bottom=2cm,
   headheight=35pt,