Dette technique : faut-il tout recoder ? 5 critères

Un fondateur m'a appelé un mardi matin, voix tendue. Son lead dev venait de poser un ultimatum : « Soit on refait tout le code, soit je pars. » Devis de l'équipe : 80 000€, quatre mois de travail. Le fondateur n'avait aucune idée de si c'était justifié.

Douze mois et 80K€ plus tard, la refonte n'était pas finie. L'ancienne version aurait pu être corrigée pour 15 000€. Ce genre de situation, je le croise au moins trois fois par an. Un dev qui décrète que « tout est à refaire », un dirigeant qui ne sait pas comment arbitrer, et un budget qui part en fumée.

La dette technique est un vrai sujet. Mais « tout recoder » est rarement la bonne réponse. Voici les 5 critères que j'utilise pour trancher quand un client me pose la question.

La dette technique, en 30 secondes

Oubliez les métaphores bancaires que vous trouvez partout. La dette technique, c'est simple : ce sont tous les raccourcis pris dans le code pour aller plus vite. Chaque raccourci fonctionne sur le moment, mais rend la suite plus difficile.

Imaginez un entrepôt. Au début, tout est rangé. Puis, pour gagner du temps, on empile les cartons n'importe où. Ça marche — jusqu'au jour où trouver un article prend 20 minutes au lieu de 2.

Toute application a de la dette technique. La question n'est pas « en ai-je ? » — c'est « est-ce qu'elle m'empêche d'avancer ? » Un code de 5 ans qui tourne sans incident est souvent plus fiable qu'un code de 6 mois bâclé sous pression. L'âge du code n'est pas un indicateur de qualité. Sa capacité à évoluer, si.

Les signaux d'alerte

Avant de parler de refonte, encore faut-il savoir si vous avez un vrai problème. Trois choses à vérifier.

Les développements ralentissent. Une fonctionnalité qui prenait deux semaines il y a un an en prend six aujourd'hui. Vos devs passent plus de temps à contourner les problèmes du code existant qu'à construire du neuf. Quand votre équipe technique vous dit « c'est compliqué » à chaque demande, ce n'est pas qu'elle manque de compétence — c'est que le code résiste.

Chaque mise à jour casse autre chose. Vous corrigez un bug de paiement, la page de connexion tombe. C'est le signal le plus dangereux : les parties du code sont tellement enchevêtrées qu'on ne peut plus toucher à une sans faire trembler les autres. Un audit de code met le doigt dessus en quelques jours.

Le troisième signal est plus insidieux : vous ne recrutez plus. J'ai vu une startup perdre trois recrutements de suite — les développeurs en entretien technique découvraient un framework abandonné depuis 2019 et retiraient leur candidature dans la semaine. Quand personne ne veut travailler sur votre code, le problème n'est plus technique, il est stratégique.

Si aucun de ces signaux ne s'applique, respirez. Votre dev a peut-être envie de recoder. Votre app, elle, n'en a pas besoin.

Les 5 critères de décision

Quand un client me demande « est-ce qu'il faut tout refaire ? », je pose cinq questions. Les réponses dessinent la décision.

1. Le code peut-il encore évoluer ?

C'est la question centrale. Si vous pouvez encore ajouter des fonctionnalités — même lentement — le code est vivant. La lenteur se corrige. L'impossibilité totale d'évoluer, non.

Un client e-commerce voulait ajouter un programme de fidélité. Son équipe a estimé 4 mois pour ce qui aurait dû prendre 3 semaines. Le code pouvait encore évoluer, mais à un coût déraisonnable. Verdict : refonte du module concerné, pas de tout le système.

2. La technologie est-elle encore maintenue ?

Un framework qui ne reçoit plus de mises à jour de sécurité depuis plus de 18 mois, c'est un problème objectif. Pas un problème de confort — un problème de sécurité. Chaque jour qui passe élargit la surface d'attaque.

En revanche, si la techno est toujours maintenue mais « pas à la mode », ce n'est absolument pas une raison de recoder.

3. Combien coûte chaque nouvelle fonctionnalité par rapport à il y a un an ?

Sortez les chiffres. Pas des impressions. Combien de jours-homme pour la dernière fonctionnalité comparable ? Et la même, l'année dernière ?

Si le ratio a doublé ou triplé, la dette pèse. Si c'est resté stable, le dev qui veut tout refaire a peut-être un autre motif. J'ai audité une startup où le CTO réclamait une migration vers une stack « moderne ». L'audit a montré que le code était stable, bien testé, et que les délais de développement n'avaient pas bougé en deux ans. La « dette technique » n'existait pas — c'était une préférence personnelle.

Un point que peu de gens osent dire : le développeur qui recommande une refonte a un biais naturel. Pas par malhonnêteté — recoder un système from scratch est plus stimulant que maintenir du code existant. C'est humain. Mais ça signifie que la recommandation n'est pas neutre, et que vous avez besoin d'un regard extérieur pour valider.

