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. Le vocabulaire à emporter : la documentation vivante, la connaissance tribale, le SPOF, la source de vérité et le sachant.