Déployer une infrastructure capable d’organiser les échanges entre applications suppose une expertise en intégration. Elle permettra de faire le bon choix entre les solutions d’hier, efficaces et largement éprouvées, et celles d’aujourd’hui, plus modernes et sophistiquées.
Savoir faire circuler les données entre les différentes applications composant un système d’information est essentiel afin de tirer le maximum d’avantages des technologies IT, notamment :
- une prise en charge des processus de bout en bout, permettant une automatisation avancée des traitements ;
- une meilleure qualité des données, du fait de la réduction des ressaisies et du nombre de référentiels.
La mise en place d’échanges de données interapplicatifs nécessite des efforts d’intégration, qui vont faire appel à tout un ensemble de techniques.
Années 1980 1990 : le règne des ETL, puis des EAI
Les traces des premières intégrations peuvent être retrouvées dès les années 1980, avec des scripts capables d’extraire les données d’une application, de les transformer, puis de les charger dans une autre application, selon la technique de l’ETL ; Extract, Transform, Load. C’est ce principe que nous retrouvons par exemple dans les intégrations visant à permettre aux mainframes de l’époque de communiquer avec des systèmes tiers.
Rapidement, des outils sont venus professionnaliser et industrialiser les travaux d’ETL. Toutefois, le principe de traitements batchs effectués – en général – la nuit est resté, avec tous les inconvénients que cela suppose en termes de ’fraîcheur’ des données, mais aussi de fiabilité, un traitement en erreur n’étant souvent détecté que le lendemain.
Une seconde vague d’outils émerge dans les années 1990, les EAI (Enterprise Application Integration). Ces solutions permettent l’intégration de données en point à point entre deux applications, le transfert des informations se faisant au fil de l’eau et donc en quasi temps réel. Arrive également le concept de web services, afin de s’adapter à un monde où Internet facilite grandement la création d’un SI connecté à l’international.
Années 2000 : l’essor des SOA et des ESB
Dans les années 2000, un nouveau terme fait son entrée : ESB, pour Enterprise Service Bus. Mais également une nouvelle approche pour définir des échanges de données : SOA, une architecture orientée services.
Là où les EAI se traduisaient par un plat de spaghettis de connecteurs, les SOA rationalisent les transferts avec des bus de données et des systèmes de files d’attente pour les messages, ce qui sécurise les échanges et la consistance des données. Les ESB se chargent d’organiser les échanges non plus en point à point, mais par demi-interfaces : la première interface récupère les données d’une application source et la seconde intègre les données dans l’application cible. Un modèle de données pivots, commun à toutes les interfaces, est défini au centre du dispositif.
Pour faire remonter une donnée du CRM à l’ERP, une première interface se charge de récupérer l’information voulue dans le CRM et de la transformer en donnée pivot. Le message est alors mis en file d’attente. Lorsqu’arrive le tour de son traitement, la seconde interface transforme la donnée pivot en information intelligible par l’ERP, avant de lui transférer. L’avantage apporté par le bus de données est que l’information issue de l’application source peut être ici consommée par plusieurs applications cibles.
Années 2010 : l’entrée en lice des microservices et des API
Avec l’essor du cloud, qui se poursuit aujourd’hui, de nouveaux concepts émergent, notamment les architectures à base de microservices. Là où les SOA permettaient de maximiser la réutilisation des points d’entrée, plusieurs applications pouvant consommer un même message sur l’ESB, les microservices passent à l’étape supérieure en termes de mise à disposition et de réutilisation des informations. Chaque action, chaque tâche peut ainsi être exposée en tant que service, que l’on pourra consommer à volonté, quand on veut et autant de fois que l’on veut.
Avec les microservices, la granularité n’a plus de limites : une application pourra proposer des services au travers d’API, que d’autres pourront consommer directement. Au besoin, des applications pourront se charger de consommer un service, puis de transformer les données pour aller les pousser dans un CRM ou un ERP ne gérant pas les API correspondantes. Etc. Un service pourra évoluer comme il l’entend et – à partir du moment où ses API ne sont pas modifiées – sans impact sur les autres services du SI, limitant ainsi les régressions qui pouvaient être constatées avec les applications connectées en point à point.
Comme avec leurs prédécesseurs, les microservices apportent leur lot de changements pour les développeurs, notamment en matière de sécurité, qu’il faut savoir gérer service par service. Mais également en matière d’API, qu’il faudra savoir définir et maintenir avec soin, des API instables faisant perdre une grande partie des bénéfices apportés par les microservices.
Il sera difficile de basculer vers les microservices sans opter au préalable pour une démarche de type DevOps. Faute de cela, l’approche SOA et les intégrations point à point restent deux techniques fiables sur lesquelles les entreprises pourront continuer à s’appuyer en toute confiance.
Notre expert
Donatien Seve
Manager Data Intégration
