Un serveur web, c'est quoi exactement ?

Définition par Corentin Tournier, développeur web

Définition du serveur web

Un serveur web est un logiciel qui reçoit les requêtes HTTP envoyées par un navigateur (ou tout autre client), les traite, puis renvoie une réponse : une page HTML, un fichier CSS, une image, ou toute autre ressource demandée. C'est ce logiciel, et non pas la machine sur laquelle il tourne, qui porte le nom de « serveur web ».

Cette nuance paraît anodine, mais elle est à l'origine d'une confusion très répandue chez les débutants : croire que le « serveur » désigne la machine physique. Un serveur web peut tourner sur un Raspberry Pi posé sur un bureau, sur une machine virtuelle louée chez un hébergeur, ou même sur votre propre ordinateur en local. La machine n'est qu'un support. Ce qui fait d'elle un serveur web, c'est le logiciel qui écoute les requêtes et y répond : Nginx, Apache, ou même un simple module intégré à Node.js.

Comment fonctionne un serveur web ? Le cycle requête-réponse

Quand vous tapez une URL dans votre navigateur, voici concrètement ce qui se passe :

1. Le navigateur résout le nom de domaine via le DNS pour obtenir l'adresse IP du serveur à contacter.
2. Il ouvre une connexion (via un socket TCP) sur un port précis du serveur : le port 80 pour du HTTP, le port 443 pour du HTTPS. Ce sont des conventions, pas des règles techniques absolues, c'est pour ça que votre serveur de développement local tourne souvent sur un port différent, comme 3000 ou 8080, sans que rien ne casse.
3. Il envoie une requête HTTP : une méthode (GET, POST...), un chemin, et des headers qui précisent le contexte de la demande.
4. Le serveur web reçoit cette requête, détermine quelle ressource ou quel traitement elle appelle, puis construit une réponse HTTP : un code de statut (200 pour un succès, 404 si la ressource n'existe pas, 500 en cas d'erreur serveur), des headers, et un contenu.
5. Le navigateur reçoit cette réponse et l'affiche.

Tout ce cycle se déroule en quelques dizaines à quelques centaines de millisecondes, et il fonctionne exactement de la même façon en local, sans connexion internet : lancer un serveur avec python -m http.server ou npx serve répond à des requêtes envoyées à localhost sans jamais sortir de votre machine, puisque le DNS et le routage réseau ne sont utiles que lorsque client et serveur sont sur des machines différentes.

L'architecture client-serveur

Ce mécanisme repose sur l'architecture client-serveur : d'un côté, un client (le navigateur) qui initie la demande ; de l'autre, un serveur qui écoute en permanence et répond. Le serveur web est la porte d'entrée de cette architecture côté serveur : celui qui accepte la connexion, avant que d'autres composants (base de données, serveur d'application, cache) n'entrent éventuellement en jeu pour construire la réponse.

C'est aussi ce qui explique pourquoi un même serveur web peut héberger plusieurs sites différents : grâce aux virtual hosts, il redirige chaque requête vers le bon dossier ou la bonne configuration selon le nom de domaine demandé. C'est exactement ce qui se passe sur un hébergement mutualisé : votre interface d'hébergeur affiche « votre serveur », alors qu'en réalité vous partagez la même instance Apache ou Nginx avec des centaines d'autres sites, chacun isolé par son propre virtual host.

Serveur web vs serveur d'application : la distinction qui change tout

C'est la confusion la plus fréquente chez les développeurs qui débutent, en particulier avec l'écosystème JavaScript. Un serveur d'application exécute la logique métier de votre code : il interprète du PHP, exécute du Python, ou fait tourner votre code Node.js. Un serveur web, lui, a historiquement pour rôle de servir du contenu statique (des fichiers HTML, CSS, JS, images) tels quels, sans les transformer.

Sauf que la frontière s'est brouillée avec le temps. Node.js, par exemple, embarque directement un module HTTP qui lui permet d'écouter un port et de répondre à des requêtes : il peut être son propre serveur web, sans qu'Apache ou Nginx ne soit nécessaire pour ça. Si votre professeur ou un tutoriel vous parle de « votre serveur Node.js », il ne s'agit pas d'un raccourci de langage : Node.js fait bien à la fois office de serveur web et de serveur d'application.

