Comment fonctionne le Web ? Client, serveur, navigateur et HTTP expliqués simplement

Le Web, ce n’est pas Internet

On confond souvent Internet et le Web. Internet est l’infrastructure globale : câbles, fibres optiques, antennes, routeurs, centres de données, protocoles réseau. Le Web, lui, est un service qui utilise Internet pour consulter des documents et des applications à l’aide d’un navigateur.

Quand vous ouvrez une page, vous n’ouvrez pas directement un fichier magique situé quelque part dans le ciel. Votre navigateur envoie une demande à une machine distante, appelée serveur. Ce serveur répond avec des données : souvent du HTML, du CSS, du JavaScript, des images, des polices ou du JSON.

Le rôle du développeur web consiste justement à comprendre cette conversation entre plusieurs acteurs : le client, le serveur, le navigateur, le protocole HTTP et les ressources qui composent la page.

Les acteurs principaux

Le client

Le client est l’application qui demande une ressource. Dans la plupart des cas, il s’agit d’un navigateur : Chrome, Firefox, Safari, Edge. Mais un client peut aussi être une application mobile, un script Node.js, un outil en ligne de commande comme curl ou une autre API.

Exemple avec curl :

curl https://example.com

Cette commande joue le rôle d’un client HTTP. Elle demande une page au serveur et affiche la réponse dans le terminal.

Le navigateur

Le navigateur est un client très sophistiqué. Il ne se contente pas de télécharger du texte. Il sait interpréter HTML, appliquer CSS, exécuter JavaScript, gérer le cache, stocker des données locales, sécuriser les échanges, afficher des images, lire des vidéos et exposer des centaines d’API web.

Son travail commence souvent par une URL comme :

https://www.example.com/articles/web

Cette URL contient plusieurs informations :

• https indique le protocole utilisé ;
• www.example.com indique le nom de domaine ;
• /articles/web indique le chemin de la ressource demandée.

Le serveur

Le serveur est la machine, ou le programme, qui reçoit la requête et renvoie une réponse. Il peut servir des fichiers statiques, comme une page HTML ou une image, ou générer dynamiquement une réponse à partir d’une base de données.

Un serveur minimal en Node.js peut ressembler à ceci :

import http from "node:http";

const server = http.createServer((request, response) => {
  response.writeHead(200, {
    "Content-Type": "text/html; charset=utf-8"
  });

  response.end("<h1>Bonjour depuis le serveur</h1>");
});

server.listen(3000, () => {
  console.log("Serveur disponible sur http://localhost:3000");
});

Ce code écoute sur le port 3000. Quand un client envoie une requête, le serveur répond avec du HTML.

Que se passe-t-il quand on tape une adresse ?

Imaginons que vous saisissiez https://example.com dans la barre d’adresse. Le navigateur doit d’abord trouver à quelle adresse IP correspond le nom de domaine. Cette étape passe par le DNS, une sorte d’annuaire distribué qui transforme un nom lisible en adresse exploitable par les machines.

Ensuite, le navigateur ouvre une connexion avec le serveur. Avec HTTPS, cette connexion est chiffrée afin d’éviter qu’un intermédiaire puisse lire ou modifier les échanges. C’est devenu la norme pour les sites modernes, notamment pour protéger les formulaires, les sessions utilisateur et les données personnelles.

Une fois la connexion prête, le navigateur envoie une requête HTTP.

Une requête HTTP, c’est quoi ?

HTTP est le protocole de communication principal du Web. Une requête HTTP contient une méthode, un chemin, des en-têtes et parfois un corps.

Exemple simplifié :

GET /articles/web HTTP/1.1
Host: example.com
Accept: text/html
User-Agent: Mozilla/5.0

La méthode GET signifie : « je veux récupérer une ressource ». Il existe d’autres méthodes courantes :

• POST pour envoyer des données ;
• PUT ou PATCH pour modifier une ressource ;
• DELETE pour supprimer une ressource ;
• OPTIONS pour demander quelles opérations sont possibles.

Côté JavaScript, on utilise souvent fetch pour déclencher une requête HTTP :

const response = await fetch("/api/products");
const products: unknown = await response.json();

console.log(products);

Dans une vraie application TypeScript, il ne faut pas faire confiance aveuglément au JSON reçu. Ce sujet est détaillé dans l’article sur le typage des données API en TypeScript.

Une réponse HTTP, c’est quoi ?

Le serveur répond avec un statut, des en-têtes et un corps.

Exemple simplifié :

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=3600

<!doctype html>
<html>
  <head>
    <title>Ma page</title>
  </head>
  <body>
    <h1>Bonjour</h1>
  </body>
</html>

Le code 200 indique que tout s’est bien passé. D’autres codes sont fréquents :

• 301 ou 308 pour une redirection permanente ;
• 302 ou 307 pour une redirection temporaire ;
• 404 quand la ressource n’existe pas ;
• 500 quand le serveur rencontre une erreur interne.

Les en-têtes HTTP donnent des informations supplémentaires. Content-Type indique le type de contenu. Cache-Control indique si le navigateur peut réutiliser une réponse déjà téléchargée. Content-Encoding peut indiquer une compression comme gzip ou Brotli, sujet détaillé dans l’article sur la compression HTTP.

