AWS et Google Cloud lancent une preview multicloud commune

AWS et Google Cloud ont lancé en avril 2026 un service commun de réseau multicloud en phase de prévisualisation. L’annonce faite lors de la re:Invent positionne les deux hyperscalers de manière inhabituellement proche et vise un problème que de nombreuses entreprises DACH connaissent depuis des années : les interconnexions complexes entre les clouds, qui sont pénibles à exploiter. Microsoft Azure devrait suivre fin 2026. État : 14 avril 2026.

Les points clés en bref

Ce qu’AWS et Google ont concrètement annoncé

Concrètement, il s’agit d’un plan de contrôle commun pour les connexions privées entre les VPC d’AWS et de Google Cloud. Le service est initialement disponible dans trois régions, dont Francfort. Les clients peuvent connecter des sous-réseaux via un workflow unifié, sans avoir à gérer en parallèle Direct Connect et Cloud Interconnect.

Pour les équipes de plateforme qui exploitent des configurations multicloud sous charge depuis 2024, il s’agit d’un changement pertinent. Les détails séparent les promesses marketing de l’utilité opérationnelle. Pour les plans 2026, il est utile de jeter un œil lucide sur ce qui fonctionne déjà aujourd’hui.

Selon l’annonce, la collaboration simplifie la mise en place de connexions privées entre les deux clouds. Au lieu de configurer séparément Direct Connect et Partner Interconnect, un layer de réseau commun doit abstraire les deux côtés. La prévisualisation est initialement disponible dans trois régions. Outre Francfort, il s’agit selon les rapports de CIO Dive de deux régions américaines.

Techniquement, la valeur réside dans la réduction de la surcharge de configuration. Aujourd’hui, les équipes de plateforme devaient gérer séparément les sessions BGP, les chemins AS et les tunnels VPN des deux côtés. Le nouveau service rassemble cela dans une abstraction commune. Pour la première version, il y a : la prise en charge de la connectivité Layer 3, mais pas encore de synchronisation automatique des politiques entre les groupes de sécurité AWS et les règles de pare-feu Google Cloud.

Important pour la classification : l’annonce s’inscrit dans une série de mouvements qu’AWS et Google Cloud ont effectués sur le marché allemand depuis fin 2025. L’interconnexion de Francfort de mars était le précurseur technique. La prévisualisation actuelle apporte le layer de contrôle. Ceux qui lisent chronologiquement les annonces d’infrastructure des six derniers mois voient une direction claire : les deux hyperscalers veulent que le multicloud ne soit plus considéré comme une solution de secours, mais comme un standard.

Selon Info-Tech Research Group, AWS détient environ 32 % de part de marché mondial, Azure se situe à 23 %, et Google Cloud à 11 %. La collaboration a justement du sens : AWS n’a pas besoin de céder du marché à Google, et Google gagne en retour l’accès aux déploiements existants natifs d’AWS. Pour les entreprises DACH, l’écosystème de centre de données de Francfort est ainsi le bénéficiaire immédiat.

Ce qui est réalité aujourd’hui et ce qui reste du marketing

Trois choses doivent être clarifiées avant de prendre une décision. Premièrement : Preview signifie Preview. Il n’y a pas de SLA, la disponibilité régionale peut changer et le nombre de clients est confidentiel. Qui mise sur ce service pour des pipelines de données multicloud productifs assume un risque qui est difficile à couvrir sur le plan opérationnel.

Deuxièmement : l’abstraction concerne le réseau, pas l’identité. Les politiques IAM doivent toujours être modélisées séparément dans les deux clouds. Qui veut mettre en place un Single-Sign-On et des comptes de service cross-cloud de manière propre se retrouve rapidement avec Terraform ou des couches d’identité fédérées dédiées. L’annonce ne change rien à cela. Elle réduit la surcharge sur la couche 3 et en dessous, pas sur la couche 7.

Troisièmement : Azure manque à l’appel. La feuille de route officielle prévoit fin 2026 pour l’intégration avec Microsoft. D’ici là, le cas à trois clouds reste un processus séparé. Qui déploie des workloads entre AWS, Azure et Google Cloud doit continuer à planifier de manière distincte. Pour les entreprises ayant des workloads existants principalement sur Azure (Office 365, Dynamics, nombreuses intégrations SaaS), cela signifie que l’avantage réseau de la nouvelle Preview reste théorique jusqu’à l’intégration d’Azure.

