Depuis 2020, Gartner pousse le modèle du « Composable ERP », suite logique de son concept de Postmodern ERP introduit dès 2013. Depuis 2022, tous les éditeurs reprennent le vocabulaire : API-first, best-of-breed, clean core, découplage. Depuis 2024, quelques DSI s’y cassent les dents et reviennent en arrière, souvent sans le dire. 2026 est l’année du bilan honnête.
L’ERP composable est-il la fin du monolithe ou une promesse sur-vendue par les analystes et les éditeurs d’iPaaS ? La réponse est nuancée. Pour une grande ETI industrielle multi-BU, oui, c’est probablement la cible raisonnable à 5 ans. Pour une PME de 200 personnes sur une seule activité, c’est souvent un piège de gouvernance qui coûte plus cher qu’il ne rapporte. Cet article distingue ce qui marche, ce qui casse, et à quelles conditions.
Qu’est-ce qu’un ERP composable
Une idée ancienne qui s’accélère
Le concept ne date pas d’hier. En 2012, Gartner publie sa Pace-Layered Application Strategy, qui propose de classer les applications en trois couches selon leur rythme de changement (Gartner Glossary) :
- Systems of Record (cycle long) : la finance, la paie, le grand livre, les référentiels. Stables, réglementés, peu différenciants.
- Systems of Differentiation (cycle moyen, 1 à 3 ans) : les processus qui distinguent l’entreprise sur son marché. Gestion commerciale spécifique, supply chain, planification.
- Systems of Innovation (cycle court, 0 à 12 mois) : les expérimentations, les applications métier de dernière minute, les POC.
En 2013, Gartner formalise le « Postmodern ERP » : l’ERP monolithique éclate en un noyau financier plus des applications satellites best-of-breed. En 2020, l’appellation devient « Composable ERP », dans le sillage du Composable Business. En 2022, la tendance entre dans le Hype Cycle for ERP de Gartner (Gartner Hype Cycle for ERP 2024).
Les quatre principes MACH appliqués à l’ERP
Le composable emprunte ses fondamentaux à MACH, l’architecture popularisée par le e-commerce headless et formalisée par la MACH Alliance (MACH Alliance) :
- Microservices : chaque fonction métier (facturation, stocks, paie) est un service indépendant, déployable et scalable séparément.
- API-first : toute interaction entre composants passe par des contrats d’API documentés, REST ou GraphQL. Pas d’accès direct à la base.
- Cloud-native : les briques sont conçues pour le cloud dès l’origine, pas portées d’un existant on-premise. Scalabilité élastique, pipelines CI/CD, mises à jour continues.
- Headless : le back-end est découplé de l’interface utilisateur. Le même service alimente un portail web, une app mobile, un chatbot ou un agent IA.
Appliqués à l’ERP, ces principes produisent une architecture où le grand livre n’a plus besoin de connaître le module achats, où la gestion commerciale peut être remplacée sans toucher à la comptabilité, où un agent IA peut appeler directement l’API de facturation.
La différence avec le best-of-breed des années 2000
Assembler plusieurs logiciels métier n’est pas nouveau. Dans les années 2000, on parlait déjà de « best-of-breed » : un ERP pour la finance, un CRM dédié, un WMS spécifique, interconnectés par des batch EDI ou des ETL nocturnes. Ce n’est pas la même chose qu’un ERP composable.
Trois différences clés :
- Les APIs sont temps réel, plus les flux batch de 2 heures du matin. Une commande passée dans le CRM arrive dans l’ERP en quelques secondes, pas le lendemain.
- Les briques sont cloud-native, plus des logiciels on-premise avec des adaptateurs. Cela change la fréquence de mise à jour et la résilience.
- L’intégration est industrialisée via un iPaaS (MuleSoft, Boomi, Workato, Celigo), plus des connecteurs ad hoc codés à la main qui pourrissent sans maintenance.
Un composable de 2026 ressemble à une architecture orientée événements (event-driven) avec un bus d’intégration managé, pas à une gare de triage de fichiers plats.
Schéma d’architecture typique
Au centre, un hub d’intégration (iPaaS + API management). Autour, six à dix briques métier indépendantes : un core finance cloud (NetSuite, Sage Intacct, Workday Financials), un HRIS (Workday, SAP SuccessFactors, Factorial), un CRM (Salesforce, HubSpot, Dynamics Sales), une plateforme achats (Coupa, Ivalua, SAP Ariba), un WMS ou un TMS métier, et un CDP ou un PIM pour les référentiels produit et client. Chaque brique a son éditeur, son contrat, sa roadmap, son cycle de release. Le hub orchestre les flux, applique les règles de conformité, centralise l’observabilité.
Pourquoi les monolithes sont remis en question
Un rythme d’innovation asymétrique
Un ERP monolithique on-premise a historiquement un cycle de release long : 18 à 36 mois pour une version majeure. Les SaaS spécialisés livrent des fonctionnalités toutes les deux à quatre semaines. Cet écart devient insoutenable quand les métiers comparent Odoo ou Salesforce à leur ERP central. Côté SAP, la transition vers S/4HANA Cloud Public Edition rapproche les rythmes (mises à jour trimestrielles), mais l’édition Private Cloud et le reste de l’existant ECC restent sur des cycles plus lents.
La contrainte de la fin de support SAP ECC
La pression calendaire est réelle. SAP a confirmé que la maintenance standard de SAP ECC 6.0 et SAP Business Suite 7 prendra fin le 31 décembre 2027, avec une maintenance étendue optionnelle et payante jusqu’au 31 décembre 2030 (SAP Maintenance Strategy). Des milliers d’ETI européennes doivent choisir entre une migration S/4HANA (brownfield ou greenfield) ou une recomposition complète de leur SI. Le moment est propice pour reposer la question d’architecture.
L’impossibilité de moderniser par brique
Dans un monolithe, moderniser la RH implique souvent de toucher la finance, parce que les deux partagent le même référentiel employé, les mêmes tables de coûts, les mêmes écritures automatisées. Dans un composable, on remplace un HRIS vieillissant sans toucher au grand livre. La modernisation devient incrémentale : RH en 2026, achats en 2027, supply en 2028. C’est le vrai argument business, pas le jargon technique.
Le verrouillage éditeur
Un monolithe concentre les dépendances. Changer d’éditeur demande un projet pluriannuel à plusieurs dizaines de millions d’euros pour une grande entreprise. Un composable disperse le risque : chaque brique est remplaçable individuellement sur 12 à 18 mois. Le levier de négociation lors des renouvellements est substantiellement différent.
L’exigence des métiers
Les directions métier veulent le meilleur outil pour leur domaine. Les DRH veulent Workday ou SAP SuccessFactors, pas le module RH historique. Les directions achats veulent Coupa. Les directions commerciales veulent Salesforce. L’ERP central devient un goulot, et les métiers contournent la DSI en souscrivant directement du SaaS. Le shadow IT finit par coûter plus cher qu’une architecture composable assumée.
Les trois modèles d’ERP composable en 2026
Toutes les architectures composables ne se ressemblent pas. Trois grands modèles coexistent, avec des économies et des risques différents.
Modèle 1 : core finance minimal plus satellites métier
On garde un ERP compact centré sur la finance : NetSuite, Sage Intacct, Workday Financials, Oracle Fusion Financials. Autour, on satellise les autres domaines : Workday ou SAP SuccessFactors pour la RH, Coupa ou Ivalua pour les achats, Kinaxis ou o9 pour la supply chain, Salesforce pour le CRM. Un iPaaS orchestre les flux. Un MDM ou un CDP tient les référentiels maîtres.
C’est le modèle le plus mature, dominant dans les services B2B, le SaaS, la tech et la santé. Les acteurs américains (NetSuite, Workday, Coupa, Salesforce) sont très structurants, ce qui crée un effet d’écosystème.
Modèle 2 : plateforme low-code comme cœur
On construit son propre ERP sur une plateforme low-code : Mendix (Siemens), OutSystems ou Microsoft Power Platform. Les applications métier sont fabriquées à la demande, les intégrations sont natives, la gouvernance est centralisée.
Ce modèle convient aux entreprises qui ont des processus très spécifiques non couverts par le standard (métiers rares, logistique complexe, industries très réglementées). Il demande une équipe IT solide et une gouvernance stricte : sans cela, on retombe dans un shadow IT industrialisé. Pour aller plus loin sur ces outils, voir notre guide low-code ERP : personnaliser Odoo, SAP et Dynamics sans coder.
Modèle 3 : ERP historique ouvert plus satellites sélectifs
On garde SAP S/4HANA Cloud, Oracle Fusion Cloud ERP ou Dynamics 365 comme noyau. On exploite leurs APIs publiques et leurs plateformes d’extension (SAP BTP, Oracle OIC, Microsoft Power Platform) pour connecter des briques spécialisées seulement là où l’ERP est faible. Finance, contrôle de gestion et supply restent sur l’ERP. La RH, le CRM ou les achats peuvent être satellisés.
C’est le modèle hybride pragmatique, choisi par la majorité des grandes entreprises qui font S/4HANA ou Oracle Fusion aujourd’hui. C’est aussi celui que SAP pousse sous le nom de « Clean Core » : garder le noyau S/4HANA proche du standard et externaliser les différenciations sur la BTP. Pour une analyse détaillée des deux plateformes, voir notre comparatif SAP S/4HANA vs Oracle Cloud ERP 2026.
Ce qui marche en composable
| Bénéfice | Effet observé |
|---|---|
| Modernisation incrémentale | Remplacement d’une brique en 6 à 12 mois sans bloquer les autres domaines |
| Levier de négociation | Contrats fractionnés, concurrence sur chaque domaine, pas de verrou unique |
| Innovation UX | Interfaces modernes par brique, adoption utilisateur plus rapide |
| Meilleure couverture métier | Chaque domaine a l’outil pensé pour lui, pas un compromis généraliste |
| Attractivité des talents | Les développeurs préfèrent coder sur APIs modernes que sur un ERP ABAP ou AL |
Le retour le plus tangible n’est pas le time-to-value initial (qui est souvent équivalent à un bon projet monolithique) mais la vélocité de modernisation sur 5 à 7 ans. Une architecture composable bien gouvernée permet de remplacer trois briques sur cette durée sans projet pluriannuel. Un monolithe, non.
Le second effet sous-estimé est l’adoption. Les utilisateurs finaux tolèrent beaucoup mieux une bonne UX spécialisée que le compromis généraliste d’un module ERP central. Les équipes achats préfèrent Coupa au module achats historique, même si la DSI est sceptique.
Ce qui casse en composable
Le discours éditeurs iPaaS omet systématiquement le revers. Voici ce qui peut faire échouer une transition composable.
Le coût d’intégration explose
L’iPaaS n’est pas gratuit. MuleSoft tarife à partir de 30 000 euros par an pour un déploiement Gold à 2 vCores, et un cas de grande entreprise atteint facilement 210 000 euros annuels pour un Platinum multi-environnements (MuleSoft Pricing 2026, Automation Atlas). Ajoutez les frais d’implémentation initiaux, qui dans certains cas dépassent le coût plateforme la première année. Boomi, Workato ou Celigo sont moins chers mais restent des postes de dépense structurants. La règle empirique largement observée chez les ETI : le coût d’intégration représente 30 à 50 pour cent du coût de licence annuel cumulé des briques métier.
Le référentiel maître devient un casse-tête
Dans un monolithe, le client existe à un seul endroit. Dans un composable, le même client est dans Salesforce, dans NetSuite, dans Coupa (comme fournisseur), dans Workday (si c’est un prestataire), dans le CDP et parfois dans le DWH. Qui est la source de vérité ? Qui propage les mises à jour ? Qui résout les conflits ? Sans une stratégie MDM (Master Data Management) sérieuse, on obtient des divergences silencieuses qui polluent le reporting et l’audit.
La gouvernance SI devient dix fois plus exigeante
Un composable exige un architecte d’entreprise dédié, une équipe d’intégration (pas un prestataire en régie), un API management (Apigee, Kong, Axway) avec versioning strict, et une gouvernance contractuelle pluri-éditeur. Sans cela, chaque brique évolue indépendamment, les APIs se brisent en cascade, et les incidents de production se multiplient.
Le closing financier devient un projet en soi
Consolider cinq ou six systèmes en un reporting financier mensuel est techniquement faisable, mais consomme du temps, du logiciel (BlackLine, Trintech, OneStream) et des ressources contrôle de gestion. Les CFO qui ont vécu la transition témoignent tous d’un durcissement du closing avant qu’il ne se stabilise, 12 à 18 mois après la bascule.
La compliance transverse devient plus difficile
Appliquer le RGPD sur un monolithe est un seul projet. L’appliquer sur huit systèmes, avec des registres de traitement qui doivent s’aligner, des droits d’accès cohérents, et des workflows de suppression qui traversent des APIs, devient un chantier permanent. Même logique pour la SOX, la CSRD, NIS2, DORA ou l’e-invoicing obligatoire dans plusieurs pays européens.
Critères pour savoir si le composable est pour vous
Tous les contextes n’appellent pas une architecture composable. Quatre critères à appliquer avant de décider.
Taille d’entreprise
En pratique, le composable devient rentable autour de 500 millions d’euros de chiffre d’affaires ou 2 000 à 3 000 salariés. En dessous, la complexité de gouvernance et le coût d’intégration dépassent les gains de flexibilité. Au-dessus, c’est quasi incontournable pour rester compétitif sur le rythme de livraison métier.
Maturité de la DSI
Pré-requis non négociables : un architecte d’entreprise dédié, une équipe d’intégration interne (2 à 5 personnes minimum), une gouvernance API formalisée, un iPaaS managé. Si la DSI actuelle est en mode « commande à prestataire », la transition composable va exposer toutes les faiblesses de gouvernance.
Horizon temporel
Une transition composable se raisonne sur 5 à 7 ans. Pas sur 2 ans. Si le sponsor (DG, CFO, CIO) a un horizon de mandat plus court, il faut soit décaler, soit s’en tenir à un composable léger (voir plus bas).
Profil métier
Le composable est surtout payant quand l’activité est hétérogène : multi-BU, multi-pays, multi-métiers avec des besoins spécifiques par domaine. Sur une activité mono-métier concentrée géographiquement, un monolithe bien paramétré reste souvent plus efficient.
Comparaison pragmatique : composable vs monolithe cloud
| Critère | Composable (ex. NetSuite + Workday + Coupa + Salesforce) | Monolithe S/4HANA Cloud ou Oracle Fusion |
|---|---|---|
| TCO cinq ans | Supérieur de 20 à 40 pour cent typique, fortement dépendant de l’intégration | Plus prévisible, enveloppe mieux maîtrisée |
| Time-to-value par brique | Rapide (6 à 12 mois par domaine) | Plus lent (18 à 24 mois pour le core) |
| Verrouillage éditeur | Dilué sur 5 à 8 éditeurs | Concentré sur un éditeur principal |
| Gouvernance SI requise | Lourde (architecte, intégration, MDM, API management) | Plus légère, un centre de compétences ERP suffit |
| Innovation par domaine | Élevée | Dépend du rythme de l’éditeur principal |
| Consolidation financière | Projet continu avec logiciels dédiés | Native, intégrée au grand livre |
| Résilience opérationnelle | Dépend de la qualité des intégrations | Mutualisée par le monolithe |
Le tableau ci-dessus n’est pas une recommandation. C’est un arbitrage. Selon que l’on optimise le coût total, la flexibilité, ou la vélocité, la bonne réponse change.
Alternative : le composable léger
Pour les ETI entre 50 et 500 millions d’euros de chiffre d’affaires, la bonne cible n’est souvent ni le full composable ni le monolithe pur, mais une version intermédiaire. Un ERP compact plus un ou deux satellites spécialisés.
Trois archetypes fréquents en Europe :
- Cegid XRP Flex + Talentsoft + Salesforce pour une ETI française à composante commerciale forte.
- SAP Business One + Sage People + HubSpot pour une PME industrielle en croissance.
- Odoo Enterprise + Workday ou Factorial + HubSpot pour un modèle distribution multi-pays.
Ce composable léger capture 70 pour cent des bénéfices du composable complet (modernisation par brique pour la RH et le CRM, UX spécialisée) sans la complexité de gouvernance d’un full best-of-breed. Un iPaaS léger (Make, Zapier enterprise, Workato à petite échelle, ou les connecteurs natifs Odoo ou SAP B1) suffit pour les volumes. Pour comprendre comment câbler CRM et ERP proprement, voir notre guide intégration CRM et ERP : architecture, flux, erreurs à éviter.
Conclusion et ressources
L’ERP composable n’est pas la fin du monolithe. C’est une option d’architecture parmi d’autres, pertinente quand la taille, la maturité DSI et l’horizon temporel s’alignent. Pour les grandes entreprises multi-BU avec une DSI mature, c’est la direction raisonnable à 2030. Pour les ETI, un composable léger capture l’essentiel des bénéfices sans le coût de gouvernance. Pour les PME, un bon monolithe SaaS bien paramétré reste souvent la meilleure décision économique.
Le débat n’est pas idéologique, il est contextuel. L’erreur classique est d’adopter un vocabulaire sans adopter les pré-requis : sans iPaaS budgété, sans architecte dédié, sans stratégie MDM, un composable mal gouverné coûte plus cher et livre moins de valeur qu’un monolithe honnête.
Pour aller plus loin sur les choix structurants d’architecture, lisez aussi notre comparatif cloud vs on-premise : avantages et inconvénients et notre guide low-code pour personnaliser un ERP sans coder.
Vous pilotez un choix ERP structurant en 2026 et vous voulez un cadrage neutre avant de lancer un RFP ? Un POC de 3 mois sur un seul domaine (finance, RH ou achats) permet de tester l’hypothèse composable sur votre contexte réel, pour un budget typique de 15 à 30 k€. Résultat : une décision Go/No-Go argumentée, pas un slide de promesses commerciales.
