Modernisation legacy pour les PME : renouveler ses applications sans paralyser l'activité

Tout dirigeant de PME connaît cette tension : un système a fait avancer l'entreprise pendant des années, mais plus personne n'ose y toucher. Une application de gestion des commandes sur Windows Server 2012, une application web en PHP 5 que seul l'ancien développeur comprenait, une base de données Access sur mesure dont dépendent la comptabilité et la planification de la production. La modernisation des applications legacy consiste à apporter une réponse honnête à cette situation : quand remplacer, quand bâtir sur l'existant, et comment le faire sans paralyser l'activité.

Qu'est-ce que la modernisation legacy, exactement ?

La modernisation legacy recouvre l'ensemble des décisions et des projets qui préparent vos applications métier vieillissantes pour les dix prochaines années. Cela peut consister à les installer dans un environnement cloud moderne sans toucher au code, à réécrire les modules les plus problématiques, ou à remplacer un système par un progiciel SaaS standard. Il s'agit rarement de « tout jeter et tout reconstruire », et encore plus rarement de « ne rien faire ».

On qualifie une application de legacy dès que l'une de ces trois conditions est remplie : il devient difficile de trouver des développeurs qui la maîtrisent encore, l'éditeur ne fournit plus de mises à jour de sécurité, ou chaque petite modification coûte un temps et un risque disproportionnés. Un système de 2015 peut déjà être legacy, tandis qu'un système de 2003 peut très bien tenir encore quelques années s'il tourne de manière isolée et à jour de ses correctifs.

Pourquoi les PME repoussent l'échéance (et ce que cela coûte)

Dans chaque comité de direction règne la même intuition : tant que ça tourne, il n'y a pas de crise. C'est vrai, jusqu'au jour où ça ne l'est plus. McKinsey a calculé que les entreprises paient 10 à 20 % de plus sur chaque projet informatique uniquement pour contourner la dette technique existante, et que chez un assureur étudié, la dette technique représentait, selon le système, entre 15 et 60 % du budget informatique. Pour une PME, ces chiffres se traduisent de manière plus concrète : chaque nouvelle demande d'évolution prend trois fois plus de temps que nécessaire, une panne coûte une demi-journée de production, et le prestataire qui est le seul à encore connaître votre stack augmente son taux horaire chaque année.

Le report a lui aussi un coût qui n'apparaît sur aucune facture. Les anciens systèmes tournent plus souvent sur une infrastructure non corrigée, ce qui complique le respect de votre obligation de sécurité au titre du RGPD et devient un réel problème si vous relevez de la nouvelle loi néerlandaise sur la cybersécurité (Cyberbeveiligingswet, transposition de NIS2). Notre guide complet sur NIS2 pour les PME néerlandaises montre qu'une politique de sécurité démontrable au sens de NIS2 englobe aussi vos anciennes applications.

Les six voies de modernisation en un coup d'œil

La littérature évoque généralement sept « R ». Pour les PME, nous retenons six voies qui comptent réellement, de la moins à la plus exigeante.

1. Retain : ne rien changer, en connaissance de cause

Vous conservez le système et assumez explicitement ce choix. C'est tout à fait envisageable s'il tourne de manière stable, si l'éditeur existe toujours et si les métiers en attendent peu. L'essentiel est de l'isoler : segment réseau dédié, règles de pare-feu strictes, sauvegardes qui fonctionnent et MFA sur chaque connexion. Sans cette hygiène, retain n'est pas un choix, mais un risque.

2. Retire : débrancher

Il arrive qu'un système ne soit presque plus utilisé. Exportez les données, archivez ce que la loi vous oblige à conserver (souvent sept ans pour les documents fiscaux aux Pays-Bas) et mettez-le hors ligne. Chaque système en moins, c'est une surface d'attaque en moins.

3. Rehost : déplacer sans modifier

Vous installez l'application telle quelle sur une infrastructure moderne, généralement dans le cloud. On parle aussi de « lift and shift ». En quelques semaines, vous vous débarrassez du matériel obsolète, mais le logiciel lui-même reste ce qu'il était. Utile si votre datacenter doit disparaître, et comme étape intermédiaire avant un futur projet de refactoring.

4. Replatform : reconstruire légèrement

Ici, vous modifiez des composants de manière ciblée. Le SQL Server autogéré devient une base de données managée, l'authentification migre vers Entra ID. La logique reste intacte. Pour de nombreuses PME, c'est la voie la plus intéressante : le meilleur résultat pour le moindre risque.

5. Refactor ou rearchitect : reconstruire le moteur

Vous conservez la finalité de l'application, mais vous en reconstruisez certaines parties de l'intérieur. Un monolithe devient quelques modules bien délimités, les intégrations codées en dur deviennent des API, l'interface se découple de la logique métier. Cette voie est rentable pour les systèmes à forte valeur métier qui freinent trop souvent le changement.

