Moderniser son logiciel Legacy : choisir entre refonte totale et strangler pattern

C’est le dilemme de tout DSI ou dirigeant de PME. Vous disposez d’un logiciel métier développé il y a 10 ou 15 ans. Il est le cœur battant de votre entreprise, il contient toute votre intelligence business, mais… il est à bout de souffle.

L’interface est datée, il est impossible à utiliser sur mobile, la connexion avec vos outils modernes (API) est un calvaire, et la maintenance devient un risque majeur car la technologie est obsolète (dette technique).

Faut-il opter pour le « Big Bang » (on rase tout et on recommence) ou tenter de rénover l’existant ?
La plupart des conseils en ligne vous enferment dans ce choix binaire. En réalité, en 2026, l’approche industrielle est plus nuancée.

Voici comment diagnostiquer votre situation et choisir la bonne thérapie pour votre « Legacy ».

1. L’audit de l’existant

Avant de signer pour une refonte à cinq chiffres, il faut ouvrir le capot. La décision ne se prend pas au « doigt mouillé », mais sur des critères techniques objectifs (technologie, structure de la base, adéquation métier) et des enjeux de risque et de coût total de possession (TCO).

De nombreuses études montrent que les projets de refonte mal cadrés explosent les délais et les budgets ; c’est pourquoi le point de départ doit toujours être un audit structuré de l’existant.

Nous analysons trois indicateurs de santé (comme détaillé dans notre guide sur la qualité logicielle):

1. L’obsolescence technologique : votre logiciel repose-t-il sur une technologie « en fin de vie » ou plus maintenue (Visual Basic 6, vieilles versions de Java ou PHP, Flash) ? Si oui, une refonte devient fortement recommandée pour des raisons de sécurité et de conformité, même si des mesures transitoires sont parfois possibles.
2. La structure de la base de données : si le code est vieux mais que la base de données est propre et bien structurée, on peut souvent sauver la « Data » et ne reconstruire que l’application.
3. L’adéquation métier : Le logiciel fait-il encore ce qu’on attend de lui ? S’il faut 15 clics pour faire une facture, le problème n’est pas que technique, il est fonctionnel.

2.   La stratégie de « l’Étranglement » (Strangler Fig) : la voie de la sécurité

La stratégie de « l’Étranglement » (Strangler Fig Pattern) est un pattern de modernisation progressive largement utilisé pour les applications Legacy.

Petit à petit, le nouveau système « étrangle » l’ancien jusqu’à le remplacer totalement. Ce modèle permet de réduire drastiquement le risque par rapport à un basculement “Big Bang”.

Au lieu de jeter l’ancien logiciel le vendredi soir pour lancer le nouveau le lundi matin (avec la panique qui accompagne généralement ce basculement), nous procédons par remplacement progressif.

• Nous construisons le nouveau logiciel (par exemple en Web/Symfony) module par module à côté de l’ancien.
• Les deux cohabitent. Par exemple, la « Gestion des Stocks » passe sur le nouveau système (brique de votre futur ERP sur mesure), tandis que la « Compta » reste sur l’ancien (Legacy).
• Petit à petit, le nouveau système « étrangle » l’ancien jusqu’à le remplacer totalement.

L’avantage ? Le risque est dilué. Vos équipes s’habituent progressivement au changement, et l’activité ne s’arrête jamais.

3. Le piège à éviter : le « lifting » graphique seul

Attention à ne pas confondre modernisation et maquillage.
Certains prestataires proposeront de simplement « refaire le design » (revamping UI) pour donner un coup de jeune.

C’est un piège dangereux s’il est fait seul. Si le moteur est lent, instable ou non sécurisé, peindre la carrosserie en rouge ne changera rien à la performance.

• Moderniser l’UX (Expérience Utilisateur) est indispensable pour l’adoption.
• Mais cela doit s’accompagner d’un travail de fond sur l’architecture (API, nettoyage de code).
  C’est le moment idéal pour re-questionner vos processus via un cadrage projet rigoureux : ne numérisez pas de vieux processus inefficaces, profitez-en pour les optimiser.

4. La migration des données : le trésor à sauver

Que vous choisissiez la refonte totale ou la modernisation progressive, l’enjeu absolu reste le patrimoine de données.
Vous avez 15 ans d’historique client, de commandes et de nomenclatures.

La migration de données est un projet dans le projet. Comme expliqué dans notre article sur l’interopérabilité, nous ne faisons pas de simples copier-coller. Nous profitons de la refonte pour :

• Nettoyer les données (doublons, erreurs).
• Restructurer l’information.
• Archiver ce qui n’est plus utile (pour alléger le nouveau système).