Dette technique : stabiliser, refactorer ou réécrire ?

Sur mes 50 derniers audits, 8 fondateurs sur 10 pensaient qu'il fallait tout réécrire. J'ai recommandé la réécriture pour 2 d'entre eux.

Les 8 autres avaient un code fragile, parfois très fragile. Mais "fragile" ne veut pas dire "condamné". Ça veut dire qu'il y a des options — et que la réécriture est rarement la meilleure.

Si votre application tourne, que vos clients l'utilisent, mais que chaque mise à jour vous donne des sueurs froides — c'est de la dette technique. Et vous avez exactement trois options pour y répondre. Je les ai vues fonctionner (et échouer) suffisamment de fois pour vous dire quand choisir laquelle.

Les signaux d'un code qui ne supporte plus le changement

Avant de parler solutions, assurons-nous qu'on parle du même problème.

Un code fragile, ce n'est pas un code "mal écrit". C'est un code qui ne supporte plus le changement. Votre application peut tourner parfaitement aujourd'hui et être un cauchemar à faire évoluer demain. La nuance est importante — et c'est souvent là que le dialogue avec votre équipe technique déraille.

Voici ce que je cherche quand un dirigeant me dit "je crois qu'on a un problème" :

Les mises à jour cassent des choses qui n'ont rien à voir. Vous corrigez un bug sur le paiement, la page de profil plante. Le dev corrige le profil, les notifications ne partent plus. Les morceaux du code sont tellement enchevêtrés que toucher à l'un fait trembler les autres.

Les développements ralentissent sans raison apparente. Ce qui prenait une semaine il y a un an en prend trois aujourd'hui. Vos développeurs ne sont pas devenus moins bons — c'est le code qui résiste. Ils passent plus de temps à contourner les problèmes existants qu'à construire du neuf. Sur le terrain, 20 à 40% du budget de développement est absorbé par ce type de friction.

Les bugs reviennent après correction. Un problème réglé il y a deux mois réapparaît. C'est le signe qu'il n'y a pas de tests automatisés, ou que ceux qui existent ne couvrent pas les cas critiques.

Si vous reconnaissez deux de ces signaux, vous avez de la dette technique qui coûte de l'argent. Reste à décider quoi faire.

Option 1 — Stabiliser : le filet de sécurité

C'est l'option que tout le monde sous-estime. Pas de réécriture. Pas de refonte de l'architecture. On ne change rien au code existant — on pose un filet de sécurité pour que les mises à jour arrêtent de tout casser.

Concrètement : on ajoute des tests automatisés sur les parcours critiques de votre application, et on met en place une intégration continue — un système qui vérifie automatiquement que rien n'a cassé avant chaque mise en production. Si quelque chose casse, le déploiement est bloqué avant d'atteindre vos utilisateurs.

Budget : 5 000 – 15 000€. Durée : 4 à 8 semaines.

Un de mes clients, une marketplace avec 3 développeurs, vivait un enfer à chaque déploiement. Le paiement ou les notifications (ou les deux) tombaient systématiquement. En 6 semaines, on a couvert 4 parcours critiques avec des tests automatisés et bloqué tout déploiement si un test échoue.

Coût : 8 000€. Depuis, plus une seule régression critique en production. La même tranquillité obtenue par une réécriture aurait coûté au minimum 60 000€ et pris 6 mois — 6 mois pendant lesquels aucune feature n'aurait été livrée aux clients.

C'est souvent la première chose que je recommande après un audit de code. Pas parce que c'est la solution définitive, mais parce que ça donne de l'air. Et surtout, ça permet de décider de la suite avec des données concrètes — au lieu de l'intuition de votre dev.

Option 2 — Refactorer : rénover pièce par pièce

Le refactoring, c'est améliorer le code de l'intérieur, morceau par morceau, sans repartir de zéro. L'application continue de tourner pendant tout le processus. Comme rénover un appartement pièce par pièce en continuant à y vivre.

La différence fondamentale avec la réécriture : c'est progressif et réversible. Si le budget se réduit ou que les priorités changent, vous pouvez vous arrêter à tout moment. Le code sera dans un meilleur état qu'au départ.

Budget : 15 000 – 60 000€. Durée : 2 à 6 mois.

