Ce qui se passe quand on tape une URL

Tu tapes une adresse, tu appuies sur Entrée, et la page s'affiche, souvent en moins d'une seconde. Entre les deux, ton navigateur a trouvé un serveur parmi des milliards de machines, ouvert une connexion chiffrée à travers des milliers de kilomètres de câbles, demandé une page, puis des dizaines de fichiers, et dessiné le tout. C'est l'une des mécaniques les plus utilisées au monde, et presque personne ne l'a vue fonctionner.

Ce cours suit ce trajet étape par étape, avec un fil unique : tu es à Paris, et tu ouvres l'article d'un journal en ligne imaginaire, www.example.com. À chaque étape, tu verras ce qui est échangé, ce que cela coûte en temps, et pourquoi une page peut être lente alors que ta connexion est excellente.

Pour qui : tu as déjà utilisé un navigateur, et tu veux comprendre ce qu'il fait ; tu n'as besoin de rien d'autre. Si tu écris du code web, ce sont les fondations de tout ce que tu construiras. Ouvre l'onglet Réseau des outils de développement de ton navigateur (touche F12) sur n'importe quelle page : tout ce qui suit s'y voit.

L'URL, pièce par pièce

Une adresse complète se lit de gauche à droite :

https://www.example.com:443/cours/web?niveau=1#quiz

Chaque pièce a un destinataire différent. L'hôte part au DNS, puis dans l'en-tête Host de la requête. Le schéma et le port décident du type de connexion. Le chemin et les paramètres composent la première ligne de la requête. Reste le fragment : où va-t-il ? Ajoute #faq à la fin de l'adresse de l'article : le serveur le recevra-t-il ? Parie, puis tape-le dans la figure, et change aussi le port, ou retire le chemin.

Le fragment disparaît de la requête : il ne quitte jamais le navigateur, qui s'en sert pour défiler jusqu'à l'élément de la page qui porte ce nom. Un serveur ne peut donc rien en faire, et ne le verra jamais dans ses journaux. Le port, lui, est sous-entendu par le schéma, et il n'entre dans l'en-tête Host que s'il sort de l'ordinaire. Ce qui part vraiment tient en deux lignes, GET /articles/42?page=2 HTTP/1.1 et Host: www.example.com. Tout le reste du cours explique ce qu'il faut faire avant de pouvoir les envoyer.

Le trajet d'une page, d'un coup d'œil

Avant de détailler, voici la carte. Entre l'adresse tapée et la page affichée, le navigateur enchaîne cinq étapes, et chacune ne peut commencer qu'une fois la précédente finie : trouver l'adresse IP du serveur (le DNS), ouvrir avec lui une connexion fiable (TCP), la chiffrer (TLS), envoyer la requête (HTTP), puis dessiner la réponse. Chaque conversation avec le serveur est un aller-retour, et c'est le nombre d'allers-retours qui fait la lenteur d'une page, bien plus que le volume de données.

Fais avancer le jeton d'une étape à l'autre. À l'étape HTTP, un pari t'attend : combien d'allers-retours le navigateur a-t-il déjà payés avant d'avoir demandé quoi que ce soit au serveur ?

Deux ou trois allers-retours, selon la version de TLS, sont payés avant que la première ligne de la requête ne parte. Le DNS ne compte pas parmi eux : il interroge un résolveur proche, pas le serveur du journal. Retiens cette arithmétique, car elle revient à chaque section. Pour aller plus vite, on ne cherche pas d'abord à envoyer moins d'octets : on cherche à supprimer des allers-retours, ou à garder la connexion ouverte pour les requêtes suivantes.

Trouver le serveur : le DNS

Les machines s'adressent par des numéros, les adresses IP : 192.0.2.10 en IPv4, 2001:db8::10 en IPv6 (deux adresses réservées aux exemples). Le DNS (Domain Name System) est l'annuaire qui traduit un nom en adresse. Le navigateur regarde d'abord sa propre mémoire, puis celle du système, puis demande à un résolveur : celui de ton fournisseur d'accès, ou un résolveur public.

C'est le résolveur qui fait le travail, de proche en proche, sur trois niveaux. Les serveurs racine ne connaissent aucun site : ils savent seulement qui gère chaque fin d'adresse (.com, .fr…). Au 21 octobre 2026, la racine compte treize identités, exploitées par douze organisations indépendantes et répliquées sur 2 047 machines dans le monde. Les serveurs de .com savent qui gère example.com. Et le serveur du site, celui qui fait autorité, donne enfin l'adresse.

