Qui écrit ici : de l'usine au cybercafé, jusqu'à Engineering Lead. Les fondamentaux qui survivent à l'IA, par quelqu'un qui a fait le chemin.

Je m'appelle Anthony. Génération 86, Lot-et-Garonne. Mon premier contact sérieux avec le code, c'était dans un cybercafé, pas dans une école d'ingénieurs. Avant le dev, il y a eu l'usine. Je sais ce que c'est qu'un métier où l'on compte les heures, et je sais ce que ça coûte, et ce que ça donne, d'en changer par ses propres moyens.

Vingt ans plus tard, je suis Engineering Lead. Je recrute, et je passe une partie de mes journées à faire ce que ce site enseigne : lire des systèmes que je n'ai pas écrits, et décider avec.

Ce site existe pour une seule raison : dire au gamin du cybercafé ce que personne ne lui a dit. Pas des tutoriels : il y en a partout, et l'IA les rend gratuits. Des fondamentaux : les choses qui ne périment pas, expliquées par quelqu'un qui a eu mal aux mêmes endroits que toi. Et une conviction qui traverse tout : comprendre en profondeur vaut plus cher que jamais, précisément parce que tu n'auras plus à tout écrire toi-même.

On ne naît pas dev. On le devient. Toujours.

*Ailleurs : mes carnets personnels sont sur [anthony.capirchio.fr](https://anthony.capirchio.fr). Et si un jour tu diriges une équipe, les mêmes questions ont une autre tête, je les traite dans [The Operating Shift](https://theoperatingshift.com).*


Qui écrit ici

À propos

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.

Le cadenas a une date de péremption


« Ne touche pas à celui-là. » Chaque équipe a son serveur, son service, son bout d'infra qu'on traite comme un dragon endormi. Il est fragile, personne n'est tout à fait sûr de ce qui arrive s'il tombe, alors personne n'essaie de le savoir. On marche sur la pointe des pieds autour, on prie pour qu'il tienne.

Et c'est exactement celui-là qui se réveille en pleine nuit, sans prévenir, et emporte le reste avec lui. Le problème n'est pas qu'il soit fragile. Le problème, c'est que tu ne l'as jamais vu tomber dans des conditions où tu pouvais l'observer tranquillement. Il a choisi son moment. Le chaos engineering, c'est lui reprendre ce choix.

## Supposer résilient n'est pas être résilient

Tu crois ton système solide. Il a des réessais, des répliques, des mécanismes de repli, tout ce qu'il faut sur le papier. Sauf que « sur le papier » et « dans la réalité » sont deux mondes, et l'écart entre les deux, c'est précisément là que vivent les incidents. Tu supposes que si une machine tombe, une autre prend le relais. Tu ne l'as jamais vérifié en conditions réelles. Tu l'espères.

Le chaos engineering renverse ça : au lieu d'attendre la panne, tu la provoques. Tu tues une machine volontairement, tu coupes une dépendance, tu ajoutes de la latence, et tu regardes comment le système réagit vraiment, pas comment tu imagines qu'il réagit. L'outil canonique, Chaos Monkey, va jusqu'à tuer des instances au hasard en production, en continu, pour que « survivre à la perte d'une machine » ne soit plus un espoir mais un fait prouvé tous les jours.

La clé, c'est le contrôle. Tu ne fous pas le feu à la maison pour voir. Tu délimites le rayon d'explosion, tu le fais en pleine journée, équipe présente, avec un bouton d'arrêt à portée de main. Tu paies un petit prix connu, maintenant, pour ne pas payer un grand prix inconnu à 3h du matin.

## Le voyant rouge, c'est ta peur

La bonne nouvelle, c'est que ton système te dit déjà où il est faible. Ce serveur que personne n'ose toucher, ce déploiement qu'on repousse toujours, cette dépendance dont on parle à voix basse : cette peur est une information, pas un tabou. Elle marque exactement l'endroit que tu n'as jamais testé, donc l'endroit où l'incident t'attend. Le chaos engineering, c'est décider d'aller voir là où ça fait peur, plutôt que d'attendre que ça décide pour toi.

## Ce que l'IA affirme et ne prouve pas

L'assistant écrit du code qui a l'air résilient. Il ajoute le réessai, le try/catch, le repli, parce que ce sont des motifs fréquents. Mais que l'ensemble survive vraiment à une panne, ça, aucune génération ne peut te le garantir, parce que ça ne se lit pas dans le code : ça se constate en le cassant. La machine te livre une résilience supposée. Seul le chaos la transforme en résilience vérifiée. C'est la même différence qu'entre un test qui passe et un comportement qu'on a réellement prouvé : tant que tu n'as pas coupé le courant, tu ne sais pas si le groupe électrogène démarre.

## Ce que je te conseille

Fais la liste des choses que ton équipe n'ose pas toucher. Elle est courte, et c'est ta carte des dangers. Prends-en une, la moins risquée, et provoque sa panne dans un cadre maîtrisé : périmètre réduit, en journée, avec un retour arrière prêt. Tu apprendras en une heure ce qu'un incident t'aurait appris en pire, plus tard, et plus cher.

Un système que tu n'as jamais vu tomber n'est pas un système résilient. C'est un système dont tu ignores encore comment il tombe.

Ce satellite fait partie du dossier [Le modèle du gruyère](/dossier/gruyere), sur la défense en profondeur. Le vocabulaire : le [chaos engineering](/definition/chaos-engineering), la [résilience](/definition/resilience) et le [rayon d'explosion](/definition/rayon-d-explosion).


Chaque équipe a ce serveur-là. Fragile, personne ne sait vraiment ce qui se passe s'il tombe, alors personne ne le teste. Et c'est précisément celui qui se réveille à 3h du matin. Le chaos engineering, c'est réveiller le dragon toi-même, à midi, avec un plan de secours.

Le serveur que tu n'oses pas redémarrer


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


Le diagramme d'architecture était magnifique : des dizaines de boîtes, des flèches nettes, trois couleurs, une légende. Je l'ai fixé dix minutes, et je ne savais toujours pas répondre à la question la plus bête qui soit : ce système, il fait quoi, et pour qui ? Il me montrait des services, des files d'attente, des bases de données. Pas une ligne sur ce que l'utilisateur, au bout, en retirait. J'avais sous les yeux un plan du métro sans le nom des stations, et on venait de me demander d'y conduire.

Un diagramme technique répond à une seule question : comment le système est-il construit. Quels composants, quels appels, quels tuyaux. C'est utile, mais quand tu hérites d'un système, ce n'est pas la question que tu te poses en premier. Celle qui te presse, c'est l'autre : qu'est-ce qu'il fait, pour qui, et avec quels mots. Un système que tu ne sais décrire qu'en services et en flèches est un système que tu ne comprends pas encore. Tu en connais la plomberie, pas la ville.

## Deux cartes pour le même système

Il existe deux façons de cartographier un système, et on ne t'a montré que la mauvaise pour débuter.

La carte technique liste les services, les bases, les flux entre eux. C'est celle des diagrammes d'archi. Elle a deux défauts quand tu découvres. D'abord elle ment sur l'intention : un service appelé `OrderService` peut faire trois choses sans rapport, et un nom de fichier ne t'a jamais dit pourquoi il existe. Ensuite elle bouge tout le temps : un refacto, un service qui se scinde, et ta carte est périmée. Tu cartographies du sable.

La carte fonctionnelle liste autre chose : ce que le système fait (ses capacités), pour qui (ses acteurs), et dans quels mots (le vocabulaire du métier). Pas « POST /v2/process », mais « un client annule une commande ». Cette carte-là est stable, parce que ce qu'un système rend à ses utilisateurs change lentement, bien plus lentement que la façon dont c'est codé. Et c'est la seule que tu peux montrer à quelqu'un qui n'est pas dev, la seule qui te dise, quand tu t'apprêtes à toucher un bout : quelle capacité je casse si je me trompe, et qui va hurler.

Le code te donne le comment. La carte fonctionnelle récupère le quoi et le pour-qui, c'est-à-dire précisément ce que le code a effacé en cours de route.

## La tracer en un après-midi, seul

Bonne nouvelle : tu n'as besoin de personne pour la première version. Pas des experts (souvent introuvables ou déjà partis), pas d'une réunion. Juste du dépôt et d'un après-midi. Voici la méthode.

Commence par les points d'entrée. Tout ce qui fait entrer quelque chose dans le système est une chose qu'il fait pour quelqu'un : les écrans, les routes d'API, les tâches planifiées, les messages consommés dans une file, les webhooks. Ça se trouve mécaniquement, en listant les routes et les jobs, sans rien comprendre encore. C'est ta liste brute de capacités.

Ensuite, nomme chaque capacité dans les mots de l'utilisateur, pas dans ceux du code. `POST /v2/proc` devient « un client passe une commande ». Si tu n'arrives pas à nommer une entrée en français simple, note-la comme une zone d'ombre : c'est une capacité que tu ne comprends pas encore, et c'est une information précieuse, pas une honte.

Pour chacune, demande pour qui. Un utilisateur final ? Un admin ? Un autre système ? Un traitement de nuit ? Les acteurs révèlent à qui le système rend service, et donc qui appeler le jour où ça casse.

Récolte le vocabulaire au passage. Les noms qui reviennent dans les routes, les tables, les logs, ce sont les mots du métier. Fais-en un mini-lexique. Et guette les frottements : quand deux mots désignent la même chose, ou qu'un mot désigne deux choses selon l'endroit, tu viens de trouver une couture, la frontière entre deux territoires du système.

Enfin, relie. Pas les services entre eux, les capacités entre elles : « passer une commande » a besoin de « vérifier le stock ». Ces dépendances-là, fonctionnelles, te donnent l'ordre des dominos.

Au bout de l'après-midi, tu as une page : une vingtaine de capacités, leurs acteurs, leurs mots, leurs dépendances. Seul, à partir du code. Prends une app de réservation fictive : « réserver un créneau », « annuler une réservation », « relancer un client sans réponse » (déclenchée par un traitement de nuit, pas par un humain), avec le lexique qui distingue le « créneau » côté client du « slot » côté technique. En une page, tu en sais plus sur ce que fait ce système que la plupart des gens qui vivent dedans depuis six mois sans l'avoir jamais posé à plat.

## Ce que l'IA en fait, et ce qu'elle n'en fait pas

L'assistant lit le code plus vite que toi et te dessinera une carte technique en un instant : le graphe d'appels, les services, qui parle à qui. Utilise-le pour la corvée, justement, pour aspirer les points d'entrée et les noms qui reviennent.

Mais la carte fonctionnelle lui échappe là où ça compte. Nommer une route dans les mots du métier, savoir que cette annulation-là est un drame pour la compta et une broutille pour le support, distinguer le mot qui cache deux réalités : tout ça, c'est du sens, et le sens ne vit pas dans le code. Il vit dans les gens qui s'en servent. L'IA voit que `proc` appelle `stock` ; elle ne sait pas que « passer une commande » est la promesse autour de laquelle toute la boîte tourne.

C'est là que tu restes indispensable. Dans un monde où le code se génère et s'accumule plus vite que jamais, celui qui sait transformer ce tas en une carte de ce qu'il signifie, celui-là tient vraiment le système. La génération produit du comment à la chaîne. Le quoi et le pour-qui, il faut encore quelqu'un pour les nommer.

## Par quoi commencer demain matin

Ne lis pas le code de haut en bas. N'ouvre pas le diagramme d'archi du wiki. Ouvre le fichier des routes, ou la liste des tâches planifiées. Liste chaque point d'entrée, nomme-le en français, mets un acteur en face. C'est ton après-midi, et ce soir tu auras une carte que le code ne dessinait pas.

Un système que tu ne sais décrire que dans les mots du code est un système que tu ne comprends pas encore, quelle que soit la beauté de son diagramme. Le jour où tu peux le raconter dans les mots de ceux qui s'en servent, tu as pris la main.

Ce satellite fait partie du dossier [Lire un système qu'on n'a pas écrit](/dossier/lire-un-systeme). Le vocabulaire à emporter : la [cartographie fonctionnelle](/definition/cartographie-fonctionnelle), la [dépendance](/definition/dependance), le [domaine](/definition/domaine), le [langage ubiquitaire](/definition/langage-ubiquitaire) et le [bounded context](/definition/bounded-context).


Le diagramme d'architecture te dit comment le système est construit, jamais ce qu'il fait ni pour qui. La carte fonctionnelle répond à l'autre question, celle dont tu as besoin en premier. Comment la tracer seul, en un après-midi, sans déranger les experts.

La carte que le code ne dessine pas


J'hérite d'une suite de tests qu'un collègue parti depuis a laissée derrière lui. Je change une ligne, une histoire d'arrondi, rien de méchant. Je lance les tests. Un feu rouge : `expect(calculePrix(100, 'VIP')).toBe(80)`. Le test attendait 80, il obtient 78.

Et là, je bloque. 80, c'est quoi ? Une vérité que ce test protège, ou un chiffre gravé un jour par quelqu'un pour une raison oubliée ? Aucun commentaire. Le nom du test : `test calculePrix`. Merci bien. Je fais un `git blame` : l'auteur a quitté la boîte il y a deux ans. Je suis devant l'échelle, et plus personne ne se souvient de la douche froide.

Un test enregistre une décision : « ce comportement compte assez pour qu'on le surveille ». Sauf qu'il n'en garde que la moitié. Il grave le *quoi*, la valeur attendue, avec une précision de machine. Le *pourquoi*, la décision et le risque qui justifient cette valeur, ne vit nulle part dans le code. Il est dans la tête de l'auteur, ou dans un message de commit, ou parti avec lui. Et le jour où le test vire au rouge, c'est le pourquoi, pas le quoi, dont tu as besoin.

## Un test vert n'a jamais besoin de son pourquoi

Tant qu'un test passe, personne ne lui demande de comptes. Il est vert, on avance. Le pourquoi ne devient vital qu'au moment exact où le test casse. Là, tu dois trancher entre deux verdicts opposés, et tout le reste dépend de ce choix.

Soit tu as introduit une régression : le test protégeait un vrai comportement, ton changement l'a cassé, tu répares ton code. Soit l'attente est périmée : le comportement a légitimement évolué, et c'est le test qu'il faut mettre à jour. Les deux situations allument exactement le même feu rouge. La seule chose qui les distingue, c'est le pourquoi. Sans lui, tu ne débugges pas, tu devines.

Et devine ce que fait un dev pressé devant un test rouge qu'il ne comprend pas. Deux options, aussi mauvaises l'une que l'autre.

Il ajuste son code jusqu'à ce que le test redevienne vert. Peut-être qu'il vient de restaurer une règle métier essentielle. Ou peut-être qu'il vient de se plier à un fossile, de nourrir un test qui ne protège plus rien. Il est le nouveau singe : il respecte l'interdiction de l'échelle sans savoir pourquoi, juste parce que le rouge fait peur.

Ou alors il supprime le test, ou l'assouplit, parce qu'« il est sûrement obsolète ». Peut-être. Ou peut-être qu'il vient de retirer la seule garde sur un comportement discret et coûteux. Le test qui semble inutile est parfois celui qui surveille le pixel de tracking dont dépend la moitié du revenu. Tu ne le sauras qu'en production.

Dans les deux cas, le test censé supprimer le doute est devenu une machine à en fabriquer. C'est ça, une dette déguisée en assurance : ça a la couleur de la sécurité (vert, tout va bien), mais au moment précis où tu comptes dessus, ça ne sait pas te dire ce que ça protège.

## Le quoi s'écrit tout seul, le pourquoi se décide

Le remède ne coûte presque rien. L'assertion dit le quoi ; une ligne dit le pourquoi. Pas un commentaire qui répète le code, ça n'aide personne :

```js
// Vérifie que le prix est 80
test('calculePrix', () => {
  expect(calculePrix(100, 'VIP')).toBe(80);
});
```

Ce commentaire redit le quoi. Il ne dit toujours pas pourquoi 80. Ce qu'il te faut, c'est un nom et une intention qui portent la décision et le risque :

```js
// La remise VIP est plafonnée à 20 %. En dessous de 80, la marge passe sous zéro.
test('plafonne la remise VIP à 20 % pour ne pas vendre à perte', () => {
  expect(calculePrix(100, 'VIP')).toBe(80);
});
```

Même assertion, même 80. Mais cette fois, le jour où le test vire au rouge, tu lis le nom et tu sais quoi faire en trois secondes. Ton changement a fait passer le prix VIP sous 80 ? Tu as cassé le garde-fou de la marge, c'est une régression, tu répares. Le métier a vraiment relevé le plafond ? Tu mets à jour le test *et* sa raison. Le rouge est redevenu une décision au lieu d'une devinette.

## Quand l'IA écrit tes tests, le pourquoi est tout ce qui te reste

Le quoi n'a jamais été aussi bon marché. Donne une fonction à l'assistant, il te sort douze assertions en dix secondes, il couvre des cas limites que tu aurais oubliés, il fait grimper ta couverture sans effort. Sur le quoi, la machine te bat à plate couture.

Mais l'assistant lit le pourquoi dans le code tel qu'il est. Il écrit des tests qui affirment le comportement actuel, sans pouvoir distinguer la règle métier structurante du hasard d'implémentation. Il gravera `toBe(80)` avec le même aplomb qu'il aurait mis pour n'importe quelle autre valeur, et s'il commente, ce sera « vérifie que le prix est 80 » : le quoi, redit. Parce que le pourquoi, le plafond à 20 %, le « vendre à perte », l'incident qui a mené à cette règle, n'est pas dans le code. Il est dans ta tête et dans la mémoire de ta boîte.

Résultat : la génération produit la pire version de l'interdiction du singe, mais à l'échelle. Des centaines d'assertions vertes qui figent le comportement présent comme s'il était tout entier voulu, et pas une qui dise pourquoi. La couverture monte, la compréhension tombe à zéro. Tu hérites d'une suite maximalement verte et maximalement muette.

C'est ça, la bascule. Le quoi est devenu le travail de la machine. Le pourquoi est le tien. La seule chose que tu peux ajouter à un test que l'IA a écrit, la seule qu'elle ne peut pas inférer, c'est la raison pour laquelle il compte. Le junior qui apprend à écrire ce pourquoi ne fait pas un travail de junior : il fait la partie qui ne s'automatise pas.

## Ce que je te conseille

Nomme tes tests par la décision qu'ils protègent, jamais par la fonction qu'ils appellent. `plafonne la remise VIP à 20 %`, pas `calculePrix`. Et si tu es incapable de nommer le pourquoi, ne l'invente pas : c'est le signe que tu ne sais pas encore ce que tu testes. Va le chercher avant d'écrire l'assertion, pas après.

Devant un test rouge que tu n'as pas écrit, ne le rends jamais vert à l'aveugle. Retrouve d'abord son pourquoi : le `git log`, le ticket, la personne. Un vert que tu ne comprends pas ne te protège pas, il t'endort.

Un test sans son pourquoi, ce n'est pas une assurance, c'est une superstition. Et une suite de superstitions, même toute verte, ne te dira jamais le jour où tu casses vraiment quelque chose.

La parabole complète du singe (le versant psychologie, l'expérience d'Asch, ce conformisme qui nous fait éviter l'échelle sans jamais poser la question) est sur mon blog perso : [Et si les singes demandaient pourquoi ?](https://anthony.capirchio.fr/posts/le-singe-du-pourquoi/).

Pour le reste sous le capot : le [test unitaire](/definition/test-unitaire), l'[assertion](/definition/assertion), la [couverture de code](/definition/couverture-de-code), la [régression](/definition/regression) et le [test de non-régression](/definition/test-de-non-regression).


Un test qui vérifie quoi sans dire pourquoi n'est pas une assurance, c'est une superstition. Ce qui se passe le jour où un test vert vire au rouge et que personne ne sait ce qu'il protégeait, et la seule chose que l'IA n'écrira jamais à ta place.

Le singe du pourquoi, édition dev


Un dimanche soir, ma femme remplit un formulaire en ligne pour la retraite de son père. Elle valide. Écran gris : « Erreur technique, veuillez réessayer plus tard. » Elle recommence, change de navigateur, vérifie sa connexion. Toujours le même mur. Le support est fermé, on est dimanche.

Réflexe de vieux dev, j'ouvre la console. Et là, dans la réponse du serveur, en clair : « Le format de l'email n'est pas conforme. » Code 417. Le coupable, trouvé en dix secondes : le « + » dans son adresse, `prenom+retraite@gmail.com`, une adresse parfaitement valide que ce formulaire refusait sans le dire.

Le serveur savait. Il l'avait même écrit. Cette phrase n'est simplement jamais arrivée jusqu'à l'écran.

Ce n'est pas un problème de formulation, ni de gentillesse envers l'utilisateur. C'est une décorrélation : d'un côté un serveur qui connaît la raison exacte du refus, de l'autre un écran qui n'en montre rien. Entre les deux, une frontière. Et la vérité ne l'a pas franchie. La question intéressante n'est pas « pourquoi ce message est nul », c'est « pourquoi l'information s'arrête à la frontière alors qu'elle existe des deux côtés du réseau ».

## Pourquoi la vérité ne passe pas la frontière

Regarde ce qui l'a franchie, justement : le code 417. Il est arrivé jusqu'à la console, intact. Pas par chance : parce que les codes de statut HTTP sont un vocabulaire que le serveur et le navigateur partagent d'avance. 404, 403, 500, les deux camps savent déjà ce que ça veut dire. Un code de statut, c'est un contrat. Il traverse la frontière parce qu'il n'a besoin d'aucune traduction.

La raison précise, elle, voyageait dans le corps de la réponse. Du texte libre. Aucune structure convenue, aucun contrat. Le front reçoit une chaîne de caractères dont il ne sait rien : destinée à l'utilisateur ? technique ? déjà traduite ? fiable ? (Au passage, c'est bien le serveur qui a tranché : le navigateur a laissé passer le « + », le serveur l'a refusé, parce que c'est lui qui valide pour de vrai.) Face à cette incertitude sur le corps, le front fait le choix prudent et paresseux : `catch (e) { afficher("Erreur technique") }`. Un attrape-tout. Il jette la raison parce qu'il ne sait pas quoi en faire, et se rabat sur une phrase qui marche pour tout et ne dit rien.

Voilà la vraie mécanique du mensonge. Ce n'est pas que le serveur se tait : c'est que la moitié de ce qu'il dit n'a pas de contrat pour traverser. Le statut passe, la raison reste à quai. À l'usine, une machine bien faite n'a jamais un seul voyant rouge « panne » : elle a un code pour le bourrage papier et un autre pour le moteur grillé, parce qu'on ne répare pas les deux de la même façon.

## Donne à la raison le même contrat qu'au code

Le remède est déjà sous tes yeux : si le code de statut franchit la frontière, c'est parce qu'il est standardisé. Il suffit d'étendre ce principe. Donne à la raison un contrat, exactement comme le statut en a un.

Concrètement, le serveur arrête de renvoyer du texte libre et renvoie un code d'erreur stable, lisible par une machine, documenté :

```json
{
  "code": "email.plus_non_supporte",
  "field": "email",
  "message": "Le format de l'email n'est pas conforme."
}
```

Ce n'est pas un bricolage maison : c'est le standard Problem Details (RFC 9457, type `application/problem+json`), fait précisément pour qu'une API dise à un client ce qui a échoué, de façon exploitable. Côté front, tu tiens une table qui associe chaque code connu à un vrai message actionnable, dans la langue de l'utilisateur :

```js
const messages = {
  "email.plus_non_supporte":
    "Ton adresse contient un « + », que ce formulaire n'accepte pas. Essaie une adresse sans.",
};

afficher(messages[erreur.code] ?? "Erreur technique, réessaie plus tard.");
```

Tout se joue dans ce `??`. Le message générique n'est plus la réponse par défaut : il devient le filet pour les codes que tu n'as pas encore traduits. Afficher la vérité redevient la règle, la cacher redevient une exception que tu choisis. Ta frontière a maintenant un poste de contrôle : ce qui porte un contrat passe, en clair, jusqu'à l'écran.

Et c'est exactement la partie que l'assistant n'écrira pas à ta place. Demande-lui une gestion d'erreur, il te sortira le `catch` générique, parce qu'il ne connaît pas ton domaine : quels codes d'erreur ton produit expose, ce que tes utilisateurs ont le droit de savoir, ça ne s'infère pas d'un modèle, ça se décide. Le contrat, c'est du savoir métier. Il reste à toi.

## Par quoi commencer demain matin

Prends tes cinq erreurs 4xx les plus fréquentes. Donne à chacune un code stable côté serveur, mappe-les côté front. Une heure de travail, et la moitié de tes « erreur technique » deviennent des phrases qui disent quoi faire. Tu gardes le générique pour les 5xx, là où c'est honnêtement tout ce que tu peux dire : le problème est chez toi, l'utilisateur ne peut qu'attendre.

Ta base de code connaît la vérité bien plus souvent que ton écran ne l'avoue. Elle n'a pas besoin que tu l'inventes. Juste que tu lui donnes un moyen de traverser.

Pour aller sous le capot : le [code de statut HTTP](/definition/code-statut-http), la différence entre [4xx et 5xx](/definition/erreur-4xx-vs-5xx), la [validation côté client ou serveur](/definition/validation), ce qu'est un [message d'erreur](/definition/message-d-erreur) qui sert à quelque chose, et le [cas limite](/definition/cas-limite) qui a tout déclenché.


Ton serveur connaît la raison exacte d'une erreur, ton écran affiche « erreur technique ». Le vrai sujet n'est pas le wording : c'est le contrat qui manque pour que la vérité franchisse la frontière entre le back et le front.

Ne mens pas à tes utilisateurs


Je fais des pizzas maison de temps en temps, et pour progresser, je me suis offert un four à pizza professionnel. Il monte à plus de 400°C. Génial, sauf que l'installer a été un cauchemar : j'ai dû refaire mon tableau électrique et changer de contrat d'énergie, parce que ça ne tenait plus. Et après tout ça, mes pizzas n'étaient toujours pas meilleures qu'au restaurant.

Le four n'y était pour rien. Le problème, c'était la pâte. Que j'achète déjà faite.

Cette histoire un peu bête est la photographie exacte de ce qu'on fait en entreprise. On investit dans l'outil le plus puissant du marché, on se grée comme les GAFAM, et les résultats ne bougent pas. Parce qu'un outil de pointe ne répare pas un fondamental bancal. Il le rend juste plus cher.

## Copier la cuisine des géants

Kubernetes, Kafka, le microservice ultra-scalable : ce sont des fours à 400°C. Ils résolvent des problèmes réels, mais des problèmes de gens qui ont trois mille ingénieurs et des milliards de requêtes. Les adopter dans une équipe de treize devs qui cherche encore son produit, c'est brancher le four avant d'avoir appris à faire la pâte.

Et comme mon installation électrique, chaque outil surdimensionné a un coût caché qu'on découvre après l'achat. Il faut le former, le maintenir, aligner l'équipe et l'organisation autour. Ce que tu croyais être un accélérateur devient un poids : tu passes plus de temps à entretenir ta stack qu'à livrer ce pour quoi tes clients te paient. La complexité que tu t'imposes pour des problèmes que tu n'as pas encore te ralentit sur les problèmes que tu as vraiment.

Au fond, c'est une confusion entre le besoin et l'envie. Tu envies le grand monospace du voisin sans te demander pourquoi il l'a : lui a cinq enfants, toi tu vis seul et tu travailles à distance, un vélo suffirait. En entreprise, c'est pareil. Tu regardes la stack d'une boîte de cinq cents personnes en oubliant que c'est sa taille et ses contraintes qui l'ont dictée, pas son génie. Ce qui la sauve, elle, te noierait, toi.

## Ce que l'IA change

L'assistant rend le piège encore plus tentant. Demande-lui une architecture, il te génère la stack complète des géants sans broncher : le microservice, la file de messages, l'orchestrateur, tout, d'un coup. C'est justement là le danger. La machine sait produire la sophistication ; elle ne sait pas si tu en as besoin. Décider de ce qui est juste pour ta taille, ton équipe et ton moment, c'est le jugement qui te reste, et il n'a jamais eu autant de valeur, parce que le surdimensionnement, lui, n'a jamais été aussi facile à générer.

## Ce que je te conseille

Avant d'adopter un outil, pose-toi une seule question : est-ce qu'il résout un problème qu'on a vraiment, maintenant, ou est-ce qu'on le prend parce que les autres l'ont ? Si tu n'arrives pas à nommer le problème, tu n'as pas besoin de l'outil. Maîtrise tes fondamentaux d'abord, ton code, tes process, ton équipe, avant de vouloir passer à l'échelle quoi que ce soit. Et dimensionne la solution à ta cuisine, pas à celle du restaurant trois étoiles d'à côté.

Un four à 400°C ne sauvera jamais une pâte industrielle. Ce n'est pas l'outil qui fait la qualité, c'est ce que tu sais en faire.


Je me suis offert un four à pizza à 400°C. Mes pizzas ne sont pas meilleures pour autant, parce que le vrai problème, c'était la pâte. La même erreur qu'on fait en copiant la stack des GAFAM sans avoir leurs problèmes.

Ce n'est pas le four, c'est la pâte


À la fin d'un post mortem, il y a presque toujours la petite phrase. Quelqu'un finit par la lâcher, à voix basse : « celui-là, je le sentais venir. » Et tout le monde hoche la tête, parce qu'au fond, plusieurs le sentaient venir. Le savoir existait. Il était là, dans la salle, avant même que ça casse. Il n'est simplement jamais sorti à temps.

C'est ça, le vrai gâchis d'un incident : la plupart du temps, quelqu'un savait.

Le post mortem est devenu un réflexe sain. Après la panne, on revient sur les causes, on tire les leçons, on corrige. C'est nécessaire. Mais c'est une autopsie : ça n'explique bien que ce qui est déjà mort. La question intéressante, c'est de savoir pourquoi on attend le cadavre pour poser des questions qu'on aurait pu poser avant.

## Faire l'autopsie avant le décès

Le pré-mortem, c'est exactement ça : l'autopsie, jouée à l'avance. Tu réunis l'équipe au début d'un projet, et au lieu de demander « quels sont les risques ? » (question à laquelle personne ne répond vraiment), tu poses celle-ci : « on est dans six mois, le projet est un fiasco complet. Qu'est-ce qui l'a tué ? »

L'inversion n'est pas un gadget. « Liste les risques », c'est une question qui met les gens sur la défensive : personne ne veut jouer les oiseaux de mauvais augure. « Le projet a échoué, raconte-moi pourquoi », ça libère la parole, parce que tu ne prédis plus une catastrophe, tu en expliques une déjà posée sur la table. D'un coup, les craintes que chacun gardait pour lui sortent. Le « de toute façon, cette dépendance-là va nous lâcher », le « personne ne comprend vraiment ce module », le « on n'aura jamais le temps de tester ce cas ». Tout ce qui, dans un post mortem, aurait commencé par « je le sentais venir ».

Ensuite, c'est mécanique. Chaque scénario de mort devient une ligne d'action : ce qu'on désamorce tout de suite, ce qu'on surveille, ce pour quoi on prépare un plan B. Tu ne supprimes pas le risque, tu refuses juste d'être surpris par lui.

## Ce que l'IA n'anticipe pas

Demande à un assistant la liste des risques d'un projet, il t'en sort trente, propres, génériques : la dette, les délais, le turnover, la sécurité. Utile comme aide-mémoire, et parfaitement inutile là où ça compte. Parce que le risque qui va vraiment te tuer n'est pas le générique, c'est le spécifique : la dépendance que ton équipe redoute sans oser le dire, le bout de système que tenait la personne qui vient de partir. Ça, ce n'est écrit nulle part. C'est dans la tête des gens, et seule une question bien posée le fait sortir. Le pré-mortem, c'est cette question.

## Ce que je te conseille

Fais-en un au démarrage de chaque projet qui compte : une heure, pas plus. Et refais-en un quand tu sens l'équipe tendue sans savoir pourquoi, parce que cette tension, souvent, c'est un pré-mortem qui demande à avoir lieu. Note chaque « je le sentais venir » comme un risque à traiter maintenant, pas comme une phrase à ressortir le jour de l'autopsie.

Il est toujours moins cher d'imaginer la mort d'un projet que de la constater. Autant faire l'autopsie tant qu'il est encore vivant.

Ce satellite fait partie du dossier [Le modèle du gruyère](/dossier/gruyere), sur la défense en profondeur.


À la fin d'un post mortem, quelqu'un finit toujours par lâcher « je le sentais venir ». Le savoir était là avant le crash. Le pré-mortem, c'est poser la question avant, quand on peut encore agir.

La panne qu'on avait tous sentie venir


Tu cases une fonctionnalité en catastrophe pour tenir la date. Ça rentre, ça marche, tu passes à la suite. Sauf que la suivante est deux fois plus dure à poser : la place où elle devait aller, tu l'as bouchée la veille avec la précédente. Et trois features plus loin, la moindre modification t'oblige à déplacer la moitié de l'existant. Tu n'es plus en train de construire. Tu es en train de perdre une partie de Tetris.

On aime se raconter que développer, c'est du LEGO. Des briques nettes, un plan, tu assembles à ton rythme un ensemble propre et cohérent. C'est l'image qu'on vend dans les conférences. C'est aussi un mensonge réconfortant.

## Le vrai jeu, c'est Tetris

Le LEGO, tu choisis tes pièces, tu as tout ton temps, tu peux défaire et refaire. Rien à voir avec ton quotidien. Dans la vraie vie, les exigences changent en cours de route, les délais se resserrent, et surtout tu ne choisis pas les pièces qui tombent. Une demande arrive, sa forme est imposée, et tu dois la caser dans l'existant sans casser ce qui tourne. Exactement Tetris : tu subis la pièce, tu décides seulement où la poser, et l'horloge accélère.

Et Tetris pardonne mal. Chaque pièce mal placée dans l'urgence laisse un trou, et les trous, ce sont tes dettes : des lignes jamais complétées qui bloquent tout ce qui vient au-dessus. Empile assez vite sans réfléchir, et tu te retrouves avec une structure haute, rigide, où poser la brique suivante relève du casse-tête. La partie ne se perd pas d'un coup. Elle se perd trou par trou, jusqu'au jour où plus rien ne rentre.

## La seule touche qui compte : pause

La tentation, sous pression, c'est d'accélérer : livrer, s'adapter, empiler. C'est le réflexe qui perd la partie. Le bon joueur ne pose pas ses pièces plus vite, il regarde la suivante avant de poser celle du moment. Il garde une vision d'ensemble, il complète ses lignes au lieu de boucher des trous, et il sait qu'appuyer sur pause pour réfléchir n'est pas du temps perdu : c'est ce qui l'empêche de tout reconstruire dans trois semaines.

## Ce que l'IA change

L'IA a mis Tetris en accéléré. Elle génère des pièces plus vite que jamais : tu obtiens en dix minutes ce qui t'aurait pris deux jours. Le problème, c'est que le jeu n'a jamais consisté à produire des pièces, mais à décider où les poser. Générer plus vite ne t'aide pas si tu bouches tes trous plus vite. Ce que la machine ne fait pas, c'est regarder la partie d'en haut et te dire « pas là ». La vision d'ensemble, l'anticipation des coups suivants, c'est ce qui te reste, et c'est ce qui sépare celui qui tient de celui qui sature.

## Ce que je te conseille

Avant de poser une pièce en urgence, prends la seconde qui coûte : est-ce que je complète une ligne, ou est-ce que je crée un trou que je paierai plus tard ? Tu n'auras pas toujours le luxe de bien placer, la pression est réelle. Mais sache au moins quand tu crées un trou, et garde une trace de là où il est. Dans ce jeu, ce n'est pas celui qui pose le plus vite qui gagne. C'est celui qui tient le plus longtemps sans que tout s'écroule.


On aime comparer l'architecture logicielle à un jeu de LEGO : des briques propres qu'on assemble à loisir. La vérité ressemble bien plus à une partie de Tetris sous pression, où tu ne choisis pas les pièces et où l'accumulation finit par tout bloquer.

Tu ne construis pas en LEGO, tu joues à Tetris


Récemment, j'ai arrêté un développement en plein milieu. Pas parce qu'il était bogué : il marchait très bien. Je l'ai arrêté parce que j'ai réalisé que sa seule raison d'exister, c'était une phrase que je m'étais dite à moi-même : « ça pourrait être vachement utile, cette fonctionnalité. » Et cette phrase, chez moi, est presque toujours le début des ennuis.

J'aime coder. Plus exactement, j'aime résoudre des problèmes avec du code, c'est ce qui me fait palpiter. Au quotidien, c'est un avantage. C'est aussi un poison : si mon plaisir est de résoudre des problèmes, alors quelque part, j'aime les problèmes. Et comme beaucoup de devs, il m'arrive de jouer au pompier pyromane, en créant moi-même ceux que je résoudrai ensuite. Pas des bugs, ça n'aurait pas de sens. Des fonctionnalités.

Après tout, qui pourrait me reprocher d'ajouter des fonctionnalités ? C'est toujours bien, une fonctionnalité de plus, non ? Eh bien non. La plupart du temps, non.

## Ce que coûte une feature que personne n'a demandée

Une fonctionnalité, ce n'est jamais juste du code. C'est de la conception, du code, des tests, de la doc, souvent de la refacto pour l'intégrer, et un risque de régression sur tout ce qui marchait avant. Ça prend du temps, ça prend de l'énergie, et ça peut foutre le bazar dans un projet sain. Tout ça pour une idée dont la seule justification est qu'elle serait « excitante à développer ».

La vraie question, à chaque fois, c'est : est-ce que le jeu en vaut la chandelle ? Ou plus honnêtement : est-ce que cette fonctionnalité a un intérêt réel, autre que nourrir mon envie de coder ? Dès que la réponse traîne, il y a une embrouille en approche. Pour me tenir, je m'appuie sur deux garde-fous un peu radicaux.

## YAGNI

*You ain't gonna need it.* Pourquoi ajouter ce dont tu n'auras pas besoin ? L'idée est de se limiter aux fonctionnalités vraiment nécessaires. C'est radical, mais c'est une cure de désintox, parce qu'il est bien question de toxicité : le développement pour l'auto-satisfaction consomme du temps, introduit des régressions, alourdit la dette. Il apporte plus de galères qu'autre chose.

Le test tient en une question : mon projet peut-il vivre sans cette feature ? S'il le peut, elle n'est pas nécessaire. Elle attend, ou elle dégage.

## La philosophie UNIX

*Fais une seule chose, et fais-la bien.* Un programme doit rester dans son domaine et ne pas déborder. `ls` liste le contenu d'un répertoire, point, même s'il a mille options. `ssh` ouvre une connexion, rien d'autre. Tu veux copier un fichier à travers SSH ? `scp` est là pour ça, ce n'est pas le boulot de `ssh`. La force de ces outils, c'est précisément ce qu'ils refusent de faire.

## Attendre le besoin, est-ce arrêter d'anticiper ?

C'est le piège inverse, et c'est là que la tentation de recréer des features non sollicitées revient. Sauf qu'ici, pas d'acronyme, pas de règle. Juste se faire confiance : à son expérience, à sa connaissance du produit. YAGNI et les autres ne sont pas des dogmes à appliquer aveuglément, ce sont des outils pour apprendre à se maîtriser soi-même.

## Ce que l'IA change

Et elle change beaucoup, ici. Avant, l'envie de coder une feature inutile se heurtait au moins à son coût : des jours de boulot, ça refroidit. L'IA vient de faire sauter ce garde-fou. Elle te génère la fonctionnalité tentante en quelques minutes, presque gratuitement. Le frein naturel a disparu. Ce qui veut dire que la seule chose qui protège encore ton projet de l'accumulation, c'est ta décision de ne pas la construire. Savoir dire non à une feature n'a jamais autant compté que depuis qu'il est devenu si facile de dire oui.

## Le meilleur commit est parfois celui qu'on ne fait pas

Le meilleur code que j'aie écrit récemment, c'est celui que je n'ai pas écrit. La prochaine fois qu'une idée te fait de l'œil juste parce qu'elle serait sympa à développer, pose-toi la seule question qui compte : le projet en a-t-il vraiment besoin ? Si tu hésites, tu as ta réponse. Foutre la feature à la poubelle, c'est parfois le meilleur commit de la journée.


J'aime coder, et parce que j'aime coder, il m'arrive de me convaincre qu'une fonctionnalité serait super utile, simplement parce que la développer serait excitant. N'est-ce pas, en réalité, une forme de pollution du projet ?

Et si je foutais cette feature à la poubelle ?

Dans ce billet nous allons revenir sur l’aversion que peuvent avoir les développeurs envers les recruteurs et sur la nécessité de les voir comme des partenaires plutôt que comme des ennemies. 

Désolé pour toi Camarade recruteur si tu passes par là, ça peut sembler très cru, mais autant être très clair et éviter de tourner autour du pot.

## Pourquoi les développeurs détestent-ils les recruteurs ?

Ce n’est ni un secret, ni un tabou. Les développeurs ont tendance à mépriser les recruteurs et soyons honnêtes, pendant longtemps il y a eu des raisons plus que valables d’adopter cette posture. 

Entre la recherche du mouton à 5 pattes, du « Javascript Ninja » ou encore de développeur Java parce que sur le profil il y a écrit Javascript, les prises de contact automatisées par mail ou LinkedIn souvent à côté de la plaque, la difficulté à obtenir des informations de base sur la mission avant un éventuel entretien téléphonique, … Les relations peuvent être assez compliquées. 

Globalement nous avons tendance à avoir le sentiment d’être des marchandises que les recruteurs souhaitent exploiter sans même chercher à comprendre ce que nous faisons ni même ce que nous sommes. 

Il faut cependant être totalement honnête, les recruteurs charcutiers ne sont pas la totalité des recruteurs. Il y a fort heureusement beaucoup d’excellents recruteurs avec une véritable connaissance de la tech et possédant une véritable approche humaine (oui bon ça veut tout et rien dire cette formule, je l’admets volontiers).

## Et si nous devions simplement les considérer comme des apporteurs d’affaire ?

Que nous aimions les recruteurs ou non, qu’ils nous aiment ou non, il ne faut surtout pas perdre de vue le principal : nous faisons du business.

Si dans le contexte d’un poste de salarié nous pourrions avoir une vision totalement différente, pour ce qui est du freelancing, il faut garder à l’esprit que les recruteurs sont des apporteurs d’affaire, des liens entre nous et les clients finaux.

Quand un commercial vient te proposer une mission en régie sur 6 mois avec un TJM de 650€, c’est avant tout un contrat d’environs 80k€ qui t’est proposé. C’est loin d’être négligeable, d’autant plus que ce contrat de 80k€, tu n’aurais probablement pas pu l’obtenir autrement.

Rembobinons.

Comment ça le contrat n’aurait pas pu être obtenu autrement ? 

Il est capital de savoir que pour beaucoup d’entreprises, notamment des grandes entreprises et grands groupes, il faut être référencé comme fournisseur pour pouvoir faire de la prestation. Pour être référencé, il faut répondre à un cahier des charges qui ne pourrait juste pas être défendu par un freelance seul. C’est ainsi que pour pouvoir faire des missions dans certaines entreprises, il n’y a pas le choix : il faut passer par un tiers.

Dans ce contexte, quoi de mieux que d’avoir des partenaires qui viennent te proposer des missions ?

## Comment les free pourraient reprendre l’ascendant

Maintenant que nous avons dressé un petit topo sur le sujet, prenons un instant pour imaginer comment nous, freelances, pourrions reprendre la main sur cette relation qui a souvent tendance à nous écraser un peu.

Ce que je souhaite détailler ici, c’est la mise ne place d’un document qui pourra être partagé directement avec les recruteurs lorsqu’ils prennent contact.

Ce document peut être un PDF ou une page en ligne. En ce qui me concerne, j’ai mis ça sur Notion, sous la forme d’une page publique. De cette manière je peux la partager facilement 

### Informations essentielles

Dans un premier temps, le document commence par les informations essentielles : 

- TJM
- Localisation
- Télétravail (fréquence, si concerné)
- Durée de mission souhaité
- Liens utiles (Github, Linkedin, page Malt, …)

L’idée 

### Critères de mission

Ensuite, définissons clairement ce que nous souhaitons et ne souhaitons pas.

- Quel type d’industrie souhaité ou refusé ?
- Quel type de mission, stack, responsabilité, … ?
- Quelle localisation, fréquence de remote ?
- Quel TJM ?
- …

Bref, l’idée ici est de lister très clairement ce que l’ont veut et ne veut pas. Attention, les nuances sont importantes. Il y a ce que l’ont veut et ce que l’ont souhaite, ce que l’ont ne souhaite pas et ce que l’ont refuse.

Il est également utile de préciser ce sur quoi il est possible de négocier, par exemple : 

> Sur site maximum 2x par semaine (idéalement 1x ou roulement 2x toutes les deux semaines).
Possible d’être sur site un peu plus longtemps au démarrage de la mission.
> 

Ensuite, il est nécessaire de proposer une synthèse de son profile, idéalement en un paragraphe. Les expériences détaillées viennent à la fin du document, par besoin de noyer le lecteur dans trop d’information dès le départ.  

### Prise de rendez-vous

Ce document, finalement, c’est un tunnel de vente. Un tunnel de vente doit mener à une action. Dans notre cas, l’action c’est une prise de rendez-vous. 

Vous pouvez inclure le widget d’un outil comme Calendly qui permettra de gérer tout le processus de prise de rendez-vous. Concrètement, vous liez votre agenda à l’outil pour empêcher la prise de rendez-vous à des moments où vous n’êtes pas dispo. Il est également possible (nécessaire) de déterminer des créneaux pour les prises de rendez-vous. Par exemple, le 10h a 11h et de 16h à 17h du mardi au jeudi. 

Il existe encore pas mal de fonctionnalités comme la création de visio automatique, le rappel de rdv aux participants ou encore l’ajout de périodes impossible à réserver avant et après un événement. 

De cette manière, il est possible de laisser au recruteur la possibilité de poser un rendez-vous de 10/15 minutes à un moment qui vous convient. 

### CV

C’est la fin du document. Il faut, c’est à ce moment que le contenu le plus imposant peut être placé, comme une forme d’annexe. 

Bien que le CV soit proposé au téléchargement au début du document, il peut être utile de laisser la possibilité au recruteur de le voir directement dans le document sans avoir à télécharger quoi que ce soit.


Dans ce billet nous allons revenir sur l’aversion qu’ont les développeurs envers les recruteurs et sur la nécessité de les voir comme des partenaires plutôt que comme des ennemies.  Nous terminerons par une réflexion sur le rôle des recruteurs et sur l’évolution de celui-ci dans les années à venir. 

En tant que Freelance, faut-il haïr les recruteurs ?


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é ?