Résumé
- Oracle doit être jugé sur les charges de travail d'entreprise acceptées, et non sur le prestige de ses bases de données, les gros titres sur la croissance du cloud ou les seules annonces d'infrastructure d'IA.
- L'entreprise possède une profondeur technique crédible dans l'état des bases de données, Exadata, les opérations de base de données autonomes, la reprise, le déploiement hybride, le placement multicloud et les applications d'entreprise, mais ces capacités ne comptent que lorsque les clients font la preuve de la migration, du basculement, de la correction, de l'identité, des coûts et des routines de support dans leurs propres environnements.
- Les données de l'exercice 2026 montrent une entreprise qui pivote fortement vers l'infrastructure cloud: le chiffre d'affaires total a atteint 67,4 milliards de dollars, le chiffre d'affaires cloud 34,0 milliards, le chiffre d'affaires de l'infrastructure cloud a augmenté de 77 % sur l'année, les obligations de performance restantes ont atteint 638 milliards de dollars, et le flux de trésorerie disponible était négatif de 23,7 milliards de dollars tandis qu'Oracle finançait un important déploiement d'infrastructure d'IA.
- La proposition de valeur d'Oracle est la plus forte pour les organisations qui exploitent déjà des environnements Oracle Database, Exadata, les applications Fusion, E-Business Suite, PeopleSoft, JD Edwards, Siebel ou MySQL et qui peuvent réduire le travail de replateformage et consolider les opérations; elle est plus faible lorsque la complexité des licences, la dépendance aux compétences, les contraintes de capacité, la dette d'intégration ou l'économie des engagements cloud l'emportent sur le gain opérationnel.
- Le bon verdict est conditionnel: Oracle peut être une plateforme fiable pour les états d'entreprise de longue durée, mais seulement si l'acheteur traite la migration, la supervision, le support, la résilience et l'économie de sortie comme faisant partie de la charge de travail plutôt que comme des réflexions après coup.
La bonne question est de savoir si la charge de travail est acceptée
Oracle est facile à mal interpréter car il contient plusieurs entreprises sous un même nom. C'est une société de bases de données avec une base installée profonde. C'est un éditeur d'applications d'entreprise avec des produits financiers, de ressources humaines, de chaîne d'approvisionnement, d'expérience client et sectoriels. C'est aussi un fournisseur d'infrastructure cloud qui construit des régions, des options de cloud distribué, des services Exadata et du calcul IA. C'est également une entreprise de licences, de support et de services dont les contrats peuvent compter autant que son ingénierie.
Toute évaluation utile doit garder ces identités ensemble sans laisser l'une d'entre elles représenter l'ensemble.
La mauvaise question est de savoir si Oracle possède une technologie impressionnante. C'est le cas. Oracle Database a des décennies d'utilisation critique. Exadata est construit autour de calcul, stockage, réseau et logiciels de base de données étroitement intégrés. La base de données autonome AI Database automatise de nombreuses opérations qui nécessitaient auparavant du personnel spécialisé. Oracle Cloud Infrastructure propose du calcul, du stockage, du réseau, de la gestion des identités, de la surveillance, des services de base de données, des options de cloud distribué et une infrastructure d'IA.
Les applications Fusion placent les processus métier sur une suite applicative et un modèle de données communs. Ce sont de réelles capacités.
Mais la valeur d'entreprise n'est pas créée lorsqu'une fonctionnalité existe. Elle est créée lorsqu'une charge de travail atteint un état accepté. Pour une migration de base de données, cela signifie que le comportement de l'application est correct, que les performances sont dans la plage convenue, que les fenêtres de perte de données et de reprise sont comprises, que la sauvegarde et la restauration ont été testées, que les contrôles d'identité et de réseau sont en place, que l'observabilité atteint les bonnes équipes, que les licences sont documentées et que l'équipe financière peut expliquer la facture.
Pour le déplacement d'une application d'entreprise, cela signifie que les approbations, les rapports, les intégrations et les files d'exceptions fonctionnent après le premier lancement. Pour l'infrastructure d'IA, cela signifie que la capacité est effectivement disponible, que les charges de travail peuvent fonctionner avec l'économie prévue et que le support peut gérer les pannes à grande échelle.
Cette distinction est importante car l'histoire publique d'Oracle en 2026 est dominée par la croissance de l'infrastructure cloud et la demande d'IA. Oracle a annoncé un chiffre d'affaires total de 67,4 milliards de dollars pour l'exercice 2026 et un chiffre d'affaires cloud de 34,0 milliards. Son chiffre d'affaires d'infrastructure cloud a augmenté de 77 % sur l'année et, rien qu'au quatrième trimestre, Oracle a enregistré 5,8 milliards de dollars de chiffre d'affaires d'infrastructure cloud, soit une hausse de 93 %.
Les obligations de performance restantes ont atteint 638 milliards de dollars, et Oracle a déclaré que les grands contrats d'IA représentaient la majeure partie de la récente augmentation. Ces chiffres montrent une demande et une dynamique stratégique. Ils ne prouvent pas que la migration de base de données, le plan de reprise après sinistre, le modèle de support ou l'analyse de coûts de chaque client fonctionnent.
Pour les acheteurs, le test est délibérément pratique. Oracle peut-il maintenir la fiabilité des états des bases de données et des charges de travail cloud à travers les migrations, les environnements hybrides, la demande d'infrastructure d'IA et les contrôles d'entreprise de longue durée? L'entreprise peut-elle accepter le résultat après avoir inclus la supervision, l'intégration, la maintenance, la revue, la gestion des exceptions, la restauration et l'économie unitaire? Si la réponse est oui, la force ancienne d'Oracle dans les états d'entreprise et ses investissements récents dans le cloud se renforcent mutuellement.
Si la réponse est non, l'histoire du cloud devient une couche de complexité supplémentaire au-dessus d'un parc déjà coûteux.
Le centre de gravité d'Oracle est passé du parc de licences à l'état opérationnel
Le rapport annuel d'Oracle pour l'exercice 2026 décrit des produits et services qui créent, exécutent et soutiennent des cadres de technologie de l'information d'entreprise à travers des modèles de déploiement cloud, sur site, hybrides et multicloud. Cette formulation est importante. L'entreprise ne se contente pas de vendre des licences de base de données en boîte pour les centres de données des clients.
Elle cherche à opérer une plus grande partie de l'état que les clients géraient auparavant eux-mêmes, tout en préservant suffisamment de compatibilité pour que la migration à partir d'anciens parcs Oracle semble plus sûre qu'un changement complet de plateforme.
La composition financière confirme ce changement. Oracle a déclaré que le chiffre d'affaires cloud représentait 51 % du chiffre d'affaires total sur l'exercice 2026, contre 43 % sur l'exercice 2025 et 37 % sur l'exercice 2024. L'entreprise a également indiqué que l'infrastructure cloud représentait 53 % du chiffre d'affaires cloud total sur l'exercice 2026, tandis que les applications cloud en représentaient 47 %. Il s'agit d'un changement significatif pour une entreprise longtemps associée aux licences de logiciels applicatifs et de bases de données. L'infrastructure cloud n'est plus une histoire secondaire.
Elle devient un moteur de revenus central.
L'attrait stratégique est évident. Oracle peut dire à un client existant de base de données qu'il n'a pas besoin de tout réécrire pour évoluer vers un modèle opérationnel géré. Il peut exécuter Oracle Database sur OCI, Exadata Cloud@Customer, Autonomous AI Database, Oracle AI Database@Azure, Oracle AI Database@Google Cloud ou Oracle Database@AWS. Il peut placer des services de base de données dans les centres de données des clients, dans des régions Oracle ou dans d'autres environnements hyperscale. Il peut connecter ces bases de données aux applications Fusion, à l'analytique, aux services de reprise et à l'infrastructure d'IA.
Pour les clients disposant de grands parcs Oracle, il s'agit d'une proposition sérieuse car elle réduit la crainte que la modernisation nécessite l'abandon de décennies de logique métier.
La même logique crée une pression à l'enfermement. Si une entreprise déplace l'état de ses bases de données, ses processus applicatifs, ses opérations de reprise, ses services d'IA, ses schémas d'identité et ses relations de support plus profondément dans le modèle cloud d'Oracle, le problème de changement s'accroît. Un client peut gagner en efficacité opérationnelle tout en augmentant sa dépendance aux prix, à la capacité, à la qualité du support, à la feuille de route des produits et aux conditions contractuelles d'Oracle.
Cette situation n'est pas propre à Oracle; toute plateforme d'entreprise essaie de devenir plus difficile à quitter à mesure qu'elle devient plus utile. Mais Oracle part d'une base particulièrement solide car de nombreux clients exploitent déjà des systèmes critiques sur Oracle Database, des applications Oracle ou des contrats de support associés.
C'est pourquoi la charge de travail acceptée est une meilleure unité d'analyse que le parc logiciel. Un parc de licences peut sembler rationnel sur un tableur tout en produisant des frictions opérationnelles. Une migration cloud peut sembler moderne tout en maintenant le client lié à d'anciens modèles de données, à d'anciennes compétences et à d'anciennes approbations. Une base de données gérée peut réduire la pénibilité des administrateurs tout en exigeant un contrôle prudent du réseau, de l'identité, de la reprise et des coûts. La question n'est pas de savoir si Oracle peut absorber davantage de la pile d'entreprise. Il le peut.
La question est de savoir si chaque charge de travail absorbée devient plus facile à exécuter, plus facile à récupérer, plus facile à auditer et plus facile à justifier dans le temps.
La fiabilité des bases de données est une chaîne, pas un slogan
L'atout le plus durable d'Oracle est la confiance dans l'état des bases de données. Cette confiance n'est pas venue d'une seule fonctionnalité. Elle est venue d'une chaîne de capacités autour du traitement transactionnel, de la concurrence, de la reprise, de la sécurité, de la réplication, de l'optimisation des performances, de la haute disponibilité, du support et des compétences accumulées des administrateurs de bases de données et des équipes applicatives.
L'offre actuelle de base de données cloud d'Oracle repose sur le déplacement de cette chaîne dans des environnements gérés et hybrides sans casser les éléments sur lesquels les clients comptent.
La surface produit publique est large. Autonomous AI Database est présentée comme une base de données gérée avec provisionnement, surveillance, sauvegardes, audit, optimisation, correction, mise à l'échelle, reprise après sinistre et contrôles de sécurité automatisés. Oracle affirme bénéficier d'un niveau de service de disponibilité de 99,95 % sans activer la reprise après sinistre et peut atteindre une disponibilité de 99,995 % avec Autonomous Data Guard.
Oracle présente également Exadata Cloud@Customer comme un moyen d'apporter les performances d'Exadata et des opérations cloud gérées dans les centres de données des clients, tout en répondant aux préoccupations de résidence des données, de sécurité et de latence. La documentation d'Exadata Cloud@Customer décrit la mise à l'échelle en ligne, Oracle RAC, l'accès à l'architecture de disponibilité maximale, la consolidation de bases de données autonomes et non autonomes, ainsi que des affirmations de performances transactionnelles et analytiques très élevées pour les systèmes actuels.
Ces affirmations ont du sens pour la base installée d'Oracle. De nombreux systèmes d'entreprise ne sont pas des services web sans état qui peuvent être facilement reconstruits sur n'importe quel cloud. Ils transportent des années de procédures stockées, de dépendances applicatives packagées, de routines de reporting, de contrôles de conformité, d'interfaces et d'habitudes opérationnelles. Un déplacement de base de données qui préserve la compatibilité Oracle peut être beaucoup moins risqué qu'une réécriture complète.
C'est particulièrement vrai pour les clients qui ont besoin d'une forte cohérence transactionnelle, d'une longue rétention, de rapports complexes, d'un placement de données réglementé ou d'une intégration étroite avec les applications Oracle existantes.
La fiabilité reste cependant une chaîne. La documentation Data Guard indique clairement que la haute disponibilité et la reprise après sinistre dépendent des bases de données primaires et de secours, des modes de protection, du transport de redo, du basculement planifié, du basculement d'urgence, de la préparation de la base de secours, du débit réseau et des choix de configuration. Un basculement planifié peut être utilisé pour éviter la perte de données lors d'une maintenance planifiée, mais un basculement d'urgence peut entraîner une perte de données dans certains modes de protection.
Oracle recommande fortement de placer les bases primaires et de secours sur des infrastructures Exadata Cloud différentes pour une meilleure isolation et protection. La documentation indique également que, comme Oracle ne possède pas le réseau entre certains clusters, les clients doivent évaluer le débit avant la mise en œuvre.
C'est le bon niveau de détail. Cela montre qu'Oracle dispose de mécanismes de fiabilité matures, mais aussi que les clients doivent les concevoir et les tester. Acheter Data Guard n'est pas la même chose qu'avoir un basculement d'urgence réussi. S'abonner à une base de données gérée n'est pas la même chose que valider l'application après le basculement. Fonctionner sur Exadata n'est pas la même chose que savoir quel mode de protection correspond au risque métier.
Un système de paiement bancaire, une application de planification hospitalière ou une base de données de facturation télécom a besoin de preuves que toute la chaîne fonctionne: réseau, stockage, calcul, version de base de données, chaînes de connexion client, rôles de basculement, surveillance, escalade de support et procédure de reprise orientée utilisateur.
Le service de reprise autonome Zero Data Loss Recovery Service d'Oracle étend le même argument. Il est conçu pour protéger les modifications de base de données en temps réel, valider les sauvegardes loin des serveurs de production et prendre en charge la reprise à un point dans le temps pour les bases de données OCI, AWS, Azure, Google Cloud et sur site. La capacité est significative car la sauvegarde et la reprise échouent souvent au moment précis où elles sont nécessaires. Mais même ici, la charge de travail acceptée nécessite plus qu'un abonnement à un produit.
Les clients doivent savoir quelles bases de données sont protégées, quelles politiques de rétention s'appliquent, qui peut supprimer ou modifier la politique de sauvegarde, comment se comporte la rétention immuable, si la reprise est testée, comment les applications se reconnectent, et si les auditeurs peuvent comprendre les preuves.
La valeur de la base de données d'Oracle est donc la plus forte lorsque les acheteurs traitent la fiabilité comme une preuve opérationnelle. Un pilote utile n'est pas une requête de démonstration. C'est une charge de travail migrée qui peut survivre à la correction, au basculement, à la restauration, à l'erreur utilisateur, au changement d'identité, au pic de charge de travail et à l'examen de la facturation. C'est là qu'Oracle peut gagner. C'est aussi là qu'une planification faible peut transformer une solide machinerie de base de données en un résultat décevant.
La migration n'est acceptée qu'après validation, retour en arrière et appropriation
L'argumentaire de migration d'Oracle est pragmatique: déplacez les charges de travail existantes avec un minimum de changements lorsque c'est possible, puis modernisez de manière sélective. Ses supports de migration couvrent les charges de travail personnalisées, open source, tierces et Oracle, avec une planification, une préparation, une exécution et une validation comme étapes explicites.
Pour les migrations de bases de données, Oracle dit fournir des stratégies en ligne et hors ligne, des conseillers de planification, une automatisation et des guides étape par étape pour passer de toute version, plateforme et système d'exploitation vers les services de base de données OCI, y compris Exadata, Cloud@Customer et Autonomous.
Cette approche correspond à la réalité des grandes entreprises. Une entreprise avec une implémentation Oracle E-Business Suite, un environnement PeopleSoft, une application Java personnalisée sur Oracle Database ou un parc Exadata peut ne pas vouloir une réécriture héroïque. Elle peut vouloir réduire la charge du centre de données, améliorer la posture de sauvegarde, accroître la flexibilité de capacité, améliorer l'intégration avec l'analytique cloud ou ouvrir une voie vers des services compatibles IA tout en préservant la logique applicative.
Oracle peut soutenir de manière crédible qu'un chemin cloud compatible réduit le risque de nouveaux bogues introduits par le replateformage.
La compatibilité peut cependant être confondue avec la simplicité. Une base de données peut migrer sans réécriture de schéma et échouer quand même à l'acceptation parce que les fenêtres de traitement par lots changent, la latence réseau affecte le comportement de l'application, les rapports dépendent d'hypothèses de stockage héritées, les intégrations d'identité sont incomplètes, les fenêtres de sauvegarde entrent en collision avec les périodes de clôture, ou les hypothèses de licence changent. Le hub de migration d'Oracle lui-même pointe la validation comme faisant partie du parcours. Ce n'est pas une formalité.
C'est la différence entre une charge de travail déplacée et une charge de travail de confiance.
Le responsable de la migration doit répondre à plusieurs questions avant de déclarer le succès du déplacement. Quelle transaction métier prouve que la charge de travail fonctionne? Quelle réconciliation prouve l'intégrité des données? Quel benchmark représente la performance normale et de pointe? Quel événement de basculement sera testé avant la mise en production? Quelle voie de retour en arrière existe si le nouvel environnement ne peut pas exécuter la charge de travail? Quel chemin de support prend en charge un problème qui traverse le code applicatif, la configuration de base de données, le réseau cloud et l'identité du client?
Quel centre de coûts voit la consommation cloud? Quel ancien système peut réellement être mis hors service?
Ces questions sont importantes car les forces d'Oracle peuvent également masquer les risques. Si l'outillage Oracle rend le déplacement familier, un client peut sous-estimer le travail de nettoyage des anciennes hypothèses. Si l'environnement cloud peut évoluer, un client peut reporter la gouvernance des coûts. Si les services gérés réduisent le travail de correction, un client peut réduire l'expertise en base de données trop tôt. Si les contrats de support restent en place, un client peut supposer que l'appropriation des problèmes est plus simple qu'elle ne l'est.
La qualité de la migration se prouve dans le passage de relais entre l'automatisation du fournisseur et la responsabilité du client.
Les meilleures migrations Oracle ne sont donc pas celles avec le diagramme d'architecture le plus dramatique. Ce sont celles avec des preuves ennuyeuses: des tests, des lignes de base de charge de travail, des exercices de reprise, des validations des propriétaires d'applications, des intégrations vérifiées, une position de licence documentée, des limites de coûts, des manuels de support et des composants hérités mis hors service. La valeur n'est pas que la charge de travail ait été déplacée vers OCI ou Exadata Cloud@Customer.
La valeur est que l'entreprise peut exploiter la charge de travail après le déplacement avec moins d'incertitude qu'avant.
Les opérations autonomes réduisent la pénibilité mais ne suppriment pas la responsabilité
L'histoire de la base de données autonome d'Oracle est convaincante car l'administration de base de données contient une grande quantité de travail répétitif et de haute compétence. Le provisionnement, la correction, l'optimisation, la mise à l'échelle, la surveillance, la sauvegarde, la reprise, l'audit et l'examen de sécurité consomment des personnes rares.
Si Oracle peut automatiser une plus grande partie de ce travail routinier dans le service de base de données, les clients peuvent réduire les erreurs humaines, accélérer les environnements de développement, standardiser les opérations et rediriger le personnel vers des tâches à plus forte valeur.
Les supports publics soutiennent cette orientation. Oracle affirme que l'Autonomous AI Database peut automatiser les tâches du cycle de vie des bases de données, utiliser l'apprentissage automatique pour l'optimisation et le diagnostic, appliquer des correctifs sans temps d'arrêt ni intervention humaine, maintenir l'audit activé, automatiser les sauvegardes et fournir des contrôles de sécurité intégrés tels que le chiffrement, le masquage, la rédaction et l'accès basé sur les rôles.
Oracle lie également la base de données à la recherche vectorielle IA et à l'apprentissage automatique en base de données, soutenant que les clients peuvent rapprocher l'IA des données d'entreprise gouvernées au lieu de déplacer les données dans des systèmes séparés.
Il s'agit d'une véritable thèse opérationnelle. Pour de nombreuses entreprises, le problème n'est pas que les administrateurs de bases de données soient inutiles. C'est qu'ils sont absorbés par la maintenance répétitive pendant que les développeurs attendent, que les équipes analytiques dupliquent les données et que les équipes de sécurité peinent à maintenir les correctifs à jour. L'automatisation peut réduire cette charge. Elle peut également rendre les petites équipes plus cohérentes si le service est bien conçu.
La limite est la responsabilité. Une opération autonome ne connaît pas les priorités métier d'un client à moins que celui-ci ne les encode. Elle ne peut pas décider quelle base de données est autorisée à subir un temps d'arrêt pendant une clôture comptable. Elle ne peut pas savoir si une application dépend d'un comportement non documenté après un correctif. Elle ne peut pas dire si un pic de charge de travail est une campagne légitime, un travail incontrôlé ou un problème de sécurité sans contexte.
Elle ne peut pas remplacer l'appropriation de la classification des données, de l'examen des accès, des priorités de reprise ou des limites de coûts.
Les propres documents de responsabilité cloud d'Oracle renforcent cette limite. Dans le modèle de sécurité partagée, Oracle sécurise l'infrastructure et les opérations du cloud, mais le client reste responsable des données, des identifiants, de l'accès aux comptes, de la gestion des applications, du comportement sécurisé des utilisateurs, des politiques IAM, de la configuration réseau et pare-feu, des choix de chiffrement côté client et de la gouvernance globale, des risques et de la sécurité des charges de travail.
Le modèle de résilience indique qu'Oracle fournit une infrastructure cloud résiliente, mais que les clients doivent concevoir la haute disponibilité et la reprise après sinistre pour leurs applications, déployer sur plusieurs domaines de pannes, domaines de disponibilité et régions, et tester le basculement.
C'est la division correcte. Cela signifie également que les clients ne doivent pas traiter "autonome" comme une raison de réduire la supervision sans discernement. Le travail change de forme. Au lieu de régler manuellement chaque index, les équipes supervisent les politiques, les exceptions, les niveaux de service et les preuves. Au lieu de corriger chaque système à la main, elles valident les fenêtres de correction, testent les applications représentatives et surveillent les résultats. Au lieu de construire manuellement chaque routine de sauvegarde, elles prouvent la restauration, la rétention et les protections contre la suppression.
Le gain opérationnel n'est réel que si la nouvelle supervision est plus petite et plus fiable que l'ancien travail manuel.
L'hybride et le multicloud sont des réponses aux contraintes, pas une liberté face à la complexité
Oracle possède l'une des stratégies hybrides et multicloud les plus distinctives parmi les principaux fournisseurs cloud. Il propose des régions OCI publiques, Exadata Cloud@Customer, Dedicated Region Cloud@Customer, Compute Cloud@Customer, Oracle Alloy et des services de base de données placés dans ou à côté des environnements AWS, Microsoft Azure et Google Cloud. Ce n'est pas une distinction cosmétique.
Elle répond aux raisons réelles pour lesquelles de nombreuses charges de travail Oracle restent difficiles à déplacer: résidence des données, latence vers les systèmes existants, contrôle réglementaire, compatibilité des applications packagées, analytique adjacente au cloud, et le fait pratique que de nombreuses entreprises standardisent déjà une partie de leur parc sur un autre hyperscaler.
Pour les clients, cela peut réduire une ancienne alternative binaire. Une banque peut vouloir l'automatisation de la base de données cloud mais avoir besoin que les données restent dans un pays ou une installation. Un fabricant peut avoir besoin d'un accès à faible latence aux systèmes locaux de l'usine. Un éditeur de logiciels peut exécuter des services applicatifs sur AWS mais avoir besoin de la compatibilité Oracle Database sans reconstruire la couche de données. Une entreprise mondiale peut vouloir de l'analytique Azure à proximité d'une base de données Oracle.
Les options distribuées d'Oracle permettent à ces acheteurs de moderniser une partie de la charge de travail sans tout déplacer dans une région cloud publique Oracle.
C'est utile. Ce n'est pas la même chose qu'éviter la complexité. Un service de base de données multicloud ajoute des frontières entre fournisseurs, consoles, chemins réseau, équipes de support, systèmes d'identité, modèles de surveillance, systèmes de facturation et circuits d'approvisionnement. Un environnement Cloud@Customer place une infrastructure cloud gérée dans un centre de données client, mais le client a toujours des questions locales d'installations, de réseau, d'accès physique, de gouvernance des données et d'appropriation des applications.
Une Dedicated Region peut apporter plus d'OCI dans un environnement contrôlé, mais elle augmente également l'engagement à long terme.
La question opérationnelle est de savoir où se termine la surface de contrôle. Si un service de base de données Oracle se trouve dans un environnement AWS, Azure ou Google Cloud, qui est responsable de l'incident lorsque la latence applicative augmente? Qui confirme si le problème vient du pool de connexions client, du routage inter-cloud, du stockage, des événements d'attente de base de données, de la fédération d'identité, de la capacité de la région ou d'un changement côté fournisseur? Qui détient les journaux? Quelle équipe est alertée? Quel accord commercial régit les crédits de service ou l'escalade de support?
Quel rapport de coûts cloud capture le coût total de l'architecture?
Le placement multicloud d'Oracle est le plus fort lorsqu'il réduit le compromis architectural sans cacher ces questions d'appropriation. Cela peut être une bonne réponse pour les clients qui souhaitent rapprocher Oracle Database des applications et de l'analytique déjà dans un autre cloud. Cela peut être une réponse faible si les acheteurs le traitent comme un pont sans friction. Le pont a encore besoin d'une conception d'itinéraire, d'une revue de sécurité, de tests de reprise, de lignes de base de performance, de répétitions de support et de clarté commerciale.
Il en va de même pour Cloud@Customer. Garder les données dans un centre de données client peut résoudre les contraintes de résidence et de latence, mais cela ne résout pas automatiquement la gouvernance. L'acheteur doit encore décider qui approuve les changements, comment les sauvegardes sont conservées, comment les scénarios de pannes locales sont gérés, comment les opérations à distance d'Oracle sont contrôlées, comment l'identité est intégrée et comment les charges de travail sortent si le contrat change. L'architecture hybride n'est pas un raccourci pour contourner la discipline d'entreprise.
C'est un moyen d'appliquer cette discipline à plus d'endroits.
L'infrastructure IA modifie le profil de risque d'Oracle pour les acheteurs d'entreprise ordinaires
La croissance de l'infrastructure cloud d'Oracle est de plus en plus liée à la demande d'IA. L'entreprise a signalé que la majeure partie de l'augmentation récente des obligations de performance restantes provenait de grands contrats d'IA, les portions de matériel prépayé et fourni par le client totalisant 75 milliards de dollars. Elle a également signalé un flux de trésorerie disponible négatif de 23,7 milliards de dollars sur l'exercice 2026 tout en investissant pour soutenir la croissance de l'infrastructure cloud.
Oracle a déclaré avoir levé 43 milliards de dollars de dette et 5 milliards de dollars de financement par actions sur l'exercice 2026 et s'attendait à environ 40 milliards de dollars de financement supplémentaire sur l'exercice 2027 par dette et par actions.
Ces chiffres comptent même pour les clients qui n'achètent pas de clusters d'entraînement d'IA de pointe. Ils montrent qu'Oracle effectue un virage à forte intensité capitalistique. Plus de régions cloud, plus de centres de données, plus de GPU, plus de réseaux, plus d'engagements énergétiques et plus de contrats clients à long terme peuvent renforcer OCI si l'exécution est bonne. Ils peuvent également créer une pression si la livraison de capacité, la disponibilité des fournisseurs, les coûts énergétiques, la concentration des clients ou les conditions de financement changent.
La dégradation d'Oracle par S&P Global Ratings en juillet 2026 à BBB-/A-3 est un signal de marché utile, pas un verdict sur le produit. La dégradation reflète les préoccupations concernant le rythme et l'impact financier du déploiement de l'infrastructure d'IA d'Oracle. Elle ne dit pas à un administrateur de base de données si un service Exadata particulier tombera en panne. Elle indique aux équipes d'approvisionnement et de finance que la stratégie d'infrastructure d'IA est devenue suffisamment importante pour affecter l'analyse de crédit.
C'est pourquoi la question de l'acheteur doit être plus granulaire que "Oracle gagne-t-il sur l'IA?" Pour un client d'infrastructure d'IA, la question est de savoir si la capacité sera livrée comme promis, si le réseau et le stockage soutiennent la charge de travail, si l'économie de l'entraînement ou de l'inférence des modèles est prévisible, si les GPU sont disponibles dans la bonne région, et si le support peut résoudre les pannes dans de grands clusters.
Pour un client ordinaire de base de données d'entreprise, la question est de savoir si le déploiement de l'IA d'Oracle améliore la plateforme sans évincer le support, augmenter les prix, mettre à rude épreuve la capacité ou changer le comportement commercial.
Le dossier technique d'Oracle en matière d'infrastructure d'IA n'est pas vide. Les documents OCI Supercluster décrivent de très grands clusters de GPU, des instances bare metal, une mise en réseau RDMA et une infrastructure haute performance pour l'entraînement et l'inférence de l'IA. Oracle AI Database et AI Vector Search apportent des fonctionnalités de recherche vectorielle et d'apprentissage automatique dans la couche de base de données, ce qui est précieux lorsque les entreprises veulent utiliser des données gouvernées sans les déplacer dans un système vectoriel séparé.
Les applications Fusion ajoutent une assistance basée sur l'IA dans les processus métiers. Ce sont des éléments cohérents d'une stratégie de plateforme.
Mais l'infrastructure d'IA n'est pas le même test que la fiabilité des bases de données. Un client de base de données veut un état durable, une reprise prévisible et des opérations stables. Un client d'infrastructure d'IA peut tolérer des modèles de pannes différents, des cycles de rafraîchissement matériel plus courts et des variations de capacité extrêmes. Oracle essaie de servir les deux. Cela peut être puissant, mais cela rend également la discipline opérationnelle plus importante.
L'entreprise doit tenir l'ancienne promesse d'un état d'entreprise fiable tout en investissant dans une nouvelle course à forte intensité capitalistique pour le calcul d'IA.
Les applications d'entreprise relient la technologie à l'acceptation métier
La suite d'applications d'Oracle est importante car de nombreuses charges de travail acceptées ne sont pas purement des charges de travail de base de données. Une clôture financière, une exécution de paie, un changement de chaîne d'approvisionnement, une approbation d'achat, une commande de vente, un dossier de service ou une décision de planification des effectifs est un processus métier reposant sur des données, des autorisations, des règles, des intégrations et des preuves d'audit.
Les applications Oracle Fusion Cloud tentent de réunir l'ERP, la gestion du capital humain (HCM), la chaîne d'approvisionnement, la fabrication, l'expérience client et l'analytique dans une suite cloud connectée avec de l'IA intégrée et des mises à jour régulières.
L'attrait est similaire à celui de Workday ou de SAP sur un point: un acheteur veut moins de systèmes fragmentés et plus d'actions métier acceptées. Oracle affirme que Fusion ERP rationalise les routines de comptabilité, de conformité et de clôture; les applications de chaîne d'approvisionnement connectent l'innovation produit, l'approvisionnement et la logistique; HCM accompagne les employés du recrutement à la retraite; les applications d'expérience client connectent les flux de campagne, de devis, de commande, de renouvellement et de service. Le fil conducteur n'est pas un écran. C'est une décision métier contrôlée.
Cela compte pour l'histoire de l'infrastructure d'Oracle car les couches de base de données et d'application se renforcent mutuellement. Un client qui exécute des applications Oracle peut trouver OCI, Autonomous Database, Exadata et Fusion Analytics plus naturels qu'une pile hétérogène assemblée à travers de nombreux fournisseurs. Un client utilisant déjà Oracle Database peut voir les applications Fusion comme un moyen de garder les données métier plus proches de la plateforme existante.
Un client utilisant un autre cloud peut préférer les services de base de données Oracle intégrés à proximité des services d'application et d'analytique de ce cloud. La stratégie d'Oracle est de faire en sorte que la pile paraisse intégrée sans forcer chaque charge de travail à un emplacement physique unique.
Le risque est que l'acceptation des processus métier soit plus difficile que l'intégration de plateforme. Une clôture ERP n'est pas acceptée parce que l'IA peut expliquer un écart. Elle est acceptée parce que le grand livre est correct, les approbations sont complètes, les exceptions sont comprises, les preuves d'audit sont disponibles et les rapports en aval sont alignés. Une recommandation de chaîne d'approvisionnement n'est pas acceptée parce qu'elle arrive dans une interface moderne.
Elle est acceptée parce que les données de base, les contraintes des fournisseurs, les enregistrements d'inventaire, les délais et les politiques de risque sont crédibles. Une action de paie ou de RH n'est pas acceptée parce que HCM est dans le cloud. Elle est acceptée lorsque les enregistrements des employés, les règles de paie, les approbations, les contrôles de confidentialité et les intégrations fonctionnent cycle après cycle.
L'IA applicative d'Oracle doit donc être évaluée comme une assistance métier supervisée, et non comme une vérité autonome. Les questions utiles sont ordinaires et strictes. Un utilisateur financier peut-il voir pourquoi une écriture suggérée ou une explication d'écart est apparue? Un examinateur d'approvisionnement peut-il contester une recommandation de sourcing? Un responsable RH peut-il comprendre la politique et les données derrière une suggestion concernant les effectifs? Les demandes d'accès peuvent-elles être vérifiées par rapport aux règles de séparation des tâches?
Les auditeurs peuvent-ils reconstituer qui a approuvé un changement et pourquoi?
Ces questions n'affaiblissent pas l'histoire des applications d'Oracle. Elles la rendent plus réelle. Les applications d'Oracle sont les plus précieuses lorsqu'elles relient l'état des bases de données, le contrôle des processus et les preuves métier. Elles sont les moins précieuses lorsque les acheteurs confondent l'IA intégrée avec un remplacement de l'appropriation des processus.
La sécurité, l'identité et la récupérabilité restent des responsabilités partagées
La position de confiance d'Oracle repose sur des signaux de sécurité, de confidentialité, de disponibilité et de conformité, mais ces signaux doivent être lus correctement. Oracle Cloud propose des accords de niveau de service pour la disponibilité, la gérabilité et les performances. Son centre de confiance oriente les clients vers un statut et un historique en temps réel pour OCI et les applications Fusion Cloud. La documentation OCI explique la responsabilité partagée pour la sécurité et la résilience.
La documentation de facturation fournit une analyse des coûts, des budgets, des rapports de coûts, des factures, des relevés d'utilisation et des récompenses de support. Les pages contractuelles montrent que les services cloud dépendent d'accords, de bons de commande et de politiques de service.
Tout cela est utile. Cela donne aux acheteurs d'entreprise des éléments à examiner. Cela ne rend pas la charge de travail d'un client sécurisée ou récupérable par défaut.
L'identité est l'exemple le plus clair. Oracle peut fournir des services IAM, des compartiments, des politiques, des journaux d'audit, des outils de chiffrement et des services de sécurité. Le client doit toujours concevoir la structure de compte, l'accès à moindre privilège, la fédération, l'accès d'urgence, la rotation, la séparation des tâches, les utilisateurs d'intégration, les rôles de base de données privilégiés et les routines d'examen. Un domaine OCI bien construit peut être sécurisé. Un domaine mal gouverné peut exposer des données sensibles, permettre un accès excessif ou rendre la reprise plus difficile.
La résilience est tout aussi explicite. La documentation de résilience d'Oracle indique qu'OCI ne réplique, ne déploie ni ne bascule automatiquement les ressources d'application et les données du domaine d'un client vers un autre domaine de disponibilité ou une autre région lors d'un sinistre ou d'une panne. Les clients sont responsables du déploiement des ressources sur plusieurs domaines de pannes, domaines de disponibilité et régions; de la définition des objectifs de point de reprise (RPO) et de délai de reprise (RTO); de la documentation des plans de haute disponibilité et de reprise après sinistre; et du test du basculement.
Ce n'est pas un défaut. C'est ainsi que fonctionne la responsabilité cloud. Mais c'est une soupape de sécurité contre la pensée magique.
La récupérabilité a également un contexte métier. Une sauvegarde de base de données peut exister et échouer quand même pour l'organisation si personne ne sait à quel point dans le temps restaurer, quels systèmes en aval doivent être réconciliés, comment gérer les transactions en cours, comment communiquer avec les utilisateurs, ou comment prouver l'état restauré aux auditeurs. Un basculement peut fonctionner techniquement et nuire quand même à l'entreprise si l'application se connecte au mauvais point de terminaison ou si les équipes de support ne savent pas qui est autorisé à déclencher les transitions de rôle.
La sécurité et la reprise doivent donc faire partie des tests d'acceptation. Les acheteurs doivent tester la restauration, le basculement, la révision des rôles, la gestion des clés, l'isolation réseau, les exports d'audit, les alertes de coûts et l'escalade de support avant de déclarer le succès. Ils ne doivent pas accepter une date de production sur la seule base d'un badge de certification ou d'une catégorie de SLA. Oracle peut fournir des contrôles solides. Les clients doivent prouver ces contrôles dans leur propre charge de travail.
Les licences et les coûts sont des faits opérationnels, pas des détails d'approvisionnement
Le dossier commercial d'Oracle ne peut pas être évalué uniquement à travers les prix catalogue du cloud. Le client doit inclure les licences, les contrats de support, les engagements cloud, la main-d'œuvre de migration, les services partenaires, le personnel interne, la maintenance de l'intégration, la formation, l'examen de sécurité, la connectivité réseau, l'observabilité, la sortie de données, la rétention des sauvegardes, la capacité de reprise après sinistre, la modernisation des applications, la mise hors service et les coûts de sortie.
Oracle fournit des outils qui aident. La gestion des coûts OCI inclut des estimateurs, des budgets, une analyse des coûts, des rapports programmés, des rapports de coûts, des détails d'abonnement, des factures et des relevés d'utilisation. Les récompenses de support Oracle peuvent appliquer les récompenses résultant de l'utilisation d'OCI aux contrats de support sur site éligibles. Les supports de migration mentionnent l'apport de licences existantes aux services cloud et des compensations de support. Ce sont des éléments significatifs pour les clients disposant de grands parcs Oracle car ils peuvent modifier l'économie de la modernisation.
Les mêmes caractéristiques peuvent produire de la complexité. Les contrats de services cloud d'Oracle ne tiennent pas en une page. Le modèle contractuel combine un accord, des bons de commande et des politiques de service. Les descriptions de service, les politiques d'hébergement, les conditions de support, les conditions de traitement des données et les limites spécifiques aux produits peuvent toutes compter.
La politique d'Oracle pour l'octroi de licences logicielles dans les environnements de cloud computing exige que les clients comptent les vCPU dans les environnements cloud autorisés et inclut des limites pour les déploiements Standard Edition. Un acheteur qui traite cela comme une réflexion après coup peut créer des surprises budgétaires ou de conformité.
La charge de travail acceptée a donc besoin d'un manuel commercial. Quelles licences sont utilisées? Lesquelles sont des services cloud avec licence incluse? Lesquelles sont en apport de licence? Quel contrat de support reste en vigueur? Quelles récompenses de support s'appliquent? Quelles fonctionnalités nécessitent des options de base de données? Quelles régions, bases de données de secours ou ressources de reprise après sinistre ajoutent des coûts? Quel événement de mise à l'échelle modifie la facture? Quelles alertes de coûts se déclenchent avant qu'un budget ne soit dépassé?
Quels anciens matériels, licences ou contrats de support peuvent être mis hors service?
L'économie unitaire dépend également de savoir si Oracle réduit le travail plutôt que de simplement le déplacer. Si l'Autonomous Database réduit la correction et l'optimisation de routine mais que le client conserve la même charge de support ailleurs, les économies peuvent être faibles. Si OCI réduit le coût de l'infrastructure mais que la migration crée des années de dépenses de conseil, le retour sur investissement peut être lent. Si Cloud@Customer résout la résidence mais enferme le client dans un engagement de plateforme à long terme important, la valeur stratégique peut encore être élevée, mais elle doit être reconnue honnêtement.
Le meilleur dossier commercial d'Oracle est la performance plus le contrôle moins la complexité évitée. Il est le plus fort lorsque les clients peuvent consolider les bases de données, mettre hors service les anciennes infrastructures, réduire l'administration manuelle, améliorer la reprise, garder les données près des applications, utiliser les compétences existantes et éviter une réécriture complète. Il est le plus faible lorsque les clients achètent de la capacité cloud sans nettoyer la position de licence, l'architecture de données, les dépendances applicatives et l'appropriation opérationnelle.
Les preuves du marché soutiennent la dynamique mais pas l'inévitabilité
Oracle a une dynamique. Les résultats de l'exercice 2026 ont montré une forte croissance de l'infrastructure cloud, des obligations de performance restantes record et une part du chiffre d'affaires cloud désormais supérieure à la moitié du chiffre d'affaires total. Le portefeuille de produits est assez large pour toucher les bases de données, les applications, les intergiciels, l'infrastructure, l'analytique, l'IA et les charges de travail sectorielles. Gartner a reconnu Oracle comme Leader dans le Magic Quadrant 2025 des services de plateforme cloud stratégiques, selon le résumé public d'Oracle.
La publication Q3 2025 de Synergy Research sur l'infrastructure cloud montrait encore qu'Amazon, Microsoft et Google détenaient 63 % des dépenses d'infrastructure cloud d'entreprise, tandis qu'Oracle se situait dans le groupe de poursuivants beaucoup plus petit qui attirait l'attention.
Cette combinaison est importante. Oracle est grand, rentable et stratégiquement pertinent, mais ce n'est pas simplement la quatrième copie d'AWS, Azure ou Google Cloud. Il a un angle d'attaque différent: la gravité des bases de données, les performances d'Exadata, le placement hybride, les applications d'entreprise, les services de base de données multicloud et des relations clients existantes profondes. Il n'a pas besoin de gagner chaque charge de travail cloud générique pour compter.
Il doit être l'endroit le plus crédible pour les charges de travail lourdes Oracle, les entreprises dépendantes des bases de données et les clients d'IA qui valorisent la conception de son infrastructure.
L'inconvénient est qu'un angle d'attaque peut devenir une frontière. Les clients qui ne sont pas déjà fortement engagés avec Oracle peuvent voir moins de raisons d'adopter OCI comme plateforme générale à moins que la capacité d'IA, le rapport prix-performance, l'intégration des bases de données ou les options de déploiement souverain ne soient décisifs. Les développeurs déjà investis dans les services natifs d'un autre cloud peuvent préférer y conserver la plupart des nouvelles applications.
Les entreprises préoccupées par les frictions de licence ou de support peuvent traiter Oracle comme nécessaire pour les charges de travail existantes mais éviter d'étendre la dépendance là où des alternatives sont matures.
C'est pourquoi les annonces de capacité ne doivent pas dominer le verdict. La valeur du cloud n'est pas seulement le calcul disponible. C'est la profondeur de l'écosystème, la réactivité du support, la couverture des régions, la familiarité des développeurs, l'outillage tiers, la maturité de la place de marché, les opérations de sécurité, la prévisibilité des coûts et les compétences de migration. Oracle a amélioré sa position, mais les acheteurs doivent toujours évaluer précisément la charge de travail plutôt que de supposer que la croissance du cloud règle la question.
Le signal du marché est donc équilibré. La poussée de l'infrastructure cloud d'Oracle est assez réelle pour changer l'entreprise. Sa base de bases de données et d'applications lui donne une voie durable vers la modernisation des entreprises. Son déploiement d'IA pourrait rendre OCI plus stratégiquement important. Mais ce même déploiement accroît l'intensité capitalistique, le risque d'exécution et les questions de concentration de clients. La dynamique augmente les enjeux. Elle n'élimine pas la diligence.
Ce qu'un acheteur doit tester avant de faire confiance à Oracle
Une évaluation sérieuse d'Oracle doit commencer par la charge de travail qui fait le plus mal, et non par la diapositive qui paraît la meilleure. Pour un parc de bases de données, choisissez une charge de travail de production représentative avec de vrais schémas transactionnels, une pression de reporting, des travaux par lots, des dépendances d'intégration et des exigences de reprise. Pour un parc d'applications, choisissez un processus qui traverse les approbations, la qualité des données, le reporting et les systèmes en aval.
Pour l'infrastructure d'IA, choisissez une charge de travail qui reflète l'économie réelle d'entraînement ou d'inférence, et non un benchmark jouet.
Le premier test est la correction de la migration. L'acheteur doit prouver l'intégrité des données, le comportement de l'application, les performances, la durée des lots, l'accès des utilisateurs, le reporting et la réconciliation après la migration. Si la charge de travail est déplacée telle quelle, testez les anciennes hypothèses. Si elle est replateformée, testez les nouvelles. Si des fonctionnalités autonomes sont introduites, testez comment les utilisateurs les supervisent et comment les exceptions remontent.
Le deuxième test est la résilience. Effectuez un basculement. Effectuez une restauration. Testez l'immutabilité des sauvegardes et les protections contre la suppression. Confirmez le RPO et le RTO avec les propriétaires métier, pas seulement avec les équipes d'infrastructure. Vérifiez le comportement de connexion des applications, le DNS, l'identité, la surveillance, la clarté du manuel opérationnel et l'escalade de support. Documentez ce qui se passe si une région, un domaine de disponibilité, un lien réseau, un nœud de base de données, un utilisateur d'intégration ou un chemin de gestion des clés échoue.
Le troisième test est la sécurité et l'auditabilité. Examinez les politiques IAM, les compartiments, les rôles de base de données, l'accès privilégié, les comptes d'intégration, les choix de chiffrement, les pistes d'audit, le masquage des données et la séparation des tâches. Confirmez qui peut modifier les paramètres de sauvegarde, de réseau, d'options de base de données et de coûts. Exportez des preuves sous une forme que les auditeurs et les équipes de risque peuvent effectivement utiliser.
Le quatrième test est le contrôle des coûts. Utilisez la consommation réelle de la charge de travail, pas une estimation optimiste. Incluez la capacité de secours, la croissance du stockage, la rétention des sauvegardes, le transfert de données, le support, les licences, le travail des partenaires, la main-d'œuvre interne et la mise hors service des anciens systèmes. Testez les budgets et les alertes de coûts. Décidez qui est responsable des dépenses imprévues. Si les récompenses de support ou l'économie d'apport de licence font partie du dossier, validez-les par rapport au contrat et à la conception réelle du déploiement.
Le cinquième test est le support. Ouvrez un cas de support non trivial pendant le pilote. Testez qui répond, quelles informations sont nécessaires, à quelle vitesse le problème est trié, et ce qui se passe lorsque le problème traverse le code applicatif, le réseau cloud, l'application et le code du client. Une charge de travail critique dépend du comportement du support, pas seulement de la conception du produit.
Le sixième test est la sortie et le changement. Demandez ce qui se passe si la charge de travail doit être déplacée à nouveau, si un engagement cloud change, si une option de base de données devient trop coûteuse, si une unité opérationnelle passe à une autre plateforme, ou si un régulateur exige un placement de données différent. Oracle peut encore être le bon choix, mais l'acheteur doit comprendre ce que quitter ou restructurer coûterait.
Ces tests ne sont pas hostiles. Ils sont le prix normal de la confiance accordée à un état d'entreprise. Les produits les plus solides d'Oracle devraient y survivre. Un acheteur qui les ignore ne fait pas preuve d'optimisme; il transfère le risque des achats vers les opérations.
Un verdict mesuré
Oracle est une plateforme sérieuse pour un état d'entreprise fiable, mais elle ne doit pas être évaluée à travers une seule histoire. L'histoire de la base de données est crédible car Oracle possède une technologie mature autour des transactions, des performances, de la haute disponibilité, d'Exadata, de la reprise et des opérations gérées. L'histoire du cloud est crédible car les résultats de l'exercice 2026 montrent une demande réelle d'infrastructure et parce qu'Oracle a construit des chemins de déploiement public, hybride et multicloud qui correspondent aux contraintes des parcs lourds Oracle.
L'histoire des applications est crédible car l'acceptation métier réside souvent dans les processus financiers, RH, de chaîne d'approvisionnement et clients, pas seulement dans les bases de données. L'histoire de l'IA est suffisamment crédible pour modifier le profil de croissance d'Oracle, mais suffisamment intensive en capital pour accroître l'examen de l'exécution et financier.
Le risque est également clair. Oracle peut réduire le travail manuel, mais il ne peut pas supprimer la responsabilité du client en matière de qualité des données, d'identité, de reprise, d'intégration, de coûts, de licences et d'appropriation du support. Il peut placer des services de base de données dans plus de clouds et dans des environnements plus contrôlés par le client, mais cela ne supprime pas la complexité du multicloud. Il peut automatiser la correction et l'optimisation, mais les clients doivent encore superviser les exceptions et valider l'impact métier.
Il peut signaler d'énormes obligations de performance restantes, mais les acheteurs ont encore besoin de preuves que leur propre charge de travail a une capacité, une récupérabilité et une économie qui ont du sens.
La meilleure façon de comprendre Oracle en 2026 est de le considérer comme une entreprise d'acceptation de charges de travail d'entreprise. Sa valeur apparaît lorsqu'une charge de travail de base de données, d'application ou cloud franchit la transition difficile vers un état opérationnel de confiance. Les preuves soutiennent la confiance lorsque le client a déjà une gravité Oracle, peut bénéficier de la compatibilité, investit dans la discipline de migration, teste le basculement, gouverne l'identité, comprend sa position de licence et suit le coût total d'exploitation.
Les preuves soutiennent la prudence lorsque les acheteurs courent après les gros titres sur le cloud ou l'IA sans prouver le modèle opérationnel.
Le véritable test pour Oracle n'est pas de savoir s'il peut construire plus d'infrastructure cloud ou attacher plus d'intelligence aux logiciels d'entreprise. C'est de savoir si une charge de travail critique peut fonctionner le mois prochain, survivre au prochain correctif, se rétablir après la prochaine panne, s'expliquer aux auditeurs, rester dans les limites commerciales et avoir encore du sens lorsque l'équipe de migration d'origine est passée à autre chose. C'est un test plus dur qu'une annonce de capacité. C'est aussi le seul test qui compte pour les entreprises qu'Oracle veut conserver.