Un groupe industriel français de taille intermédiaire ouvre une filiale commerciale à Varsovie et en rachète une autre à Séville. Son ERP central, SAP S/4HANA déployé depuis trois ans au siège, tourne bien. La question qui se pose immédiatement : faut-il étendre S/4HANA à ces deux entités de 18 et 23 utilisateurs respectivement, ou choisir un ERP plus léger et les connecter au système central ?
C’est la question fondatrice de la stratégie two-tier ERP. Et en 2026, la réponse n’est pas “ça dépend” vague : elle se calcule, se modélise et s’architecture.
Cet article s’adresse aux DSI et responsables IT d’ETI internationales qui gèrent entre 3 et 15 filiales et réfléchissent à leur architecture ERP. Il complète notre guide sur la stratégie multi-ERP pour les groupes, notre référence sur le multi-site et la consolidation intercompany, et notre comparatif des architectures iPaaS.
1. Qu’est-ce que la stratégie two-tier ERP ?
1.1 ERP de niveau 1 vs niveau 2 : rôles respectifs
La stratégie two-tier ERP consiste à faire coexister délibérément deux catégories d’ERP dans un même groupe : un ERP de niveau 1 (Tier 1) pour le siège et les grandes entités, et un ERP de niveau 2 (Tier 2) pour les filiales ou business units aux besoins plus simples.
Le Tier 1 prend en charge les processus groupe les plus complexes : consolidation financière IFRS, gestion de production multi-sites, conformité fiscale avancée, supply chain internationale, reporting exécutif. Les éditeurs positionnés ici sont SAP S/4HANA (RISE with SAP), Oracle Cloud ERP, Dynamics 365 Finance & Operations, et dans une moindre mesure Infor CloudSuite. Ces plateformes sont puissantes, hautement paramétrables, mais coûteuses à déployer et à opérer.
Le Tier 2 couvre les besoins courants d’une filiale : comptabilité locale, facturation clients et fournisseurs, stock de base, CRM, paie. Il doit être déployable rapidement (dans les 3 à 6 mois), maintenu à coût raisonnable, et conforme aux obligations fiscales et comptables du pays d’implantation. Les solutions majeures de ce segment sont SAP S/4HANA Cloud Public Edition (GROW with SAP), Oracle NetSuite, Microsoft Dynamics 365 Business Central, et Odoo.
Ce n’est pas un paysage multi-ERP accidentel, né de rachats successifs et d’héritages sédimentés. C’est une architecture délibérée, avec une gouvernance et une intégration pensées dès le départ. La nuance est fondamentale.
1.2 Pourquoi le “one-size-fits-all” ne fonctionne pas pour les groupes multi-pays
Déployer un ERP Tier 1 dans l’ensemble des entités d’un groupe international semble séduisant sur le papier : référentiel unique, consolidation native, support mutualisé. En pratique, trois obstacles rendent cette approche peu viable pour les petites filiales.
D’abord, le coût de licence disproportionné. Les éditeurs Tier 1 facturent leurs licences en fonction de la taille de déploiement, mais leurs minimums contractuels restent élevés même pour 15 utilisateurs. Étendre un contrat SAP S/4HANA RISE à une filiale de 20 personnes revient souvent à dépenser deux à trois fois ce que l’entité déboursera pour un ERP Tier 2 adapté.
Ensuite, le délai de déploiement incompatible avec la réalité opérationnelle. Un projet S/4HANA ou Oracle Cloud ERP en filiale internationale prend entre 12 et 24 mois en déploiement standard. Une filiale rachetée doit être opérationnelle en 3 à 6 mois. Le two-tier permet d’ouvrir la filiale avec un Tier 2 déployé rapidement, le temps que l’intégration au Tier 1 soit conduite sereinement.
Enfin, les contraintes réglementaires locales que l’ERP central ne couvre pas nativement. La facturation électronique obligatoire en Italie (SDI), la déclaration SII en Espagne, le système e-Factura en Roumanie : ces localisations fiscales spécifiques sont souvent mieux supportées par des éditeurs Tier 2 qui y consacrent des équipes locales.
Gartner, dans sa note de recherche “Two-Tier ERP: A Useful, Composable ERP Strategy for Complex Organizations”, considère le two-tier comme l’une des expressions concrètes de l’ERP composable : chaque couche du groupe utilise l’outil le mieux adapté à sa complexité opérationnelle.
2. Quand la stratégie two-tier devient-elle le bon choix ?
2.1 Seuil de taille de filiale : la règle des 50 utilisateurs ERP actifs
La règle empirique la plus utilisée par les intégrateurs ERP est celle du seuil de 50 utilisateurs ERP actifs par filiale. En dessous de ce seuil, le coût total de possession d’un ERP Tier 1, license + déploiement + formation + support annuel, est disproportionné par rapport à la valeur générée pour l’entité.
Un calcul simplifié illustre la logique : une licence SAP S/4HANA RISE pour 20 utilisateurs filiale coûte en moyenne 30 000 à 50 000 euros par an, auxquels s’ajoutent 150 000 à 250 000 euros de déploiement initial. Sur cinq ans, le coût total dépasse souvent les 350 000 euros. Le même périmètre fonctionnel couvert par Dynamics 365 Business Central ou NetSuite revient à 60 000 à 120 000 euros sur cinq ans pour la même filiale, selon les modules activés.
Au-delà de 50 utilisateurs, la balance penche vers le Tier 1 : la complexité opérationnelle justifie la puissance de l’outil, et le coût unitaire par utilisateur devient compétitif.
2.2 Spécificités métier incompatibles avec l’ERP central
Certains métiers de filiales résistent structurellement à l’ERP central. Une filiale de distribution rachète récemment par un groupe industriel SAP aura des besoins CRM et e-commerce que S/4HANA couvre mal nativement. Une filiale de services professionnels a besoin d’un PSA (Professional Services Automation) que l’ERP production du groupe ne propose pas.
Dans ces cas, le Tier 2 n’est pas un pis-aller temporaire. C’est l’outil adapté au métier, intégré au Tier 1 uniquement pour les flux financiers (remontée du chiffre d’affaires, des créances, des dettes, et des provisions).
2.3 Contraintes réglementaires locales
La conformité fiscale locale est l’argument le plus souvent décisif. Les filiales implantées dans des pays à réglementation fiscale numérique avancée, Italie, Espagne, Pologne, Roumanie, ont besoin d’un ERP localisé et certifié dans le pays. Paramétrer un ERP central généraliste pour supporter ces obligations coûte plus cher, et prend plus de temps, que d’adopter un Tier 2 dont l’éditeur entretient déjà cette localisation.
2.4 Coût de déploiement prohibitif de l’ERP central en petites entités
Le coût de déploiement d’un ERP Tier 1 en petite filiale est rarement linéaire. Les consultants SAP ou Oracle facturent leurs prestations au même tarif qu’en déploiement siège. Le risque de surinvestissement sur un périmètre réduit est réel. Un projet qui aurait coûté 200 000 euros pour 100 utilisateurs siège peut en coûter 150 000 pour 15 utilisateurs filiale, avec des fonctions utilisées à 30 % seulement.
3. Les 4 combinaisons two-tier les plus courantes en 2026
3.1 SAP S/4HANA + Microsoft Dynamics 365 Business Central
La combinaison la plus répandue dans les groupes européens de taille intermédiaire. Le siège tourne sur SAP S/4HANA (RISE with SAP, cloud privé), les filiales de moins de 80 utilisateurs sur Dynamics 365 Business Central.
L’intégration passe par un iPaaS, Azure Integration Services ou MuleSoft selon le stack technique du groupe. Les flux financiers, factures intercompany, données fournisseurs partagés, consolidation mensuelle, sont synchronisés via des APIs standardisées. L’hétérogénéité vendeur est gérée par l’iPaaS, ce qui exige une équipe d’intégration dédiée.
3.2 Oracle Cloud ERP + NetSuite (filiales multidevises)
Oracle a racheté NetSuite en 2016 précisément pour structurer cette architecture two-tier. Oracle Cloud ERP tient les finances du siège et des grandes entités ; NetSuite OneWorld équipe les filiales internationales, avec une gestion native des multi-devises et des multi-entités.
L’intégration est assurée par SuiteCloud Connect for Oracle, un connecteur natif qui synchronise les données financières entre les deux niveaux (NetSuite Two-Tier ERP for Oracle). L’avantage majeur : les deux éditeurs appartenant au même groupe, la gouvernance contractuelle et la feuille de route produit sont alignées.
3.3 SAP ou Oracle + Odoo (filiales PME < 30 utilisateurs)
Pour les filiales les plus petites, moins de 30 utilisateurs avec des besoins de base en comptabilité, facturation et CRM, Odoo s’impose comme le Tier 2 le plus économique. Sa licence démarre à 24,90 dollars par utilisateur et par mois (Odoo Pricing 2026). Un déploiement simple peut être finalisé en 4 à 8 semaines.
L’intégration avec un SAP ou Oracle central passe obligatoirement par un iPaaS : Odoo n’offre pas de connecteur natif vers ces éditeurs Tier 1. La synchronisation se limite généralement aux données financières essentielles, comptes clients, fournisseurs, balance, pour alimenter la consolidation groupe. C’est suffisant si la filiale est autonome opérationnellement.
3.4 Dynamics 365 Finance & Operations + Business Central
La combinaison la plus fluide techniquement. Microsoft a conçu Business Central comme le Tier 2 naturel de Dynamics 365 Finance & Operations. Les deux produits partagent la couche Microsoft Dataverse, ce qui simplifie considérablement la synchronisation des données : contacts, articles, plans comptables peuvent être partagés via des connecteurs standard, sans développement iPaaS sur mesure (Two-Tier ERP Strategy with Business Central).
L’avantage décisif : un seul contrat Microsoft, une seule équipe support, des compétences consultants mutualisables. Le surcoût de gestion d’un Tier 2 distinct est significativement réduit.
4. Architecture d’intégration : faire parler les deux niveaux
4.1 Synchronisation financière : consolidation, intercompany, multidevise
La règle cardinale de la stratégie two-tier est celle-ci : l’ERP Tier 2 ne doit jamais créer de silos financiers. Les données financières des filiales, chiffre d’affaires, créances clients, dettes fournisseurs, provisions, doivent remonter au Tier 1 ou au CPM (Corporate Performance Management) de consolidation, selon un calendrier et un format définis.
La consolidation en multi-devises exige que le Tier 2 transmette ses données dans la devise de reporting du groupe (en général l’euro), avec les taux de change utilisés à la clôture, pour que les écarts de change latents soient correctement calculés. Un Tier 2 qui exporte ses balances en devise locale sans taux attaché oblige les équipes consolidation à un retraitement manuel chronophage.
4.2 Interfaces temps réel vs batch : quand choisir quoi
Toutes les synchronisations ne requièrent pas la même fréquence. Un cadrage pragmatique distingue deux catégories :
Temps réel (ou quasi-temps réel, délai < 15 minutes) : stocks disponibles pour les commandes clients intercompany, position de trésorerie pour la gestion des financements, statut des livraisons intragroupes. Ces flux conditionnent des décisions opérationnelles immédiates.
Batch (quotidien ou mensuel) : balance comptable, justifications de charges, positions analytiques, données RH. Ces flux alimentent des processus de clôture planifiés, la latence n’est pas critique.
Surdimensionner les interfaces temps réel augmente les coûts de middleware et la complexité de monitoring. Mieux vaut cartographier les flux par criticité et choisir la fréquence au plus juste.
4.3 iPaaS et middleware : critères de choix
Trois plateformes dominent le segment des intégrations ERP-to-ERP en Europe :
Azure Integration Services : solution naturelle si le Tier 1 est Dynamics 365 et le Tier 2 Business Central. Les deux produits étant sur Azure, la latence est minimale et les connecteurs natifs réduisent le développement sur mesure.
MuleSoft (Anypoint Platform) : outil de référence pour les stacks SAP-Salesforce ou SAP-multi-ERP. Sa bibliothèque de connecteurs certifiés SAP est étendue. L’investissement initial est élevé (licence, formation), mais il absorbe des architectures d’intégration complexes.
Dell Boomi : positionnement agnostique, bonne couverture des éditeurs mid-market (NetSuite, Odoo, Sage). Modèle de licensing par nombre de connexions, adapté aux architectures two-tier modestes.
Le critère de décision principal n’est pas l’outil lui-même : c’est l’existence de compétences internes ou partenaires pour l’opérer durablement. Un iPaaS que personne ne maîtrise en interne devient un goulet d’étranglement dès la première modification de flux.
5. Gouvernance et pièges à éviter
5.1 Shadow IT et fragmentation progressive
Le risque numéro un du two-tier est l’extension non maîtrisée. Une filiale déploie son Tier 2. Six mois plus tard, la filiale ajoute un outil de gestion des notes de frais non connecté, puis un CRM local parce que le Tier 2 “ne fait pas assez bien le CRM”. Le two-tier devient three-tier, puis five-tier.
La gouvernance doit définir dès le départ une liste close d’outils autorisés en complément du Tier 2, avec des intégrations pré-validées. Tout ajout hors liste passe par une décision IT groupe, pas par la filiale seule.
5.2 Double maintenance et double formation
La stratégie two-tier implique structurellement deux cycles de vie logicielle distincts. Les montées de version du Tier 1 et du Tier 2 ne sont pas synchronisées. Une mise à jour majeure d’un côté peut casser une interface de l’autre, si celle-ci s’appuie sur une API versionnée.
L’équipe IT groupe doit maintenir la compétence sur les deux systèmes, ou contractualiser des partenaires experts sur chacun. Ce coût de gestion est souvent sous-estimé dans le business case initial.
5.3 Propriété des données et ownership cross-système
Dans une architecture two-tier, les mêmes entités de données existent souvent dans les deux systèmes : le fournisseur Acme est dans le Tier 1 comme dans le Tier 2. La question de la source de vérité doit être tranchée explicitement : qui crée les nouvelles fiches fournisseurs ? Dans quel système ? Quel est le processus de propagation ?
Sans décision claire, les doublons prolifèrent, les codes comptables divergent, et la consolidation devient un exercice de rapprochement manuel interminable.
6. Quatre profils d’ETI et recommandations
Groupe industriel, 500 utilisateurs siège, 3 filiales commerciales de 15 à 25 utilisateurs chacune en Europe de l’Est. L’ERP central est SAP S/4HANA RISE. Recommandation : Odoo pour les filiales, intégré via MuleSoft ou Azure Integration Services pour les flux financiers. ROI attendu : coût total two-tier inférieur de 40 à 60 % à un déploiement SAP uniforme, pour des filiales dont les besoins métier sont couverts à 90 % par Odoo.
Groupe de services professionnels, 200 utilisateurs au siège en France, 5 filiales en Europe, 30 à 60 utilisateurs chacune. Dynamics 365 Finance & Operations au siège. Recommandation : Business Central en filiales, intégration via Dataverse. Avantage : un seul écosystème Microsoft, compétences mutualisées, contrat unifié.
Société e-commerce multi-pays, siège aux Pays-Bas, filiales à géométrie variable en fonction de l’expansion géographique. Recommandation : Oracle Cloud ERP au siège, NetSuite OneWorld pour les filiales dès leur ouverture. Le modèle SaaS de NetSuite permet d’ouvrir une nouvelle entité en 6 à 8 semaines, sans projet IT lourd.
Groupe issu d’une acquisition récente. La filiale acquise tourne sur un ERP existant. Recommandation : ne pas migrer immédiatement. Traiter l’ERP existant comme un Tier 2 transitoire, construire l’intégration financière minimum pour la consolidation, et prévoir la convergence à 18-24 mois post-acquisition. La stabilité opérationnelle post-acquisition vaut plus que la pureté architecturale immédiate.
Conclusion
La stratégie two-tier ERP n’est pas un compromis : c’est une architecture rationnelle pour les groupes qui refusent de faire payer à leurs petites filiales le coût d’un ERP Tier 1 conçu pour des milliers d’utilisateurs. Elle fonctionne quand trois conditions sont réunies : une intégration financière rigoureuse entre les deux niveaux, une gouvernance claire sur les outils autorisés en complément, et une équipe IT capable de maintenir la compétence sur les deux systèmes.
Les quatre combinaisons décrites dans cet article, SAP + Business Central, Oracle + NetSuite, SAP/Oracle + Odoo, et D365 F&O + Business Central, ne sont pas des recettes universelles. Elles constituent des points de départ à adapter au profil de chaque filiale, à la roadmap de l’éditeur Tier 1 retenu, et aux contraintes réglementaires locales.
Téléchargez notre grille d’évaluation ERP pour benchmarker vos options Tier 1 et Tier 2 sur 30 critères pondérés, du coût de licence à la maturité des localisations fiscales européennes.
