Garder sa suite ESB / BPM / MDM : l'arbre de décision honnête

Chez nous, l'article le plus cité en interne est pourquoi l'ESB¹ est trop vieux comme défaut. Ce texte est le complément nécessaire : quand ne pas le remplacer. Parce qu'une DSI⁷ qui ne lit que la moitié du message prend de mauvaises décisions dans l'autre sens : migration forcée là où la suite tient encore, ou conservation par inertie là où seule la sync compte.

Blueway, Talend ESB¹, IBM, Software AG : des suites françaises et européennes tournent encore, portent des flux critiques, et restent parfois le meilleur outil pour le besoin réel. Portlane ne prétend pas les remplacer toutes. Il vise une tranche : synchronisation de données entre systèmes qui exposent déjà des API⁴.

Arbre de décision : la première fourche

Posez une seule question : votre besoin principal, c'est quoi ?

• A. Synchronisation de données entre applications (CRM⁵, ERP⁶, outils métier) : recevoir, transformer, livrer, relancer.
• B. Orchestration de processus métier (BPM²) : validations, workflows, tâches humaines, enchaînements complexes.
• C. Référentiel de données maître (MDM³) : une vision unique clients, produits, tiers, avec gouvernance dédiée.
• D. Médiation technique lourde : protocoles hérités, formats industriels, connecteurs¹² certifiés que vous ne voulez pas réécrire.

Si B, C ou D est dominant : gardez la suite (ou un équivalent de sa catégorie). Portlane n'est pas la réponse à ces lettres. Si A couvre l'essentiel de votre volume opérationnel : la suite est probablement surdimensionnée pour ce périmètre, sans pour autant devoir disparaître d'un coup si B/C/D existent ailleurs dans le même contrat.

Quand garder la suite complète

• Vous exploitez réellement le BPM² : circuits de validation, interventions métier, SLA⁹ sur des processus.
• Le MDM³ est votre source de vérité pour clients ou produits, pas un module activé « au cas où ».
• Des protocoles ou formats hérités passent encore par le bus et ne sont pas prêts pour des API⁴ modernes.
• Un marché public ou un contrat cadre verrouille l'éditeur et la certification.
• Le coût de sortie dépasse clairement cinq à sept ans de maintien au statu quo.
• L'équipe (interne + ESN¹⁷) maîtrise la suite avec un bus factor¹⁰ acceptable (≥ 2 sur le critique).
• Un rachat éditeur (ex. Blueway) est digéré et le support tient encore vos flux.

Dans ces cas, « moderniser » en remplaçant tout par un iPaaS¹¹ cloud ou par du code est un programme à part entière, pas une évidence. La modernisation par tranches (nouveaux flux ailleurs, anciens sur la suite) est souvent plus sage.

Quand la suite est surdimensionnée (mais encore là)

C'est la situation la plus fréquente en ETI⁸ : vous payez ESB¹ + BPM² + MDM³, vous n'utilisez que la sync. Personne ne l'a décidé. C'est arrivé par reconduction, par extension de périmètre, par défaut d'alternative à l'époque.

• Trente flux en prod, zéro workflow BPM² actif hors sync.
• Le module MDM³ est vide ou alimenté à la main dans Excel.
• Les intégrateurs disent « on fait du Talend / Blueway » mais écrivent surtout du mapping CRUD¹³.
• La direction demande pourquoi la licence coûte autant sans comprendre le découpage modules.

Ici, garder toute la suite pour ce seul usage est rationnel seulement si le coût de sortie l'impose. Sinon, l'enjeu est de séparer les périmètres : la suite pour ce qui reste B/C/D, autre chose pour la tranche A.

Stratégie « tranche sync » : coexistence

Vous n'êtes pas obligé de tout remplacer un vendredi. Modèle courant :

• Geler les nouveaux flux sync sur la suite. Plus d'extension du périmètre legacy.
• Nouveaux flux sync sur une plateforme dédiée (code, iPaaS¹¹, ou Portlane quand prêt).
• Laisser BPM²/MDM³/médiation lourde sur la suite tant qu'ils servent.
• Inventorier chaque flux : date de sortie cible, criticité, propriétaire.
• Ne pas faire tourner deux chemins pour le même flux sans fenêtre de bascule documentée.

C'est moins spectaculaire qu'une big bang migration. C'est ce qui tient en production chez les ETI⁸ qui n'ont pas dix mois-homme à flammer.

Suite legacy vs iPaaS : ne pas sauter du même pied

Remplacer Blueway par Workato ou Boomi ne résout pas le surdimensionnement si le besoin réel reste de la sync. Vous changez de lock-in, pas de périmètre. Voir qu'est-ce qu'un iPaaS et coût de sortie.

La bonne question n'est pas « cloud ou on-premise¹⁵ ». C'est « avons-nous besoin d'une suite, d'un iPaaS¹¹, ou d'une couche sync possédée », selon la lettre A/B/C/D.

Garder vs extraire la sync, côte à côte

