Moderniser un ERP legacy sans le remplacer

Thèse de cet article, réfutable : encapsuler un ERP legacy — API, couche d'intégration, front moderne — livre l'essentiel de la valeur d'une modernisation à une fraction du risque du remplacement intégral. Non parce que le remplacement échoue toujours : parce que sa distribution de risque est intenable.

L'étude de référence est datée ; sa leçon est statistique, pas conjoncturelle. En 2011, Flyvbjerg et Budzier (Oxford) analysent 1 471 projets informatiques : le dépassement de coût moyen est de 27 %. Cette moyenne rassure à tort. Un projet sur six dérape de 200 % en coût et de près de 70 % en délai.

Les cas audités donnent un visage à cette queue de distribution :

Détail décisif du cas Birmingham : le système remplacé était en service depuis 1999 et coûtait 5,1 M£ par an. Il fonctionnait. L'audit incrimine la gouvernance et la conduite du changement du projet — jamais le produit ni son éditeur. Le legacy n'était pas le problème : c'était un actif.

Le pattern a une source primaire : Martin Fowler, qui l'a nommé après avoir observé les figuiers étrangleurs du Queensland en 2001. Son billet de référence, réécrit le 22 août 2024, résume le sort des réécritures intégrales en huit mots :

« Go down in flames most of the time » — Martin Fowler, à propos des remplacements intégraux, Strangler Fig Application (version d'août 2024).

L'idée tient en trois affirmations. Remplacer par petits composants distribue le risque. Le retour sur investissement arrive plus tôt, pendant que le legacy continue de rendre service. Surtout, le pattern borne la perte maximale de chaque étape : un argument de gestion de risque, pas une mode d'architecture.

Ce n'est plus une opinion de blog. Microsoft le décrit dans son Azure Architecture Center : une façade intercepte les requêtes et les route vers le legacy ou vers les nouveaux services ; « l'approche incrémentale atténue les risques par rapport aux changements systémiques de grande ampleur ». AWS en a fait un guide prescriptif pour la modernisation de services web legacy, en créditant explicitement Fowler. Cette logique d'étapes bornées, dont chacune livre sa valeur, structure aussi notre façon de construire.

Beaucoup d'ERP en place exposent leurs fonctions via SOAP. Ce n'est pas une tare : SOAP 1.2 est une Recommandation W3C de 2007, « un protocole léger destiné à l'échange d'informations structurées » — un standard ouvert et documenté, qui ne périme pas. En 2023, 26 % des plus de 40 000 répondants de l'enquête Postman l'utilisaient encore. Encapsuler une API SOAP legacy est le quotidien de milliers d'équipes.

La démarche documentée par AWS tient en trois temps :

1. Façade    : des proxies en simple passe-plat devant les services SOAP existants
2. Contrat   : chaque fonction décrite dans une spécification OpenAPI (v3.2.0, sept. 2025)
3. Migration : redirection progressive, service par service, vers des API REST modernes

AWS recommande de commencer par les composants bien testés, à faible dette technique et à fort besoin d'évolution. Entre le nouveau front et l'ERP, une couche de traduction — l'anti-corruption layer, pattern issu du Domain-Driven Design d'Eric Evans et documenté par Microsoft — isole les nouveaux services des sémantiques du legacy. Ses coûts sont assumés : une latence supplémentaire, et un service de plus à exploiter. L'encapsulation n'est pas gratuite ; elle est bornée. Ce cadrage par étapes est détaillé dans notre méthode.

La fin de maintenance mainstream de SAP Business Suite 7, annoncée par l'éditeur en février 2020 pour fin 2027, alimente un discours d'urgence au remplacement. Le même communiqué prévoit pourtant une maintenance étendue optionnelle jusqu'à fin 2030, moyennant deux points supplémentaires sur la base de maintenance. L'éditeur lui-même laisse donc du temps. L'encapsulation permet de l'utiliser : la façade absorbe l'échéance au lieu de la subir.

Le risque inverse existe : l'encapsulation qui n'« étrangle » jamais rien. Le GAO (l'équivalent américain de la Cour des comptes) l'a mesuré en juillet 2025 : sur 10 systèmes legacy critiques identifiés en 2019, seuls 3 avaient achevé leur modernisation en février 2025. La parade est dans le pattern lui-même : chaque étape doit livrer une valeur autonome — un front utilisable, une intégration en production — et pas seulement préparer la suivante.

Ce que ça coûte de ne rien faire — Les agences fédérales américaines dépensent plus de 100 milliards de dollars par an en informatique, dont environ 80 % pour exploiter et maintenir l'existant (GAO, juillet 2025). Sur les 11 systèmes legacy critiques recensés, âgés de 23 à 60 ans, 8 reposent sur des langages obsolètes et 7 présentent des vulnérabilités de sécurité connues. Attendre ne fige pas le coût : cela concentre les risques sur un futur projet d'autant plus gros.

Moderniser un ERP sans le remplacer se décide sur des critères comparables ; chaque chiffre renvoie aux sources en fin d'article.

En comité, exiger pour chaque scénario la réponse à une seule question : quelle est la perte maximale si cette étape échoue ? Pour instruire ce comparatif sur votre système, nos services couvrent de l'audit de l'existant à la couche d'intégration.

L'encapsulation ne s'applique pas partout, et la documentation Microsoft liste elle-même les contre-indications : requêtes impossibles à intercepter par une façade ; système petit et simple, où le remplacement direct coûte moins cher que l'échafaudage ; besoin urgent de décommissionnement. S'ajoutent les coûts propres de l'anti-corruption layer : latence supplémentaire et un service de plus à exploiter et superviser. Enfin, le pattern exige une discipline de livraison : sans valeur autonome à chaque étape, on obtient le strangler éternel — une couche de plus posée sur le legacy, précisément ce qu'on voulait éviter. Si votre système coche une de ces cases, le remplacement direct peut être la bonne réponse.