L'accélération de la stratégie multicloud d'Oracle : implications sectorielles de l'interconnexion intercloud GA, de la base de données Exascale et de l'expansion régionale

Oracle accélère sa stratégie multicloud : interconnexion intercloud en GA, bases de données Exascale et expansion régionale — implications pour le secteur

Introduction

De mai à août 2026, Oracle a dévoilé successivement sur son blog officiel consacré au multicloud une série d’avancées : Oracle Interconnect for AWS est passé d’une disponibilité limitée à une disponibilité générale (GA), Oracle AI Database@AWS et Oracle AI Database@Google Cloud ont respectivement introduit l’infrastructure Exascale et les capacités de stockage Exadata Exascale, tandis que la couverture régionale s’est étendue à 22 régions à l’échelle mondiale. Ces mises à jour, en apparence disparates, renvoient en réalité à une même question : lorsque les charges de travail des entreprises sont naturellement réparties sur plusieurs clouds, les actifs de bases de données, considérés comme les plus difficiles à migrer, peuvent-ils fonctionner d’un cloud à l’autre sans réarchitecturer les applications ? Pour les CTO et les architectes cloud, cela touche directement à la structure de coûts des réseaux intercloud, aux modèles de déploiement des bases de données, ainsi qu’aux modalités de mise en œuvre de la résidence des données et de la continuité d’activité.

I. Contexte : une progression concentrée sur trois mois

La logique centrale du multicloud Oracle n’a rien de complexe : faire tourner les services Oracle Database sur une infrastructure OCI déployée à proximité d’autres régions cloud, et les fournir aux clients via une chaîne d’outils familière et une facturation consolidée. Cette série d’annonces de l’été 2026 marque l’expansion simultanée de cette approche sur les plans des capacités et de la couverture géographique.| Date | Événement | Points clés | | --- | --- | --- | | 15 mai | Oracle Interconnect for AWS en disponibilité limitée | Annoncé par Nathan Thomas, vice-président senior de la gestion des produits OCI, vise à remplacer les réseaux multicloud construits par les clients par une connexion managée | | 20 mai | OCI GoldenGate en GA sur Oracle AI Database@Google Cloud | Peut être activé directement dans la console Google Cloud et payé avec les remises pour engagement Google Cloud | | 20 mai | Oracle AI Database@AWS s’implante à São Paulo | Couvre le marché sud-américain, avec initialement une zone de disponibilité | | 17 juin | Premier anniversaire du lancement d’Oracle AI Database@AWS | Annonce d’Autonomous AI Database Serverless en GA, de l’arrivée imminente de l’infrastructure Exascale, de l’extension à 20 régions AWS, du niveau MAA Platinum et d’un accord de collaboration stratégique à long terme (SCA) | | 23 juin | Ajout de Stockholm et San José | Le nombre total de régions dans le monde atteint 22 | | 29 juillet | Oracle Interconnect for AWS en disponibilité générale | Premier déploiement dans OCI Ashburn et AWS USA Est (Virginie du Nord), d’autres paires de régions seront proposées ultérieurement | | 12 août | ExaDB-XS disponible sur Oracle AI Database@AWS | Facturation selon les ECPU et l’usage de stockage, réduction du coût d’entrée, vente via AWS Marketplace | | 14 août | Exadata Exascale arrive dans Oracle AI Database@Google Cloud | Les clients peuvent provisionner des clusters de VM Exadata avec du stockage Exascale |

Il est à noter que cette vague d’annonces se concentre sur AWS et Google Cloud. Ce rythme, qui consiste d’abord à s’associer étroitement avec certains fournisseurs de cloud à très grande échelle, montre que la stratégie multicloud d’Oracle relève davantage d’une duplication de capacités que d’un déploiement généralisé.

II. Analyse technique : à quels problèmes répondent respectivement ces trois éléments ?

