Le modèle client-serveur : comment une page arrive dans ton navigateur
8 min · Débutant · 7 août 2026
Deux rôles, une même conversation
Le web repose sur un modèle simple : un client (ton navigateur) envoie une demande, un serveur (une machine ailleurs sur le réseau) y répond. Le client initie toujours l’échange ; le serveur ne parle jamais en premier.
Cette dissymétrie a une conséquence directe pour la suite de ce cours : presque toutes les techniques qui suivent, qu’elles soient légitimes ou malveillantes, consistent à envoyer une requête un peu différente de celle attendue, pour observer comment le serveur y répond.
Le trajet complet, étape par étape
Quand tu tapes https://cybercursus.fr/fr/ dans la barre d’adresse et que tu appuies sur Entrée, plusieurs étapes s’enchaînent avant que la page ne s’affiche :
1. Résolution DNS : le nom "cybercursus.fr" est traduit en adresse IP
2. Connexion : le navigateur établit une connexion avec le serveur à cette adresse
3. Requête : le navigateur envoie une requête HTTP ("donne-moi cette page")
4. Traitement : le serveur reçoit la requête, prépare une réponse
5. Réponse : le serveur renvoie la réponse (le code de la page, entre autres)
6. Rendu : le navigateur affiche la page à partir de la réponse reçue Le rôle du DNS
Un ordinateur ne comprend pas nativement cybercursus.fr : il communique avec des adresses IP, comme 76.76.21.21. Le DNS (Domain Name System) est l’annuaire distribué qui fait cette traduction, à l’étape 1 du trajet ci-dessus.
Info
Cette résolution est mise en cache à plusieurs niveaux (navigateur, système d’exploitation, box internet) : c’est pour ça qu’un changement de configuration DNS met parfois plusieurs heures à devenir visible pour tous les visiteurs d’un site.
Ce que ce modèle implique
Le serveur ne peut réagir qu’à ce qu’on lui envoie explicitement dans une requête. Autrement dit, toute la logique de sécurité d’une application web repose, d’une manière ou d’une autre, sur la capacité du serveur à traiter correctement des requêtes qu’il n’a pas anticipées, y compris des requêtes délibérément construites pour le tromper. C’est le fil conducteur du reste de ce cours, et de celui sur les injections SQL.