8 min de lecture<\/p>\n
Google a annonc\u00e9 lors de la Cloud Next 2026 des briques qui font passer le multi-cloud de la th\u00e9orie architecturale \u00e0 la d\u00e9cision op\u00e9rationnelle. Tout DACH-CIO qui croit encore qu’une strat\u00e9gie cross-cloud \u00e9choue \u00e0 cause des co\u00fbts d’egress et des silos de donn\u00e9es devrait y regarder de tr\u00e8s pr\u00e8s : le levier se situe aujourd’hui dans l’endroit o\u00f9 r\u00e9sident les donn\u00e9es et dans le co\u00fbt de leur d\u00e9placement.<\/strong><\/p>\n Qui a s\u00e9rieusement tent\u00e9 ces trois derni\u00e8res ann\u00e9es de r\u00e9partir ses workloads sur deux hyperscalers conna\u00eet le r\u00e9flexe du camp des CFO : les co\u00fbts d’egress. AWS, Azure et GCP facturent chaque gigaoctet de trafic sortant \u00e0 des tarifs qui, cumul\u00e9s sur un pipeline de 80 t\u00e9raoctets par mois, atteignent vite cinq chiffres. Ces tarifs sont parfaitement d\u00e9lib\u00e9r\u00e9s : voil\u00e0 \u00e0 quoi ressemble le vendor lock-in une fois traduit en poste de bilan. Les donn\u00e9es install\u00e9es dans un bucket ressortent ensuite \u00e0 un prix \u00e9lev\u00e9.<\/p>\n La fonction de caching cross-cloud que Google a pr\u00e9sent\u00e9e \u00e0 la Next 2026 agit pr\u00e9cis\u00e9ment \u00e0 ce niveau. Elle conserve localement dans le cache du lakehouse les donn\u00e9es d\u00e9j\u00e0 pass\u00e9es de l’autre c\u00f4t\u00e9 de la fronti\u00e8re du cloud, si bien que les requ\u00eates r\u00e9currentes ne d\u00e9clenchent plus d’egress \u00e0 chaque ex\u00e9cution. Pour un dispositif de reporting qui consomme chaque jour le m\u00eame jeu de donn\u00e9es depuis un bucket S3, cela repr\u00e9sente, dans le meilleur des cas, un ordre de grandeur de trafic sortant en moins. La v\u00e9rit\u00e9 architecturale derri\u00e8re tout cela : le caching est une technique \u00e9prouv\u00e9e, et d\u00e8s qu’un hyperscaler l’offre en service natif par-dessus les fronti\u00e8res d’un cloud tiers, le calcul de ROI du cross-cloud bascule massivement.<\/p>\n Un groupe industriel de taille interm\u00e9diaire qui collecte ses donn\u00e9es machines dans AWS S3 et les analyse via GCP BigQuery g\u00e9n\u00e8re de son propre aveu environ 12 TB d’egress cross-cloud par mois. Aux tarifs AWS actuels, cela repr\u00e9sente pr\u00e8s de 1 080 euros par mois, uniquement pour le d\u00e9placement des donn\u00e9es. Avec un taux de hits du cache de 70 % sur les requ\u00eates analytics r\u00e9currentes, le trafic sortant retombe \u00e0 environ 3,6 TB et la facture \u00e0 environ 330 euros. Sur l’ann\u00e9e, l’\u00e9cart atteint 9 000 euros, pour un seul chemin de donn\u00e9es. Qui exploite plusieurs pipelines de ce type parle vite d’effets \u00e0 six chiffres.<\/p>\n La deuxi\u00e8me bascule vient du lakehouse lui-m\u00eame. Google baptise la nouvelle variante \u00ab borderless \u00bb : la couche lakehouse peut r\u00e9f\u00e9rencer des tables stock\u00e9es physiquement dans S3 ou Azure Data Lake, sans que les donn\u00e9es aient besoin d’\u00eatre r\u00e9pliqu\u00e9es dans BigQuery. Pour les \u00e9quipes d’ing\u00e9nierie, cela signifie moins d’ETL, moins de jobs de synchronisation, moins d’endroits o\u00f9 une d\u00e9rive de sch\u00e9ma vient casser le reporting. Pour les CIO, cela signifie que la question de l’endroit o\u00f9 les donn\u00e9es \u00ab doivent se trouver \u00bb peut recevoir une nouvelle r\u00e9ponse, politique et contractuelle, sans que chaque r\u00e9ponse d\u00e9clenche aussit\u00f4t un projet de migration.<\/p>\n L’envers de la d\u00e9cors : qui contr\u00f4le la couche lakehouse contr\u00f4le la logique de requ\u00eatage. Google se positionne ici en interm\u00e9diaire neutre, un choix strat\u00e9giquement habile : son propre compute devient le moteur de requ\u00eatage standard au-dessus des buckets d’autrui. AWS et Azure m\u00e8nent des initiatives comparables, chacune toutefois plus fortement ancr\u00e9e dans son propre \u00e9cosyst\u00e8me. Le choix de la couche lakehouse qui s’imposera comme standard de facto dans une entreprise du DACH constitue d\u00e8s lors une d\u00e9cision de strat\u00e9gie vendor \u00e0 longue port\u00e9e.<\/p>\n \u00ab Le multi-cloud \u00e9tait jusqu’ici une r\u00e9ponse de conformit\u00e9. Avec les nouvelles couches de lakehouse et de caching, il devient une option architecturale, mais le choix de celui qui pilote la couche de donn\u00e9es demeure une d\u00e9cision de lock-in \u00e0 long terme. \u00bb<\/p>\n<\/blockquote>\n La Gemini Enterprise Agent Platform et l’Agentic Data Cloud constituent l’annonce aux implications les plus strat\u00e9giques. Google regroupe agent registry, skill registry, tool registry et gouvernance dans une couche explicitement con\u00e7ue pour piloter ensemble les workloads AWS, Azure et GCP. Google mise ainsi sur la formule \u00ab nous devenons le control plane au-dessus de vos applications existantes \u00bb ; l’\u00e9poque du discours \u00ab migrez vos applications chez nous \u00bb est r\u00e9volue. Du point de vue d’un CIO, c’est attractif, car le rapport \u00e0 l’investissement s’en trouve chang\u00e9 : le budget finance un abonnement de pilotage abstrait qui remplace le projet classique de migration de workloads.<\/p>\n Le risque est toutefois seulement d\u00e9plac\u00e9 d’une couche vers le haut. Qui constatera dans deux ans que l’agent registry et l’inventaire des tools r\u00e9sident chez Google vivra, avec le r\u00e9flexe \u00ab nous changeons simplement de control plane \u00bb, exactement le m\u00eame effet de lock-in que le multi-cloud \u00e9tait cens\u00e9 \u00e9viter. La seule r\u00e9ponse durable : imposer des standards ouverts pour les d\u00e9finitions d’agents, les sch\u00e9mas de skills et les manifestes de tools, avant que les formats propri\u00e9taires n’aient cr\u00e9\u00e9 de situations de fait.<\/p>\n Ce que le d\u00e9bat architectural oublie souvent : le RGPD, NIS2 et l’EU AI Act laissent toute latitude sur le choix du cloud provider ; ils encadrent en revanche le lieu o\u00f9 les donn\u00e9es sont trait\u00e9es et les personnes autoris\u00e9es \u00e0 y acc\u00e9der. Une couche de caching cross-cloud qui conserve des donn\u00e9es personnelles dans un cache GCP alors que la table ma\u00eetre se trouve dans un centre de donn\u00e9es AWS en Allemagne soul\u00e8ve de vraies questions de droit \u00e0 la protection des donn\u00e9es. La question op\u00e9rationnelle : quelle cat\u00e9gorie de donn\u00e9es a le droit d’\u00eatre mise en cache, et o\u00f9 ? Et comment le cycle de vie du cache est-il document\u00e9 lorsque l’autorit\u00e9 de contr\u00f4le pose des questions ?<\/p>\n La r\u00e9ponse des vendors s’appellera \u00ab policy-driven caching \u00bb, autrement dit des r\u00e8gles qui d\u00e9terminent quelles classes de donn\u00e9es sont autoris\u00e9es \u00e0 franchir quelles fronti\u00e8res de cloud. En pratique, cela signifie : un sch\u00e9ma de classification des donn\u00e9es doit \u00eatre en place avant la construction du premier pipeline cross-cloud en production. Qui repousse cela \u00e0 plus tard se fabrique un g\u00e9n\u00e9rateur de constats d’audit.<\/p>\n 1. O\u00f9 se trouvent les donn\u00e9es ma\u00eetres et o\u00f9 est-il permis d’en stocker des copies ?<\/strong> Le caching a des allures de question de performance, il rel\u00e8ve en r\u00e9alit\u00e9 de la conformit\u00e9. Toute mise en cache cross-cloud exige au pr\u00e9alable une classification des donn\u00e9es.<\/p>\n 2. Quel moteur de requ\u00eatage deviendra le standard ?<\/strong> Les couches lakehouse affichent des demi-vies de cinq \u00e0 dix ans. Le choix du chemin de requ\u00eatage dominant, BigQuery, Athena, Synapse ou Snowflake, rel\u00e8ve d’une d\u00e9cision de strat\u00e9gie vendor avant d’\u00eatre une affaire de tooling.<\/p>\n 3. Qui contr\u00f4le le control plane des agents ?<\/strong> Lorsque l’agent registry et l’inventaire des tools r\u00e9sident chez un hyperscaler, le multi-cloud reste solide au niveau du compute et se recentre \u00e0 nouveau au niveau de l’intelligence. Les discussions sur les standards ouverts doivent \u00eatre engag\u00e9es d\u00e8s aujourd’hui.<\/p>\n Lors de la pr\u00e9sentation, Google n’a communiqu\u00e9 aucun tarif catalogue distinct. La logique \u00e9conomique repose sur la r\u00e9duction des frais d’egress existants ; le cache lui-m\u00eame se facture via des r\u00e9servations de slots BigQuery ou via le on-demand pricing, donc au niveau de la couche compute, sans tarif de caching s\u00e9par\u00e9.<\/p>\n<\/details>\n Pour l’instant, oui : l’impl\u00e9mentation du lakehouse cross-cloud suppose que BigQuery serve de moteur de requ\u00eatage. AWS et Azure proposent des approches comparables (Athena Federated Queries, Synapse Link), chacune centr\u00e9e sur son moteur d’origine. Une v\u00e9ritable neutralit\u00e9 entre fournisseurs passe uniquement par des standards ouverts comme Apache Iceberg, que les trois hyperscalers prennent d\u00e9sormais en charge.<\/p>\n<\/details>\n La question devient concr\u00e8te d\u00e8s qu’une entreprise exploite en parall\u00e8le deux comptes cloud en production ; c’est plus fr\u00e9quent qu’on ne le pense dans le Mittelstand du DACH, souvent \u00e0 la suite d’acquisitions ou via des fournisseurs SaaS aux backends cloud \u00e9troitement li\u00e9s. Qui paie chaque mois plus de 500 euros d’egress gagne \u00e0 calculer le ROI.<\/p>\n<\/details>\n Trois choses : un sch\u00e9ma de classification des donn\u00e9es avec des autorisations de cache claires par cat\u00e9gorie, une d\u00e9cision sur le moteur de requ\u00eatage qui deviendra le langage standard et un chemin d’escalade document\u00e9 pour les constats d’audit relatifs aux contenus du cache. Sans ces trois points, le premier courrier de l’autorit\u00e9 se r\u00e9v\u00e9lera douloureux.<\/p>\n<\/details>\n Un CDN acc\u00e9l\u00e8re, en bordure du r\u00e9seau, la livraison des contenus. Le caching d’egress intervient plus en amont : il conserve les jeux de donn\u00e9es fr\u00e9quemment interrog\u00e9s \u00e0 proximit\u00e9 de la r\u00e9gion de compute, afin que les requ\u00eates cross-cloud r\u00e9p\u00e9t\u00e9es ne d\u00e9clenchent plus \u00e0 chaque appel de co\u00fbteux frais d’egress. Le gain se joue dans la courbe des co\u00fbts.<\/p>\n<\/details>\n Source de l’image : g\u00e9n\u00e9r\u00e9e par IA (juin 2026), certificat C2PA int\u00e9gr\u00e9 dans l’image<\/em><\/p>\nL’essentiel en bref<\/h2>\n
\n
L’egress, une taxe cach\u00e9e sur chaque id\u00e9e multi-cloud<\/h2>\n
Un exemple DACH rend l’ordre de grandeur tangible<\/h3>\n
Du silo de donn\u00e9es au lakehouse borderless<\/h2>\n
\n
Stack d’agents : qui contr\u00f4le les donn\u00e9es contr\u00f4le les skills<\/h2>\n
La conformit\u00e9 atterrit sur la couche cross-cloud<\/h2>\n
Trois questions de contr\u00f4le avant le prochain pas multi-cloud<\/h2>\n
Questions fr\u00e9quentes<\/h2>\n
Combien co\u00fbte concr\u00e8tement le caching cross-cloud ?<\/strong><\/summary>\n
Fonctionne-t-il uniquement avec Google en position centrale ?<\/strong><\/summary>\n
Est-ce pertinent pour le Mittelstand du DACH ou r\u00e9serv\u00e9 aux grands groupes ?<\/strong><\/summary>\n
Que doit-on clarifier avant le premier projet de pipeline cross-cloud ?<\/strong><\/summary>\n
En quoi le caching d’egress se distingue-t-il d’un CDN classique ?<\/strong><\/summary>\n
Plus de contenus du r\u00e9seau MBF Media<\/h3>\n
\n