November 11, 2026
November 11, 2026
Presque toutes les entreprises établies en ont un : le système auquel personne ne veut toucher. Il gère toujours les commandes, les stocks ou la comptabilité, mais il est lent à faire évoluer, difficile à connecter aux nouveaux outils, et seules une ou deux personnes comprennent vraiment son fonctionnement. Le remplacer semble risqué. Le garder semble coûteux. Ce guide présente les principales façons de moderniser un système hérité, ce qui fait varier le coût, les risques à surveiller et comment choisir l'approche adaptée à votre entreprise.
Sept façons de moderniser un système hérité
Un système hérité, ou système legacy, est un logiciel ou un matériel dont l'entreprise dépend encore, mais qui est devenu difficile ou coûteux à maintenir, à modifier ou à connecter à des technologies plus récentes. L'âge compte, mais il n'explique pas tout. Un système de dix ans bien documenté et facile à mettre à jour ne pose pas vraiment problème. Un système de cinq ans construit sur un framework abandonné, sans tests ni documentation, peut déjà être un système hérité.
Exemples typiques :
La modernisation des systèmes hérités consiste à mettre à jour ces systèmes pour qu'ils soient plus faciles à maintenir, plus sûrs à exploiter et mieux à même de soutenir l'activité. Cela ne signifie pas toujours tout recommencer. Parfois, une API bien placée ou un passage au cloud règle l'essentiel du problème.
La plupart des entreprises ne modernisent pas à cause d'un événement unique. La pression monte progressivement. Voici les signaux que nous rencontrons le plus souvent :
Si plusieurs de ces situations vous parlent, la modernisation vous coûte probablement déjà plus que vous ne le pensez.
Un projet de modernisation coûte de l'argent, d'où la tentation de garder l'ancien système « encore un an ». Mais maintenir des systèmes hérités en vie a aussi un prix, même s'il est réparti sur de nombreuses lignes budgétaires.
Le Government Accountability Office (GAO) américain offre un point de repère utile. Dans un rapport de 2019, il relevait qu'environ 80 % du budget informatique du gouvernement fédéral, soit plus de 90 milliards de dollars cette année-là, servaient à exploiter et maintenir les systèmes existants, y compris des systèmes hérités vieillissants. Il ne reste alors qu'une faible part pour la nouveauté. La plupart des entreprises n'en sont pas là, mais le schéma est familier : plus vous dépensez pour faire tourner d'anciens systèmes, moins il vous reste pour progresser.
Les coûts cachés des systèmes hérités comprennent généralement :
Aucun de ces coûts n'apparaît sur une facture unique, c'est pourquoi on les sous-estime facilement.
Un cadre très répandu, popularisé par le cabinet d'études Gartner, décrit sept options, souvent appelées les « R » de la modernisation. Elles vont de changements légers au remplacement complet. Le bon choix dépend de ce qui pose réellement problème : l'infrastructure, le code, l'architecture ou l'adéquation avec votre activité.
Encapsuler
L'encapsulation conserve le système existant mais l'entoure d'API, afin que des applications plus récentes puissent lire et écrire ses données de façon contrôlée. Par exemple, un distributeur peut garder son système de commandes vieux de 15 ans tout en ajoutant une couche d'API pour que son nouveau portail client et son application mobile consultent les stocks et passent commande directement.
C'est souvent la première étape la plus rapide et la moins chère, et elle soulage l'ancien système le temps de préparer la suite. L'inconvénient, c'est que l'ancien code reste en place, avec toutes ses limites. Notre guide sur ce qu'est l'intégration de systèmes présente les différentes façons de connecter des systèmes.
Réhéberger
Le réhébergement, aussi appelé « lift and shift », déplace l'application vers une nouvelle infrastructure, généralement le cloud, avec peu ou pas de modification du code. Il résout des problèmes comme des serveurs vieillissants, un centre de données coûteux ou une faible résilience. Il ne rend pas l'application plus facile à modifier, mais il peut être réalisé assez rapidement et crée une base stable pour la suite. Une bonne configuration cloud et hébergement et une migration de système à distance soigneusement préparée en sont les ingrédients clés.
Changer de plateforme
Le changement de plateforme va un peu plus loin. L'application passe sur une nouvelle plateforme avec des modifications légères et ciblées, comme l'adoption d'une base de données cloud managée ou d'une version plus récente de l'environnement d'exécution. Vous bénéficiez d'une partie des avantages du cloud, comme une montée en charge plus simple, des sauvegardes automatiques et moins de maintenance serveur, sans réécriture complète.
Refactoriser
La refactorisation améliore la structure interne du code sans changer ce que le système fait pour ses utilisateurs. Les développeurs suppriment les doublons, découpent les modules trop volumineux, ajoutent des tests automatisés et mettent à jour les bibliothèques obsolètes. C'est le bon choix quand le système remplit bien son rôle mais qu'il est devenu lent et risqué à modifier. La refactorisation se fait souvent progressivement, en parallèle des évolutions courantes.
Réarchitecturer
Réarchitecturer change la façon dont le système est construit, par exemple en découpant une grande application en services plus petits qui peuvent être développés, déployés et dimensionnés séparément. C'est pertinent quand l'activité exige bien plus d'évolutivité ou de souplesse que la conception actuelle ne le permet, comme pour un commerçant dont les commandes en ligne ont été multipliées par dix. C'est un projet important qui demande de solides compétences d'ingénierie.
Reconstruire
Reconstruire, c'est réécrire l'application de zéro avec des technologies modernes, en conservant sa finalité et ses règles métier essentielles. C'est approprié quand le code existant ne peut raisonnablement pas être sauvé, mais que le système fait encore quelque chose de spécifique à votre activité qu'aucun produit du marché ne gère bien. La reconstruction offre le plus de liberté et comporte le plus de risques, c'est pourquoi elle se fait souvent par étapes plutôt qu'en une seule fois. Il s'agit généralement d'un projet de développement de logiciel sur mesure.
Remplacer
Remplacer, c'est retirer l'ancien système et passer à un produit existant, souvent une plateforme SaaS. Cela fonctionne bien quand vos processus sont assez standard, comme la comptabilité, les RH ou un CRM simple, et que de bons produits existent déjà. L'essentiel du travail porte alors sur la migration des données, l'intégration et l'adaptation de vos processus au nouvel outil. Si vous hésitez entre un outil packagé et un développement sur mesure, notre comparatif entre low-code et développement sur mesure peut vous aider.
En pratique, beaucoup de projets combinent plusieurs approches. Une entreprise peut remplacer son ancien module comptable par un SaaS, réhéberger son système de commandes dans le cloud et l'encapsuler avec des API pour qu'un portail client nouvellement développé puisse dialoguer avec lui.
Il n'existe pas de prix standard, car le travail va de l'ajout de quelques API à la reconstruction d'un système central. Ce que l'on peut faire, c'est comparer les approches et comprendre ce qui fait varier le coût de chacune.
Les principaux facteurs de coût sont :
Une façon raisonnable de maîtriser le coût est de commencer par un diagnostic. Quelques semaines consacrées à cartographier le système, ses données, ses utilisateurs et ses connexions se rentabilisent généralement en évitant de choisir la mauvaise approche. Nos services de conseil commencent souvent précisément par là.
Les projets de modernisation échouent plus souvent à cause d'une mauvaise préparation que d'une mauvaise technologie. Voici les risques qui méritent le plus d'attention.
Le passage de l'ancien au nouveau système est le moment le plus dangereux du projet. La banque britannique TSB l'a appris en avril 2018, lorsqu'elle a migré les comptes de ses clients vers une nouvelle plateforme informatique. La plateforme a immédiatement connu de graves problèmes, et une part importante de ses 5,2 millions de clients a été touchée, en agence, par téléphone, en ligne et sur mobile. Il a fallu attendre décembre 2018 pour un retour à la normale. En 2022, les régulateurs britanniques ont infligé à TSB des amendes totalisant 48,65 millions de livres, estimant que la banque n'avait pas organisé ni contrôlé correctement son programme de migration, ni géré les risques liés à ses contrats d'externalisation.
Peu d'entreprises sont confrontées à une telle échelle, mais la leçon vaut pour toutes. Évitez autant que possible une bascule unique en « big bang ». Migrez par étapes, faites tourner l'ancien et le nouveau système en parallèle pendant un temps, répétez la bascule et préparez un plan de retour arrière testé au cas où quelque chose tournerait mal.
Les systèmes hérités contiennent souvent des années de petites règles que personne n'a écrites : un tarif spécial pour un client, une exception fiscale, un contournement pour le format de fichier d'un fournisseur. Si le nouveau système les oublie, les problèmes apparaissent des semaines après le lancement. La parade, c'est une analyse minutieuse : lire le code, interroger les utilisateurs de longue date et comparer les résultats de l'ancien et du nouveau système sur des données réelles.
Les anciennes données sont rarement aussi propres qu'on le pense. Clients en double, champs manquants et formats incohérents sont la norme. Traitez le nettoyage des données comme un projet à part entière, migrez des lots de test tôt et vérifiez les résultats avec les personnes qui utilisent ces données au quotidien.
Une fois le projet lancé, chacun a sa liste de souhaits. Ajouter de nouvelles fonctionnalités pendant la migration rend le projet plus long, plus coûteux et plus difficile à tester. Une règle pratique consiste à reproduire d'abord ce que fait l'ancien système, puis à l'améliorer dans des phases ultérieures.
Un système techniquement parfait échoue quand même si les équipes ne l'utilisent pas. Impliquez les utilisateurs tôt, formez-les avant le lancement et gardez un canal de retours ouvert pendant les premiers mois.
Une technique très répandue pour réduire la plupart de ces risques est l'approche dite « strangler ». Au lieu de remplacer tout le système d'un coup, on construit de nouvelles fonctions autour de l'ancien système, morceau par morceau, en y transférant progressivement les utilisateurs et les données jusqu'à pouvoir éteindre l'ancien. C'est plus long, mais chaque étape est plus petite et plus facile à annuler.
Chaque projet est différent, mais la plupart des modernisations réussies suivent un chemin similaire.
1. Faire l'état des lieux. Listez les systèmes, leurs utilisateurs, leurs données, leurs connexions et leurs points de douleur. Notez les parties critiques et celles qui servent rarement.
2. Définir les besoins de l'entreprise. Soyez clair sur l'objectif : réduire les coûts d'exploitation, renforcer la sécurité, accélérer les évolutions, ajouter des intégrations ou soutenir la croissance. L'objectif détermine l'approche.
3. Choisir une approche pour chaque partie. Tous les modules n'appellent pas le même traitement. Certains peuvent être retirés, d'autres encapsulés, d'autres reconstruits.
4. Commencer par un pilote. Choisissez une partie importante mais pas la plus critique, et modernisez-la en premier. Vous en apprendrez beaucoup sur les données, les règles cachées et l'équipe avant de vous attaquer au cœur du système.
5. Migrer par étapes. Transférez utilisateurs, données et fonctions progressivement, avec des tests et une possibilité de retour arrière à chaque étape. L'assurance qualité et les tests sont particulièrement importants ici, y compris la comparaison des résultats entre ancien et nouveau système.
6. Décommissionner l'ancien système. Une fois que tout a été transféré et vérifié, arrêtez proprement l'ancien système. Archivez les données que vous devez conserver et résiliez les licences et contrats devenus inutiles. Beaucoup de projets sautent cette étape et finissent par payer deux systèmes.
Serdao développe et maintient des logiciels d'entreprise depuis plus de 18 ans, sur plus de 50 technologies. Notre modèle associe une gestion de projet à l'européenne, depuis notre siège en France, à des équipes de développement basées à Hô Chi Minh-Ville, au Vietnam.
Nous pouvons vous accompagner sur :
Si vous déplacez aussi des systèmes vers de nouveaux serveurs ou de nouveaux sites, notre article sur la migration de système à distance explique comment ce travail est généralement planifié.
Vous avez un système dont vous ne savez pas quoi faire ? Découvrez nos services de développement logiciel ou contactez notre équipe pour en parler.
Conclusion
Moderniser un système hérité ne signifie pas forcément une réécriture risquée en tout ou rien. Pour beaucoup d'entreprises, le meilleur chemin commence petit : une couche d'API pour relier l'ancien système aux nouveaux outils, un passage au cloud, ou le remplacement d'un module qui bloque clairement tout le reste.
L'essentiel est de comprendre ce que vous avez avant de décider ce qu'il faut changer, de choisir une approche pour chaque partie du système et d'avancer par étapes que vous pouvez tester et annuler. L'activité continue ainsi de tourner pendant que ses systèmes rattrapent leur retard.
1. Qu'est-ce que la modernisation des systèmes hérités ?
C'est le processus de mise à jour de logiciels ou d'infrastructures dépassés pour les rendre plus faciles à maintenir, plus sûrs et mieux à même de soutenir l'activité. Cela va de l'ajout d'API à un ancien système jusqu'à son passage au cloud, sa reconstruction ou son remplacement par un nouveau produit.
2. Quelles sont les principales approches de modernisation ?
Les sept options les plus citées sont encapsuler, réhéberger, changer de plateforme, refactoriser, réarchitecturer, reconstruire et remplacer. Beaucoup de projets en combinent plusieurs selon les parties du système.
3. Combien de temps dure un projet de modernisation ?
Cela dépend de l'approche et de la taille du système. Ajouter des API ou réhéberger peut prendre de quelques semaines à quelques mois. Reconstruire ou remplacer un système métier central prend généralement de nombreux mois et se découpe souvent en phases.
4. Vaut-il mieux reconstruire ou remplacer un système hérité ?
Remplacez-le si vos processus sont assez standard et que de bons produits existent déjà. Reconstruisez-le s'il soutient une façon de travailler propre à votre entreprise que les produits du marché gèrent mal.
5. Quel est le plus grand risque d'une modernisation ?
La perturbation de l'activité au moment de passer de l'ancien au nouveau système, souvent causée par des problèmes de données ou des règles métier oubliées. Migrer par étapes, faire tourner les systèmes en parallèle et prévoir un plan de retour arrière réduisent fortement ce risque.
6. Peut-on moderniser sans arrêter l'activité ?
Oui, dans la plupart des cas. Les approches progressives transfèrent fonctions et utilisateurs petit à petit, si bien que l'ancien système continue de fonctionner jusqu'à ce que chaque partie du nouveau ait été testée et validée.
7. Comment savoir quelle approche convient à mon système ?
Commencez par un diagnostic du code, des données, des intégrations et des utilisateurs du système, et soyez clair sur l'objectif métier. Cette analyse indique généralement la bonne approche pour chaque partie, et elle coûte bien moins cher qu'un mauvais choix.