Architectes DACH au cœur du coup de cache de Google

Le 24 avril, Google Cloud a annoncé lors du Wrap-Up de Cloud Next 2026 le Cross-Cloud Caching en tant que nouvelle fonctionnalité. L’idée : les données AWS et Azure sont mises en miroir dans le stockage Google Cloud lors de la première lecture et sont ensuite disponibles localement pour les requêtes répétées. Les frais de sortie pour la deuxième, troisième et millième requête sont supprimés. Pour les architectes de multi-nuages DACH, c’est un argument de coût solide sur le papier. Mais cela pose une question qui n’a jamais été aussi directement posée : combien de souveraineté des données vaut une facture de sortie ?

Les points clés en bref

L’annonce a été faite lors du Cloud Next 2026 Wrap-Up du 24 avril (cloud.google.com). Le Cross-Cloud Caching s’inscrit dans la stratégie visant à répondre à la réalité des multi-nuages, que de nombreuses entreprises DACH vivent depuis des années, mais gèrent rarement de manière élégante. Nous avions déjà intégré le plus grand bloc de la feuille de route : Ce que les architectes DACH doivent apporter de la feuille de route Cloud Next 2026. Le Cross-Cloud Caching est le levier pratique qui en découle.

Fonctionnement de la fonctionnalité

Le principe est le même que le caching, tel que les développeurs frontend le connaissent dans le contexte des CDN, mais à un niveau plus bas et au-delà des frontières des nuages. Un travail dans BigQuery ou Vertex AI lit un jeu de données à partir d’AWS S3. Lors de la première lecture, le trafic passe par le tuyau habituel et coûte des frais de sortie. Le Cross-Cloud Caching copie l’objet en parallèle dans le stockage Google Cloud. Les requêtes suivantes contre le même jeu de données lisent à partir du cache local. Du point de vue d’AWS, il n’y a plus de trafic après la première lecture.

Techniquement, il s’agit d’une combinaison de miroir de stockage et de routage intelligent : recherche de cache avant la lecture cross-cloud, invalidation basée sur TTL et un niveau de contrôle qui décide de ce qui vaut la peine d’être mis en cache. Ceux qui ont déjà travaillé avec des caches de bordure et Stale-While-Revalidate connaissent les modèles. Ce qui est nouveau, c’est que Google propose cela au niveau du stockage et l’intègre avec ses propres services d’analyse.

Pourquoi les équipes DACH doivent regarder de plus près

Les frais de sortie (Egress) sont depuis des années le poste le plus désagréable de la facture cloud. AWS et Azure facturent environ 8 à 9 centimes par gigaoctet (GB) qui franchit la limite du fournisseur, dans les premiers niveaux (Source : Tarification des transferts de données AWS, Tarification de la bande passante Azure, état d’avril 2026). Pour les charges de travail qui extraient régulièrement plusieurs téraoctets (TB) de clouds tiers, cela s’additionne rapidement pour atteindre des montants qui justifient une refonte de l’architecture. Le cache cross-cloud intervient exactement à ce niveau.

C’est intéressant pour les architectes DACH, car de nombreux déploiements productifs présentent exactement ce modèle de lecture : les données sont historiquement stockées dans AWS ou Azure, mais l’équipe d’analyse travaille sur BigQuery. Sans cache, le même jeu de données est extrait d’AWS mois après mois. Avec le cache, le trafic se produit une seule fois, puis plus jamais. Si le poste de dépense est raisonnablement stable, la facture est rapidement établie. Une logique similaire a été discutée la semaine dernière dans notre vérification pratique sur CloudFormation vs Terraform pour le multi-cloud : les décisions d’outillage tournent souvent autour de ces coûts d’exploitation récurrents.

Ce qui casse, ce qui porte

La discussion honnête n’est pas « fonctionnalité oui ou non », mais « pour quels données et sous quelles conditions ». Les données personnelles sous les directives DSGVO, les classes de données réglementées du domaine KRITIS ou les stocks avec des restrictions géographiques explicites ne sont pas des candidats au cache. Les ensembles de données de télémétrie, de flux de clics ou de formation sans lien avec les personnes le sont davantage. La ligne de séparation appartient à la décision d’architecture documentée, et non à la revue FinOps annuelle.

Ce que les architectes DACH devraient faire dans les 90 prochains jours

Tout d’abord : un rapport d’égas propre à partir d’AWS et Azure, classé par ensemble de données et cloud cible. Celui qui ne l’a pas ne peut pas quantifier le levier. Deuxièmement : une classification des stocks de données en fonction de leur aptitude au cache, avec validation de conformité. Troisièmement : un pilote pour un seul ensemble de données lourd en lecture, idéalement des données de télémétrie ou de formation. Cela donne lieu à un chiffre réel au lieu d’une estimation sur les diapositives du fournisseur.

Stratégiquement, la question du compromis entre dépendance et flexibilité mérite un atelier honnête : le cache cross-cloud réduit la douleur d’égas, mais crée une nouvelle dépendance à l’égard de la couche de stockage de Google. Celui qui a déjà un plan de sortie multi-cloud dans son tiroir devrait intégrer la fonctionnalité dans ce plan avant qu’il ne devienne silencieusement opérationnel.

Foire aux questions

Photo : Lovelano / Wikimedia Commons (CC BY 4.0)