L'ESB* a vingt-cinq ans : encore utile, plus le bon pari par défaut

Votre plateforme d'intégration tourne. Elle a été choisie il y a huit ou douze ans, elle fait le travail, et personne au comité de direction n'a de raison d'ouvrir le sujet. C'est exactement pour ça qu'il mérite d'être ouvert : la question n'est pas de savoir si ça marche aujourd'hui, mais ce que ça coûtera de la faire évoluer, de la reprendre ou d'en sortir dans trois ans.

L'ESB* (Enterprise Service Bus, ou bus de services d'entreprise) est né au début des années 2000 pour un problème réel : faire dialoguer des applications qui n'avaient pas été conçues pour ça. Peu d'interfaces standardisées, peu de notifications automatiques entre systèmes, des protocoles différents partout. Le bus central, avec ses connecteurs*, sa médiation et sa distribution, était la réponse rationnelle.

Vingt-cinq ans plus tard, la plupart des systèmes que vous branchez exposent déjà des API*, des notifications automatiques et parfois des événements. Le problème que l'ESB* résolvait s'est en grande partie résorbé par la conception même des logiciels modernes. Ce qui reste, c'est un modèle lourd pour un besoin qui, dans beaucoup d'ETI, se résume à : recevoir une donnée, la transformer, la livrer, pouvoir relancer si ça casse. Pour le comparatif technique neutre ETL* vs ESB* (volumes, intensité, ressources), voir le guide BastionLab.

L'ESB* n'est pas mort. Des suites tournent, tiennent des contrats, et restent le bon outil quand vous avez vraiment besoin de la profondeur. Ce qui est trop vieux, c'est d'en faire le choix par défaut dès qu'il faut synchroniser quatre systèmes.

Ce que l'ESB* faisait bien, et pourquoi ça comptait

Il faut être juste. L'ESB* a réglé des problèmes que les liens directs entre applications ne réglaient pas :

• Le découplage : chaque application se connecte au bus, pas à toutes les autres. Ajouter un système ne multiplie pas les liens un à un.
• La traduction entre mondes techniques : formats et protocoles hétérogènes, absorbés par le bus derrière une façade unique.
• Le contrôle central : routage, transformations, relances et audit au même endroit.
• La réactivité : les échanges partent dès qu'une donnée arrive, là où un traitement de nuit ne suffisait plus.

Pour un SI des années 2005 à 2015, avec un ERP* lourd, des applications métier silotées et peu d'interfaces natives, ce modèle tenait la route. Beaucoup d'organisations françaises l'ont adopté pour de bonnes raisons. Blueway, Talend ESB*, MuleSoft et d'autres en portent encore la trace.

Ce qui a changé autour du bus

Le paysage d'intégration n'est plus celui de 2005. Quatre déplacements structurels rendent le bus central moins nécessaire, et plus difficile à justifier en budget :

• Les applications parlent un langage commun. CRM*, ERP* cloud, outils métier SaaS* : le connecteur* exotique est devenu l'exception, pas la règle.
• Les notifications et les appels planifiés remplacent une partie de la médiation. La source pousse l'information, ou on la récupère sur une interface documentée. Pas besoin d'un connecteur* certifié pour chaque éditeur.
• Les files d'attente* fiables sont devenues un standard. On sait aujourd'hui découpler les systèmes sans coller toute la logique métier dans un bus.
• Le code a gagné sur la configuration propriétaire. Revue, tests, recrutement : les équipes ne veulent plus que la logique critique vive uniquement dans un studio éditeur.

Résultat : pour une synchronisation entre un CRM*, un ERP* et deux outils métier, le besoin réel ressemble davantage à un chemin simple et ordonné, recevoir, orienter, transformer, livrer, qu'à une plateforme de médiation de services d'entreprise.

Où l'ESB* reste pertinent

Dire qu'un modèle est vieux n'est pas dire qu'il est inutile. L'ESB* reste le bon choix quand :

• Vous avez réellement besoin d'orchestration de processus (BPM*) ou d'un référentiel de données maître (MDM*) sous le même toit.
• Votre paysage impose encore des échanges techniques lourds, formats industriels, protocoles hérités, connecteurs* certifiés, que vous ne voulez pas réécrire.
• Le support éditeur et la contractualisation, secteur public ou grand compte, pèsent plus que la portabilité de votre logique.
• La suite est déjà en place, les flux critiques y tournent, et le coût de sortie dépasse le coût de rester, pour l'instant.

Dans ces cas, remplacer l'ESB* par principe est un mauvais calcul. Le mauvais calcul inverse, c'est de payer et d'exploiter une suite ESB*, BPM* et MDM* pour une trentaine de flux de synchronisation. C'est la situation la plus fréquente que l'on rencontre, et personne ne l'a décidée : elle s'est installée par reconduction de contrat.

