Votre DSI gère aujourd’hui SAP sur Azure, Oracle Fusion sur OCI, Salesforce hébergé chez AWS et Workday dont personne ne sait trop où il tourne. Pas parce que vous avez conçu cette architecture. Parce qu’elle s’est construite toute seule, acquisition après acquisition, SaaS après SaaS, au fil des décisions prises dans différentes directions métier. Le multi-cloud ERP n’est pas une stratégie pour la majorité des ETI — c’est le résultat de dix ans d’accumulation.
Selon le Flexera State of the Cloud Report 2026, 89 % des organisations utilisent aujourd’hui plusieurs fournisseurs cloud simultanément, et 73 % opèrent en mode hybride. Le taux de gaspillage cloud a atteint 29 % en 2026 — première hausse en cinq ans. Sans gouvernance formalisée, le multi-cloud coûte de plus en plus cher pour un bénéfice de plus en plus flou.
Cet article propose un cadre d’analyse : les 4 architectures multi-cloud possibles pour un ERP, le comparatif des hyperscalers, et les piliers de gouvernance pour éviter que votre paysage cloud ne devienne ingérable.
Le multi-cloud ERP : une réalité subie plus que choisie
Comment les ETI se sont retrouvées en multi-cloud sans l’avoir planifié
Trois mécanismes expliquent la quasi-totalité des situations multi-cloud non planifiées dans les ETI.
Les acquisitions sont le premier vecteur. Chaque filiale acquise arrive avec son propre ERP, son propre cloud, ses propres contrats. L’intégration applicative prend des années ; en attendant, les deux environnements coexistent. Après deux ou trois acquisitions, le DSI manage trois ERP sur deux ou trois clouds différents.
Le cloud creep est le second vecteur. Un département finance adopte NetSuite parce que la DRH a refusé d’attendre le prochain cycle de mise à jour de l’ERP central. Le marketing déploie HubSpot en autonomie. La supply chain choisit un WMS SaaS sur AWS. Chacune de ces décisions est rationnelle prise isolément ; collectivement, elles produisent une fragmentation dont personne n’est responsable.
Les directions métier qui achètent leur SaaS sans consulter l’IT sont le troisième vecteur. La prolifération des achats SaaS en dehors du processus de gouvernance IT a explosé depuis 2020. Chaque outil “best-of-breed” s’installe sur son cloud de prédilection.
La combinaison de ces trois mécanismes explique que, selon Flexera, l’adoption multi-cloud progresse souvent de façon non intentionnelle, via des fusions, des équipes applicatives en silos, ou des architectures héritées plutôt que par une stratégie délibérée.
La carte des ERP par hyperscaler certifié en 2026
Chaque hyperscaler a noué des partenariats préférentiels avec certains éditeurs ERP. Ces partenariats ne sont pas neutres : ils influencent les SLA disponibles, les intégrations natives, et les économies de coûts possibles.
AWS est l’hébergeur historique de SAP (partenariat depuis 2011), d’Oracle (E-Business Suite, JDE), d’Infor et de Sage X3. Son écosystème de partenaires intégrateurs est le plus dense.
Azure est devenu le cloud de prédilection de SAP depuis le partenariat renforcé de 2019, confirmé et approfondi à SAP Sapphire 2026 avec l’intégration SAP Joule + Microsoft Copilot et l’expansion des capacités SAP Datasphere sur Microsoft Fabric (source : Microsoft TechCommunity). Microsoft Dynamics 365 est nativement sur Azure. Workday est certifié Azure et AWS.
GCP est l’option privilégiée pour les workloads Oracle analytiques, SAP BW/4HANA, et IFS. Sa force réside dans BigQuery et Vertex AI pour les cas d’usage analytiques autour de l’ERP.
OCI (Oracle Cloud Infrastructure) est le socle exclusif d’Oracle Fusion Cloud ERP. Tous les clients Fusion partagent la même codebase hébergée sur OCI, désormais disponible dans plus de 40 régions mondiales. OCI propose des interconnexions directes avec Azure, AWS et GCP pour les architectures hybrides (source : Oracle).
Les clouds souverains français forment une cinquième catégorie à surveiller en 2026 : OVHcloud (infrastructure qualifiée SecNumCloud), S3NS (Thales/Google, qualification SecNumCloud 3.2 obtenue fin 2025), Cloud Temple, et Bleu (Orange/Capgemini sur technologie Azure, qualification en cours). Voir l’analyse détaillée dans notre article sur le cloud de confiance et l’ERP en France.
Les 4 architectures multi-cloud ERP possibles
Architecture 1 — Hub-and-spoke (un cloud principal, les autres en périphérie)
Le modèle hub-and-spoke consiste à désigner un cloud principal qui héberge le coeur ERP transactionnel, et à y rattacher les modules périphériques hébergés sur d’autres clouds via des connexions dédiées (VPN, ExpressRoute, Direct Connect selon les hyperscalers).
Exemple type : SAP S/4HANA sur Azure comme hub, Workday HR sur Azure également pour maintenir les données RH dans le même périmètre cloud, Salesforce sur AWS en périphérie avec une intégration SAP Integration Suite.
Avantages : gouvernance centralisée sur un fournisseur principal, contrats simplifiés, SLA de disponibilité défini sur un seul périmètre, coûts d’egress limités aux flux entre hub et périphérie.
Inconvénients : dépendance forte au cloud principal — si Azure ou AWS a une panne dans votre région, l’ensemble du paysage ERP est affecté. Latence potentielle si des modules périphériques sont géographiquement distants.
Profil adapté : ETI avec un ERP dominant (SAP ou Oracle) et quelques modules complémentaires. C’est l’architecture recommandée pour une ETI qui part de zéro ou qui cherche à rationaliser un existant fragmenté.
Architecture 2 — Best-of-breed distribué (chaque fonction sur son cloud optimal)
Chaque domaine fonctionnel s’appuie sur la solution et le cloud qui lui convient le mieux : Oracle Fusion Finance sur OCI, Workday HR sur Azure, Salesforce CRM sur AWS, WMS Infor CloudSuite sur GCP. Pas de cloud central — chaque système est optimal dans son périmètre.
Avantages : chaque module peut être remplacé indépendamment sans migration globale. Résilience améliorée si les SLA de disponibilité sont contractuellement distincts.
Inconvénients : explosion des coûts d’intégration iPaaS (une plateforme d’intégration doit orchestrer N clouds), frais d’egress sur tous les flux inter-cloud, et complexité de monitoring — un incident qui touche deux clouds simultanément est très difficile à diagnostiquer. Le budget d’intégration dépasse régulièrement les prévisions initiales dans ce modèle, comme le détaille notre analyse des coûts cachés des intégrations ERP-SaaS.
Profil adapté : scale-ups tech avec une équipe IT mature, ou grandes entreprises dont chaque direction métier dispose d’un budget IT indépendant. Déconseillé en dessous de 500 collaborateurs : le coût de gouvernance est disproportionné.
Architecture 3 — Hybride coordonné (on-premise core + cloud périphérique)
Le coeur ERP reste sur site (souvent SAP ECC ou Oracle E-Business Suite encore sous contrat) tandis que les nouvelles fonctionnalités — BI, analytique, RH, CRM — sont déployées dans le cloud.
Avantages : les données les plus sensibles (financières, paie) ne quittent pas l’infrastructure maîtrisée. Les investissements on-premise existants continuent d’être amortis. Les coûts cloud sont limités aux périmètres applicatifs nouvellement ouverts.
Inconvénients : double maintenance (infrastructure on-premise + cloud), latence entre le coeur et les modules cloud, et une trajectoire de modernisation qui se complexifie : les mises à jour du coeur ERP on-premise sont découplées du rythme cloud, ce qui crée progressivement un écart fonctionnel.
Profil adapté : secteurs régulés (banque, défense, santé) avec des contraintes de localisation des données, ou ETI en phase de transition dont le contrat ERP on-premise court encore 3 à 5 ans.
Architecture 4 — Cloud souverain + hyperscaler (compliance + performance)
Cette architecture combine un hébergement souverain pour les données sensibles (conformité Cloud Act, RGPD, obligations sectorielles) avec un hyperscaler américain pour les workloads de performance ou d’IA.
Contexte : le Cloud Act américain (2018) donne aux autorités américaines accès aux données hébergées par toute société américaine, quelle que soit la localisation physique des serveurs. AWS, Azure, GCP et OCI sont des entités américaines — leurs datacenters européens n’échappent pas à cette juridiction. Pour les organisations dans le périmètre du décret SREN ou des secteurs régulés, héberger les données ERP les plus sensibles sur un cloud souverain qualifié devient une exigence.
Exemple de découpage : données financières et paie sur OVHcloud SecNumCloud ou S3NS, module analytique anonymisé sur Azure ou GCP pour bénéficier de Vertex AI ou Azure OpenAI.
Coût : le premium souverain est réel — des retours de DSI le situent généralement entre 15 et 30 % au-dessus d’un hébergement hyperscaler américain pur, en raison du coût des certifications et de l’écosystème de services managés plus limité.
Profil adapté : OES (opérateurs d’importance essentielle), établissements de santé, administrations publiques, ou ETI industrielles sous-traitantes de la BITD.
Comparatif des 4 hyperscalers pour ERP
| Hyperscaler | ERP privilégiés | Forces pour l’ERP | Points d’attention |
|---|---|---|---|
| AWS | SAP, Oracle EBS/JDE, Infor, Sage X3 | Écosystème intégrateur le plus dense, maturité HANA, géographie mondiale | Moins de synergies natives si stack Microsoft/SAP ; IAM distinct à fédérer |
| Azure | SAP S/4HANA, Dynamics 365, Workday | Partenariat SAP renforcé en 2026, intégration Copilot/Joule GA, SAP Datasphere sur Fabric | Coût licensing peut dépasser si l’ETI n’est pas dans l’écosystème Microsoft |
| GCP | Oracle, SAP BW, IFS | Analytique (BigQuery, Vertex AI), Workspace intégré | Moins de partenaires ERP que AWS/Azure ; moins mature pour workloads transactionnels purs |
| OCI | Oracle Fusion Cloud (natif et exclusif), SAP | Latence réduite pour Oracle Fusion, interconnexions certifiées vers Azure/AWS/GCP | Empreinte partenaire plus limitée ; moins adapté si l’ERP principal n’est pas Oracle |
Les clients Oracle Fusion bénéficient d’une latence réduite en restant sur OCI — Oracle optimise les performances de Fusion pour sa propre infrastructure. Les clients SAP trouveront dans Azure le partenariat le plus approfondi en 2026, avec des cas clients documentés comme Maersk (500 serveurs SAP et 1 pétaoctet de données migrés sur Azure en six mois avec une disponibilité quasi continue) ou KONE (54 000 contrats traités avec une réduction de 33 % du temps de traitement via SAP + Azure AI, selon Microsoft TechCommunity).
Gouvernance du multi-cloud ERP : les 4 piliers
Pilier 1 — iPaaS comme colonne vertébrale
Un paysage multi-cloud sans plateforme d’intégration centralisée produit inévitablement des flux point-à-point : 10 systèmes génèrent potentiellement 45 flux bilatéraux. Chaque nouveau SaaS ajoute N connexions.
Les options principales en 2026 sont MuleSoft (racheté par Salesforce, dominant dans les grandes entreprises), Dell Boomi (racheté par Francisco Partners, fort en mid-market), Azure Integration Services (natif Azure, recommandé si Azure est le hub), et SAP Integration Suite (recommandé si SAP est le coeur, avec des adaptateurs prébuilt pour plus de 400 systèmes).
Règle pratique : standardisez sur une seule iPaaS avant d’atteindre votre cinquième intégration. Après ce seuil, la dette d’intégration rend le changement de plateforme coûteux. Retrouvez l’analyse complète des postes de coûts cachés dans notre article sur les coûts d’intégration ERP-SaaS.
Pilier 2 — IAM fédéré cross-cloud
Chaque hyperscaler dispose de son propre système de gestion des identités et des accès : AWS IAM, Azure Entra ID, OCI IAM, GCP Identity. Sans fédération, les DSI gèrent autant de consoles d’administration et d’annuaires d’utilisateurs que de clouds.
La solution est la fédération d’identité via SAML 2.0 ou OIDC, avec un fournisseur d’identité central (IdP) : Okta, Microsoft Entra ID (si Azure est le hub), ou Ping Identity. Tous les clouds se connectent à cet IdP unique. Un utilisateur a une seule identité, une seule procédure de révocation en cas de départ.
Sans IAM fédéré, chaque utilisateur dispose d’identités multiples, les accès fantômes s’accumulent après les départs, et les audits de conformité deviennent des exercices manuels à haut risque.
Pilier 3 — FinOps ERP cloud
Selon Flexera, 29 % des dépenses cloud sont gaspillées en 2026 — en hausse pour la première fois depuis cinq ans. Les organisations qui gèrent plusieurs clouds sans gouvernance FinOps formalisée voient leurs factures augmenter sans que la valeur métier ne progresse proportionnellement. Les 63 % d’organisations ayant des équipes FinOps dédiées (Flexera 2026) contrôlent mieux ce phénomène.
En contexte multi-cloud, le FinOps est plus complexe qu’en mono-cloud : chaque hyperscaler a son propre modèle de tarification, ses propres mécanismes de réservation (Reserved Instances AWS, Azure Reservations, OCI Universal Credits), et ses propres outils de visualisation des coûts.
Pratiques essentielles : tagging systématique dès le premier déploiement (module ERP, entité, environnement), allocation des coûts par business unit, alertes de dépassement par cloud et par projet. Pour aller plus loin, notre article FinOps ERP détaille les leviers d’optimisation applicables aux stacks SAP, Oracle et Dynamics.
Pilier 4 — Data governance multi-cloud
Le risque sous-estimé du multi-cloud ERP est la perte de contrôle sur la localisation des données. Quand les données financières transitent entre un ERP SAP sur Azure et un module analytique sur GCP pour alimenter un dashboard Tableau hébergé sur AWS, combien de frontières nationales les données ont-elles traversées ? Sous quelle juridiction sont-elles en transit ?
La data governance multi-cloud repose sur trois actions concrètes : classification des données (sensibles, internes, publiques) avec des politiques de localisation associées, contrôle des flux inter-cloud via la plateforme iPaaS (chaque flux est documenté, chiffré, et auditable), et revue périodique des politiques de résidence des données au regard des évolutions réglementaires (NIS 2, SREN, DORA pour les services financiers).
Recommandations par profil d’ETI
Profil 1 : ETI industrielle sous SAP (500-3 000 collaborateurs)
Optez pour Azure comme hub principal. Le partenariat SAP-Microsoft en 2026 offre le meilleur niveau d’intégration native : SAP Joule et Microsoft Copilot sont en disponibilité générale depuis fin 2025, SAP Datasphere s’intègre directement dans Microsoft Fabric pour l’analytique avancée. Gardez Workday ou SuccessFactors sur Azure pour limiter les frais d’egress. Utilisez SAP Integration Suite pour les flux ERP-internes et Azure Integration Services pour les flux vers les partenaires externes. Architecture cible : hub-and-spoke avec Azure comme hub.
Profil 2 : ETI de services sous Oracle Fusion Cloud et Salesforce
Oracle Fusion est sur OCI — vous n’avez pas le choix du cloud pour votre coeur financier. Salesforce héberge ses services principalement sur AWS et GCP. La connexion entre les deux passe par MuleSoft (que vous avez probablement déjà dans votre licence Salesforce) ou Oracle Integration Cloud. Monitorez de près les frais d’egress OCI vers AWS/GCP pour les synchronisations données en temps réel — ils peuvent représenter une part significative de votre facture inter-cloud. Architecture cible : best-of-breed avec Oracle Integration Cloud comme pont central.
Profil 3 : ETI multi-pays en croissance rapide
Le risque majeur dans ce profil est l’absence de standard architectural dès les premières acquisitions. Chaque nouvelle entité amène son ERP local et son cloud de prédilection. La gouvernance décentralisée coûte exponentiellement plus cher à mesure que le groupe grandit.
La recommandation est de définir un « blueprint » standard avant l’acquisition de la cinquième entité : cloud principal approuvé, iPaaS de groupe obligatoire pour tous les flux inter-systèmes, et politique de tags FinOps commune. Imposer ces standards à chaque nouvelle entité lors de l’intégration est plus rentable que de les harmoniser après coup. Architecture cible : hub-and-spoke imposé dès le départ, même si le hub initial est modeste.
Pour aller plus loin, trois articles pour approfondir les sujets connexes : notre analyse des coûts cachés des intégrations ERP-SaaS et iPaaS, notre guide sur le cloud de confiance et SecNumCloud pour les DSI en France, et notre analyse de l’architecture ERP microservices, monolithique ou composable pour les choix d’architecture applicative au-delà du seul hébergement cloud.
