BigQuery : comment éviter une facture de 30 000 € en limitant vos quotas

L'autre jour, je suis tombé sur ce post LinkedIn de Neal Cole qui parlait des risques de coûts sur BigQuery. En lisant les commentaires et en me rappelant des histoires d'horreur vues sur Reddit (comme celle-ci ou celle-là) où des gens se retrouvent avec des factures à 5 chiffres, je me suis posé une question simple :

Mais c'est si compliqué de mettre des quotas ?

Personne n'explique clairement comment faire. Pour obtenir une réponse simple, on a l'impression qu'il faut toujours télécharger un livre blanc, remplir un formulaire et passer quatre barrières marketing.

Stop. Ça ne devrait pas être si difficile. Voici donc un article direct, sans blabla, qui vous explique en 5 étapes comment mettre en place ce fameux quota et dormir sur vos deux oreilles.

Surtout que le contexte a changé. Auparavant, la limite par défaut pour les requêtes était illimitée. Face aux factures astronomiques, Google a décidé d'appliquer un nouveau quota par défaut de 200 Tio (Tebibytes) par jour à partir de septembre 2025.

À première vue, c'est une protection. Mais faisons le calcul :

200 Tio/jour * 30 jours * ~5€/Tio = 30 000€ par mois.

Ce "garde-fou" peut donc encore vous coûter très cher. Passons à la pratique.

Prérequis

• Un projet Google Cloud avec l'API BigQuery activée.
• Les permissions IAM nécessaires pour modifier les quotas (par exemple, le rôle roles/serviceusage.quotaAdmin).

Pourquoi est-il vital de définir un quota personnalisé ?

Le modèle de tarification "on-demand" de BigQuery est basé sur la quantité de données analysées (bytes scanned) par vos requêtes. C'est puissant, mais c'est aussi un risque. Une seule requête mal écrite, une jointure oubliée ou un script automatisé qui boucle peut scanner des téraoctets de données en quelques minutes.

Les causes les plus fréquentes de dérapage sont :

• Les requêtes SELECT * sur de très grosses tables.
• L'absence de clause WHERE ou de filtres sur les partitions de dates.
• Des outils de BI ou des scripts qui exécutent des requêtes en arrière-plan.

Un quota personnalisé n'est pas une contrainte, c'est votre assurance anti-catastrophe. Il bloque toute consommation au-delà d'un seuil que VOUS avez jugé sûr.

Tutoriel : appliquer un quota de 0.2 Tio/jour sur BigQuery

Nous allons définir une limite qui correspond à environ 30€ de consommation maximale par mois. Suivez le guide !

Étape 1 : Accéder à la section "Quotas"

1. Connectez-vous à votre Google Cloud Console.
2. Dans le menu de navigation ( en haut à gauche), allez dans IAM et administration > Quotas.

Étape 2 : Filtrer pour trouver le bon quota

La page des quotas peut être intimidante. Utilisons les filtres pour aller droit au but.

1. Dans la barre de Filtre, cliquez pour ajouter des filtres.
2. Service : Sélectionnez ou tapez BigQuery API.

1. Métrique : C'est l'étape la plus importante. Cherchez et sélectionnez Query usage per day. Cela correspond à la quantité de données analysées par les requêtes on-demand pour le projet.

Étape 3 : Sélectionner et modifier le quota

Dans la liste des résultats filtrés, vous devriez voir la ligne correspondant à "Query usage per day".

1. Cochez la case à gauche de cette ligne.
2. Un bouton MODIFIER LES QUOTAS apparaît en haut de la page. Cliquez dessus.

Étape 4 : Définir votre nouvelle limite de sécurité

Un panneau s'ouvre sur la droite. C'est ici que la magie opère.

1. Dans le champ Nouvelle limite, entrez la valeur souhaitée. Pour notre exemple, tapez 0.2. L'unité (Tio) est déjà spécifiée par la métrique.
2. Cliquez sur OK.
3. Une dernière fenêtre de confirmation apparaît. Cliquez sur ENVOYER LA DEMANDE.

Note importante : Une limite de 0.2 Tio signifie que votre projet ne pourra pas scanner plus de 200 Gio de données par jour, ce qui équivaut à un coût maximal d'environ 1€. C'est une limite de sécurité très raisonnable pour la plupart des projets de taille petite à moyenne.

