On croit volontiers qu’une bonne documentation dispense de cartographier une application reprise. C’est faux, et de loin. Une doc, même soignée, décrit ce que ses auteurs voulaient construire, à un instant donné. Pas ce que le système fait aujourd’hui. Entre les deux, il y a eu quatre ans de correctifs en urgence, un développeur parti sans rien dire, une fonction désactivée un vendredi soir et jamais réactivée. Quand on me confie une application que plus personne ne comprend, la doc qui l’accompagne (quand elle existe) m’intéresse comme témoignage historique, pas comme source de vérité. Ce qui compte, c’est le comportement réel, et il ne se lit pas dans un fichier Word oublié sur un partage réseau.
Pour le reconstituer, je croise trois sources qui ne mentent pas de la même manière : le code, le système en marche, et les gens qui s’en servent.
Une doc décrit une intention, pas un comportement. Je reconstitue le réel en lisant le code par ses points d’entrée, en observant le système tourner et en écoutant ceux qui s’en servent. Quand les sources divergent, c’est le runtime qui tranche.
Le code reste la référence. Le lire du début à la fin, en revanche, est le meilleur moyen de se noyer en deux jours. J’attaque par les points d’entrée. Les routes et URL exposées me disent ce que l’application reçoit du dehors ; les tâches planifiées, ce qu’elle déclenche seule à heure fixe ; les files et événements consommés, ce à quoi elle réagit. Pour chacun, je tire le fil : quelles données sont lues, lesquelles sont écrites, quels services appelés au passage. Les flux principaux se reconstituent ainsi, sans qu’il faille tout comprendre.
Mais le code décrit seulement ce qui peut se produire. Ce qui arrive vraiment, seul le runtime le montre (le système en train de tourner pour de bon, par opposition au code lu au repos), et l’écart surprend presque à chaque fois. La base de données d’abord : ses tables, leurs relations, et surtout ce qui est réellement rempli. Sur une vieille appli de gestion reprise il y a deux ans, le schéma comptait plus de quarante tables ; une douzaine à peine portaient des lignes récentes. Le reste appartenait à des fonctions mortes depuis longtemps. Un schéma bien lu raconte le métier mieux que n’importe quel commentaire. Viennent ensuite les journaux, qui livrent les erreurs récurrentes et les chemins effectivement empruntés, y compris ce que l’appli fabrique à trois heures du matin quand personne ne regarde. Et puis les flux réseau, qui révèlent avec quels services externes elle dialogue pour de bon. C’est souvent là qu’on tombe sur l’intégration oubliée : ce connecteur vers un prestataire de paiement que plus personne n’avait en tête, toujours en place, toujours en train d’émettre des requêtes.
Reste la source qu’on néglige le plus : les gens. Ceux qui utilisent l’application savent ce qu’elle fait pour eux sans en avoir lu une ligne. Un quart d’heure avec un utilisateur métier vous apprend quelles fonctions comptent vraiment et quelles bizarreries chacun a intégrées sans le formuler — « il faut valider dans cet ordre-là, sinon ça plante ». Ce savoir d’usage ne se trouve nulle part ailleurs. Pendant tout ce travail, je consigne au fil de l’eau ce qui n’était écrit nulle part : les flux et les pièges, et surtout les dépendances cachées. Pas un beau document, un simple fichier de notes. Il finit souvent par devenir la première documentation honnête du projet et m’évite de refaire deux fois la même enquête.
Un exemple pour finir. L’an dernier, je reprends une application de facturation chez un petit éditeur. La doc, datée, affirmait que les relances clients partaient « tous les premiers du mois ». J’ai regardé tourner le système : aucune relance n’était sortie depuis sept mois. La tâche planifiée existait toujours dans le code, intacte, mais une mise à jour du serveur de messagerie avait changé un identifiant que personne n’avait reporté. Le code disait vrai, la doc aussi en un sens, et pourtant rien ne partait. Si je m’étais fié au papier, j’aurais cherché un bug là où il n’y en avait pas. C’est le système en marche qui a posé la bonne question, et la réponse tenait dans une variable d’environnement périmée.