Middleware
Le middleware désigne la couche logicielle qui s'intercale entre les applications, leur permettant de communiquer, d'échanger des données et de coordonner leurs traitements. Dans le contexte ERP, le middleware relie le socle ERP au CRM, à l'e-commerce, aux marketplaces, à la BI, à l'IoT, aux portails fournisseurs, aux systèmes partenaires et aux applications legacy. La catégorie middleware englobe l'Enterprise Service Bus (ESB) classique, l'iPaaS moderne, les brokers de messages, les API gateways et les plateformes de streaming d'événements.
Catégories de middleware
- ESB (Enterprise Service Bus) — schéma classique des années 2000, avec un bus central qui route les messages entre systèmes. IBM Integration Bus, Oracle Service Bus, TIBCO BusinessWorks, MuleSoft (à l'origine un ESB, désormais iPaaS)
- iPaaS (Integration Platform as a Service) — le successeur moderne, cloud-native : Mulesoft, Boomi, Microsoft Azure Logic Apps et Power Automate, SAP Integration Suite, Workato, Celigo, Informatica IICS
- Brokers de messages — messagerie asynchrone : Apache Kafka, RabbitMQ, Amazon SQS, Azure Service Bus, IBM MQ
- API gateways — gestion des API exposées : Apigee (Google), Kong, AWS API Gateway, Azure API Management, Tyk, MuleSoft Anypoint API Manager
- Plateformes de streaming d'événements — Apache Kafka, Apache Pulsar, AWS Kinesis, Azure Event Hubs, Google Pub/Sub — pour les flux de données en temps réel
- ETL/ELT (voir ETL) — pour le déplacement de données à des fins analytiques, souvent complémentaire du middleware opérationnel
Schémas d'architecture
Trois schémas dominent les architectures de middleware centrées sur l'ERP. (1) Hub-and-spoke : toutes les intégrations transitent par une plateforme de middleware centrale. Gouvernance plus simple, point de défaillance unique, peut devenir un goulot d'étranglement. C'est le standard des intégrations de l'ère ESB. (2) Mesh / point-à-point : les applications s'intègrent directement ou via un middleware léger. Plus résilient, mais plus difficile à gouverner à grande échelle. Courant dans les environnements cloud-native. (3) Event-driven (piloté par les événements) : les applications publient des événements dans un flux central (de type Kafka) ; les consommateurs s'abonnent aux événements qui les concernent. Cette approche passe bien à l'échelle et favorise un couplage faible. Elle se généralise dans les architectures composables modernes. Les PME et ETI françaises combinent généralement plusieurs schémas — iPaaS pour les intégrations opérationnelles, streaming d'événements pour les flux de données en temps réel, ETL pour les données analytiques, le tout coordonné par une forme ou une autre de gouvernance d'intégration.
Cas d'usage courants du middleware ERP
E-commerce vers ERP : les commandes remontent de la boutique vers l'ERP, le stock et les prix redescendent vers la boutique. Généralement un iPaaS léger (Microsoft Power Automate, Boomi, Celigo). CRM vers ERP : synchronisation des données maîtres clients, passage de l'opportunité à la commande. Souvent via des connecteurs natifs d'éditeurs (Salesforce-SAP, HubSpot-NetSuite). Orchestration des marketplaces : Amazon, eBay, Cdiscount unifiés au sein d'un même ERP. iPaaS spécialisés (Plytix, Productsup) ou plateformes de gestion de marketplaces (channable, sellforte). EDI pour le B2B : EDIFACT legacy plus flux modernes basés sur les API à destination des clients de la distribution et de l'automobile. Les prestataires d'EDI managé (SEEBURGER, ecosio, Crossinx) jouent le rôle de plateformes d'intégration spécialisées dans la connectivité avec les partenaires commerciaux. À noter pour la France, la dématérialisation des factures s'appuie sur le format Factur-X et la plateforme Chorus Pro pour les échanges avec le secteur public. BI et analytique : l'ETL/ELT déplace les données de l'ERP vers les entrepôts de données pour l'analyse.
Conseils pratiques
Trois recommandations pratiques pour un middleware centré sur l'ERP. (1) Adapter le niveau de l'outil à la complexité de l'intégration. Les cas d'usage simples (5 à 20 flux) conviennent aux plateformes légères (Zapier, Make, Power Automate Standard). Les environnements complexes (plus de 50 flux, exigences temps réel, EDI) requièrent un iPaaS d'entreprise (Mulesoft, Boomi, SAP Integration Suite). (2) Investir dans la gouvernance d'intégration. Sans responsable, sans documentation ni cycles de revue, le parc d'intégrations devient fragile et incontrôlable. Désignez un référent intégration, tenez un registre des flux et imposez des règles de gestion du changement. (3) Éviter l'accès direct à la base de données en production. Le middleware doit consommer des API ou des événements, et non lire ou écrire directement dans les bases de données de l'ERP. Les accès au niveau base de données cassent à chaque montée de version de l'ERP et créent des angles morts de gouvernance.