diff --git a/rapport/enonce.pdf b/rapport/enonce.pdf
index 40ebd42bf860fd5bf8b73142eab1fd6b902f325a..ddf1ee6a7c92bea8ce584f741938c2827f33a8d8 100644
Binary files a/rapport/enonce.pdf and b/rapport/enonce.pdf differ
diff --git a/rapport/text/3-etude.md b/rapport/text/3-etude.md
index 33b7646367f0241e4d93a4738c0d3c031822da66..de6dbc69a5d2bafb14b8633514aab9ff58d45299 100644
--- a/rapport/text/3-etude.md
+++ b/rapport/text/3-etude.md
@@ -40,7 +40,7 @@ Il existe toutefois plusieurs techniques particulièrement utilisées. Certaines
 Au vu de leur utilisation, les (+API_a) restent aujourd'hui la méthode préférée d'échange de données. Elles ont l'avantage, contrairement aux autres méthodes, de proposer quasi-directement la récupération des informations.
 
 Les (+API_a) cependant restent rares; de nombreux sites n'en ont pas. Dans le cas où elles en proposent, elles sont souvent payantes, accessibles sur permission uniquement, limitées et peu ou pas documentées.
-En outre, les (+API_a), lesquelles représentent $83\%$ du trafic HTTP mondial [@akamai_state_2019], constitue une lourde charge pour l'exploitant du site, qu'elle soit technique ou financière. Qui plus est, il est potentiellement nécessaire de payer un développeur pour la développer et la maintenir.
+En outre, les (+API_a), lesquelles représentent $83\%$ du trafic HTTP mondial [@akamai_state_2019], constituent une lourde charge pour l'exploitant du site, qu'elle soit technique ou financière. Qui plus est, il est potentiellement nécessaire de payer un développeur pour la développer et la maintenir.
 
 D'autres sites, qui composent la grande majorité des sites, ne proposent aucun système de récupération. Le site web lui-même est le seul accès aux documents possible. L'utilisateur doit alors aller récupérer manuellement les documents un par un. Par exemple, un des sites de l'Etat de Genève nommé FAO refuse de proposer une API car les informations sont disponibles gratuitement en ligne [@departement_presidentiel_notitle_2018].
 
@@ -96,7 +96,7 @@ Employer des techniques douteuses n'est pas puni par la loi mais peut être vu d
 
 La question juridique du scraping est complexe. C'est un sujet décrié par les grandes entreprises [@bode_court_2019], qui semble commencer à être réglementé [@igor_us_2018]. La règle d'or semble être de faire preuve de bon sens en ne causant aucun tort à l'entreprise fournissant des données[^8]. Pour pouvoir le vérifier, un contrôle total de l'application est nécessaire, ce qui est uniquement possible avec un framework.
 
-[^8]: Ne pas faire preuve de fair-play est un exemple d'une entreprise ne faisant pas usage du bon sens.
+[^8]: Ne pas faire preuve de fair-play en téléchargeant les données privées d'un site sans en demander la permission est un exemple d'une entreprise ne faisant pas usage du bon sens.
 
 ### Bilan intermédiaire
 
diff --git a/rapport/text/4-conception.md b/rapport/text/4-conception.md
index 399b7bda4ac0f9142f5993d7c912435e0d943665..eccf50c91fc448356f478e718cb83cc1b3d96f80 100644
--- a/rapport/text/4-conception.md
+++ b/rapport/text/4-conception.md
@@ -9,13 +9,13 @@ Ce projet propose un certain nombres de termes afin de simplifier la compréhens
 * Workflow : Le terme workflow désigne une liste dans un ordre précis de tâches.
 * Module : une action prédéterminée (cliquer quelque part, ouvrir un navigateur, effectuer une addition, etc.).
 * Tâche : une tâche est une instance d'un module.
-* Worker : Un système permettant de démarrer plusieurs workflow sur la même machine.
+* Worker : Un système permettant de démarrer plusieurs workflows sur la même machine.
 
 ## Cahier des charges
 
 Plusieurs critères permettent de garantir un fonctionnement optimal lors de la récupération de documents sur différents sites web.
 
