Pourquoi certains systèmes legacy gagnent à être intégrés

Avant de choisir un outil d’intégration, déterminez si le système legacy est inadapté ou simplement difficile d’accès

Un ERP qui calcule encore correctement les commandes, les stocks et les indicateurs clients n’a pas besoin d’être remplacé simplement parce que ses données ne sont accessibles qu’au travers d’un écran vieux de dix ans. C’est un problème d’intégration : le système reste une source fiable, mais les logiciels modernes ne peuvent pas accéder proprement à ses réponses. Un système dont la logique d’état des commandes ne correspond plus aux opérations, ou dont le champ d’unité de mesure signifie des choses différentes selon la personne qui l’a renseigné, pose un autre problème. Son comportement sous-jacent ne permet plus d’accompagner le changement en toute sécurité.

Établissez cette différence avant de choisir une façade API, la capture des données modifiées (CDC) ou une plateforme d’intégration en tant que service (iPaaS). Commencez par consigner si le problème tient à l’impossibilité d’exposer des informations fiables ou à l’impossibilité de faire évoluer un système dont la logique ou le modèle est devenu invalide. Les progiciels d’entreprise doivent toujours composer avec les contraintes du legacy ainsi qu’avec les nouvelles exigences d’architecture et de conformité, mais ces contraintes ne justifient pas automatiquement la réécriture d’une logique métier correcte.

Les audits d’intégration constatent fréquemment le premier cas, et les praticiens à l’origine de ces approches décrivent la plupart des ERP comme relevant de cette situation. Les fournisseurs de modernisation ont aussi un intérêt commercial à ce qu’une organisation conclue qu’un remplacement est nécessaire, ce qui les incite à brouiller la distinction. Aucune de ces affirmations ne modifie le test architectural. Si l’ancien système donne la bonne réponse, isolez la manière dont les autres logiciels y accèdent ou l’interprètent ; si la réponse elle-même est de plus en plus erronée, une autre interface ne pourra pas corriger le comportement sous-jacent.

Une connexion peu coûteuse peut préserver le couplage que vous vouliez supprimer

La distinction devient concrète avec l’accès direct à la base de données, car il peut résoudre la connectivité en quelques heures tout en conservant presque tout le risque architectural. Un développeur ouvre une connexion à la base de données de l’ERP, interroge la table des commandes et livre le nouveau service. Il n’y a ni façade à construire, ni broker à exploiter, ni contrat versionné à définir, si bien que l’implémentation initiale peut sembler exceptionnellement efficace. Le coût a simplement été reporté jusqu’au premier changement incompatible de la base de données.

Ce changement crée une dérive de schéma, c’est-à-dire que la structure de la base de données ou la signification de ses données évolue sous les consommateurs. Une colonne renommée, un code de statut réaffecté ou une clé étrangère supprimée peut casser chaque service qui dépend directement de la table, sans version d’interface et potentiellement sans avertissement. La représentation interne de l’ERP devient alors une interface supportée alors même que personne n’a accepté de la supporter. Les personnes qui ont conçu ce schéma n’en sont souvent plus responsables.

Les effets apparaissent dans les revues d’intégration d’ERP et de systèmes cœur. Dans une mission, une demi-douzaine de services interrogeaient la même table de commandes tout en appliquant des interprétations différentes et non documentées au même code de statut. Dans ce type de revues, les anciens états de commande, indicateurs clients et concepts d’unité de mesure réapparaissaient régulièrement à l’identique dans des services modernes. Chaque équipe avait hérité indépendamment des hypothèses de l’ancien système et construit sa propre interprétation de celles-ci.

Ce couplage accumulé peut être acceptable pour une requête de reporting temporaire sur un système déjà programmé pour être retiré, lorsque la stabilité en aval n’a aucune valeur à long terme. En dehors de ce cas étroit, le faible coût opérationnel initial est trompeur, car un changement de schéma peut transformer directement le risque de maintenance différée en panne. Éviter ce résultat exige une frontière délibérée. La bonne frontière dépend de ce qui doit être isolé.

Choisissez la frontière en fonction de ce qui doit être isolé

Lorsque l’ancien système donne déjà la bonne réponse et que son interface constitue l’obstacle, une façade API crée un contrat maîtrisé. La façade est un service léger, détenu séparément, qui traduit l’interface legacy dans une forme que les applications modernes peuvent consommer, sans obliger ces applications à comprendre l’ancien schéma ni à modifier le code legacy. Pour un ERP dont les données utiles sont enfouies derrière des structures vieilles de plusieurs décennies, cela peut fournir un niveau d’isolation suffisant. Les praticiens de l’intégration décrivent la plupart des ERP comme relevant de cette large situation de « ne peut pas exposer ».