1. Interconnexion multicloud : transformer le réseau d’un projet en serviceAu début du multicloud, il existait principalement deux façons de connecter deux clouds : faire transiter le trafic par l’Internet public ou établir soi-même un tunnel chiffré. La première présente une surface d’exposition notable en matière de sécurité, de disponibilité et de capacité ; la seconde, bien qu’elle exclue l’Internet public, reporte entièrement sur le client la charge de l’approvisionnement, de la configuration et de la gestion des capacités. En pratique, les entreprises doivent aussi coordonner simultanément deux modèles de routage qui n’ont pas été conçus l’un pour l’autre, gérer des contrats avec des tiers des deux côtés, et mettre en place un réseau construit en propre avant même de commencer réellement leurs activités.

Oracle Interconnect for AWS vise précisément à transformer cette couche. Il fournit une connexion privée, à haut débit et entièrement managée entre OCI et AWS, utilise par défaut le chiffrement IEEE 802.1AE MACsec, repose sur une tarification de connexion OCI unifiée et cohérente à l’échelle mondiale, ne facture aucun frais de transfert de données, et bénéficie d’un support conjoint d’Oracle et d’AWS. En termes non techniques : cela équivaut à construire entre deux campus une autoroute dédiée, exploitée conjointement par les deux parties, l’entreprise n’ayant plus besoin de poser elle-même la route, d’acheter le terrain ou d’entretenir la chaussée.

2. Exascale : découpler le calcul et le stockage, abaisser la barrière à l’entrée d’Exadata

L’Exadata traditionnel ressemble davantage à un équipement intégré : le calcul et le stockage sont mis à l’échelle conjointement selon un ratio fixe, et la moindre erreur de planification de capacité entraîne soit du gaspillage, soit des contraintes. Le changement clé d’Exascale consiste à dissocier les deux.

Du côté AWS, ExaDB-XS repose sur le modèle de cloud élastique multilocataire d’Oracle : les clients peuvent démarrer avec un petit cluster de VM, faire évoluer indépendamment le calcul et le stockage, ne payer que les ECPU et le stockage réellement utilisés, tout en prenant en charge Oracle Database 19c et Oracle AI Database 26ai, et en offrant des capacités de thin clone ainsi que de snapshot et de clonage basées sur redirect-on-write. Du côté Google Cloud, les clients peuvent quant à eux provisionner un cluster Exadata VM avec stockage Exascale, faire évoluer le stockage de manière flexible à mesure que les besoins de la base de données augmentent, tout en conservant les caractéristiques de performance, de disponibilité et de fiabilité de l’Exadata dédié.

Pour les responsables, l’essence de ce changement est une transformation de la logique d’achat : passer d’un achat unique d’une capacité suffisante à un paiement à l’usage et à une extension en fonction de la croissance, la composante d’investissement (Capex) étant davantage transférée vers les dépenses d’exploitation (Opex).

3. OCI GoldenGate : le plan de données dans les scénarios multicloud

Pour exécuter des bases de données intercloud, impossible de faire l'impasse sur la synchronisation des données. Depuis la disponibilité générale d'OCI GoldenGate sur Google Cloud, les clients peuvent souscrire à ce service managé directement depuis la console Google Cloud et payer au moyen d'engagements Google Cloud. Il offre la capture de données modifiées (CDC) à faible latence et la réplication en temps réel, pour prendre en charge les migrations de bases de données à faible risque, les architectures hybrides et multicloud, l'amélioration de la disponibilité, ainsi que l'analyse quasi temps réel sur des sources de données Oracle et non Oracle.

La CDC peut être comprise comme un journal des modifications mis à jour en continu : chaque modification de données dans la base source est capturée et synchronisée vers la cible, plutôt que d'attendre une fenêtre de traitement par lots pour un transfert groupé. Cela permet aux charges de travail opérationnelles, analytiques et d'IA de s'appuyer sur des données synchronisées en continu.

III. Analyse de l'impact sur les entreprises

Structure de coûts. ExaDB-XS est facturé selon les ECPU et l'utilisation du stockage, ce qui abaisse directement le seuil d'essai et de démarrage d'Exadata ; la mise à l'échelle indépendante d'Exascale réduit le gaspillage lié à la réservation de capacité pour les pics. Interconnect applique une tarification de connexion unifiée et ne facture pas les transferts de données, ce qui rapproche les dépenses réseau intercloud d'un poste fixe prévisible. Il convient toutefois de rappeler que le coût total intercloud doit encore être évalué globalement en tenant compte des règles de facturation des deux côtés ; le réseau n'en est qu'un élément.

