Anthony, Engineering Lead, vingt ans de code. Autodidacte : de l'usine au cybercafé, jusqu'aux systèmes que tu utilises tous les jours.


Anthony Capirchio


Un utilisateur te signale un bug. Tu vérifies : tu l'as corrigé la semaine dernière, c'est en production, ça marche chez toi et chez tout le monde que tu testes. L'utilisateur, lui, insiste, ça ne marche pas. Tu finis par lâcher la phrase magique : « fais Ctrl+Shift+R. » Et là, le bug disparaît d'un coup.

Son navigateur servait un fichier JavaScript vieux de plusieurs semaines. Pas par erreur : parce qu'un en-tête, que tu avais posé et oublié, lui disait de le garder longtemps sans rien revérifier. Tu avais corrigé le code. Son navigateur n'avait simplement jamais redemandé la nouvelle version.

## Avant tout le reste, le navigateur se demande s'il a déjà

Tout ce qu'on a vu jusqu'ici, la résolution DNS, la poignée de main, le cadenas, la requête, ça coûte du temps. Alors avant de s'y lancer, le navigateur pose une question plus radicale : est-ce que je n'ai pas déjà ça sous la main ? C'est la première étape, avant même de traduire le nom en adresse.

S'il a une copie qu'il juge encore fraîche, il l'utilise sans contacter personne. Pas de DNS, pas de connexion, pas de requête. C'est ce qui rend une page déjà visitée quasi instantanée. Cette fraîcheur, c'est toi qui la fixes, via un en-tête, `Cache-Control`, où tu écris en substance « garde ce fichier pendant tant de temps ». Tant que ce délai n'est pas écoulé, le navigateur ne redemande rien : il te sert sa copie, point.

Quand le délai expire, il ne repart pas forcément de zéro. Il peut faire une vérification à moindre coût : « j'ai cette version, identifiée par cette étiquette (un ETag), est-elle toujours d'actualité ? » Le serveur répond soit « rien n'a changé, garde la tienne », une réponse minuscule et rapide, soit il renvoie la nouvelle. Le cache a donc deux régimes : ne même pas demander, ou demander mais pour pas cher.

## Le piège est dans l'en-tête que tu oublies

Tout se joue dans ce délai que tu poses une fois. Mets un `Cache-Control` long sur un fichier qui ne change jamais, une image, une police : parfait, tes utilisateurs ne le retéléchargent plus. Mets le même délai long sur un fichier qui change, comme le JavaScript de ton application, et tes utilisateurs gardent l'ancienne version aussi longtemps que tu le leur as dit, même après que tu as déployé le correctif. Voilà pourquoi ton bug « corrigé » continue de vivre chez eux : le navigateur obéit à un ordre que tu lui as donné et oublié.

La parade classique tient en une astuce : mettre une empreinte dans le nom du fichier, `app.a3f9.js`. Change le code, l'empreinte change, donc le nom change, donc c'est une URL que le cache n'a jamais vue : il est obligé d'aller la chercher. Tu ne te bats plus contre le cache, tu le contournes proprement.

## Ce que l'IA ne reproduira pas

Le cache est invisible jusqu'au jour où il mord, et il mord toujours de la pire façon : un bug que tu ne reproduis pas. Chez toi tout va bien, la trace d'erreur ne dit rien, parce que le problème n'est pas dans le code. Il est dans un en-tête et dans la mémoire d'un navigateur qui n'est pas le tien. L'IA te génère l'application, pas ta stratégie de cache, et ce « ça marche chez moi pas chez lui » est exactement le genre de fantôme qu'aucune génération ne t'expliquera. Comprendre le cache, c'est ce qui transforme un spectre impossible à reproduire en un correctif d'une ligne.

## Ce que je te conseille

Mets en cache sans retenue ce qui ne change jamais, à condition de lui donner un nom qui change quand son contenu change. Sois prudent avec ce qui bouge : délai court, ou revalidation. Et quand un utilisateur te décrit un bug que tu sais mort et enterré, soupçonne le cache avant de douter de toi-même. Le DNS te mentait sur l'adresse du serveur. Le cache, lui, te ment sur la version du fichier, et c'est un mensonge que tu as toi-même autorisé.

Un navigateur optimise la vitesse en pariant que ce qu'il a déjà est encore bon. La plupart du temps, il gagne son pari. Ton travail, c'est de savoir exactement quand tu lui as donné le droit d'avoir tort.

