Reprendre un projet abandonné : par où commencer

Le prestataire est parti. Le projet est à l'arrêt. Et maintenant ?

C'est une situation plus fréquente qu'on ne le pense. Un développeur freelance qui disparaît du jour au lendemain. Une agence qui livre un produit à moitié fini puis ne répond plus. Un associé technique qui quitte l'aventure. Un projet interne laissé en jachère faute de ressources.

Vous vous retrouvez avec du code, peut-être un produit partiellement fonctionnel, et aucune idée de ce qu'il faut faire. Voici comment aborder la situation.

Étape 1 : Ne pas paniquer (ni tout jeter)

Le premier réflexe de beaucoup de fondateurs, c'est de vouloir tout recommencer de zéro. "Le code est probablement nul, on repart à neuf." Parfois c'est vrai. Mais souvent, c'est une erreur coûteuse.

Même un projet imparfait contient de la valeur : des choix de conception, une logique métier implémentée, des données existantes, une interface déjà pensée. Avant de tout jeter, il faut évaluer ce qui existe.

Étape 2 : L'audit technique

C'est la première chose que je fais quand un client me contacte pour reprendre un projet. Je prends le temps d'examiner ce qui existe pour répondre à quelques questions clés :

Le code est-il exploitable ? Est-ce que le code est structuré de manière compréhensible ? Est-ce qu'il utilise des technologies encore maintenues et supportées ? Est-ce qu'il y a des tests ? De la documentation ?

L'infrastructure est-elle en place ? Où est hébergée l'application ? Avez-vous accès aux serveurs, aux bases de données, aux différents services utilisés ? Parfois, le plus gros problème n'est pas le code mais le fait que les accès sont perdus.

Quelle est la dette technique ? Quels sont les raccourcis qui ont été pris ? Quels sont les risques de sécurité ? Qu'est-ce qui est fragile et risque de casser ?

Quel est le gap entre l'existant et votre objectif ? Combien de travail reste-t-il pour arriver à un produit fonctionnel et fiable ?

Étape 3 : Les trois scénarios

Après l'audit, on se retrouve généralement dans l'un de ces trois cas :

Scénario A : Le code est récupérable

Le projet est bien construit dans l'ensemble, avec quelques problèmes à corriger. On peut reprendre le développement là où il s'est arrêté, corriger les problèmes identifiés, et avancer.

C'est le meilleur cas. Le coût de reprise est modéré et vous ne perdez pas le travail déjà réalisé.

Scénario B : Le code est partiellement récupérable

Certaines parties du projet sont solides, d'autres sont inutilisables. On garde ce qui fonctionne, on reconstruit le reste. C'est une approche hybride qui demande du discernement pour savoir où mettre la frontière.

Scénario C : Il vaut mieux repartir de zéro

Le code est tellement mal écrit, la technologie tellement obsolète, ou les fondations tellement bancales qu'il serait plus coûteux de corriger que de reconstruire.

Ce n'est pas une catastrophe. Même dans ce cas, le travail précédent n'est pas perdu : vous avez les maquettes, la logique métier, les retours utilisateurs, et une vision beaucoup plus claire de ce que vous voulez. La reconstruction sera bien plus rapide que la première tentative.

Étape 4 : Sécuriser les accès

Avant toute chose, assurez-vous que vous avez accès à tout :

Le code source (idéalement sur une plateforme comme GitHub ou GitLab)
Les serveurs et l'hébergement
La base de données
Les services tiers (paiement, emails, stockage...)
Le nom de domaine et les certificats de sécurité

Si vous n'avez pas ces accès, c'est la priorité absolue. Sans eux, personne ne peut reprendre le projet.

Conseil pour l'avenir : tous les accès doivent être à votre nom, sur vos comptes. Jamais sur les comptes personnels de votre prestataire.

Étape 5 : Définir un plan de reprise

Une fois l'audit fait et les accès sécurisés, on construit un plan concret :

Les corrections urgentes : sécurité, bugs critiques, problèmes qui impactent les utilisateurs
La stabilisation : remettre le produit en état de fonctionner de manière fiable
Les évolutions : reprendre le développement des nouvelles fonctionnalités

L'erreur serait de vouloir tout faire en même temps. On stabilise d'abord, on avance ensuite.

Comment éviter cette situation à l'avenir

Quelques principes simples :

Tous les accès à votre nom : code, hébergement, services
Un point régulier : ne laissez jamais plus de 2 semaines sans nouvelles de votre prestataire
De la documentation : insistez pour qu'il y ait un minimum de documentation technique
Pas de dépendance exclusive : le code doit être compréhensible par un autre développeur

Votre projet est à l'arrêt et vous ne savez pas par où commencer ? Contactez-moi pour un audit de l'existant.