Dette technique : reprendre un code existant sans carnage

Un dirigeant m'a appelé après avoir perdu 3 développeurs en 6 mois. Les trois avaient démissionné pour la même raison : le code sur lequel ils devaient travailler.

L'entreprise avait racheté une app e-commerce. Le code "fonctionnait". Le fondateur avait recruté 3 devs pour ajouter des fonctionnalités. Aucun audit préalable. Aucune documentation. Six mois et 120 000 € de coûts RH plus tard, l'app n'avait pas bougé d'une ligne.

C'est un schéma que je croise régulièrement. Un dirigeant hérite d'un code — rachat, départ du dev, fin de contrat freelance — et prend les mauvaises décisions parce que personne ne lui a expliqué la marche à suivre. Voici les 4 étapes pour reprendre un code chargé de dette technique, dans le bon ordre, avec ce que ça coûte vraiment à chaque niveau.

La dette technique, en une phrase

C'est l'accumulation de raccourcis pris dans le code pour aller plus vite. Comme une dette financière : tant que vous ne remboursez pas, les intérêts s'accumulent. Sauf que les intérêts, ici, ce sont des bugs, des ralentissements, et des fonctionnalités qui prennent 3 fois plus de temps que prévu.

Mais le vrai coût de la dette technique, celui que personne ne met dans les tableurs, c'est le turnover. Un bon développeur qui arrive sur une codebase pourrie part en 6 mois. Pas parce qu'il est fainéant — parce qu'il sait qu'il perd son temps. Un dev moyen, lui, reste, mais produit de moins en moins. Dans les deux cas, vous payez.

Le dirigeant dont je parlais avait fait le calcul : 3 recrutements à environ 8 000 € chacun, 6 mois de salaires improductifs, plus le coût d'opportunité d'un produit figé. Total : environ 120 000 €. Le coût d'un audit + stabilisation ? 20 000 €.

Étape 1 — Auditer avant de toucher à quoi que ce soit

Première règle, et la plus ignorée. Avant de recruter un dev, avant de demander une estimation de refonte, avant de décider si on garde ou on jette : on audite.

Un audit de code prend 2 à 5 jours selon la taille du projet. On regarde l'architecture, la couverture de tests, les dépendances, la sécurité, et l'état de la documentation. Le livrable : un rapport qui dit exactement ce qui va, ce qui ne va pas, et ce que ça coûte à corriger.

Ce que ça coûte : entre 1 500 et 5 000 €.

Ce que ça change : j'ai audité une startup SaaS dont le board voulait tout réécrire. Budget estimé : 80 000 €. Après l'audit, j'ai constaté que le cœur de l'application était solide. Le problème se concentrait sur la couche d'authentification et quelques endpoints d'API — deux modules qu'on pouvait reprendre sans toucher au reste. Stabilisation ciblée : 15 000 €. Sans cet audit, ils auraient reparti de zéro. Et la réécriture aurait probablement coûté le double du budget initial. J'y reviens plus loin.

J'ai écrit un article dédié sur ce que coûte un audit de code et ce qu'il contient concrètement.

Étape 2 — Documenter ce qui existe

Après l'audit, avant de corriger quoi que ce soit, il faut documenter. Phase la moins glamour, la plus négligée.

Un client m'a dit : "On a de la documentation." J'ai regardé. Un fichier README de 12 lignes datant de 2022, trois schémas sur Miro dont les liens étaient morts, et des commentaires dans le code qui décrivaient une version d'il y a deux ans. Techniquement, oui, c'était de la documentation. Pratiquement, c'était du bruit.

Une documentation utile, ça tient en quelques éléments :

• L'architecture : quels composants, comment ils communiquent
• Les flux critiques : inscription, paiement, les parcours utilisateur qui font tourner le business
• Les décisions techniques : pourquoi tel choix a été fait — même si c'était un mauvais choix, au moins on comprend le contexte
• Les zones dangereuses : les modules qu'il ne faut pas toucher sans avoir compris pourquoi ils sont comme ça

Ce que ça coûte : 2 à 5 jours d'un développeur senior, soit 2 000 à 5 000 €.

Sans cette étape, chaque nouveau dev qui arrive repasse par la même phase de découverte. J'ai vu des équipes où l'intégration technique durait 3 mois — pas parce que le code était complexe, mais parce que personne ne savait expliquer comment ça marchait. Un code bien documenté ramène ce temps à 2-4 semaines.

Étape 3 — Stabiliser, pas réécrire

C'est ici que la plupart des dirigeants font l'erreur fatale : ils confondent stabiliser et réécrire.

Stabiliser, c'est rendre le code existant fiable. On ajoute des tests sur les parties critiques, on corrige les failles de sécurité, on isole les modules fragiles. On ne change pas l'architecture — on la consolide.