Ce satellite ouvre le dossier [Navigateur](/dossier/browser) : c'est la toute première chose que fait un navigateur, avant [la résolution DNS](/blog/dns-le-premier-mensonge-du-web). Le vocabulaire : le [cache HTTP](/definition/cache-http), le [Cache-Control](/definition/cache-control), l'[ETag](/definition/etag) et la [revalidation](/definition/revalidation).


Un utilisateur signale un bug. Tu l'as corrigé la semaine dernière, c'est déployé, ça marche chez toi. Un « vide ton cache » plus tard, le bug disparaît. Avant même de contacter le serveur, ton navigateur se demande s'il a déjà la réponse, et il a le droit de te resservir une version périmée.

Le bug que j'avais déjà corrigé


Une page qu'on trouve lente. On accuse le back, la base, le réseau, on part optimiser des requêtes SQL. Sauf que le serveur, mesures en main, répond en vingt millisecondes. La page part instantanément. Et pourtant, l'utilisateur reste devant un écran blanc pendant deux bonnes secondes avant que quoi que ce soit n'apparaisse.

Le goulot d'étranglement n'était pas d'obtenir la page. C'était de la dessiner. Un script placé tout en haut bloquait tout le reste, et rien ne pouvait s'afficher tant qu'il n'était pas téléchargé et exécuté. Le réseau était rapide. Le rendu, lui, était à l'arrêt.

## Recevoir une page n'est pas l'afficher

Quand la réponse HTTP arrive, le navigateur ne « montre » pas le HTML. Il le construit. Il lit le HTML et en fait le DOM, un arbre de tous les éléments de la page. Il lit le CSS et en fait le CSSOM, l'arbre des styles. Il combine les deux, calcule la mise en page (où va chaque chose, à quelle taille), puis peint : il remplit enfin les pixels. Recevoir, construire l'arbre, calculer, peindre. Le premier pixel n'apparaît qu'au bout de cette chaîne, pas à la réception.

Et cette chaîne, le JavaScript peut la figer net. Un `<script>` classique posé dans le `<head>` arrête le navigateur en pleine construction : il ne parse plus, il ne peint plus, il attend que le script soit téléchargé et exécuté. Pourquoi ? Parce qu'un script a le droit de réécrire la page, alors le navigateur n'ose rien afficher qui pourrait être effacé la seconde d'après. C'est ce qu'on appelle un script bloquant. Un réseau parfait plus un script mal placé, et tu obtiens ta page blanche.

## Le DOM n'est pas gratuit à toucher

Le DOM n'est pas qu'une étape de départ, c'est aussi ce que ton JavaScript manipule ensuite pour rendre la page vivante. Sauf que chaque fois que tu le modifies, le navigateur peut devoir recalculer la mise en page et repeindre. Touche le DOM une fois, c'est indolore. Touche-le cent fois dans une boucle, et tu déclenches cent recalculs : la page rame, saccade, alors que ton serveur, lui, n'a rien à se reprocher. Le coût est passé du réseau à l'écran, et on continue de chercher au mauvais endroit.

## Ce que l'IA ne voit pas dans ton composant

L'assistant te génère un composant impeccable, qui compile et qui marche. Ce qu'il ne te dit pas, c'est où ce composant bloque le premier affichage, pourquoi la mise en page sautille au chargement, ou pourquoi une interaction saccade. Ça ne se lit pas dans le code, ça se lit dans la façon dont le navigateur l'exécute, sous la couche que la génération manipule. Réparer une page lente au serveur rapide, c'est comprendre le chemin de rendu, et ce chemin, aucune complétion ne le commente pour toi. La performance perçue vit en dessous du code généré.

## Ce que je te conseille

Quand une page te paraît lente, mesure d'abord où : le temps de réponse du serveur et le temps jusqu'au premier pixel sont deux chiffres différents, et ils n'accusent pas le même coupable. Ne laisse pas un script bloquer ton premier affichage, repousse-le avec `defer` ou en bas de page. Et touche le DOM avec parcimonie : regroupe tes modifications au lieu de les distiller dans une boucle.

Un utilisateur ne mesure pas la vitesse de ton serveur. Il mesure le temps qu'il passe devant du blanc. Ce sont rarement les mêmes millisecondes.