-* **Distributivité** : Les différents workflow doivent être distribués, c'est-à-dire répartis sur plusieurs machines différentes. De cette façon, il est possible d'accélérer le téléchargement de données et de répartir la charge sur plusieurs machines.
+* **Distributivité** : Les différents workflows doivent être distribués, c'est-à-dire répartis sur plusieurs machines différentes. De cette façon, il est possible d'accélérer le téléchargement de données et de répartir la charge sur plusieurs machines.
 * **Parallélisme** : Pour accélérer le téléchargement de données, il est encore possible d'utiliser les différents coeurs du processeur de chaque machine accueillant Inari.
 * **Simple d'utilisation** : Un utilisateur sans formation préalable doit être en mesure de se servir de ce logiciel.
 * **Robustesse** : Le logiciel doit être capable de résister aux pannes. Par exemple, si un client Inari venait à s'arrêter, il devrait être possible de le remettre en état pour relancer les tâches que le client était en train de faire.
@@ -35,11 +35,11 @@ Inari fonctionne sur un modèle client-serveur. Le client se charge de télécha
 
 * L'interaction entre l'utilisateur et les clients;
 * La récupération des documents téléchargés par chaque client;
-* La gestion des workflow, c'est-à-dire leur création comme leur exécution;
+* La gestion des workflows, c'est-à-dire leur création comme leur exécution;
 * La répartition des tâches entre les clients.
 
-La figure 2.1 montre le schéma suivi par un workflow à son lancement. Pour commencer, le client se connecte au serveur web et sélectionne un workflow (flèches 1 et 2). Là, il peut sélectionner les documents qu'il souhaite récupérer. Ce choix fait, l'utilisateur lance le workflow. Cela enregistre dans la base de données les tâches à exécuter (flèche 3). Ces tâches sont ensuite envoyées au serveur Inari (flèche 4), qui répartit de façon équitable les tâches à effectuer
-aux différents clients (flèche 5). Les documents sont alors téléchargés par les clients qui, à chaque tâche effectuée, informent le contrôleur du succès ou de l'échec de la tâche (flèche 6). Enfin, le client peut, une fois tous les documents récupérés, télécharger une archive des clients contenant l'ensemble des documents téléchargés jusqu'ici (flèche 7).
+La figure 2.1 montre le schéma suivi par un workflow à son lancement. Pour commencer, le client se connecte au serveur web et sélectionne un workflow (flèches un et deux). Là, il peut sélectionner les documents qu'il souhaite récupérer. Ce choix fait, l'utilisateur lance le workflow. Cela enregistre dans la base de données les tâches à exécuter (flèche trois). Ces tâches sont ensuite envoyées au serveur Inari (flèche quatre), qui répartit de façon équitable les tâches à effectuer
+aux différents clients (flèche cinq). Les documents sont alors téléchargés par les clients qui, à chaque tâche effectuée, informent le contrôleur du succès ou de l'échec de la tâche (flèche six). Enfin, le client peut, une fois tous les documents récupérés, télécharger une archive des clients contenant l'ensemble des documents téléchargés jusqu'ici (flèche sept).
 
 ### Communication
 
