C'est une situation qui revient souvent en prestation : on m'appelle sur un système existant, écrit par une équipe qui n'est plus là, dans un langage que je n'utilise pas tous les jours, pour un métier que je découvre. Le réflexe naturel serait de commencer par tout lire. C'est le plus sûr moyen de perdre trois semaines.
Chercher d'abord ce qui est exécutable
Avant de lire une ligne de code, je cherche à faire tourner quelque chose. Compiler, lancer, obtenir un comportement observable, même partiel. Un système qu'on ne sait pas exécuter reste une abstraction, et toute analyse menée dessus est une hypothèse.
Cette étape révèle immédiatement l'état réel du projet : si la chaîne de compilation est cassée, si des dépendances ont disparu, si la procédure de déploiement existe. Ce diagnostic vaut plus que n'importe quel audit documentaire.
Identifier qui détient l'information non écrite
Dans tout projet ancien, une part de la connaissance n'a jamais été consignée. Elle se trouve chez le technicien de production qui connaît les cas limites, chez le responsable produit qui se souvient pourquoi telle contrainte a été acceptée, chez l'ancien développeur toujours joignable.
Ces personnes sont le vrai chemin critique des premiers jours. Le code dit ce que le système fait ; elles seules disent pourquoi.
Reconstruire la spécification a posteriori
Sur un projet non documenté, j'écris la spécification qui manque, telle que le système se comporte réellement. Ce document devient le point de comparaison avec ce que le client croit avoir. L'écart entre les deux est généralement le cœur de la mission.
Produire un livrable réel, vite
Je m'impose de livrer quelque chose d'utile dans les deux premières semaines : une correction, une fonction attendue, un banc de test. Pas un rapport d'analyse.
Un livrable réel oblige à traverser toute la chaîne — comprendre, modifier, tester, déployer — et met en évidence les points de blocage que l'analyse seule ne fait jamais apparaître. C'est aussi ce qui installe la confiance avec l'équipe en place, qui a vu passer d'autres intervenants avant moi.
Il n'y a pas de raccourci : reprendre un système inconnu prend du temps. Mais l'ordre dans lequel on s'y prend change beaucoup l'issue — exécuter avant de lire, parler avant d'analyser, livrer avant de conclure.