cours1 min de lecture

Client-serveur et requêtes HTTP

Quand vous chargez une page Web, deux ordinateurs dialoguent — le vôtre (client) demande, un serveur lointain répond. Ce dialogue suit un protocole précis : HTTP.

programme

Introduction

Chaque fois que vous chargez une page Web, deux ordinateurs entrent en conversation : le vôtre (qui exécute votre navigateur) et un serveur distant (qui héberge la page). Le vôtre demande, le serveur répond. Ce dialogue suit un protocole strict — HTTP (HyperText Transfer Protocol) — qui précise quels messages s'échanger et comment les structurer.

Comprendre ce dialogue, c'est lever un dernier capot du Web : derrière chaque clic se cache une requête envoyée à travers Internet, et une réponse qui revient avec le contenu attendu.

Le modèle client-serveur

Sur le Web, deux rôles bien distincts :

Le client est l'ordinateur qui demande. Le plus souvent, c'est votre navigateur (Firefox, Chrome, Safari…).
Le serveur est l'ordinateur qui répond. Il est allumé 24h/24, connecté à Internet, et stocke les pages et fichiers qu'il distribue.

Le modèle client-serveur

Le client demande, le serveur répond. Toujours dans cet ordre, jamais l'inverse. Le serveur ne « pousse » pas une page chez vous tant que vous ne l'avez pas demandée.

Analogie : imaginez un restaurant. Le client consulte la carte, passe commande auprès du serveur en salle ; le serveur transmet en cuisine, puis rapporte le plat. La salle ne vous apporte rien tant que vous n'avez pas commandé.

Qui fait quoi dans le navigateur ?

Une page Web moderne fait travailler les deux côtés :

Côté client (votre navigateur)	Côté serveur (machine distante)
Affiche le HTML / CSS reçu	Stocke les pages HTML, CSS, images
Exécute le JavaScript de la page	Génère parfois les pages à la demande (PHP, Python, Node.js)
Gère vos clics, vos formulaires	Stocke la base de données
Charge les images, vidéos	Envoie chaque ressource à la demande

C'est pour cela que le programme demande de « distinguer ce qui est exécuté par le client et par le serveur » : tout ce qui dépend du moment où vous interagissez (clic, animation, formulaire) tourne dans votre navigateur ; tout ce qui dépend de données partagées (catalogue produits, commentaires, posts) est calculé sur le serveur.

Outil pédagogique : ouvrez les Outils de développement d'un navigateur (touche F12 sur la plupart). L'onglet Réseau vous montre toutes les requêtes émises pour charger la page courante. Chaque ligne = un dialogue client/serveur.

Quand vous tapez une adresse Web, qui contacte qui en premier ?

Le protocole HTTP : la langue du dialogue

HTTP signifie HyperText Transfer Protocol — protocole de transfert hypertexte. C'est l'ensemble des règles qui dictent comment le client et le serveur formulent leurs messages.

Une transaction HTTP, c'est toujours :

Le client envoie une requête.
Le serveur renvoie une réponse.

Une requête HTTP : à quoi ça ressemble

Quand vous demandez https://nsi.rocks/cours/sb-web à votre navigateur, voici ce qu'il envoie réellement au serveur (en simplifié) :

GET /cours/sb-web HTTP/1.1
Host: nsi.rocks
User-Agent: Mozilla/5.0 (...)

Décomposons ligne par ligne :

Élément	Valeur	Rôle
Méthode	`GET`	Le verbe : « je veux récupérer une ressource »
Chemin	`/cours/sb-web`	Quelle ressource sur le serveur
Version	`HTTP/1.1`	Version du protocole
Host	`nsi.rocks`	Quel site (un serveur peut en héberger plusieurs)
User-Agent	`Mozilla/5.0 (...)`	Quel navigateur fait la demande

Les deux dernières lignes (Host, User-Agent) sont des en-têtes : des informations supplémentaires que le navigateur joint à la requête. Une vraie requête en compte plusieurs autres, mais ces deux-là suffisent pour comprendre le principe.

