ESB : définition, rôle historique, et pourquoi le mot prête encore à confusion

On dit « on a un ESB¹ » comme on dit « on a un ERP⁹ » : une boîte dans le schéma SI. Le problème, c'est que le mot ne désigne pas toujours la même chose. Parfois une architecture. Parfois une suite éditeur. Parfois juste l'habitude de tout faire passer au centre, sans que personne ait vraiment choisi ce modèle.

ESB¹ signifie Enterprise Service Bus, ou bus de services d'entreprise. C'est une plateforme, souvent centrale, qui fait dialoguer des applications hétérogènes : elle traduit les protocoles et les formats, route les messages, parfois transforme et orchestre. L'idée d'origine était que chaque système se branche au bus au lieu de parler à tous les autres en point à point.

Pour l'argument « trop vieux comme premier réflexe », voir l'ESB est trop vieux. Ici, on commence par le mot.

Ce que fait un ESB

En pratique, un ESB¹ découple les applications (chacune parle au bus, pas à tous les voisins), médie protocoles et formats derrière une façade, route et transforme les messages, et centralise le contrôle : audit, relances, connecteurs⁴ au même endroit.

Le modèle naît au début des années 2000, quand les interfaces standardisées entre applications étaient encore rares. Les premiers bus commerciaux (Sonic, IBM WebSphere) et le projet open source Mule (devenu MuleSoft) incarnent cette vague. Blueway, fondé vers 2003, s'inscrit dans la même lignée ; Talend ESB arrive plus tard (2011). Beaucoup de ces suites ont ensuite ajouté BPM⁵ et MDM⁶ sous le même toit.

Ce que ce n'est pas

Ce n'est pas un synonyme d'iPaaS² : l'iPaaS² est surtout une offre cloud sous abonnement (qu'est-ce qu'un iPaaS). Ce n'est pas non plus une simple file d'attente⁷ : la file fait attendre un message de façon fiable, alors que l'ESB¹ empile médiation, connecteurs⁴ et souvent de la logique métier dans le bus. Et ce n'est pas « toute intégration on-premise⁸ » : on peut intégrer chez soi sans bus central, c'est précisément le pari d'un runtime plus étroit.

Ce que le modèle a bien résolu

Dans des SI silotés, le point à point explosait. Les protocoles n'étaient pas standard. Beaucoup d'organisations voulaient un goulot gouverné. Pour 2005-2015, avec un ERP⁹ lourd et peu d'interfaces natives, le réflexe était rationnel. Le juger avec les yeux de 2026 sans ce contexte serait de mauvaise foi.

Ce qui a changé

Les applications exposent des API³ et des événements. Les files d'attente⁷ fiables découplent sans tout coller dans un bus. Pour la logique critique, le code versionné gagne souvent sur la configuration studio. Et en ETI¹⁰, le besoin du quotidien ressemble surtout à de la synchronisation de données, pas à une suite BPM⁵/MDM⁶ complète.

Quand garder un ESB

• Vous utilisez vraiment le BPM⁵ ou le MDM⁶ sous le même toit.
• Vous dépendez de protocoles lourds ou de connecteurs⁴ certifiés que vous ne voulez pas réécrire.
• La contrainte éditeur (marché public, support) pèse plus que la portabilité.
• La suite est déjà en place, et le coût de sortie dépasse encore le coût de rester.

Où se place Portlane

Portlane n'est pas un ESB¹, et ce n'est pas un hasard. C'est une plateforme d'intégration conçue pour un besoin précis : synchroniser des données entre vos systèmes, de façon fiable, sans acheter toute une suite.

Vous exécutez chez vous. La logique vit en Python dans votre dépôt : relisible, testable, transmissible. Licence à vie¹¹ : vous possédez le droit d'exécuter, vous ne louez pas le moteur tous les mois. Entre chaque étape, des files d'attente⁷ fiables : si un flux tombe, le message attend et se relance, au lieu de disparaître.

• Ce que vous gagnez : propriété du code, maîtrise de l'infrastructure, recrutement Python plutôt qu'experts d'un studio éditeur.
• Ce que nous refusons : bus central, BPM⁵, MDM⁶, catalogue de connecteurs⁴ à faire certifier par l'éditeur.
• Le pari : une ETI¹⁰ dont le quotidien est de faire circuler des données n'a pas besoin d'un bus d'entreprise pour le faire correctement.

Portlane est encore en développement actif : thèse produit claire, pas une migration à lancer lundi matin. Pour comparer éditeur par éditeur : Blueway, MuleSoft, Talend. Le récit complet : pourquoi nous construisons Portlane.

Pour aller plus loin

• Le jugement de modèle : l'ESB est trop vieux
• La catégorie cloud : qu'est-ce qu'un iPaaS
• Les patterns d'échec : dead letter queue
• ETL vs ELT : etl vs elt

Un ESB¹ est un bus de médiation, calibré pour un problème précis. Utile quand ce problème est encore le vôtre. Disproportionné quand votre quotidien, c'est surtout de faire circuler des données entre systèmes qui parlent déjà HTTP.

Questions fréquentes

L'ESB est-il « mort » ?

Non. Des suites tournent encore, et elles restent pertinentes dès que vous avez vraiment besoin de BPM⁵, de MDM⁶ ou d'une médiation profonde. Ce qui a vieilli, c'est le réflexe d'en faire le premier choix dès qu'il faut synchroniser des systèmes qui exposent déjà des API³. Thèse longue : l'ESB est trop vieux.

ESB et iPaaS, c'est la même chose ?

Pas vraiment. L'ESB¹ désigne d'abord un modèle d'architecture : un bus central, souvent on-premise⁸. L'iPaaS² est une catégorie commerciale cloud, en général sous abonnement. Certains iPaaS² reprennent des idées d'ESB¹, mais le contrat, le déploiement et le modèle économique ne sont pas les mêmes. Voir qu'est-ce qu'un iPaaS.

Quelle différence entre un ESB et une file d'attente ?

Une file d'attente⁷ fait une chose, et la fait bien : faire attendre un message de façon fiable. Un ESB¹ orchestre beaucoup plus : protocoles, connecteurs⁴, transformations, parfois de la logique métier dans le bus. Portlane s'appuie sur le premier modèle, pas sur le second.

Portlane est-il un ESB ?

Non. Portlane est une plateforme d'intégration au périmètre étroit : recevoir, transformer, livrer. Ni bus de médiation universelle, ni BPM⁵, ni MDM⁶. Encore en développement actif.

Quand faut-il encore choisir un ESB ?

Quand le besoin dépasse la synchronisation de données : orchestration de processus, référentiel maître, échanges multi-protocoles lourds, ou contrainte de marché public sur une suite déjà installée. Dans ces cas, le bus (ou la suite qui l'embarque) reste cohérent.

Glossaire

• ¹ ESB (Enterprise Service Bus) : bus de services d'entreprise, plateforme centrale qui fait dialoguer des applications hétérogènes.
• ² iPaaS : plateforme cloud d'intégration fournie en service, en général sous abonnement.
• ³ API : interface standardisée pour échanger des données entre logiciels.
• ⁴ Connecteur : module éditeur pour brancher une application précise sur une plateforme.
• ⁵ BPM : orchestration de processus métier.
• ⁶ MDM : référentiel de données maître.
• ⁷ File d'attente : stockage temporaire des messages entre étapes.
• ⁸ On-premise : déploiement dans votre infrastructure.
• ⁹ ERP : progiciel de gestion intégré.
• ¹⁰ ETI : entreprise de taille intermédiaire en France.
• ¹¹ Licence à vie : droit d'exécuter sans abonnement récurrent.