Parce que la façade prend en charge la traduction, son rôle diffère de celui d’une API gateway. La gateway gère les enjeux de trafic tels que le routage, l’authentification, la limitation de débit et la journalisation des requêtes sur un ou plusieurs backends. La façade protège les consommateurs de l’interface legacy en traduisant sa représentation. Mettre des endpoints ERP bruts derrière une gateway peut améliorer la gestion du trafic, mais les consommateurs restent couplés aux représentations de l’ERP.

Cette traduction fait de la façade une construction d’ampleur modérée : un service, une équipe et un contrat défini. Son coût récurrent apparaît lorsque le schéma ERP change et que quelqu’un doit mettre à jour la traduction, en particulier après le départ des ingénieurs qui l’ont construite. Plus important encore, une façade devient trop légère lorsque des concepts legacy réapparaissent inchangés dans le code moderne. À ce stade, la frontière doit isoler un modèle de domaine autant qu’une interface.

Une couche anti-corruption fournit cette frontière plus robuste en traduisant les concepts legacy dans le modèle de domaine utilisé par les nouveaux logiciels. Martin Fowler la décrit comme « une couche qui traduit entre deux modèles de domaine afin que les changements d’un côté ne se propagent pas à l’autre ». Un système legacy peut être correctement conçu pour son objectif d’origine et nécessiter malgré tout cette couche parce que son modèle diffère de celui qui convient aux nouveaux services. La traduction ne démontre donc pas, à elle seule, que le cœur legacy est erroné.

Les champs ERP rendent visible ce décalage de modèle. Des états de commande cryptiques, des indicateurs clients et des champs d’unité de mesure peuvent contenir des règles métier anciennes que les applications modernes ne devraient pas avoir à décoder chacune de leur côté. Lors d’une revue de code, un nom de champ legacy ou un code de statut repris tel quel dans un nouveau service constitue un signal d’alerte fort, surtout lorsqu’il faut demander à quelqu’un d’en expliquer le sens. Lorsque plusieurs consommateurs effectuent ce décodage indépendamment, chacun devient responsable de la compréhension du modèle legacy.

Parce que la couche anti-corruption centralise cette interprétation, sa construction exige des classes de traduction, des tests de mapping et un emplacement explicite pour une logique auparavant implicite dans un ancien schéma. Ce travail supplémentaire localise les changements ultérieurs : si un fournisseur ERP renomme une valeur de statut ou en ajoute une autre, la traduction peut être modifiée une seule fois au lieu d’obliger chaque service consommateur à changer. La frontière clé se situe entre la traduction d’un modèle legacy valide et la correction répétée d’un comportement devenu invalide. Une correction répétée déplace le problème vers la modernisation.

Des besoins d’accès différents appellent une frontière asynchrone. La CDC et le streaming d’événements conviennent lorsque les consommateurs ont besoin des changements en continu ou lorsque des interrogations répétées imposeraient une charge excessive à l’application legacy. La CDC lit le journal des transactions de la base de données et convertit les changements de lignes en événements sans modifier le code applicatif. Un broker ou une file d’attente peut ensuite distribuer ces événements à plusieurs services, évitant que chaque consommateur ne crée un nouveau chemin de requête vers l’ancien système.

Ce mécanisme de distribution suit une propriété que Gregor Hohpe et Bobby Woolf décrivent dans Enterprise Integration : producteurs et consommateurs sont découplés via des canaux intermédiaires. En pratique, de nouveaux services peuvent consommer un changement sans interroger directement l’ERP. Le même ouvrage apporte aussi un éclairage historique sur l’Enterprise Service Bus (ESB), un modèle d’intégration centralisé qui promettait un chemin commun pour le trafic inter-systèmes mais pouvait lui-même devenir un système legacy indésirable. Centraliser l’intégration déplace l’endroit où le couplage est géré, mais les enjeux de cycle de vie demeurent.

