Reprendre un code legacy : audit, dette technique et décision (refondre ou continuer ?)

En bref — La reprise d'un code legacy commence par un audit structuré qui mesure 5 signaux clés. Refondre n'est justifié que si plus de 3 signaux sont au rouge et que l'application est stratégique — sinon, corriger et consolider coûte deux à quatre fois moins cher.

Image : wocintechchat.com — Openverse (by)

J’ai vu des dirigeants dépenser 80 000 euros pour refondre une application qui fonctionnait. Pas parce qu’elle était irrécupérable — parce que personne n’avait posé les bonnes questions avant de signer.

La reprise de code legacy, c’est l’une des décisions les plus coûteuses qu’une PME puisse prendre. Et c’est aussi l’une des moins bien documentées. Tu hérites d’une application que ton prestataire précédent a construite en 2017, personne ne sait vraiment ce qu’il y a dedans, et tu dois décider : on repart de zéro ou on continue avec ce qu’on a ?

Je code depuis 2008. J’ai repris des dizaines de bases de code dans des états très variables. Ce guide, c’est ce que j’aurais aimé avoir en main dès le début.

En bref : la règle de décision en une phrase

Avant d’aller plus loin, voilà la règle que j’applique systématiquement :

Refondre uniquement si la dette technique bloque activement les évolutions, que le coût de maintenance annuel dépasse 30 % du coût de refonte estimé, et que l’application est stratégique pour ton business — les trois conditions à la fois, pas une seule.

Si tu as une seule case cochée sur trois, corriger et consolider l’existant sera presque toujours moins cher, moins risqué, et plus rapide. La refonte totale est séduisante parce qu’elle semble nette. Elle est rarement optimale.

Comment savoir si un code legacy est récupérable ?

Un code legacy récupérable, c’est un code sur lequel on peut intervenir sans tout casser, même si c’est inconfortable. L’évaluation tient à cinq tests concrets.

Test 1 — La lisibilité du code

Ouvre un fichier au hasard dans le cœur métier de l’application. Sans documentation, sans demander à personne : est-ce que tu comprends ce que ça fait en moins de dix minutes ?

Ce n’est pas un test de QI. C’est un test de maintenabilité réelle. Un code illisible n’est pas forcément mauvais techniquement — mais chaque intervention dessus coûtera deux à trois fois plus cher qu’un code clair. Si tu dois systématiquement “décompiler dans ta tête” pour comprendre la logique métier, c’est un signal rouge.

Test 2 — La couverture de tests

Pas besoin d’atteindre 100 % de couverture. Mais zéro test, c’est un drapeau orange immédiat. Pas parce que c’est une mauvaise pratique abstraite — parce qu’en l’absence de tests, chaque modification devient une prise de risque non mesurable. Corriger un bug peut en créer trois autres sans que personne ne le sache avant la production.

Un minimum viable : des tests sur les chemins critiques (connexion, paiement, génération de documents si c’est le cœur du métier). En dessous, le coût de reprise monte mécaniquement.

Test 3 — L’état des dépendances

Lance un audit des packages et librairies. Les frameworks et bibliothèques utilisés ont-ils des versions actives ? Y a-t-il des dépendances avec des vulnérabilités connues non corrigées ? Des librairies abandonnées par leurs mainteneurs depuis 3 ans ou plus ?

Dans les projets PME que j’ai audités, c’est souvent là que ça fait mal. Une application en Node.js avec des dépendances qui n’ont pas été mises à jour depuis 2020, c’est une surface d’attaque ouverte — et une migration parfois plus complexe que prévu.

Test 4 — La séparation des couches

Est-ce que la logique métier est emmêlée avec la base de données, l’interface, les appels API ? Un code où tout est dans le même fichier de 2 000 lignes, c’est ce qu’on appelle le “spaghetti code”. Pas impossible à maintenir, mais chaque évolution devient chirurgicale.

Ce test est particulièrement révélateur pour estimer le coût d’une future évolution. Si tu veux ajouter une fonctionnalité et que ça implique de toucher à 15 fichiers non liés en apparence, tu paies la dette à chaque sprint.

Test 5 — La traçabilité Git

Est-ce qu’il y a un historique Git complet ? Des messages de commit qui ont un sens ? Des branches de fonctionnalité distinctes ?

Un dépôt avec un seul commit “first commit” et 4 ans de code dedans, c’est une application qui n’a jamais été pensée pour être transmise. Ce n’est pas bloquant en soi, mais ça alourdit significativement le travail d’audit et de prise en main.

Résultat du diagnostic : 0 à 1 signal rouge = code récupérable, priorise les corrections ciblées. 2 à 3 signaux = zone de vigilance, un audit approfondi est nécessaire avant toute décision. 4 à 5 signaux = l’hypothèse de refonte devient sérieuse, mais reste à chiffrer avant de trancher.