Ce satellite fait partie du dossier [Navigateur](/dossier/browser). Juste avant lui, la demande de la ressource : [Le bug était dans l'enveloppe](/blog/requete-http). Le vocabulaire : le [DOM](/definition/dom), le [CSSOM](/definition/cssom), le [script bloquant](/definition/script-bloquant) et le [chemin de rendu critique](/definition/chemin-de-rendu-critique).


Une page lente. Tout le monde accuse le back, le réseau. Sauf que le serveur répond en 20 ms et l'utilisateur fixe du blanc pendant deux secondes. Le goulot n'était pas d'obtenir la page, mais de la dessiner. Ce que fait vraiment un navigateur entre la réponse et le premier pixel.

Le serveur répondait en 20 ms, l'écran restait blanc


L'appel échoue. Tout le monde décrète que le serveur est cassé, que l'API est en rade. On rejoue la requête à la main, dans un outil à part : elle passe. Dans l'application : elle échoue. Même URL, mêmes données envoyées. Pendant une heure, on relit le code qui construit le corps de la requête, ligne par ligne, sans rien trouver.

Le coupable n'était pas dans le contenu. Il était dans l'enveloppe. Un en-tête, `Content-Type`, annonçait du texte brut alors qu'on envoyait du JSON. Le serveur, très correctement, refusait de lire une lettre dont l'enveloppe mentait sur le contenu. On relisait la lettre. Le problème était sur l'enveloppe.

## Une requête, c'est trois choses

On réduit souvent une requête HTTP à une URL. Elle en contient bien plus, et c'est cette ignorance qui coûte des heures.

Une requête, c'est d'abord une ligne : un verbe et une cible. `GET /utilisateurs`, `POST /commandes`. Le verbe dit l'intention, la cible dit sur quoi. C'est ensuite un paquet d'en-têtes, et c'est là que se joue l'essentiel : qui tu es (`Authorization`), ce que tu envoies (`Content-Type`), ce que tu sais recevoir (`Accept`), tes cookies, ta langue. Les en-têtes, ce sont les métadonnées qui disent au serveur comment lire tout le reste. C'est enfin, parfois, un corps : la charge utile, le JSON que tu poses dans un `POST`.

La réponse a exactement la même anatomie : un code de statut qui résume le sort de la demande, ses propres en-têtes, son propre corps. Et le drame se répète à chaque fois : on regarde le verbe, l'URL et le corps, et on oublie les en-têtes, précisément là où vit le contrat silencieux entre le client et le serveur.

## Le verbe n'est pas décoratif

Le choix du verbe non plus n'est pas anodin. `GET` lit, sans rien changer : c'est une demande sûre, qu'on peut rejouer, mettre en cache, relancer sans risque. `POST` crée ou modifie : le rejouer, c'est risquer de commander deux fois. Toute une machinerie invisible, les caches, les proxys, les mécanismes de nouvelle tentative, fait confiance à cette distinction. Utilise un `GET` pour une action qui modifie, et un jour un cache te resservira un vieux résultat, ou un navigateur rejouera l'action tout seul. Le verbe n'est pas une étiquette, c'est une promesse sur laquelle d'autres comptent.

## Ce que l'IA remplit, et ce qu'elle ignore

L'assistant t'écrit l'appel réseau en une ligne, et il remplit les en-têtes courants sans que tu y penses. Utile. Mais l'en-tête qui compte vraiment, c'est celui qui est propre à ton API : le schéma d'authentification maison, le `Content-Type` exact qu'elle exige, l'en-tête de version qu'elle réclame. Ça, c'est le contrat de ton domaine, il n'est écrit nulle part dans le code générique, et la machine ne peut pas l'inventer. Et le jour où la requête échoue, lire ce qui cloche, c'est lire les en-têtes un par un, ce qu'aucune génération ne commente pour toi. L'enveloppe, c'est là que l'humain débogue encore.

## Ce que je te conseille

Quand une requête échoue, ne compare pas seulement l'URL et le corps entre le cas qui marche et celui qui casse : compare la requête entière, en-têtes compris. Neuf fois sur dix, la différence est dans l'enveloppe que personne ne regarde. Et choisis ton verbe pour ce qu'il signifie, pas par habitude : `GET` lit, `POST` change, parce que tout l'écosystème autour te croit sur parole.

Une requête ne se résume pas à ce que tu demandes. C'est aussi la façon dont tu le demandes, et cette façon, le serveur la lit avant tout le reste.

Ce satellite fait partie du dossier [Navigateur](/dossier/browser). Juste avant lui, la connexion sécurisée : [Le cadenas a une date de péremption](/blog/tls-le-cadenas). Le vocabulaire : la [requête HTTP](/definition/requete-http), l'[en-tête HTTP](/definition/en-tete-http), la [méthode HTTP](/definition/methode-http), le [corps de requête](/definition/corps-de-requete) et le [code de statut HTTP](/definition/code-statut-http).


« Le serveur est cassé. » Non : la requête est partie avec la bonne adresse, le bon contenu, mais la mauvaise enveloppe. Une requête HTTP, ce n'est pas qu'une URL et des données. C'est une lettre dont l'en-tête dit tout, et que personne ne relit jamais.

Le bug était dans l'enveloppe


Un site parfaitement en ligne à 23h59, hors service à 00h00. Aucun déploiement, aucune modification de code, personne n'a touché à rien. Et pourtant, tous les visiteurs tombent d'un coup sur un écran rouge pleine page : « Votre connexion n'est pas privée. » Le genre de message qui fait fuir un utilisateur en une seconde.

Rien n'était cassé. Une date, simplement, était passée. Le certificat TLS du site avait expiré à minuit, et le navigateur a fait ce pour quoi il est programmé : il a claqué la porte.

Le cadenas dans la barre d'adresse, on le prend pour un décor. C'est en réalité une échéance que tu portes, et une promesse plus étroite que tu ne crois.

## Ce que le cadenas règle vraiment

Une fois la connexion ouverte par TCP, ton navigateur ne se met pas à parler en clair. Il sécurise d'abord l'échange avec TLS, et ça répond à deux questions distinctes.

La première : est-ce que le serveur en face est vraiment celui qu'il prétend être ? On ne va pas envoyer un mot de passe à un inconnu qui se fait passer pour ta banque. C'est le rôle du certificat : un document signé par une autorité de certification, un tiers de confiance que ton navigateur connaît d'avance. Le serveur présente son certificat, le navigateur vérifie la signature, et si elle tient, l'identité est prouvée.

La seconde : comment parler sans que personne au milieu ne puisse lire ? C'est le rôle du handshake TLS, qui suit celui de TCP. Les deux camps s'y mettent d'accord sur des clés de chiffrement, en quelques allers-retours, de façon à ce que même quelqu'un qui intercepte tout ne voie qu'une bouillie illisible. Le cadenas fermé, c'est ces deux choses réunies : une identité vérifiée, et un tuyau chiffré.

## Trois façons dont le cadenas claque

Et comme pour TCP, savoir lire l'échec vaut mieux que paniquer.

Le certificat expiré, celui de mon histoire : il était valide, il ne l'est plus. Les certificats ont une date de péremption exprès, pour limiter les dégâts si l'un est volé et forcer un renouvellement régulier. Sauf que cette date, c'est une échéance que tu possèdes, et que le navigateur applique sans pitié. Le certificat pour le mauvais domaine : il est valide, mais émis pour `exemple.com` alors que tu es sur `www.exemple.com`. L'identité ne correspond pas, le navigateur refuse. L'autorité inconnue, enfin : le certificat est signé par quelqu'un que ton navigateur ne connaît pas, souvent parce qu'il est auto-signé. Techniquement chiffré, mais personne ne se porte garant de l'identité.

Trois écrans rouges qui se ressemblent, trois causes, trois correctifs différents.

## Ce que l'IA ne te dira pas sur le cadenas

Tu n'écriras jamais un handshake TLS : l'infra et les bibliothèques s'en chargent, l'IA te configure le HTTPS en quelques lignes. Parfait, tant que le vert reste vert. Mais deux choses restent à toi. Lire l'écran rouge, d'abord : expiré, mauvais domaine ou autorité inconnue ne se réparent pas pareil, et aucune génération ne fera ce diagnostic à ta place le jour de la panne. Comprendre la promesse, ensuite. Le cadenas prouve que le tuyau est privé et que le serveur est bien celui qu'il annonce. Il ne prouve pas que ce serveur est honnête. Un site de phishing peut afficher un cadenas parfaitement valide : il est vraiment `paypa1-secure.com`, chiffré et tout. Confondre « connexion sécurisée » et « site de confiance », c'est le piège que la machine ne t'évitera pas.

## Ce que je te conseille

Traite l'expiration de tes certificats comme ce qu'elle est : une date dans un calendrier, donc une alerte à automatiser. Un certificat qui expire ne prévient pas, il tombe. Devant un écran rouge, lis la cause avant de tout redémarrer. Et rappelle-toi ce que le cadenas dit et ne dit pas : il sécurise le chemin, il ne garantit pas la destination.

Une connexion chiffrée vers un menteur reste une conversation avec un menteur. Le cadenas protège tes mots, pas ton jugement.

Ce satellite fait partie du dossier [Navigateur](/dossier/browser). Juste avant lui, l'ouverture de la connexion : [Trois paquets avant de se parler](/blog/handshake-tcp). Le vocabulaire : le [TLS](/definition/tls), le [certificat](/definition/certificat), le [handshake TLS](/definition/handshake-tls) et le [chiffrement](/definition/chiffrement).


Un site qui tombe à minuit sans le moindre déploiement, tous les visiteurs face à un écran rouge « connexion non privée ». Le coupable n'est pas ton code : c'est un certificat TLS qui a expiré. Ce que le cadenas promet vraiment, et les trois façons dont il claque la porte.

Le cadenas a une date de péremption


Une requête qui ne répond pas. Pas une erreur, pas un refus : rien. L'écran tourne, tu attends. Au bout de trente secondes très précises, un timeout, et c'est tout. Le serveur n'a jamais dit non. Il n'a jamais rien dit du tout.

Ce genre de silence est le pire des symptômes, parce qu'il ne t'apprend rien. Un 404 t'oriente, un 500 t'oriente, même un « connexion refusée » t'oriente. Là, tu n'as que le vide. Et le vide, neuf fois sur dix, veut dire une seule chose : la conversation n'a jamais commencé. La poignée de main a échoué.

Avant qu'un navigateur puisse demander quoi que ce soit à un serveur, il faut que les deux se mettent d'accord sur un point idiot mais fondamental : est-ce qu'on s'entend ? Pas « est-ce que tu as la page », juste « est-ce que mes mots t'arrivent, et est-ce que les tiens m'arrivent ». Tant que ce n'est pas établi, personne ne dit rien d'important. C'est le rôle de TCP, et ça se joue en trois paquets.

## La poignée de main en trois temps

Une fois le nom traduit en adresse IP (c'est le travail du DNS, l'étape d'avant), ton navigateur ne se met pas à parler tout de suite. Il ouvre d'abord une connexion, avec un échange en trois temps qu'on appelle le handshake.

Premier paquet, le client au serveur : SYN. En clair, « je voudrais te parler, voici mon numéro de départ. » Deuxième paquet, le serveur au client : SYN-ACK. « Bien reçu, je suis d'accord, et voici le mien. » Troisième paquet, le client au serveur : ACK. « Reçu aussi, on est bons. »

Pourquoi trois, et pas deux ? Parce qu'il ne suffit pas que le client sache que le serveur l'entend. Il faut aussi que le serveur sache que le client l'entend en retour. Chaque camp doit obtenir la preuve que sa voix porte dans les deux sens. Le premier paquet prouve que le client émet, le deuxième que le serveur reçoit et émet, le troisième que le client reçoit. À la fin des trois, et seulement là, la connexion est « établie » : les deux ont la certitude d'être audibles. C'est maintenant, et pas avant, que la vraie requête peut partir.

Ce cérémonial, c'est ce qui sépare TCP de son cousin plus brutal, UDP, celui qu'utilise justement le DNS. UDP envoie et ne vérifie rien : il crie dans le vide et espère. Rapide, sans garantie. TCP prend le temps de la poignée de main parce qu'il promet ce qu'UDP ne promet pas : que ce que tu envoies arrive, dans l'ordre, ou que tu sauras que ça a raté.

## Trois façons d'échouer, trois coupables

Et c'est là que le silence du début devient lisible. Une connexion peut rater de trois manières, et chacune te désigne un coupable différent.

« Connexion refusée », immédiate : le serveur a répondu, mais pour dire non. Personne n'écoute sur ce port. Ta cible existe, mais la porte est fermée. Le silence puis le timeout : ton SYN est parti et aucun SYN-ACK n'est revenu. Personne n'a refusé, personne n'a accepté. La plupart du temps, un pare-feu a mangé ton paquet sans un mot. C'est le cas le plus vicieux, parce qu'il n'y a aucun interlocuteur, juste un mur invisible. La connexion qui tombe en pleine conversation, enfin : un RST, une réinitialisation brutale. L'échange était lancé, et l'autre bout a raccroché au nez sans prévenir.

Savoir lire ces trois-là, c'est transformer un « ça marche pas » inutile en un diagnostic. Le silence n'accuse pas ton code : il accuse le réseau entre toi et le serveur.

## Ce que l'IA n'abstrait pas

Tu ne verras jamais un SYN de ta vie de dev. Les bibliothèques ouvrent la connexion pour toi, l'IA te génère l'appel réseau en une ligne, et c'est très bien : personne ne veut coder un handshake à la main. Mais cette abstraction est parfaite tant que tout marche. Le jour où ça pend trente secondes, aucune bibliothèque, aucune génération ne te dira pourquoi, parce que le pourquoi est en dessous de la couche qu'elles gèrent. Comprendre la poignée de main, c'est exactement ce qui te reste quand l'abstraction lâche. La machine te connecte ; savoir ce que « connecté » signifie, et ce que son échec raconte, c'est encore à toi.

## Ce que je te conseille

La prochaine fois qu'une requête pend sans répondre, ne relis pas ton code en premier. Demande-toi d'abord si la conversation a seulement commencé. Refusée, silence, ou reset : ces trois mots te disent où chercher, et t'évitent de déboguer une heure une application qui, elle, n'a jamais reçu le moindre appel.

Une connexion, ce n'est pas un détail technique sous la requête. C'est la première chose qui peut mentir sur l'état du monde. Apprends à lire ses trois silences.

Ce satellite fait partie du dossier [Navigateur](/dossier/browser), le parcours complet d'une URL. Juste avant lui : [DNS, le premier mensonge du web](/blog/dns-le-premier-mensonge-du-web). Le vocabulaire : le [TCP](/definition/tcp), le [handshake TCP](/definition/handshake-tcp), le [paquet](/definition/paquet), le [port](/definition/port) et l'[UDP](/definition/udp).


Une requête qui ne renvoie ni erreur ni refus, juste du silence pendant trente secondes. Souvent, c'est que la conversation n'a jamais commencé : la poignée de main TCP a échoué. Comment deux machines décident qu'elles peuvent se parler, et pourquoi son échec est le pire des bugs.

Trois paquets avant de se parler


Tu déploies une nouvelle version, tu fais pointer le domaine vers le nouveau serveur, tu rafraîchis : c'est en ligne, ça marche. Trois bureaux plus loin, un collègue ouvre exactement la même URL et tombe sur l'ancienne version, celle que tu viens de remplacer. Même réseau, même navigateur. Toi tu vois la vérité, lui voit un fantôme. Et pendant les heures qui suivent, selon l'endroit d'où on tape ton adresse, on obtiendra l'une ou l'autre, sans logique apparente.

Le coupable n'est pas ton code. C'est le DNS, et la façon dont il t'arrange la vérité.

Quand tu tapes une adresse, tu crois demander au web où se trouve un site, maintenant. Tu ne demandes rien de tel. Tu interroges un empilement de mémoires, dont chacune a le droit de te répondre avec une version un peu périmée, tant qu'un compte à rebours n'est pas écoulé. L'adresse que ton navigateur obtient n'est presque jamais la vérité en direct. C'est la dernière vérité que quelqu'un a pris la peine de retenir. Voilà le premier mensonge du web, et c'est un mensonge organisé.

## L'enquête

Reprenons depuis le début. Tu tapes `exemple.com`. Ton navigateur, lui, ne sait pas parler à un nom : il lui faut une adresse IP, une suite de chiffres, la seule chose qu'une machine sait joindre. Le nom de domaine n'est qu'une politesse pour les humains. Quelqu'un doit donc traduire `exemple.com` en son IP. Cette traduction, c'est la résolution DNS. Et elle ressemble moins à une consultation d'annuaire qu'à un interrogatoire de témoins, où chacun peut te répéter une vieille information au lieu d'aller vérifier.

Premier témoin : ton navigateur lui-même. Il garde un cache de ce qu'il a résolu récemment. S'il a demandé `exemple.com` il y a deux minutes, il ne redemande à personne, il te ressort son souvenir. Premier endroit où l'information peut être périmée sans que tu le saches.

Deuxième témoin : ton système d'exploitation, qui tient son propre cache, juste derrière.

Troisième, le personnage clé : le résolveur. C'est lui qui fait le vrai travail d'enquête à ta place, en général celui de ton fournisseur d'accès, ou un résolveur public. Et lui aussi a un cache, partagé par des milliers d'utilisateurs. S'il a résolu `exemple.com` pour un voisin il y a cinq minutes, il te sert la même réponse sans bouger. C'est très probablement ce qui est arrivé à ton collègue : son résolveur avait encore l'ancienne adresse en mémoire.

Ce n'est que si personne n'a de réponse fraîche que l'enquête remonte à la source. Le résolveur interroge alors un serveur racine, qui ne connaît pas `exemple.com` mais sait qui gère les `.com`. Il redirige vers les serveurs du `.com`, qui ne connaissent pas le site mais savent quel serveur fait autorité sur `exemple.com`. Le résolveur interroge enfin ce serveur d'autorité : la source de vérité, celle qui détient les vrais enregistrements.

Là, il obtient deux choses. Un enregistrement : un A, qui associe le nom à une IP, ou un CNAME, qui dit « ce nom est l'alias d'un autre nom, recommence la traduction avec celui-là ». Et surtout, collé à cette réponse, un nombre : le TTL. « Cette réponse est valable N secondes. »

## Le TTL, ce permis de mentir

Le TTL (time to live) est le cœur de l'affaire. C'est la durée pendant laquelle chaque témoin de la chaîne a le droit de garder la réponse et de te la resservir sans rien vérifier. Un TTL d'une heure, et ton résolveur répétera la même IP pendant une heure à tous ceux qui demandent, même si tu as changé l'adresse à la source entre-temps.

C'est exactement pour ça que ton collègue voyait un fantôme. Tu avais changé l'enregistrement, mais son résolveur tenait encore l'ancienne réponse, valide jusqu'à l'expiration de son TTL. La nouvelle vérité et l'ancienne coexistaient, servies par des caches différents, jusqu'à ce que les comptes à rebours s'éteignent un à un. C'est ce qu'on appelle la propagation DNS, et ce n'en est pas une : c'est une expiration.

La vérité en direct, pour le DNS, n'existe pas. Ce que tu obtiens, c'est une réponse qui était vraie quand un cache est allé la chercher, et qu'on suppose encore vraie tant que son TTL tient. Le système entier repose sur un mensonge borné et assumé. Et c'est une bénédiction : sans ces caches, le moindre clic déclencherait toute l'enquête jusqu'aux serveurs racine, et le web ramperait. Ici, le mensonge est ce qui rend le web rapide.

## Ce que j'écoute vraiment en entretien

Je pose souvent le grand classique : « que se passe-t-il quand tu tapes une URL et appuies sur Entrée ? ». Ce que je n'écoute pas, c'est la récitation. Navigateur, DNS, TCP, HTTP, rendu : tout le monde connaît la liste, et une IA te la déroule mieux que n'importe quel candidat.

Ce que j'écoute, c'est un seul mot : cache. Le candidat qui dit « le navigateur regarde d'abord son cache, le résolveur a le sien, et il y a un TTL sur chaque réponse » ne récite pas des étapes, il a compris un mécanisme. Il sait que la résolution n'est pas une consultation en direct mais une cascade de mémoires, chacune avec le droit d'être en retard. Et celui-là, le jour où la moitié des utilisateurs tombent sur l'ancien serveur à trois heures du matin, saura où regarder pendant que les autres redémarrent l'application au hasard.

C'est ce que l'IA a rendu précieux. La liste des étapes ne vaut plus rien, elle se génère gratuitement. Ce qui vaut, c'est de savoir où le mécanisme te ment, parce que c'est là que vivent les vrais bugs, et ça, aucun résumé ne te le donnera à ta place.

## Ce que je te conseille

La prochaine fois que « ça marche chez moi mais pas chez lui », soupçonne un cache avant de soupçonner ton code. Et avant une migration, regarde le TTL de l'enregistrement que tu vas changer : c'est la durée pendant laquelle ton ancienne adresse continuera de hanter le web. Abaisse-le la veille, à quelques minutes, et le jour où tu bascules, le mensonge sera court.

Le web ne te montre jamais le présent. Il te montre un passé récent qu'il n'a pas encore pris la peine de rafraîchir. Le jour où tu intègres ça, la moitié des bugs « impossibles » deviennent évidents.

Ce satellite fait partie du dossier [Navigateur](/dossier/browser). Le vocabulaire à emporter : le [DNS](/definition/dns), le [résolveur](/definition/resolveur), le [TTL](/definition/ttl), les [enregistrements A et CNAME](/definition/enregistrement-a-cname) et le [cache DNS](/definition/cache-dns).


Ce que ton navigateur te montre n'est jamais la vérité en direct : c'est un empilement de caches qui ont chacun le droit de te mentir un peu, le temps d'un TTL. La résolution DNS complète racontée comme une enquête, et ce que j'écoute vraiment quand je pose la question en entretien.

DNS, le premier mensonge du web


Ils sont là, tapis dans la console, prêts à te sauter au visage avec leurs grosses erreurs rouges dès que tu tentes un appel un peu ambitieux. Les fameux en-têtes CORS, ceux qui te rappellent que non, tout ne roule pas toujours tout seul. Et si je te disais qu'en réalité, ils ne t'en veulent pas ? Qu'ils sont là pour protéger quelqu'un, et que ce quelqu'un, c'est ton utilisateur ?

## Chaque requête traîne tes cookies

Pour comprendre CORS, il faut d'abord un fait tout bête. Quand ton navigateur fait une requête vers un domaine, il y joint automatiquement tous les cookies qu'il possède pour ce domaine. Tu appelles `mabanque.fr`, et le cookie de session que ta banque a déposé chez toi part avec la requête, sans que tu fasses quoi que ce soit. C'est même comme ça que tu restes connecté : le cookie voyage seul, le serveur le lit, il te reconnaît.

Pratique. Et un peu terrifiant, si on y réfléchit une seconde.

## Le scénario où on te fait les poches

Imagine un web sans aucune protection. Tu t'es connecté à ta banque ce matin, tu as donc encore ton cookie de session bien au chaud. Puis tu visites un site quelconque, qui a décidé de te dépouiller. Ce site charge du JavaScript qui, en douce, lance une requête vers `mabanque.fr/solde`.

Comme cette requête part vers le domaine de ta banque, elle emporte, automatiquement, ton cookie de session. Ta banque reçoit une requête parfaitement authentifiée, te reconnaît, et répond avec ton solde. Le site malveillant n'a jamais vu ni ton mot de passe ni ton cookie : il a juste profité du fait que ton navigateur, lui, les avait. Et il pourrait enchaîner tous les appels qu'il veut.

C'est exactement ce que le navigateur refuse de laisser arriver.

## La règle par défaut : on ne parle pas aux étrangers

Par défaut, un navigateur bloque les requêtes JavaScript vers un autre domaine que celui de la page en cours. Tu es sur `uneembrouille.com`, tu tentes un appel vers `mabanque.fr` : le navigateur met le holà et t'affiche la fameuse erreur rouge. C'est la politique de même origine, et cette erreur CORS que tu maudis, c'est elle qui parle.

Autrement dit, le rouge dans ta console n'est pas un bug. C'est le système qui fait son travail : empêcher, par défaut, n'importe quel site de se servir de la session bancaire ouverte dans ton autre onglet.

CORS, c'est simplement le mécanisme qui permet de faire une exception, proprement. Si une API veut autoriser un domaine précis à l'appeler, elle répond avec un en-tête, `Access-Control-Allow-Origin`, contenant ce domaine. Le navigateur voit l'autorisation explicite, et laisse passer. Deux sites qui travaillent ensemble s'entendent ainsi, sans ouvrir la porte à toute la rue.

## Le « correctif » qui désarme le garde du corps

Et c'est là que ça dérape, en général. Face à l'erreur rouge, la tentation est de la faire taire au plus vite. La façon la plus rapide : répondre `Access-Control-Allow-Origin: *`. L'étoile, ça veut dire « n'importe quel domaine peut m'appeler ». L'erreur disparaît, tu es content, tu passes à autre chose.

Sauf que tu viens de retirer la sécurité que CORS mettait en place. Pour une API vraiment publique et sans cookie, l'étoile est légitime. Mais la coller pour éteindre un voyant rouge sans comprendre ce qu'il protégeait, c'est débrancher le garde du corps parce qu'il t'a demandé ta pièce d'identité.

## Ce que l'IA te souffle un peu trop vite

Demande à un assistant de régler ton erreur CORS, et il ira souvent au plus court : mets une étoile, ou passe par un proxy qui contourne la restriction côté serveur. Ça marche, l'erreur s'en va. Mais la question qu'il ne pose pas, parce qu'il ne connaît pas ton contexte, c'est : cette porte, ai-je le droit de l'ouvrir aussi grand ? Y a-t-il, derrière, des cookies, des données sensibles, une session ? Ce jugement sur ce que tu protèges et pour qui ne se génère pas. La machine sait faire disparaître le rouge. Savoir si tu en as le droit, ça reste à toi.

## Ce que je te conseille

Quand tu tombes sur une erreur CORS, ne cherche pas d'abord à la faire taire. Demande-toi ce que le navigateur est en train de protéger. La plupart du temps, il fait exactement son boulot, et le bon correctif n'est pas de retirer le mur : c'est d'autoriser, côté serveur, le domaine précis qui en a besoin. L'étoile, garde-la pour les API réellement publiques, et en connaissance de cause.

Le rouge dans ta console n'est pas ton ennemi. C'est souvent le seul, dans l'histoire, qui se soucie de ton utilisateur pendant que tu te bats avec ta requête.

En marge du voyage d'une URL, dans le dossier [Navigateur](/dossier/browser). Le vocabulaire : les [CORS](/definition/cors) et le [cookie](/definition/cookie).


Ils sont tapis dans la console, prêts à te sauter au visage avec leurs grosses erreurs rouges. Et si les CORS ne t'en voulaient pas ? S'ils étaient là pour protéger, pas toi, mais ton utilisateur, de sa propre session ouverte dans l'onglet d'à côté ?

L'autodidacte

Navigateur