FILM RÉSEAU Une journée de voyage avec HTTP / HTTPS (le vrai “sous le capot”)

 FILM RÉSEAU — Une journée de voyage avec HTTP / HTTPS (le vrai “sous le capot”)

On a déjà fait le film du DNS, le voyage de TCP et de IP… aujourd’hui on monte d’un étage : HTTP / HTTPS.
Et comme d’habitude sur Aide en Informatique, on repart de zéro, terre-à-terre, avec une analogie simple.

---

1) HTTP, c’est quoi exactement ?

HTTP = HyperText Transfer Protocol
En clair : c’est le langage de conversation entre ton navigateur (Chrome, Firefox…) et un serveur web.

 Analogie :

IP/TCP = la route + le camion + la livraison fiable

HTTP = la feuille de commande et la réponse du magasin

HTTP ne “transporte” pas physiquement les données : il décrit quoi demander et comment répondre.

---

2) Le film : “Je tape wwwsitecom et j’appuie Entrée”

 Scène A — Le navigateur prépare le voyage

1. Tu tapes une URL

2. Le navigateur découpe :

le nom de domaine (site[point]com)

le chemin (/produits)

les paramètres (?page=2)

3. Il doit trouver l’adresse du serveur → DNS (on a déjà fait le film )

---

 Scène B — Connexion : TCP d’abord (la poignée de main)

Avant de parler HTTP, il faut une connexion fiable : TCP.

 Analogie :
Avant de passer une commande au téléphone, tu vérifies que la ligne marche.

➡️ Le PC fait le 3-way handshake TCP (SYN / SYN-ACK / ACK) avec le serveur, en général sur :

port 80 pour HTTP

port 443 pour HTTPS

---

3) Le cœur du film : Request / Response (commande / facture)

✅ 3.1 La requête HTTP (Request)

C’est le navigateur qui envoie une “commande”.

Exemple (simplifié) :

Méthode : GET (je veux lire)

Chemin : / ou /login ou /api/users

Headers : des infos “papier” attachées à la commande

Body : données (souvent pour POST)

 Analogie :
Tu arrives au guichet et tu dis :
“Bonjour, je veux le produit X, je parle français, voici mon numéro de client, et j’accepte ces formats.”

Les méthodes HTTP (super importantes)

GET : lire une page ou une ressource

POST : envoyer des données (formulaire, login)

PUT/PATCH : modifier

DELETE : supprimer

OPTIONS : “tu acceptes quoi ?” (souvent CORS / API)

---

✅ 3.2 La réponse HTTP (Response)

Le serveur répond toujours avec :

un status code

des headers

un body (HTML, JSON, image…)

Les codes qui reviennent tout le temps

200 OK : tout va bien

301/302 : redirection (ex: http → https)

401 : pas authentifié

403 : interdit

404 : introuvable

500 : erreur serveur

503 : serveur surchargé / maintenance

 Analogie :
Tu commandes → on te répond :
“OK voilà”, ou “on n’a pas”, ou “revient plus tard”, ou “problème en cuisine”.

---

4) Les headers : les “étiquettes” du colis

Les headers, c’est ce qui permet au web d’être “intelligent”.

Exemples utiles :

Host : le site demandé (important quand plusieurs sites sont sur le même serveur)

User-Agent : info navigateur

Accept / Content-Type : format attendu / format envoyé

Authorization : token (API)

Cookie : session / login

Cache-Control : mise en cache

Content-Length : taille

 Analogie :
Sans étiquette, le livreur livre “un colis” sans savoir à qui, ni comment le manipuler.

---

5) Cookies & Sessions : “comment le serveur sait que c’est toi ?”

HTTP est stateless : chaque requête est indépendante.
Donc pour se souvenir de toi, on utilise :

Cookie de session (le plus classique)

ou Token (JWT / OAuth)

 Analogie :
Tu entres dans un festival : on te met un bracelet.
Sans bracelet, tu dois prouver ton identité à chaque stand.

---

6) Pourquoi HTTP est devenu HTTPS ?

Le problème d’HTTP (sans S)

