Maîtriser sa facture cloud est devenu l'un des enjeux stratégiques les plus complexes pour les directions IT et financières. Les budgets progressent, les périmètres s'élargissent, et la visibilité sur les dépenses reste fragmentée entre des dizaines de services, de projets et d'équipes. Dans ce contexte, identifier les leviers d'optimisation réellement impactants — ceux qui génèrent des économies substantielles sans ralentir les métiers — est devenu un exercice d'arbitrage permanent.
Sur Google Cloud Platform, un service concentre une part disproportionnée de cette problématique dans les organisations data-driven : BigQuery. Représentant souvent plus de 20% de la facture GCP totale, sa courbe de coût est structurellement haussière — portée par la multiplication des usages data, BI et IA. Et malgré l'ampleur du poste, la quasi-totalité de ces organisations ne franchit jamais le pas vers le seul levier que Google lui-même classe parmi les plus rentables de son catalogue.
Ce levier, c'est la réservation de slots BigQuery — et son potentiel d'économies, jusqu'à 74% sur les coûts de requêtage, reste massivement sous-exploité.
BigQuery : quand la facture d'analyse de données dérape
Le pricing on-demand, piège par défaut
Par défaut, BigQuery fonctionne en mode on-demand : chaque requête est facturée en fonction du volume de données scanné, à 6,25$ par TiB. Ce modèle est séduisant au démarrage — pas de commitment, pas de configuration, pas de risque apparent. Mais à mesure que les usages se multiplient (data science, BI, ETL, reporting automatisé), la facture agrégée peut rapidement atteindre plusieurs dizaines ou centaines de milliers d'euros par mois.
Ce qui aggrave la situation, c'est que la répartition des coûts BigQuery est souvent opaque : les requêtes sont lancées depuis de multiples projets, par des équipes différentes, sans visibilité consolidée sur les volumes requêtés ni sur les requêtes les plus consommatrices.
Jusqu'à 81% des coûts BigQuery concentrés sur le requêtage
Dans les organisations à usage intensif de BigQuery, les coûts d'analyse (SKU de type « Analysis ») représentent en général entre 75 et 85% de la facture BigQuery totale — le reste correspondant au stockage et à l'archivage. Ce sont précisément ces coûts d'analyse, directement liés au requêtage, qui sont adressables par la réservation de slots.
Ce que sont réellement les slots BigQuery
Slot = unité de capacité de calcul
Un slot BigQuery est une unité de capacité de calcul : concrètement, une combinaison de CPU, RAM et réseau allouée pour exécuter des requêtes. Acheter des slots, c'est acheter de la puissance de traitement plutôt que payer au volume de données scanné.
Fair scheduler et concurrence des charges de travail
BigQuery intègre un fair scheduler : si plusieurs requêtes s'exécutent simultanément, les slots disponibles sont répartis équitablement entre elles. Ce mécanisme rend la gestion par réservations particulièrement pertinente à l'échelle d'une organisation multi-équipes.
Le système d'Éditions BigQuery
Standard, Enterprise, Enterprise Plus : les différences clés
Depuis juillet 2023, Google a restructuré son offre de réservation de slots avec un système d'Éditions. Voici les caractéristiques essentielles :
| Critère | Standard | Enterprise | On-demand |
|---|---|---|---|
| Prix région US | 0,04$/slot-heure | 0,06$/slot-heure | 6,25$/TiB scanné |
| Prix région EU | +10% (≈ 0,044$) | +10% (≈ 0,066$) | 6,25$/TiB |
| Modèle compute | Autoscaling | Autoscaling + Baseline | On-demand |
| Slots max | 1 600 slots | Quota à définir | Quota à définir |
| Baseline | Non disponible | Optionnelle | N/A |
| Engagement | Non disponible | 1 an (–20%) / 3 ans (–40%) | Aucun |
Combien peut-on économiser avec la réservation de slots ?
Jusqu'à 73% d'économies avec l'édition Standard
Sur des workloads réels, l'édition Standard en mode autoscaling génère une réduction de 73% des coûts de requêtage par rapport au on-demand.
Le coût réel moyen d'une requête type chute ainsi d'environ 8,78€ en on-demand à 2,36€ en édition Standard.
L'engagement sur 1 ou 3 ans pour aller plus loin
L'édition Enterprise sans engagement génère une réduction de 56% par rapport au on-demand. Avec un engagement de 1 an, on monte à 65%. Avec un engagement de 3 ans, à 74%.
La décision d'engagement doit être basée sur une analyse rigoureuse :
Matrice de décision Flex / Mensuel / Annuel
Stratégie d'implémentation : Crawl / Walk / Run
Phase Crawl — Expérimenter sans risque
Objectif : valider le modèle économique sur un périmètre limité avant tout engagement.
Phase Walk — Passage à l'échelle
Phase Run — Optimisation par l'analyse de consommation
À partir de quel volume agir ?
La réservation de slots devient économiquement pertinente dès que l'un de ces critères est rempli :
En dessous de ces seuils, les charges de travail légères sont mieux servies par le on-demand, avec une limitation de consommation via les quotas BigQuery API.
Le modèle de gouvernance des accès
La structure de gouvernance repose sur trois niveaux de permissions :
Point important : le coût d'une requête BigQuery est imputé sur le projet qui exécute la requête, et non sur le projet depuis lequel les données sont récupérées. Distinction critique pour le chargeback.
Monitoring et pilotage : les outils natifs
INFORMATION_SCHEMA : la source de vérité FinOps BigQuery
BigQuery expose via INFORMATION_SCHEMA des vues système permettant d'analyser la consommation en slot-heures par utilisateur, par projet, par type de job et par réservation. Les vues essentielles :
Admin Resource Charts et Alerting Policies
Les Admin Resource Charts permettent de visualiser en temps réel l'utilisation des slots, la concurrence des requêtes, et les jobs en échec. Couplés à des alerting policies sur les métriques query_time, scanned_bytes et slots_allocated, ils constituent le dispositif de monitoring minimal.
Ce que cette démarche révèle sur la maturité FinOps GCP
La réservation de slots BigQuery est emblématique d'une problématique plus large : les organisations qui ont industrialisé leur usage de GCP ont souvent optimisé le Compute Engine (rightsizing, CUDs, Spot Instances), mais laissé les services gérés comme BigQuery fonctionner en mode on-demand par défaut.
L'enjeu n'est pas seulement technique : c'est un enjeu de gouvernance et d'accountability. Sans visibilité sur la consommation de slots par équipe et par projet, il est impossible de responsabiliser les équipes data sur leurs dépenses BigQuery.