Reprendre un projet existant : les dix vérifications d’entrée

Les quatre contrôles qui décident

Quatre éléments suffisent à savoir si une reprise est envisageable. S’il en manque un, le premier travail consiste à le reconstituer, et c’est un chantier en soi.

1. Les sources complètes, avec leur historique, pas une archive datée.
2. La capacité à reconstruire l’application depuis zéro, sur une machine neuve.
3. La capacité à la déployer, avec la procédure réellement utilisée.
4. Les secrets et accès : qui les détient, où sont-ils stockés, comment les changer.

Six contrôles qui chiffrent l’effort

La troisième ligne réserve les plus mauvaises surprises. Un correctif appliqué directement sur un serveur, jamais commité, disparaît au premier déploiement — et le bug revient sans que personne comprenne pourquoi.

Ce qu’il ne faut pas faire les premières semaines

La tentation est de réécrire ce qu’on ne comprend pas. C’est presque toujours prématuré : le code étrange encode souvent une règle métier réelle, apprise dans la douleur, que personne n’a documentée.

Commencez par rendre le système observable : journaux exploitables, mesure des erreurs, capacité à rejouer un cas. Vous saurez alors ce qui casse réellement, plutôt que ce qui a l’air fragile.

Formaliser ce qui a été trouvé

Un état des lieux daté, partagé avec le client, protège les deux parties. Il distingue ce qui a été constaté, ce qui reste à explorer faute d’accès, et ce qui a été corrigé dès l’entrée.

Ce document sert aussi de référence lorsqu’un défaut apparaît trois mois plus tard : il permet de savoir s’il était présent à la reprise ou introduit depuis, question qui devient vite conflictuelle sans trace écrite.

On ne reprend pas un logiciel : on reprend un système, ses accès, son historique et les connaissances des personnes qui l’ont fait vivre.