Le pattern "Strangler Fig" est une stratégie de modernisation logicielle qui remplace progressivement un système hérité par des composants plus modernes, une capacité à la fois. Il fonctionne en plaçant une façade devant le système existant, qui intercepte toutes les requêtes. Cette façade a pour rôle de router les requêtes soit vers le système hérité, soit vers le nouveau service, au fur et à mesure que les fonctionnalités sont migrées.
L'implémentation pratique de cette façade se fait généralement via un proxy inverse ou une passerelle API. Cette dernière analyse les requêtes et les dirige en fonction du chemin d'accès, des en-têtes ou de drapeaux de fonctionnalités, sans nécessiter de modifications du côté client. Il est crucial de noter que cette façade représente un coût opérationnel et de maintenance supplémentaire, car elle est active pendant toute la durée de la migration, qui peut s'étendre sur une longue période.
Une difficulté majeure dans l'application de ce pattern réside dans la gestion des données durant la période de coexistence des deux systèmes. La décision de qui "écrit en dernier" et contrôle donc la vérité des données doit être prise en amont pour éviter les problèmes de cohérence. De plus, le pattern peut échouer près de la fin si les derniers composants à migrer s'avèrent trop complexes ou mal définis, tandis que l'entreprise a déjà enregistré les bénéfices des migrations antérieures.
L’article passe en revue plusieurs patterns d’architecture particulièrement pertinents en 2026 et les replace dans des contextes concrets, loin de l’effet de mode, en détaillant leurs bénéfices réels, leurs pièges fréquents et les stacks technologiques qui les accompagnent. Sont étudiés dans cette partie le Strangler Fig Pattern, utilisé pour moderniser progressivement un système legacy par extraction incrémentale derrière une façade/API claire ; l’Anti-Corruption Layer (ACL), essentiel pour protéger un nouveau domaine métier des incohérences d’un ancien système ; l’architecture hexagonale (Ports & Adapters), qui isole le cœur métier des contraintes techniques pour faciliter les tests, les migrations et l’évolution technologique ; ainsi que le Service Mesh, présenté comme une réponse aux problématiques de communication, d’observabilité et de sécurité dans des architectures microservices, mais avec une complexité opérationnelle non négligeable.
Ces patterns sont replacés dans une vision d’ensemble avec ceux abordés dans la première partie — Event-Driven Architecture, API-First avec API Gateway et BFF, CQRS avec Event Sourcing, et le Saga Pattern — afin de proposer un panorama cohérent des choix architecturaux actuels. L’article insiste sur le fait que ces patterns ne sont pas des recettes universelles mais des outils à utiliser selon le contexte, la maturité de l’organisation et la nature du système existant, en montrant clairement quand ils apportent de la valeur… et quand ils compliquent inutilement l’architecture.
L'auteur explique un pattern qui permet de faire une transition d'un code "legacy" vers un code plus moderne... Et j'ai beaucoup ri à "If you think leaving French comments in the code is okay, go to hell." ^^