Chaque réponse est gardée pendant une durée choisie par son propriétaire, le TTL (time to live). Interrogés à la main avec dig le 21 octobre 2026, les vrais serveurs répondent ainsi : la racine renvoie vers les treize serveurs de .com, une liste valable 172 800 secondes, soit deux jours ; le serveur de .com renvoie vers ceux d'example.com, aussi pour deux jours ; et le serveur du site donne l'adresse avec un TTL de 300 secondes, cinq minutes.

Un résolveur vient de résoudre le nom. Dix minutes plus tard, tu rouvres la page : combien de serveurs du monde doit-il interroger ? Choisis un délai dans la figure pour redessiner l'échange, et parie sur ce que répond la racine avant qu'elle ne le fasse.

Dix secondes plus tard, aucun serveur n'est interrogé : le résolveur répond de mémoire. Dix minutes plus tard, un seul : la réponse de 300 secondes a expiré, mais il se souvient encore de qui gère .com et example.com, et va droit au serveur du site. Trois jours plus tard, tout recommence. Le piège de la racine, c'est qu'elle ne donne jamais l'adresse : elle renvoie, et le travail se fait en suivant les renvois. Deux durées de vie différentes expliquent aussi pourquoi on dit qu'un changement de DNS « se propage » : rien ne voyage, ce sont des caches qui expirent chacun à son heure.

Se connecter : la distance, puis TCP et TLS

Le prix de la distance

