cours1 min de lecture

Client, serveur et HTTP

Comment une page Web dialogue avec un serveur — requêtes HTTP, méthodes, codes de statut, et frontière client/serveur.

programme

Introduction

Vous savez désormais structurer une page (HTML, CSS), réagir aux gestes de l'utilisateur (événements), et la transformer en direct (DOM). Reste la pièce manquante : comment cette page dialogue-t-elle avec le reste du monde, et notamment avec le serveur qui l'héberge ? La réponse tient en quatre lettres : HTTP, HyperText Transfer Protocol. Ce cours formalise la distinction client / serveur et décrit le cycle requête → réponse qui fonde tout le Web.

Voir .

La frontière client / serveur

Quand vous visitez nsi.rocks :

Votre navigateur (Firefox, Chrome…) est le client. Il tourne sur votre machine. Il exécute le HTML, le CSS et le JavaScript reçus.
Le serveur est une machine distante qui détient les fichiers du site et les envoie sur demande. Il exécute son propre code (Python, PHP, Node, Go… peu importe).

[Votre ordinateur]                  [Quelque part dans le monde]
+-----------------+                 +-------------------+
|   Navigateur    |  ←── HTTP ──→  |  Serveur Web      |
|  (HTML/CSS/JS)  |                 |  (code + données) |
+-----------------+                 +-------------------+
       Client                              Serveur

Cette frontière est fondamentale. Tout ce que vous voyez à l'écran s'exécute chez vous. Tout ce qui touche aux données partagées (utilisateurs, articles, commandes…) s'exécute côté serveur.

Un même langage peut tourner des deux côtés. JavaScript existe côté client (dans le navigateur) et côté serveur (via Node.js). Mais le rôle fonctionnel — afficher pour le client, gérer les données pour le serveur — reste distinct.

Qui fait quoi ?

Tâche	Où ?	Pourquoi
Afficher la page	Client	Le rendu visuel se fait chez l'utilisateur.
Valider visuellement un formulaire	Client	Réactivité immédiate, pas d'attente réseau.
Réagir au clic, au clavier	Client	Les événements ont lieu chez l'utilisateur.
Re-valider les données reçues	Serveur	Le client peut être hostile, le serveur fait foi.
Stocker les utilisateurs, les articles	Serveur	Les données sont partagées entre tous les visiteurs.
Vérifier un mot de passe	Serveur	Le client ne doit pas voir les mots de passe stockés.
Calculer un prix avec une promotion réelle	Serveur	Sinon n'importe qui modifie le prix dans son navigateur.
Envoyer un e-mail	Serveur	Le client n'a pas accès au système d'envoi.

Règle d'or : tout ce qui vient du client est potentiellement malveillant. Le serveur doit toujours revalider, re-vérifier les droits et ne jamais faire confiance aveuglément à un paramètre reçu — même s'il provient d'un formulaire validé en HTML5.

Où vérifier un mot de passe lors d'une connexion ?

Mémorisé côté client, retransmis au serveur

Certaines informations sont conservées localement par le navigateur et rejouées à chaque requête :

Cookies : petits couples nom=valeur stockés par le navigateur, réenvoyés automatiquement à chaque requête vers le site qui les a posés. Sert typiquement à garder la session de connexion.
localStorage : zone de stockage clé-valeur côté client, non retransmise automatiquement. Pour des préférences locales (thème clair/sombre, brouillon de message).
Cache HTTP : les images, scripts et feuilles de style téléchargés une fois peuvent être réutilisés sans nouvelle requête.

Le serveur, lui, ne mémorise rien sur le client en dehors de ce qu'il décide de stocker dans ses propres bases. Il dépend des cookies (ou d'un token envoyé manuellement) pour reconnaître un visiteur d'une requête à l'autre.

Anatomie d'une requête HTTP

Une requête HTTP est un message texte envoyé du client vers le serveur. Elle comporte trois parties :

POST /inscription HTTP/1.1                 ← ligne de requête
Host: exemple.fr                           ┐
User-Agent: Mozilla/5.0 …                  │  en-têtes
Content-Type: application/x-www-form-urlencoded │
Cookie: session=abc123                     ┘

email=alice%40exemple.fr&motdepasse=secret ← corps (optionnel)

Ligne de requête : méthode (GET, POST…), chemin de la ressource (/inscription), version du protocole (HTTP/1.1).
En-têtes : informations annexes (hôte, type de contenu, cookies, identité du client…).
Corps : données envoyées au serveur (présent surtout pour POST, PUT).

Anatomie d'une réponse HTTP

Le serveur répond avec un message de même structure :

HTTP/1.1 200 OK                            ← ligne de statut
Content-Type: text/html; charset=utf-8     ┐  en-têtes
Set-Cookie: session=abc123; HttpOnly       │
Content-Length: 1024                       ┘

<!DOCTYPE html>                            ← corps (le HTML, le JSON…)
<html>…</html>

Ligne de statut : version HTTP + code de statut (200, 404, 500…) + message court (OK, Not Found…).
En-têtes : type du contenu retourné, cookies à poser, taille…
Corps : le HTML, le JSON, l'image, etc.

Les méthodes HTTP courantes

Méthode	Sémantique
`GET`	Lire une ressource. Paramètres dans l'URL. Pas d'effet de bord.
`POST`	Créer ou soumettre. Paramètres dans le corps. Effet de bord.
`PUT`	Remplacer une ressource complète. Idempotent.
`PATCH`	Modifier partiellement une ressource.
`DELETE`	Supprimer une ressource.

