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


J'ai eu ma demi-heure avec la seule personne qui connaissait encore le système. Je lui ai demandé : « donc ce module gère bien les relances, c'est ça ? » Elle a dit oui. Je suis reparti rassuré. Deux semaines plus tard, ça a explosé, sur les relances, précisément. Elle ne m'avait pas menti. C'est moi qui lui avais soufflé la réponse, et elle s'était contentée d'acquiescer. Ma question portait déjà sa conclusion. Il ne restait plus qu'à hocher la tête.

Un système ne se confie pas à qui l'interroge mal. La doc est morte, tu le sais déjà. Ce qui reste de vérité vit à deux endroits : dans le code, qui ne ment pas sur ce qu'il fait, et dans quelques têtes, qui savent pourquoi. Le piège, c'est que ces deux sources te diront ce que tu veux entendre si tu leur poses la mauvaise question. Demande « ça marche bien, non ? », et tu récolteras la confirmation de ta propre supposition, jamais la vérité. Le talent, ici, n'est pas de connaître les réponses. C'est de poser des questions auxquelles on ne peut pas répondre par réflexe.

## Interroger sans rien supposer

Avant la première question, un principe : tout ce que tu ne sais pas reste une question ouverte, jamais une supposition par défaut. Face à un système opaque, ton cerveau veut combler les trous tout seul (« ça doit marcher comme d'habitude »), et c'est exactement là que tu tombes. Un système opaque n'est pas un système sans réponses ; c'est un système plein de suppositions que personne n'a jamais vérifiées. Chaque inconnu, tu l'écris comme une chose à aller vérifier, pas comme un vide que tu combles d'espoir.

Ensuite, l'ordre : le code d'abord, les humains après. Pas parce que le code est plus riche, mais parce qu'il ne se souvient pas de travers. Il te dit, factuellement, ce que le système fait. Tu arrives alors devant les gens armé de faits, capable de repérer quand un souvenir contredit les logs. Car les humains reconstruisent : ils te diront « ça a toujours marché » là où le système est tombé deux fois le mois dernier. Ils ne mentent pas, ils se souviennent de l'intention, pas de l'exécution. Ton travail, c'est de faire parler l'écart entre les deux.

Et avant d'ouvrir la bouche, verrouille le vocabulaire. Quand ton interlocuteur dit « commande », « relance », « client », assure-toi que le mot désigne une seule chose, et la même pour vous deux. La moitié des malentendus sur un legacy viennent d'un terme qui en cache deux. Une heure d'enquête avec un lexique flou, c'est une heure de fausses réponses parfaitement alignées.

## Les questions qui ne télégraphient pas leur réponse

Voici le cœur. Une bonne question d'enquête ne contient pas sa réponse. « Ce module gère les paiements, c'est bien ça ? » est une mauvaise question : elle appelle un oui. Remplace-la par des questions qui obligent à raconter.

« Montre-moi la dernière fois que ça a cassé. » Tu n'apprends presque rien d'un système en marche ; tu apprends tout de la façon dont il tombe.

« Qu'est-ce que tu n'oserais pas toucher ici, et pourquoi ? » La peur des gens est une carte des dangers plus fiable que n'importe quelle doc.

« Quand tout tombe en pleine nuit, qui est-ce qu'on appelle ? » La réponse te donne le vrai propriétaire du système, celui que l'organigramme ne montre pas.

« Si tu partais demain, qu'est-ce que personne ne saurait ? » Une seule question, et tu vois surgir d'un coup les points de défaillance uniques et la connaissance qui n'est écrite nulle part.

Aucune de ces questions ne peut recevoir un « oui » de politesse. Chacune force un récit, et c'est dans le récit que le système avoue.

## « Ouvre le code, la vérité est dedans »

L'objection que j'entends le plus : pourquoi perdre une heure et demie à faire parler quelqu'un, alors que le code est là, et qu'il ne ment pas ?

Elle n'est pas idiote, et je commence d'ailleurs par le code. Mais le code est muet sur deux choses que seul un humain détient : pourquoi il a été fait ainsi, et ce qui fait mal quand ça casse. Il te dira que le paiement passe par trois services. Il ne te dira jamais que le troisième est tenu par la seule personne qui en comprend la logique, et qu'elle part dans un mois. Le code te donne la carte du terrain. Il ne te montre pas où sont les mines. Les mines sont dans les têtes, et on ne les repère qu'en posant les bonnes questions.

## Ce que l'IA change

C'est là que tout se retourne. Le produit de cette enquête, ce n'est pas un joli document à ranger. C'est un plan : des zones précises, classées par le risque. Ce plan, tu peux le confier à un agent qui, lui, lira l'intégralité du code, zone par zone, bien plus vite que toi.

L'IA sait tout lire. Ce qu'elle ne sait pas, c'est où regarder, ni ce qui compte. Elle ne peut pas demander « qu'est-ce que tu n'oserais pas toucher », parce qu'elle ignore ce qui est en jeu, et pour qui. L'interrogatoire, c'est ce qui transforme une machine à lire du code en auditeur utile : c'est toi qui lui donnes ses ordres de mission. Dans un monde où lire le code est devenu gratuit, savoir faire avouer le système et les gens pour décider où l'IA doit creuser, voilà ce qui reste rare, et cher.

## Ce que je te conseille

Avant de toucher un système que tu ne connais pas, arrache-toi une heure et demie avec la personne qui le connaît encore. Passe-la à poser des questions dont la réponse n'est pas déjà dans la question. Ne demande jamais « c'est bien comme ça, non ? » ; demande « raconte-moi la dernière fois que ça a cassé ». Et note chaque « je ne sais pas » comme une chose à aller vérifier dans le code, jamais comme un trou à combler d'une supposition.

Si tu ne devais retenir qu'une question, garde celle-là : « si tu partais demain, qu'est-ce que personne ne saurait ? » Elle fait avouer, d'un coup, tout ce que le système doit à une seule tête.

Ce satellite fait partie du dossier [Lire un système qu'on n'a pas écrit](/dossier/lire-un-systeme). Le vocabulaire à emporter : la [documentation vivante](/definition/documentation-vivante), la [connaissance tribale](/definition/connaissance-tribale), le [SPOF](/definition/spof), la [source de vérité](/definition/source-de-verite) et le [sachant](/definition/sachant).


La doc est morte, la vérité vit dans le code et dans quelques têtes, et les deux te diront ce que tu veux entendre si tu poses mal la question. La méthode pour faire parler un système et les gens qui l'entourent : les questions qui ne télégraphient pas leur réponse.

Faire avouer un système


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 incident qui n'aurait dû concerner qu'un recoin du système finit par les toucher tous. Un petit bout se fait avoir, une entrée mal validée, un accès qui fuite, et de proche en proche, c'est l'ensemble qui est atteint. Quand on remonte le fil, la cause de départ est presque toujours ridicule au regard des dégâts. Ce qui a transformé un bobo en catastrophe, ce n'est pas la taille du trou initial. C'est que rien ne l'a empêché de se propager.

Parce que tout se faisait confiance. Une seule clé ouvrait toutes les portes, la base de données répondait à qui la sonnait, le moindre service pouvait parler à n'importe quel autre. Un système où tout communique avec tout, c'est un système où une seule brèche donne accès au tout.

## Le gruyère et l'alignement des trous

C'est là qu'entre le modèle du gruyère. Chaque protection est une tranche de fromage : un pare-feu, une authentification, une validation. Aucune n'est parfaite, chacune a ses trous. Prises isolément, ces failles ne posent pas de drame. Le désastre arrive quand les trous s'alignent d'une tranche à l'autre et forment un couloir droit, du dehors jusqu'au cœur.

La défense en profondeur, c'est empiler des couches imparfaites mais indépendantes, pour qu'un trou dans l'une soit couvert par la suivante. Le piège, c'est le mot indépendantes. Un système plat, où tout se fait confiance, ce n'est pas un empilement de tranches : c'est une pile où les trous sont déjà alignés d'avance. Une seule brèche, et le couloir est ouvert.

## Cloisonner, c'est bâtir les murs

Cloisonner, c'est isoler des zones pour qu'un problème reste là où il est né. La base de données n'est pas joignable depuis le web public : un trou dans le front n'atteint pas les données. Chaque service ne reçoit que les droits dont il a strictement besoin : un composant compromis ne peut rien faire de plus que son travail. Des identifiants séparés, des frontières réseau, des permissions au plus juste. Tout ça décide d'une seule chose : jusqu'où une brèche peut se propager avant de heurter un mur. C'est le rayon d'explosion, et le cloisonnement le raccourcit.

## Ce que l'IA relie un peu trop volontiers

Demande à un assistant de faire marcher un système, et il reliera tout à tout : c'est le chemin le plus court, celui qui produit le moins d'erreurs. Il n'ajoutera pas de lui-même une frontière de permissions ou un cloisonnement que tu n'as pas demandé, parce qu'une frontière ressemble à un obstacle, et qu'un obstacle ressemble à un bug pour une machine qui optimise le « ça marche ». Décider de ce qui ne doit surtout pas pouvoir se parler, de ce qu'un composant ne doit jamais pouvoir atteindre, ça naît d'un réflexe précis : imaginer la brèche. Et imaginer la brèche, c'est du jugement, pas de la complétion.

## Ce que je te conseille

Pars du principe que ça arrivera. Non pas « est-ce qu'on se fera avoir », mais « le jour où ce bout-là est compromis, jusqu'où l'attaquant peut-il aller depuis là ? ». Conçois pour que la réponse soit « pas bien loin ». Applique le moindre privilège par défaut : donne à chaque partie le minimum, pas le maximum confortable. Et à chaque nouvelle connexion que tu ouvres, pose la question : si ce côté tombe, qu'est-ce que ça ouvre de l'autre ?

Tu n'empêcheras jamais tous les trous. La défense en profondeur n'est pas le fantasme du mur parfait. C'est s'assurer que le jour où l'un cède, le suivant tient encore.

Ce satellite fait partie du dossier [Le modèle du gruyère](/dossier/gruyere), sur la défense en profondeur. Le vocabulaire : le [cloisonnement](/definition/segmentation), le [moindre privilège](/definition/moindre-privilege) et la [défense en profondeur](/definition/defense-en-profondeur).


Un incident qui n'aurait dû toucher qu'un coin du système les a tous emportés, parce que tout se faisait confiance : une clé ouvrait toutes les portes, la base répondait à l'internet entier. Le trou de départ était minuscule. Les dégâts, totaux. Cloisonner, c'est empêcher les trous de s'aligner.

Ce qui tombe ne doit pas tout emporter


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.

L'autodidacte

Toutes les publications

Faire avouer un système

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

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

Le bug était dans l'enveloppe

Ce qui tombe ne doit pas tout emporter

Le cadenas a une date de péremption