La vraie question n'est pas technique

Être prêt pour la suite, ce n'est pas « ça tourne encore ». C'est : dans cinq ans, une équipe nouvelle peut-elle relire, tester, faire évoluer et sortir de cette couche sans lancer un programme pluriannuel ? Posée comme ça, la question cesse d'être un débat d'architecture et redevient une question de coût, de risque et de continuité.

• Compétence de niche : le vivier ESB* et BPM* propriétaire est étroit et cher. Python et les pratiques d'ingénierie classiques se recrutent et se transmettent.
• Logique opaque : une configuration de bus ne se relit pas comme du code. Difficile à contrôler, difficile à tester, difficile à transmettre lors d'un départ.
• Périmètre qui gonfle : la suite pousse le BPM*, le MDM*, la gestion d'API*. Vous payez et maintenez ce que vous n'utilisez qu'à moitié.
• Dépendance de trajectoire : la feuille de route produit, les connecteurs*, le modèle de licence, c'est l'éditeur qui décide. Un rachat change la donne du jour au lendemain, comme l'a montré le cas Blueway / SoftProject.
• Décalage avec le SI d'aujourd'hui : applications connectées, API* versionnées, flux explicites. Le réflexe n'est plus « tout passe par le bus », c'est « chaque flux a un chemin clair et observable ».

Un système qui tourne n'est pas un système que vous pouvez encore faire évoluer à coût raisonnable. C'est la distinction qui compte quand le sujet remonte en comité de direction.

Ce qui a remplacé le bus : étapes, files, code

Pour synchroniser des données entre systèmes qui exposent des API*, l'approche moderne n'est plus un hub de médiation. C'est un chemin linéaire, avec une file d'attente* fiable entre chaque étape :

• Entrée : la donnée arrive, par notification ou récupération planifiée, et attend son tour.
• Orientation : des règles simples envoient le flux vers le bon traitement.
• Transformation : la logique métier, écrite en code, testable et versionnée.
• Livraison : envoi vers le système cible, avec relances si besoin.
• Supervision : hors du chemin de la donnée. Santé, rejeu, journal des événements.

Le découplage ne vient plus d'un bus central. Il vient des files d'attente* fiables entre chaque étape : si quelque chose tombe, le message attend et se relance. Rien ne disparaît en mémoire, et personne ne passe la matinée à rejouer des flux à la main.

Comment Portlane tranche

Portlane n'est pas un ESB* relooké. C'est une plateforme d'intégration au périmètre plus étroit : recevoir une donnée, la transformer, la livrer. Chez vous, en Python, sous licence perpétuelle.

• Pas de bus central : un chemin simple et ordonné, pas une médiation de services d'entreprise.
• La logique vous appartient : les transformations sont du code versionné, relisible et testable, pas une configuration éditeur.
• Rien ne disparaît en cas d'incident : les messages attendent leur tour, se relancent, et l'équipe voit ce qui a échoué.
• Périmètre assumé : intégration de données uniquement. Pas de BPM*, pas de MDM*, pas de catalogue de connecteurs* à faire certifier par l'éditeur.

Le pari : une ETI dont le besoin réel est de synchroniser des systèmes n'a pas besoin d'un bus d'entreprise pour le faire correctement.

ESB* et Portlane, côte à côte

• Rôle ESB* : médiation de services, et souvent de la logique métier dans le bus. Portlane : chemin d'intégration simple, recevoir, transformer, livrer.
• Exécution ESB* : tout passe par le bus central. Portlane : étapes ordonnées, avec files d'attente* fiables entre elles.
• Transformations ESB* : configuration studio et formats propriétaires. Portlane : code Python versionné, relisible en revue.
• Périmètre ESB* : souvent ESB*, BPM*, MDM* et catalogue de connecteurs*. Portlane : intégration de données uniquement.
• Propriété ESB* : dépend de l'éditeur. Portlane : votre code, licence perpétuelle, exécution dans votre infrastructure.
• Exploitation ESB* : console éditeur, expertise de niche. Portlane : supervision claire, santé, rejeu, journal, sans boîte noire.

La ligne qui compte : Portlane n'essaie pas d'être un ESB* moderne. Il refuse le catalogue de connecteurs*, le dessin de flux à la souris et la suite BPM* et MDM*, volontairement.

Ce que ça change au niveau d'une direction

