Application legacy : moderniser ou remplacer

Votre application legacy tourne encore. C'est exactement ce qui la rend dangereuse.

Elle facture, elle planifie, elle pilote la production. Personne n'ose la toucher, le seul développeur qui la connaissait est parti, et chaque évolution se compte désormais en semaines. Vous savez qu'il faudra agir. La vraie question n'est pas « si », c'est « comment » : moderniser sur place, migrer la stack ou remplacer purement et simplement.

Ces trois voies n'ont ni le même coût, ni la même durée, ni les mêmes risques. Choisir la mauvaise coûte souvent plus cher que de ne rien faire pendant un an.

Dans cet article, vous allez découvrir :

• •Les quatre signaux qui distinguent une application vieillissante d'une application legacy qui détruit de la valeur
• •Les trois voies possibles (moderniser, migrer, remplacer) avec, pour chacune, le moment où elle s'impose, son ordre de grandeur budgétaire, sa durée et ses risques
• •Le tableau comparatif et les six critères qui font basculer d'une voie à l'autre
• •Trois applications métier livrées par ONDEV (Dassault Aviation, SNEF, Enovacom) qui illustrent chaque voie avec des résultats réels

Une application legacy n'est pas une application vieille. C'est une application dont le coût de chaque évolution dépasse la valeur qu'elle rapporte.

Qu'est-ce qu'une application legacy, vraiment ?

Le mot « legacy » est souvent utilisé comme une insulte technique. C'est une erreur de lecture. Une application de 2012 qui tourne sans incident et que trois développeurs savent modifier n'est pas legacy. Elle est mature.

Une application devient legacy quand l'organisation perd la capacité de la faire évoluer à un coût raisonnable. Le critère est économique avant d'être technologique. Le framework obsolète, la base de données non maintenue ou l'absence de tests ne sont que les causes habituelles de cette perte de capacité.

Les quatre signaux qui ne trompent pas

• •La connaissance s'est évaporée : une seule personne (ou plus personne) sait comment l'application fonctionne réellement. La documentation, quand elle existe, décrit une version qui n'est plus en production.
• •Chaque modification casse autre chose : sans tests automatisés, toute évolution déclenche une régression ailleurs. Les équipes finissent par refuser de toucher à certains modules.
• •L'écosystème a décroché : le langage, le framework ou la base de données ne reçoivent plus de correctifs de sécurité. Recruter dessus devient difficile, et cher.
• •Le métier contourne l'outil : les utilisateurs exportent dans Excel, créent des fichiers partagés, utilisent des outils SaaS en parallèle. L'application n'est plus la source de vérité.

Deux cases cochées sur quatre, et l'application coûte déjà plus qu'elle ne rapporte. Nous détaillons ce calcul dans notre article sur le coût réel du code legacy et le moment où réécrire. Ici, nous traitons la décision qui suit : quelle voie emprunter.

Les trois voies : moderniser, migrer, remplacer

Il n'existe que trois façons de sortir d'une application legacy. Strangler pattern, réécriture big bang, refactoring incrémental ou rehosting ne sont que des variantes de ces trois voies.

Voie 1 : moderniser sur place

On conserve le langage et l'architecture. On ajoute des tests sur les zones critiques, on met à jour les dépendances, on découpe les modules fragiles, on remplace l'interface vieillissante par une couche moderne branchée sur le code existant.

Quand elle s'impose : le code reste compréhensible, le langage est encore maintenu, le périmètre fonctionnel correspond toujours au métier. L'application est vieillissante, pas condamnée.

Ordre de grandeur : la voie la moins chère au ticket d'entrée. Elle se mène par lots de quelques semaines, chacun livrant une amélioration visible, et le budget se lisse dans le temps.

Durée : de quelques semaines à quelques mois selon la taille du code et le nombre de zones à sécuriser.

Risques : ne jamais finir. Sans objectif clair, la modernisation devient une maintenance améliorée qui coûte tous les mois sans régler la cause. Second risque : moderniser une application dont le métier n'a plus besoin.

C'est le cadre naturel d'un contrat de maintenance applicative structurée : on ne se contente pas de corriger les bugs, on réduit la dette à chaque intervention.

Voie 2 : migrer la stack