Avec l'adresse, le navigateur ouvre une connexion TCP : un canal fiable, qui remet les données dans l'ordre et renvoie ce qui se perd. Ouvrir ce canal demande un aller-retour (« je veux me connecter », « d'accord »). Et chaque aller-retour a un coût incompressible : la lumière dans la fibre parcourt environ 200 000 km par seconde, soit 1 ms pour 200 km, et il faut faire le trajet dans les deux sens. Entre Paris et Sydney, environ 17 000 km à vol d'oiseau, un aller-retour coûte donc au moins 170 ms ; les vrais câbles font des détours, et c'est encore plus.

Le même article, la même connexion (TLS 1.2, rien en cache). Hébergé près de Paris, il met 71 ms avant son premier octet. Hébergé à Sydney, combien de millisecondes de plus ? Parie, puis éloigne le serveur et retire des allers-retours pour voir lesquels pèsent le plus.

Quatre allers-retours à 170 ms : environ 680 ms de plus, alors que le serveur de Sydney travaille aussi vite que celui de Paris. Un serveur deux fois plus rapide n'y changerait presque rien. Dans la figure, « Connexion déjà ouverte » supprime d'un coup le DNS, TCP et TLS : c'est pourquoi les navigateurs gardent leurs connexions ouvertes, et que HTTP/2 fait passer toutes les requêtes d'une page par une seule connexion.

D'où trois habitudes du web rapide :

• rapprocher le contenu : un CDN (Content Delivery Network) garde des copies des fichiers dans des centres de données partout dans le monde, à quelques millisecondes des visiteurs ;
• réutiliser les connexions : une fois ouverte, une connexion sert pour toutes les requêtes suivantes ;
• supprimer des allers-retours : TLS 1.3 en économise un, et HTTP/3 fusionne l'ouverture de connexion et le chiffrement. Il est déjà utilisé par 41,1 % des sites (W3Techs, octobre 2026).

Le débit (combien de données par seconde) et la latence (combien de temps pour un aller-retour) sont deux choses différentes. Une meilleure connexion augmente le débit ; elle ne rapproche pas Sydney.

Chiffrer : TLS 1.2 et TLS 1.3

TCP donne un canal fiable, pas un canal privé : tout ce qui y passe est lisible par chaque machine du chemin, le Wi-Fi du café comme le fournisseur d'accès. TLS chiffre le canal. Le serveur présente un certificat, signé par une autorité que le navigateur connaît, qui prouve qu'il détient bien ce nom de domaine ; puis les deux côtés s'accordent sur des clés de session, sans jamais les faire voyager. C'est le cadenas. Les certificats ont une durée de vie courte, et elle raccourcit : 90 jours chez Let's Encrypt au 21 octobre 2026, 45 jours d'ici février 2028. On les renouvelle donc automatiquement (voir Le serveur expliqué).

La poignée de main n'a pas la même forme en TLS 1.2 et en TLS 1.3. Relevés avec openssl s_client -msg sur un vrai serveur le 21 octobre 2026, les messages sont les suivants. En 1.2, le client envoie un ClientHello, le serveur répond par ServerHello, Certificate, ServerKeyExchange et ServerHelloDone, puis le client envoie ses clés et son Finished, et le serveur termine par le sien : deux allers-retours. En 1.3, le ClientHello contient déjà la moitié de l'échange de clés, le serveur répond par son ServerHello et, déjà chiffrés, son certificat et son Finished, puis le client envoie son Finished avec la requête : un seul aller-retour.

Voici les deux diagrammes, A et B, sans leurs noms. Trait plein : le message est lisible par quiconque écoute le câble ; pointillé : il est chiffré. Dans lequel le certificat du site voyage-t-il en clair ? Parie, puis compare une première visite et un retour sur le site.

Dans A, qui est TLS 1.2, le certificat part en clair, avant que le chiffrement n'existe : quelqu'un qui écoute le câble lit à quel site tu parles. En TLS 1.3, le certificat est déjà chiffré, et il manque un aller-retour entier. Quand tu reviens sur un site, la session est reprise grâce à un billet : plus de certificat, et TLS 1.3 peut même glisser la requête dans le tout premier message (0-RTT). Le prix : un attaquant peut copier cet envoi et le rejouer, si bien qu'on le réserve aux requêtes qui ne changent rien, comme une lecture. Une chose reste visible dans les deux versions : le nom du site, dans le ClientHello (le SNI). Seule l'extension ECH (RFC 9849, mars 2026) permet de le chiffrer aussi, si le serveur et le navigateur la gèrent.

La requête et la réponse HTTP

La connexion ouverte, le navigateur envoie une requête HTTP : une méthode, un chemin, des en-têtes.

GET /articles/42?page=2 HTTP/1.1
Host: www.example.com
Accept: text/html
Cookie: session=7f3a…

Le serveur répond par un code de statut, des en-têtes, puis le contenu :

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
ETag: "a1b2c3"

<!doctype html>…

Les méthodes disent l'intention : GET pour lire, POST pour envoyer, PUT ou PATCH pour modifier, DELETE pour supprimer. HTTP est sans état : chaque requête est indépendante, le serveur ne se souvient de rien. Ce sont les cookies, renvoyés avec chaque requête, qui portent la session. HTTP/2 et HTTP/3 envoient les mêmes informations sous une forme binaire, plus compacte, mais le sens est identique.

Les codes se lisent par centaine :

• 2xx, succès : 200 OK, 201 Created ;
• 3xx, redirection : 301 (déplacé pour toujours), 304 (pas modifié : garde ta copie) ;
• 4xx, la requête est en cause : 400 (mal formée), 401 (non authentifié), 403 (interdit), 404 (introuvable), 429 (trop de requêtes) ;
• 5xx, le serveur a échoué : 500 (erreur interne), 502 (un serveur intermédiaire n'a pas obtenu de réponse valide), 503 (service indisponible ou surchargé).

Voici huit réponses de serveur, à classer par famille. Quatre d'entre elles font hésiter : 201, 304, 429 et 502. Lesquelles te surprendront ?

Le chiffre des centaines suffit presque toujours à savoir de quel côté se trouve le problème. Les pièges le confirment : 304 est une redirection qui renvoie vers ta propre copie, 429 blâme le rythme de la requête alors que le serveur va bien, 502 vient d'un intermédiaire et non de ta requête. La conduite en découle. On ne réessaie pas une 4xx telle quelle, elle ne passera pas davantage. Une 5xx peut passer plus tard, avec un délai qui s'allonge, en respectant Retry-After quand le serveur le donne. Et on ne rejoue jamais à l'aveugle une requête qui crée quelque chose (voir Les API backend).

Afficher la page

Le navigateur lit le HTML au fur et à mesure. Il y découvre d'autres ressources : feuilles de style, scripts, images, polices. Chacune est une nouvelle requête, souvent sur la même connexion. Il construit l'arbre de la page (le DOM), lui applique les styles, calcule la place de chaque élément, puis le dessine. Les scripts peuvent ensuite tout modifier (voir Le frontend).

Une page ordinaire, c'est des dizaines de requêtes, et l'onglet Réseau les montre en cascade. Question avant de toucher quoi que ce soit : pour la toute première requête vers un site, dans quel ordre le navigateur fait-il les étapes ?

La cascade se lit de gauche à droite. Seule la première requête vers un domaine paie le DNS, la connexion TCP et le chiffrement TLS ; les suivantes réutilisent la connexion ouverte. La feuille de style bloque l'affichage tant qu'elle n'est pas arrivée, et une police découverte tard dans le CSS ajoute une marche à l'escalier. preconnect ouvre une connexion plus tôt, quand on sait qu'on en aura besoin.

Le cache : l'aller-retour le plus rapide est celui qu'on ne fait pas

Le navigateur garde des copies des fichiers. L'en-tête Cache-Control de chaque réponse lui dit combien de temps une copie reste bonne, et s'il doit la revérifier. Quatre réglages couvrent l'essentiel :

• no-store : ne rien garder (données sensibles) ;
• max-age=N : la copie est bonne N secondes, sans rien demander, au risque de servir une version dépassée ;
• no-cache : garder, mais revérifier à chaque fois ; avec un ETag (une empreinte du contenu), le serveur répond 304 sans rien renvoyer si rien n'a changé ;
• un nom versionné et immutable : le nom change avec le contenu, la copie se garde un an. La page HTML, elle, reste en no-cache pour pointer toujours vers les bons noms.

À 11 h 30, on met en ligne une nouvelle version du script. Avec une heure de fraîcheur, que voit la visite de 11 h 40 ? Et avec un nom versionné ? Règle le panneau A sur « Une heure » et le panneau B sur « Nom versionné », puis essaie les autres réglages.

Avec une heure de fraîcheur, la copie vérifiée à 11 h est jugée bonne jusqu'à midi : à 11 h 40, le navigateur ne demande rien et affiche l'ancienne version, sans le savoir. Le nom versionné évite ce piège sans rien coûter : la page, revérifiée à chaque visite, pointe vers un nouveau nom, et le fichier est téléchargé une seule fois. no-cache ne veut pas dire « pas de cache » : c'est no-store qui interdit de garder une copie.

Ce qu'on oublie souvent

• Le fragment ne part pas, mais les paramètres, si. Tout ce qui suit ? voyage dans l'adresse, reste dans les journaux et dans l'historique : on n'y met jamais un secret.
• localhost, c'est ta machine. L'adresse 127.0.0.1 ne sort jamais de l'ordinateur : « ça marche chez moi » ne dit rien du serveur.
• Le cadenas ne dit pas que le site est honnête. Il dit qu'on parle en privé au détenteur du nom. Un site d'hameçonnage peut avoir un certificat valide.
• Une redirection coûte un trajet de plus. http:// vers https://, puis sans www vers www : chaque 301 refait un aller-retour, parfois une connexion.
• Un changement de DNS ne se propage pas. Des caches expirent, chacun à son heure ; on baisse le TTL avant une migration, pas pendant.
• On ne réessaie pas une erreur 4xx. Elle ne passera pas telle quelle ; une 5xx, peut-être plus tard.

Teste-toi

Quelques questions sur les idées qu'on vient de croiser. La raison s'affiche après chaque réponse : c'est elle qui compte.

Le vocabulaire en un coup d'œil

Ce qu'il faut retenir

• Une URL devient une adresse IP grâce au DNS, puis une connexion TCP chiffrée par TLS, puis une requête HTTP.
• De l'URL, le serveur ne reçoit que l'hôte, le chemin et les paramètres : le fragment reste dans le navigateur.
• Chaque aller-retour coûte au moins la distance divisée par la vitesse de la lumière dans la fibre : de loin, c'est la route qui domine, pas le serveur.
• On gagne du temps en rapprochant le contenu (CDN), en réutilisant les connexions et en supprimant des allers-retours (TLS 1.3, HTTP/3).
• Les codes se lisent par centaine : 2xx ok, 3xx ailleurs, 4xx ta requête, 5xx le serveur.
• Le meilleur cache : des fichiers à nom versionné, gardés un an, et une page HTML revérifiée à chaque visite.

Pour aller plus loin

• Grigorik (2013), High Performance Browser Networking, O'Reilly, en accès libre : latence, TCP, TLS, HTTP, mesures à l'appui (consulté le 21 octobre 2026).
• MDN, An overview of HTTP et HTTP caching (consultés le 21 octobre 2026).
• IETF, RFC 9110 : HTTP Semantics (méthodes, en-têtes, codes de statut) et RFC 9111 : HTTP Caching, puis RFC 6585 pour le code 429.
• IETF, RFC 8446 : TLS 1.3 (août 2018), dont la section 2.3 sur le 0-RTT, et Cloudflare, A Detailed Look at RFC 8446 : pourquoi TLS 1.3 économise un aller-retour.
• IETF, RFC 9849 : TLS Encrypted Client Hello (mars 2026) : chiffrer aussi le nom du site.
• Root Server Technical Operations Association, root-servers.org : 13 identités, 12 opérateurs et 2 047 instances au 21 octobre 2026.
• Let's Encrypt, Certificate Lifetimes : 90 jours aujourd'hui, 45 jours d'ici février 2028 (consulté le 21 octobre 2026).
• W3Techs, Usage statistics of HTTP/3 : 41,1 % des sites en octobre 2026 (consulté le 21 octobre 2026).
• WHATWG, URL Standard : la lecture d'une adresse que fait la figure de la première section.