Dans la majorité des groupes de taille intermédiaire à grande, le paysage ERP n’est pas un jardin bien ordonné. C’est un archipel : un SAP S/4HANA hérité de la maison mère, un Odoo adopté par la filiale e-commerce rachetée il y a deux ans, un Sage X3 qui fait tourner la comptabilité du siège depuis quinze ans. Chaque île fonctionne, mais l’ensemble ne communique pas, ou mal.
La question n’est pas nouvelle, mais elle se pose avec une acuité renouvelée. La croissance externe s’accélère, les exigences réglementaires se multiplient par pays, et les plateformes d’intégration (iPaaS) rendent enfin viable ce qui relevait du projet pharaonique il y a cinq ans. Alors, faut-il tout migrer vers un ERP unique, ou assumer la coexistence et investir dans l’orchestration ?
Cet article propose un cadre de décision pour les DSI et directeurs de la transformation qui gèrent, ou subissent, un paysage multi-ERP. Il complète notre guide sur le multi-site et multi-entité avec un seul ERP et notre comparatif des architectures iPaaS.
Pourquoi les groupes se retrouvent avec plusieurs ERP
Croissance externe et rachats successifs
C’est le scénario le plus fréquent. Un groupe industriel rachète un concurrent, une startup complémentaire ou un acteur dans un pays voisin. Chaque cible arrive avec son propre ERP, ses processus métiers rodés et ses équipes qui connaissent l’outil. Forcer une migration immédiate vers l’ERP du groupe acquéreur, c’est prendre un risque opérationnel majeur au moment précis où l’intégration post-acquisition exige de la stabilité.
Les fonds de private equity connaissent bien ce dilemme : avec un horizon de cession de trois à cinq ans, investir 18 mois et plusieurs millions dans une convergence ERP n’a aucun sens économique. Le multi-ERP n’est alors pas un accident, c’est la stratégie rationnelle.
Filiales dans des secteurs ou pays aux contraintes SI incompatibles
Un groupe présent dans l’agroalimentaire et la distribution n’a pas les mêmes besoins ERP qu’une entité de services. Le premier a besoin de traçabilité lot, de gestion des DLC et de conformité sanitaire. Le second a besoin de staffing, de feuilles de temps et de facturation au projet. Aucun ERP généraliste ne couvre nativement ces deux univers avec la même profondeur.
De même, les contraintes réglementaires locales (facturation électronique en Italie, SII en Espagne, e-Factura en Roumanie) peuvent justifier un ERP local spécialisé plutôt qu’un paramétrage complexe de l’ERP central.
Choix délibéré : best-of-breed par BU vs uniformité groupe
Certains groupes font le choix conscient du best-of-breed. Plutôt qu’un ERP monolithique qui fait tout moyennement, ils préfèrent un ERP industriel spécialisé pour la production, un PSA pour les activités de conseil, et un ERP finance pour la consolidation groupe. C’est l’approche dite « composable », que Gartner promeut depuis sa théorisation de l’ERP postmoderne en 2013.
Une étude Rimini Street menée auprès de 455 décideurs IT montre que 78 % des clients SAP envisagent de s’appuyer sur plusieurs éditeurs pour innover dans leur paysage ERP (E3 Magazine / Rimini Street). Le monolithe n’est plus un dogme.
Single-instance, multi-instance, multi-ERP, clarifier les architectures
Avant de trancher, il faut nommer précisément ce dont on parle. Trois architectures coexistent, et elles n’ont pas les mêmes implications.
Single-instance : un ERP, un tenant, toutes les entités
C’est le modèle canonique promu par SAP avec S/4HANA Cloud : toutes les entités juridiques du groupe opèrent dans un seul tenant, avec un plan comptable commun, des référentiels partagés et une consolidation native. L’avantage est évident : un seul système à maintenir, une seule version à mettre à jour, une visibilité temps réel sur l’ensemble du groupe.
Le revers : un déploiement long (12 à 24 mois minimum pour un groupe multi-pays), un coût élevé, et une rigidité qui peut étouffer les filiales aux besoins atypiques. Chaque spécificité locale se traduit par un paramétrage supplémentaire ou un développement spécifique qui complexifie les montées de version.
Multi-instance : le même ERP, des tenants séparés par BU ou pays
Le groupe utilise le même éditeur (par exemple Microsoft Dynamics 365 Finance), mais chaque filiale ou région dispose de son propre tenant. Les référentiels sont distincts, les paramétrages adaptés aux contraintes locales, et la consolidation se fait via des interfaces entre instances.
Ce modèle offre un bon compromis entre autonomie locale et cohérence éditeur. Les compétences sont mutualisables, les montées de version sont coordonnées, et l’intégrateur peut intervenir sur un socle technique homogène. En revanche, les interfaces inter-instances doivent être construites et maintenues, ce qui n’est pas gratuit.
Multi-ERP : des éditeurs différents coexistent
C’est le cas le plus complexe et le plus fréquent dans les groupes issus de croissance externe. SAP pour la branche industrielle, Odoo pour le retail, Sage pour le corporate, Workday pour les RH. Chaque système a sa logique, ses APIs, ses cycles de mise à jour et son écosystème d’intégrateurs.
L’avantage : chaque BU dispose de l’outil le mieux adapté à son métier. L’inconvénient : l’intégration entre systèmes devient un projet à part entière, permanent et coûteux.
Tableau comparatif
| Critère | Single-instance | Multi-instance | Multi-ERP |
|---|---|---|---|
| Cohérence des données | Très forte | Forte (si interfaces OK) | Faible sans MDM |
| Autonomie des filiales | Faible | Moyenne | Forte |
| Coût d’intégration | Faible (natif) | Moyen | Élevé (iPaaS + MDM) |
| Délai de déploiement | Long (12-24 mois) | Moyen (6-12 mois/instance) | Court par BU, long en consolidation |
| Flexibilité métier | Limitée au standard | Modérée | Maximale |
| Compétences requises | Un éditeur | Un éditeur, N tenants | N éditeurs, N logiques |
| Complexité de montée de version | Modérée | Multipliée par N | Indépendante par BU |
Quand le multi-ERP est la bonne stratégie
Holdings de PE avec horizon de cession court
Pour un fonds qui prévoit de céder une entité dans trois à cinq ans, unifier l’ERP est un investissement à fonds perdus. L’acquéreur suivant imposera son propre système. La stratégie rationnelle : stabiliser chaque ERP existant, déployer une couche iPaaS légère pour la consolidation financière, et investir le budget économisé dans la croissance opérationnelle.
Filiales avec des contraintes réglementaires locales fortes
Quand une filiale roumaine doit se conformer à e-Factura et e-Transport, qu’une filiale espagnole est soumise au SII et TicketBAI, et que le siège français utilise Chorus Pro, forcer un ERP central à gérer nativement ces trois régimes est souvent plus coûteux qu’un ERP local déjà conforme dans chaque pays. La complexité réglementaire justifie parfois la fragmentation du paysage applicatif.
Entités très différentes : manufacturing + services + retail
Un groupe qui opère simultanément dans la fabrication industrielle, le conseil en ingénierie et la distribution en ligne a trois métiers fondamentalement distincts. Un ERP manufacturing (Infor CloudSuite Industrial, IFS Cloud) ne couvre pas bien le staffing et la facturation au temps passé. Un PSA (Deltek, Kantata) ne gère pas la production avec ordres de fabrication. Et un OMS e-commerce n’a pas les mêmes besoins que les deux précédents. Le multi-ERP est ici un choix d’architecture, pas un accident historique.
Quand le multi-ERP est un piège
Consolidation financière impossible sans middleware lourd
Le flux le plus critique en multi-ERP est la consolidation financière. Agréger les comptes de filiales qui utilisent des plans comptables différents, des devises différentes, des règles d’élimination intercompany différentes, tout cela nécessite un outil de consolidation dédié (SAP BPC, OneStream, Tagetik) ou des développements lourds. Si le groupe est soumis aux normes IFRS, la complexité est décuplée : chaque ajustement entre référentiels locaux et IFRS doit être tracé et auditable.
Explosion des coûts de maintenance et de compétences
Chaque ERP nécessite ses propres compétences : consultants fonctionnels, développeurs techniques, administrateurs système. Maintenir trois ERP différents, c’est maintenir trois équipes, ou payer trois contrats de TMA (Tierce Maintenance Applicative) avec trois intégrateurs différents. Le coût total de possession (TCO) d’un paysage multi-ERP est structurellement plus élevé que celui d’un ERP unifié, à périmètre fonctionnel équivalent.
Perte de visibilité temps réel sur les KPI groupe
Sans couche d’intégration robuste, le reporting groupe devient un exercice de consolidation manuelle. Les tableaux de bord sont alimentés par des extractions Excel, les données arrivent avec 48 heures de retard, et personne n’a confiance dans les chiffres. Pour un comité de direction qui pilote à la semaine, c’est un handicap opérationnel majeur.
Orchestrer un paysage multi-ERP, la couche d’intégration
Si le multi-ERP est la stratégie retenue (ou la réalité héritée), l’enjeu se déplace vers l’orchestration. L’objectif n’est pas de fondre les ERP entre eux, mais de créer une couche intermédiaire qui assure la circulation des données critiques.
iPaaS comme colonne vertébrale
Les plateformes d’intégration cloud (iPaaS), MuleSoft, Boomi, Workato, sont devenues le standard pour connecter des ERP hétérogènes. Elles offrent des connecteurs pré-construits vers les principaux ERP, un moteur de transformation des données, et une supervision centralisée des flux.
Le marché iPaaS mondial est estimé à plus de 70 milliards de dollars d’ici 2030, avec une croissance annuelle supérieure à 30 % (Latenode, 2025). Cette croissance reflète directement le besoin d’intégration des paysages applicatifs hétérogènes. Le coût annuel d’une plateforme iPaaS entreprise se situe typiquement entre 50 000 et 250 000 €, selon le volume de flux et le nombre de connecteurs.
Les flux prioritaires à connecter : commandes intercompany, mouvements de stocks inter-sites, écritures comptables pour consolidation, référentiels clients et fournisseurs partagés.
MDM pour la cohérence des référentiels
Le Master Data Management (MDM) est le prérequis souvent sous-estimé du multi-ERP. Sans référentiel commun de clients, fournisseurs, articles et plans comptables, l’iPaaS ne peut pas mapper correctement les données entre systèmes.
Le marché MDM connaît une croissance soutenue, passant d’environ 19 milliards de dollars en 2025 à une projection de plus de 70 milliards en 2032 (Verdantis, 2026). Pourtant, une entreprise sur quatre retarde encore son déploiement MDM à cause de la complexité d’intégration avec les systèmes existants.
Les acteurs de référence (Informatica, Reltio, Stibo Systems) proposent des solutions cloud qui synchronisent les référentiels entre ERP en temps réel. Le coût d’un projet MDM varie de 100 000 € (PME, un seul domaine) à plusieurs millions (groupe multi-pays, multi-domaines).
Data warehouse / data lakehouse pour la consolidation analytique
La consolidation opérationnelle (stocks, commandes, production) et la consolidation financière passent souvent par un entrepôt de données commun. Un data lakehouse (Snowflake, Databricks, BigQuery) agrège les données de chaque ERP, les normalise et les expose via des tableaux de bord unifiés (Power BI, Looker, Tableau).
C’est la réponse à la perte de visibilité : plutôt que d’exiger un reporting natif de chaque ERP, on crée une couche analytique commune qui absorbe l’hétérogénéité des sources.
API gateway et gouvernance des flux inter-ERP
Dans un paysage multi-ERP, le nombre d’intégrations point-à-point croît de façon combinatoire. Avec trois ERP, on a potentiellement six flux bidirectionnels. Avec cinq, vingt. Un API gateway centralise les appels, applique des politiques de sécurité et de throttling, et offre un point d’observation unique sur la santé des échanges.
La gouvernance des flux n’est pas un luxe technique : c’est ce qui empêche un incident sur un ERP de se propager aux autres par effet domino. Chaque flux doit avoir un propriétaire métier identifié, un SLA documenté et un circuit d’escalade en cas de défaillance.
Feuille de route : décider, cartographier, orchestrer
Phase 1 : Cartographier le paysage applicatif existant (4-6 semaines)
Avant de décider, il faut voir clair. La cartographie couvre :
- Inventaire des ERP : éditeur, version, hébergement (on-premise / cloud / hybride), nombre d’utilisateurs, modules actifs.
- Flux de données inter-systèmes : quels flux existent aujourd’hui (même manuels via Excel), quelle fréquence, quel volume, quelle criticité.
- Coûts actuels : licences, TMA, hébergement, ressources internes par ERP.
- Contraintes réglementaires : obligations locales (facturation électronique, localisation comptable, conformité sectorielle) qui imposent un paramétrage spécifique.
Le livrable est une matrice qui croise les entités du groupe avec les ERP utilisés, les flux critiques et les coûts associés. C’est la base factuelle de toute décision.
Phase 2 : Définir la cible à 3 ans (2-4 semaines)
Trois scénarios se dessinent généralement :
- Convergence totale : migration de toutes les entités vers un ERP unique. Pertinent pour les groupes matures, stables, avec un horizon long et un budget conséquent.
- Convergence partielle : regroupement des entités les plus proches sur un même ERP, maintien d’ERP spécialisés pour les cas atypiques. C’est souvent le scénario le plus pragmatique.
- Coexistence assumée : maintien des ERP existants avec investissement dans la couche d’orchestration (iPaaS + MDM + data warehouse). Pertinent pour les holdings de PE, les groupes très diversifiés, ou les contextes post-acquisition récents.
Le choix dépend de trois facteurs : l’horizon de détention, la diversité des métiers et le budget disponible. Il n’y a pas de réponse universelle, mais il y a des mauvaises raisons de choisir (nostalgie d’un rêve single-instance, pression commerciale d’un éditeur, ou inertie face à la complexité).
Phase 3 : Prioriser les intégrations par valeur métier (en continu)
Une fois la cible définie, la mise en oeuvre passe par une priorisation rigoureuse des flux d’intégration. Le critère n’est pas la complexité technique, mais la valeur métier :
- Consolidation financière : c’est le flux non négociable. Sans lui, le groupe ne peut pas clôturer ses comptes.
- Référentiels clients et fournisseurs : sans cohérence sur ces données, chaque entité vit dans son propre univers commercial.
- Stocks et commandes intercompany : critique pour les groupes avec des flux physiques entre entités.
- Reporting RH et paie : important mais souvent moins urgent que les trois précédents.
Chaque flux intégré est un projet en soi, avec son budget, son délai et son propriétaire métier. La tentation de tout intégrer en parallèle est un piège classique, mieux vaut un flux bien intégré qu’une dizaine de flux instables.
Ce qu’il faut retenir
Le multi-ERP n’est ni une fatalité ni une erreur. C’est une réalité pour la majorité des groupes de taille significative, et c’est parfois la stratégie la plus intelligente. L’erreur n’est pas d’avoir plusieurs ERP, c’est de ne pas les orchestrer.
Les entreprises qui combinent des architectures ouvertes et composables avec un support multi-éditeur atteignent des performances supérieures dans 83 % des cas, contre seulement 27 % pour les approches monolithiques traditionnelles (E3 Magazine / Rimini Street). Le paradigme a changé : la question n’est plus « quel ERP unique choisir ? » mais « comment faire coexister intelligemment les outils les mieux adaptés à chaque métier ? ».
Pour approfondir, lisez notre guide sur la gestion multi-site et multi-entité avec un seul ERP, notre comparatif des architectures iPaaS pour l’intégration ERP et notre analyse des 100 premiers jours post-fusion SI.
