Dans Vinland Saga, Thorfinn passe la première partie de l'histoire à vouloir détruire. Puis il comprend que la vengeance ne construit rien, et le reste du récit le montre en train de défricher, semer, bâtir. C'est le même personnage, avec une énergie retournée.
Reprendre un projet existant demande exactement ce retournement. Le premier réflexe, face au code d'un autre, est de vouloir tout raser. C'est presque toujours la mauvaise décision.
Une bonne moitié de mes missions consiste à reprendre un produit commencé par quelqu'un d'autre — développeur parti, agence en fin de contrat, prestataire qui ne répond plus. Voici la méthode que j'ai fini par stabiliser.
Jour 1 : faire tourner, ne rien juger
Le premier objectif est unique : avoir le projet qui démarre en local, sans modifier une ligne de logique.
Ça paraît trivial. Ça prend souvent la journée entière. Variables d'environnement non documentées, version de Node incompatible, base de données à peupler, service tiers dont personne n'a la clé.
Je note tout ce qui bloque dans un fichier au fur et à mesure. Ce fichier devient le futur README, et c'est déjà une livraison de valeur : le prochain développeur mettra vingt minutes là où j'ai mis huit heures.
Règle absolue de cette journée : aucun jugement. Pas de « c'est mal fait », pas de refactoring opportuniste. Tu ne comprends rien encore. Ce que tu prends pour de l'incompétence est parfois une contrainte que tu ignores.
Jour 2 : cartographier, pas lire
On ne lit pas un projet ligne par ligne. On en dresse la carte.
Ce que je cherche, dans cet ordre :
Les points d'entrée. Routes HTTP, écrans, tâches planifiées, webhooks. C'est la surface par laquelle le monde extérieur touche le système.
Le modèle de données. Le schéma de base en dit plus long que le code. Les noms de tables, les clés étrangères, les colonnes ajoutées à la va-vite racontent l'histoire du produit et de ses virages.
Les dépendances externes. Quels services tiers ? Que se passe-t-il quand ils tombent ? C'est là que se cachent les pannes futures.
Le chemin de l'argent. S'il y a du paiement, je le trace intégralement. C'est toujours la zone la plus sensible et la plus mal testée.
Je produis un schéma — souvent à la main, photographié. Il sert de support à la première vraie discussion avec le client.
Jour 3 : trouver le fil de l'histoire
git log est le document le plus sous-estimé d'un projet repris.
Ce que je regarde :
- Le rythme. Des commits réguliers puis un trou de six mois puis une reprise frénétique : le produit a été abandonné puis relancé dans l'urgence. Ça explique beaucoup d'incohérences.
- Les messages de panique.
fix,fix2,fix urgent,revert fix urgent. Ces séquences marquent les zones qui ont fait mal en production. Ce sont les zones à comprendre en priorité. - Les auteurs. Trois styles différents dans le même dossier expliquent pourquoi les conventions divergent.
Un projet a une histoire, et le code en est la sédimentation. Le lire sans son histoire, c'est juger un choix sans connaître la contrainte qui l'a produit.
Jour 4 : mesurer au lieu d'opiner
C'est le jour qui change la conversation avec le client.
Tant que tu dis « le code est de mauvaise qualité », tu émets une opinion contre laquelle on peut argumenter. Quand tu montres des chiffres, la discussion devient factuelle :
- Couverture de tests — souvent proche de zéro, mais il faut le chiffre.
- Dépendances obsolètes et vulnérabilités —
npm audit,go list -m -u, l'équivalent selon la pile. - Temps de build et de démarrage — impact direct sur la vitesse de livraison future.
- Taille du bundle — impact direct sur les utilisateurs.
- Les fichiers les plus modifiés, croisés avec les plus longs. L'intersection donne les points chauds : gros et souvent touchés, donc risqués.
Ce dernier croisement est le plus utile. Il désigne objectivement où investir, sans débat de goût.
Jour 5 : proposer un plan, pas une réécriture
Voilà le moment où la plupart des reprises échouent.
Le développeur, après quatre jours de découverte inconfortable, annonce : « il faut tout refaire ». Le client entend : « les six mois et l'argent investis sont perdus ». La relation démarre sur un conflit.
Et le pire, c'est que la réécriture complète est presque toujours une erreur. Le code existant, aussi laid soit-il, encode des années de cas particuliers découverts en production. Chaque if bizarre correspond à un client mécontent un jeudi soir. Réécrire, c'est repayer tous ces apprentissages au prix fort.
Ce que je propose à la place, par ordre :
- Stabiliser. Ce qui empêche de livrer sereinement : environnement reproductible, déploiement automatisé, sauvegardes. Aucune fonctionnalité, que du socle.
- Sécuriser. Les vulnérabilités, les secrets en clair, les endpoints non protégés. Non négociable, avant tout le reste.
- Tester le cœur. Pas 80 % de couverture : le parcours qui rapporte de l'argent, testé de bout en bout. Ça devient le filet de sécurité de toute la suite.
- Refactoriser à l'occasion. On améliore ce qu'on touche pour une autre raison. Jamais de chantier de refactoring isolé — c'est invendable et ça dérive.
- Réécrire par morceaux, seulement si un module le mérite vraiment, et derrière une interface stable.
Ce plan a un avantage décisif : le client voit de la valeur dès la deuxième semaine. Une réécriture, elle, demande six mois avant le premier bénéfice visible, et échoue souvent avant.
Les signaux qui me font refuser
Toutes les reprises ne sont pas saines. Ce qui me fait décliner :
Aucun accès à quelqu'un qui connaît le métier. Si le développeur précédent est parti et que personne dans l'entreprise ne sait pourquoi le système se comporte ainsi, chaque décision devient une devinette.
Un client qui veut une réécriture avant l'audit. S'il a déjà décidé, il ne cherche pas un avis, il cherche une exécution. Ça se termine mal.
Pas de production accessible. Impossible de savoir ce qui tourne réellement. La branche main n'est pas toujours ce qui est déployé — je l'ai vérifié à mes dépens.
« C'est urgent, on saute l'audit. » Cinq jours d'audit contre six mois de mission, c'est 4 % du budget. Les refuser garantit de découvrir les problèmes au pire moment.
Le problème de fond
Notre profession valorise énormément la création et très peu la reprise. Les conférences parlent de nouveaux frameworks, pas de comment reprendre un projet Angular 8 en production.
Pourtant, la majorité du code écrit dans le monde est du code de maintenance. La majorité des missions réelles consiste à faire évoluer l'existant.
Cette asymétrie a un coût culturel. On forme des développeurs qui savent démarrer et pas continuer. Qui confondent « je ne comprends pas ce code » avec « ce code est mauvais ». Qui proposent une réécriture parce que c'est plus amusant, en la justifiant par la dette technique.
Il y a une compétence spécifique à reconstituer l'intention derrière un code qu'on n'a pas écrit. Elle s'apprend, elle se paie bien, et presque personne ne l'enseigne.
Le meilleur test
Une question que je pose désormais en entretien de mission, et qui révèle beaucoup :
« Raconte-moi un moment où tu as gardé un code que tu trouvais mauvais, et pourquoi. »
Quelqu'un qui n'a jamais vécu ça n'a pas encore rencontré la contrainte réelle. Quelqu'un qui répond avec précision a compris que le code n'existe pas pour être beau, mais pour rendre un service à quelqu'un.
Cette méthode est celle que j'applique en mission. Si tu as un projet commencé par un autre et que tu ne sais pas par où le reprendre, écris-moi — un audit tient en cinq jours.