Vous venez de récupérer un projet : un dépôt Git, peut-être une application en production, et personne pour vous expliquer comment tout cela tient. Avant de décider quoi que ce soit (corriger, continuer ou repartir), il faut savoir ce que vous avez entre les mains. C’est le rôle d’un audit. Voici comment je m’y prends, dans l’ordre.
Ce qu’un audit doit répondre
Trois questions, pas trente : qu’est-ce qui fonctionne, qu’est-ce qui est risqué, et combien il reste à faire. Tout le reste en découle.
1. Faites-le tourner
Avant de lire une seule ligne, essayez de lancer le projet en local. Installation des dépendances, variables d’environnement, base de données : est-ce que ça démarre ? Si ce n’est pas le cas, vous tenez déjà une information importante. Un projet qu’on ne sait pas reproduire, c’est le premier chantier, avant même la moindre fonctionnalité.
2. Lisez l’architecture avant le détail
On comprend un projet par sa forme d’ensemble, pas en ouvrant les fichiers un par un. Regardez la structure des dossiers, la stack, les dépendances, la façon dont les morceaux communiquent entre eux. En une heure, vous savez si vous avez affaire à quelque chose de propre et lisible, ou à un plat de spaghettis.
3. Cherchez la dette et les risques
Quelques signaux parlent vite : des dépendances en retard de plusieurs versions majeures, aucun test sur les parcours critiques, des secrets (mots de passe, clés d’API) écrits en clair dans le code, des « TODO » abandonnés aux endroits sensibles. Ce ne sont pas des détails. Ce sont eux qui décident du coût des semaines à venir.
4. Regardez ce qui n’est pas dans le code
Un projet ne se résume pas à son dépôt. Où tourne la base de données ? Qui détient les accès ? Comment se fait le déploiement ? Existe-t-il des sauvegardes ? Les vraies fragilités se cachent souvent là, hors du code, dans l’infrastructure que personne n’a documentée.
5. Sortez un verdict actionnable
Un audit qui se termine par « c’est compliqué » ne sert à rien. À la fin, vous devez avoir en main : ce qui est conservable, ce qui est à reprendre, les risques classés par gravité, et un ordre de grandeur de temps. De quoi décider, pas de quoi vous inquiéter.
Ce qu’un bon audit n’est pas
Ce n’est pas un devis de réécriture déguisé. Quelqu’un qui, après deux heures, conclut qu’il faut tout refaire vous vend une réécriture, pas un diagnostic. La plupart du temps, une bonne partie du code est parfaitement récupérable.
Un code hérité fait peur surtout parce qu’il est inconnu. Une fois l’audit fait, il redevient un projet normal : une liste de tâches et un chemin clair. C’est la première étape de toute reprise de projet que je prends en main.
Vous avez récupéré un projet et vous ne savez pas ce qu’il vaut ? Faites un audit. Je vous rends un état des lieux clair et ce qu’il reste vraiment à faire.
Questions fréquentes
Combien de temps prend un audit ? De quelques heures à deux ou trois jours selon la taille du projet. Le but est un diagnostic, pas une exploration ligne par ligne.
Faut-il donner accès à tout ? Idéalement oui : le code, l’hébergement, la base de données. Mais on peut commencer avec le seul dépôt et compléter ensuite.
L’audit est-il payant ? Un premier regard est gratuit lors de l’appel. Un audit approfondi, avec rapport écrit, est une prestation à part entière, à prix fixe.