Modèle de déploiement. Pour les clients Oracle qui exécutent déjà des applications sur AWS, l'absence de refonte est le principal argument de cette série de mises à jour : les services de base de données s'exécutent sur l'infrastructure OCI, mais sont déployés à proximité des applications AWS. Les migrations par étapes, les architectures applicatives distribuées et la réduction de la dépendance à l'Internet public sont des cas d'usage directement applicables.

Exploitation et support. La facturation consolidée, la réutilisation de la chaîne d'outils existante et l'interface de support coordonné entre Oracle et AWS réduisent les frictions organisationnelles des équipes intercloud. Mais la complexité de l'exploitation multicloud ne disparaît pas pour autant : elle se déplace simplement de la gestion des réseaux auto-construits et des contrats vers l'identité fédérée, la supervision et la localisation des pannes.

Sécurité et conformité. Le chiffrement MACsec par défaut et les liaisons privées réduisent la surface d'exposition à l'Internet public. L'expansion régionale est une réponse directe aux enjeux de conformité : Stockholm sert les besoins de résidence des données des marchés nordiques et européens, San José est proche des pôles technologiques et commerciaux de l'Ouest américain, et São Paulo couvre le marché sud-américain. Pour les secteurs réglementés, ce type de choix de région a souvent plus de poids dans la décision que les indicateurs de performance.

IV. Analyse de la concurrence sur le marchéDu point de vue du paysage concurrentiel, la principale caractéristique de cette série de mises à jour est la concurrence par positionnement différencié. Oracle n'a pas affronté frontalement les hyperscalers sur la couche IaaS pour le calcul générique ; il traite plutôt la base de données comme un produit livré de manière multicloud, laissant AWS et Google Cloud capter davantage de charges de travail tandis qu'Oracle capte la consommation liée aux bases de données. Il s'agit plutôt d'une alliance de complémentarité : l'accord de coopération stratégique à long terme (SCA) annoncé par les deux parties le 17 juin a encore renforcé cette relation. Selon les informations officielles, un an après son lancement, Oracle AI Database@AWS comptait déjà des centaines de clients exécutant des charges de travail critiques sur cette offre.

Les parties susceptibles d'en bénéficier comprennent : les clients entreprises possédant d'importants actifs de bases de données Oracle, mais souhaitant conserver leurs applications sur d'autres clouds ; AWS et Google Cloud, car ils hébergent davantage de bases de données d'entreprise et de charges de travail d'IA ; ainsi que les canaux et intégrateurs qui opèrent autour d'AWS Marketplace et des engagements de dépenses de Google Cloud.

Les parties susceptibles de subir des pressions comprennent : les fournisseurs tiers spécialisés dans les liaisons dédiées intercloud construites en propre et l'hébergement réseau, dont la proposition de valeur est diluée par la connectivité managée et une tarification unifiée ; ainsi que le discours selon lequel les bases de données métier doivent être entièrement réécrites en bases de données cloud natives — la prise en charge des deux versions Exascale et 19c/26ai permet à davantage d'entreprises de choisir une trajectoire progressive consistant à migrer d'abord, puis à moderniser. En conséquence, les fournisseurs de bases de données cloud natives feront face à une résistance accrue au remplacement lorsqu'ils chercheront à attirer les charges de travail Oracle existantes.

V. Observations des tendances du secteur

Le point focal de la concurrence dans le multicloud passe de la connectivité au plan de données. Ces dernières années, les problèmes d'ingénierie du multicloud concernaient principalement l'interconnexion réseau ; or des capacités telles qu'Exascale, GoldenGate ou la recherche vectorielle IA native montrent que la prochaine phase de concurrence portera sur la manière dont les données circulent entre les clouds et dont elles sont utilisées par l'IA.

La direction de la gravité des données s'inverse. L'approche traditionnelle consistait à déplacer les applications à côté des données ; aujourd'hui, on déplace les services de base de données à côté des applications — la base de données s'exécute sur l'infrastructure OCI, mais est déployée à proximité des régions AWS ou Google Cloud. Ce modèle de « cloud dans le cloud » pourrait devenir la trajectoire de migration par défaut des systèmes hérités d'entreprise.