Refondre ou continuer : le tableau de décision

Voilà les critères que j’utilise pour structurer cette décision avec un dirigeant. Ce n’est pas une grille magique — c’est un cadre pour éviter de décider à l’affect.

La vraie difficulté, c’est la ligne “stratégique ou périphérique”. Une PME peut avoir une application de gestion des présences salariés qui est techniquement catastrophique — mais si elle ne représente que 5 % du temps opérationnel et qu’elle ne génère pas de données critiques, la refondre à 40 000 euros n’est pas prioritaire. À l’inverse, une application de devis et facturation qui ralentit chaque vente mérite d’être traitée comme priorité.

Bref, la question n’est pas “est-ce que le code est moche ?” mais “est-ce que l’état du code te coûte de l’argent ou des opportunités aujourd’hui ?”

Combien coûte un audit de code existant ?

Un audit de reprise de code legacy pour une PME se situe généralement entre 1 500 et 4 500 euros. Voici ce qui fait varier le prix.

Facteurs qui font monter l’enveloppe :

• Base de code volumineuse sans documentation (plus de 50 000 lignes effectives)
• Pas d’accès propre aux environnements (il faut reconstituer)
• Technologies multiples (un backend PHP, un frontend React, une API tierce non documentée, un script Python qui tourne quelque part)
• Données sensibles qui nécessitent des précautions RGPD lors de l’analyse

Ce qu’un audit doit produire, concrètement :

• Une cartographie de l’architecture réelle (pas celle imaginée)
• Une liste des risques classés par criticité (bloquant / urgent / à traiter)
• Une estimation du coût de correction par niveau de risque
• Une recommandation chiffrée : continuer + corriger, ou refondre avec une fourchette de budget
• Un avis sur les dépendances critiques et leur état de support

En dessous de 1 500 euros, tu obtiens en général une revue superficielle. Quelqu’un a regardé le code en diagonale, t’a dit “c’est pas terrible” et t’a fait une liste de recommandations vagues. Ce n’est pas un audit exploitable pour une décision à 30 000 ou 80 000 euros.

Ce que ça débloque : un audit sérieux, c’est souvent ce qui permet d’éviter une refonte à 60 000 euros parce qu’on découvre que le problème réel est concentré sur deux modules mal architecturés — et que les corriger coûte 8 000 euros. J’ai vu ce scénario se répéter.

Pour qui la refonte est un piège budgétaire

La refonte totale est présentée comme une solution propre. Elle peut devenir un gouffre. Voici les profils pour qui elle est presque systématiquement une erreur.

Les PME avec un budget serré et une application qui “tourne quand même”

Si ton application fonctionne en production, qu’elle génère du revenu, et que le principal reproche c’est qu’elle est “vieille” ou “pas moderne” — refondre pour refondre est une erreur. La modernité du code n’est pas un objectif business.

Une refonte en contexte PME, ça prend en réalité 6 à 18 mois. Pendant ce temps, tu dois maintenir l’ancienne application, financer la nouvelle, et gérer la migration des données. Le budget initial est presque toujours dépassé de 30 à 50 %.

Les organisations sans équipe tech stable

Si tu n’as pas de développeur en interne ou de prestataire de confiance pour suivre le projet, une refonte totale est un risque majeur. Les décisions d’architecture se prennent à mi-parcours, les périmètres glissent, les délais s’allongent. Sans quelqu’un capable de cadrer techniquement le projet côté client, tu navigues à l’aveugle.

Les applications avec des règles métier complexes non documentées

C’est le piège le plus sous-estimé. La vraie valeur d’une application vieille de 7 ans, ce n’est pas son code — c’est les règles métier encodées dedans. Des calculs de marge, des conditions d’éligibilité, des workflows de validation que personne n’a jamais formalisés par écrit parce que “l’appli le fait automatiquement”.

Refondre sans documenter ces règles d’abord, c’est les perdre. Et les reconstituer après coup à partir des utilisateurs coûte parfois plus cher que la refonte elle-même.

Le bon ordre : documenter les règles métier, auditer le code existant, puis décider. Jamais l’inverse.

Ce qu’il faut exiger du prestataire sortant

La reprise de code legacy implique presque toujours un prestataire qui passe la main. Cette transition est un moment de risque. Voici ce que tu dois obtenir avant de signer quoi que ce soit avec le suivant.

Checklist de livraison prestataire sortant

Accès et propriété du code

