Ce qui se passe vraiment quand vous tapez une URL et appuyez sur Entrée

Pourquoi c'est LA question

"Que se passe-t-il quand vous tapez une URL et appuyez sur Entrée" est l'une des questions les plus posées en entretien technique, et pas par hasard — une réponse vraiment complète touche au DNS, au TCP, au TLS, au HTTP et au rendu, ce qui veut dire que c'est en fait cinq petits sujets déguisés en un seul. La plupart des explications en sautent la moitié ou noient le lecteur sous des noms de protocoles sans jamais expliquer à quoi ils servent. Voici la version qui essaie de ne faire ni l'un ni l'autre.

Étape 1 : transformer un nom en adresse

Une URL comme https://exemple.com contient un nom de domaine, pas un emplacement vers lequel un ordinateur peut réellement router des paquets — pour ça, il faut une adresse IP. La toute première chose qui se passe est donc une résolution DNS : votre ordinateur demande à un résolveur DNS "quelle est l'adresse IP de exemple.com ?" Ce résolveur ne connaît presque jamais la réponse par cœur non plus ; il interroge une chaîne d'autres serveurs DNS (les serveurs racine, puis les serveurs responsables du .com, puis les serveurs que exemple.com désigne lui-même comme faisant autorité) jusqu'à ce que l'un d'eux réponde avec une vraie adresse IP, quelque chose comme 93.184.216.34. Toute cette recherche est généralement invisible et rapide, en partie parce que les réponses DNS sont mises en cache — par votre navigateur, votre système d'exploitation, et souvent votre routeur — donc cette chaîne complète ne tourne vraiment que la première fois, et les réponses en cache sont réutilisées jusqu'à leur expiration.

Étape 2 : ouvrir une vraie connexion

Une fois l'adresse IP en main, votre ordinateur ouvre une connexion TCP vers le serveur à cette adresse, sur le port 443 pour HTTPS (ou 80 pour du HTTP simple). C'est la "poignée de main en trois temps" : votre ordinateur envoie un paquet SYN, le serveur répond par SYN-ACK, votre ordinateur répond par ACK, et c'est seulement à ce moment-là que les deux parties considèrent réellement la connexion comme ouverte. Cette poignée de main existe pour que chaque côté puisse confirmer que l'autre est vraiment là et prêt, avant de s'engager à envoyer de vraies données — c'est l'équivalent réseau du "tu m'entends ?" / "oui, et toi tu m'entends ?" / "oui" avant qu'un appel téléphonique ne commence vraiment.

Étape 3 : rendre la connexion privée (TLS)

Si l'URL commence par https://, il reste une étape avant que du contenu web ne circule réellement : la poignée de main TLS. C'est là que votre navigateur et le serveur se mettent d'accord sur une méthode de chiffrement et échangent les clés cryptographiques nécessaires pour chiffrer tout ce qui suit, et — c'est crucial — c'est là que votre navigateur vérifie le certificat du serveur pour confirmer qu'il parle vraiment au véritable exemple.com et non à quelque chose qui usurpe son identité. C'est le petit cadenas dans la barre d'adresse. Sautez cette étape (http:// tout court) et tout ce qui est envoyé ensuite, y compris n'importe quel mot de passe tapé dans un formulaire de cette page, circule en texte clair que n'importe qui positionné entre vous et le serveur peut lire.

Étape 4 : la requête et la réponse elles-mêmes

Ce n'est qu'à ce moment que le navigateur envoie une requête HTTP — un message en texte clair qui dit, en substance, "envoie-moi la page à ce chemin, et voici quelques informations sur mon navigateur et ce que j'accepte." Le serveur traite cette requête (ce qui peut vouloir dire lire un fichier statique, ou exécuter du code applicatif qui interroge une base de données et assemble une page à la volée) et renvoie une réponse HTTP : un code de statut (200 pour un succès, 404 pour "non trouvé", 500 pour une erreur serveur, et des dizaines d'autres), un ensemble d'en-têtes décrivant la réponse, et — généralement — un corps contenant le HTML lui-même.

Étape 5 : transformer le HTML en ce que vous voyez

Le navigateur n'affiche pas simplement du texte HTML brut ; il l'analyse pour en faire un arbre structuré (le DOM), et à mesure qu'il rencontre des références à des fichiers CSS, JavaScript et des images dans ce HTML, il déclenche d'autres requêtes — chacune pouvant repasser par sa propre résolution DNS, sa propre poignée de main TCP et sa propre poignée de main TLS si elle pointe vers un domaine différent, ce qui explique exactement pourquoi une page chargeant des ressources depuis six domaines tiers différents peut sembler nettement plus lente qu'une page qui ne le fait pas. Une fois le CSS analysé et appliqué au DOM, le navigateur peut calculer la mise en page visuelle réelle et commencer à peindre des pixels à l'écran. Le JavaScript peut s'exécuter à divers moments de ce processus et modifier encore la page — récupérer plus de données, changer ce qui est affiché, attacher les gestionnaires d'événements qui font que les boutons et formulaires font vraiment quelque chose quand on interagit avec eux.

Pourquoi les parties "ennuyeuses" sont celles qui valent la peine d'être comprises

Aucune de ces cinq étapes n'est exotique — DNS, TCP, TLS et HTTP sont des protocoles vieux de plusieurs décennies, extrêmement bien documentés, pas des astuces propriétaires ingénieuses. C'est exactement ce qui rend cette question si utile à vraiment comprendre plutôt qu'à mémoriser : une fois qu'on sait qu'un chargement de page lent peut venir d'une résolution DNS lente, d'une poignée de main TCP lente vers un serveur à l'autre bout de la planète, d'un serveur lent à générer la réponse, ou d'un navigateur lent à rendre une page trop chargée, on a cinq hypothèses distinctes et vérifiables au lieu d'une vague impression que "internet est lent aujourd'hui" — et c'est toute la différence entre deviner un correctif et en trouver un vraiment.