La souveraineté et la régionalisation deviennent des caractéristiques produit. L'ouverture successive des régions de Stockholm, São Paulo et San José montre que la couverture régionale n'est plus seulement une optimisation de la latence, mais une infrastructure de conformité pour la résidence des données et la continuité d'activité.

La frontière entre l'IA et les bases de données continue de s'estomper. Du nommage des produits à la combinaison de capacités (Autonomous AI Lakehouse, recherche vectorielle IA native, version 26ai), Oracle intègre nativement les capacités d'IA dans la couche base de données, plutôt que de laisser les entreprises bâtir en dehors de la base de données un ensemble distinct de recherche vectorielle et de plateforme de caractéristiques.Ces changements convergent vers une conclusion : le multicloud est en train de passer d’un choix d’architecture réseau à un choix d’architecture de données ; au cours des cinq prochaines années, la concurrence en matière d’infrastructure cloud tournera davantage autour de la portabilité des services de données.

CloudTechDaily Insight

Ce qui mérite le plus d’être retenu dans cette série d’annonces n’est pas telle ou telle fonctionnalité, mais le fait que l’unité de mesure de la concurrence multicloud est en train de changer. Par le passé, lorsqu’une entreprise évaluait le multicloud, elle regardait la bande passante des liaisons dédiées, le trafic sortant et la main-d’œuvre d’exploitation ; aujourd’hui, ce qui est mis sur la table, c’est le coût d’entrée de la base de données (facturation en ECPU et stockage), le mode de tarification de la connectivité inter-cloud (tarification unifiée de la connexion, sans frais de transfert de données), ainsi que la capacité des données à être consommées par l’IA sur place. Lorsque ces éléments sont transformés en produits, la décision multicloud passe d’une question de faisabilité technique à une question calculable sur les plans financier et de conformité.

Pour la stratégie IT des entreprises, trois points méritent d’être intégrés à l’évaluation. Premièrement, la base de données inter-cloud n’est plus le point d’arrivée d’un projet de migration, mais peut devenir un état de fonctionnement de long terme ; les critères des revues d’architecture doivent être ajustés en conséquence. Deuxièmement, une fois la couche de connectivité gérée comme un service managé, la prévisibilité des coûts inter-cloud augmente, mais la dépendance s’accroît également — les clients doivent évaluer leur degré de dépendance à une relation de collaboration de long terme entre les deux acteurs et à des processus de support conjoint. Troisièmement, l’expansion régionale apporte des options de conformité plutôt qu’un simple gain de performance ; les secteurs réglementés devraient intégrer la liste des régions dans leur planification de la résidence des données et de la continuité.

Il faut reconnaître que ce modèle dépend encore de la volonté de coopération et de la feuille de route produit des hyperscalers. Les annonces de ce cycle se concentrent sur AWS et Google Cloud, et leur couverture reste incomplète ; la performance réelle du support conjoint en matière de localisation des pannes et de répartition des responsabilités nécessite également davantage de validation en environnement de production. Une approche plus pragmatique consiste donc à : valider, avec un petit cluster ExaDB-XS, les performances et l’expérience d’exploitation des bases de données métier critiques dans un environnement inter-cloud ; remplacer les liaisons inter-cloud publiques existantes ou les liens auto-construits par un pilote Interconnect ; et, avant de passer à l’échelle, effectuer une double vérification du modèle de coûts et de la résidence des données.

À moyen et long terme, la base de données en tant que service inter-cloud pourrait bien, comme la base de données managée en son temps, passer du cas particulier à la configuration par défaut du secteur. Une fois que les principaux éditeurs de bases de données auront franchi cette étape, la pression pour que les autres entreprises et fournisseurs de cloud emboîtent le pas se manifestera rapidement — c’est là l’impact le plus profond de cet événement sur l’industrie du cloud computing.

---

Source de référence : blog officiel d’Oracle « Oracle Multicloud – What's News », https://blogs.oracle.com/cloud-infrastructure/oracle-multicloud-whats-new-blog