HTTP : le guide complet du protocole invisible qui fait tourner le web

Ou : Comment un physicien du CERN a inventé la langue commune d’Internet — et pourquoi elle n’a toujours pas de mémoire

Vous avez cliqué sur un lien pour arriver ici. Entre votre clic et l’apparition de ce texte, votre navigateur et mon serveur ont eu une conversation. Une conversation structurée, polie, codifiée — et dont ni l’un ni l’autre ne se souviendra dans cinq secondes.

HTTP, c’est le système postal d’Internet. Votre navigateur écrit une lettre (« donne-moi cette page »), l’envoie à l’adresse indiquée, et attend la réponse. Le serveur lit la lettre, prépare le contenu, et le renvoie. Puis les deux s’oublient mutuellement. Chaque page que vous chargez est un échange postal complet — demande, réponse, oubli.

Ce protocole a été inventé en 1991 par un physicien du CERN qui voulait que des chercheurs puissent partager des documents¹. Trente-cinq ans plus tard, il transporte vos stories Instagram, vos virements bancaires, vos appels aux API REST, et les prompts que vous envoyez aux LLM. C’est le protocole le plus utilisé de la planète, et presque personne ne sait qu’il existe.

Comment fonctionne HTTP : anatomie du protocole qui fait tourner chaque page web

Une conversation à sens unique

HTTP est un protocole requête-réponse. Le client parle, le serveur répond. C’est tout. Pas de conversation libre, pas de flux bidirectionnel, pas de « attends, j’ai autre chose à te dire ». Le client envoie une lettre, le serveur répond, fin de l’échange.

Et surtout : HTTP est stateless — sans état. Le serveur ne se souvient pas de vous entre deux requêtes. Vous pouvez charger la même page dix fois, et pour le serveur, ce sont dix clients différents. Le facteur ne sait pas qu’il vous a déjà livré hier. Chaque livraison est la première.

C’est contre-intuitif, et c’est exactement ce qui fait la force du protocole. Si le serveur ne garde aucun état, on peut mettre cinquante serveurs derrière un répartiteur de charge et n’importe lequel peut répondre à n’importe quelle requête. Pas besoin de se souvenir de qui parle à qui. C’est cette propriété qui permet au web de tenir la charge de milliards d’utilisateurs simultanés — une prouesse d’ingénierie déguisée en amnésie chronique.

Évidemment, cette amnésie a un prix. Quand vous vous connectez à un site, vous ne voulez pas retaper votre mot de passe à chaque clic. On verra plus loin comment les cookies et les sessions contournent élégamment ce problème.

Les verbes : ce que vous demandez au serveur

Chaque requête HTTP commence par un verbe — une méthode qui indique au serveur ce que vous attendez de lui. C’est le type de courrier que vous envoyez : une demande d’information, un colis à livrer, un recommandé avec accusé de réception.

*PATCH peut être idempotent selon l’implémentation, mais ce n’est pas garanti par la spécification.

« Idempotent » signifie que faire la même requête deux fois produit le même résultat. DELETE /articles/7 deux fois ? L’article est supprimé la première fois, et la deuxième fois le serveur vous dit qu’il n’existe plus. Le résultat final est identique. POST /articles deux fois ? Vous avez créé deux articles. C’est la différence.

Si vous voulez voir ces verbes en action dans un contexte d’API, l’article API REST les détaille avec des exemples concrets.

Les codes de réponse : le serveur vous répond en chiffres

Chaque réponse HTTP arrive avec un code de statut à trois chiffres. C’est l’avis de réception de votre courrier — sauf que le bureau de poste est remarquablement précis sur ce qui s’est passé.

Les codes sont organisés en familles :

Les codes que vous croiserez le plus souvent :

Les headers : tout ce que l’enveloppe raconte

Si la requête est la lettre, les headers sont les mentions écrites sur l’enveloppe : l’expéditeur, la priorité, « fragile », « ouvrir en premier ». Ce sont des métadonnées qui accompagnent chaque requête et chaque réponse.

Quelques headers essentiels :

• Content-Type : le format du contenu (application/json, text/html). C’est la différence entre envoyer un colis et envoyer une lettre — le destinataire doit savoir ce qu’il ouvre.
• Authorization : vos identifiants. Le badge d’accès glissé dans l’enveloppe.
• Cache-Control : combien de temps le client peut garder la réponse en cache avant de redemander.
• Accept : ce que le client préfère comme format de réponse. « Envoyez-moi du JSON, pas du XML, s’il vous plaît. »
• User-Agent : qui est le client (Chrome, Firefox, un bot, un script Python).
• Access-Control-Allow-Origin : le header CORS, qui contrôle quels sites tiers ont le droit d’appeler votre serveur. Un sujet à lui seul.

Les headers sont souvent la partie la plus ignorée d’HTTP, et souvent la source des bugs les plus frustrants. Un Content-Type manquant et votre API retourne du texte brut au lieu de JSON. Un Cache-Control mal configuré et vos utilisateurs voient des données d’il y a trois heures.

HTTPS et TLS : sceller l’enveloppe