Exemple récent. Une startup healthtech prépare sa Série A. Le code est un monolithe de 3 ans, construit par un freelance puis repris par un junior. Deux modules posent problème : l'authentification (failles de sécurité) et la gestion des données patients (pas de chiffrement, pas de logs d'accès — un cauchemar RGPD).

Due diligence technique dans 4 mois. Plutôt que tout réécrire, on a priorisé ces deux modules. Un dev senior à mi-temps pendant 3 mois. 22 000€. La due diligence est passée sans accroc. Les investisseurs n'ont même pas mentionné le reste du code — parce que les parties critiques étaient solides.

Le refactoring fonctionne quand la stack technique est encore viable et que le problème est localisé. Si l'ensemble du code est un enchevêtrement impossible à démêler, c'est l'option suivante qu'il faut regarder. Mais dans mon expérience, on en arrive rarement là.

Option 3 — Réécrire : la solution nucléaire

Repartir de zéro. Nouveau code, souvent nouvelle architecture, parfois même nouveau langage. C'est la solution radicale — et la préférée des développeurs. Écrire du code neuf est plus gratifiant que réparer du code ancien. Mais la gratification de votre dev et l'intérêt de votre entreprise ne convergent pas toujours.

Budget : 40 000 – 150 000€+. Durée annoncée : 3-6 mois. Durée réelle : 6-18 mois.

Ce dernier chiffre n'est pas un effet de style. Sur les migrations techniques que j'ai accompagnées, une seule a tenu son planning initial. Les autres ont pris le double, voire le triple.

Le piège que personne ne mentionne : pendant toute la réécriture, vous maintenez deux codebases. L'ancienne qui tourne en production avec ses bugs à corriger et ses clients à servir. La nouvelle qui n'est pas prête. Double charge pour l'équipe. Double budget.

Un fondateur de SaaS B2B que j'ai accompagné a sauté le pas trop vite. 200 clients, application qui fonctionnait, mais code fragile. Son CTO l'a convaincu : "Il faut tout refaire." Six mois plus tard : zéro feature nouvelle, 15% des clients partis chez un concurrent, réécriture terminée à 60%.

Je le dis avec d'autant plus de franchise que j'ai commis la même erreur. Il y a quelques années, j'ai recommandé une réécriture à un client alors qu'un refactoring ciblé aurait suffi. Huit mois au lieu de trois. Depuis, je ne recommande la réécriture que quand toutes les conditions sont réunies : stack obsolète (plus de mises à jour de sécurité, plus de devs disponibles sur le marché), architecture incompatible avec ce que le produit est devenu, et budget ET temps pour encaisser une longue période sans nouvelles fonctionnalités.

La question à se poser avant tout : faut-il vraiment tout recoder ?

L'arbre de décision : stabiliser, refactorer ou réécrire

Plutôt qu'un diagnostic à l'instinct, voici le cadre que j'utilise avec mes clients :

Ma règle : toujours commencer par stabiliser. Même si vous pensez qu'il faudra refactorer ou réécrire à terme. La stabilisation est rapide, pas chère, et elle vous donne une vision claire de l'état réel du code. Les tests automatisés révèlent les zones vraiment fragiles. Ensuite, vous décidez avec des données — pas avec le ressenti de votre développeur.

Dans 80% des cas, la stabilisation suffit ou débouche sur un refactoring ciblé de quelques modules. La réécriture complète reste l'exception.

Ne prenez pas cette décision seul avec votre dev

La première chose que je dis aux dirigeants qui me posent la question : ne décidez pas sur la base d'une seule opinion. Ce n'est pas un problème de confiance — c'est un problème de biais. Un développeur qui vit dans un code tous les jours a tendance à en exagérer les défauts. C'est humain. Il subit la frustration au quotidien.

Faites auditer le code par un regard extérieur. Un audit prend quelques jours et coûte une fraction de ce que coûterait une mauvaise décision. C'est d'ailleurs l'une des erreurs tech les plus fréquentes en startup : lancer une réécriture à 80 000€ sur la foi d'un seul avis.

Votre app marche. C'est déjà énorme. La priorité, c'est de la garder en marche tout en lui rendant sa capacité à évoluer. Et ça, dans 80% des cas que je croise, ça ne nécessite pas de repartir de zéro.