Comment le navigateur construit la page

Quand le navigateur reçoit du HTML, il le parse et construit le DOM, c’est-à-dire une représentation structurée du document. Ensuite, il télécharge les ressources référencées : fichiers CSS, scripts JavaScript, images, polices, modules, vidéos.

Voici une page simple :

<!doctype html>
<html lang="fr">
  <head>
    <meta charset="utf-8" />
    <title>Produit</title>
    <link rel="stylesheet" href="/styles.css" />
    <script type="module" src="/app.js"></script>
  </head>
  <body>
    <main>
      <h1>Chaise ergonomique</h1>
      <p>Une chaise pensée pour le confort quotidien.</p>
      <button>Ajouter au panier</button>
    </main>
  </body>
</html>

Le HTML décrit la structure, le CSS décrit la présentation, JavaScript ajoute des comportements. Ces trois couches ne jouent pas le même rôle. Une base HTML claire améliore l’accessibilité, le référencement et la robustesse. Cette logique rejoint l’approche de progressive enhancement, qui consiste à partir d’un document fonctionnel avant d’ajouter des améliorations.

Une page web moderne charge souvent plusieurs ressources

Une page n’est presque jamais composée d’un seul fichier. Après le HTML initial, le navigateur peut demander :

• une feuille CSS ;
• plusieurs modules JavaScript ;
• des images responsives ;
• une police ;
• des données JSON ;
• des icônes ;
• des fichiers vidéo ou audio.

Le navigateur organise ces téléchargements selon leur priorité. Les ressources critiques, comme le CSS nécessaire au premier affichage, doivent arriver vite. Les ressources secondaires peuvent attendre.

On peut aider le navigateur avec des indications comme preload, preconnect ou modulepreload, abordées dans l’article sur les resource hints HTML.

Site statique, application web et API

Un site statique sert principalement des fichiers déjà prêts : HTML, CSS, JavaScript, images. C’est simple, rapide et robuste.

Une application web dynamique peut générer des pages selon l’utilisateur, son panier, ses permissions ou le contenu d’une base de données. Le serveur peut produire du HTML directement, ou bien fournir une API JSON consommée par le frontend.

Exemple de réponse JSON :

{
  "id": "product-42",
  "name": "Chaise ergonomique",
  "price": 149.9,
  "available": true
}

Le navigateur peut récupérer cette donnée puis mettre l’interface à jour sans recharger toute la page. C’est le principe utilisé par de nombreuses interfaces en JavaScript, qu’elles soient écrites avec Vue, React, Nuxt, Next ou sans framework.

Le cache : éviter de tout retélécharger

Pour aller plus vite, le navigateur peut mettre certaines réponses en cache. Une image, une police ou un fichier JavaScript versionné n’a pas besoin d’être téléchargé à chaque visite.

Un en-tête comme celui-ci indique que la ressource peut être conservée longtemps :

Cache-Control: public, max-age=31536000, immutable

Le cache améliore les performances, mais il doit être maîtrisé. Un fichier trop fortement caché sans stratégie de versionnement peut empêcher les utilisateurs de recevoir une correction. Pour les applications plus avancées, les Service Workers permettent même d’intercepter certaines requêtes et de rendre des pages partiellement disponibles hors ligne.

Sécurité : pourquoi HTTPS et les en-têtes comptent

Le Web repose sur la confiance entre client et serveur. HTTPS chiffre les échanges, mais ce n’est qu’une partie du sujet. Les en-têtes HTTP peuvent aussi limiter les risques : empêcher certains scripts de s’exécuter, contrôler les capacités du navigateur, limiter les ressources externes ou réduire l’impact d’une injection.

Par exemple, une Content Security Policy peut restreindre les scripts autorisés :

Content-Security-Policy: default-src 'self'; script-src 'self'

Cette protection est détaillée dans l’article sur la Content Security Policy. Elle montre bien que le fonctionnement du Web ne se limite pas à afficher des pages : il faut aussi contrôler ce que le navigateur a le droit de charger et d’exécuter.

Résumons le trajet d’une page

Quand vous ouvrez une page web, voici le scénario général :

1. Le navigateur lit l’URL.
2. Il résout le nom de domaine avec DNS.
3. Il ouvre une connexion sécurisée avec le serveur.
4. Il envoie une requête HTTP.
5. Le serveur renvoie une réponse HTTP.
6. Le navigateur parse le HTML.
7. Il télécharge CSS, JavaScript, images et autres ressources.
8. Il construit le rendu visuel.
9. JavaScript peut ensuite déclencher de nouvelles requêtes et modifier l’interface.

Comprendre ce cycle est fondamental. Cela aide à mieux déboguer une page blanche, une erreur 404, une API qui ne répond pas, une image lente à charger, un problème de cache ou une différence entre rendu serveur et rendu client.

Le Web paraît simple parce qu’un clic suffit à ouvrir une page. Techniquement, il s’agit pourtant d’une chaîne précise de protocoles, de formats et de décisions prises par le navigateur. Plus vous comprenez cette chaîne, plus vous développez des sites rapides, accessibles, maintenables et fiables.