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


« 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.

L'autodidacte

Toutes les publications

Le serveur que tu n'oses pas redémarrer

Trois paquets avant de se parler

DNS, le premier mensonge du web

La carte que le code ne dessine pas

Le singe du pourquoi, édition dev

Ne mens pas à tes utilisateurs