Réécrire, c'est repartir de zéro. Et dans 80 % des cas que j'audite, c'est une mauvaise idée.

Le code legacy contient des années de cas particuliers, de corrections de bugs et d'ajustements métier que personne ne se rappelle. Quand vous réécrivez, vous les oubliez. Et vous les redécouvrez un par un, en production, avec des clients qui appellent. J'ai vu des réécritures estimées à 3 mois durer 14 mois. Le budget ? Multiplié par 2,5.

Un fondateur m'a contacté pour "juste ajouter Stripe" à son SaaS B2B. Code écrit par un freelance deux ans plus tôt. Le nouveau dev a estimé 2 semaines. Trois mois après, toujours rien en production. Le code était tellement couplé que chaque modification dans un module cassait autre chose. Pas de tests, pas de filet de sécurité. Ils ont finalement dû passer par 6 semaines de stabilisation avant de pouvoir ajouter quoi que ce soit.

Ce que ça coûte : entre 5 000 et 30 000 €, selon la taille du projet et la gravité de la dette technique.

La bonne approche : stabiliser par zones, sans tout arrêter. On identifie les 2-3 modules les plus critiques — souvent l'authentification, le paiement, les données utilisateur — on les sécurise en priorité, et le développement continue sur le reste.

Je l'admets : j'ai moi-même fait l'erreur inverse en début de carrière. Sur un projet de reprise, j'ai commencé par moderniser le stack — mise à jour des dépendances, migration du framework. Résultat : 3 semaines de régressions en cascade. J'aurais dû documenter et stabiliser d'abord. Depuis, la règle est simple : on ne touche pas à l'infrastructure tant que le code n'est pas testé.

Étape 4 — Évoluer enfin

Une fois le code audité, documenté et stabilisé, vous pouvez recommencer à construire. La différence est spectaculaire.

J'ai une règle que j'appelle la règle des 3 mois : si un développeur compétent met plus de 3 mois à être autonome sur votre codebase, le problème n'est pas le développeur. C'est le code. Un code sain, même complexe, même avec beaucoup de logique métier, permet à un bon dev d'être productif en 2 à 4 semaines.

Après la stabilisation, vous êtes dans cette situation. Recruter devient possible. Avancer redevient normal.

Sur le recrutement, un point important : soyez transparent. Un dev qui accepte de travailler sur du code repris avec un plan de modernisation clair — il restera. Un dev à qui vous vendez un "projet clean" et qui découvre le contraire le premier jour — vous le perdrez en 3 mois.

Si cette reprise de code s'inscrit dans un contexte de levée de fonds, sachez que les investisseurs regarderont exactement ces mêmes points lors de la due diligence technique. Mieux vaut les traiter avant qu'on vous les demande.

Les 5 signaux que votre code accumule de la dette technique

Pas besoin d'être technique pour repérer ces signaux. Si vous en reconnaissez 2 ou plus, votre code a besoin d'aide.

1. Chaque fonctionnalité prend plus de temps que la précédente. La première feature a pris 1 semaine. La dernière a pris 2 mois. Vos devs ne ralentissent pas — c'est le code qui résiste.

2. Les bugs reviennent après correction. On corrige un problème sur le paiement, il réapparaît 3 semaines plus tard. Ou la correction crée un nouveau bug ailleurs.

3. Les estimations sont systématiquement dépassées. Votre dev dit "2 semaines", il met 6 semaines. Ce n'est pas de l'incompétence — c'est qu'il découvre des problèmes en cours de route que personne ne pouvait anticiper sans documentation.

4. Vous avez du turnover technique. Si vos devs partent et que le salaire n'est pas le problème, regardez le code. C'est la première cause de départ que personne n'ose mentionner en entretien de sortie.

5. Le nouveau dev dit "il faut tout refaire". C'est le signal le plus fréquent. Et paradoxalement, la réponse est rarement de tout refaire — c'est de faire un audit pour savoir quoi reprendre et dans quel ordre.

Le coût de ne rien faire

Le dirigeant qui avait perdu ses 3 devs a fini par suivre ce processus. Audit : 1 semaine. Documentation : 3 jours. Stabilisation des modules critiques : 5 semaines. Coût total : environ 20 000 €.

Six mois plus tard, un seul développeur — plus junior que les trois précédents — tenait la codebase et livrait des fonctionnalités toutes les deux semaines.

Le coût de ne pas avoir fait l'audit au départ : 120 000 € et un an de perdu.

Si vous êtes dans cette situation — code hérité, dev parti, produit qui n'avance plus — la première étape n'est pas de recruter. C'est de faire évaluer ce que vous avez.