ServicesÀ proposNotesContact Me contacter →
EN FR
Note

Contrôle des Coûts de Requêtes IA pour BigQuery MCP

Gérer les risques de coût et de sécurité liés aux assistants IA qui exécutent des requêtes BigQuery via MCP — atténuation des coûts, protection en écriture et garde-fous pratiques.

Planté
mcpbigquerygcpaicost optimization

L’accès d’un assistant IA à BigQuery via MCP introduit des risques de coût et de sécurité qui n’existent pas avec un accès uniquement humain. Un assistant IA optimise pour répondre aux questions, pas pour limiter les coûts — si répondre à une question nécessite de scanner une table de 10 To, il le fera. Les deux options MCP (le serveur distant et le Toolbox) sont en prévisualisation/bêta au début de 2026, ajoutant une couche d’imprévisibilité. Chaque appel à execute_sql exécute une vraie requête BigQuery à un vrai coût (6,25 $ par TiB scanné avec la tarification à la demande selon le modèle de coût BigQuery).

Le Risque de Coût

Un assistant IA curieux posant de larges questions sur des tables volumineuses peut accumuler des frais rapidement. Considérez ce schéma d’interaction :

  1. L’utilisateur demande : « Quelles sont les tendances dans nos données de commandes ? »
  2. L’IA appelle list_table_ids pour trouver les tables pertinentes
  3. L’IA appelle get_table_info sur plusieurs tables pour comprendre les schémas
  4. L’IA écrit et exécute une requête large — potentiellement SELECT * sur une grande table de faits — pour explorer les données
  5. L’IA écrit des requêtes de suivi pour affiner l’analyse

Les étapes 3 et 4 sont là où les coûts s’accumulent. L’inspection des schémas est peu coûteuse, mais les requêtes exploratoires peuvent être onéreuses. Une IA ne sait pas (et ne se préoccupe pas) que orders est une table de 5 To. Elle écrit la requête qu’elle pense être la plus appropriée pour répondre à votre question.

Le modèle de tarification de BigQuery rend cela particulièrement sensible : vous payez pour les octets scannés, pas pour les octets retournés. Une requête qui scanne 5 To et retourne 10 lignes coûte autant qu’une qui en retourne 10 millions. Les clauses LIMIT ne réduisent pas la facture — BigQuery scanne d’abord, limite ensuite.

Stratégies d’Atténuation des Coûts

Utilisez des requêtes paramétrées personnalisées. C’est le contrôle le plus efficace. Le fichier tools.yaml du Toolbox vous permet de définir des requêtes avec des clauses LIMIT intégrées, des sélections de colonnes spécifiques et des filtres de partition. L’IA renseigne les paramètres mais ne peut pas modifier la forme de la requête. Une requête définie avec SELECT order_id, amount FROM orders WHERE date BETWEEN @start AND @end LIMIT 100 ne deviendra jamais un scan complet de table.

Restreignez l’accès à des datasets spécifiques. Accordez bigquery.dataViewer uniquement sur les datasets auxquels l’IA doit accéder, pas au niveau du projet. Si l’IA ne peut voir que vos datasets de couche mart (qui sont plus petits et pré-agrégés), le coût maximum par requête est borné par la taille de ces tables. Les tables brutes/staging, qui tendent à être beaucoup plus grandes, restent inaccessibles.

Définissez des contrôles de coût BigQuery. Utilisez des quotas au niveau du projet et de l’utilisateur pour plafonner les coûts quotidiens de requêtes :

  • Les quotas personnalisés par projet limitent le total quotidien des octets scannés
  • Les quotas par utilisateur limitent ce qu’un seul compte de service peut scanner

Ce sont des filets de sécurité, pas des stratégies d’optimisation. Ils évitent les dérapages de coût mais ne rendent pas les requêtes moins chères.

Surveillez les patterns de requêtes. Interrogez INFORMATION_SCHEMA.JOBS_BY_PROJECT filtré par le compte de service MCP pour voir ce que l’IA exécute réellement. Recherchez :

  • Les requêtes sans filtres de partition sur des tables partitionnées
  • Les patterns SELECT * sur des tables larges
  • Les requêtes répétées scannant les mêmes grandes tables

Ce monitoring vous indique quand ajouter des outils personnalisés ou restreindre l’accès aux datasets.

Le Problème de la Protection en Écriture

Voici quelque chose qui surprend souvent : execute_sql peut exécuter des instructions INSERT, UPDATE, DELETE et DDL. Si l’IA dispose des permissions bigquery.dataEditor (qui autorisent les modifications de tables), une requête comme DROP TABLE ou DELETE FROM est techniquement possible.

Pour un accès MCP en lecture seule, la stratégie IAM est claire :

  • N’accordez que roles/bigquery.user (pour exécuter des requêtes et lister les datasets)
  • N’accordez que roles/bigquery.dataViewer (pour lire les données des tables)
  • N’accordez jamais roles/bigquery.dataEditor

La note Patterns IAM BigQuery couvre cela en détail, mais le point essentiel pour MCP : le compte de service de l’IA doit disposer des permissions minimales nécessaires pour les opérations en lecture. Si vous avez besoin que l’IA écrive des données (rare), créez un compte de service distinct avec un accès en écriture à des datasets spécifiques uniquement.

Alternativement, utilisez des requêtes paramétrées personnalisées avec des instructions SQL exclusivement en lecture seule. Même si le compte de service dispose de permissions plus larges, l’IA ne peut exécuter que les requêtes que vous avez définies.

Autres Points d’Attention

Les requêtes longues peuvent expirer. MCP a son propre timeout indépendant de celui de BigQuery. Une requête complexe que BigQuery finirait éventuellement peut expirer au niveau du protocole MCP, vous laissant avec une requête échouée et un job BigQuery toujours en cours d’exécution (et facturé).

Les grands ensembles de résultats sont tronqués. Les réponses MCP ont des limites de taille. Si une requête retourne des millions de lignes, la réponse sera tronquée. L’IA pourrait ne pas réaliser que les résultats sont incomplets et tirer des conclusions à partir de données partielles.

Limites de requêtes simultanées. BigQuery a des limites de requêtes simultanées par projet. Si l’IA exécute plusieurs requêtes en succession rapide (ce qu’elle fait parfois lors de l’exploration de données), elle peut atteindre ces limites et recevoir des erreurs.

Instabilité en bêta. Les deux options MCP sont en prévisualisation/bêta au début de 2026. Fixez une version spécifique du Toolbox en production. Attendez-vous à des changements incompatibles entre les versions.

L’Approche Pratique

Commencez de manière conservatrice et assouplissez selon les besoins :

  1. Utilisez le Toolbox avec des requêtes paramétrées personnalisées uniquement — pas d’execute_sql
  2. Pointez les outils vers les tables de la couche mart, pas vers les données brutes
  3. Incluez des clauses LIMIT dans chaque définition de requête
  4. Surveillez l’activité de requêtes du compte de service pendant quelques semaines
  5. Ajoutez execute_sql comme outil uniquement si les requêtes paramétrées s’avèrent insuffisantes

Cela inverse l’approche habituelle (tout accorder, restreindre ensuite) vers le pattern plus sûr consistant à ne rien accorder et à ajouter des accès là où un besoin démontré existe. La note Posture de sécurité pour les agents IA couvre la philosophie plus large derrière cette approche du moindre privilège pour les outils IA.