6. Rebuild ou replace : repartir de zéro ou adopter un progiciel

Parfois, le système ne correspond plus à votre entreprise. Un CRM maison de 2010 laisse place à un SaaS moderne, un système de gestion des stocks sur mesure est remplacé par un progiciel sectoriel. Le risque, c'est l'adoption : le progiciel fonctionne différemment, et vos processus doivent suivre.

Comment choisir la bonne voie pour chaque système

Un plan de modernisation pour une PME se résume rarement à « tout reconstruire » ou « tout replatformer ». C'est un arbitrage de portefeuille. Placez vos applications dans une matrice simple : la valeur métier sur un axe, la santé technique sur l'autre.

• Forte valeur, mauvaise santé : refactor ou rebuild. C'est là que vous investissez.
• Forte valeur, santé correcte : replatform. Vous consolidez un système que vous voulez garder.
• Faible valeur, mauvaise santé : retire ou replace. N'y consacrez pas de budget de modernisation.
• Faible valeur, santé correcte : retain. Isolez-le et laissez-le tranquille.

Cet exercice se fait en un après-midi avec le dirigeant, le responsable informatique et une personne qui connaît le travail au quotidien. Le résultat n'est jamais un chiffre, mais une courte liste de quatre ou cinq priorités pour l'année à venir.

Le pattern Strangler Fig, en termes simples

En 2004, Martin Fowler a proposé une image qui fonctionne toujours : votre nouveau système pousse autour de l'ancien comme un figuier étrangleur, fonction après fonction, jusqu'à ce que l'ancien puisse disparaître. Pour une PME, c'est essentiel, car il est rarement possible de se passer de son système métier pendant six mois. Concrètement : placez un proxy ou une passerelle API devant votre ancienne application, développez les nouvelles fonctionnalités derrière cette passerelle sur une infrastructure moderne, puis basculez progressivement les points d'accès existants de l'ancien vers le nouveau. L'utilisateur s'en aperçoit à peine, et si un nouveau composant ne fonctionne pas, il suffit de rétablir la règle de routage.

C'est presque toujours préférable à un « big bang » précédé de six mois de silence pendant lesquels tout le monde espère que la nouvelle version fonctionnera. Le big bang paraît audacieux, mais il concentre tous les risques sur une seule journée.

Combien ça coûte, en fourchettes réalistes

La modernisation se résume difficilement à un chiffre, car tout dépend du périmètre. Voici quelques ordres de grandeur que nous observons souvent dans les projets de PME.

• Rehost et replatform d'une application métier de taille moyenne : quelques dizaines de milliers d'euros, étalés sur quelques mois. Les coûts cloud récurrents remplacent en partie les anciens coûts de matériel et de licences.
• Projets de refactoring par module : selon l'ampleur, de 15 000 à 80 000 € par module, généralement répartis sur plusieurs trimestres pour que l'activité garde son rythme.
• Rebuild complet ou remplacement par un SaaS : rarement moins de 50 000 €, et souvent plusieurs centaines de milliers d'euros pour du sur-mesure avec intégrations.

Ne comparez pas ces montants uniquement à l'option « ne rien faire maintenant », mais aux coûts que vous payez déjà sans le dire : maintenance, solutions de contournement, mises en production lentes, risque.

Le legacy et le Data Act européen

Moderniser vers le cloud, c'est aussi composer avec le Data Act européen. Ce règlement s'applique aux services cloud depuis le 12 septembre 2025. À partir de janvier 2027, les fournisseurs ne pourront plus vous facturer de frais de changement de fournisseur ni de frais de sortie de données (egress), et chaque contrat devra comporter une clause de sortie prévoyant un transfert en 30 jours maximum. Pour votre projet de modernisation, cela signifie : exigez dès maintenant la portabilité dans vos nouveaux contrats, c'est-à-dire aucune dépendance forte à des formats de données propriétaires ou à un service managé spécifique sans alternative ouverte. Notre guide pour éviter la dépendance fournisseur (vendor lock-in) dans le cloud explique comment l'ancrer dans votre architecture.

Les six étapes d'un projet de modernisation sain

1. Inventaire du portefeuille. Une liste de toutes les applications avec leur propriétaire, version, hébergement, nombre d'utilisateurs et statut.
2. Matrice valeur-santé. Chaque application dans un quadrant, avec la direction et les utilisateurs finaux.
3. Une voie par système. Retain, retire, rehost, replatform, refactor ou replace, avec justification.
4. Séquencement et MVP. Quels trois systèmes traitez-vous dans les six prochains mois, et quelle est la première version minimale ?
5. Mise en œuvre de l'approche Strangler. Les nouvelles fonctionnalités derrière une passerelle, les points d'accès existants migrés un par un.
6. Capitaliser sur l'apprentissage. Chaque livraison apporte des connaissances pour la suivante. Documentez les choix d'architecture et l'automatisation des tests.