Une méthode est dite idempotente quand l'effet d'une requête est le même qu'on la rejoue 1 fois ou 100 fois. GET, PUT, DELETE sont idempotentes ; POST ne l'est pas (deux POST créent typiquement deux ressources).

En classe de Première, retenir surtout GET et POST, déjà vus avec les formulaires. Les autres sont là pour information.

Combien de fois peut-on rejouer une requête GET sans changer l'état du serveur (cas idéal) ?

Les codes de statut

Trois chiffres qui résument le sort de la requête. La famille (1er chiffre) donne déjà l'indication :

Famille	Sens	Exemples
2xx	Succès	`200 OK`, `201 Created`, `204 No Content`
3xx	Redirection	`301 Moved Permanently`, `302 Found`, `304 Not Modified`
4xx	Erreur côté client	`400 Bad Request`, `401 Unauthorized`, `403 Forbidden`, `404 Not Found`
5xx	Erreur côté serveur	`500 Internal Server Error`, `502 Bad Gateway`, `503 Service Unavailable`

À connaître absolument :

200 OK : tout va bien.
301/302 : la ressource a déménagé.
401 : non authentifié (« qui êtes-vous ? »).
403 : authentifié mais sans droit (« je sais qui vous êtes, et c'est non »).
404 : ressource introuvable.
500 : le serveur a planté.

HTTP vs HTTPS — le chiffrement

HTTP en clair circule lisible sur le réseau. N'importe quel intermédiaire (routeur, point d'accès Wi-Fi public, FAI) pourrait lire vos requêtes. HTTPS chiffre la communication via TLS (Transport Layer Security) :

[Navigateur] ←── TLS chiffré ──→ [Serveur]
            messages incompréhensibles
            pour tout intermédiaire

Effets concrets :

Confidentialité : le contenu (mots de passe, panier, requête) reste privé entre le client et le serveur.
Intégrité : un tiers ne peut pas modifier la requête en transit sans être détecté.
Authentification du serveur : le certificat TLS prouve que vous parlez bien à nsi.rocks et pas à un imposteur.

Sans HTTPS, POST n'est pas plus sécurisé que GET. Les deux passent en clair. C'est le chiffrement TLS qui rend la communication confidentielle, pas la méthode HTTP. Tout site sérieux n'utilise plus que HTTPS aujourd'hui (https://… dans la barre d'adresse, cadenas dans le navigateur).

Quand chiffrer ? Toujours, en pratique. Les navigateurs modernes signalent les sites en HTTP simple comme « non sécurisés ». Les API publiques refusent souvent les connexions non chiffrées.

Le cycle complet — exemple pas à pas

Vous tapez https://nsi.rocks/cours dans le navigateur. Voici le scénario type :

Résolution DNS — le navigateur traduit nsi.rocks en adresse IP (vu en Seconde).
Établissement TLS — client et serveur négocient le chiffrement (HTTPS).

Requête HTTP — le navigateur envoie :

GET /cours HTTP/1.1
Host: nsi.rocks
User-Agent: Mozilla/5.0 …
Cookie: session=xyz

Traitement serveur — le serveur identifie la session via le cookie, prépare la page (en BDD, en Markdown, peu importe), construit le HTML.

Réponse HTTP — il renvoie :

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

<!DOCTYPE html>…

Rendu — le navigateur lit le HTML, émet d'autres requêtes pour les CSS, les images, les scripts référencés (chacune avec son propre cycle requête/réponse), construit le DOM et l'affiche.
Interactivité — une fois la page rendue, JavaScript peut émettre d'autres requêtes HTTP en arrière-plan via fetch(…) sans recharger la page.

Que signifie un code de statut HTTP qui commence par 4 ?

Requêtes en JavaScript — `fetch` (sensibilisation)

Pour communiquer avec le serveur sans recharger la page, JavaScript propose la fonction fetch :

fetch("/api/articles")
  .then(reponse => reponse.json())
  .then(donnees => {
    console.log("Articles reçus :", donnees);
  })
  .catch(erreur => {
    console.error("Échec :", erreur);
  });

Et pour envoyer des données :

fetch("/api/inscription", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ email: "[email protected]" })
});

Vous n'aurez pas à maîtriser fetch au programme de Première, mais comprendre qu'une page peut faire des requêtes HTTP en cours de vie, sans soumission de formulaire, est essentiel pour saisir le Web moderne.

Cas particuliers et pièges

Confondre POST et chiffrement : POST cache les données de l'URL, pas du réseau. Seul HTTPS chiffre.
Croire que le client est de confiance : un utilisateur peut désactiver JavaScript, modifier les requêtes envoyées, ignorer les validations HTML. Le serveur est seul gardien des règles.
Confondre 401 et 403 : 401 = « pas connecté », 403 = « connecté mais pas autorisé ».
Penser HTTP « sans état » : HTTP est stateless à la base — chaque requête est indépendante. La continuité (session de connexion, panier) est rétablie artificiellement par les cookies ou les tokens.

Pour aller plus loin

HTTP a évolué : HTTP/2 (2015) puis HTTP/3 (2022) optimisent le transport sans changer la sémantique des méthodes et des codes. Le couple REST (architecture qui mappe les méthodes HTTP sur des actions CRUD) structure beaucoup d'API modernes — vous le rencontrerez en NSI Terminale et en BTS/CPGE. Le principe reste : un client demande, un serveur répond, sur un protocole texte simple.