13 - IHM Web

Introduction

On appelle interface homme-machine (IHM) tout ce qui permet à une personne de communiquer avec une machine : des éléments matériels que l’on touche ou que l’on regarde, et des éléments logiciels qui réagissent à nos gestes.

Prenons un pavé tactile de portable. Le doigt glisse sur le pavé (geste de l’utilisateur), le pavé mesure ce déplacement (matériel), le système d’exploitation déplace le pointeur à l’écran (logiciel), et un appui ouvre le fichier visé (logiciel). Chaque geste produit une réponse visible : c’est ce dialogue qui fait l’interface.

Introduction (suite)

Une bonne IHM part toujours des besoins de celui qui l’utilise : elle doit être claire, prévisible et facile à prendre en main. Dans ce chapitre, on s’intéresse à l’IHM que tout le monde utilise chaque jour : le navigateur Web, et la façon dont il obtient les pages qu’il affiche.

Protocole HTTP

Un protocole est un ensemble de règles que deux machines suivent pour se comprendre. Le protocole HTTP (Hypertext Transfer Protocol, protocole de transfert hypertexte) fixe la façon dont un client (le navigateur : Firefox, Chrome, Safari…) et un serveur Web (un programme comme Apache ou nginx, installé sur une machine connectée en permanence) échangent des messages.

Ces messages sont écrits en texte ordinaire : un humain peut les lire. Pour circuler sur le réseau, ils sont confiés aux protocoles TCP et IP, étudiés dans le chapitre sur les réseaux.

Protocole HTTP (suite)

HTTP sert à presque tout ce que fait un navigateur : charger une page HTML, une image ou une feuille de style, envoyer le contenu d’un formulaire. Les robots des moteurs de recherche, qui parcourent le Web pour l’indexer, l’utilisent aussi.

Protocole HTTP (suite)

Voici ce qui se passe lorsque l’on saisit l’adresse http://www.exemple.fr/cours/http.html :

1. le navigateur isole le nom de domaine www.exemple.fr ;
2. il demande à un serveur DNS l’adresse IP qui correspond à ce nom, par exemple 203.0.113.5 (une adresse IP est le numéro d’une machine sur Internet, comme un numéro de téléphone) ;
3. il ouvre une connexion TCP avec la machine qui porte cette adresse ;
4. il envoie une requête HTTP qui demande la ressource /cours/http.html ;
5. le serveur cherche ce fichier et le renvoie dans une réponse HTTP ;
6. le navigateur lit le code HTML reçu et construit la page à l’écran.

Protocole HTTP (suite)

Chaque échange suit donc le même schéma : une requête du client, une réponse du serveur.

Entête HTTP d’une requête

Une requête commence par quelques lignes appelées en-tête. Voici celle qu’envoie le navigateur dans l’exemple précédent :

GET /cours/http.html HTTP/1.1
Host: www.exemple.fr
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 14_5) Firefox/128.0
Accept: text/html
Accept-Language: fr

Entête HTTP d’une requête (suite)

Ligne par ligne :

• GET est la méthode : elle dit ce que le client attend du serveur (ici, obtenir une ressource) ;
• /cours/http.html est le chemin de la ressource sur le serveur ;
• HTTP/1.1 est la version du protocole ;
• Host rappelle le nom de domaine visé ; il peut être suivi d’un numéro de port, qui désigne le programme à qui s’adresse la requête sur la machine (80 par défaut pour HTTP, 443 pour HTTPS) ;

Entête HTTP d’une requête (suite)

• User-Agent décrit le navigateur et le système ; la mention Mozilla/5.0 est un reste historique que tous les navigateurs conservent ;
• Accept indique le type de contenu souhaité (ici une page HTML) ;
• Accept-Language indique la langue préférée de l’utilisateur.

Le protocole prévoit plusieurs méthodes : GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS, CONNECT et TRACE. Quatre suffisent pour ce chapitre :

Entête HTTP d’une requête (suite)

