Prestataire disparu, code que personne ne comprend : reprendre un projet orphelin

Par où commencer quand le prestataire a disparu ?

Le réflexe est de vouloir « corriger » tout de suite. C'est une erreur. On ne modifie pas un code qu'on ne comprend pas encore : le risque de casser une fonction invisible est trop élevé.

Ma première étape est un état des lieux froid, en trois volets :

• Les accès. Qui possède le compte cloud, le nom de domaine, le dépôt de code, la base de données ? Sans ces clés, aucune reprise n'est possible. C'est souvent le point de blocage numéro un.

• Le code source. Existe-t-il un dépôt versionné (Git) ou seulement des fichiers sur un serveur ? Un historique de commits raconte l'histoire du projet ; son absence est déjà une information.

• La production. Où tourne l'application, sous quelle version, avec quelles dépendances ? Je documente l'existant avant d'y toucher.

À la fin de cette phase, vous savez exactement ce que vous possédez. C'est le socle de toute décision.

Comment auditer un code que personne ne comprend ?

Un code orphelin n'est pas forcément un mauvais code. Il est simplement sans mémoire humaine. L'audit consiste à reconstituer cette mémoire.

Concrètement, je procède ainsi :

• Lecture de la structure avant les détails. J'identifie l'architecture, les points d'entrée, les modules métier. Comprendre la carte avant les rues.

• Repérage des dépendances. Bibliothèques obsolètes, versions non maintenues, services externes appelés en dur. Chaque dépendance est un risque potentiel.

• Recherche des zones sensibles. Gestion des paiements, authentification, données personnelles. Ce sont les endroits où une erreur coûte cher.

• Tests de non-régression minimaux. Avant toute modification, je pose quelques tests sur les parcours critiques pour détecter une casse immédiatement.

L'objectif n'est pas de tout comprendre d'un coup, mais de rendre le code navigable et modifiable en sécurité.

Faut-il reprendre l'existant ou tout réécrire ?

C'est la question qui coûte le plus cher quand on y répond trop vite. La réécriture complète séduit — repartir « propre » — mais elle efface aussi des années de règles métier apprises à la dure, souvent invisibles dans un cahier des charges.

Je tranche sur des critères concrets, pas sur une intuition :

• Reprendre quand le code fonctionne, que la logique métier est riche et que la dette technique est circonscrite. On stabilise, on documente, on fait évoluer.

• Réécrire partiellement quand un module précis est bloquant mais que le reste tient. C'est le cas le plus fréquent.

• Réécrire entièrement uniquement quand la technologie est morte, la sécurité compromise, ou le coût de maintenance supérieur au coût de reconstruction.

Dans la majorité des dossiers, la bonne réponse est la reprise progressive. Elle préserve ce qui marche et concentre l'effort là où il compte.

Comment sécuriser un projet pour qu'il ne redevienne jamais orphelin ?

Reprendre un projet abandonné ne suffit pas : il faut supprimer les conditions qui l'ont rendu vulnérable. Un projet devient orphelin quand tout repose sur une seule tête sans trace écrite.

Ce que je mets en place systématiquement :

• Récupération et centralisation des accès à votre nom, jamais à celui d'un intermédiaire. Vous restez propriétaire de vos actifs.

• Documentation vivante : architecture, procédures de déploiement, points de vigilance. Assez pour qu'un tiers puisse reprendre demain.

• Automatisation du déploiement pour supprimer les manipulations manuelles risquées et non reproductibles.

• Sauvegardes vérifiées — une sauvegarde jamais testée n'est pas une sauvegarde.

C'est précisément ma promesse : un seul responsable, de la stratégie au code en production, mais un projet documenté pour ne dépendre de personne. La fin du bus-factor.

Combien de temps et à quel coût reprendre un projet abandonné ?

La durée dépend de l'état réel du projet, que seul l'audit révèle. Un audit initial se mène généralement en quelques jours ; la stabilisation en quelques semaines ; les évolutions ensuite, au rythme de vos priorités.

Les ordres de grandeur varient selon la taille de la base de code, la qualité de l'existant et l'urgence en production [À COMPLÉTER]. Ce que je peux garantir, c'est la méthode : d'abord comprendre, puis stabiliser, enfin faire évoluer — dans cet ordre, sans le brûler.