Ces enjeux de cycle de vie façonnent l’implémentation de la CDC. La construction est décrite comme modérée : un connecteur de journal de transactions, un schéma d’événement et des tests de contrat capables de révéler une dérive de schéma. Son exploitation exige une infrastructure de broker, une supervision du retard des consommateurs et une gestion de l’évolution des schémas, avec un effort qui croît à mesure que la population de consommateurs augmente plutôt qu’en fonction du seul nombre d’endpoints. Les recommandations d’AWS sur l’architecture orientée événements sont particulièrement pertinentes pour les garanties d’ordre et de livraison, car ces sémantiques peuvent créer des problèmes d’implémentation qu’un appel synchrone n’a pas. AWS vend de l’infrastructure cloud et des services orientés événements, et a donc un intérêt commercial à ce que les organisations adoptent des architectures qui utilisent ces capacités.

L’infrastructure de livraison ne peut pas non plus établir si un événement conserve encore la bonne signification métier. Si une colonne source est renommée ou réaffectée, un connecteur peut sembler fonctionner normalement tout en émettant des données incorrectes jusqu’à ce qu’un consommateur détecte le changement sémantique. Les tests de contrat sont importants parce que la santé de l’infrastructure ne peut pas prouver que les logiciels en aval interprètent encore correctement un événement. Pour un consommateur qui a simplement besoin d’une réponse synchrone, une façade est généralement plus simple et moins coûteuse ; lorsque la base de données ne fournit aucun journal de transactions exploitable, une exportation batch planifiée constitue la solution de repli appropriée plutôt que de qualifier une extraction périodique de streaming.

Au-delà de ces frontières un-à-un et un-à-plusieurs, l’échelle modifie de nouveau l’économie lorsque de nombreux systèmes aux formes indépendantes doivent échanger des informations. Les recommandations des praticiens situent le seuil de l’iPaaS à environ une douzaine de systèmes couvrant des formats, des calendriers et des protocoles différents. Lorsque seuls les deux premiers systèmes communiquent, une façade ou un pipeline CDC est moins coûteux à construire et à exploiter. Aux alentours d’une douzaine de systèmes, le travail sur mesure point à point peut approcher n² connexions, chacune avec son propre comportement de défaillance.

Un ERP, un CRM, un système de gestion d’entrepôt et plusieurs applications SaaS échangeant des données à des rythmes différents constituent le type de parc où l’iPaaS peut rentabiliser sa licence. La plateforme peut centraliser des intégrations qui, autrement, seraient conçues individuellement sur un ensemble croissant de systèmes. En contrepartie, l’organisation devient dépendante de connecteurs propriétaires et de transformations intégrées dans des DSL propres à la plateforme, c’est-à-dire des langages spécifiques au domaine utilisés pour définir ces transformations. Les coûts de licence peuvent aussi augmenter à mesure que des endpoints sont ajoutés.

Cette dépendance répète une leçon tirée de l’expérience ESB. Le traitement historique de ce modèle dans Enterprise Integration montre pourquoi une couche d’intégration centrale peut accumuler suffisamment de comportements embarqués et de dépendance organisationnelle pour devenir un autre système difficile à faire évoluer. Les produits iPaaS modernes peuvent reproduire ce problème de cycle de vie avec une technologie différente. La question décisive reste ce que la frontière isole : interfaces, modèles, charge de requête et coordination multi-systèmes relèvent de l’intégration, tandis qu’une frontière de plus en plus chargée de rendre correct un comportement cœur incorrect prend en charge un travail de modernisation.

Comparez le coût du cycle de vie au coût d’implémentation

Une fois la frontière choisie, son estimation d’implémentation ne couvre qu’une partie du coût. L’intégration consomme du calcul et des licences, mais elle consomme aussi une connaissance humaine spécialisée sur les raisons pour lesquelles les mappings, les retries et la gestion des événements se comportent comme ils le font. Une option qui minimise le projet initial peut devenir coûteuse après des années de changements de schéma, de croissance des endpoints et de rotation du personnel. Les hooks directs sur la base de données et les façades simples illustrent clairement ce schéma, car leur maintenance différée peut se transformer en panne lorsque le schéma legacy change.

L’iPaaS déplace une plus grande part de ce coût de cycle de vie vers une facture récurrente visible. Deux modèles tarifaires comptent dans les parcs observés fortement centrés sur les ERP : les plateformes peuvent facturer en fonction des connecteurs et du volume de données plutôt que de la complexité réellement résolue, et la licence peut évoluer avec le nombre de connecteurs ou d’endpoints plutôt qu’avec l’usage transactionnel. Ces modèles mettent en évidence le problème de planification même si les modèles de tarification varient. Les coûts par connecteur ont augmenté à plusieurs reprises dans les parcs ERP observés après que le travail d’intégration sous-jacent a cessé d’évoluer de manière significative.