4. Le problème est-il localisé ou généralisé ?

C'est le critère qui sépare la refonte totale de la refonte partielle. Dans la majorité des cas que j'audite, le problème est localisé. Trois modules sur douze sont critiques. Le reste tient la route.

Un client fintech avait un monolithe de 200 000 lignes de code. L'équipe voulait tout réécrire : estimation 120K€, 10 mois. Après audit, on a identifié trois modules véritablement problématiques. Refonte ciblée : 18 000€, six semaines. Le reste n'avait pas besoin d'être touché.

5. Avez-vous le temps ?

Une refonte totale, c'est 6 à 18 mois pendant lesquels votre équipe construit le futur au lieu d'améliorer le présent. Pas de nouvelles fonctionnalités. Pas de réactivité marché. Vos concurrents, eux, ne s'arrêtent pas.

Si vous êtes en phase de croissance, si vous préparez une levée de fonds, si vos clients attendent des évolutions — une refonte totale est un luxe que vous ne pouvez probablement pas vous offrir.

L'arbre de décision : refonte totale, partielle ou stabilisation

Répondez aux cinq questions ci-dessus. Vous tombez dans l'un de ces trois scénarios.

Refonte totale — Le code ne peut plus évoluer du tout, la techno est morte, les coûts ont explosé, et le problème est partout. C'est le scénario le plus rare. Sur les 40+ audits que j'ai réalisés, moins de 20% justifiaient une réécriture complète. Si vous êtes dans ce cas, préparez-vous : multipliez l'estimation de votre équipe par deux, en budget comme en temps. Vous serez plus proche de la réalité.

Refonte partielle — Le cas le plus fréquent, et de loin. Le problème est concentré sur certains modules. On refait ce qui bloque, on garde ce qui marche. C'est ce qu'a fait un client fintech que j'accompagnais : migration module par module sur 8 mois, zéro interruption de service pour 200 000 utilisateurs. Coût réel : 45K€ au lieu des 120K estimés pour tout refaire.

Stabilisation — Le code fonctionne mais il est fragile. On ne recode pas : on consolide. Ajout de tests automatisés sur les zones critiques, correction des points chauds, documentation de ce qui doit l'être. C'est la solution la moins chère et la plus rapide, souvent suffisante pour gagner 12 à 18 mois de tranquillité.

Combien ça coûte — et combien ça dérape

La refonte à 80K€ du début de cet article devait en coûter 30K. Le fondateur avait validé un devis basé sur une estimation « optimiste ». Quatre mois sont devenus douze. Le budget a presque triplé. Et pendant ces douze mois, l'ancienne application devait continuer à tourner en parallèle — ce qui doublait la charge de maintenance.

Ce cas n'est pas exceptionnel. Les refontes totales dépassent leur budget initial dans plus de la moitié des cas. Toujours la même raison : l'équipe ne réécrit pas juste du code. Elle réécrit le code ET toutes les subtilités métier ajoutées au fil des années — les cas particuliers, les exceptions demandées par les clients, les correctifs qui n'ont jamais été documentés. Ces subtilités n'apparaissent que quand un utilisateur signale que « ça ne marche plus comme avant ».

Règle simple : si votre équipe estime 4 mois, prévoyez 8. Si elle estime 50K€, budgétez 80 à 100K€. Et posez-vous la question : ce montant ne serait-il pas mieux investi dans une refonte partielle, avec du budget restant pour faire avancer le produit ?

L'erreur la plus chère : ne rien faire

J'ai passé cet article à faire le procès de la refonte excessive. L'inverse est tout aussi dangereux.

Un fondateur e-commerce que j'accompagnais en CTO externalisé recevait des alertes de son équipe technique depuis six mois : la base de données ne tiendrait pas la montée en charge. Il repoussait. « On verra après la levée. » « Pas le budget. » « Ça tient pour l'instant, non ? »

Black Friday. L'application tombe. Trois jours hors service. 120 000€ de chiffre d'affaires perdu. La correction de la couche base de données aurait coûté 15 000€.

Ignorer la dette technique n'est pas une option gratuite. C'est un pari. Et quand il se retourne contre vous, la facture est toujours plus salée que la prévention.

Avant de décider : faites auditer

Ne tranchez jamais sur la seule recommandation de votre équipe interne. Non pas qu'elle soit incompétente — mais elle est partie prenante. Un audit de code externe coûte entre 1 500 et 5 000€ et vous donne un diagnostic factuel : ce qui est critique, ce qui peut attendre, vos options chiffrées.

C'est exactement ce que je fais dans le cadre de mon activité de direction technique externalisée : poser un diagnostic avant d'engager un budget. Pas pour vendre une refonte — pour éviter les mauvaises.