On m'a déjà refilé une application critique dont plus personne ne savait comment elle marchait. Elle tournait, elle tenait la charge, une partie de la boîte en dépendait. Un détail : les deux personnes qui l'avaient écrite étaient parties. La doc décrivait une version qui n'existait plus. Le code compilait, et plus personne de vivant ne savait vraiment pourquoi il était fait comme ça. Une boîte noire en état de marche, avec pour seul mode d'emploi le code lui-même. Ma première tâche n'a pas été d'écrire une ligne. Elle a été de comprendre ce que j'avais devant moi.
On t'a appris à écrire du code. À l'école, dans les tutos, sur les projets perso, tout ton apprentissage était tourné vers une seule direction : produire, faire sortir du neuf. Personne ne t'a appris l'autre moitié du métier, celle que tu passes vraiment tes journées à faire une fois en poste : lire du code que tu n'as pas écrit, reconstruire l'intention derrière un système opaque, deviner pourquoi un morceau tient de telle façon avant d'oser y toucher. On forme des gens à bâtir du neuf, et on les lâche dans un monde fait de bien plus d'ancien que de neuf.
Longtemps, ça passait : tu finissais par connaître ton système à force d'y vivre. Sauf que l'IA vient de casser cet équilibre. Quand la génération crache du code plus vite que quiconque ne peut le relire, le goulot d'étranglement du métier se déplace. Ce n'est plus l'écriture qui est rare et chère, c'est la compréhension. Relire, cartographier, interroger un système que tu n'as pas produit : voilà la compétence qui prend de la valeur pendant que l'écriture en perd. C'est le pari de ce dossier. On y parle d'une seule chose : comment prendre la mesure d'un système dont tu n'as ni les auteurs, ni la doc, ni le droit à l'erreur.
Dans quel ordre lire ce dossier
D'abord, faire une carte. « La carte que le code ne dessine pas » explique pourquoi une carte de ce que le système fait, pour qui et avec quels mots, bat une carte de ses services et de ses flèches, et comment tracer la tienne, seul, en un après-midi, sans mobiliser les rares experts encore là.
Ensuite, faire parler. « Faire avouer un système » réunit les questions qui font parler le code et les humains autour de lui, celles qui ne télégraphient pas leur réponse, pour extraire ce qu'aucune documentation n'a jamais écrit.
Ce dossier se construit
Il n'est pas terminé, et je préfère te le dire que te vendre un sommaire complet que je ne tiendrai pas. D'autres pièces viendront : remonter à une décision d'architecture à partir de ses seules traces, suivre un flux de données d'un bout à l'autre, savoir quand arrêter de comprendre et commencer à changer. Je les ajouterai ici quand elles existeront, pas avant.
Le vocabulaire à garder sous la main pour toute la suite : le legacy, la dette technique, le couplage et la cohésion, la boîte noire et la rétro-ingénierie.