Le cinquième système connecté illustre pourquoi l’unité de facturation compte. Son impact sur la licence peut augmenter qu’il déplace dix enregistrements par jour ou dix millions, et l’on a observé des budgets d’intégration dériver à la hausse simplement parce que le nombre d’endpoints augmentait sans augmentation significative des flux de données. L’unité économique de la plateforme peut donc différer de ce que l’entreprise perçoit comme une activité utile. Les revues d’architecture doivent inclure cette relation récurrente lorsqu’elles comparent les estimations d’implémentation.

La connaissance humaine récurrente crée une autre dépendance opérationnelle. Les couches d’intégration exigent une infrastructure d’automatisation et une refonte des processus, puis survivent souvent plus longtemps que les équipes qui les ont créées. Cinq ans plus tard, le personnel en place peut être incapable d’expliquer une règle de retry ou pourquoi un flux d’événements supprime les messages dupliqués d’état de commande. La dette technique a ici un sens précis : un système que les équipes ne peuvent pas modifier en toute sécurité, que son code paraisse ordonné ou non.

Un wrapper ne reste temporaire que si la responsabilité, les tests et une sortie sont explicites

Parce que la connaissance humaine peut disparaître, une couche d’intégration a besoin de contrôles explicites de cycle de vie dès le départ. Le risque devient concret lorsqu’une couche n’a ni propriétaire, ni tests vis-à-vis du système qu’elle encapsule, ni condition documentée de retrait. Lorsque ces trois éléments manquent, un pont temporaire peut devenir un autre système legacy tout en conservant une étiquette de temporaire. La frontière reçoit des changements des deux côtés, sa maintenabilité est donc une exigence opérationnelle.

Les tests apportent le premier contrôle en vérifiant les hypothèses par rapport au système legacy lui-même. Les modules ERP sont patchés, les codes de statut sont renommés et les mises à niveau des fournisseurs ajoutent des états de commande, de sorte que des tests limités aux nouveaux services ne peuvent pas détecter tous les changements pertinents. Une suite de tests liée aux mappings de la couche anti-corruption peut détecter cette dérive lorsqu’elle se produit. Sans cette vérification, la première preuve claire peut être un écart silencieux en production qui atteint les clients.

La responsabilité traite un autre échec du cycle de vie. La couche d’intégration devrait avoir un responsable nommé, distinct à la fois du responsable du système legacy et du responsable de la nouvelle plateforme, car la responsabilité de la frontière peut sinon tomber entre ces équipes. Les revues d’ERP et de systèmes cœur ont mis au jour des couches sans propriétaire qui ont survécu aux ingénieurs qui comprenaient leurs modes de défaillance. Une fois cette connaissance disparue, la maintenance ordinaire elle-même devient risquée.

Les contrôles de retrait concernent l’autre extrémité du cycle de vie et doivent figurer dans le document de conception plutôt que dans un élément de backlog sans condition de déclenchement. Les conditions utiles sont concrètes : « Démonter lorsque la migration ERP est terminée » et « démonter lorsque les consommateurs lisent directement depuis le flux d’événements ». Une frontière sans événement de ce type a en pratique été conçue pour une durée indéfinie, quel que soit le nom initial du projet. Le strangler fig pattern de Fowler ne fournit pas à lui seul une condition de suppression pour une infrastructure d’intégration dont le retrait n’a jamais été défini.

Ces contrôles deviennent plus importants à mesure que la frontière gagne en indépendance. Un signal d’alerte apparaît lorsqu’elle acquiert son propre cycle de release, se sépare opérationnellement des deux systèmes connectés et accumule une logique de mapping trimestre après trimestre. Les façades créent délibérément des contrats d’interface, les couches anti-corruption isolent délibérément des modèles, et la CDC crée délibérément des contrats d’événements ; les tests de contrat, une responsabilité explicite et des conditions de retrait permettent donc à ces contrats de rester modifiables. Si ces contrôles s’affaiblissent tandis que le comportement s’accumule, le wrapper commence à acquérir le même problème de maintenabilité que celui qu’il était censé contenir.

Lorsque la frontière commence à remplacer le cœur, relancez la modernisation