• GET demande une ressource sans la modifier ; c’est la méthode utilisée quand on clique sur un lien ;
• POST envoie des données au serveur pour qu’il les traite, par exemple les réponses d’un formulaire d’inscription ;
• PUT dépose une ressource sur le serveur, ou remplace celle qui existe déjà ;
• DELETE demande la suppression d’une ressource.

Entête HTTP d’une réponse

Le serveur répond avec un message construit sur le même modèle : une ligne de statut, un en-tête, une ligne vide, puis le corps, c’est-à-dire le contenu demandé.

Entête HTTP d’une réponse (suite)

HTTP/1.1 200 OK
Date: Tue, 13 Oct 2026 08:15:42 GMT
Server: nginx/1.26.2
Content-Type: text/html; charset=UTF-8
Content-Length: 182

<!doctype html>
<html lang="fr">
<head>
<meta charset="utf-8">
<title>Le protocole HTTP</title>
</head>
<body>
<h1>Le protocole HTTP</h1>
<p>Une requête, puis une réponse.</p>
</body>
</html>

Entête HTTP d’une réponse (suite)

La première ligne est la ligne de statut. Elle donne la version du protocole, puis un code de réponse : 200 signifie que tout s’est bien passé et que la ressource est jointe. Le code le plus connu des internautes est sans doute 404, renvoyé quand la page demandée n’existe pas. Les codes principaux sont présentés plus bas.

Les lignes suivantes forment l’en-tête de la réponse :

• Date donne l’heure de la réponse ;
• Server indique le logiciel serveur qui a répondu, ici nginx ;
• Content-Type précise la nature du contenu (une page HTML) et son codage des caractères (UTF-8) ;
• Content-Length donne la taille du corps en octets.

Entête HTTP d’une réponse (suite)

Après la ligne vide vient le code HTML de la page. Le serveur ne l’affiche pas : il l’envoie tel quel, et c’est le navigateur qui l’interprète pour dessiner la page.

Le logiciel qui reçoit les requêtes et fabrique les réponses s’appelle un serveur Web. Les deux plus répandus sont nginx et Apache ; ils tournent le plus souvent sur des machines équipées d’un système GNU/Linux.

Formulaires : GET et POST

Un formulaire permet à l’utilisateur de saisir des informations et de les envoyer au serveur. Il est délimité par la balise <form>, dont deux attributs règlent l’envoi :

• action donne l’adresse du programme du serveur qui recevra les données ;
• method donne la méthode HTTP utilisée : get (la valeur par défaut) ou post.

Chaque champ porte un attribut name : c’est ce nom, associé à la valeur saisie, que le navigateur transmet au serveur.

Formulaires : GET et POST (suite)

<form action="/inscription" method="get">
  <label for="prenom">Prénom</label>
  <input type="text" id="prenom" name="prenom">
  <label for="age">Âge</label>
  <input type="number" id="age" name="age">
  <input type="submit" value="Envoyer">
</form>

L’utilisateur saisit Leo et 16, puis clique sur le bouton.

Avec la méthode GET, les paramètres sont ajoutés à l’adresse, après un point d’interrogation, sous la forme nom=valeur, et séparés par le caractère & :

Formulaires : GET et POST (suite)

GET /inscription?prenom=Leo&age=16 HTTP/1.1
Host: www.exemple.fr

Les paramètres restent visibles dans la barre d’adresse, dans l’historique du navigateur et dans les journaux du serveur ; l’adresse obtenue peut être mise en favori ou partagée. GET convient à une recherche ou à un filtre, qui ne modifient rien sur le serveur.

Formulaires : GET et POST (suite)

Avec la méthode POST, les mêmes paramètres voyagent dans le corps de la requête, après la ligne vide :

POST /inscription HTTP/1.1
Host: www.exemple.fr
Content-Type: application/x-www-form-urlencoded
Content-Length: 17

prenom=Leo&age=16

Formulaires : GET et POST (suite)

