Reprendre un projet sans documentation, c’est reconstituer l’intention d’un système à partir de son seul comportement observable. Pas de spécifications, pas de schéma d’architecture, pas de note du prédécesseur : le code et son environnement d’exécution sont la totalité de ce dont vous disposez. Un prestataire qui part sans un mot, un développeur unique devenu injoignable, et vous voilà avec un dossier, un accès SSH, rien d’autre. J’ai repris des projets dans cet état une bonne dizaine de fois.
La tentation, à ce moment, est toujours la même : ouvrir l’éditeur et chercher à tout comprendre d’un coup. Je l’ai eue aussi. C’est une fausse piste. Le code est bien la seule vérité disponible, mais on ne le fait pas parler en se jetant dessus le premier jour. On commence par se mettre à l’abri. Ce travail-là ne touche presque pas au code lui-même.
Sans documentation, le code est la seule vérité. Avant d’y toucher, je sécurise le présent : récupérer les accès, mettre le code dans un Git propre, rendre l’environnement reproductible, vérifier qu’une sauvegarde se restaure. Comprendre l’application vient après ; la modifier, plus tard encore.
L’urgence, avant la moindre ligne lue, c’est l’inventaire des accès. Tout ce qui permet de garder le projet en vie : serveurs, dépôt, base de données, noms de domaine, comptes de services tiers, certificats. Pour chacun, une seule question : est-ce que j’y ai la main, ou est-ce que je peux la reprendre ? Un maillon manquant suffit à rendre l’édifice fragile. Le jour où ce mot de passe se perd, où ce certificat expire sans alerte, le projet peut se retrouver injoignable d’un coup. J’ai vu un site marchand tomber deux jours durant parce que son domaine se renouvelait sur la boîte mail personnelle d’un développeur parti, à laquelle plus personne n’avait accès. Tant que les accès ne sont pas entre vos mains, le reste peut attendre.
Vient ensuite le code, qui arrive rarement avec un historique exploitable. Parfois aucun Git : une archive ZIP, ou le contenu du serveur de production récupéré tel quel. Je le place dans un dépôt propre, avec un premier commit qui fige l’état reçu. Ce geste, anodin en apparence, débloque deux choses immédiatement. Un point de référence stable d’abord, cet état initial que je peux toujours retrouver intact. Et la liberté de modifier sans la peur au ventre, puisque chaque changement devient traçable et qu’un git revert ramène toujours à l’état d’avant. Sans ce filet, on n’ose toucher à rien. Un projet auquel on n’ose pas toucher est déjà mort.
Reste l’environnement. Un projet qui ne tourne que sur la machine de son auteur disparu vous laisse prisonnier de la prod : impossible d’expérimenter quoi que ce soit sans risquer le site en ligne. Je reconstitue donc un environnement de développement qui démarre ailleurs, de façon fiable, conteneurisé quand le projet s’y prête, ce qui évite les classiques « ça marche chez moi ». L’objectif tient en une phrase : lancer le projet sur ma machine, ou sur n’importe quelle autre, sans dépendre du serveur de production. Ce point réclame parfois une journée entière, surtout quand les versions de PHP ou de la base ne sont écrites nulle part et qu’il faut les retrouver par tâtonnements. Le temps qu’on y passe se rembourse au premier incident évité.
Et juste avant la première vraie modification, une dernière vérification, qu’on oublie presque toujours : existe-t-il une sauvegarde de la production, et surtout, est-ce qu’elle se restaure ? Une sauvegarde jamais restaurée ne protège de rien. C’est un fichier dont on espère qu’il fera l’affaire le jour venu, et l’espoir n’est pas une stratégie de reprise. On ne pose pas la main sur un système hérité sans pouvoir revenir en arrière pour de vrai.
Accès repris, code versionné, environnement qui démarre ailleurs, sauvegarde testée : le présent est sécurisé. C’est alors, et alors seulement, qu’on peut cartographier ce que fait l’application, suivre les flux, repérer les zones risquées, sereinement, parce qu’une erreur de lecture ne coûte plus la survie du projet. Reprendre un projet, ça ne commence pas par le code. Ça commence par se ménager un cadre où l’on a le droit de se tromper.
Un exemple pour finir, parce qu’il résume tout. L’an dernier, on me confie une application de gestion interne, sans aucune doc, le développeur parti depuis six mois. Je passe trois jours à ne rien « produire » : accès rapatriés au nom de la société, code mis sous Git, environnement reconstruit. Le quatrième jour, je teste la sauvegarde. Elle ne se restaure pas. Un chemin codé en dur pointait vers un dossier qui n’existait plus sur le nouveau serveur. La sauvegarde tournait toutes les nuits depuis deux ans, personne n’aurait pu s’en servir. Si j’avais commencé par modifier le code, comme on me pressait de le faire, la première vraie panne aurait été la dernière.