ETL, ESB, EAI, EDI, SOA, APIM. Les acronymes liés au transfert de données sont nombreux, et plusieurs d’entre eux désignent des notions qui se recoupent. Certains font référence à des concepts similaires, d’autres s’imbriquent parfaitement les uns dans les autres, tandis que d’autres encore ne se recoupent que partiellement. Il est donc facile de transformer un raccourci technique en décision d’achat.
Dans cet entretien, Édouard Cante, Chief Product Officer chez SoftProject, nous livre son point de vue sur la différence entre l'ETL et l'ESB, ainsi que sur les conséquences que cela implique, selon lui, pour les entreprises. Mais est-ce vraiment le bon débat à mener, compte tenu des besoins réels des entreprises ?
Dans un article précédent, nous étions arrivés à la conclusion que l'ESB et l'API management (APIM) étaient les deux faces d'une même médaille. En va-t-il de même pour les ESB et l'ETL ?
Édouard Cante : Non, mais leurs champs d'application respectifs se recoupent en partie : ils concernent tous deux le transport et la transformation des données au sein d'un système d'information. Compte tenu de leur nature, on pourrait estimer qu'il faut faire un choix en fonction du type de flux de données. Ce n'était pas le cas entre l'ESB et l'APIM, qui se complètent mutuellement.
La différence historique réside principalement dans la dimension architecturale. Les spécificités de l'ETL et de l'ESB ne sont pas faciles à cerner pour ceux qui ne sont pas experts en gestion des données. De plus, le paysage a évolué ces dernières années.
D'un point de vue historique, et peut-être de manière un peu simpliste, l’ETL s’avère efficace pour traiter d’énormes volumes lorsque les performances sont primordiales, mais que le nombre d’échanges n’est pas très élevé. Il traite les données en tant qu’ensemble, en bloc. Par exemple, si vous souhaitez obtenir le chiffre d’affaires total ventilé par client, l’ETL regroupera toutes les lignes et appliquera un traitement à l’ensemble de celles-ci. Cette approche par ensembles est notamment adoptée dans les domaines de la Business Intelligence et du Data Warehousing. À l’inverse, l’ESB est efficace pour traiter un grand nombre d’échanges à haute fréquence, chacun portant un volume de données limité, et impliquant une composante algorithmique dans le traitement. Il joue sans aucun doute un rôle dans la décloisonnement des données et dans le soutien d’une architecture orientée services (SOA) en agissant comme un bus d’échange sécurisé à l’échelle de l’ensemble du système d’information.
« Pour résumer à l'aide d'exemples extrêmes, l'ETL sert à créer des entrepôts de données à partir de systèmes de type ERP et CRM . L'ESB s'adresse à une entreprise qui souhaite utiliser une semi-interface pour exposer, par exemple, les devis, les commandes et les clients issus de son CRM, et permettre à d'autres applications de récupérer ces données en se connectant au bus d'applications. »
Édouard Cante, Chief Product Officer, SoftProject
Je suis toutefois fermement convaincu que ces différences historiques frôlent désormais la simplification excessive. Qui peut vraiment affirmer aujourd’hui qu’il achète un système ETL uniquement à des fins de BI ?
Pourquoi pensez-vous que la distinction entre ESB et ETL n'est plus valable ?
Édouard Cante : Une autre différence souvent mise en avant est que l’ETL est une technologie de type « pull », qui fonctionne à la demande, tandis que l’ESB est une technologie de type « push », qui génère des messages. Mais du point de vue du client, est-il envisageable de ne recourir qu’au « pull » ou uniquement au « push » ? Lorsqu’une entreprise a mis en place un système ETL et qu’elle a ensuite besoin de « pousser » des données, cette fonctionnalité ne peut pas être intégrée individuellement dans chaque application. Cela nécessite des développements spécifiques et met en évidence le problème qui est au cœur de cette distinction.
Si la distinction entre ESB et ETL était justifiée il y a dix ans, je suis fermement convaincu qu'elle n'est plus valable d'un point de vue métier. Des concepts différents n'impliquent pas nécessairement des solutions différentes. Demander au service informatique de choisir entre deux outils différents selon qu'il souhaite exposer ou interagir revient à aborder le problème sous le mauvais angle. Les besoins métier ne peuvent pas être limités par des contraintes techniques.
« Pour la plupart des entreprises, l'installation d'un ETL pur, d'une part, et d'un ESB pur, d'autre part, ne génère aucun retour sur investissement. »
Édouard Cante, Chief Product Officer, SoftProject
Mettez en place un socle de données fiable pour permettre une automatisation pilotée par l'IA et une prise de décision sûre. Téléchargez le livre blanc pour découvrir comment faire de la gouvernance des données une capacité stratégique — et tirer pleinement parti de l'automatisation évolutive et de l'IA.
Comment le marché a-t-il évolué depuis l'apparition des concepts d'ETL et d'ESB ?
Édouard Cante : À l’origine, il existait de réelles différences technologiques. Les marchés se sont scindés et ont évolué séparément. Certains éditeurs d’outils ETL ont empiété sur le domaine de prédilection des ESB pour gagner des parts de marché, et inversement. Parallèlement, les arguments marketing ont compartimenté les besoins en fonction de la technologie, afin de confirmer leur positionnement relatif. Les éditeurs de logiciels ESB ont également cherché à se définir comme des puristes.
«La bataille s'est principalement déroulée sur le plan technologique, et non en fonction des besoins réels. C'est une erreur ! »
Édouard Cante, Chief Product Officer, SoftProject
Les frontières sont donc devenues floues du point de vue du client, ce qui a donné lieu à des positions simplistes. Il existe une incompréhension généralisée quant à la nature d’un ESB et à son potentiel. L’ESB a parfois été réduit à un simple transporteur de données, négligeant complètement son rôle dans l’organisation globale du trafic de données — un point que nous abordons également dans notre article sur l’ESB, le middleware et les microservices. Il en résulte que de nombreux projets ont échoué en raison de ces approches dogmatiques.
J'ai vu un exemple chez un détaillant : le projet avait débuté par une cartographie théorique du trafic de données sur un magnifique schéma, dans le but de justifier le recours à un ESB à 100 %. Finalement, lorsque le projet a démarré, cette position extrême s'est heurtée à la dure réalité : certaines applications ne pouvaient pas l'utiliser en temps réel. Le projet s'est soldé par un échec total.
Si le fait de considérer l'ETL et l'ESB comme mutuellement exclusifs est une erreur, quel est alors le véritable problème ?
Édouard Cante : Le véritable enjeu, c’est de voir les choses sous un autre angle. C’est justement parce que le marketing impose le choix « soit ESB, soit ETL » que nous sommes confrontés à ces échecs ! Cette dichotomie n’a plus aucun sens dans la plupart des cas.
Le service informatique se retrouve contraint de choisir entre deux outils alors que ses besoins réels nécessitent les deux: dans la plupart des cas, il souhaite désiloiser les données et les faire circuler entre les différentes applications du système d'information, produire des analyses décisionnelles et centraliser les données au sein d'un système de gestion des données de référence (MDM). Le fait d'associer chaque concept à une solution différente l'oblige à s'écarter des besoins métier, sans qu 'il n'en tire aucun avantage.
«Il faudrait plutôt les associer. La solution doit répondre aux besoins de l'entreprise, et non à un dogme technologique. »
Édouard Cante, Chief Product Officer, SoftProject
Ce défi se pose même au sein des communautés d'utilisateurs qui maîtrisent plutôt les outils que les concepts. Les utilisateurs ont alors une vision limitée de la gestion des flux de données en tant que telle. C'est en comprenant les concepts que les utilisateurs peuvent gagner en maîtrise et adopter plus facilement différents outils.
Si la question n'est pas de savoir s'il faut privilégier l'ETL ou l'ESB, quelles questions faut-il se poser pour réussir la refonte des systèmes ?
Édouard Cante : Tout d’abord, il faut accepter la réalité et s’y adapter. S’il est important de cartographier les processus et de prendre du recul pour avoir une vue d’ensemble, une approche théorique du type « tout sera en SOA » ou « tout communiquera via des API » ne tient pas la route. Avoir une vision d’avenir, c’est bien, mais dans la réalité, les applications doivent pouvoir communiquer dès maintenant !
Les outils informatiques doivent s'adapter aux besoins de l'entreprise, et non l'inverse. L'objectif est d'harmoniser la collaboration au sein de l'organisation.
« Le débat entre ETL et ESB n'a pas de sens. Si l'on veut répondre aux besoins des services informatiques, ces deux domaines ne peuvent plus rester distincts. La distinction s'opère désormais entre, d'une part, le transport et la transformation des données et, d'autre part, l'exploitation des données. »
Édouard Cante, Chief Product Officer, SoftProject
S'il doit y avoir une différence, je la situerais à un autre niveau. Nous pouvons distinguer les solutions de transformation des données, qui assurent la sécurité des flux de données et les mettent à la disposition d’outils de préparation de données hautement fonctionnels, destinés à des rôles spécifiques, tels que les data scientists, la BI, etc.
Les métiers disposent ainsi d’outils hautement fonctionnels, conçus spécialement pour eux, tandis que le responsable des données conserve un rôle central pour garantir la qualité, la transformation et la disponibilité des données. Ce sont ces outils de préparation des données qui bouleversent le marché. L’autonomie des départements opérationnels prend tout son sens, sans pour autant qu’ils aient à s’impliquer dans la manière dont les données circulent. La circulation des données doit répondre à des enjeux cruciaux en matière de performance et de conformité légale.
« Le trafic de données doit être considéré dans son ensemble, quelle que soit la méthode utilisée pour transmettre les données en réponse à un besoin métier spécifique. La véritable différence, en termes d’outils techniques, réside désormais entre la transformation des données et leur préparation. »
Édouard Cante, Chief Product Officer, SoftProject
Je suis donc fermement convaincu qu’il est nécessaire à la fois de respecter les normes actuelles et de gérer les fameux « systèmes hérités » sur lesquels tout système d’information continue de fonctionner. Les clients qui utilisent des solutions ETL/ESB/EAI sont contraints de les utiliser avec ces applications, ils n’ont pas le choix. En tant qu’éditeurs de logiciels, nous devons donc nous aussi nous y conformer. Nous devons être la « boîte à outils » qui permet aux clients de faire circuler leurs données.
Qu'est-ce que cela signifie pour la plateforme SoftProject ?
Édouard Cante : Nous n'avons jamais accordé beaucoup d'importance à la différence entre l'ESB et l'ETL, car nos clients ne perçoivent pas leur problématique sous cet angle. Notre objectif est d'apporter une réponse globale aux défis liés à la refonte des systèmes d'information grâce à une plateforme modulaire qui unifie ces concepts autour des enjeux métier et des personnes.
La couche d'intégration de la plateforme SoftProject gère ces deux types de scénarios sur une base commune : les chargements en masse planifiés et les échanges déclenchés par des événements, grâce à plus de 200 adaptateurs prêts à l'emploi, à la transformation visuelle des données et à un bus ouvert et résilient. Lorsque ces données doivent piloter un processus concret, X4 BPMS le modélise et l'exécute en BPMN 2.0 sur la même plateforme, tandis que Phoenix assure la gouvernance et le contrôle de l'exécution de bout en bout.
Du côté de la gouvernance, la logique est la même. dataspot. gère les métadonnées et la traçabilité des données, MyDataCatalogue rend le patrimoine de données accessible, et la gestion des données de référence vous offre un enregistrement fiable au lieu de cinq enregistrements plausibles — un problème que nous abordons dans la section « Vue unique du client ».
Il existe certes quelques cas extrêmes où un système « ultra-ETL » s'avère nécessaire, mais en réalité, ceux-ci sont rares.
Lectures complémentaires : Interopérabilité et flux de données · Mise en œuvre d'un ESB · Choisir sa plateforme de données · Livres blancs et guides
En tant que directeur des produits, Édouard Cante est chargé de l'orientation stratégique et du développement du portefeuille de produits de SoftProject. Fort d'une excellente connaissance du marché et d'un esprit d'innovation très marqué, il promeut des solutions centrées sur le client et veille à la compétitivité à long terme de l'entreprise.
FAQ : ESB ou ETL ? :
Quelle est la différence entre l'ESB et l'ETL ?
L'ETL extrait les données, les transforme et les charge par lots : il s'agit de volumes importants et d'un nombre limité d'échanges planifiés. Un Enterprise Service Bus gère de nombreux petits échanges à haute fréquence entre les applications, généralement déclenchés par des événements et accompagnés d'une logique de traitement. Les deux technologies transfèrent et transforment les données ; elles diffèrent par l'unité de travail, et non par leur objectif.
Ai-je besoin à la fois d'un ESB et d'un outil ETL ?
Ces deux fonctionnalités sont indispensables. Quant à savoir si cela nécessite deux produits distincts, c'est une autre question — et pour la plupart des entreprises, la réponse est non. L'utilisation conjointe d'une solution ETL pure et d'un ESB pur entraîne généralement des coûts de licence supplémentaires, nécessite deux types de compétences distincts et crée une interface d'intégration entre les deux, sans pour autant répondre à un besoin qu'une plateforme unique ne pourrait pas satisfaire.
L'ETL fonctionne-t-il en « pull » et l'ESB en « push » ?
C'est le comportement par défaut de chacun d'entre eux, mais ce n'est pas une contrainte dont il faut tenir compte lors de la conception. Les organisations qui adoptent un modèle unique finissent par avoir besoin de l'autre, et l'adapter application par application correspond exactement au type de développement sur mesure qu'une couche d'intégration était censée éliminer.
Quel est le lien entre un ESB et la gestion des API ?
Elles sont complémentaires plutôt que concurrentes. L'ESB coordonne les services au sein de votre système d'information ; la gestion des API régit la manière dont ces services sont exposés et utilisés à l'extérieur de celui-ci — contrôle d'accès, suivi de l'utilisation, gestion des versions et normalisation.