En pratique, en production, on combine souvent les deux : un serveur web comme Nginx en première ligne, qui sert les fichiers statiques et transmet le reste à un serveur d'application (Node.js, PHP-FPM, un serveur WSGI pour Python...). Ce qui nous amène directement au prochain point, source d'une deuxième confusion très fréquente.

Le reverse proxy n'est pas un serveur web

Placer Nginx « devant » une application Node.js est une pratique courante, mais elle ne consiste pas à remplacer le serveur web de l'application par Nginx. Dans cette configuration, Nginx fait office de reverse proxy : il reçoit la requête, mais au lieu de la traiter lui-même, il la redirige vers un autre processus (votre application Node.js, qui répond elle-même en tant que serveur web) et relaie la réponse au client.

Cette nuance change concrètement votre façon de débugger : si une requête échoue, il faut savoir si le problème vient de la configuration du reverse proxy (mauvaise redirection, timeout) ou du serveur applicatif derrière. Un reverse proxy peut aussi faire de l'équilibrage de charge (load balancing) entre plusieurs instances de votre application, gérer la terminaison TLS/SSL pour le HTTPS, ou encore servir de cache : autant de responsabilités distinctes du simple fait de « servir une page web ».

Apache vs Nginx : deux architectures, deux philosophies

Apache HTTP Server et Nginx sont les deux logiciels de serveur web les plus utilisés au monde, mais ils ne sont pas interchangeables sans conséquence : ils reposent sur des architectures internes différentes.

• Apache, lancé en 1995, traite historiquement chaque connexion via un processus ou un thread dédié. Cette approche offre une grande flexibilité de configuration, mais consomme davantage de mémoire à mesure que le nombre de connexions simultanées augmente.
• Nginx, créé en 2004 pour répondre aux limites d'Apache sur la gestion d'un grand nombre de connexions concurrentes, repose sur un modèle événementiel asynchrone : un nombre réduit de processus gère un très grand nombre de connexions en parallèle, avec une empreinte mémoire nettement plus stable sous forte charge.

Cette différence d'architecture explique en grande partie l'évolution du marché : selon W3Techs (janvier 2026), Nginx détient désormais 33,3 % de part de marché parmi les sites dont le serveur est identifiable, devant Cloudflare Server (25,8 %) et Apache, qui repasse sous la barre des 24,4 %. Mais ce chiffre ne veut rien dire isolément : pour un site à faible trafic, la différence de performance entre les deux est rarement perceptible. C'est surtout sous forte concurrence de connexions simultanées que l'architecture événementielle de Nginx prend l'avantage.

Où tourne un serveur web en pratique ?

Un serveur web peut tourner dans plusieurs contextes selon l'étape du projet :

• En local, sur votre machine de développement, souvent via un serveur intégré léger (le module HTTP de Node.js, le serveur de développement de Vite, python -m http.server...), sans jamais nécessiter de connexion internet.
• Sur un hébergement mutualisé, où votre site partage la même instance Apache ou Nginx que de nombreux autres sites, isolés via des virtual hosts.
• Sur un VPS (serveur privé virtuel) ou une instance cloud, vous installez et configurez vous-même votre serveur web. C'est là qu'intervient un fichier de configuration (comme nginx.conf) qu'il vaut mieux comprendre plutôt que copier-coller depuis un forum : une simple erreur de syntaxe, comme un point-virgule oublié, peut suffire à faire planter tout le serveur.
• Derrière un CDN, qui met en cache une partie du contenu au plus près des visiteurs pour soulager le serveur web d'origine.

Une fois en production, ne négligez pas les logs du serveur (access.log, error.log) : ils constituent la première source de diagnostic en cas de problème, et c'est souvent le premier réflexe qui manque aux développeurs qui n'ont jamais eu à déployer un projet eux-mêmes.