Sur le plan opérationnel, cela signifie pour la plupart des organisations informatiques DACH : la nouvelle Preview est intéressante en tant que signal et champ d’expérimentation, mais pas en tant que composant de production. Qui prévoit une stratégie à deux clouds avec AWS et Google Cloud pour 2026 peut intégrer l’abstraction dans la réflexion sur l’architecture. Qui a Azure dans son mix continue de planifier avec des fournisseurs tiers établis comme Megaport ou Equinix Fabric.

Ce que les équipes de plateforme en DACH devraient vérifier maintenant

Pour la plupart des organisations informatiques dans l’espace germanophone, trois étapes concrètes valent la peine d’être franchies. La première est un état des lieux : quels workloads s’exécutent aujourd’hui via des connexions multicloud et quel est l’effort de configuration associé ? Si cela coûte moins de 10 pour cent du temps de travail de la plateforme, la préversion n’est pas une priorité. Si l’effort est plus élevé, un banc d’essai à Francfort est intéressant.

La deuxième étape consiste à comparer avec les alternatives existantes. Megaport, Equinix Fabric et Console Connect proposent depuis des années des interconnexions cross-cloud. La différence avec la nouvelle collaboration entre AWS et Google réside dans le modèle de tarification et la couche de gestion, et non dans une technique fondamentalement nouvelle. La comparaison DACH des trois hyperscalers montre les principales différences en matière de fonctionnalités réseau et de tarification.

La troisième étape concerne la stratégie de workload. Une couche multicloud simplifiée réduit les coûts opérationnels pour les architectures distribuées. Mais elle ne rend pas superflue la réinstallation dans le cloud. Ceux qui se posent la question en 2026 de savoir quels workloads doivent être rapatriés dans leurs propres centres de données trouveront dans l’analyse du modèle TCO de réinstallation dans le cloud un cadre structuré pour cela.

Un quatrième thème apparaît de plus en plus souvent dans les discussions de projet : la conformité. Ceux qui sont évalués selon NIS2 ou DORA doivent discuter de l’abstraction du réseau avec les auditeurs. La responsabilité des déclarations d’incident incombe toujours aux deux fournisseurs de cloud individuellement. Un plan de contrôle commun ne modifie pas les voies de déclaration, mais ajoute simplement une couche d’abstraction supplémentaire que la gouvernance informatique doit évaluer.

Comparaison avec les offres d’interconnexion multicloud existantes

L’annonce ne tombe pas dans le vide. Depuis au moins cinq ans, il existe un marché pour les interconnexions cross-cloud, qui peut être divisé en trois catégories. Les courtiers en réseau comme Megaport et Equinix Fabric proposent des connexions directes virtuelles entre tous les grands hyperscalers. Ils sont physiquement présents dans les hôtels de carriers et vendent la connectivité de couche 2 en tant que service. Les fournisseurs de colocation comme NTT ou Interxion étendent cela à des connexions physiques cage-to-cage. Les services SD-WAN natifs du cloud comme Cisco Multicloud Defense ou Aviatrix construisent une couche logicielle par-dessus et apportent leurs propres moteurs de politique.

La collaboration entre AWS et Google entre dans une quatrième catégorie : la coopération native entre hyperscalers. La différence réside dans la profondeur de l’intégration et le prix. Une configuration Megaport coûte pour une entreprise DACH typique avec deux régions cloud environ 2 000 à 4 000 euros par mois, selon la bande passante et la redondance. La collaboration entre AWS et Google sera probablement en dessous, car aucune tierce partie ne gagne d’argent. Les chiffres exacts manquent jusqu’à présent.

Pour les entreprises ayant des contrats Megaport ou Equinix existants, rien ne change à court terme. Les contrats continuent à courir, la fonctionnalité reste plus large. Mais ceux qui mettent en place une nouvelle stratégie multicloud en 2026 et n’ont qu’AWS et Google Cloud dans leur plan devraient évaluer l’option native dès que la disponibilité générale sera atteinte.

