— 18 mai 2026 · 7 min de lecture
Vendor lock-in EDI : 5 tests pour évaluer ton ESB
Le coût réel d'un ESB ou hub EDI propriétaire ne se mesure pas au coût de souscription, mais au coût d'en sortir. Cinq tests concrets pour estimer ce coût avant signature, ou pour décider si une migration vaut la peine.
Test 1 : portabilité des données opérationnelles
La question : peut-on exporter l'historique complet des messages échangés (audit log, payloads bruts, ACKs, événements de statut) dans un format ouvert (NDJSON, CSV, Parquet) sans intervention vendor ?
L'évaluation : demander une démo d'export de 100 000 messages avec les colonnes attendues (ID, sender, receiver, timestamp réception, timestamp envoi, statut, type message, taille payload). Le délai de production de cet export et la qualité du format sont révélateurs. Drapeau rouge : besoin d'un connecteur propriétaire ou d'une API payante avec rate limit. Bon : export direct via interface admin en quelques minutes, format ouvert documenté.
Test 2 : export des mappings de transformation
La question : peut-on extraire les règles de mapping (EDIFACT ↔ JSON pivot, UBL ↔ ERP) dans un format lisible et réutilisable sur un autre moteur ?
L'évaluation : demander l'export d'un mapping ORDERS EDIFACT D.96A → JSON canonique. Examiner le format. Drapeau rouge : format binaire propriétaire (Boomi .mxp, MuleSoft .jar, IBM .map de WebSphere Transformation Extender), ou XML proprio dépendant d'un runtime spécifique (IBM Sterling B2B Integrator .map). Bon : XSLT standard, ou code TypeScript/Python lisible, ou format YAML/JSON documenté, ou DataWeave partiellement portable. Stedi mise sur des mappings JavaScript, ce qui est intéressant pour la portabilité mais reste lié à leur runtime.
Test 3 : portabilité des credentials partenaires
La question : peut-on exporter le profile complet de chaque partenaire (certificats X.509, AS2 IDs, endpoints AS4, SLA convenu, contacts techniques) sous un format machine-readable ?
L'évaluation : demander l'export en JSON ou YAML de 100 partner profiles. Drapeau rouge : export PDF ou Excel nécessitant re-saisie manuelle sur cible (vu plusieurs fois !). Bon : export structuré couvrant tous les champs y compris les certificats (PEM ou DER), avec documentation des secrets management.
Test 4 : schéma de monitoring et alerting
La question : les métriques de monitoring (latence, success rate, throughput, error rate par partenaire) sont-elles exposées via un format ouvert (OpenTelemetry, Prometheus, OpenMetrics) ? Les alertes sont- elles définies en code (Terraform, Pulumi) ou seulement via UI propriétaire ?
L'évaluation : demander un endpoint Prometheus
/metrics ou un exporter OpenTelemetry OTLP. Drapeau rouge :
métriques visibles uniquement dans une UI propriétaire avec billing à part pour
l'export. Bon : OpenTelemetry natif sortant vers n'importe quel
backend (Grafana, Datadog, New Relic). Cf notre page
métriques
EDI : SLO, error budgets, KPIs.
Test 5 : clauses contractuelles d'exit
La question : que dit le contrat sur la fin de relation — coût d'export, délai garanti d'accès aux données après résiliation, format des livrables d'exit, propriété des mappings écrits pendant le contrat ?
L'évaluation : demander l'exit clause au juridique avant signature. Drapeau rouge : « les données restent accessibles 30 jours après résiliation pour 50 000 EUR » ou « les mappings sont la propriété du vendor » (vu chez certains ESB enterprise classiques). Bon : accès gratuit 90 jours, format ouvert garanti, mappings propriété du client. Certains vendors (Stedi, B2Brouter, Storecove) annoncent explicitement "no lock-in" et tiennent ; d'autres préfèrent ne pas en parler.
Que faire concrètement ?
Pour un projet greenfield 2026, privilégier des solutions code-first ou explicitement portables : Stedi (JavaScript-first), code maison sur Apache Camel ou NiFi, Kafka Connect + ksqlDB. Pour une migration depuis un legacy lock-in, planifier l'exit en deux phases : (1) extraire et re-documenter l'existant en format pivot (souvent un effort de 6-12 mois pour un grand groupe), (2) migrer flux par flux vers le nouveau runtime.
L'erreur la plus commune : vouloir « tout migrer d'un coup » sans avoir fait la phase 1. Le projet déraille à 40 % d'avancement quand on découvre des mappings non documentés, des règles dans des scripts personnalisés, des cas spéciaux dans la config opérationnelle. La phase 1 est moins glorieuse mais elle conditionne tout le reste.
Conclusion : la portabilité comme critère premier
Pour un ESB ou hub EDI, le critère « portabilité » devrait peser au moins autant que « fonctionnalités » et « pricing » dans une grille d'arbitrage. Une fois signée, une plateforme EDI fait souvent 10-15 ans dans la maison. La capacité d'en sortir dans 7 ans à coût raisonnable est un actif aussi important que la capacité de la déployer aujourd'hui à coût raisonnable.