diff --git a/Documentation/Documentation.md b/Documentation/Documentation.md
index 9546697d8ee0aeac84e99968c7a06a4d48e3d51c..583eda73e70af5d43acbc149a6d3101cdf3b4e94 100644
--- a/Documentation/Documentation.md
+++ b/Documentation/Documentation.md
@@ -61,7 +61,7 @@ Pour gérer les appels à la base de données, nous avons créé une API posséd
 
 `User - /API/v1/user`<br>
 Cette route gère le CRUD des utilisateurs avec respectivement les méthodes post, get, patch et delete (pour les deux dernières, on rajoute l'ID à la route ainsi `/API/v1/user/:id`) 
-Lorsqu'on s'y connecte, l'API vérifie si l'utilisateur est admin et, dans le post et le patch, elle vérifie également les identifiant.
+Lorsqu'on s'y connexe, l'API vérifie si l'utilisateur est admin et, dans le post et le patch, elle vérifie également les identifiant.
 
 `Question - /API/v1/question`<br>
 De façon similaire à user, le CRUD est géré avec les mêmes méthodes post, get, patch et delete. Par contre, à la différence des utilisateurs, il y a deux get. L'un, de base, retournant toutes les questions et un deuxième auquel on ajoute un ID qui ne retournera que la question souhaitée.
@@ -140,14 +140,146 @@ modales de création et mise à jour d'utilisateurs. Celle de création est uniq
 
 Pour permettre un affichage toujours à jour sans avoir à rafraîchir la page entière, nous utilisons les "Behaviors Subjects". Ils sont utilisables en tant qu'observable, afin de permettre le rafraîchissement du composant parent lors d'un changement de valeurs.
 
-Les modales sont in fine de simples ```<div>``` avec un z-index élevé.
+Les modales sont in fine de simples ```<div>``` avec un z-index élevé. Cela simplifie largement le code pour un résultat très satisfaisant.
+
+Le code HTML des modales a été inspiré d'un code trouvé en ligne. Malheureusement, au moment où l'on écrit ce rapport, on ne retrouve plus l'adresse du site WEB hôtant ce code.
+
+Les services sont très utiles pour du code qui n'est pas directement lié avec de l'affichage de composent. Ils agissent comme des singletons. Plutôt qu'avoir toute cette logique dans nos composants, on a décidé de les mettres à part dans des services.
 
 #### Problèmes rencontrés
 
-En raison d'un manque de temps, nous n'avons pas implémenté de système de vérification des codes HTTP. Par exemple, si un utilisateur qui cherche à se connecter se trompe de mot de passe, au lieu d'avoir l'information qu'il a rentré de mauvaises informations, il se fait rediriger vers la page principale, sans être connecté.
+En raison d'un manque de temps, nous n'avons pas implémenté de système de vérification des codes HTTP. Par exemple, si un utilisateur qui cherche à se connexer se trompe de mot de passe, au lieu d'avoir l'information qu'il a rentré de mauvaises informations, il se fait rediriger vers la page principale, sans être connexé.
 C'est selon nous un aspect secondaire du projet, et nous avons préféré nous concentrer sur les aspects primaires.
 
 
 ### Sockets IO
 
-Il y a un bug dans notre site que nous n'avons pas réussi à régler, même avec de l'aide. À la fin d'une partie, le tableau des scores s'affiche correctement et est détruit si l'on quitte la page. Cependant, si l'admin revient, l'affichage affichera toujours le dit tableau. 
\ No newline at end of file
+Les sockets servent à ouvrire une connexion entre un système backend et un système frontend. Nous allons donc découper la documentation en deux.
+
+#### Backend
+
+Le backend Socket Server s'occupe de recevoir les communications des divers clients, et de gérer la logique du jeu.
+
+Il y a deux phases :
+
+1. En attente
+    - Des utilisateurs peuvent s'insrire pour une partie
+    - À chaque communication, on envoie le nombre d'utilisateurs présents dans une partie
+    - Les utilisateurs peuvent se désinscrire de la partie
+    - Sur la déconnexion, si l'utilisateur était inscrit, on le désinscrit
+    - Lorse que trois utilisateurs sont connexés, on lance la partie
+        - On récupère dix questions aléatoires
+        - On informe les joueurs du début de la partie
+2. En jeu
+    - Envoyer une question
+    - Récupérer la réponse d'un utilisateur
+    - Envoyer les points des utilisateurs
+    - Répéter jusqu'à plus de question disponible
+    - Envoyer le total des points
+
+Pour cela, la librairie Socket.io nous offre une classe Io.Server
+```ts
+this.on('connection'); // Nous permet d'écouter et d'agir sur une connexion
+this.broadcast.emit(); // Nous permet d'envoyer un messages à tous les sockets connectés
+```
+
+Sur l'écoute de connexion, nous pouvons également récupérer le socket émitteur, ce qui nous permet d'agir en fonction d'un socket en particulier. On peut y enregistrer des écoutes d'évènements, ce qui nous permet d'y créer toute la logique pour la partie de jeu.
+
+#### Frontend 
+
+Ici, nous avons décidé d'utiliser un module Node nommé `ngx-socket-io` qui est techniquement un wrapper autour de `socket.io` créé pour Angular.
+
+**Instanciation**
+
+Il est instancié dans `app.module.ts` comme suit :
+On crée une config de socket
+```ts
+const config: SocketIoConfig = { url: 'http://0.0.0.0:30992', options: { autoConnect: false } };
+```
+autoConnect est à `false` pour faire en sorte de connecter la socket que lorse qu'on affiche les salles de jeu à l'écran.
+
+Ensuite dans les imports, on ajoute :
+
+```ts
+SocketIoModule.forRoot(config)
+```
+
+**Usage**
+
+Maintenant, nous pouvons simplement récupérer dans un constructeur 
+```ts
+constructor(
+    private socket: Socket
+)
+```
+
+**Service**
+
+Tous les aspects liés au Socket sont condensés dans un service ici humblement nommé `socketService`.
+
+Ce service offre les méthodes suivantes :
+
+```ts
+get playerNumber()
+get gameStart()
+get questionID()
+get answers()
+get points()
+get scoreboard()
+joinRoom()
+leaveRoom()
+connectSocket()
+disconnectSocket()
+sendAnswer(answer: Answer)
+sendMessage(text: string)
+```
+
+Tous les get ici retourne des Observables, pour les mêmes raisons qu'énoncées au chapitre précédent.
+
+Les autres méthodes vont communiquer avec le back directement.
+
+A la construction du service, on lui passe en paramètre du socket le token JWT de l'utilisateur et on enregistre tous les évènements d'écoutes sur le socket.
+
+**Usage du service**
+Dans le constructeur des composants concernés, on peut y ajouter le service.
+```ts
+private socket: SocketService
+```
+Cela lui donne accès à toutes les méthodes décrites plus haut.
+
+
+**gameroom**
+La gameroom a quatre états distincts :
+1. Salle non-rejointe
+    - On peut voir le nombre de joueurs dans la salle
+    - On peut y rentrer
+2. Salle rejointe
+    - On peut attendre que suffisamment de joueurs se connectent
+    - On peut discuter avec les joueurs actuellement dans la salle
+    - On peut quitter la salle
+3. Partie en cours
+    - On affiche la question et les réponses reçues
+    - On peut sélectionner une réponse
+    - On peut toujours discuter avec les autre joueurs
+4. Partie terminée
+    - On affiche le tableau des scores
+    - On peut quitter la salle
+
+**chat**
+Un aspect supplémentaire qui n'était pas demandé dans l'énoncé du travail a été ajouté : On peut Chatter !
+Lorse qu'on est dans la salle, une fenêtre de chat s'ouvre, et on y voit les messages envoyés avec les pseudos des joueurs.
+Son fonctionnement est très simple :
+
+1. Le client emit le message vers le backend
+2. Le backend broadcast le message vers tous les clients
+3. Tous les client affichent le message
+
+#### Aspects importants
+
+Dans le composant `gameroom`, on affiche à la fin d'une partie les résultats. Ces résultats sont dans un dictionnaire ayant pour clé, le pseudo du joueur, et en valeur son nombre de points. La manière d'afficher un dictionnaire à l'aide d'un *ngFor a été tirée d'une question [StackOverflow](https://stackoverflow.com/questions/66338094/how-do-i-make-ngfor-for-dictionary-in-angular).
+
+#### Problèmes rencontrés
+
+Il y a un bug dans notre site que nous n'avons pas réussi à régler, même avec de l'aide. À la fin d'une partie, le tableau des scores s'affiche correctement et est détruit si l'on quitte la page. Cependant, si l'admin revient, l'affichage affichera toujours le dit tableau.
+
+Pour le chat, on a essayé de donner une couleur différente pour chaque pseudo. Ça s'est malheureusement avéré être un des problèmes les plus difficiles que l'on ait pu voir à l'HEPIA, et nous avons été forcés d'abandonner.
\ No newline at end of file