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


« Que se passe-t-il quand tu tapes une URL et que tu appuies sur Entrée ? » Je pose cette question en entretien depuis des années, et elle ne sert pas à ce qu'on croit. Elle sépare deux profils : ceux qui récitent une liste d'étapes apprise par cœur, et ceux qui savent qu'entre ta touche Entrée et le premier pixel, une dizaine de systèmes se sont parlé, ont négocié, ont pris des raccourcis, et que chacun pouvait te mentir un peu ou tout faire échouer. Les premiers m'ennuient. Les seconds, je les retiens.

Ce voyage paraît instantané, d'un seul bloc. Il ne l'est pas. C'est une succession d'étapes, dans un ordre précis, et chacune est un endroit où quelque chose peut silencieusement mal tourner. Ce dossier le suit, pas à pas. Chaque étape est un satellite à part entière.

## Le voyage, dans l'ordre

Avant même de commencer, le navigateur triche : il regarde s'il n'a pas déjà la réponse sous la main. [Le bug que j'avais déjà corrigé](/blog/cache-http) raconte comment le cache accélère tout, au prix d'une version parfois périmée que tu as toi-même autorisée.

Puis il faut traduire le nom en adresse. [DNS, le premier mensonge du web](/blog/dns-le-premier-mensonge-du-web) : la résolution racontée comme une enquête, et pourquoi ce que tu vois n'est jamais la vérité en direct.

L'adresse en main, il ouvre la connexion. [Trois paquets avant de se parler](/blog/handshake-tcp) : la poignée de main TCP, et les trois façons dont elle échoue en silence.

Si c'est du HTTPS, il la sécurise. [Le cadenas a une date de péremption](/blog/tls-le-cadenas) : ce que TLS prouve vraiment, et ce qu'il ne prouve pas.

Alors seulement, il demande la ressource. [Le bug était dans l'enveloppe](/blog/requete-http) : une requête, c'est une lettre dont l'en-tête dit tout, et que personne ne relit.

Et il faut encore la dessiner. [Le serveur répondait en 20 ms, l'écran restait blanc](/blog/rendu-ecran-blanc) : ce qui se passe entre la réponse reçue et le premier pixel.

## Pourquoi connaître le voyage

Chacune de ces six étapes peut casser à sa manière, et produire le même symptôme apparent : une page lente, blanche, ou qui refuse de charger. Connaître le voyage, ce n'est pas réciter un parcours pour un entretien. C'est savoir, quand ça coince, à quel étage regarder pendant que les autres redémarrent l'application au hasard. C'est précisément ce qui ne se génère pas : la liste des étapes, l'IA te la donne ; savoir où chacune ment, ça reste à toi.


Tu tapes une adresse, tu appuies sur Entrée, la page apparaît. Entre les deux, une dizaine de systèmes se sont parlé, dans un ordre précis, et chacun pouvait te mentir ou tout faire échouer. Le dossier qui suit ce voyage étape par étape, là où chacune peut silencieusement mal tourner.

Le voyage d'une URL


Le pire incident sur lequel j'ai enquêté n'avait pas de coupable unique. Pas de grosse faute, pas de négligence flagrante. Juste cinq petites choses, chacune anodine prise seule, qui s'étaient alignées ce jour-là au mauvais moment. Un log ignoré, une alerte mal réglée, une vérification sautée, une astreinte injoignable, un déploiement lancé trop vite. Aucune ne suffisait. Toutes ensemble, elles ont ouvert un couloir droit jusqu'à la panne.

C'est exactement l'image du gruyère.

## Des tranches trouées, mais décalées

Le modèle vient de la sécurité, et il tient en une image. Chaque protection d'un système est une tranche de fromage : un test, une revue, un pare-feu, une alerte. Aucune n'est parfaite, chacune a ses trous. Et ce n'est pas grave, tant que les trous ne sont pas au même endroit. Le désastre, c'est le jour où ils s'alignent d'une tranche à l'autre et laissent passer la catastrophe de bout en bout.

La défense en profondeur, c'est tout l'inverse du mur unique et parfait, qui n'existe pas. C'est accepter que chaque couche soit imparfaite, et en empiler assez d'indépendantes pour que leurs trous ne tombent jamais en face. Ce dossier réunit les pratiques qui décalent les trous.

## Les pratiques du dossier

Anticiper, d'abord. [La panne qu'on avait tous sentie venir](/blog/premortem) : le pré-mortem, ou imaginer l'échec d'un projet avant qu'il n'arrive, pour désamorcer ce que tout le monde sentait sans le dire.

Éprouver, ensuite. [Le serveur que tu n'oses pas redémarrer](/blog/chaos-engineering) : le chaos engineering, ou casser volontairement pour savoir si ça tient, au lieu de l'espérer.

Contenir, enfin. [Ce qui tombe ne doit pas tout emporter](/blog/cloisonnement) : le cloisonnement, pour qu'une brèche dans un coin n'ouvre pas l'accès au tout.

## Ce dossier se construit

Il n'est pas complet, et je préfère te le dire. D'autres couches viendront : automatiser ce qui est répétitif pour retirer l'erreur humaine de la boucle, apprendre proprement de chaque incident au lieu de chercher un coupable. Je les ajouterai quand elles existeront.

Une dernière chose, parce qu'elle change tout aujourd'hui. L'IA ajoute des trous plus vite que jamais : du code généré qu'on relit à peine, des hypothèses jamais vérifiées, de la sophistication qu'on empile sans la comprendre. Elle ne creuse pas des failles par malveillance, elle en creuse par vitesse. La défense en profondeur, c'est précisément la discipline qui empêche tous ces trous de s'aligner. Elle n'a jamais été aussi utile que depuis qu'on produit du gruyère aussi vite.


Le pire incident n'a presque jamais de coupable unique : juste plusieurs petites failles, anodines seules, qui se sont alignées au mauvais moment. Le dossier des pratiques qui décalent les trous, pour qu'une brèche quelque part n'ouvre pas un couloir jusqu'au cœur.

Le modèle du gruyère


On m'a déjà refilé une application critique dont plus personne ne savait comment elle marchait. Elle tournait, elle tenait la charge, une partie de la boîte en dépendait. Un détail : les deux personnes qui l'avaient écrite étaient parties. La doc décrivait une version qui n'existait plus. Le code compilait, et plus personne de vivant ne savait vraiment pourquoi il était fait comme ça. Une boîte noire en état de marche, avec pour seul mode d'emploi le code lui-même. Ma première tâche n'a pas été d'écrire une ligne. Elle a été de comprendre ce que j'avais devant moi.

On t'a appris à écrire du code. À l'école, dans les tutos, sur les projets perso, tout ton apprentissage était tourné vers une seule direction : produire, faire sortir du neuf. Personne ne t'a appris l'autre moitié du métier, celle que tu passes vraiment tes journées à faire une fois en poste : lire du code que tu n'as pas écrit, reconstruire l'intention derrière un système opaque, deviner pourquoi un morceau tient de telle façon avant d'oser y toucher. On forme des gens à bâtir du neuf, et on les lâche dans un monde fait de bien plus d'ancien que de neuf.

Longtemps, ça passait : tu finissais par connaître ton système à force d'y vivre. Sauf que l'IA vient de casser cet équilibre. Quand la génération crache du code plus vite que quiconque ne peut le relire, le goulot d'étranglement du métier se déplace. Ce n'est plus l'écriture qui est rare et chère, c'est la compréhension. Relire, cartographier, interroger un système que tu n'as pas produit : voilà la compétence qui prend de la valeur pendant que l'écriture en perd. C'est le pari de ce dossier. On y parle d'une seule chose : comment prendre la mesure d'un système dont tu n'as ni les auteurs, ni la doc, ni le droit à l'erreur.

## Dans quel ordre lire ce dossier

D'abord, faire une carte. [« La carte que le code ne dessine pas »](/blog/la-carte-que-le-code-ne-dessine-pas) explique pourquoi une carte de ce que le système fait, pour qui et avec quels mots, bat une carte de ses services et de ses flèches, et comment tracer la tienne, seul, en un après-midi, sans mobiliser les rares experts encore là.

Ensuite, faire parler. [« Faire avouer un système »](/blog/faire-avouer-un-systeme) réunit les questions qui font parler le code et les humains autour de lui, celles qui ne télégraphient pas leur réponse, pour extraire ce qu'aucune documentation n'a jamais écrit.

## Ce dossier se construit

Il n'est pas terminé, et je préfère te le dire que te vendre un sommaire complet que je ne tiendrai pas. D'autres pièces viendront : remonter à une décision d'architecture à partir de ses seules traces, suivre un flux de données d'un bout à l'autre, savoir quand arrêter de comprendre et commencer à changer. Je les ajouterai ici quand elles existeront, pas avant.

Le vocabulaire à garder sous la main pour toute la suite : le [legacy](/definition/legacy), la [dette technique](/definition/dette-technique), le [couplage](/definition/couplage) et la [cohésion](/definition/cohesion), la [boîte noire](/definition/boite-noire) et la [rétro-ingénierie](/definition/retro-ingenierie).


On t'a appris à écrire du code, personne ne t'a appris à en lire. C'est pourtant devenu la compétence numéro un, précisément parce que l'IA écrit. Le dossier des méthodes pour comprendre un système dont tu n'as ni les auteurs, ni la doc, ni le droit à l'erreur.

L'autodidacte

Tous les dossiers

Le voyage d'une URL

Le modèle du gruyère

Lire un système qu'on n'a pas écrit