• Coût : vous payez l'intégration dont vous avez besoin, pas une suite entière utilisée à moitié.
• Risque de dépendance : la logique vit chez vous. Un rachat d'éditeur ne décide plus de votre trajectoire.
• Continuité : une équipe peut reprendre les flux sans le seul spécialiste de la plateforme, et un départ cesse d'être un risque d'exploitation.
• Sortie : vous repartez avec votre logique, pas avec un export propriétaire illisible.

Précision utile : Portlane est encore en développement actif. Ce qui précède décrit un positionnement produit et une plateforme en construction, pas une migration à lancer lundi matin. Si votre urgence porte sur un éditeur précis : Blueway, Talend, MuleSoft, Workato ou Boomi.

Comment trancher concrètement

• Listez vos flux actifs et classez-les honnêtement : synchronisation de données, orchestration de processus, référentiel maître, échanges techniques lourds.
• Si l'essentiel du volume opérationnel est de la synchronisation entre applications connectées, vous n'avez probablement pas besoin d'un ESB* pour ce périmètre.
• Gardez l'ESB* là où le BPM*, le MDM* ou les protocoles lourds sont réels. Ne forcez pas un remplacement idéologique.
• Pour le reste, un chemin ordonné, des files fiables et des transformations en code suffisent. C'est le modèle que Portlane met en place.

Cet inventaire prend une demi-journée et ne coûte rien. Il donne surtout une réponse chiffrée à une question qui reste souvent sans réponse : combien de votre budget d'intégration finance un périmètre que vous n'utilisez plus.

L'ESB* a été la bonne réponse à une époque. Il reste la bonne réponse à certains problèmes. Il n'est simplement plus la bonne réponse par défaut, et il n'est pas raisonnable de continuer à décider comme si le SI de 2026 était encore celui de 2005. Critères techniques ETL* / ESB* : BastionLab.

Questions fréquentes

L'ESB* est-il « mort » ?

Non. Des suites ESB* tournent encore, tiennent des contrats critiques, et restent le bon outil quand vous avez réellement besoin d'une médiation de services profonde, d'un BPM* ou d'un MDM* sous le même toit. Ce qui est mort, c'est le réflexe de poser un bus central dès qu'il faut synchroniser deux systèmes qui exposent déjà des API*.

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

Un ESB* orchestre beaucoup de choses à la fois : protocoles, connecteurs*, transformations, et souvent de la logique métier dans le bus lui-même. Une file d'attente* ne fait qu'une chose : garantir qu'un message attend son tour, survit à une panne, et peut être relancé. Portlane s'appuie sur ce second modèle, plus simple à exploiter et plus facile à auditer.

Pourquoi du code Python plutôt qu'une configuration éditeur ?

Parce que la logique de vos flux doit pouvoir être relue, testée et transmise comme le reste de votre SI. Une configuration propriétaire dépend d'une compétence rare et d'un produit. Python se recrute, se documente et se reprend sans le seul expert de la plateforme.

Portlane remplace-t-il un ESB* complet ?

Non, et ce n'est pas l'objectif. Portlane couvre l'intégration de données : recevoir, transformer, livrer. Pas de BPM*, pas de MDM*, pas de catalogue de connecteurs* certifiés pour chaque grand éditeur. Si votre usage réel, c'est la suite complète, gardez la suite.

Quand faut-il encore choisir un ESB* ?

Quand le besoin dépasse la synchronisation de données : orchestration de processus métier, référentiel de données maître, échanges multi-protocoles lourds, ou contrainte de marché public sur une suite déjà installée. Dans ces cas, changer pour « moderniser » sans changer le besoin est un mauvais calcul.

Glossaire

• ESB (Enterprise Service Bus) : bus de services d'entreprise, plateforme centrale qui fait dialoguer des applications hétérogènes.
• API : interface qui permet à deux logiciels d'échanger des données de façon standardisée.
• Connecteur : module fourni par un éditeur pour brancher une application précise, CRM ou ERP par exemple, sur sa plateforme. Le catalogue de connecteurs est la liste de ces modules, souvent payante et liée à la feuille de route de l'éditeur.
• BPM (Business Process Management) : orchestration de processus métier, validations, workflows, enchaînements de tâches.
• MDM (Master Data Management) : référentiel de données maître, une vision unique des clients, produits, etc.
• ETL : extraction, transformation et chargement de données, souvent par lots.
• ERP : progiciel de gestion intégré, le système central qui porte commandes, stocks, facturation et comptabilité.
• CRM : logiciel de gestion de la relation client, contacts, opportunités, ventes.
• SaaS (Software as a Service) : logiciel loué par abonnement et hébergé par son éditeur, par opposition à un logiciel installé chez vous.
• File d'attente : mécanisme qui stocke les messages en attendant leur traitement, pour qu'une panne ne les fasse pas disparaître.