Les méthodes HTTP à connaître

Méthode	Sens
`GET`	Récupérer une ressource (le cas le plus fréquent — afficher une page)
`POST`	Envoyer des données au serveur (formulaire, message à publier)

Pour SNT, deux méthodes suffisent : GET (afficher une page, suivre un lien) et POST (envoyer un formulaire, publier un message). D'autres méthodes existent (PUT, DELETE…) mais sortent du programme à ce niveau.

Les paramètres dans une requête

Une URL peut contenir des paramètres après le ?. Ils sont transmis avec la requête, et permettent au serveur de personnaliser sa réponse :

https://www.google.com/search?q=meteo+paris&hl=fr

Paramètre	Valeur
`q`	`meteo paris` (la recherche)
`hl`	`fr` (langue d'affichage)

Plusieurs paramètres sont séparés par &. Cette URL utilise donc la méthode GET pour transmettre q=meteo+paris et hl=fr au serveur de Google.

Quand on remplit un formulaire (par exemple un mot de passe), il ne faut pas que la donnée passe par l'URL en méthode GET — sinon le mot de passe apparaît dans l'historique du navigateur et dans les journaux du serveur. C'est la raison pour laquelle les formulaires de connexion utilisent toujours POST.

Dans l'URL https://example.com/search?q=hello&page=2, combien de paramètres sont passés au serveur ?

Une réponse HTTP : à quoi ça ressemble

Le serveur répond avec un message qui commence par un code de statut :

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1245

<!DOCTYPE html>
<html>
...
</html>

200 OK signifie : « j'ai trouvé la ressource, la voici ».
Content-Type indique le type de contenu (text/html ici, mais ce peut être image/png, application/pdf…).
Après une ligne vide, le contenu lui-même (le HTML de la page).

Codes de statut à reconnaître

Code	Signification	Sens
`200`	OK	Tout va bien, voici la ressource
`301` / `302`	Redirection	La ressource a changé d'adresse
`403`	Forbidden	Accès interdit
`404`	Not Found	Page introuvable (« lien cassé »)
`500`	Internal Server Error	Le serveur a planté

Le célèbre « erreur 404 » que vous voyez parfois est exactement ça : le serveur vous répond « je n'ai pas cette page ». C'est une réponse HTTP valide, juste négative.

Récapitulatif : le voyage d'une page

Quand vous tapez nsi.rocks dans la barre de votre navigateur :

Le navigateur résout le nom via le DNS (nsi.rocks → adresse IP) — vu au chapitre Internet.
Le navigateur ouvre une connexion TCP avec le serveur à cette IP.
Le navigateur envoie une requête HTTP : GET / HTTP/1.1.
Le serveur traite la requête et renvoie une réponse HTTP : 200 OK suivi du HTML de la page d'accueil.
Le navigateur analyse le HTML et affiche la page.
Pour chaque image, chaque feuille CSS, chaque fichier JavaScript référencé dans le HTML : nouvelle requête, nouvelle réponse.

Une seule page peut ainsi déclencher des dizaines de requêtes HTTP.

Cas particuliers et pièges

HTTP n'est pas chiffré par défaut — c'est HTTPS qui ajoute le chiffrement (s pour secure).
Le serveur ne sait pas « qui » est le client de manière fiable — c'est pour cela qu'on a besoin des cookies pour identifier un utilisateur d'une requête à l'autre (vu au cours sécurité).
Une requête est sans mémoire : chaque échange est indépendant du précédent du point de vue du protocole HTTP.

À retenir

Le Web fonctionne en client-serveur : le client (navigateur) demande, le serveur répond. Le dialogue suit le protocole HTTP : une requête qui précise une méthode (GET, POST) et un chemin, suivie d'une réponse qui commence par un code de statut (200, 404…). Les paramètres sont passés dans l'URL après un ?, séparés par &.