Coût d'une refonte d'application legacy : options, budget, durée

Qu'est-ce qu'une application legacy, et quand faut-il la refondre ?

Une application legacy est un logiciel encore utile, souvent critique, mais devenu difficile à faire évoluer. Son âge compte moins que ses symptômes : plus personne ne maîtrise le code, les dépendances ne reçoivent plus de correctifs de sécurité, chaque évolution prend des semaines et l'équipe redoute chaque mise en production. Cas typique : un framework abandonné, comme AngularJS, dont le support officiel a pris fin en janvier 2022.

Refondre ne veut pas dire tout jeter. Selon l'état du code, l'opération va du simple changement d'hébergement à la réécriture complète, et le budget suit le même écart. Avant de demander un devis, mieux vaut savoir de quelle option on parle.

Quelles sont les options pour refondre une application legacy ?

Quatre options reviennent dans presque tous les projets, et elles se combinent. Le remplacement par un logiciel du marché est une autre décision, laissée de côté ici.

Le rehosting : changer d'hébergement sans toucher au code

On déplace l'application telle quelle vers une nouvelle infrastructure, par exemple d'un serveur interne vers le cloud. AWS range cette approche (« lift and shift ») parmi ses 7 stratégies de migration : l'application change de serveurs sans être modifiée. C'est rapide et peu risqué, mais la dette reste entière. Vous hébergez mieux un code toujours aussi difficile à modifier.

Le refactoring : assainir le code existant

On améliore le code sans changer ce que voit l'utilisateur : remise sous tests des zones critiques, découpage des parties trop imbriquées, mise à jour des dépendances. C'est l'option la moins chère à chaque étape, et elle avance en parallèle des évolutions courantes. Mais si le framework n'est plus maintenu, le refactoring repousse le problème sans le régler.

La migration progressive (strangler fig)

La migration progressive consiste à remplacer une application legacy morceau par morceau, pendant qu'elle reste en production. Martin Fowler l'a baptisée « strangler fig », du nom du figuier étrangleur qui pousse autour d'un arbre jusqu'à le remplacer. Concrètement, on place devant l'ancien système une couche qui aiguille chaque requête : les fonctions déjà réécrites partent vers le nouveau code, les autres restent servies par l'ancien. On migre ainsi un module à la fois, en commençant par celui qui pose le plus de problèmes ou qui apporte le plus de valeur. Chaque étape est couverte par des tests de non-régression et peut être annulée. Vos utilisateurs ne vivent pas de grande bascule, et vous pouvez ralentir ou réorienter le chantier à tout moment. La contrepartie : deux systèmes à faire cohabiter pendant la transition, et du code de raccordement qui sera jeté à la fin.

La réécriture complète

On repart d'une page blanche avec une nouvelle stack, puis on bascule tous les utilisateurs à une date donnée. Sur le papier, c'est la solution la plus propre. Dans les faits, c'est la plus chère et la plus risquée : il faut retrouver les règles métier enfouies dans le code et maintenir l'ancienne version jusqu'à la bascule. Elle se justifie quand la technologie n'est plus exploitable du tout, ou quand le métier a tant changé que l'ancien périmètre ne sert plus de référence.

Combien coûte une refonte d'application legacy ?

Le coût d'une refonte se calcule en jours-homme, multipliés par le taux journalier moyen (TJM) de l'équipe. Sur le marché français, un développeur senior en freelance facture en général 500 à 700 € par jour. Le tableau donne des ordres de grandeur pour une application métier de taille moyenne, avec quelques dizaines d'écrans et deux ou trois intégrations.

Repères du marché français en 2026, calculés avec un TJM senior de 500 à 700 €, hors audit et hors hébergement. Ils ne remplacent pas un devis : l'audit sert justement à chiffrer votre propre application.

Retenez surtout que la réécriture est rarement l'option économique : elle reproduit des années de règles métier et oblige à faire tourner deux systèmes jusqu'à la bascule. Pour comparer, notre article sur le coût d'un MVP situe un produit neuf entre 20 000 et 60 000 € dans la plupart des cas. Réécrire une application en service depuis des années coûte en général plusieurs fois ce montant. La migration progressive peut coûter autant au total. Elle étale cependant la dépense, livre de la valeur dès les premiers mois et peut s'arrêter le jour où le gain ne justifie plus l'effort.

Qu'est-ce qui fait varier le coût d'une refonte ?

À taille égale, l'effort varie beaucoup d'une application à l'autre. Six facteurs pèsent plus que le nombre d'écrans.

• Sans tests automatisés, chaque modification doit d'abord être sécurisée. Remettre une zone sous tests avant d'y toucher absorbe une bonne part du budget de départ.
• Quand les développeurs d'origine sont partis et que rien n'est documenté, il faut retrouver les règles métier dans le code. C'est lent, et c'est là que naissent les mauvaises surprises.
• Les données d'une base qui a quinze ans d'historique, avec ses doublons et ses formats successifs, demandent des scripts de reprise, des contrôles et plusieurs répétitions avant la bascule. C'est un poste que l'on sous-estime facilement.
• Chaque intégration (ERP, authentification unique, API de partenaires, exports comptables) doit être reproduite puis testée de bout en bout.
• L'outillage pèse avant même la première ligne modifiée. Une application répartie sur quatre ou cinq dépôts (site, application mobile, front, back, administration) demande déjà un vrai chantier pour être installée et configurée. Regrouper l'essentiel dans un monorepo est souvent la première étape rentable.
• Une application utilisée jour et nuit, ou soumise aux exigences de la santé ou du secteur public, impose des fenêtres d'intervention, des plans de retour arrière et une traçabilité qui allongent chaque étape.

