Ressources · GCP FinOps · 2025-09-01 · 7 min de lecture

Optimisation BigQuery : pourquoi la réservation de slots est le levier n°1 sous-exploité

Comment réduire vos coûts d'analyse de données en passant du mode on-demand aux éditions BigQuery, et quand s'engager sur 1 ou 3 ans.

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. Souvent l'un des premiers postes de la facture Google Cloud, 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, beaucoup de ces organisations restent en mode on-demand et n'utilisent pas les réservations de slots ni les engagements de capacité.

La réservation de slots est pourtant l'un des rares leviers BigQuery qui change le modèle de prix lui-même plutôt que les requêtes : elle mérite un calcul sur vos propres données avant tout autre réglage.

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.

Le requêtage, premier poste à vérifier

La facture BigQuery se partage entre l'analyse (SKU de type « Analysis »), directement liée au requêtage, et le stockage. Dans les organisations à usage intensif, l'analyse en représente souvent la plus grande part : vérifiez-le SKU par SKU sur votre export de facturation. Ce sont précisément ces coûts d'analyse 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 :

Sources : grille de prix BigQuery de Google Cloud (prix publics en dollars) ; documentation des éditions BigQuery, consultée le 22 octobre 2026, pour le plafond de 1 600 slots de l'édition Standard et les remises d'engagement de 20 % sur un an et de 40 % sur trois ans.

Combien peut-on économiser avec la réservation de slots ?

Le gain se calcule sur vos propres requêtes

Le gain dépend entièrement de votre charge : aucun pourcentage générique ne le remplace. Le calcul se fait sur vos données. INFORMATION_SCHEMA donne, requête par requête, les octets facturés et les slot-millisecondes consommées. Les octets facturés, multipliés par le prix on-demand, donnent le coût actuel ; les slot-heures, multipliées par le prix d'une édition, donnent le coût en capacité. L'écart entre les deux, sur 30 jours, est le gain à attendre, avant les effets de l'autoscaling.

L'engagement sur 1 ou 3 ans pour aller plus loin

Sur l'édition Enterprise, l'engagement réduit le prix de la slot-heure de 20 % sur un an et de 40 % sur trois ans. Mais un slot engagé est facturé en permanence, qu'il serve ou non. D'où deux seuils, qui se déduisent directement de ces remises :

• Slots engagés utilisés plus de 80 % du temps → l'engagement d'un an coûte moins cher que l'autoscaling
• Slots engagés utilisés plus de 60 % du temps → l'engagement de trois ans coûte moins cher
• En dessous de 60 % → autoscaling sans engagement

Ces seuils comparent le prix engagé au prix à l'usage de la même édition ; la série horaire de consommation de slots dit de quel côté se trouve chaque charge.

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.

• Créer un ou plusieurs Admin Projects en parallèle d'un département consommateur de BigQuery
• Configurer 1 à 5 réservations en édition Standard (1 600 slots max), sans engagement, baseline fixée à 0, risque nul
• Assigner chaque réservation à un projet spécifique pour garantir des performances proches du on-demand
• Configurer les permissions et activer le monitoring de consommation (INFORMATION_SCHEMA, Admin Resource Charts)

Phase Walk : Passage à l'échelle

• Un Admin Project couvre l'ensemble des entités ou BUs concernées
• Déploiement en édition Enterprise avec des réservations dimensionnées sur la consommation observée en phase Crawl, baseline à 0, sans engagement
• Le reporting horaire de l'utilisation de slots devient représentatif, c'est le prérequis de la phase Run

Phase Run : Optimisation par l'analyse de consommation

• Analyser la timeseries de consommation de slots pour identifier les charges de travail durables et prévisibles
• Acheter des engagements (Commitments) sur 1 ou 3 ans en fonction du profil d'usage réel
• Modifier les réservations en place, ajouter des baselines sur les slots engagés

À partir de quel volume agir ?

La réservation de slots devient économiquement pertinente quand le coût simulé en slot-heures, sur 30 jours de vos requêtes, passe nettement sous le coût on-demand constaté, en tenant compte du temps de mise en place et de suivi. Les charges légères ou très irrégulières restent souvent mieux servies par le on-demand, avec une limitation de consommation par les quotas de l'API BigQuery.

Le modèle de gouvernance des accès

La structure de gouvernance repose sur trois niveaux de permissions :

• Administrateurs : gèrent les engagements (Commitments) et les réservations au niveau Admin Project
• Managers d'équipe : créent et assignent les réservations à leurs projets (Reservations + Assignments)
• Utilisateurs : exécutent des requêtes sur des projets assignés à leur réservation d'équipe

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 :

• JOBS_BY_USER / JOBS_BY_PROJECT / JOBS_BY_ORGANIZATION : coût et temps par requête
• RESERVATION_CHANGES_BY_PROJECT : historique des modifications de réservations
• CAPACITY_COMMITMENT_CHANGES_BY_PROJECT : suivi des engagements achetés

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.

FAQ

La réservation de slots dégrade-t-elle les performances ?

Pas nécessairement. En mode autoscaling (baseline à 0), BigQuery ajoute des slots à la demande ; le seul impact est un court temps de montée en charge. Avec une baseline fixée (slots permanents), ce temps disparaît. Des performances équivalentes au on-demand sont obtenues dès lors que la réservation dispose d'un nombre de slots suffisant.

Quel est le seuil de coût à partir duquel l'optimisation est rentable ?

Il n'y a pas de seuil universel : il se calcule sur vos 30 derniers jours de requêtes, en comparant le coût on-demand constaté au coût simulé en slot-heures. Si l'écart ne couvre pas l'effort de mise en place et de suivi, restez en on-demand.

Quelle différence entre les Éditions BigQuery et les anciens Flat Rate ?

Les anciens modèles Flex Slots et Flat Rate ont été remplacés par les Éditions depuis juillet 2023. Le nouveau système découple la durée d'engagement du choix d'édition : toutes les Éditions fonctionnent en autoscaling par défaut. L'édition Standard remplace globalement le Flex, tandis qu'Enterprise et Enterprise Plus correspondent aux anciens flat rate avec des fonctionnalités supplémentaires.