• Accès complet au dépôt de code (Git, Bitbucket, autre) avec l’historique complet
• Confirmation écrite que le code t’appartient (mentionné dans le contrat initial ou obtenu par avenant)
• Accès aux comptes de déploiement (hébergeur, CI/CD, registre d’images Docker si applicable)

Environnements et infrastructure

• Credentials des environnements de production, staging, et développement
• Documentation de l’infrastructure (serveurs, services cloud, variables d’environnement)
• Procédure de déploiement documentée — même sommaire

Documentation technique

• Schéma de base de données à jour (ou dump annoté)
• Liste des APIs tierces utilisées avec les clés d’accès et les contrats associés
• Document d’architecture, même d’une page
• Liste des cron jobs, tâches planifiées, workers en arrière-plan

Passation fonctionnelle

• Liste des fonctionnalités avec les modules de code correspondants
• Bugs connus non résolus, avec leur criticité estimée
• Contacts des prestataires tiers si applicable (hébergeur, service mail transactionnel, etc.)

Si le prestataire sortant rechigne à fournir l’un de ces éléments, c’est un signal. Les accès à ton propre code ne sont pas négociables. Dans les cas où un prestataire retient les accès en attendant un solde impayé, c’est une situation juridique à régler rapidement — avec un avocat si nécessaire.

Sur le timing : idéalement, prévoir une période de chevauchement de deux à quatre semaines pendant laquelle l’ancien et le nouveau prestataire peuvent se parler directement. Ça évite des semaines de reverse engineering inutile.

Les trois erreurs les plus fréquentes en reprise de code legacy

Je les mets ici parce qu’elles reviennent systématiquement, indépendamment de la taille de la PME.

Erreur 1 : décider avant d’auditer. “On va tout refaire” ou “on va juste continuer” avant d’avoir ouvert le capot. Les deux peuvent être des erreurs selon la réalité du code.

Erreur 2 : sous-estimer la migration des données. Le code, ça se réécrit. Les données, c’est plus compliqué. Une base de données avec 8 ans de données de production, des contraintes implicites jamais documentées, des valeurs nulles qui ont un sens métier — c’est souvent la partie qui fait exploser les délais lors d’une refonte.

Erreur 3 : ne pas prévoir de budget de transition. Pendant la reprise, les deux systèmes coexistent. Il faut maintenir l’ancien, construire ou prendre en main le nouveau, et gérer la bascule. Le budget “reprise” qui n’inclut pas cette phase de coexistence est systématiquement dépassé.

Quelle est la bonne approche avec la méthode F.A.S.T. ?

La méthode F.A.S.T. que j’utilise dans mes missions s’applique directement ici : Figer le périmètre, Auditer avant de toucher, Structurer les priorités, Transférer proprement.

Dans le contexte d’une reprise de code legacy, ça donne :

• Figer : définir avant de commencer ce qui doit fonctionner à l’issue de la reprise. Pas ce qui serait bien d’avoir — ce qui doit fonctionner.
• Auditer : passer par les 5 tests décrits plus haut avant toute décision d’architecture ou de budget.
• Structurer : classer les interventions par criticité (bloquant, important, cosmétique) et traiter dans cet ordre.
• Transférer : documenter ce qui a été fait pour que la prochaine reprise soit moins douloureuse.

Cette approche évite le syndrome de la feuille blanche : “on repart de zéro parce que l’ancien code est incompréhensible” — alors qu’un audit aurait montré que seuls deux modules posaient problème.

Ce que ça change de travailler avec quelqu’un qui a vu les deux côtés

Je suis du côté code depuis 2008. J’ai été le dev qui livrait, le dev qui reprenait, et le prestataire qu’on a remplacé. Cette double lecture change la façon d’aborder une reprise.

Quand un dirigeant arrive avec “mon dev précédent a tout laissé dans un état catastrophique”, ma première réaction n’est pas de valider — c’est d’aller regarder. Parfois c’est vrai. Parfois c’est un code qui n’est pas beau mais qui est solide. Parfois c’est l’inverse : un code propre en surface qui cache des problèmes structurels graves.

L’audit de code existant, ce n’est pas un jugement de valeur sur le prestataire précédent. C’est une photographie de l’état réel, pour prendre une décision éclairée.

Ce que tu peux faire maintenant

Si tu es dans une situation de reprise de code legacy — que tu sois sur le point de changer de prestataire, que tu aies récupéré une application en interne, ou que tu hésites entre refondre et continuer — la première étape est l’audit.

Pas pour avoir raison ou tort sur la décision que tu as déjà en tête. Pour avoir les éléments pour décider correctement.

Si tu veux qu’on en parle ensemble, tu peux prendre un créneau directement ici : /schedule-meeting. On regarde ensemble ce que tu as, et je te dis franchement ce que j’en pense.