Lisez aussi notre guide pour élaborer une feuille de route informatique si vous souhaitez inscrire ce projet dans un plan pluriannuel plus large.

Les pièges fréquents dans les projets de PME

• Vouloir tout moderniser en même temps. Remplacer cinq systèmes en un an, c'est l'erreur classique. Répartissez sur plusieurs trimestres.
• Pas d'environnement de test. Sans environnement de test et de recette équivalent, aucune nouvelle version ne doit partir en production. Comptez 10 à 15 % du projet pour cette infrastructure.
• Pas de stratégie de données. Convenez à l'avance de la manière dont vous migrez les données et de qui est propriétaire de chaque champ.
• Remplacer l'ancienne dépendance par une nouvelle. Renseignez-vous sur les formats d'export, la documentation et la clause de sortie avant de signer.
• Uniquement l'informatique, pas les métiers. Sans porteur côté métier, toute modernisation s'enlise au bout de trois mois. Désignez un product owner issu du groupe des utilisateurs finaux.
• Oublier l'adoption. Une nouvelle interface plus efficace mais d'apparence différente semble toujours « moins bonne » les premières semaines. Formez, communiquez et réduisez au maximum cette période d'inconfort.

Ce que vous gardez en interne et ce que vous externalisez

En pratique, trois rôles sont toujours nécessaires : un product owner issu de votre propre organisation, un architecte qui veille à la cohérence à long terme et une équipe qui développe. Cette équipe peut être largement externe, et pour beaucoup de PME, c'est souvent la seule option réaliste. L'important est de documenter les connaissances à la fin de chaque sprint, pour ne pas devenir dépendant d'un seul profil senior. Notre pôle d'ingénierie logicielle est organisé de sorte que les connaissances et le code restent chez le client, avec des dépôts partagés et des moments de transfert.

Questions fréquentes sur la modernisation legacy

Quand la modernisation est-elle plus urgente qu'il n'y paraît ? Quatre signaux indiquent une urgence réelle : plus aucun prestataire ne maintient le système, l'infrastructure sous-jacente ne reçoit plus de mises à jour de sécurité, vous ne trouvez plus de développeurs pour la stack, ou chaque petite modification prend un temps disproportionné. Dans cette situation, attendre n'est plus un choix, mais un risque qui s'accumule chaque jour.

Faut-il passer au cloud, ou peut-on rester sur site ? Beaucoup de modernisations de PME se font vers le cloud, car les services managés vous déchargent des correctifs, des sauvegardes et de la montée en charge. Mais un environnement sur site stable peut tout à fait convenir aux applications soumises à des exigences de latence strictes ou à des classifications de données particulières. Le choix dépend de votre coût total de gestion, de votre équipe et de votre profil de risque. Notre guide pour choisir entre serveur et cloud vous aide à faire ce choix de manière argumentée.

Combien de temps dure un projet de modernisation dans une PME ? Pour une seule application, on observe en pratique de quelques mois à environ deux ans, selon l'ampleur et la complexité. Un rehost peut se faire en quelques semaines, un replatform en quelques mois, et un rebuild complet prend souvent de six mois à un an et demi. Si vous découpez vos projets en livraisons trimestrielles, vous disposez à chaque fois d'un point de réajustement.

Le pattern Strangler fonctionne-t-il aussi pour de très petits systèmes ? Oui, et c'est même souvent là qu'il est le plus efficace. Une petite application se découpe généralement en quelques points d'accès que vous pouvez reconstruire progressivement derrière un proxy. Comme le périmètre est réduit, vous pouvez même migrer plusieurs fonctions par sprint. Le principe est universel : mieux vaut une amélioration fonctionnelle chaque semaine qu'un grand saut incertain dans six mois.

Une subvention ou un avantage fiscal peut-il aider ? Parfois, oui. Aux Pays-Bas, des dispositifs d'innovation comme la WBSO peuvent rendre une partie de vos heures de développement fiscalement plus avantageuses. Vérifiez à l'avance si votre projet est éligible avant de compter sur une aide.

Conclusion

La modernisation legacy, ce n'est ni « tout refaire » ni « attendre encore un an ». C'est un arbitrage de portefeuille dans lequel vous choisissez délibérément, système par système, entre retain, retire, rehost, replatform, refactor ou replace, et dans lequel vous construisez les nouvelles fonctionnalités progressivement plutôt qu'en un seul grand saut. Commencez par un inventaire honnête, choisissez trois systèmes pour cette année, développez derrière une passerelle et gardez votre équipe attentive au transfert de connaissances.

Vous ne savez pas quelle voie convient à vos systèmes métier, ou vous souhaitez échanger sur un plan pluriannuel réaliste qui ne paralyse pas votre activité ? TRON Group accompagne les PME dans leurs projets de modernisation, de l'inventaire du portefeuille jusqu'à la livraison. Appelez-nous sans engagement au +31 85 303 5869 ou faites évaluer votre plan par notre pôle d'ingénierie logicielle.