Ce qui est réaliste ensuite

Les trois à six prochains mois montreront si la préversion est techniquement viable. Trois points d’observation sont décisifs. Stabilité de la disponibilité régionale : si l’une des trois régions de démarrage tombe en panne, la confiance dans l’architecture globale diminue nettement. Extension à d’autres dépendances de Francfort : eu-central-2 (Zurich) sera-t-elle ajoutée ou restera-t-on à eu-central-1 ? La réponse décidera si les clients suisses ayant des exigences de résidence des données pourront participer. Clarification sur le calendrier Azure : si la date limite de fin 2026 pour Microsoft est respectée, le trio d’abstraction de réseau est réaliste. Sinon, la préversion reste un outil AWS-Google avec un rayon d’action limité.

Pour les PME allemandes ayant une stratégie cloud dominée par AWS, la préversion offre un champ d’apprentissage. Un VPC de test à Francfort avec un homologue Google Cloud, connecté via le nouveau service, ne coûte pas de budgets notables et montre en fonctionnement combien la surcharge opérationnelle est réellement économisée grâce à l’abstraction. Les résultats alimenteront les décisions d’architecture pour 2027, année où Azure sera également inclus.

Risques et questions ouvertes

Aussi appréciable que soit la simplification, quelques risques subsistent. Le premier concerne le verrouillage du fournisseur au niveau de la couche réseau. Celui qui construit son architecture multicloud sur un service orchestré par l’un des deux hyperscalers a certes réduit sa dépendance, mais ne l’a pas éliminée. L’abstraction ne fonctionne que dans les limites définies conjointement par AWS et Google. Les fonctionnalités qui n’existent que dans l’un des deux clouds restent séparées.

Le deuxième risque réside dans le modèle de support. En cas de problème, la question classique du multi-fournisseur se pose : quel support est responsable ? L’annonce mentionne un modèle d’escalade commun. La façon dont cela fonctionne dans la pratique en cas d’incidents réels de niveau P1 est la véritable mise à l’épreuve. Les expériences tirées de coopérations comparables montrent que les processus de support communs nécessitent 6 à 12 mois pour fonctionner réellement sans heurts.

Le troisième point ouvert concerne la feuille de route. Une intégration IAM sera-t-elle disponible en 2027 ? La synchronisation des politiques et la fédération des politiques réseau seront-elles étendues à la couche 7 ? Sans ces extensions, le service reste un outil réseau, et non une plateforme de gestion multicloud. Cela n’est pas négatif – c’est simplement un positionnement clair que les architectes informatiques doivent connaître avant de s’appuyer dessus.

Recommandation d’architecture pour les projets 2026

Celui qui planifie actuellement une nouvelle construction cloud ou refactore une architecture existante peut appliquer trois lignes directrices. Premièrement : définir la couche réseau sur des standards ouverts. Les abstractions des hyperscalers sont pratiques, mais une base Terraform ou Crossplane reste la fondation la plus stable. Deuxièmement : séparer la couche d’identité du réseau. Celui qui résout l’authentification unique via des fournisseurs dédiés comme Okta, Entra ID ou Keycloak reste plus flexible en cas de changement de fournisseur cloud. Troisièmement : modéliser les modèles de coûts avant qu’ils ne soient créés. Une connexion multicloud simplifiée réduit les coûts d’exploitation, mais peut augmenter les coûts de transfert de données si elle est utilisée de manière trop généreuse. Un modèle TCO soigneusement calculé pour une durée de 24 mois fournit une base de décision plus solide que toute annonce de prix des hyperscalers.

Le quatrième point concerne la surveillance. Celui qui connecte deux clouds via un plan de contrôle abstrait doit combiner l’observabilité des deux côtés. Les configurations basées sur Prometheus avec Grafana comme couche frontale unifiée se sont avérées pratiques chez les PME de la région DACH. Une plateforme d’observabilité multicloud dédiée comme Datadog ou Dynatrace ne vaut la peine que pour une complexité de charge de travail que la plupart des PME n’atteignent de toute façon pas.

Foire aux questions

Crédit image de titre : Pexels / Brett Sayles