Ils n’apparaissent plus dans l’adresse. On emploie POST pour envoyer un mot de passe, créer un compte ou passer une commande, c’est-à-dire pour les envois qui modifient des données sur le serveur. POST ne chiffre rien pour autant : en HTTP, le corps d’une requête se lit sur le trajet aussi facilement que l’adresse. Seul HTTPS protège les données pendant leur transport.

Ce qui s’exécute sur le client et sur le serveur

Voici, dans l’ordre, ce qui se passe quand l’utilisateur envoie le formulaire :

1. le navigateur affiche la page reçue ; un script JavaScript de cette page peut s’exécuter sur le client, par exemple pour vérifier qu’un champ n’est pas vide, avant tout envoi ;
2. au clic sur le bouton, le navigateur construit la requête GET ou POST et l’envoie ;
3. sur le serveur, un programme (écrit par exemple en PHP ou en Python) lit les paramètres, consulte ou modifie une base de données, puis fabrique une page HTML ;
4. le serveur renvoie cette page dans sa réponse, et le navigateur l’affiche.

Ce qui s’exécute sur le client et sur le serveur (suite)

Le client ne voit jamais le code du serveur : il ne reçoit que la page produite. À l’inverse, le serveur ne voit pas ce que fait le script du client : une vérification faite en JavaScript peut être contournée, et le serveur doit refaire ses propres contrôles.

Les cookies

HTTP ne garde aucun souvenir d’une requête à l’autre : chaque requête est traitée seule. Pour qu’un site reconnaisse un visiteur (panier d’achat, connexion), le serveur ajoute à sa réponse un champ Set-Cookie :

Set-Cookie: session=a3f9c2

Le navigateur mémorise ce cookie, puis le renvoie au même site dans chacune des requêtes suivantes, dans le champ Cookie :

Cookie: session=a3f9c2

Les cookies (suite)

Le serveur sait ainsi que deux requêtes viennent du même visiteur. Le cookie est stocké sur le client : on peut le consulter ou l’effacer dans les réglages du navigateur.

Protocole HTTPS

Les messages HTTP circulent en clair : toute machine placée sur le trajet peut les lire. Le protocole HTTPS (le S signifie secure, sécurisé) ajoute une couche de chiffrement : les messages sont transformés de façon à n’être lisibles que par le client et le serveur.

Protocole HTTPS (suite)

Une connexion HTTPS se déroule en trois temps :

1. le navigateur demande une connexion sécurisée, parce que l’adresse commence par https:// ;
2. le serveur présente un certificat, sorte de carte d’identité numérique délivrée par un organisme de confiance ; le navigateur vérifie que ce certificat correspond bien au site demandé ;
3. client et serveur conviennent d’une clé de chiffrement commune, puis tous leurs échanges sont chiffrés avec cette clé.

Protocole HTTPS (suite)

Le certificat protège contre l’attaque de l’intermédiaire (en anglais man in the middle) : un pirate qui se ferait passer pour le site d’une banque ne pourrait pas présenter le certificat de cette banque, et le navigateur afficherait une alerte. Le chiffrement, lui, rend inutilisables les données qu’un pirate parviendrait à intercepter. Le fonctionnement des clés de chiffrement est étudié en terminale.

En pratique, avant de saisir un mot de passe ou des coordonnées bancaires, on vérifie que l’adresse commence par https:// et que le navigateur ne signale aucun problème de certificat.

Liste des codes HTTP

Le code de la ligne de statut tient en trois chiffres. Le premier chiffre donne la famille : 2 pour un succès, 3 pour une redirection, 4 pour une erreur du client, 5 pour une erreur du serveur.

Liste des codes HTTP (suite)

Liste des codes HTTP (suite)

Liste des principaux champs HTTP

Chaque ligne d’en-tête est un champ de la forme Nom: valeur. Voici les plus courants.

• Dans les requêtes

Liste des principaux champs HTTP (suite)

• Dans les réponses

Liste des principaux champs HTTP (suite)