diff --git a/Readme.md b/Readme.md
index c56e819..b1607c7 100644
--- a/Readme.md
+++ b/Readme.md
@@ -11,3 +11,4 @@ include_toc: true
 
 - [JavaScript](./Web/X%20-%20JavaScript/index.md)
 - [API JS-DOM](./Web/X%20-%20API%20JS-DOM/index.md)
+- [Communications Client-Serveur](./Web/X%20-%20Communications%20Client-Serveur/index.md)
diff --git a/Web/X - Communications Client-Serveur/HTTP queries.dia b/Web/X - Communications Client-Serveur/HTTP queries.dia
new file mode 100644
index 0000000..cb2dd3d
Binary files /dev/null and b/Web/X - Communications Client-Serveur/HTTP queries.dia differ
diff --git a/Web/X - Communications Client-Serveur/HTTP queries.png b/Web/X - Communications Client-Serveur/HTTP queries.png
new file mode 100644
index 0000000..28aed6f
Binary files /dev/null and b/Web/X - Communications Client-Serveur/HTTP queries.png differ
diff --git a/Web/X - Communications Client-Serveur/index.md b/Web/X - Communications Client-Serveur/index.md
new file mode 100644
index 0000000..46abfca
--- /dev/null
+++ b/Web/X - Communications Client-Serveur/index.md	
@@ -0,0 +1,163 @@
+---
+gitea: none
+
+include_toc: true
+
+---
+
+[TOC]
+
+
+
+# Architecture client/serveur
+
+
+
+Un site Web est généralement constitué d'au moins 2 parties :
+
+- *le côté client* : qui est l'ensemble des fichiers (HTML/CSS/JS/WASM) interprétés par le navigateur et exécuté sur le poste de travail de l'utilisateur.
+
+- *le côté serveur* : qui va s'exécuter sur le serveur et qui répondra aux requêtes du navigateur. C'est lui qui va, entre autres, donner au navigateur les fichiers HTML/CSS/JS/WASM nécessaires à l'affichage du site.
+
+
+
+La communication entre le client et le serveur se fait généralement via le protocole HTTP(S). Le client envoie une requête HTTP au serveur qui retourne une réponse HTTP.
+
+<img src="file:///home/demigda/Data/Recherche/Git/Notes-de-Cours/Web/X%20-%20Communications%20Client-Serveur/HTTP%20queries.png" title="" alt="" data-align="center">
+
+L'affichage d'une page Web se déroule usuellement de la sorte :
+
+```html
+<!DOCTYPE>
+<html>
+    <head>
+        <script src='...' defer></script>
+        <link rel='stylesheet' href='...'></link>
+    </head>
+    <body>
+    
+    </body>
+</html>
+```
+
+1. Le navigateur demande au serveur le fichier HTML correspondant à la page Web à afficher.
+
+2. Le navigateur commence à lire et à interpréter le fichier HTML reçu.
+
+3. Le navigateur lit la balise `<script>` et commence à télécharger le fichier correspondant. Comme la balise a l'attribut `defer`, le navigateur continue de lire et interpréter le fichier HTML.
+
+4. Le navigateur lit la balise `<link>` et commence à télécharger le fichier CSS correspondant.
+
+5. Le navigateur commence à construire l'arbre DOM à partir du contenu de `<body>`.
+
+6. Une fois l'arbre DOM construit, il execute le script qui était `defer`.
+
+7. Une fois l'exécution du script fini, le navigateur dessine la page Web pour la première fois.
+
+
+
+## Optimisations
+
+L'un des objectifs des développeur Web est de dessiner la page Web le plus tôt possible. Pour cela, il va user de diverses techniques :
+
+- *Compresser les fichiers* avant de les transmettre, réduisant le temps de téléchargement des ressources nécessaires.
+
+- *Réduire la taille des fichiers* en
+  
+  - supprimant le code inutilisé
+  
+  - le minimifiant (supprime les espaces et retours à la ligne)
+  
+  - en l'uglifiant (réduit la taille du code au prix de sa lisibilité, e.g. en renommant les variables).
+  
+  - pour les images, en réduisant sa résolution/qualité, ou en utilisant des formats vectoriels (SVG).
+  
+  - pour les images, afficher un *placeholder* ou version en basse résolution puis progressivement [la remplacer une version de plus haute résolution](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Tutorials/js13kGames/Loading#images).
+
+- *Télécharger ou exécuter plus tard* les ressources non-nécessaires à l'affichage, via :
+  
+  - du *lazy load*, e.g. ne télécharger les images que lorsqu'elles apparaissent à l'écran.
+  
+  - de la *pagination*, e.g. sur un tableau ne télécharger/afficher que les X premières entrées et proposer des boutons pour afficher les entrées suivantes.
+  
+  - en reportant l'execution de certains bouts de codes à plus tard.
+
+- *Réduire le nombre de fichiers téléchargés* (on vise généralement 3-4 fichiers par page) :
+  
+  - remplacer l'URL d'une image par [une chaîne de charactère en base64](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs).
+  
+  - fusionner les fichiers CSS en un seul.
+  
+  - fusionner les fichiers JS en un seul.
+  
+  - intégrer certaines ressources (e.g. JSON) dans le fichier JS.
+  
+  - intégrer le JS et/ou le CSS dans le fichier HTML.
+
+- *Utiliser des caches* pour éviter de re-télécharger à chaque fois certaines ressources :
+  
+  - un cache basé le protocole HTTP (cf [Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching)).
+  
+  - un cache local basé sur `localStorage`, `sessionStorage`, ou `indexDB`.
+  
+  - un cache côté serveur en enregistrant des données dans la RAM afin de pouvoir répondre plus rapidement aux requêtes qui s'il fallait aller les lire directement sur le disque.
+
+- *Pré-télécharger les ressources*, en commençant à les télécharger le plus tôt possible :
+  
+  - dans les balises `<script>`, l'attribut `defer`.
+  
+  - pour d'autres ressources utilisées plus tard, cf [<link rel=preload href='...' as='...'/>](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/preload).
+
+- Pour les site Web massivement visités :
+  
+  - *distribuer la charge* (load balancing) entre plusieurs serveurs (⚠ engendre des problématiques de synchronisations).
+  
+  - *rapprocher le serveur du client*, *edge computing* (contenu dynamique), *content delivery network* (contenu statique).
+  
+  - découper son site Web en plusieurs modules/services indépendants hébergés sur plusieurs serveurs (⚠ si les services doivent fréquemment communiquer entre eux cela peut s'avérer contre-productif).
+
+
+
+⚠ L'optimisation prématurée est diabolique. Vous n'avez, à votre niveau, pas besoin d'optimiser vos sites Web. Vous n'avez pas non plus à implémenter vous-mêmes ces optimisations, de nombreux outils le font déjà pour vous (e.g. Webpack).
+
+
+
+🚩 [TODO] : outils navigateur pour network / load performances (lighthouse)
+
+🚩 [TODO] : archi projet dev vs prod.
+
+
+
+# Le serveur Web
+
+Nginx/Apache2/Live Server vs Deno => pourquoi séparer (statique vs dynamique ! CORS !) ?
+
+
+
+Command line
+
+BDD API/FileAPI
+
+! Jamais faire confiance client
+
+## Serveur REST
+
+=> Principe
+
+=> Utilité
+
+=> Différent type de requêtes
+
+
+
+=> Routes
+
+    => Serveur Python/JS/TS
+
+
+
+## Websocket
+
+
+
+## Server event