On conserve le périmètre fonctionnel et les données, mais on change la fondation : langage ou framework, base de données, hébergement. La logique métier est réécrite module par module, et les deux applications cohabitent le temps de la transition.

Quand elle s'impose : le code reste globalement sain mais l'écosystème est en fin de vie (version de PHP ou de Java sans support, framework abandonné, base de données qui ne reçoit plus de correctifs). Le métier est satisfait de ce que fait l'outil ; c'est la fondation qui lâche.

Ordre de grandeur : nettement plus coûteuse que la modernisation sur place, puisqu'une large part du code est réécrite. Mais moins chère qu'un remplacement, car on ne redécouvre pas le métier : les règles, les écrans et les cas limites sont connus.

Durée : plusieurs mois, parfois plus d'un an pour les applications très étendues. La cohabitation des deux systèmes allonge le calendrier mais sécurise la bascule.

Risques : la reproduction à l'identique de défauts que personne ne voulait garder, les écarts de comportement sur les cas limites non documentés, et la double charge d'exploitation pendant la transition.

C'est le schéma typique d'une migration d'application PHP vers une stack moderne : le métier a été validé par des années d'usage, seule la fondation doit changer.

Voie 3 : remplacer

On repart d'une feuille blanche à partir des besoins métier actuels, pas des écrans existants. L'ancienne application sert de référence, pas de modèle. Le remplacement passe par un développement sur-mesure ou par un logiciel du marché.

Quand elle s'impose : le métier a changé au point que l'application ne décrit plus la réalité du travail. Ou bien le code est tellement dégradé que le comprendre coûte plus cher que le réécrire. Ou encore l'outil existant n'est plus un avantage concurrentiel et un logiciel standard fait aussi bien.

Ordre de grandeur : le ticket d'entrée le plus élevé des trois voies. En contrepartie, le coût de possession sur les années suivantes chute, parce que l'application est conçue pour évoluer.

Durée : plusieurs mois pour une première version utilisable, puis des itérations. Le danger est de vouloir tout livrer d'un coup.

Risques : le plus connu est l'effet « second système » : l'équipe veut corriger tous les défauts de l'ancien outil en une fois, le périmètre gonfle, le projet s'enlise. Le second est la perte de règles métier enfouies dans le code et que personne ne se souvient d'avoir écrites.

Cette voie correspond à ce que nous appelons une refonte d'application web : on reconstruit à partir des usages réels, pas à partir de l'existant.

Le tableau comparatif

Les six critères qui font basculer d'une voie à l'autre

Le tableau donne la carte. Voici la boussole : six questions à poser dans l'ordre, chacune pouvant faire remonter d'une voie à la suivante.

1. Le code est-il encore lisible ? Si un développeur senior qui ne connaît pas l'application met moins d'une journée à comprendre un module et à le modifier sans peur, le code est sain. Sinon, la modernisation sur place va coûter plus cher qu'annoncé.

2. L'écosystème est-il encore maintenu ? Un langage ou un framework sans correctifs de sécurité est une bombe à retardement réglementaire autant que technique. Ce critère seul fait basculer de la voie 1 à la voie 2.

3. Le périmètre fonctionnel décrit-il encore le métier ? Si les utilisateurs contournent l'outil, moderniser ou migrer revient à restaurer une maison dont les pièces ne servent plus. Ce critère fait basculer vers le remplacement.

4. Les données sont-elles exploitables ? Un schéma de base propre et documenté rend la migration réaliste. Un schéma dégradé, avec des colonnes détournées et des doublons, alourdit la migration et rapproche du remplacement, en imposant une reprise de données sérieuse.

5. Quel est l'horizon de l'entreprise ? Une cession ou une levée dans les dix-huit mois change tout. Un acquéreur valorise une application remplacée ou migrée, et déduit du prix une application legacy, quel que soit son chiffre d'affaires. La modernisation sur place, elle, rassure rarement un auditeur technique.

6. Quelle capacité l'équipe peut-elle absorber ? Remplacer une application mobilise le métier pendant des mois pour exprimer et valider les besoins. Si cette disponibilité n'existe pas, la migration de stack est la voie réaliste, même quand le remplacement serait théoriquement meilleur.