HTTP = tout en clair.
Si quelqu’un est sur le même réseau (wifi public, routeur compromis, proxy malveillant), il peut :

lire ce que tu envoies

lire ce que tu reçois

modifier au passage (injection)

 Analogie : HTTP = carte postale
Tout le monde peut lire pendant le trajet.

---

HTTPS = HTTP + TLS (le tunnel chiffré)

Le “S” veut dire : Secure, via TLS (anciennement SSL).

 Analogie : HTTPS = lettre dans une enveloppe scellée + signature du magasin.

---

7) Le cadenas : certificat, clé publique… expliqué simplement

7.1 Le certificat, c’est quoi ?

Un certificat c’est comme une carte d’identité officielle du site.

Il contient :

le nom du site (domaine)

la clé publique du serveur

une signature d’une autorité de confiance (CA)

 Analogie : Tu ne fais pas confiance à “n’importe quel vendeur”.
Tu fais confiance parce qu’il a une carte d’identité validée par la mairie (la CA).

---

7.2 Clé publique / clé privée : version ultra simple

Clé publique : tu peux la donner à tout le monde

Clé privée : tu la gardes secrète, elle prouve que tu es bien toi

 Analogie :

Clé publique = adresse de ta boîte aux lettres

Clé privée = la clé qui ouvre la boîte

---

8) Le film HTTPS : que se passe-t-il VRAIMENT ?

 Scène 1 — Bonjour, qui es-tu ?

Ton navigateur se connecte au serveur (port 443) et dit :
“Je veux chiffrer, voilà les options que je supporte.”

 Scène 2 — Le serveur montre sa carte d’identité

Le serveur envoie son certificat (avec sa clé publique).

 Scène 3 — Le navigateur vérifie

Le navigateur vérifie :

est-ce signé par une CA reconnue ?

le nom de domaine correspond ?

certificat expiré ?

Si ça échoue → alerte (cadenas barré, warning)

 Scène 4 — Création d’une clé de session

Le navigateur et le serveur se mettent d’accord sur une clé de session (temporaire).
Ensuite, ils chiffrent tout avec cette clé (chiffrement symétrique, rapide).

 Analogie : Ils se mettent d’accord sur un code secret de la journée, puis ils parlent toute la journée avec.

---

9) Est-ce qu’un attaquant peut décrypter du HTTPS ?

 En général : NON, s’il ne possède pas la clé de session / clé privée.

Mais il y a des cas où il peut voir ou récupérer des choses :

✅ Ce qu’il peut voir même en HTTPS :

l’adresse IP du serveur

le domaine (souvent via SNI / DNS si pas chiffré)

la quantité de données, timing (métadonnées)

⚠️ Quand ça devient possible de “casser” la confidentialité :

si ton appareil est compromis (malware) → il lit avant chiffrement

si tu acceptes un faux certificat (attaque MITM + utilisateur naïf)

si une entreprise installe un proxy TLS (certificat installé sur le PC)

si le serveur est mal configuré ou vieux protocole

 Analogie : Même si la lettre est scellée, si quelqu’un vole ton téléphone et lit le message avant que tu le mettes dans l’enveloppe… c’est fini.

---

10) Pourquoi Chrome “force” le HTTPS ?

Parce que le web moderne veut :

empêcher l’espionnage

empêcher la modification en route

protéger les identifiants/cookies

protéger les transactions

Et surtout : un site en HTTP peut être “injecté” (pubs, scripts, redirections) sans que tu le voies.

---

Conclusion terre-à-terre

 HTTP = la conversation “commande ↔ réponse” du web
 HTTPS = la même conversation, mais dans un tunnel chiffré + identité vérifiée
Le cadenas ne veut pas dire “site honnête”, il veut dire :
✅ “la connexion est chiffrée et tu parles au bon serveur”.

---

 Si tu veux, dis-nous en commentaire : tu veux qu’on fasse le film “API REST en HTTP” (GET/POST/JWT/CORS) ou le film WebSocket ?

 Rejoins nos canaux pour être alerté de tous nos posts et contenus (posts, infographies, livres, labs, cas pratiques) — tous les liens utiles sont en commentaire.

‐--------