Voici la traduction française du contenu HTML :

« `html

8 Min. temps de lecture

Lors de la Cloud Next 2026, Google a annoncé des composants qui transforment le multi-cloud d’une théorie architecturale en une décision opérationnelle. Les DACH-CIO qui pensent encore que la stratégie cross-cloud échoue à cause des coûts d’egress et des silos de données devraient y regarder de plus près : le levier n’est plus le compute, mais l’emplacement des données et le coût de leur déplacement.

Les points clés en bref

• Cross-cloud Lakehouse (anciennement BigLake) permet désormais des requêtes sur des sources de données AWS, Azure et GCP sans réplication complète, la couche de mise en cache cross-cloud stocke la première lecture dans le système d’origine et réduit les frais d’egress pour les requêtes récurrentes.
• Gemini Enterprise Agent Platform regroupe les registres d’agents, les registres de compétences et la gouvernance dans une couche conçue explicitement pour les déploiements multi-cloud, non pas une nouvelle stack de fournisseur, mais un plan de contrôle au-dessus des workloads existants.
• Agentic Data Cloud fait de la gestion des données une question stratégique : celui qui contrôle les tables maîtres contrôle la stack d’agents qui les utilise.
• AWS et Google ont annoncé séparément une coopération pour les déploiements multi-cloud, ce qui rend les workloads techniquement plus portables entre les hyperscalers, mais intensifie la course pour le contrôle de la couche données.
• Conséquence opérationnelle pour les DSI : La question n’est plus « dans quel cloud », mais « où reste le maître, où peut-on calculer, qui assume le risque du cache ».

L’egress, une taxe cachée sur toute idée de multi-cloud

Ceux qui ont sérieusement tenté ces trois dernières années d’étendre des workloads sur deux hyperscalers connaissent la réaction du côté des DAF : les coûts d’egress. AWS, Azure et GCP facturent des montants par gigaoctet de trafic sortant qui, cumulés sur un pipeline de 80 téraoctets par mois, atteignent rapidement cinq chiffres. Ces tarifs ne sont pas un hasard, ils représentent ce à quoi ressemble le vendor lock-in dans une ligne de bilan. Les données stockées une fois dans un bucket en ressortent à prix d’or.

La fonction de mise en cache cross-cloud présentée par Google lors de la Next 2026 s’attaque précisément à ce problème. Elle stocke localement dans le cache du lakehouse les données qui ont été transférées une fois au-delà de la frontière cloud, de sorte que les requêtes récurrentes n’entraînent plus d’egress à chaque fois. Pour une configuration de reporting qui consomme quotidiennement le même jeu de données depuis un bucket S3, cela signifie idéalement un ordre de grandeur en moins de trafic sortant. La vérité architecturale derrière cela : le caching n’est pas nouveau, mais lorsqu’un hyperscaler le propose comme service natif au-delà des frontières cloud, cela modifie radicalement le calcul de ROI pour le cross-cloud.

Un exemple DACH rend l’ampleur tangible

Un groupe industriel de taille moyenne qui collecte ses données machine dans AWS S3 et les analyse via GCP BigQuery génère, selon ses propres chiffres, environ 12 To d’egress cross-cloud par mois. Aux tarifs actuels d’AWS, cela représente près de 1 080 euros par mois, uniquement pour le déplacement des données. Avec un taux de cache hit de 70 % sur les requêtes d’analytics récurrentes, le trafic sortant chute à environ 3,6 To, et la facture à environ 330 euros. Sur l’année, cela représente une différence de 9 000 euros pour un seul flux de données. Ceux qui gèrent plusieurs pipelines de ce type parlent rapidement d’effets à six chiffres.

Du silo de données au Lakehouse sans frontières

Le deuxième changement provient du Lakehouse lui-même. Google qualifie cette nouvelle variante de « borderless » (sans frontières) : la couche Lakehouse peut référencer des tables physiquement situées dans S3 ou Azure Data Lake, sans qu’il soit nécessaire de répliquer les données dans BigQuery. Pour les équipes d’ingénierie, cela signifie : moins d’ETL, moins de jobs de synchronisation, moins de points où une dérive de schéma peut casser un rapport. Pour les DSI, cela signifie que la question de savoir où les données « doivent résider » peut être réexaminée sur les plans politique et contractuel, sans que chaque réponse ne déclenche immédiatement un projet de migration.

L’envers de la médaille : celui qui contrôle la couche Lakehouse contrôle la logique de requête. Google se positionne ici comme un intermédiaire neutre, ce qui est stratégiquement judicieux, car son propre moteur de calcul devient le moteur de requête standard sur des buckets externes. AWS et Azure ont des initiatives comparables, mais sont chacun plus fortement ancrés dans leur propre écosystème. Le choix de la couche Lakehouse qui deviendra le standard de facto dans une entreprise DACH est donc une décision stratégique de fournisseur avec une longue durée de vie.

« Le multi-cloud était jusqu’à présent une réponse de conformité. Avec les nouvelles couches de Lakehouse et de caching, cela devient une option architecturale, mais le choix de qui pilote la couche données reste une décision de verrouillage à long terme. »

Stack d’agents : qui contrôle les données contrôle les compétences

La Gemini Enterprise Agent Platform et l’Agentic Data Cloud représentent l’annonce la plus stratégique. Google regroupe le registre des agents, le registre des compétences, le registre des outils et la gouvernance dans une couche explicitement conçue pour piloter conjointement les workloads AWS, Azure et GCP. Ainsi, Google ne mise pas sur « migrez vos applications chez nous », mais sur « nous devenons le plan de contrôle de vos applications existantes ». Du point de vue du DSI, cela est attractif car cela modifie le rapport d’investissement : au lieu de financer un projet de migration de workload, on paie un abonnement de contrôle abstrait.

Cependant, cela ne fait que déplacer le risque d’un niveau vers le haut. Celui qui découvrira dans deux ans que le registre des agents et l’inventaire des outils se trouvent chez Google vivra le même effet de verrouillage avec « nous changeons de plan de contrôle » que le multi-cloud était censé éviter. La seule réponse durable : imposer des standards ouverts pour les définitions d’agents, les schémas de compétences et les manifestes d’outils, avant que des formats propriétaires ne créent des faits accomplis.

La conformité s’invite dans la couche cross-cloud

Ce qui passe souvent inaperçu dans le débat architectural : le RGPD, NIS2 et l’AI Act européen ne prescrivent pas de fournisseur cloud, mais ils dictent où les données sont traitées et qui peut y accéder. Une couche de caching cross-cloud qui conserve des données personnelles dans un cache GCP, alors que la table source se trouve dans un data center AWS allemand, n’est pas trivial sur le plan de la protection des données. La question opérationnelle est : quelle catégorie de données peut être mise en cache, et où ? Et comment le cycle de vie du cache est-il documenté lorsque l’autorité de régulation pose des questions ?

La réponse des fournisseurs sera un « caching piloté par politiques », c’est-à-dire des règles définissant quelles classes de données peuvent franchir quelles frontières cloud. En pratique, cela signifie qu’un schéma de classification des données doit être en place avant la première mise en production d’un pipeline cross-cloud. Celui qui reporte cette étape s’expose à générer des constats d’audit.

Trois questions à se poser avant la prochaine étape multi-cloud

1. Où se trouvent les données sources, et où peuvent se trouver leurs copies ? Le caching semble être une question de performance, mais c’est une question de conformité. Sans classification des données, pas de cache cross-cloud.

2. Quel moteur de requête deviendra le standard ? Les couches Lakehouse ont une demi-vie de cinq à dix ans. Le choix de savoir si BigQuery, Athena, Synapse ou Snowflake deviendra le chemin de requête dominant est une décision stratégique de fournisseur, pas une décision d’outillage.

3. Qui contrôle le plan de contrôle des agents ? Si le registre des agents et l’inventaire des outils se trouvent chez un hyperscaler, le multi-cloud est efficace au niveau du calcul, mais centralisé au niveau de l’intelligence. Il faut engager dès maintenant les discussions sur les standards ouverts, pas dans deux ans.

Foire aux questions