@@ -57,7 +57,7 @@ Le mode _single_ permet, comme son nom l'indique, de lancer un workflow une fois
 
 \cimg{figs/bulk.png}{scale=.35}{Exemple d'application du mode bulk}{Source : créé par Théo PIRKL}
 
-Les informations entrées dans le mode bulk sont combinées entre elles. Par exemple, à la figure 2.2, une tâche est lancée avec le paramètres `month` à 9, `sid` à 6307.9099 et `year` à 2017; une autre est lancée avec les paramètres `month` à 10, `sid` à 6307.9099 et `year` à 2017. Toutes les combinaisons des paramètres rentrés sont alors convertis en workflow. Cette façon de faire permet de rentrer  rapidement un nombre important de workflow. Afin d'éviter de charger le contrôleur inutilement, c'est le client qui calcule toutes les combinaisons. Le contrôleur, quant à lui, reçoit les workflow générées et se contente de les répartir entre les clients Inari disponibles.
+Les informations entrées dans le mode bulk sont combinées entre elles. Par exemple, à la figure 2.2, une tâche est lancée avec le paramètres `month` à 9, `sid` à 6307.9099 et `year` à 2017; une autre est lancée avec les paramètres `month` à 10, `sid` à 6307.9099 et `year` à 2017. Toutes les combinaisons des paramètres rentrés sont alors convertis en workflow. Cette façon de faire permet de rentrer  rapidement un nombre important de workflow. Afin d'éviter de charger le contrôleur inutilement, c'est le client qui calcule toutes les combinaisons. Le contrôleur, quant à lui, reçoit les workflow générés et se contente de les répartir entre les clients Inari disponibles.
 
 Inari envoie de façon intelligente les workflows sur le client le moins chargé. Il consulte pour cela sa base de données, et sélectionne le client possédant le moins de workflows. Cela permet de garantir un fonctionnement équitable de chaque client, et en cas de panne, de ne pas avoir à relancer une grande partie des workflows.
 Dans le mode _single_, un workflow est automatiquement assigné à un client Inari. Dans le mode _bulk_, en revanche, l'ensemble des workflows reçus sont distribués à tous les clients. De cette façon, si un utilisateur génère 200 workflows à exécuter puis 2000, les tâches sont malgré tout réparties également entre chaque client. Il y aura donc deux clients avec 1100 workflows et non un avec 200 et l'autre avec 2000.
@@ -71,7 +71,7 @@ Le parallélisme permet, de manière générale, d'accélérer le traitement de
 
 Le multiprocessing permet de mettre à contribution chaque coeur du processeur sur lequel est exécuté le client Inari. Le multiprocessing permet d'isoler chaque traitement. Le multithreading n'était pas utilisable dans le cadre de ce projet en raison de la technologie utilisée pour télécharger les documents [@noauthor_multithreading_nodate].
 
-L'utilisation d'un pool de clients Inari, quant à elle, permet d'ajouter une couche de parallélisme : on pourrait comparer son utilisation à un multiprocessing de haut niveau, où tous les ordinateurs formeraient ensemble un seul processeur. Utiliser plusieurs ordinateurs apporte aussi une redondance dans le traitement des documents. Dans le cas où un ordinateur hébergeant un client Inari venait à tomber en panne pendant un traitement, il est possible d'une part de relancer les tâches. On pourrait ensuite choisir de les relancer sur le même ordinateur une fois son fonctionnement restauré, ou sur un autre. L'utilisation des deux technologies de parallélisme permet non seulement de prévenir des pannes, mais aussi d'utiliser de façon optimale les ressources de chaque ordinateur accueillant un client Inari.
+L'utilisation d'un pool de clients Inari, quant à elle, permet d'ajouter une couche de parallélisme : on pourrait comparer son utilisation à un multiprocessing de haut niveau, où tous les ordinateurs formeraient ensemble un seul processeur. Utiliser plusieurs ordinateurs apporte aussi une redondance dans le traitement des documents. Dans le cas où un ordinateur hébergeant un client Inari venait à tomber en panne pendant un traitement, il serait possible relancer les tâches. On pourrait ensuite choisir de les relancer sur le même ordinateur une fois son fonctionnement restauré, ou sur un autre. L'utilisation des deux technologies de parallélisme permet non seulement de prévenir des pannes, mais aussi d'utiliser de façon optimale les ressources de chaque ordinateur accueillant un client Inari.
 De cette façon, il est possible de traiter plusieurs workflows en même temps. Le workflow n'est donc pas accéléré mais la quantité de workflows exécutables en simultané est augmentée.
 Par exemple, si huit machines sont considérées comme clients et que chacune possède huit coeurs, il est théoriquement possible de lancer $64$ workflows à la fois. Théoriquement, car les workflows peuvent consommer des ressources importantes et lancer trop de workflow à la fois peut surcharger l'ordinateur sur lequel est hébergé un des clients Inari. Il est donc important, en configurant les clients Inari, de ne pas allouer à ces derniers la totalité des ressources système à disposition.
 Le chapitre _mesures_ montre l'accélération observée lors des mesures grâce au parallélisme.
@@ -84,7 +84,7 @@ L'interface web permet à l'utilisateur de _dessiner_ son workflow : un certain
 
 \cimg{figs/inari-frontend-ui.png}{scale=.35}{Interface web Inari}{Source : créé par Théo PIRKL}
 
-Comme la figure 2.3 le montre, l'interface est composée de la façon suivante : à droite, l'interface permet de _dessiner_ son workflow en ajoutant des modules et en les interconnectant. Les boutons en bas à droite permettent la construction, la sauvegarde du workflow et l'ajout d'un module. Le menu à gauche permet de naviguer entre les différentes ressources accessibles à l'utilisateur, comme les workflows, les modules, les clients et les clicks. Chaque client Inari propose de télécharger l'intégralité des documents récupérés jusqu'ici. En outre, il est possible à l'utilisateur de gérer ses _clicks_. Les clicks représentent une ressource permettant à l'utilisateur de décrire à Inari ce qu'il faut sélectionner sur un site web en particulier. Ces clicks sont représentés sous la forme d'une formule XPath, l'équivalent d'un langage de programmation permettant de désigner un ou plusieurs éléments sur une page XML comme du HTML. La figure 2.4 donne un exemple de clicks insérés dans l'application.
+Comme la figure 2.3 le montre, l'interface est composée de la façon suivante : à droite, l'interface permet de _dessiner_ son workflow en ajoutant des modules (les boîtes) et en les interconnectant (les flèches). Les boutons en bas à droite permettent la construction, la sauvegarde du workflow et l'ajout d'un module. Le menu à gauche permet de naviguer entre les différentes ressources accessibles à l'utilisateur, comme les workflows, les modules, les clients et les clicks. Chaque client Inari propose de télécharger l'intégralité des documents récupérés jusqu'ici. En outre, il est possible à l'utilisateur de gérer ses _clicks_. Les clicks représentent une ressource permettant à l'utilisateur de décrire à Inari ce qu'il faut sélectionner sur un site web en particulier. Ces clicks sont représentés sous la forme d'une formule XPath, l'équivalent d'un langage de programmation permettant de désigner un ou plusieurs éléments sur une page structurée comme du (+HTML_a). La figure 2.4 donne un exemple de clicks insérés dans l'application.
 
 \cimg{figs/inari-frontend-xpath.png}{scale=.32}{Exemple de clicks}{Source : créé par Théo PIRKL}
 
@@ -92,15 +92,15 @@ Programmer une XPath n'est pas un prérequis prévu par le cahier des charges. I
 
 Un utilisateur se servirait de l'interface de la façon suivante : après s'être inscrit et s'être connecté, il aurait la possibilité de créer un workflow. Là, il pourra ajouter des modules, et les connecter entre eux. Une fois son workflow terminé, il aura la possibilité de le sauvegarder et de le générer. L'action de générer un workflow convertit le workflow du format visuel au format d'exécution. Ces deux formats sont discutés plus en détail dans la section _fonctionnement du workflow_.
 
-Une fois son workflow généré, l'utilisateur a la possibilité de contrôler l'avancement en demandant, via la page _clients_, l'avancement de la récupération.
+Une fois son workflow généré, l'utilisateur a la possibilité de contrôler via la page _clients_ l'avancement de la récupération.
 
 ### Robustesse
 
 Inari a été conçu de façon à pouvoir résister aux erreurs le mieux possible. La majorité des composants sont dépendants les uns des autres au moment où ils discutent entre eux, mais pas avant ou après la discussion.
 Par exemple, le contrôleur Inari n'est pas essentiel au fonctionnement de l'application une fois que ce dernier a transmis aux clients Inari leurs tâches respectives. Un client Inari peut subir une panne : le contrôleur est en mesure de renvoyer les tâches d'un client Inari pour reprendre là où le client en était.
-Enfin, l'interface de contrôle web est complètement détachée du reste du projet : même si elle tombe en panne, aucun composant ne sera impacté.
+Enfin, l'interface de contrôle web est complètement détachée du reste du projet : même si elle tombe en panne, aucun autre composant ne sera impacté.
 L'exécution des tâches est elle aussi prévue pour résister aux pannes : chaque client Inari signale chaque tâche comme terminée ou en échec. Si trop d'échecs surviennent sur un client, le contrôleur Inari ordonne automatiquement son arrêt temporaire. L'arrêt se caractérise comme une pause de cinq minutes, le temps au client Inari de terminer les tâches en cours. Cette pause de cinq minutes est particulièrement utile lors du ralentissement d'un site web : si le site sur lequel Inari tente de récupérer des documents commence à ralentir, cela s'observe sous forme d'une vague d'erreurs au niveau des tâches. Le contrôleur bloque alors les clients Inari, le temps que le site web retrouve ses performances.
-Enfin, le parallélisme des tâches amène lui aussi une robustesse : chaque exécution de workflow est isolée des autres, ce qui permet d'éviter des effets de bords. Si un workflow devait s'arrêter en cours de route, il serait signalé au contrôleur, renvoyé au client et réexécuté dès qu'un des coeurs est disponible.
+Enfin, le parallélisme des tâches amène lui aussi une robustesse : chaque exécution de workflow est isolée des autres, ce qui permet d'éviter des effets de bords. Si un workflow devait s'arrêter en cours de route, il serait signalé au contrôleur, renvoyé au client et réexécuté dès que possible.
 
 ### Fonctionnement du workflow
 
@@ -108,7 +108,7 @@ Le workflow se présente à l'utilisateur sous la forme d'un graphe unidirection
 
 \cimg{figs/inari-example-workflow.png}{scale=.28}{Exemple de workflow}{Source : créé par Théo PIRKL}
 
-Une fois le graphe dessiné, il est nécessaire au système de convertir le format permettant de dessiner et d'afficher le workflow à un format permettant de l'exécuter. Ce dernier n'est pas du code, car Inari ne possède pas de moteur syntaxique lui permettant d'autogénérer du code. A la place, un fichier contenant les modules à exécuter avec leurs arguments est généré. De cette façon, il suffit au client de démarrer le module indiqué par le fichier généré et d'indiquer les arguments nécessaires au fonctionnement du workflow.
+Une fois le graphe dessiné, il est nécessaire au système de convertir le format permettant de dessiner et d'afficher le workflow vers un format permettant de l'exécuter. Ce dernier n'est pas du code, car Inari ne possède pas de moteur syntaxique lui permettant d'autogénérer du code. A la place, un fichier contenant les modules à exécuter avec leurs arguments est généré. De cette façon, il suffit au client de démarrer le module indiqué par le fichier généré et d'indiquer les arguments nécessaires au fonctionnement du workflow.
 
 \begin{figure}[t!]
     \begin{subfigure}{.48\linewidth}
diff --git a/rapport/text/5-mesures.md b/rapport/text/5-mesures.md
index ead6cb790f792beb6d26f4b10e3d84d11d040d3f..47237842ad799e112cf8f8b5df0a5ea7799a7973 100644
--- a/rapport/text/5-mesures.md
+++ b/rapport/text/5-mesures.md
@@ -36,7 +36,7 @@ Chaque expérience a été effectuée trois fois. L'objectif d'augmenter le nomb
 \begin{samepage}
 
 Chaque expérience avait le même objectif : télécharger les 1000 mêmes documents du site. Ces dernières correspondent donc à une exécution complète du logiciel et chacune d'entre elles est indépendante des autres. Les clients Inari ont été redémarrés après chaque expérience pour garantir une fiabilité maximale des résultats.
-Puisqu'il y a six expériences, six graphiques sont présentés. Chaque graphique comporte trois lignes, pour les trois mesures de chaque expérience. On télécharge $1000$ documents, répartis dix par dix sur des pages; on télécharge donc 100 pages. L'ordonnée des mesures ira donc de 0 à 100 pages téléchargées.
+Puisqu'il y a six expériences, six graphiques sont présentés. Chaque graphique comporte trois lignes, pour les trois mesures de chaque expérience. On télécharge $1000$ documents, répartis dix par dix sur des pages; on télécharge donc 100 pages. L'ordonnée des mesures ira donc de zéro à 100 pages téléchargées.
 Le terme \textit{document} sera privilégié à celui de \textit{page}. On préfèrera le terme \textit{expérience} à celui de graphique : la figure 3.1 contient les six graphiques de chaque expérience. Une lettre est indiquée en légende sous chaque graphique et elle indique la lettre de l'expérience.
 
 \begin{figure}[t!]
@@ -111,7 +111,7 @@ Il est toutefois difficile de tirer de vraies conclusions de ce graphique : en e
 
 Deux questions ont été posées dans l'introduction de ce chapitre. La première question était de déterminer si l'automatisation de la récupération des documents était plus rapide que le téléchargement des documents un par un. Au vu des mesures, on peut conclure que oui. Dans le pire des cas, c'est-à-dire les cas les plus lents, Inari est capable d'effectuer les actions trois fois plus vite qu'un être humain.
 
-La seconde question, quant à elle, concernait la distribution des tâches de téléchargement : est-ce que cela accélère le traitement des tâches ? Il est difficile de répondre catégoriquement sur la base des résultats obtenus. Il faut trouver les réglages idéaux afin de pouvoir véritablement accélérer le traitement des documents. Dans l'ensemble des mesures prises, les paramètres donnant les pires taux de performances restent bien plus rapides qu'un être humain. Toutefois, on peut passer d'un taux de performance de $200\%$ à $1614\%$ en optimisant les réglages. C'est donc un processus pouvant se montrer indispensable. A noter que la variation du taux de performance est quelque chose qui est non maitrisable, puisqu'il dépend principalement du serveur sur lequel les documents sont téléchargés.
+La seconde question, quant à elle, concernait la distribution des tâches de téléchargement : est-ce que cela accélère le traitement des tâches ? Il est difficile de répondre catégoriquement sur la base des résultats obtenus. Il faut trouver les réglages idéaux afin de pouvoir véritablement accélérer le traitement des documents. Dans l'ensemble des mesures prises, les paramètres donnant les pires taux de performances restent bien plus rapides qu'un être humain. Toutefois, on peut passer d'un taux de performance de $200\%$ à $1614\%$ en optimisant les réglages. C'est donc un processus pouvant se montrer indispensable. A noter que la variation du taux de performance est quelque chose qui est non maîtrisable, puisqu'il dépend principalement du serveur sur lequel les documents sont téléchargés.
 
 ## Swiss-Impex
 
@@ -186,9 +186,9 @@ La prochaine mesure étant plus longue, l'analyse des imports-exports de matièr
 #### Analyse des imports-exports de matières pétrolières, des armes et des masques en tissu
 
 On obtient ici un graphique. Chaque ligne représente le nombre de documents téléchargés en fonction du temps.
-\cimg{figs/measures/swiss-impex/special.pdf}{scale=.75}{Graphique du téléchargement de Swiss-Impex en configuration multicatégorie}{Graphique fabriqué par Théo Pirkl}
+\cimg{figs/measures/swiss-impex/special.pdf}{scale=.75}{Graphique du téléchargement de Swiss-Impex en configuration multicatégorie}{Source: créé par Théo Pirkl}
 
-Pour commencer, il est intéressant de voir que le logiciel, même sur plusieurs milliers de documents, conserve une vitesse de téléchargement relativement constante, ce qu'on peut observer grâce à la quasi-droite qu'affiche le graphique. On peut apercevoir sur la mesure 2 un ralentissement prononcé de la vitesse de téléchargement, qui peut être expliquée par une lenteur du service ou une lenteur des postes téléchargeant les documents.
+Pour commencer, il est intéressant de voir que le logiciel, même sur plusieurs milliers de documents, conserve une vitesse de téléchargement relativement constante, ce qu'on peut observer grâce à la quasi-droite qu'affiche le graphique. On peut apercevoir sur la mesure deux un ralentissement prononcé de la vitesse de téléchargement, qui peut être expliquée par une lenteur du service ou une lenteur des postes téléchargeant les documents.
 
 Il faut, selon les mesures effectuées, $9800$ secondes pour télécharger $4092$ documents, soit 0.41 documents par seconde, ou 0.002 documents par seconde par coeur. On peut calculer un gain de performance de $1.25$ fois la vitesse d'un être humain, soit un pourcentage de gain absolu de $25\%$. Pour comparer ces mesures à celles de téléchargements plus courts, on remarque que le gain de performance sur des quantités de documents plus grandes semblent influencer le gain de performance final : dans le cas de quantités plus petites, le gain de performance était de $2.25$ la vitesse d'un être humain. Il est toutefois impossible d'affirmer qu'il existe une corrélation entre la quantité de documents à télécharger et le gain de performance : de nombreux facteurs externes tels que la vitesse du réseau, l'état du service et l'état des machines effectuant le téléchargement viennent influencer la mesure de façon quasi aléatoire.
 
diff --git a/rapport/text/ZZ-glossaire.tex b/rapport/text/ZZ-glossaire.tex
index 5b38fe359277da50df821533b6b036d76570b2b7..396d906af0b9fb202e39fea48455d441255dd54e 100644
--- a/rapport/text/ZZ-glossaire.tex
+++ b/rapport/text/ZZ-glossaire.tex
@@ -13,3 +13,4 @@
 \newacronym{IP_a}{IP}{Internet Protocol}
 \newacronym{FQDN_a}{FQDN}{Fully Qualified Domain Name}
 \newacronym{CSV_a}{CSV}{Comma Separated Value}
+\newacronym{HTML_a}{HTML}{Hyper Text Markup Language}