Le voyage d’une requête web

Vous cliquez sur un lien, tapez une URL, ou appuyez sur « Entrée ». Et presque instantanément, une page s’affiche. Mais que se passe‑t‑il réellement entre votre clic et l’affichage final ?

Cet article vous emmène dans les coulisses d’un site web : le trajet d’une requête, depuis votre navigateur jusqu’au serveur, puis le retour jusqu’à votre écran.

L’objectif : démystifier ce flot.

Tout commence dans votre navigateur (Chrome, Firefox, Safari, etc.). Dans le jargon technique du web, vous êtes un client, qui interagissez avec une interface web grâce à ce navigateur.

Sur le réseau internet, chaque équipement est identifié de manière unique par une adresse IP (Internet Protocol), un peu à la manière d’une adresse postale. 

Lorsque vous saisissez une URL (ex : https://www.nomdedomaine.com/blog) ou cliquez un lien, le navigateur prépare une requête dîte HTTP. Le premier réflexe du navigateur va être de déterminer à quelle adresse IP envoyer prépare cette requête HTTP. Il va donc s’adresser à un système DNS (Domain Name System), qui est comme un annuaire qui sait retrouver à quelle IP correspond ce nom de domaine.

Une fois l’adresse IP obtenue, le navigateur établit une connexion (souvent sécurisée via HTTPS) au serveur correspondant. Il génère alors une requête comprenant :

• La méthode (souvent GET pour « je veux cette page »),
• Le chemin (ex : /blog),
• Des en‑têtes (qui indiquent quel navigateur vous utilisez, quel type de contenu vous acceptez, etc.),
• Parfois des paramètres, par exemple pour filtrer les informations comme &categorie=cirque.

La requête quitte votre machine, passe par votre routeur/modem, traverse divers équipements (réseau de votre fournisseur, routeurs internet, caches, proxys…) avant d’atteindre le serveur.

Il est possible qu’un CDN (Content Delivery Network) ou une Cache intermédiaire serve la requête avant d’atteindre le serveur principal, accélérant ainsi l’affichage.

Enfin, la requête arrive sur le serveur web (ex : un serveur Apache, Nginx, ou autre) qui va la traiter.

Le serveur lit la requête : méthode, chemin, en‑têtes, etc. Il détermine ce que l’utilisateur demande.

Deux cas typiques :

• Le contenu est statique (ex : un fichier HTML, une image). Le serveur renvoie le fichier.
• Le contenu est dynamique : le serveur applique une logique métier, interroge une base de données, effectue un calcul…

Ensuite, le serveur génère une réponse HTTP, comportant :

• Un code de statut : par exemple 200 pour « OK » ou 404 pour « introuvable »,
• Des en‑têtes : type de contenu, Cache…
• Un corps : le HTML, le CSS et le JS de la page.

Une fois la réponse prête, elle est envoyée de nouveau sur le réseau en retour vers votre navigateur.

Votre navigateur reçoit la réponse.

Le navigateur lit le HTML, construit la structure de la page (DOM), télécharge et applique les styles CSS, puis seulement il affiche la page.

Les scripts JavaScript peuvent s’exécuter à différents moments selon leur place et leurs paramètres.

Au fil de la construction du rendu, il peut arriver que la page déclenche d’autres requêtes (AJAX) pour charger du contenu additionnel après l’affichage initial. Le tout doit se faire assez rapidement pour que l’utilisateur ne « patiente » pas trop : les temps de latence, de chargement des ressources, les caches, etc., influencent l’expérience utilisateur.

Pour rendre cela plus concret :

• Le navigateur est comme un client au guichet : il demande, attend une réponse.
• Le réseau est comme un réseau de routes et tunnels : la requête voyage.
• Le serveur est comme une usine : il prend la demande, traite, produit un résultat.
• Le navigateur est ensuite l’afficheur : il reçoit, interprète, affiche.

• HTTP (Hypertext Transfer Protocol) : le protocole qui définit comment les requêtes et réponses sont formatées.
• URL : l’adresse que vous saisissez pour demander une ressource.
• Méthode HTTP : GET, POST, etc. indiquent ce que le client veut faire.
• AJAX (Asynchronous JavaScript and XML) est une méthode qui permet à une page web de communiquer avec le serveur en arrière-plan, sans avoir besoin de se recharger entièrement , par exemple, pour afficher de nouveaux contenus, envoyer un formulaire ou mettre à jour une partie de la page en direct.
• Status code : 200 (OK), 404 (Not Found), 500 (Erreur serveur) …
• Un CDN est un réseau de serveurs répartis dans le monde, conçu pour livrer plus rapidement les contenus d’un site web (images, vidéos, fichiers, etc.) en les stockant au plus près de l’utilisateur final.
• Le DOM (Document Object Model) est comme une carte interactive de la page web que lit le navigateur : il transforme le code HTML en une structure que le navigateur peut comprendre, modifier et afficher, comme une maquette en blocs que l’on peut manipuler avec JavaScript.

Si un site est lent, c’est peut‑être la résolution DNS, ou un serveur surchargé, ou un gros fichier à charger côté client.

Si vous voyez une erreur 404, cela signifie que le serveur n’a pas trouvé la ressource demandée.

Si vous utilisez un site sur un mobile, ou une connexion lente, toute la chaîne doit être optimisée (réseau + serveur + client).

Vous avez maintenant une vue d’ensemble du chemin qu’emprunte une requête web : de votre clic jusqu’à l’affichage final. Vous savez ce que sont les étapes majeures et pourquoi chacune compte.

Dans un prochain article de cette série, nous plongerons côté serveur : ce qui se passe dans l’usine, dans la logique métier, les bases de données, les API, bref : l’intérieur du serveur.

Si vous avez des questions, des anecdotes (« mon site met 10 secondes », « j’ai une 404 »), n’hésitez pas à les partager : cela enrichira le dialogue.