Ce problème de maintenabilité modifie la décision architecturale lorsque le problème sous-jacent passe de l’exposition d’informations fiables à la capacité de faire évoluer le système lui-même en toute sécurité. Un signal est une couche anti-corruption dont les règles de traduction croissent plus vite que la logique métier sous-jacente, laissant l’organisation maintenir deux modèles en évolution. Un autre est organisationnel : les ingénieurs actuels comprennent les modes de défaillance du wrapper mais ne peuvent plus expliquer le système cœur parce que sa responsabilité et sa connaissance d’origine ont disparu. L’isolation devient alors la conséquence par défaut d’une compréhension perdue plutôt qu’un choix architectural maîtrisé.

La sécurité peut aussi faire évoluer la décision de manière indépendante, car un cœur non supporté modifie le risque de chaque frontière qui l’entoure. Si le fournisseur legacy ne publie plus de correctifs, chaque point d’intégration supplémentaire peut accroître l’exposition autour d’un cœur non patché. L’économie peut produire le même effet lorsque l’exploitation du wrapper, l’astreinte, la maintenance des tests de contrat et une licence iPaaS dépassent ensemble le coût d’un replatforming amorti sur trois ans. Il s’agit d’heuristiques pratiques plutôt que de seuils financiers universels, en particulier lorsqu’un programme plus large de progiciels d’entreprise doit aussi satisfaire des exigences d’architecture et de conformité.

Ces signaux comptent davantage lorsqu’ils s’accumulent. Les praticiens considèrent chacun d’eux pris isolément comme gérable, et « Deux ou plus ensemble » comme le déclencheur d’une réouverture de la modernisation. À ce stade, un autre modèle d’intégration a peu de chances de traiter le problème devenu différent. Le wrapper a peut-être commencé comme un moyen légitime de préserver une logique correcte, mais l’accumulation de mappings, la disparition de la responsabilité, un logiciel non supporté ou une économie d’exploitation défavorable peuvent modifier la décision par la suite.

Une fois cette décision modifiée, une option de modernisation est le strangler fig pattern, que Martin Fowler a nommé en 2004. Il remplace progressivement les capacités tandis que la plateforme d’origine reste opérationnelle, en basculant chaque capacité après validation du remplacement. Cela en fait une stratégie de modernisation même si des frontières d’intégration peuvent intervenir pendant la transition. Une fois que l’encapsulation ne se justifie plus économiquement, le framework des 7 Rs est également suggéré comme point de départ de la discussion sur la modernisation ; pour les systèmes ecommerce, un guide de modernisation du legacy ecommerce est cité pour la stratégie, la feuille de route et les arbitrages de risque.

Points clés

• Vérifiez si le cœur donne encore la bonne réponse : Les équipes d’architecture peuvent distinguer les problèmes d’accès des problèmes de modernisation en vérifiant si la logique métier legacy reste fiable. Une logique correcte se prête à l’intégration ; un comportement de plus en plus invalide rend le remplacement plus crédible.
• Considérez l’accès direct à la base de données comme un couplage de long terme : Les requêtes directes réduisent l’effort de construction initial, mais exposent chaque consommateur à la dérive de schéma et à des hypothèses legacy non documentées. Réservez-les principalement aux cas de courte durée où la stabilité en aval a peu de valeur à long terme.
• Adaptez la frontière d’intégration au problème : Utilisez des façades API pour l’isolation des interfaces, des couches anti-corruption pour la traduction du modèle de domaine, la CDC pour la distribution continue des changements, et l’iPaaS pour les parcs multi-systèmes plus vastes. Réévaluez l’approche lorsque la frontière commence à corriger le comportement du cœur.
• Comparez l’économie du cycle de vie : Les responsables technologiques peuvent évaluer les options d’intégration en tenant compte des licences récurrentes, des opérations, des connaissances spécialisées, de la maintenance des schémas et de l’exposition aux pannes, en plus du coût d’implémentation. Une tarification iPaaS fondée sur les endpoints et la rotation du personnel peuvent modifier sensiblement l’économie au fil du temps.
• Attribuez à chaque wrapper un responsable et une sortie : Désignez un responsable nommé, testez les mappings par rapport au système legacy et définissez une condition concrète de retrait lors de la création de la frontière. Ces contrôles empêchent une infrastructure d’intégration temporaire de devenir un autre système legacy difficile.
• Relancez la modernisation lorsque les signaux d’alerte s’accumulent : Une logique de traduction qui croît rapidement, la perte de connaissance du système cœur, un logiciel non supporté et une économie d’exploitation défavorable indiquent que l’isolation perd de sa valeur. Plusieurs signaux réunis justifient de réévaluer un remplacement progressif ou une autre voie de modernisation.