Combien de temps dure une refonte ?

Comptez quelques semaines pour un rehosting, un à trois mois pour un refactoring ciblé, six à dix-huit mois pour une migration progressive complète, et neuf mois à deux ans pour une réécriture. Ces durées supposent deux ou trois développeurs seniors, sans geler les évolutions.

Regardez surtout quand arrive le premier résultat. Une migration progressive met son premier module en production en quelques semaines, alors qu'une réécriture ne montre rien d'utilisable avant la bascule finale.

Pourquoi la réécriture « big bang » dérape-t-elle si souvent ?

Une réécriture « big bang » remplace tout le système d'un coup, à une date fixée. Elle dérape pour deux raisons bien identifiées. La première tient au code : l'ancienne application contient des années de corrections et de cas particuliers que personne n'a documentés. En repartant de zéro, on les perd, puis on les redécouvre un par un en production. La seconde tient au calendrier : pendant le chantier, le métier continue d'évoluer, et chaque nouvelle demande doit être développée deux fois ou mise en attente. Comme la valeur n'arrive qu'à la bascule, six mois de retard représentent six mois de coûts sans aucun bénéfice. Joel Spolsky décrivait déjà ce piège en 2000 avec l'exemple de Netscape, resté près de trois ans sans nouvelle version majeure pendant sa réécriture (Things You Should Never Do, Part I). Réécrire reste parfois nécessaire, mais c'est rarement le bon premier choix.

Combien coûte le statu quo ? Le poids du KTLO

Ne rien faire a aussi un prix, le KTLO (« Keep The Lights On ») : le temps que l'équipe passe à faire tourner l'application (correctifs, incidents, mises à jour imposées, contournements) au lieu de construire de nouvelles fonctionnalités.

Dans l'étude The Developer Coefficient, publiée par Stripe en 2018 auprès de milliers de dirigeants et de développeurs dans six pays, les développeurs estiment à 17,3 heures par semaine le temps perdu en maintenance dans leur entreprise (code de mauvaise qualité, débogage, refactoring), sur une semaine moyenne de 41,1 heures. La France arrive en tête, avec 20,9 heures.

Pour estimer le vôtre, demandez à l'équipe quelle part de son temps est partie en maintenance au dernier trimestre, et appliquez ce ratio à son coût annuel. Posé à côté du budget de la refonte, ce chiffre parle à une direction.

Pourquoi commencer par un audit de 3 à 5 jours ?

Un audit préalable coûte peu au regard d'une refonte, et il évite de chiffrer à l'aveugle. Il se vend généralement au forfait, sur 3 à 5 jours, soit environ 1 500 à 3 500 € au TJM senior du marché. L'auditeur lit le code, fait tourner l'application, consulte l'infrastructure et échange avec ceux qui la maintiennent. Il cartographie la dette : les zones sans tests, les dépendances en fin de vie, les modules qui concentrent les incidents. Le livrable est un plan d'action priorisé et chiffré en jours-homme, qui recommande une option (refactoring, migration progressive ou réécriture) et l'ordre des chantiers. Vous pouvez ensuite confier ce plan à l'équipe de votre choix, y compris la vôtre. Sans audit, un devis de refonte repose sur des hypothèses que personne n'a vérifiées. C'est le format de notre audit technique d'application.

Questions fréquentes sur le coût d'une refonte

Peut-on refondre une application sans interrompre l'activité ?

Oui, et c'est le principal intérêt de la migration progressive. L'application reste en production, chaque étape peut être annulée, et les bascules sensibles se planifient sur des créneaux choisis avec vous. La réécriture, elle, impose une bascule unique, avec un plan de retour arrière.

Faut-il changer de technologie pendant la refonte ?

Pas forcément. Changer de framework coûte cher et ne se justifie que si l'actuel n'est plus maintenu ou bloque réellement vos évolutions. Passer d'Angular à React parce que React est plus répandu revient à financer une réécriture pour un gain théorique. La stack que votre équipe maîtrise déjà est en général la bonne.

Refonte au forfait ou en régie ?

Le forfait convient aux chantiers bien délimités, comme une montée de version ou la migration d'un module précis. Une migration progressive sur plusieurs mois se prête mieux à la régie (facturation au temps passé), car le périmètre se précise à mesure que l'on découvre le code. On peut aussi forfaitiser l'audit, puis chaque lot de migration.

Refonte ou refactoring : faut-il trancher dès le départ ?

Non. C'est le rôle de l'audit, et les deux approches se combinent souvent. Nous détaillons les critères de choix dans notre article refonte ou refactoring.

Et chez Neodev ?

Notre offre de refonte d'application legacy suit cette méthode : un audit court, puis une migration par incréments réversibles, avec un système qui reste en production à chaque étape. Nous avons l'habitude de travailler dans des systèmes d'information en place. Sur le portail client OPT NC (cas client), par exemple, il s'agissait notamment d'unifier l'authentification (OKTA) de l'ensemble des applications.

Après l'audit, vous recevez un plan d'action chiffré et un devis détaillé sous 48 h. Le code reste intégralement le vôtre.