Trois applications métier qui illustrent chaque voie

Voici trois applications livrées par ONDEV, une par voie, avec leurs résultats mesurés.

Dassault Aviation : remplacer par une application métier conçue pour durer

Pour Dassault Aviation, nous avons développé une application métier sur-mesure qui remplace des processus auparavant fragmentés entre plusieurs outils. Résultat : plus de 90 utilisateurs actifs, plus de 100 fonctionnalités livrées et une heure gagnée par processus.

C'est la voie 3 bien menée : partir des usages réels, livrer une première version centrée sur les processus à plus forte valeur, puis étendre fonctionnalité par fonctionnalité. La stack (React, Node.js, PostgreSQL, WebGL) a été choisie pour sa longévité, pas pour sa nouveauté.

SNEF : une stack moderne, auto-hébergée, pour une application technique

Pour SNEF, nous avons construit une application de visualisation de schémas électriques sur Next.js, TypeScript, PostgreSQL et Prisma. Les équipes gagnent 1h30 tous les deux jours et disposent d'une visibilité complète sur leurs projets.

C'est la fondation type d'une migration de stack réussie : un ORM typé qui documente le schéma de données, un framework maintenu par un écosystème massif, un hébergement maîtrisé en interne. Une application construite ainsi ne redeviendra pas legacy dans cinq ans, parce que chaque brique a une trajectoire de maintenance claire.

Enovacom : moderniser dix applications sans les réécrire

Le cas le plus parlant pour la voie 1 est celui d'Enovacom, éditeur de logiciels de santé. Plutôt que de réécrire un parc d'applications hétérogènes, nous avons conçu un design system et une refonte UX à l'échelle : plus de 70 composants réutilisables, 10 applications harmonisées, 100 % de réutilisabilité.

Chaque application a conservé sa logique métier. Ce qui a changé, c'est la couche d'interface, désormais commune, cohérente et maintenue à un seul endroit. C'est exactement ce que permet la modernisation sur place quand le code reste sain : un gain visible pour les utilisateurs, un coût réparti, aucune bascule risquée.

Dans les trois cas, la décision a été prise sur des critères explicites, pas sur une préférence technologique. C'est l'approche que nous appliquons sur chaque développement d'application web sur-mesure.

Les erreurs qui transforment une modernisation en gouffre

Quelle que soit la voie, les mêmes erreurs reviennent dans les projets qui dérapent.

• •Décider sans audit préalable. Une semaine d'audit de code évite des mois d'erreur.
• •Confondre migration et amélioration. Ajouter des fonctionnalités pendant la migration mélange deux projets et empêche de vérifier que le nouveau système fait ce que faisait l'ancien.
• •Négliger la reprise des données. Les données sont le vrai actif ; leur nettoyage et leur transfert sont presque toujours sous-estimés.
• •Couper l'ancien système trop tôt. La cohabitation coûte, mais c'est l'assurance la moins chère contre une bascule ratée.
• •Ne pas prévoir la suite. Une application migrée ou remplacée sans plan de maintenance redevient legacy. Le budget doit inclure les années qui suivent.

FAQ : application legacy, modernisation et remplacement

Avant de trancher entre les trois voies, un audit de code objective l'état réel de votre application legacy et chiffre chaque option sur des constats, pas sur des impressions.

Si la décision intervient dans le cadre d'un rachat ou d'une cession, la due diligence technique traduit ces mêmes constats en décote, en garantie ou en clause du protocole.

Ce qu'il faut retenir avant de décider

Il n'y a pas de bonne voie dans l'absolu. Il y a la voie qui correspond à l'état réel de votre code, à la vie de son écosystème, à l'adéquation de l'outil avec le métier et à l'horizon de votre entreprise. Moderniser quand le code est sain, migrer quand la fondation lâche, remplacer quand le métier a changé : cette grille tranche la majorité des cas.

Ce qui tranche les autres, c'est un audit : une semaine à lire le code et interroger les utilisateurs coûte toujours moins cher qu'un projet engagé dans la mauvaise direction.

Vous hésitez entre moderniser, migrer ou remplacer votre application métier ? Parlons de votre application et de son avenir : nous vous dirons quelle voie s'impose, et pourquoi.