Alphabet, maison mère de Google, vient d’annoncer l’acquisition d’Intersect pour 4,75 milliards $ en cash, auxquels s’ajoute la reprise de la dette existante. Cette opération représente l’une de ses transactions les plus importantes et marque un tournant dans sa stratégie de développement de centres de données dédiés à l’IA.
L’enjeu est de taille : permettre à Google d’accéder à davantage d’électricité pour ses infrastructures, alors que le réseau électrique américain, vieillissant, peine à absorber une demande énergétique qui explose pour la première fois depuis des décennies. L’IA constitue le principal moteur de cette croissance fulgurante.
« Intersect nous aidera à accroître nos capacités, à opérer avec plus d’agilité dans la construction de nouvelles centrales électriques en phase avec la nouvelle charge des centres de données, et à repenser les solutions énergétiques pour stimuler l’innovation et le leadership des États-Unis » déclare Sundar Pichai, directeur général de Google et d’Alphabet.
Un portefeuille énergétique impressionnant
Aux termes de cet accord, Alphabet achète les projets énergétiques et de centres de données d’Intersect, qu’ils soient en développement ou en construction. L’entreprise possède 15 milliards $ d’actifs en exploitation ou en construction.
Elle exploite actuellement environ 7,5 gigawatts de capacité solaire et de stockage, et prévoit de développer 8 gigawatts supplémentaires. Pour référence, un gigawatt équivaut approximativement à la production d’un réacteur nucléaire et peut alimenter environ 750 000 foyers. L’essentiel de cette capacité est concentré au Texas.
Son PDG, Sheldon Kimber, avait d’ailleurs surnommé le Texas le « Disneyland de l’énergie » en raison de ses abondantes ressources éoliennes et solaires. Parmi ses projets phares dans cet État figure « Quantum », un système de stockage d’énergie propre construit directement à côté d’un campus de centres de données pour Google.
L’opération s’inscrit dans une stratégie plus large d’Alphabet dans le secteur énergétique. Google, en partenariat avec TPG Rise Climate, avait déjà soutenu Intersect lors d’une levée de fonds de plus de 800 millions $ en décembre 2024.
Une structure d’acquisition sur mesure
Dans le cadre de cet accord, Alphabet acquiert la plateforme de développement et les effectifs d’Intersect, y compris les actifs en développement déjà sous contrat avec Google. Intersect conservera sa propre marque et restera dirigée par Sheldon Kimber.
Les actifs opérationnels existants de la société au Texas, ainsi que ses actifs opérationnels et en développement en Californie, ne seront pas inclus dans l’acquisition et continueront de fonctionner comme une entreprise indépendante, soutenue par ses investisseurs actuels. TPG Rise Climate conservera une participation dans ces actifs.
Intersect explorera également un éventail de technologies émergentes pour accroître et diversifier l’approvisionnement énergétique, tout en soutenant les investissements de Google dans ses centres de données américains.
« En acquérant un développeur et pas seulement un contrat d’achat d’électricité, Google s’offre la flexibilité nécessaire pour construire où et quand il le souhaite » estime Ben Hertz-Shargel, analyste du cabinet Wood Mackenzie cité par Bloomberg.
Alibaba, géant chinois du numérique et de l’infrastructure cloud, poursuit sa stratégie IA « full stack » articulée autour de ses modèles Qwen (LLM) et Wan (génération visuelle/vidéo). Le groupe lance Wan2.6, un modèle concurrent de Veo3 et Sora 2 qui promet d’abaisser la barrière d’entrée de la vidéo IA en combinant génération d’images, de […]
Et si nous développions un portail collaboratif communautaire ?
OPENALIS.NET est un projet 100% open source en recherche d'un coup de boost pour arriver sur le marché FR très prochainement.
Un premier tour de table sera mené à partir de la fin du premier trimestre 2026 en fonction des retours de potentiels investisseurs afin de créer une nouvelle structure proposant LE portail collaboratif libre FR à la fois pour les particuliers et les entreprises.
(NdM.:LE ça semble ambitieux pour un nouveau projet avec Cozy/Twake, Nextcloud, Yunohost, etc. en libre sur des secteurs similaires)
Un accès simple pour tout le monde et une plateforme crédible pour les entreprises.
(Le nom du projet est voué à changer par la suite.)
Lors du dernier salon de l'OSXP sur Paris, OPENALIS.NET a reçu un accueil très chaleureux.
Avec plusieurs centaines de participants à cette campagne nous pourrions changer définitivement la donne en termes d'alternative souveraine sur notre sol et partout ailleurs.
Le vrai « AWS re:Invent » se joue souvent loin des keynotes “agents partout”. Plusieurs annonces « invisibles » reconfigurent déjà l’architecture et l’exploitation au quotidien.. Un second regard sur l’un des évènements IT majeurs de l’année 2025… Chaque année, AWS re:Invent s’impose comme la grand-messe du cloud. Et comme depuis quelques années le même scénario se […]
La plateforme data est devenue l’infrastructure critique pour industrialiser l’IA générative sans perdre le contrôle des données propriétaires, de la gouvernance et de la sécurité. Databricks accélère ce mouvement avec une seconde levée de fonds XL en 2025, une Série L qui semble préparer une prochaine introduction en bourse. Depuis l’explosion de l’IA générative, les […]
Chez les principaux fournisseurs de bases de données cloud, il n’est plus si rare que des produits se chevauchent.
La synthèse du dernier Magic Quadrant dédié à ce marché en témoigne. La majorité des « leaders » (5 sur 9) ont droit à une remarque à ce sujet :
Alibaba Cloud
Chevauchement entre AnalyticDB et Hologres (analytique) comme entre DMS et DataWorks (intégration de données).
AWS
Grand choix de SGBD et d’options d’intégration… au prix de chevauchements et de conflits.
Google
Plusieurs solutions pour Postgre (Cloud SQL, AlloyDB, Spanner) entre lesquelles il faut faire la balance.
IBM
Chevauchements sur la partie entrepôt de données, entre les offres Db2 Warehouse, Neterra watsonx.data.
Microsoft
Concurrence entre Azure Synapse, Microsoft Fabric et Azure Databricks.
Gérer les coûts reste un défi
Autre sujet largement partagé parmi les « leaders » : la gestion des coûts.
Elle est difficile chez AWS faute de tarification unifiée entre services.
Elle l’est aussi pour beaucoup de clients de Databricks, malgré des avancées sur l’outillage FinOps.
Chez Google, elle a tendance à se complexifier avec l’intégration de nouvelles fonctionnalités.
Concernant Oracle, la clientèle se plaint toujours des prix et de la difficulté de contractualisation, même si la tendance s’atténue avec le passage au cloud et son modèle de facturation à l’usage.
Concernant Snowflake, Gartner a un jugement plus spécifique : le côté « user-friendly » est susceptible de favoriser le développement d’un état d’esprit « black box », et par là même de limiter la capacité à optimiser les workloads.
Plusieurs de ces fournisseurs avaient déjà été épinglés à ce sujet il y a un an, dans l’édition précédente de ce Magic Quadrant.
Databricks, à cause de la difficulté à prédire les coûts avec le modèle fondé sur des unités de consommation.
Google, parce que le suivi des dépenses pouvait se révéler délicat, a fortiori lorsqu’on interfaçait aux bases de données des services fondés sur des unités de consommation.
Oracle, perçu, de par son historique, comme un fournisseur aux offres onéreuses.
Alibaba, chez qui la variété des modèles de pricing, combinée à une facturation découplée pour certaines ressources au nom de la flexibilité, pouvait s’avérer difficile à maîtriser.
20 fournisseurs, 9 « leaders »
D’une année à l’autre, les critères à respecter ont peu évolué. Il fallait toujours, entre autres, gérer au moins un cas d’usage parmi :
Transactionnel
Transactions « légères » (gros volumes à haute concurrence et basse latence)
Gestion d’état d’applications
Data warehouse
Lakehouse
Analyse d’événements
Une fois encore, Gartner n’a évalué que les offres managées, fournies en cloud public ou privé. Il n’a pas pris en compte les bases de données hébergées sur du IaaS.
Les 20 fournisseurs classés sont les mêmes que l’an dernier. Et les 9 « leaders » d’alors le sont restés. Dans l’ordre alphabétique : Alibaba Cloud, AWS, Databricks, Google, IBM, Microsoft, MongoDB, Oracle et Snowflake.
Sur l’axe « exécution », reflétant la capacité à répondre à la demande, la situation est la suivante :
Rang
Fournisseur
Évolution annuelle
1
AWS
=
2
Google
=
3
Microsoft
+ 1
4
Oracle
– 1
5
Databricks
=
6
Snowflake
+ 1
7
MongoDB
– 1
8
IBM
+ 2
9
Alibaba Cloud
– 1
10
InterSystems
– 1
11
Huawei Cloud
=
12
SAP
=
13
Teradata
=
14
Cloudera
=
15
Couchbase
+ 3
16
SingleStore
+ 1
17
EDB
+ 3
18
Redis
– 3
19
Neo4j
– 3
20
Cockroach Labs
– 1
Sur l’axe « vision », reflétant les stratégies :
Rang
Fournisseur
Évolution annuelle
1
Google
=
2
Databricks
+ 3
3
Microsoft
– 1
4
Oracle
– 1
5
AWS
– 1
6
Snowflake
+ 2
7
Alibaba Cloud
+ 3
8
IBM
– 1
9
SAP
– 3
10
Teradata
– 1
11
MongoDB
=
12
Cloudera
=
13
InterSystems
+ 2
14
Neo4j
=
15
Huawei Cloud
+ 1
16
EDB
+ 4
17
Couchbase
=
18
SingleStore
=
19
Redis
– 6
20
Cockroach Labs
– 1
Alibaba Cloud, distingué pour son approche « data + IA »…
Les principales offres d’Alibaba Cloud sur ce marché sont PolarDB et ApsaraDB (transactionnel), AnalyticDB et MaxCompute (analytique), Tair et Lindorm (clé-valeur).
L’a dernier, le groupe chinois avait été salué pour sa présence sectorielle importante et différenciée, le développement de son écosystème de partenaires et le poids de sa communauté open source.
Cette année, Gartner apprécie la tarification, jugée attractive. Ainsi que la fiabilité de l’architecture serverless. Désormais étendue à tous les SGBD, elle se distingue par son architecture découplant calcul, mémoire et stockage en environnement hybride. Bon point également pour l’approche « data + IA » qui permet de développer et de déployer des applications en n’utilisant que des technologies d’Alibaba Cloud.
… mais pas pour la configuration de PolarDB
L’an dernier, Gartner avait pointé, au-delà de la gestion des coûts, le risque géopolitique associé à Alibaba Cloud. Ainsi que la disponibilité encore limitée de ses servies hors de l’Asie (moins de régions et de zones de disponibilité que la concurrence).
Cette année encore, la faible présence hors Asie est signalée. Elle peut se traduire par un moins grand nombre d’intégrations d’outils tiers et de ressources en anglais (documentation, formation, support). Attention aussi à la configuration de PolarDB, jugée complexe par les nouveaux utilisateurs, notamment sur l’équilibre coût/performance et la gestion du stockage multicouche. Il faut y ajouter les chevauchements de produits sus-évoqués.
AWS a un catalogue d’une ampleur sans égale…
Aurora, Redshift, DynamoDB et SageMaker font partie des principaux produits d’AWS sur ce marché.
L’an dernier, Gartner avait salué la couverture fonctionnelle d’AWS et sa capacité à créer du liant entre ses solutions. Il avait aussi noté l’exhaustivité des partenariats et de la présence géographique.
Ce dernier point vaut toujours et s’assortit d’un bon historique de disponibilité de l’infrastructure ainsi que d’une approche « proactive » de dialogue avec le client pour l’optimisation des coûts. AWS a, plus globalement, un catalogue d’une ampleur sans égale sur ce marché, avec SageMaker comme point central de gouvernance data/IA.
… mais des dépendances pour l’orchestration hybride
L’intégration entre les services d’AWS peut être complexe, avait souligné Gartner l’an dernier. Le cabinet américain avait aussi constaté que la prise en charge des déploiements hybrides/multicloud était limitée malgré la disponibilité de connecteurs natifs et le support de moteurs comme Spark (les clients tendent à utiliser des orchestrateurs tiers, avait-il expliqué).
Ce dernier constat est toujours d’actualité : beaucoup de clients dépendent de solutions tierces pour l’orchestration hybride/multicloud. S’y ajoutent les deux éléments sus-évoqués : gestion des coûts difficile et chevauchements entre produits.
Databricks, rapide pour innover…
Outre Data Intelligence Platform (qui inclut Unity Catalog), Databricks propose du data warehouse avec Databricks SQL, du transactionnel avec Lakebase, ainsi que de l’intégration et de l’engineering avec Lakeflow.
L’an dernier, Gartner avait salué les investissements dans la GenAI (dont l’acquisition de MosaicML), traduits par le développement de ses propres LLM. Il avait aussi donne un bon point au catalogue Unity (qui venait d’être basculé en open source) et au format Delta Lake (concurrent d’Iceberg).
Cette année, Databricks est salué pour sa « vision lakehouse », bien qu’il ne soit plus seul sur ce marché. Il l’est aussi pour sa cadence d’innovation, entre la composante Agent Bricks (qui a reçu des fonctionnalités importantes presque tous les mois), l’acquisition de Tabular (qui a accompagné la prise en charge d’Iceberg sur tout le portefeuile) et l’introduction de capacités low code dans Lakeflow. Bon point également pour l’engagement sur des standards ouverts (Delta Lake, Iceberg, Spark, Postgre…) qui favorisent la portabilité.
… mais pas si simple à prendre en main
L’an dernier, Gartner avait pointé le manque d’intuitivité de l’UI, qui changeait fréquemment tout en manquant de documentation et de capacités low code. Il y avait ajouté l’aspect FinOps, sus-évoqué.
Cette année, le cabinet américain met un bémol à la logique d’ouverture : certains clients s’inquiètent d’un éventuel verrouillage au niveau de l’orchestration et de Delta Live Tables (devenu Lakeflow Spark Declarative Pipelines). Il souligne par ailleurs la tendance des clients à juger que l’usage de la solution exige un haut niveau de compétence technique. En parallèle, le sujet FinOps reste valable (voir ci-dessus).
Google, bien positionné sur l’IA…
Entre autres produits positionnés sur ce marché, Google a Spanner, BigQuery, AlloyDB, Cloud SQL, Firestore, Memorystore et Bigtable.
L’an dernier, Gartner avait salué les contributions open source (à PostgreSQL en particulier). Il avait fait de même pour les avancées dans la GenAI (intégration de Gemini + support transversal de la recherche vectorielle via LangChain) et pour la fondation data/IA unifiée avec Dataplex pour la gouvernance.
Cette fondation data/IA a à nouveau droit à un bon point ; dans les grandes lignes, pour les mêmes motifs. Gartner note plus globalement la capacité de l’offre SGBD de Google à couvrir les cas d’usage dans l’IA agentique. Et apprécie en particulier l’exhaustivité des modèles de données pris en charge par Spanner (relationnel, clé-valeur, graphe, vectoriel).
… mais moins sur le partage de données
Le réseau de partenaires doit encore se développer, avait estimé Gartner l’an dernier. Il avait aussi pointé l’aspect FinOps et souligné que Google proposait moins d’options que la concurrence pour l’intégration native d’applicaitons et le master data management.
Cette année, outre la gestion des coûts et les chevauchements sus-évoqués, un point de vigilance va à la marketplace de données et aux capacités de partage. Elle se révèlent moins avancées que chez certains concurrents, malgré des améliorations sur les clean rooms et l’interopérabilité entre clouds.
IBM étend sa présence multicloud…
Les principaux SGBD cloud d’IBM sont Db2 (transactionnel + analytique) et watsonx.data (lakehouse).
L’an dernier, Big Blue s’était distingué sur sa stratégie sectorielle (solutions spécifiques adaptées sur la gouvernance, la sécurité et la conformité). Ainsi que sur sa capacité à combiner les expertises en open source et en data management au service des déploiements hybrides. Son offre est bien adaptée aux applications critiques, avait ajouté Gartner.
Cette année encore, la stratégie sectorielle est saluée. L’extension de la présence cloud l’est aussi (mise à disposition de Db2 chez les hyperscalers et acquisition de DataStax, qui a une forte présence multicloud). Bon point également pour l’approche « bien définie » d’IBM concernant l’intégration des SGBD dans les frameworks de data management.
… mais a toujours du mal à faire passer son message
IBM a du mal à se différencier dans la communication, par ailleurs pas uniforme entre équipes commerciales, avait expliqué Gartner l’a dernier. Il avait aussi rappelé que le déploiement géographique de l’offre n’atteignait pas encore celui des autres hyperscalers.
Les difficultés de communication restent d’actualité, occasionnant un certain manque de notoriété sur le segment. En parallèle, IBM demeure perçu comme un vendeur « legacy », ce qui est susceptible de détourner certains acheteurs. Gartner y ajoute, comme sus-évoqué, les chevauchements entre certains produits.
Une offre exhaustive chez Microsoft…
Entre autres produits, Microsoft évolue sur ce marché avec Azure SQL Database, Azure Database pour PostgreSQL et MySQL, ainsi qu’Azure Cosmos DB.
L’an dernier, Gartner avait salué l’exhaustivité de l’offre et le niveau d’intégration avec les autres services Microsoft. Il avait aussi apprécié les possibilités d’usage de l’IA pour le data management. Et les avancées sur la gestion du multicloud, exemplifiées par l’interconnexion Azure-Oracle comme par les « raccourcis » dans OneLake pour les analyses fédérées.
Bon point cette année encore pour l’exhaustivité de l’offre, qui « gère presque tous les modèles de données et cas d’usage sectoriels ». L’engagement de Microsoft sur PostgreSQL est également salué. Comme les innovations sur la partie IA (embeddings in-database, indexation de vecteurs, jonctions entre Copilot et Fabric…).
… mais une offre Fabric qui manque encore de maturité
Le chevauchement de certaines offres avait déjà été signalé l’an dernier, en sus de craintes des clients sur la pérennité d’Azure Synapse Analytics et d’Azure Database face à Microsoft Fabric. Ce dernier manquait encore de maturité, avait expliqué Gartner : les capacités d’intégration, de gouvernance et de gestion des métadonnées étaient moins « robustes » que chez d’autres « leaders ». Le déploiement pouvait par ailleurs se révéler complexe, en particulier pour le DR, la sécurité et la gestion des coûts.
Outre le chevauchement de certains produits, Gartner pointe à nouveau le manque de maturité de Microsot Fabric. Les inquiétudes des clients touchent autant aux fonctions data warehouse que gouvernance, entre souveraineté, dimensionnement des ressources, prix, gestion des métadonnées et data quality. Attention aussi aux investissements consentis pour intégrer le transactionnel dans Fabric : sur le court terme, ils peuvent engendrer des enjeux de performance.
MongoDB demeure un standard pour le modèle document…
Outre son édition communautaire et son produit sur site (Enterprise Advanced), MongoDB propose son SGBD Atlas chez AWS, Google et Microsoft.
L’an dernier, Gartner avait salué une offre « bien considérée » pour ses capacités de traitement à haut volume, son élasticité et la flexibilité du schéma. Il avait aussi souligné la souplesse et la rapidité d’implémentation, contribuant à la popularité auprès des développeurs.
Ce dernier élément vaut toujours et engendre un vivier de compétences d’autant plus grand. S’y ajoute la richesse des options de déploiement, accentuée par un programme de partenariats jugé « robuste ». MongoDB est plus globalement parvenu à établir une forme de standard pour qui souhaite un modèle orienté document.
… mais manque d’un storytelling sur la convergence transactionnel-analytique
Si MongoDB associe transactionnel et analytique, son offre se limite à du non relationnel, avait signalé Gartner l’an dernier. La concurrence s’accentue de la part de fournisseurs de SGBD qui incluent l’approche document en plus d’autres modèles, avait-il souligné ; sans compter ceux qui proposent une compatibilité MongoDB.
Cette remaruqe sur la concurrence accrue reste valable. Le cabinet américain y ajoute la courbe d’apprentissage nécessaire pour prendre en main le modèle MongoDB. Et le manque d’un storytelling complet l’intégration du transactionnel et de l’analytique.
Oracle, salué pour sa richesse fonctionnelle…
Autonomous AI Lakehouse, Autonomous JSON Database et Exadata Database Service font partie des SGBD cloud au catalogue d’Oracle.
L’an dernier, Gartner avait salué l’exhaustivité de l’offre (fonctionnalités + support de modèles modèles de données et de l’architecture lakehouse). Ainsi que le niveau de gestion du multicloud (offres Database@ + interconnexion avec les principaux hyperscalers) et la capacité à diffuser rapidement des nouveautés (GenAI, low code, consensus RAFT).
Cette année encore, la richesse fonctionnelle est saluée (bases de données distribuées, recherche vectorielle, framework agentique…). La diversité des options de déploiement l’est aussi. Comme l’adéquation de l’offre d’oracle aux applications critiques.
… mais peu adopté pour les déploiements lakehouse
Oracl reste perçu comme onéreux et a du travail pour « cloudifier » sa base client, avait noté Gartner l’an dernier. Il avait aussi appelé les acheteurs à s’assurer de bien interpréter l’approche « une base de données pour tout » et ce qu’elle impliquait en matière de livraison de fonctionnalités.
Cette dernière remarque est reconduite : vigilance sur cette approche, qui s’oppose aux architecture combinant les SGBD et les systèmes de data management. La question du prix – sus-évoquée – reste sensible et les clients continuent à prioriser des produits concurrents pour les déploiements lakehouse.
Snowflake a amélioré sa couverture fonctionnelle…
L’an dernier, Snowflake s’était distingué par son UI adaptée à divers profils d’utilisateurs, sa prise en charge de multiples formats sur la couche de stockage et l’extension de l’architecture lakehouse avec Iceberg et Polaris.
Cette année encore, Gartner donne un bon à l’UI. Il relève aussi l’extension fonctionnelle de l’offre (data engineering avancé via Openflow, ML/IA avec Snowpark et Cortex AI, support de Postgre apporté par l’acquisition de Crunchy Data). Et l’amélioration de la scalabilité avec les entrepôts de génération 2 (meilleur rapport qualité-prix que la gen 1 pour les workloads complexes).
… mais reste focalisé sur le batch et l’analytique
L’an dernier, Gartner avait pointé une prise en charge limitée des scénarios hybrides. Il y avait ajouté la complexité dans le partage des données entre organisations utilisatrices de Snowflake et les défis d’usabilité que posait l’intégration avec le stockage sur site via les tables externes.
Ces deux derniers aspect demeurent. D’une part, la performance n’est pas la même avec les tables externes qu’avec le stockage natif ou les tables Iceberg. De l’autre, sur le partage, il est nécessaire de bien planifier des éléments tels que les permissions, le repartage et les restrictions régionales. Gartner y ajoute l’aspect FinOps (voir ci-dessus). Et le fait que l’architecture est focalisée sur le batch et l’analytique plutôt que sur le transactionnel ou le temps réel (même s’il existe les tables hybrides et une intégration avancée de PostgreSQL).
Le couperet est tombé : IBM arrête le support du CDKTF (Cloud Development Kit pour Terraform).
Cette boîte à outils permet de générer des fichiers de configuration en utilisant des langages impératifs (TypeScript, Python, Java, C# et Go). Elle s’inspire de l’AWS Cloud Development Kit – et en réutilise des bibliothèques.
IBM estime que le projet n’a pas trouvé sa place. Il est vrai que la traction sur les canaux communautaires et au-delà est restée minimale.
Le CDKTF n’a en tout cas jamais été stabilisé. Jusqu’à la dernière version, sortie en juin 2025, les changements non rétrocompatibles sont demeurés monnaie courante.
Un tout autre contexte qu’OpenTofu
Dans ce contexte, IBM s’affirme d’autant plus ouvert à l’idée d’un fork (le code est sous licence MPL). Ce n’est effectivement pas la même histoire qu’avec OpenTofu. Ce projet concurrent de Terraform avait émergé à l’été 2023. HashiCorp, alors encore indépendant, venait de changer la lience de ses produits. Exit la MPL (Mozilla Public License), place à la BSL (Business Source License), qui a eu pour principal effet d’interdire d’« embarquer » ou d’« héberger » les éditions communautaires desdits produits dans le cadre de toute offre commerciale destinée à un usage en prod.
Lancé sous l’impulsion d’entreprises dont le modèle économique reposait au moins en partie sur Terraform, OpenTofu avait été stabilisé début 2024. Entre-temps, une autre initiative avait vu le jour : OpenBao, pensé comme un substitut à Vault, autre produit HashiCorp.
IBM est offciellement devenu propriétaire de HashiCorp en février 2025, quasiment un an après avoir annoncé son projet d’acquisition. En attendant un éventuel fork du CDKTF, il invite à utiliser la commande cdktf synth –hcl pour convertir les fichiers .tf en HCL (HashiCorp Configuration Language).
Chez VMware, fini le catalogue de prix unifié pour l’EMEA (Europe, Moyen-Orient, Afrique).
Il y a désormais deux catalogues. Respectivement pour l’Espace économique européen (UE + Islande, Liechtenstein et Norvège) et pour les autres pays de cette zone.
VVF et vSphere Enterprise+ maintenus dans l’UE, mais jusqu’à quand ?
La différence n’est pas des moindres : hors de l’EEE, les offres VVF (vSphere Foundation) et VSEP (vSphere Enterprise+) ne sont plus commercialisées.
Ne restent que VSS (vSphere Standard) et VCF (Cloud Foundation).
Le premier change de modèle : il devient un SKU sans durée déterminée, à 70 $/cœur/an – soit le tarif jusque-là appliqué pour un an d’engagement.
Le second voit son prix augmenter de 350 à 400 $/cœur/an.
En parallèle, le module complémentaire Private AI Foundation n’est plus disponible.
La nouvelle politique commerciale hors EEE impose par ailleurs le fameux minimum de 72 cœurs.
Ce minimum s’entend par ligne de commande – en d’autres termes, par édition de produit VMware. Broadcom l’appliquait déjà depuis avril… en dehors de l’EMEA. L’examen de son cas par la Commission européenne a probablement motivé cette exception et la décision de la faire perdurer dans l’EEE.
VCF comme offre unique : on y va tout droit
vSphere Enterprise+ avait disparu de la gamme VMware une première fois, quelques semaines après la fusion avec Broadcom. Il avait finalement été réintroduit en novembre 2024, sans vSAN (stockage) ni NSX (réseau).
Depuis, on l’a continûment dit en sursis. Comme vSphere Standard, qui n’est déjà plus vendu en APAC (Asie-Pacifique) depuis avril 2025 – et qui semble désormais ne plus l’être non plus en Amérique du Nord.
Ces offres sont d’autant plus sur la sellette qu’il n’est pas prévu qu’elles prennent en charge vSphere 9. Jusqu’à nouvel ordre, elles sont cantonnées au maximum à vSphere 8 (Update 3), dont le support général se termine en octobre 2027.
Les perspectives n’étaient pas beaucoup plus positives pour VVF. Surtout que VCF 9 a apporté plusieurs capacités favorisant les migrations depuis d’autres produits VMware, notamment pour l’importation NSX.
L’échéance approche : le 16 décembre 2025, la Matmut éteindra sa plate-forme data sur site.
Ce socle Spark-Hadoop avait été constitué en 2017, avec la stack open source Cloudera. Sur le papier, il est resté à son statut de PoC. Dans les faits, il est devenu de la prod.
En 2022, à l’arrivée d’un nouveau CDO, deux visions de modernisation se sont confrontées.
Le CTO prônait une plate-forme unifiée, avec un outil proche de ceux déjà en place. Une option qui assurerait un support éditeur large, mais induirait des efforts supplémentaires de développement pour les équipes data, de gestion pour les équipes de production, et de formation pour l’usage par toutes les entités.
Le CDO portait l’idée d’une plate-forme full open source – toujours on-prem – avec une multitude de fournisseurs. Il en découlerait le besoin d’assurer un support pour pléthore de services, en plus de l’aspect formation (sur des nouveaux outils : ML, orchestrateur…).
Chez S3NS, pas d’immunité au CLOUD Act… mais du chiffrement que la Matmut maîtrise
Dans ce contexte, la Matmut a étudié la possibilité d’aller chez un hyperscaler. Elle s’est tournée vers S3NS et son offre « Contrôles locaux » (récemment renommée CRYPT3NS).
Cette offre utilise des HSM (modules de sécurité matériels) fournis et hébergés par Thales. Elle « n’empêchera pas une instance américaine de demander à Google de dumper les données », a reconnu Jean-Jacques Mok, directeur de programme cloud au sein de la Direction du numérique et de l’innovation de la Matmut, lors du salon DEVOPS REX. Ce dump n’est toutefois pas fait en live, tempère-t-il : les données sont récupérées à froid. « Et ça tombe bien : c’est ce qui est crypté par le boîtier HSM. »
« Globalement, Google aura répondu aux injonctions, poursuit l’intéressé. Charge [aux États-Unis] de s’amuser ensuite à décrypter les données, [sachant que] les clés ne sont pas hébergées chez Google. » C’est effectivement la Matmut qui en a la maîtrise. Jean-Jacques Mok en donne une illustration : lorsqu’un des deux boîtiers HSM de la Matmut est tombé en panne, il a dû se rendre chez S3NS, qui ne pouvait pas lui-même en initialiser un autre.
Un socle BigQuery-Dataflow-Cloud Composer
La plate-forme montée chez S3NS s’articule autour de BigQuery, avec Dataflow pour les trasnsformations et Cloud Composer – version packagée d’Airflow – pour l’orchestration. « On a un peu déshabillé la mariée , admet Jean-Jacques Mok. C’est tout l’intérêt d’un cloud provider : on est venu chercher uniquement les services dont on avait besoin. »
Pour structurer les données, la Matmut est restée sur du classique : l’architecture médaillon (bronze = données brutes ; argent = données nettoyées ; or = données spécialisées). Il y a ajouté une zone vermeille ; qui, par rapport à la zone argent, est agnostique de la source des données.
Une autre zone, dite zone relais, a été mise en place. Une exigence « portée par les execs ». S’y trouvent toutes les données maîtres à envoyer vers le cloud.
La fin promise du « pot à bonbons »…
Le projet a duré environ un an et demi. « On [n’était] pas sur du lift & shift, mais sur une transformation de l’organisation data », précise Pascal Deshayes, président de TerraOps, qui a accompagné le projet (l’ESN a son siège à Rouen, comme la Matmut). Ne serait-ce que de par la transition depuis un système intégralement sur site, avec, entre autres, un CI/CD « pas du tout automatisé ».
Il a fallu faire avec les limites de l’offre « Contrôles locaux », tant en termes de versions que de nombre de services managés utilisables. Un avantage, néanmoins : la facilité de prise en main par les consultants habitués à GCP.
« Maintenant qu’on a des utilisateurs et de la donnée, il faut qu’on soit capable de maîtriser cette consommation », explique Jean-Jacques Mok. Aujourd’hui, l’IT à la Matmut est encore un « pot à bonbons », concède-t-il : « Tout le monde pioche dedans jusqu’à ce qu’il n’y [ait plus de budget]. »
… et des accès en « open bar »
L’offre « Cloud de confiance » – celle pour laquelle S3NS postule à la qualification SecNumCloud – est en ouverture généralisée depuis quelques mois. La Matmut ne l’a pas encore adoptée. Elle y est toutefois appelée : c’est l’une des conditions qui ont permis d’aller vers ces services.
Avec RGPD, DORA et CSRD en toile de fond, la migration est aussi l’occasion de mieux encadrer le lignage des données et les accès. « Sur l’ancienne plate-forme, c’était complètement open bar, déclare Jean-Jacques Mok. Là, on revient à un cadre plus standard : tu n’accèdes qu’à la donnée [qui t’est autorisée] et surtout, tu vas demander [aux propriétaires] le droit de la consommer ».
La Matmut ne le cache pas : quitter un mode Spark-Hadoop pour un monde orienté services managés basés sur BigQuery implique de retravailler le plan de carrière de certaines personnes. « Il faut qu’ils comprennent que le modèle SAS ne va pas durer éternellement », glisse Jean-Jacques Mok…
Langage commun, standardisation des processus, portabilité… Autant de notions dont Gaspard Plantrou, chef produit de Numspot, use pour vanter « l’indépendance numérique portée par Kubernetes ».
Cette grammaire se retrouve dans la dernière annonce de l’entreprise. Laquelle a décidé d’aller au-delà du socle OUTSCALE, en fournissant un plan de contrôle « à la Red Hat » unifiant la gestion des environnements d’infrastructure.
Kubernetes sera la base de cette plate-forme qui englobera des services managés et des fonctions data/IA (modèles, agents et RAG), avec une console et des API unifiées. Une marketplace de services préconfigurés y sera adossée. Numspot compte la déployer en Europe auprès de fournisseurs d’infrastructure, en s’alignant sur les référentiels nationaux équivalents à SecNumCloud. Une vente en marque blanche est envisagée. Des discussions sont en cours avec des sociétés en Allemagne, en Espagne et en Italie.
L’ensemble doit prendre forme au deuxième semestre 2026. Numspot promet une capacité d’adaptation « dynamique » du niveau de confiance. À commencer sur son infra chez OUTSCALE, composée d’une région eu-west « souveraine » et d’une région cloud-gov en cours de qualification SecNumCloud (J1 validé au printemps, audit J2 récemment finalisé).
Une dizaine de clients/projets référents
Pour le moment, 3 ans après sa création, Numspot a à son catalogue les services suivants :
Gestion : console et IaC
Calcul : VM et GPU NVIDIA
Réseau : VPC, IP publiques, VPN, DirectLink, load balancer
Stockage : bloc, objet, snapshots
Base de données : PostgreSQL
Conteneurs : Kubernetes et OpenShift
Sécurité/identité : IAM
Une brique d’observabilité (logging et métriques) est sur la roadmap. On y trouve aussi un registre de conteneurs, un catalogue d’images de VM, du BYOK, du MongoDB et du Redis-like, du KMS, un WAF et du CI/CD (GitLab).
Numspot liste 25 partenaires dont 10 éditeurs (ALLONIA, CEO-Vision, Cleyrop, CobolCloud, Denodo, Docaposte, Energisme, Red Hat, Veeam et VirtualBrowser). Il nomme une dizaine de clients/projets référents, dans la finance/assurance, la santé et le secteur public :
CISIRH (Centre interministériel de services informatiques relatifs aux ressources humaines)
CNP Assurances
Docaposte
Domelior (services de soins à domicile ; petite entreprise bretonne)
ERAFP (complémentaire de la fonction publique)
Maisons France services
M.I.A. Seconde (application d’adaptive learning pour les professeurs en seconde générale)
Pavillon de la Mutualité (groupe d’offre de soins mutualiste en Nouvelle-Aquitaine)
Perfecto Groupe (agence de com francilienne)
Service civique national
Union Retraite (GIP qui réunit les organismes de retraite obligatoire, de base et complémentaire)
Face à l’essor fulgurant de l’IA, les services publics ne peuvent plus rester à la porte du cloud, surtout quand les données les plus sensibles sont en jeu. Le défi : construire un cloud souverain européen qui combine niveau de sécurité maximal, agilité technologique et capacité à faire tourner des workloads d’IA à l’échelle. La […]
La bataille du cloud se joue aussi sur le CPU. Pour les hyperscalers et pour AWS en particulier, précurseur avant tout le monde, les processeurs ne sont pas que des composants essentiels à toute infrastructure informatique. Ils sont un levier direct pour vendre moins cher et consommer moins à l’échelle planétaire. Avec son nouveau Graviton5, […]
Pour accéder au catalogue Gaia-X du CISPE, attention à ne pas suivre le lien que l’association affiche sur la page d’accueil de son site.
Nous en avons fait l’amère expérience. Ledit lien pointe vers une ancienne version du catalogue… qui n’est que partiellement fonctionnelle. Certains filtres sont inopérants (localisation des services, par exemple) tandis que d’autres ne renvoient aucun résultat (tri par fournisseur, par certification, par label Gaia-X). De nombreuses fiches sont par ailleurs en doublon voire plus ; et sur chacune, le JSON source est inaccessible (erreur 503). Les contenus mêmes ne sont plus à jour, reflétant les principes de Gaia-X tels qu’ils étaient essentiellement fin 2022.
Une maintenance depuis la France
À la « bonne » adresse, la spécification Gaia-X référente est celle de mars 2025. L’enregistrement des services passe toujours par le CISPE (démarche gratuite pour les membres et les affiliés). L’exploitation et la maintenance du catalogue restent à la charge de Cloud Data Engine, SASU francilienne née en 2023, quelques semaines avant le passage en prod.
Les services listés respectent un socle minimal d’exigences – dit « conforité standard » – attendues pour pouvoir participer à l’écosystème Gaia-X. Ils peuvent être labellisés à trois niveaux supplémentaires.
Le premier comporte des exigences en matière de droit applicable, de gouvernance et de transparence. Il est obtenu sur la base d’une autocertification.
Le deuxième requiert une possibilité de traiter les données en Europe uniquement. Le troisième ajoute des critères pour assurer l’immunité aux lois extra-européennes. L’un et l’autre impliquent un audit tiers sur la protection des données et la cybersécurité ; pas sur la portabilité et la soutenabilité.
De premières offres labellisées Gaia-X niveau 3
À l’occasion du Sommet Gaia-X 2025, le CISPE a mis en lumière l’intégration d’un premier bouquet d’offres de services labellisées au niveau 3. Au nombre de 9, elles émanent de 5 fournisseurs. Dont 3 français :
Cloud Temple (IaaS open source, IaaS bare metal et PaaS OpenShift)
OVHcloud (Hosted Private Cloud by VMware)
Thésée Datacenter (hébergement dans ses deux datacenters des Yvelines)
Les étiquettes désignant les autres niveaux de conformité n’ont encore été attachées à aucun service (elles l’étaient pour quelques-uns dans l’ancienne version du catalogue).
Cloud Temple rejoint Ikoula, OVHcloud et Thésée Data Center
Côté certifications, certaines étiquettes n’ont, là aussi, pas encore été massivement attribuées. Illustration avec le code de conduite SWIPO, actuellement associé à seulement 4 services.
D’autres étiquettes, à l’instar de C5 (le « SecNumCloud allemand »), ne retournent quasiment pas de résultats, faute de fournisseurs nationaux référencés dans le catalogue. Pour le moment ils sont 13 :
Quatre français (Cloud Temple, Ikoula, OVHcloud, Thésée Data Center)
Deux espagnols (Gigas Hosting, Jotelulu)
Cinq italiens (Aruba, CoreTech, Netalia, Opiquad, Seeweb)
Un néerlandais (Leaseweb)
Un américain (AWS)
Cloud Temple – non membre du CISPE, comme OVHcloud et Thésée Data Center – et Seeweb étaient les seuls de ces fournisseurs à ne pas figurer dans l’ancienne version du catalogue*.
Les quelque 600 services référencés sont presque tous localisés dans l’UE. Les 15 exceptions (États-Unis, Canada, Australie, Singapour) sont liées à OVHcloud.
Les tags relatifs aux catégories de services visent large. « Authentification », par exemple, est attribué autant au remote desktop et au PBX virtuel de Jotelulu qu’à l’hébergement web et au Veeam d’OVHcloud.
* Son intégration « a posteriori » se ressent : elle ne respecte par l’ordre alphabétique (Cloud Temple est positionné après CoreTech dans la liste déroulante du filtre fournisseurs).
Bonsoir ! Un nouvel entretien pour que vous passiez un bon week-end enrichissant en matière d’IT et de cloud, celui de Christophe Le Lesur, co-CEO de Cloud Temple… Mais qu’est-ce donc que ce co-CEO ? Je vous en dis bien plus dans cet article :)
Des checkpoints, du replay… et ça donne des fonctions Lambda « durables ».
AWS a mis cette option en lumière lors de sa conférence re:Invent 2025. La promesse : des exécutions qui peuvent durer jusqu’à 1 an, avec une reprise fiable après interruption ou mise en pause.
Un SDK à intégrer dans le code des fonctions permet d’implémenter les primitives qui gèrent ce mécanisme. Les mises en pause peuvent se faire pour une durée déterminée. On peut aussi conditionner la reprise à un événement donné.
La facturation se fait sur trois plans :
Opérations « durables » (étapes, pauses, callbacks) : 8 $ le million
Données écrites : 0,25 $/Go
Données conservées : 0,15 $/Go/mois
Lambda en un peu moins serverless
Autre option mise en avant : les instances Lambda managées. Il s’agit ici de choisir les configurations EC2 sur lesquelles exécuter les fonctions.
On crée pour cela des « fournisseurs de capacités ». Ces fournisseurs s’exécutent dans le compte AWS, au sein d’un VPC (et au moins d’un sous-réseau). On peut en paramétrer certains aspects :
Architecture CPU
Types d’instances autorisées (liste blanche, liste noire ou sans restriction)
Nombre maximal d’instances
Mode de mise à l’échelle (manuelle ou automatique)
Clé de chiffrement EBS (éventuellement personnalisée)
Un autre modèle de concurrence…
Lorsqu’on publie une version d’une fonction associée à un fournisseur de capacité, Lambda lance des instances managées (3 par défaut, pour la résilience). Ou bien il en utilise des existantes si les ressources sont suffisantes pour accueillir l’environnement d’exécution.
De même, un environnement d’exécution peut gérer plusieurs invocations en parallèle (64 maximum). Le modèle de concurrence est donc différent de celui de Lambda « standard » (une invocation = un environnement).
… de sécurité…
Ce système suppose que la sûreté des threads, la gestion d’état et l’isolation du contexte doivent être gérés différemment en fonction du contexte.
Les fournisseurs de sécurité constituent en fait la limite de confiance. Avec les instances Lambda managées, les fonctions s’exécutent effectivement dans des conteneurs, lesquels ne fournissent pas le même niveau de sécurité que la techno de micro-VM Firecracker utilisée en standard.
… de scaling…
Avec les instances Lambda managées, pas de démarrage à froid. La mise à l’échelle est asynchrone, sur la base de signaux de consommation CPU. Dans cet esprit, l’option est donc à réserver aux workloads dont le trafic est prévisible. AWS ne garantit d’ailleurs pas la stabilité si la charge fait plus que doubler dans un intervalle de 5 minutes.
Quatre paramètres influent sur la mise à l’échelle :
Quantités de mémoire et de vCPU allouées à une fonction
Concurrence maximale par environnement
Cible d’utilisation de ressources
Types d’instances autorisés
… et de tarification
Les instances Lambda managées sont facturées au prix d’EC2 à la demande… avec 15 % de frais supplémentaires. L’option permet néanmoins d’exploiter d’éventuelles remises (savings plans, instances réservées…). Il faut ajouter des frais de 0,20 $ par million de requêtes.
Plus besoin de shards ni de requêtes fédérées : vous pouvez consolider vos données vectorielles en un seul index.
AWS en fait l’un des arguments de S3 Vectors, lancé en disponibilité générale lors de la re:Invent.
Avec S3 Vectors, la promesse d’un index unique
Le service était en previewdepuis juillet. Il apporte une gestion native des vecteurs dans S3, avec un type de bucket spécifique. Sur le papier, c’est une alternative moins onéreuse à Aurora Serverless et OpenSearch Serverless, en contrepartie de temps de réponse allongés (« sous la seconde », affirme AWS).
La préversion permettait de stocker jusqu’à 50 millions de vecteurs par index (et 10 000 index par bucket). Avec la version commerciale, on passe à 2 milliards, d’où l’argument de la consolidation. Autre seuil relevé : le nombre maximal de résultats par requête (100 désormais, contre 30 en preview). Quant à la latence, elle est maintenant « fréquemment sous les 100 ms ».
S3 Vectors a une intégration avec Bedrock Knowledge Bases (RAG) et avec Amazon OpenSearch (utilisation comme moteur sur les clusters managés ou injection d’un snapshot dans la version serverless).
L’accélération GPU activée sur OpenSearch
En parallèle, une option d’accélération GPU fait son entrée sur l’OpenSearch d’AWS. Promesse : construire des bases vectorielles « jusqu’à 10 fois plus vite » pour un quart du prix traditionnel, grâce à un usage optimisé de l’infra. En complément, il devient possible de régler les niveaux de rappel et de latence souhaités.
Une mémoire épisodique pour les agents Bedrock
À l’occasion de la re:Invent, il y a aussi du nouveau dans Bedrock AgentCore. Cette offre, lancée à l’été 2025, est dans la lignée de Bedrock Agents. Elle en a étendu les capacités (gestion native de MCP et contrôle plus fin de la mémoire, par exemple) et en a désagrégé la plupart en modules indépendants, par ailleurs « détachés » de Bedrock de sorte qu’ils prennent en charge des technologies non disponibles sur la plate-forme.
Voilà Bedrock AgentCore doté d’une forme de mémoire épisodique. Avec cette stratégie, les agents capturent des « épisodes structurants » (contexte, processus de raisonnement, actions, résultats). Ils sont censés pouvoir ainsi agir de façon plus cohérente lorsqu’ils rencontrent des situations similaires.
AWS dote aussi AgentCore de la diffusion audio bidirectionnelle. Lors des interactions vocales, l’agent peut être interrompu et s’adapter au nouveau contexte sans avoir à terminer son action au préalable.
Un service managé de supervision est également ajouté, mais pour le moment en preview. On peut y intégrer des évaluations personnalisées en plus de celles livrées pour analyser des indicateurs tels que la précision, l’utilité, la concision et la sûreté. Les résultats sont délivrés dans CloudWatch.
Autre preview : celle de la fonctionnalité Policy in AgentCore. Elle permet d’intercepter les appels d’outils sur la passerelle et de leur appliquer des stratégies définies en langage naturel ou avec Cedar.
Les derniers modèles Mistral et Gemma ajoutés sur Bedrock
AWS a aussi profité de la re:Invent pour rappeler les derniers ajouts de modèles ouverts sur Bedrock. Parmi eux :
Mistral Large 3, Ministral 3 (3B, 8B, 14B), Magistral Small 1.2, Voxtral Mini 1.0, Voxtral Small 1.0
Gemma 3 (4B, 12B, 27B)
Kimi K2 Thinking (de Moonshot AI)
MiniMax M2 (de MiniMax AI)
Nemotron Nano 2 9B et une version « vision » 12B (de NVIDIA)
GPT-OSS-safeguard 20B et 120B (modèles de modération de contenu)
Qwen3-Next-80B-A3B et Qwen3-VL-235B-A22B
Nova Sonic : une deuxième génération plus polyglotte
Amazon enrichit aussi sa propre famille de modèles Nova. Avec notamment Nova 2 Sonic.
La première génération de ce modèle de reconnaissance et de synthèse vocales avait été lancée en avril. La deuxième gère mieux les entrées alphanumériques, les énoncés courts, les accents, le bruit de fond et l’audio qualité téléphonie (8 kHz). Avec elle arrivent les « voix polyglottes » (capacité à changer de langue au milieu d’une conversation), les appels d’outils asynchrones et un réglage de sensibilité pour la détection de voix (ce qui laisse plus ou moins de temps à l’utilisateur pour finir sa phrase).
AWS lance Nova dans le bain de l’automatisation web
Sous la marque Nova Forge, AWS permet de continuer l’entraînement de ses propres modèles à partir de divers checkpoints, en utilisant des jeux de données spécialisés « sur étagère » ou en en important. L’ensemble repose sur l’outillage SageMaker AI et permet d’effectuer éventuellement de l’apprentissage par renforcement.
On trouve aussi un modèle Amazon (Nova 2 Lite) à la base de Nova Act, service d’automatisation agentique pour les navigateurs web. Il est intégré avec le framework d’ochestration Strands Agents.
Les données synthétiques sous l’angle privacy
Les serveurs de tracking MLflow qu’on peut greffer depuis l’an dernier à SageMaker pour superviser les expérimentations ML disposent désormais d’une option serverless. Avec la possibilité de partager des instances entre domaines et comptes AWS.
Le service Clean Rooms (salles blanches de données) permet quant à lui maintenant de créer des jeux de données synthétiques (tabulaires, destinées à entraîner des modèles de régression et de classification ; pas des LLM). Le système utilise un modèle qui reproduit les patterns statistiques du dataset d’origine tout en éliminant les données identifiantes. En ce sens, il est présenté comme une alternative aux techniques d’anonymisation.
AI Factories : AWS s’approprie aussi la notion
AWS s’approprie le concept des AI Factories en lançant une offre sous ce nom. On n’en sait pas grand-chose à l’heure actuelle, sinon qu’elle doit permettre de déployer des clusters IA managés (puces Trainium et NVIDIA + services AWS) dans les datacenters des clients, « comme une région AWS privée ». Premier client référent : l’entreprise saoudienne HUMAIN, qui va installer sur place une « zone IA » avec jusqu’à 150 000 GPU.
Des fonctions Lambda « durables »
Les fonctions Lambda durables ne sont pas spécifiques aux workloads IA, mais elles sont susceptibles de faciliter leur exécution.
Par « durables », il faut entendre « dont la durée de vie peut atteindre 1 an ». Elle peuvent effectivement être mises en pause jusqu’à ce que des conditions spécifiques soient remplies (typiquement, des événements externes). Seul le temps de calcul actif est facturé.
Un SDK s’intègre au code des fonctions pour pouvoir implémenter ces pauses. Ainsi que des « étapes » permettant de ne pas reprendre l’exécution depuis le début en cas d’échec.
Alphabet, maison mère de Google, a retiré sa plainte antitrust déposée auprès de la Commission européenne contre les pratiques cloud de Microsoft, une semaine après l’ouverture par Bruxelles de trois enquêtes de marché sur AWS et Microsoft Azure dans le cadre du Digital Markets Act (DMA).
Désormais, Google affirme vouloir contribuer aux travaux des autorités dans ce cadre plus large, et indique rester engagé dans le dialogue avec les décideurs publics pour faire évoluer les règles de concurrence et les conditions de licences dans le cloud.
Google avait saisi la Commission européenne en 2024 en accusant Microsoft d’utiliser des conditions de licences logicielles pour enfermer les clients dans sa plateforme Azure. La plainte mettait en avant des pénalités financières, des restrictions d’usage de Windows Server et des obstacles d’interopérabilité pour les entreprises souhaitant exécuter les logiciels Microsoft sur des clouds concurrents ou migrer leurs charges de travail hors d’Azure.
Ces griefs faisaient écho à des préoccupations déjà exprimées par l’association professionnelle CISPE, soutenue par Amazon, qui avait elle-même déposé puis retiré une plainte contre Microsoft après un accord transactionnel en 2024.
Enquêtes de l’UE sur le cloud
Les enquêtes ouvertes par la Commission visent à déterminer si AWS et Azure doivent être désignés comme « contrôleurs d’accès » (gatekeepers) pour leurs services cloud, alors même qu’ils ne remplissent pas automatiquement tous les seuils chiffrés prévus par le DMA. Bruxelles veut évaluer si certaines caractéristiques du secteur (effets de verrouillage, coûts de sortie, barrières techniques au multicloud) renforcent le pouvoir de marché de ces hyperscalers au détriment de la concurrence.
Une troisième enquête examinera si les dispositions actuelles du DMA suffisent à traiter les pratiques susceptibles de limiter la contestabilité et l’équité dans le cloud, ou si des ajustements réglementaires sont nécessaires. La Commission a indiqué que ces travaux s’inscrivent dans un effort plus large pour adapter les outils de concurrence numérique aux spécificités de l’informatique en nuage dans l’UE.
Les grandes entreprises combinent plusieurs clouds pour répartir les workloads, optimiser les coûts, rapprocher les données des utilisateurs et limiter les risques de dépendance à un seul fournisseur. Jusqu’ici, relier ces environnements impliquait soit l’usage d’Internet public sans garanties de bande passante, soit des montages de connectivité privée complexes, longs à déployer et coûteux à exploiter.
L’alliance entre AWS et Google Cloud combine le nouveau service AWS Interconnect- multicloud et Google Cloud Cross-Cloud Interconnect pour proposer une connectivité privée et automatisée entre les deux environnements. Elle fournit une connectivité entre VPC AWS et VPC/VPC‑SC Google Cloud, intégrée de manière native aux consoles et APIs des deux fournisseurs.
Google Cloud avait déjà positionné Cross-Cloud Interconnect comme brique clé de son architecture “Cross-Cloud Network”, permettant de relier Google Cloud à AWS, Azure, Oracle Cloud Infrastructure et d’autres MSP via des liens privés à haut débit.
Les deux acteurs mettent en avant une automatisation poussée : les clients peuvent réserver de la capacité dédiée à la demande et établir la connectivité en quelques minutes, sans gérer directement le câblage, les circuits ni l’infrastructure physique sous‑jacente.
L’annonce inclut une spécification ouverte pour l’interopérabilité réseau entre clouds décrite comme un standard commun de connectivité privée qui vise à réduire la complexité de l’adressage, du routage et de la gestion des politiques réseau entre environnements AWS et Google Cloud.
L’objectif est de permettre à d’autres fournisseurs de cloud d’implémenter le même modèle, afin d’étendre ce socle d’interopérabilité au‑delà du seul duo AWS–Google Cloud. Cette ouverture pourrait favoriser l’émergence d’un écosystème où les clouds majeurs s’alignent sur des standards communs de connectivité privée, à l’image de ce qui existe déjà pour certains protocoles réseau et interfaces de peering.
Caractéristiques techniques mises en avant
Sur le plan technique, Cross-Cloud Interconnect fournit des liaisons privées avec des capacités de 10 ou 100 Gbit/s dans de nombreux sites mondiaux, gérées par Google côté physique, avec des métriques de performance détaillées (latence, pertes de paquets, temps de trajet aller‑retour).
Les documents techniques de Google décrivent un modèle de double attachement (primaire et redondant) et l’utilisation de BGP pour l’échange de routes entre Google Cloud et AWS, avec des exigences de haute disponibilité.
AWS Interconnect-multicloud, en préview, est présenté comme un service managé offrant des connexions privées simples, résilientes et à haut débit vers d’autres clouds, intégrées avec les outils réseau et d’observabilité AWS.
L’intégration avec Cross-Cloud Interconnect vise à abstraire la gestion des ports, des circuits et des délais de provisioning, en exposant une expérience de type “cloud‑native” dans les deux consoles.
Cas d’usage et bénéfices clients
L’alliance cible des scénarios où les données ou applications sont réparties entre AWS et Google Cloud, par exemple pour des plateformes analytiques, des charges IA/ML, ou l’intégration de SaaS opérant sur plusieurs clouds.
Un exemple cité concerne l’intégration de Salesforce Data 360, qui nécessite des ponts privés robustes entre différents environnements pour alimenter des cas d’usage d’IA et d’analytique sur des données réparties.
Pour les clients, les bénéfices mis en avant sont la réduction du temps de mise en service des liaisons, la simplification opérationnelle (moins de gestion d’infrastructure physique) et de meilleures garanties de performance que l’Internet public. L’approche standardisée doit aussi faciliter la gouvernance réseau et la sécurité dans des environnements multicloud complexes, où les architectures doivent concilier segmentation, conformité et performance de bout en bout.
Sous le feu des critiques des associations professionnelles et scrutés par les régulateurs, les deux grands CSP américains engagent un mouvement vers un modèle où la connectivité inter‑cloud devient un service managé de première classe, au même titre que le compute ou le stockage, plutôt qu’un assemblage de liens télécoms et de configurations spécifiques.
Reste à observer dans quelle mesure les autres fournisseurs adopteront la spécification proposée et comment les intégrateurs réseau et opérateurs télécoms adapteront leurs offres face à cette montée en puissance de la connectivité multicloud native.
Le plan de contrôle de Route 53 n’est plus tout à fait monorégion.
AWS l’a effectivement répliqué en partie. Et ainsi réduit la dépendance à la région cloud us-east-1.
En toile de fond, l’incident d’octobre. Il a pris racine dans cette région cloud, (re)mettant en lumière le point faible qu’elle constitue. Entre autres, donc, parce que quantité de services y ont leur plan de contrôle.
Une récupération « accélérée »…
La réplication partielle de celui de Route 53 se traduit par une option de « récupération accélérée ». On peut l’activer pour chaque zone hébergée publique (conteneur d’enregistrements définissant l’acheminement du trafic d’un domaine spécifique sur le réseau Internet). Une copie de la zone est alors conservée dans la région us-west-1.
… avec un RTO de 60 minutes
En cas d’indisponibilité prolongée dans la région us-east-1, une bascule est censée s’effectuer… dans un délai de 60 minutes. On n’a alors pas accès à l’ensemble des méthodes API. Mais les principales sont disponibles : listage des zones, des enregistrements et des ensembles de délégation, soumission et suivi de changements, etc.
En période de bascule, il n’est pas possible de créer de zones, ni d’en supprimer. On ne peut pas non plus (dés)activer la signature DNSSEC. Et les connexions AWS PrivateLink ne fonctionnent pas. Par après, pour supprimer une zone, il faut d’abord désactiver l’option de « récupération accélérée ». Laquelle, pour préciser, ne concerne pas le volet DNS privé de Route 53.
Connexion
