Reprendre un projet abandonné : ce que je regarde avant de m'engager
Prestataire disparu, associé technique parti, projet interne à l'arrêt — avant de décider s'il faut reprendre, réparer ou reconstruire, voici l'audit que je fais systématiquement.
Le réflexe de tout jeter est presque toujours une erreur coûteuse
Un prestataire qui disparaît, une agence qui livre à moitié puis ne répond plus, un associé technique qui quitte l'aventure : la situation est plus fréquente qu'on ne le pense, et le premier réflexe — "le code est probablement mauvais, repartons de zéro" — est rarement justifié. Même un projet imparfait contient de la valeur : des choix de conception, une logique métier déjà implémentée, des données existantes, une interface déjà pensée par des utilisateurs réels. Avant de trancher, il faut évaluer ce qui existe.
L'audit technique répond à quatre questions, pas plus
Le code est-il exploitable ? Structure compréhensible, technologies encore maintenues, présence ou non de tests et de documentation.
Les accès sont-ils récupérables ? Hébergement, base de données, services tiers — le blocage le plus fréquent n'est pas le code, c'est la perte d'accès à ce qui le fait tourner.
Quelle est la dette technique réelle ? Les raccourcis pris, les risques de sécurité identifiables, ce qui est fragile et proche de la rupture.
Quel est l'écart entre l'existant et l'objectif ? Ce qui reste à faire pour arriver à un produit fiable, pas juste fonctionnel en apparence.
Trois issues possibles, et aucune n'est un échec
Le code peut être largement récupérable : le projet est construit de façon cohérente, avec des points précis à corriger, et le développement reprend là où il s'est arrêté sans perdre le travail déjà réalisé — c'est le cas le plus favorable.
Il peut être partiellement récupérable : certaines parties tiennent, d'autres non. On garde ce qui fonctionne, on reconstruit le reste, avec du discernement sur où placer la frontière entre les deux.
Ou il peut être préférable de repartir de zéro — quand le code est trop mal structuré, la technologie trop obsolète, ou les fondations trop fragiles pour que la correction coûte moins cher que la reconstruction. Ce n'est pas une catastrophe : les maquettes, la logique métier déjà validée et les retours des premiers utilisateurs restent acquis, et la reconstruction va bien plus vite que la première tentative parce que l'ambiguïté produit a déjà été résolue.
Sécuriser les accès avant tout le reste
Rien n'avance sans ça : le code source sur une plateforme partagée, les accès aux serveurs et à l'hébergement, la base de données, les services tiers (paiement, emails, stockage), le nom de domaine et les certificats. Tant que ces accès ne sont pas entre les mains du porteur de projet, personne ne peut reprendre quoi que ce soit — et c'est systématiquement la première urgence, avant même de juger la qualité du code.
Pour la suite, un principe simple évite de revivre la situation : tous les accès doivent être détenus au nom du porteur de projet, jamais sur les comptes personnels d'un prestataire.
Le plan de reprise se construit dans un ordre précis
Une fois l'audit fait et les accès sécurisés, l'ordre compte plus que l'exhaustivité : d'abord les corrections urgentes — sécurité, bugs critiques, ce qui impacte directement les utilisateurs. Ensuite la stabilisation, pour que le produit fonctionne de façon fiable et prévisible. Les nouvelles fonctionnalités viennent en dernier, jamais en même temps que la stabilisation — vouloir tout faire de front est la façon la plus sûre de rallonger la reprise.
Un projet abandonné n'est jamais un point de départ vierge. C'est un point de départ avec des inconnues à lever avant de pouvoir avancer vite — et l'audit sert exactement à ça : transformer les inconnues en décisions.