Votre ERP tourne depuis trois ans. Les modules coeur fonctionnent. Et pourtant, vos équipes techniques soulèvent une question de fond : faut-il garder ce monolithe ou commencer à l’extraire en microservices ? Vos concurrents du secteur affichent des “architectures composables”. Un consultant vient de vous parler de MACH. Et le DSI d’un homologue en conférence a expliqué comment son équipe a découpé le catalogue produits en service indépendant, ce qui lui a permis de pousser de nouvelles fonctionnalités en quelques jours plutôt qu’en quelques mois.
Résultat : vous avez des signaux contradictoires. Les articles d’architecture vantent les microservices. Les retours d’expérience terrain relatent des projets qui ont coûté dix-huit mois de migration pour un gain finalement modeste. La réalité se situe entre les deux, et elle dépend de votre contexte.
Cet article n’est pas un cours d’architecture. C’est une aide à la décision : quand décomposer fait sens, quand le monolithe reste le choix rationnel, et comment naviguer entre les deux avec la stratégie “strangler fig”.
Monolithique, microservices, composable : ce que ces termes veulent vraiment dire en contexte ERP
Le monolithe moderne en 2026 : ce n’est pas votre ERP des années 2000
Le mot “monolithique” évoque souvent l’image d’un système rigide, difficile à modifier, déployé tous les six mois. Cette représentation est périmée pour les ERP majeurs actuels.
SAP S/4HANA Cloud, Microsoft Dynamics 365, Oracle Fusion Cloud sont des applications construites sur une architecture interne à microservices. Côté éditeur, les équipes SAP déploient des services indépendants (comptabilité, gestion des stocks, commandes) qui communiquent via des API et peuvent évoluer séparément. Ce que vous percevez comme un monolithe depuis votre interface utilisateur est en réalité un agrégat de services gérés par l’éditeur.
Ce que vous choisissez, en tant que DSI, ce n’est donc pas si votre ERP est un monolithe ou non côté éditeur. C’est si vous, vous découpez vos extensions, vos personnalisations et vos intégrations avec les outils périphériques en microservices indépendants, ou si vous les construisez comme une couche applicative unifiée au-dessus de l’ERP.
Microservices appliqués à l’ERP : découplage des domaines fonctionnels
Dans un contexte ERP, l’architecture microservices signifie en pratique extraire un ou plusieurs domaines fonctionnels (catalogue produits, pricing, gestion de commandes e-commerce, notifications clients) de l’ERP en services applicatifs autonomes, déployables indépendamment, communicant avec l’ERP via des API ou des événements asynchrones.
Chaque service possède sa propre base de données, sa propre logique de déploiement, et peut être mis à jour sans toucher aux autres. Une modification du service de pricing ne nécessite pas de tester et redéployer le module comptabilité.
L’avantage est réel sur les domaines à fort taux de changement. L’inconvénient est tout aussi réel : coordonner plusieurs services distribués introduit une complexité opérationnelle que l’on sous-estime systématiquement lors de la phase de conception.
Composable ERP (MACH) : promesses et réalité terrain 2026
L’acronyme MACH, promu par la MACH Alliance (fondée en 2020, désormais forte de plusieurs centaines de membres dont Commercetools, Contentful, Algolia, Akeneo), décrit une approche d’architecture basée sur quatre principes : Microservices, API-first, Cloud-native, Headless.
Dans le contexte ERP, un “composable ERP” désigne une architecture dans laquelle les couches fonctionnelles sont assembées à partir de briques commerciales spécialisées plutôt que d’un ERP généraliste unique : un PIM comme Akeneo pour le référentiel produits, un moteur de pricing comme Pricefx, un OMS dédié (Order Management System) pour la gestion des commandes e-commerce, connectés à un ERP de back-office pour la comptabilité et la logistique.
La promesse est séduisante : remplacer chaque brique indépendamment, accélérer les évolutions sur les domaines différenciants. La réalité terrain 2026 est plus nuancée. Un projet composable bien exécuté livre effectivement une agilité fonctionnelle remarquable sur le front e-commerce ou pricing. Un projet composable mal cadré multiplie les interfaces à maintenir, les problèmes de cohérence des données entre systèmes, et les coûts d’intégration que personne n’avait correctement budgétisé.
Quand décomposer son ERP en microservices est la bonne décision
Volume transactionnel et scalabilité asymétrique
Le cas d’usage le plus solide pour extraire un domaine en microservice est la scalabilité asymétrique : une partie de votre SI doit monter en charge de manière disproportionnée par rapport au reste.
L’exemple typique est le e-commerce B2B en contexte de pics de demande (appels d’offres saisonniers, soldes, campagnes marketing) : le module de consultation de catalogue et de passage de commande doit absorber dix fois le trafic habituel sans que cela n’impacte les performances de votre module comptabilité, votre ordonnancement de production ou votre gestion des stocks. Isoler ce service dans une architecture déployée sur des instances scalables automatiquement (Kubernetes, services managés cloud) permet de traiter ce pic sans dimensionner l’ensemble du SI pour le pire cas.
Cette justification tient dès lors que vos volumes le nécessitent vraiment. Pour une ETI avec 5 000 commandes par jour en pic, la question de la scalabilité automatique de l’ERP ne se pose généralement pas : les ERP cloud modernes absorbent ces charges sans architecture personnalisée.
Time-to-market sur des fonctions différenciantes
Deuxième cas solide : vous avez identifié un domaine fonctionnel qui constitue un avantage concurrentiel direct, sur lequel vous voulez itérer rapidement et indépendamment de vos cycles de mise à jour ERP.
Un algorithme de recommandation personnalisée pour votre catalogue B2B, un moteur de pricing dynamique intégrant les données de marché en temps réel, une logique de règles promotionnelles spécifique à votre secteur : ces fonctions bénéficient d’être développées et déployées en dehors des contraintes du cycle de release ERP.
La condition : le domaine doit être fonctionnellement stabilisé avant la décomposition. L’erreur classique est de découper en microservices un domaine dont les règles métier sont encore en cours de définition. Chaque modification des règles nécessite alors de faire évoluer l’interface entre services, ce qui génère un coût de refactoring croissant avec le nombre de services impliqués.
Les prérequis organisationnels non négociables
Avant tout projet de décomposition, évaluez honnêtement trois prérequis organisationnels :
1. Des équipes produit autonomes par domaine. La règle des deux pizzas (popularisée par Amazon) stipule qu’un service microservice doit être gérable par une équipe de 6 à 10 personnes maximum. En pratique, une ETI de 800 salariés dispose rarement de 3 ou 4 équipes DevOps distinctes capables chacune de posséder un service end-to-end. Avant de créer cinq services, assurez-vous d’avoir les équipes pour les maintenir durablement.
2. Une maturité DevOps réelle. Les microservices exigent une infrastructure CI/CD automatisée, des pipelines de tests indépendants par service, une observabilité distribuée (tracing, logging agrégé), une gestion des secrets et des certificats par service. Un environnement où les déploiements sont encore manuels ou semi-manuels n’est pas prêt pour une architecture microservices, quel que soit l’intérêt fonctionnel de la décomposition.
3. Une gouvernance des contrats d’API. Dans une architecture distribuée, l’interface entre services devient un contrat critique. Toute modification non rétrocompatible d’une API interne peut casser les services consommateurs. La gestion de ces contrats (versioning, documentation, tests de contrat) nécessite une discipline d’ingénierie que toutes les organisations n’ont pas encore internalisée.
Quand garder un ERP monolithique est la décision rationnelle
ETI de moins de 1 500 salariés : le coût de coordination dépasse les bénéfices
Pour une ETI de 200 à 1 500 salariés, le bilan coût-bénéfice d’une architecture microservices penche souvent du côté des coûts. Les équipes IT sont réduites (5 à 15 personnes pour un périmètre applicatif complet), les domaines fonctionnels n’ont pas les volumes qui justifient la scalabilité indépendante, et les cycles de changement métier ne sont pas suffisamment rapides pour que le time-to-market différentiel d’un service indépendant change réellement les résultats.
Dans ce contexte, la complexité opérationnelle d’une architecture microservices (gestion des services mesh, circuit breakers, transactions distribuées via le pattern saga) représente une dette technique qui dépasse largement la valeur apportée.
L’ERP monolithique structuré, correctement paramétré, avec une intégration propre vers les solutions périphériques via des connecteurs ou une plateforme iPaaS légère, couvre les besoins de la grande majorité des ETI dans cette tranche de taille.
Contraintes d’intégration legacy : l’overhead asynchrone insupportable
Le deuxième cas où le monolithe reste le choix rationnel concerne les SI avec un legacy fort : mainframe, applications métier propriétaires, bases de données relationnelles fortement couplées.
Une architecture microservices repose sur une communication asynchrone via des événements (message broker) ou des appels API synchrones avec gestion des erreurs distribuée. Dans un SI qui échange des données avec des systèmes legacy via des flux batch quotidiens ou des connexions directes en base de données, la migration vers une architecture événementielle représente un chantier d’infrastructure considérable qui n’a souvent pas de rapport avec la valeur métier recherchée.
Le monolithe structuré : ce que les éditeurs n’appellent pas microservices mais qui s’en approche
Les ERP modernes comme SAP S/4HANA, Dynamics 365 ou Odoo (dans une moindre mesure) offrent une modularité interne significative : APIs REST documentées, possibilité de désactiver des modules non utilisés, mécanismes d’extensions (ABAP pour SAP, Power Platform pour D365, modules Python pour Odoo) qui permettent des personnalisations sans toucher au coeur du système.
Cette approche, que les architectes appellent parfois “modular monolith”, permet de bénéficier de la cohérence transactionnelle d’un système intégré tout en préservant une certaine agilité sur les extensions. Pour la majorité des ETI, elle représente le juste milieu entre l’ERP monolithique figé des années 2000 et la complexité opérationnelle d’une architecture microservices complète.
L’approche intermédiaire : la stratégie “strangler fig” sur l’ERP existant
Extraire 1 à 2 domaines à fort enjeu
La stratégie “strangler fig” (figuier étrangleur), popularisée par Martin Fowler, consiste à extraire progressivement des fonctionnalités d’un système existant sans le remplacer en une seule fois. Appliquée à un ERP, elle signifie identifier 1 ou 2 domaines à fort enjeu business (e-commerce B2B, catalogue produits, pricing dynamique, logistique temps réel) et les extraire en services indépendants, tout en conservant l’ERP comme coeur transactionnel pour la comptabilité, la paie, les achats.
Un exemple de référence dans le secteur manufacturier : une ETI de 1 800 salariés qui a extrait son catalogue produits et son moteur de configuration variant de Dynamics 365 vers un service dédié. Résultat : le time-to-market pour les nouvelles configurations de produit est passé de plusieurs semaines à quelques jours. L’ERP D365 reste le système de référence pour les commandes confirmées, la valorisation des stocks et la comptabilité. Les deux systèmes communiquent via un message broker Azure Service Bus.
Cette approche présente un avantage décisif : vous n’avez pas besoin de migrer l’intégralité de votre SI pour bénéficier de l’agilité microservices sur le périmètre qui en a réellement besoin.
Patterns d’intégration : façade API et événements asynchrones
Deux patterns d’intégration structurent la communication entre l’ERP et les services extraits :
La façade API sur l’ERP legacy : au lieu d’exposer directement les API natives de l’ERP (souvent complexes, spécifiques à l’éditeur), vous construisez une couche d’abstraction qui traduit les appels métier en appels ERP. Cette façade permet de changer l’implémentation ERP sous-jacente sans impacter les services consommateurs, et de maintenir un contrat API stable même lors des mises à jour majeures de l’ERP.
Les événements asynchrones via message broker : plutôt que des appels API synchrones entre l’ERP et les services (qui créent des couplages temporels et des problèmes de disponibilité), vous publiez des événements métier (commande créée, stock mis à jour, client modifié) dans un bus de messages, que les services abonnés consomment à leur rythme. Ce modèle est plus résilient et plus scalable, au prix d’une complexité accrue sur la gestion des cas d’erreur et de la cohérence éventuelle des données.
Outillage courant en 2026 : coûts et prérequis humains
Les technologies les plus utilisées pour ces patterns d’intégration en contexte ERP en 2026 :
- Apache Kafka : référence pour les architectures événementielles à fort volume. Coût d’exploitation significatif (infrastructure dédiée ou service managé type Confluent Cloud à partir de quelques centaines d’euros par mois pour un usage modéré). Prérequis : une équipe capable d’opérer Kafka en production, ce qui n’est pas trivial.
- Azure Service Bus / Azure Event Hub : option managée pour les environnements Microsoft (D365, Azure). Intégration native avec Logic Apps et Power Platform. Tarification à l’usage, accessible pour les ETI.
- SAP Integration Suite (anciennement SAP Cloud Platform Integration) : la solution de référence pour les environnements SAP, avec des connecteurs préconstruits pour les principaux SaaS et la gestion des transformations de données.
- MuleSoft Anypoint Platform : iPaaS enterprise pour les architectures complexes multi-éditeurs. Tarification significative (à partir de plusieurs milliers d’euros par mois), justifiée pour des périmètres d’intégration larges. Pour une analyse comparative complète des iPaaS, consultez notre comparatif MuleSoft, Boomi, Make et connecteurs natifs ERP.
Tableau comparatif : monolithique vs microservices vs composable selon 6 critères
| Critère | Monolithique | Microservices | Composable (MACH) |
|---|---|---|---|
| TCO 5 ans | Faible à modéré (licence ERP + maintenance courante) | Élevé (infrastructure distribuée, observabilité, équipes dédiées) | Élevé (licences multiples éditeurs + coûts d’intégration) |
| Time-to-value nouvelle fonctionnalité | Lent sur les fonctions différenciantes (cycle release ERP) | Rapide sur les services découpés, lent pour la mise en place initiale | Rapide une fois l’architecture stable, long à atteindre |
| Complexité opérationnelle | Faible (un système à opérer) | Élevée (monitoring distribué, gestion des pannes partielles, sagas) | Très élevée (gouvernance multi-éditeurs, cohérence des données) |
| Dépendance éditeur | Forte (roadmap ERP pilote les évolutions) | Faible (services indépendants remplaçables) | Faible par conception, mais forte en pratique par service |
| Scalabilité sélective | Nulle (l’ensemble scale de façon homogène) | Haute (chaque service scale indépendamment) | Haute par service |
| Taille d’équipe requise | Petite (2 à 5 personnes IT suffisent) | Grande (1 à 2 équipes par service en production) | Grande (équipe intégration + équipes par brique) |
La grille de décision : 8 questions pour choisir votre architecture ERP
Répondez à ces 8 questions. Comptez vos réponses A (monolithique), B (microservices) ou C (composable MACH) selon les indications.
1. Quelle est la taille de votre équipe IT interne dédiée à l’ERP et aux applications métier ?
- Moins de 5 personnes à temps plein → A
- 5 à 15 personnes → peut aller vers B sur 1 domaine
- Plus de 15 personnes avec équipes produit → B ou C envisageable
2. Votre organisation a-t-elle déjà des pipelines CI/CD automatisés et une pratique DevOps établie ?
- Non, les déploiements sont encore partiellement manuels → A
- Oui, pour l’essentiel des applications → B possible
- Oui, avec observabilité distribuée déjà en place → B ou C
3. Existe-t-il un domaine fonctionnel précis où le time-to-market actuel bloque directement votre chiffre d’affaires ?
- Non → A (pas de justification ROI pour la décomposition)
- Oui, sur 1 à 2 domaines identifiés → B ciblé (strangler fig)
- Oui, sur l’ensemble du SI commercial → C à évaluer
4. Vos volumes transactionnels créent-ils des pics de charge asymétriques entre modules ?
- Non, les charges sont homogènes → A
- Oui, sur un périmètre limité (e-commerce, pricing) → B ciblé
- Oui, sur plusieurs domaines indépendants → B ou C
5. Le domaine fonctionnel que vous envisagez de décomposer est-il fonctionnellement stabilisé ?
- Non, les règles métier évoluent encore → Attendez (quel que soit le modèle)
- Oui, les règles sont stables depuis au moins 12 mois → B ou C possible
6. Quel est votre horizon de rentabilité acceptable pour un projet d’architecture ?
- Moins de 12 mois → A (les projets microservices ont rarement un ROI avant 18-24 mois)
- 18 à 36 mois → B ciblé envisageable
- Plus de 36 mois acceptables → B ou C selon les réponses précédentes
7. Votre SI comprend-il des systèmes legacy avec des interfaces batch ou des connexions directes en base de données ?
- Oui, nombreuses → A ou migration legacy préalable avant toute décomposition
- Non, principalement des API REST documentées → B ou C possible
8. Votre domaine fonctionnel nécessite-t-il de travailler avec plusieurs éditeurs spécialisés (PIM, OMS, pricing) plutôt qu’une extension de votre ERP actuel ?
- Non, l’ERP actuel couvre le besoin avec des extensions → A
- Oui, sur un périmètre limité (e-commerce uniquement) → B ciblé
- Oui, sur plusieurs domaines différenciants → C à évaluer sérieusement
Interprétation :
- Majorité A : conservez et optimisez votre architecture monolithique. Investissez dans les intégrations propres et la modularité interne de votre ERP.
- Majorité B, 1-2 domaines ciblés : adoptez la stratégie strangler fig. Commencez par un seul service sur le domaine le plus justifié.
- Majorité C ou B sur de nombreux domaines : évaluez une approche composable, mais avec un cadrage rigoureux des coûts d’intégration et une équipe architecture dédiée.
Pour aller plus loin sur les sujets liés, consultez notre guide ERP composable : architecture, coûts et conditions de réussite 2026 et notre analyse ERP vs Best-of-Breed : les 8 processus où les modules natifs montrent leurs limites.