• Besoin BPM² / MDM³ réel. Garder : oui, la suite reste légitime. Extraire sync : seulement si coexistence maîtrisée.
• Volume opérationnel = sync pure. Garder : coûteux, vous payez des modules dormants. Extraire sync : aligne coût et usage.
• Bus factor¹⁰ sur la suite. Garder : acceptable si ≥ 2 experts. Extraire sync : opportunité de passer en code recrutable.
• Horizon 5 ans. Garder : si contrat et éditeur stables. Extraire sync : si vous voulez reprendre la main sur le cœur métier.
• Portlane pertinent. Garder : pour B/C/D, Portlane ne remplace pas. Extraire sync : tranche A uniquement. Produit encore en dev.

Cas Blueway : être juste

Blueway est l'exemple français le plus cité : ESB¹, BPM², MDM³, installé chez des ETI⁸ et collectivités. Le rachat par SoftProject a rappelé que la trajectoire éditeur compte. Garder Blueway peut être rationnel si :

• Vos processus BPM² tournent et sont documentés.
• Le support répond encore sur vos versions.
• Le coût de migration n'est pas financé.
• Vous segmentez : pas de nouveaux flux sync critiques sur la suite sans revue.

Remplacer Blueway « parce que c'est vieux » sans changer le besoin B/C/D reproduit le même schéma avec un autre logo.

Où Portlane se limite volontairement

Portlane = recevoir, transformer, livrer en Python, licence à vie¹⁶, chez vous. Pas de bus central. Pas de BPM². Pas de MDM³. Pas de catalogue de connecteurs¹² à certifier.

Si votre décision tombe sur B, C ou D : Portlane n'est pas la réponse, et nous préférons le dire avant un appel commercial. Si elle tombe sur A pour une partie du SI : c'est la tranche visée. Pourquoi nous construisons Portlane. Produit encore en développement actif. Stratégie, pas bascule immédiate.

Plan d'action en cinq étapes

• Inventoriez tous les flux prod (demi-journée).
• Classez chaque flux en A, B, C ou D.
• Calculez la part du budget suite qui sert A seul.
• Décidez : tout garder, coexistence, ou sortie par tranches, avec date de révision.
• Documentez la décision pour le comité de direction (risque, coût, bus factor¹⁰).

Garder sa suite n'est pas un aveu d'échec. La garder pour un usage qu'elle ne sert plus, si. L'arbre de décision ci-dessus vise à éviter les deux extrêmes.

Questions fréquentes

Une suite ESB / BPM / MDM est-elle « dépassée » par défaut ?

Non. Ce qui est dépassé, c'est d'en faire le choix par défaut pour de la simple synchronisation de données. Quand vous utilisez réellement l'orchestration de processus, le référentiel maître ou la médiation multi-protocoles, la suite peut encore être le bon outil.

Peut-on garder Blueway et ajouter Portlane ?

Oui, en théorie : Portlane vise la tranche synchronisation de données entre systèmes à API⁴, pas le remplacement d'un BPM² ou d'un MDM³. En pratique, il faut tracer une frontière claire des flux, et Portlane est encore en développement actif.

Comment savoir si on paie une suite pour un besoin sync seulement ?

Inventoriez vos flux en production. Si l'essentiel est « recevoir une donnée, transformer, livrer » sans workflow humain complexe ni référentiel maître central, vous financez probablement un périmètre plus large que votre usage réel.

Le secteur public doit-il garder sa suite ?

Souvent, les contraintes de marché, de certification et de continuité pèsent plus que la modernité. Garder peut être rationnel, à condition de ne pas étendre le périmètre sans recalculer le TCO¹⁴.

Portlane remplace-t-il Blueway ?

Non si vous utilisez BPM², MDM³ ou une médiation de services profonde. Oui sur la tranche sync de données si c'est votre besoin réel et que vous acceptez un produit encore en construction. Pas de remplacement idéologique.

Glossaire

• ¹ ESB : bus de services d'entreprise, médiation centralisée.
• ² BPM : orchestration de processus métier, workflows et validations.
• ³ MDM : référentiel de données maître.
• ⁴ API : interface standardisée entre logiciels.
• ⁵ CRM : gestion de la relation client.
• ⁶ ERP : progiciel de gestion intégré.
• ⁷ DSI : direction des systèmes d'information.
• ⁸ ETI : entreprise de taille intermédiaire.
• ⁹ SLA : engagement de niveau de service.
• ¹⁰ Bus factor : risque lié au nombre de personnes maîtrisant un système.
• ¹¹ iPaaS : plateforme d'intégration en abonnement.
• ¹² Connecteur : module pour brancher une application sur une plateforme.
• ¹³ CRUD : créer, lire, mettre à jour, supprimer. Opérations de base sur des données.
• ¹⁴ TCO : coût total de possession sur la durée de vie.
• ¹⁵ On-premise : exécution sur votre infrastructure.
• ¹⁶ Licence à vie : achat du droit d'utilisation sans abonnement obligatoire pour le déployé.
• ¹⁷ ESN : entreprise de services du numérique.