HTTP est une carte postale. Tout le monde peut la lire : votre fournisseur d’accès, l’opérateur du WiFi du café, quiconque se trouve entre votre navigateur et le serveur. Le contenu circule en clair³.

HTTPS, c’est la même carte postale glissée dans une enveloppe scellée. Le « S » signifie « Secure », et la sécurité vient de TLS (Transport Layer Security) — un protocole de chiffrement qui s’intercale entre HTTP et la couche réseau.

Le processus, en simplifié : votre navigateur et le serveur se serrent la main (le TLS handshake), s’échangent des clés de chiffrement, et à partir de là tout le trafic est chiffré. Même si quelqu’un intercepte les données, il ne voit que du bruit.

Depuis 2015-2016, Let’s Encrypt a rendu les certificats TLS gratuits et automatiques. Avant ça, un certificat coûtait de l’argent et du temps, ce qui décourageait beaucoup de sites. Aujourd’hui, navigateurs et moteurs de recherche pénalisent activement les sites en HTTP simple. HTTPS n’est plus une option — c’est le strict minimum.

Cookies et sessions : le post-it sur l’enveloppe

HTTP est stateless. Le serveur ne se souvient de rien. Mais vous, vous voulez rester connecté. Vous ne voulez pas vous authentifier à chaque clic.

La solution : les cookies. Quand vous vous connectez, le serveur colle un post-it sur l’enveloppe retour — un header Set-Cookie qui contient un identifiant unique. À chaque requête suivante, votre navigateur renvoie ce post-it via le header Cookie, et le serveur fait semblant de se souvenir de vous.

Côté serveur, deux approches coexistent :

• Sessions serveur : le serveur stocke vos données de session (panier d’achat, préférences, identité) et le cookie ne contient qu’un identifiant. Simple, mais ça force le serveur à garder un état — ce qui contredit un peu le principe stateless.
• Tokens JWT : toutes les informations sont dans le cookie lui-même, signées cryptographiquement. Le serveur n’a rien à stocker — il vérifie juste la signature. C’est l’approche préférée des architectures modernes et des API REST.

Dans les deux cas, c’est un contournement élégant : HTTP reste stateless, mais l’application au-dessus simule un état grâce à un post-it que le client transporte fidèlement d’une requête à l’autre.

De HTTP/0.9 à HTTP/3 : trente-cinq ans d’évolution

HTTP n’est pas resté figé. Cinq versions majeures en trente-cinq ans, chacune résolvant les problèmes de la précédente :

HTTP/0.9 tenait sur une page. Une seule méthode, pas de headers, du HTML brut en retour. C’était suffisant pour des physiciens qui partageaient des documents au CERN.

HTTP/1.1 a tenu le web pendant presque vingt ans. Sa grande innovation : les connexions persistantes. Avec HTTP/1.0, chaque requête ouvrait et fermait une connexion TCP. Avec 1.1, on peut envoyer plusieurs requêtes sur la même connexion. Mais une seule à la fois — elles font la queue.

HTTP/2 (basé sur SPDY de Google) a résolu le problème de la file d’attente grâce au multiplexage : plusieurs requêtes et réponses transitent simultanément sur la même connexion, en flux binaire plutôt qu’en texte. En termes postaux : au lieu d’un facteur qui fait un aller-retour par lettre, on met plusieurs lettres dans le même sac.

HTTP/3 remplace TCP par QUIC, un protocole de transport basé sur UDP. Pourquoi ? Parce que TCP a un problème fondamental : si un seul paquet se perd dans un flux multiplexé, tout le flux attend la retransmission (head-of-line blocking). QUIC gère chaque flux indépendamment. C’est le passage du courrier postal au drone de livraison — plus rapide, et un retard sur une livraison ne bloque pas les autres.

HTTP en pratique aujourd’hui

HTTP est devenu bien plus qu’un protocole pour afficher des pages web. C’est la couche de transport universelle d’Internet :

• Les navigateurs l’utilisent pour charger chaque page, chaque image, chaque script.
• Les API REST s’appuient entièrement dessus — quand vous construisez une API, vous construisez sur HTTP.
• Les CDN (réseaux de distribution de contenu) optimisent la livraison HTTP en rapprochant le contenu des utilisateurs.
• Les LLM : quand vous interrogez un modèle de langage via une API, c’est HTTP qui transporte votre prompt et la réponse.
• Les webhooks, ces notifications serveur-à-serveur, sont des requêtes HTTP POST.

Pour les cas où HTTP ne suffit pas — chat en temps réel, mises à jour en continu, jeux multijoueurs — WebSocket prend le relais. WebSocket commence par un handshake HTTP classique, puis « upgrade » la connexion vers un canal bidirectionnel persistant. HTTP ouvre la porte, WebSocket s’installe dans le salon.

Récapitulatif

HTTP est le protocole le plus utilisé et le moins remarqué du monde. Il est partout, tout le temps, pour tout le monde — et il ne se souvient de personne. C’est peut-être la plus belle métaphore involontaire de l’infrastructure : les choses qui fonctionnent vraiment bien sont celles qu’on ne remarque jamais. Jusqu’au jour où elles tombent en panne, et là on découvre que toute la civilisation numérique tenait sur un système postal qui oublie tout après chaque livraison.