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


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 ?

L'autodidacte

Methodo