Étape 5 : Vérification

La mise à jour du quota peut prendre quelques minutes. Une fois appliquée, vous verrez la nouvelle limite dans la colonne "Limite" de l'interface des quotas. La limite par défaut de 200 Tio sera remplacée par votre nouvelle valeur de 0.2.

Quelle limite choisir pour votre projet ?

La valeur de 0.2 Tio est un excellent point de départ, mais le "bon" quota dépend de votre usage. Pour l'affiner :

• Analysez votre consommation passée : Dans BigQuery, utilisez les vues INFORMATION_SCHEMA.JOBS pour voir combien de données vos requêtes analysent en moyenne chaque jour.
• Définissez une marge de sécurité : Prenez votre consommation journalière moyenne et ajoutez une marge confortable (ex: 50% ou 100%) pour gérer les pics d'activité sans bloquer les opérations légitimes.

Limitations et points d'attention avancés

Mettre en place ce quota est une excellente pratique, mais il est crucial de comprendre ses implications pour éviter les mauvaises surprises.

• Que se passe-t-il quand le quota est atteint ? Toute nouvelle requête "on-demand" échouera immédiatement avec une erreur quotaExceeded. Cela bloquera non seulement les utilisateurs dans la console, mais aussi tous les services et scripts automatisés qui dépendent de ces requêtes.
• Impact sur les services connectés :
  • Looker Studio (et autres outils de BI) : Les tableaux de bord connectés à BigQuery ne se rafraîchiront plus et afficheront des erreurs.
  • Requêtes planifiées (Scheduled Queries) : Elles échoueront.
  • Workflows (Dataform, Cloud Composer) : Les tâches qui exécutent des requêtes BigQuery seront en erreur, ce qui peut bloquer toute une chaîne de traitement de données.
• Qu'est-ce qui ne compte PAS dans ce quota ? Heureusement, certaines opérations ne sont pas comptabilisées et continueront de fonctionner :
  • Les requêtes qui bénéficient du cache de BigQuery. Si le résultat a déjà été calculé récemment, BQ le renvoie sans scanner de données et donc sans impacter le quota.
  • Les requêtes sur les méta-données (vues INFORMATION_SCHEMA).
  • Les opérations de chargement (load), d'export ou de copie de données.
• Le risque du "voisin bruyant" (Noisy Neighbor) : Le quota Query usage per day s'applique au niveau du projet. Dans un projet partagé par plusieurs utilisateurs ou équipes, une seule personne ou un seul script défaillant peut consommer l'intégralité du quota journalier, bloquant ainsi le travail de tout le monde. La communication et la gouvernance sont donc essentielles.

Exceptions et autres sources de coûts

Attention, ce quota sur l'usage des requêtes n'est pas un bouclier anti-facture absolu. Il ne couvre pas tout. Voici des cas où des coûts supplémentaires peuvent survenir :

• Le stockage de données : Le coût le plus évident après les requêtes. Le stockage actif et le stockage à long terme sont facturés séparément et ne sont pas affectés par ce quota.
• Les insertions en streaming (Streaming Inserts) : Si vous insérez des données en temps réel dans BigQuery, cette opération a sa propre tarification et ses propres quotas.
• BigQuery Omni, transferts et requêtes fédérées : L'utilisation de BigQuery pour requêter des données sur d'autres clouds (AWS S3, Azure) ou l'utilisation de requêtes fédérées (ex: vers Cloud SQL) ont leurs propres quotas et coûts, indépendants de celui que nous avons défini.
• Autres opérations facturables : Des services comme les exports de données ou l'utilisation de l'API BigQuery Storage Read ont également une facturation qui leur est propre.

Conclusion : prenez le contrôle

La puissance du cloud s'accompagne de la responsabilité de gérer ses coûts. Laisser les quotas par défaut, surtout ceux aussi élevés que la future limite de Google, c'est prendre un risque financier inutile.

En quelques clics, vous venez de mettre en place un filet de sécurité robuste qui pourrait vous épargner des milliers d'euros et beaucoup de stress.

N'attendez pas la mauvaise surprise. Prenez 5 minutes aujourd'hui pour vérifier et ajuster vos quotas BigQuery.