L'Oubli Volontaire

HTTP est un amnésique. C'est un trait fondamental, une caractéristique architecturale : il est "sans état" (stateless). Chaque requête qu'il transporte est un événement isolé, complet en soi. Pour le serveur, chaque appel qui arrive est le premier. Il ne se souvient pas de celui qui est venu une seconde avant. Cette amnésie est une force – elle simplifie, rend le système robuste et scalable – mais c'est aussi un problème majeur. Comment faire du web interactif, des paniers d'achat, des connexions utilisateurs, avec un facteur qui oublie tout à chaque tournée ?

1. Le Problème du "Stateless" : La Mémoire Qui Fait Défaut

Imaginez un serveur de banque. Un client demande son solde (GET /compte/solde). Le serveur répond 200 OK avec le montant. Puis, une seconde plus tard, le même client demande un virement (POST /compte/virement). Pour HTTP, ces deux requêtes sont totalement indépendantes. Le serveur qui reçoit la deuxième n'a aucun moyen de savoir qu'elle vient de la même personne que la première. Il ne sait pas qui demande le virement.

Conséquence : Aucune notion de "session", de "utilisateur connecté", de "panier en cours". L'expérience web moderne, personnalisée et continue, serait impossible. On retournerait à l'âge des pages statiques et anonymes.

Le défi est donc : comment ajouter de la mémoire par-dessus ce protocole qui n'en a pas ?

2. Les Solutions : Bricoler la Mémoire

Pour contourner cette amnésie, on a inventé des astuces. Des mécanismes qui, sans modifier HTTP, permettent au serveur (et au client) de se "reconnaître" d'une requête à l'autre.

a. Les Cookies : Le Ticket à Conserver

C'est la solution historique, directement intégrée au navigateur.

• Principe : Le serveur, lors de la première réponse, glisse un petit morceau de données dans l'en-tête Set-Cookie. Il dit au navigateur : "Garde ceci pour moi, et renvoie-le moi à chaque fois que tu me parleras."
• Fonctionnement :
  1. Première visite sur site.com → Le serveur répond Set-Cookie: session_id=abc123.
  2. Le navigateur stocke la paire session_id=abc123 dans son tiroir (pour site.com).
  3. Visite suivante sur site.com → Le navigateur ajoute automatiquement Cookie: session_id=abc123 à chaque requête.
  4. Le serveur voit ce cookie, reconnaît "abc123", et peut réattacher la requête à un utilisateur ou une session en mémoire côté serveur.
• C'est comme un ticket de vestiaire. Le serveur garde vos affaires (vos données de session) en coulisses, et vous donne un numéro (le cookie). À chaque interaction, vous montrez le numéro pour récupérer vos affaires.

b. Les Sessions : La Cachette Côté Serveur

Les cookies seuls ne sont souvent pas suffisants pour stocker toutes les données (panier, préférences). On les combine donc avec un mécanisme de session.

• Principe : Le cookie ne contient plus qu'un identifiant unique et impersonnel (ex: session_id=xyz789). Cet identifiant est la clé pour accéder à un petit espace de stockage privé côté serveur (en mémoire, dans une base de données rapide comme Redis).
• Fonctionnement :
  1. L'utilisateur se connecte. Le serveur crée un espace "session" pour lui, y stocke {user_id: 42, panier: [...]} et génère une clé xyz789 pour y accéder.
  2. Il envoie Set-Cookie: session_id=xyz789.
  3. Pour les requêtes suivantes, le serveur reçoit le cookie, utilise xyz789 pour retrouver l'espace session en mémoire, et a ainsi accès à toutes les données de l'utilisateur.
• C'est comme un coffre à la banque. Le cookie est la clé, mais les objets de valeur (les données) restent en sécurité dans le coffre-fort (le serveur).

c. Les Tokens (JWT) : Le Passeport Autonome

Avec les APIs modernes et les applications mobiles, une nouvelle méthode est apparue : le token, souvent sous forme de JWT (JSON Web Token).

• Principe : Ici, le serveur ne stocke rien. Il crée un passeport numérique signé et chiffré qui contient lui-même les données de l'utilisateur (son ID, son rôle, une date d'expiration). Ce token est envoyé au client (souvent dans le corps d'une réponse de login).
• Fonctionnement :
  1. Le client s'authentifie, reçoit un JWT (une longue chaîne cryptée).
  2. Pour chaque requête suivante, il place ce token dans l'en-tête Authorization: Bearer <le_token_jwt>.
  3. Le serveur reçoit le token, le déchiffre, vérifie sa signature, et extrait directement les informations de l'utilisateur. Aucune recherche en base de données n'est nécessaire pour retrouver la session.
• C'est comme un passeport avec un hologramme. Le document lui-même (le token) contient votre identité et est infalsifiable. Vous le présentez, on le vérifie, et on vous fait confiance.

En conclusion : L'amnésie native de HTTP n'est pas une fatalité. C'est une contrainte qui a stimulé la créativité des développeurs. Cookies, sessions et tokens sont les trois grandes familles de béquilles mémorielles que nous avons inventées. Chacune a ses forces et ses faiblesses (sécurité, performance, complexité), mais elles ont toutes le même but : faire croire à l'utilisateur qu'il dialogue avec un serveur qui le connaît, en dépit du facteur amnésique qu'est HTTP.