Il s’avère que nous utilisions tous MCP de la mauvaise façon.

Ce n’est pas moi qui le dis. C’est Cloudflare, issu de leur recherche de septembre 2025 sur l’efficacité des agents IA. Leur découverte : lorsqu’ils ont demandé aux LLMs d’écrire du code qui appelle des APIs au lieu de générer directement des appels d’outils MCP, la consommation de tokens a chuté de 81 %. Anthropic a validé indépendamment cette conclusion quelques semaines plus tard, rapportant une réduction de 98,7 % dans un workflow Google Drive vers Salesforce.

Pour ceux d’entre nous qui travaillent avec BigQuery et GCP au quotidien, cette recherche a des implications importantes. MCP (Model Context Protocol) est devenu le nouveau standard en vogue pour connecter les agents IA aux outils externes. Google a lancé des serveurs MCP managés pour BigQuery en décembre 2025. L’écosystème s’étend rapidement. Alors pourquoi deux acteurs majeurs suggèrent-ils que nous ferions peut-être mieux d’écrire des commandes shell ?

La réponse réside dans les données d’entraînement, et elle suggère que les commandes bq et gcloud que vous utilisez depuis des années ne sont pas des outils legacy à abstraire. Elles pourraient être l’interface la plus efficace de Claude Code vers votre data warehouse.

Pourquoi les LLMs parlent mieux Bash que les schémas d’outils JSON

L’asymétrie des données d’entraînement

Les LLMs apprennent de ce qu’ils ont vu. Claude, ChatGPT et leurs pairs ont ingéré des millions de dépôts GitHub, de réponses Stack Overflow, d’articles de blog et de documentation. L’outil en ligne de commande bq existe depuis 2011. gcloud a été lancé en 2013. Cela représente plus d’une décennie d’exemples d’utilisation réels : forums de discussion, code de tutoriels, scripts de production, configurations CI/CD.

L’appel d’outils MCP, en revanche, nécessite que les modèles génèrent du JSON structuré correspondant à des schémas spécifiques (des formats qu’ils n’ont rencontrés principalement que dans des données d’entraînement synthétiques créées spécifiquement pour enseigner l’utilisation d’outils). L’équipe d’ingénieurs de Cloudflare l’a formulé sans détour :

Faire effectuer des tâches à un LLM avec l’appel d’outils, c’est comme faire suivre à Shakespeare un cours intensif d’un mois en mandarin puis lui demander d’écrire une pièce dans cette langue. Ce ne sera tout simplement pas son meilleur travail.

L’asymétrie est frappante. Quand Claude génère une commande bq query, il puise dans des patterns qu’il a vus des milliers de fois. Quand il génère un appel d’outil MCP, il travaille à partir d’un corpus bien plus petit et plus artificiel.

Les preuves des benchmarks

L’expérience « Code Mode » de Cloudflare a testé cette hypothèse directement. Ils ont demandé à des agents de créer 31 événements de calendrier : une fois en utilisant l’appel d’outils MCP traditionnel, une fois en écrivant du code TypeScript contre les mêmes APIs.

L’approche Code Mode a utilisé 81 % moins de tokens. Mais le résultat le plus révélateur était qualitatif : l’agent écrivant du code a correctement appelé new Date() pour déterminer la date actuelle avant de créer les événements. L’agent utilisant l’appel d’outils, n’ayant pas cette capacité, a créé les 31 événements un an dans le passé.

La recherche d’Anthropic est allée plus loin. Leur cas de test (télécharger un document depuis Google Drive et l’attacher à un enregistrement Salesforce) nécessitait 150 000 tokens avec MCP traditionnel. Avec l’exécution de code, c’est tombé à 2 000 tokens. Une réduction de 98,7 %.

L’insight clé explique pourquoi : avec MCP traditionnel, chaque résultat intermédiaire passe par la fenêtre de contexte du modèle. Télécharger un fichier ? Le modèle voit la réponse complète. Parser des métadonnées ? Retour dans le contexte. Attacher à Salesforce ? Un autre aller-retour. Avec l’exécution de code, les données restent dans un sandbox. Le modèle ne reçoit que le résultat final dont il a réellement besoin.

Pour les workflows BigQuery, ce principe s’étend naturellement aux commandes CLI. Claude n’a pas besoin de parser des schémas d’outils JSON pour comprendre bq query --nouse_legacy_sql 'SELECT * FROM dataset.table LIMIT 10'. Il a vu ce pattern d’innombrables fois.

La taxe en tokens de MCP

Avant de plonger dans les spécificités BigQuery, quantifions ce que MCP coûte réellement en espace de fenêtre de contexte.

Le fardeau initial

Chaque serveur MCP que vous connectez charge ses définitions d’outils dans le contexte de Claude avant le début de votre conversation. Les tests internes d’Anthropic ont révélé que 58 outils répartis sur 5 serveurs MCP consommaient environ 55 000 tokens, avant un seul message utilisateur.

Dans des configurations extrêmes, les définitions d’outils seules ont englouti 134 000 tokens. C’est 67 % de la fenêtre de contexte de 200K de Claude disparue avant que vous posiez votre première question.

Les mesures réelles de Claude Code racontent une histoire similaire. Un utilisateur a documenté sa configuration avec 7 serveurs MCP :

Même après une optimisation agressive (réduction à 3 serveurs essentiels), ils consommaient encore 42 600 tokens (21,3 % du contexte). Pour les workflows de data engineering nécessitant des requêtes BigQuery, des opérations GCS, des commandes dbt et la gestion de pipelines, l’overhead s’accumule rapidement.

L’efficacité du CLI en comparaison

Une commande bq query modérément complexe consomme 15-30 tokens. La définition de schéma JSON pour un seul paramètre d’outil MCP dépasse souvent cela. Quand vous exécutez des dizaines d’opérations dans une session (exploration de schémas, profilage de données, itérations sur des transformations), la différence est de l’ordre de grandeur, pas de pourcentages.

Ce n’est pas un argument contre l’existence de MCP. C’est un argument pour comprendre ses coûts et choisir le bon outil pour chaque tâche.

Le paysage MCP pour BigQuery

Pour prendre une décision éclairée, vous devez savoir ce qui est réellement disponible. Google a investi significativement dans l’infrastructure MCP pour BigQuery, et l’écosystème a mûri rapidement.

Options officielles Google

Serveur MCP distant BigQuery (Managé, Preview en janvier 2026)

L’option entièrement hébergée de Google ne nécessite aucune installation locale. L’authentification utilise OAuth 2.0 combiné aux permissions IAM, et le serveur fonctionne entièrement sur l’infrastructure de Google. La configuration est minimale :

gcloud beta services mcp enable bigquery.googleapis.com

Le serveur managé expose des outils pour les requêtes, l’exploration de schémas, et une capacité ask_data_insights pour l’analytique conversationnelle.

MCP Toolbox for Databases (Local, Open Source)

Pour les équipes préférant le contrôle local, la toolbox de Google fournit un seul binaire Go supportant BigQuery aux côtés de 30+ autres bases de données (AlloyDB, Cloud SQL, Spanner, PostgreSQL, MySQL). La version 0.24.0 inclut 10 outils BigQuery pré-construits :

• execute_sql : Exécuter des requêtes avec des entrées paramétrées
• list_dataset_ids : Énumérer les datasets d’un projet
• list_table_ids : Lister les tables d’un dataset
• get_table_info : Récupérer le schéma et les métadonnées
• ask_data_insights : Exploration de données en langage naturel

La configuration se trouve dans un fichier tools.yaml :

sources:
  my-bigquery-source:
    kind: bigquery
    project: your-project-id
    location: EU

La consommation de tokens pour l’ensemble complet d’outils BigQuery se situe autour de 2 000-5 000 tokens (substantiel mais gérable).

Alternatives communautaires

Plusieurs serveurs communautaires optimisent pour des cas d’usage spécifiques :

ergut/mcp-bigquery-server fournit un accès en lecture seule avec une limite de requête configurable (1 Go par défaut), des garde-fous utiles pour le contrôle des coûts dans les workflows exploratoires.

bigquery-mcp de pvoo revendique 70 % moins de tokens en « mode basique » en ne retournant que les noms plutôt que les métadonnées complètes lors de l’exploration de schémas.

Le serveur de caron14 inclut uniquement le support --dry_run pour l’estimation des coûts avant l’exécution des requêtes.

Toutes les options utilisent les Application Default Credentials, donc l’authentification fonctionne de manière identique aux outils CLI. Si gcloud auth application-default login fonctionne, MCP aussi.

Ce que bq CLI fait et que MCP ne peut pas

C’est ici que la comparaison devient concrète. Les implémentations actuelles de MCP pour BigQuery se concentrent presque exclusivement sur les requêtes et l’exploration de schémas. De nombreux fondamentaux du data engineering n’existent tout simplement pas :

Pour le data engineering en production (où vous chargez régulièrement des fichiers, exportez des résultats, copiez des tables entre datasets et gérez des jobs), la CLI offre une couverture complète. MCP propose un sous-ensemble focalisé sur l’analytique.

Un workflow ETL réel

Considérez un pipeline typique : ingérer des fichiers CSV depuis Cloud Storage, les transformer avec SQL, exporter les résultats pour la consommation en aval.

# Charger les données brutes depuis GCS
bq load \
  --source_format=CSV \
  --autodetect \
  --replace \
  raw_data.daily_sales \
  'gs://my-bucket/sales/2025-01-*.csv'

# Transformer et matérialiser
bq query \
  --destination_table=analytics.sales_summary \
  --replace \
  --nouse_legacy_sql \
  '
  SELECT
    DATE_TRUNC(sale_date, MONTH) as month,
    region,
    SUM(amount) as total_sales,
    COUNT(DISTINCT customer_id) as unique_customers
  FROM raw_data.daily_sales
  GROUP BY 1, 2
  '

# Exporter pour consommation externe
bq extract \
  --destination_format=CSV \
  --compression=GZIP \
  analytics.sales_summary \
  'gs://my-bucket/exports/sales_summary_*.csv.gz'

La toolbox MCP gère l’étape du milieu à merveille. Tout le reste (le chargement, l’export) nécessite la CLI. Si vous construisez des pipelines avec Claude Code, vous avez besoin de bq que vous utilisiez ou non MCP en plus.

Comparaison de workflows côte à côte

Comparons les approches pour une tâche courante d’analytics engineering : explorer un dataset inconnu avant de construire des modèles dbt.

Le scénario

On vous a donné accès à un nouveau dataset ecommerce. Vous devez comprendre sa structure : quelles tables existent, leurs schémas, nombre de lignes et relations clés.

Approche CLI

# Lister toutes les tables
bq ls --format=pretty ecommerce

# Obtenir le schéma de la table orders
bq show --schema --format=prettyjson ecommerce.orders

# Profilage rapide : nombre de lignes et plage de dates
bq query --nouse_legacy_sql '
SELECT
  COUNT(*) as row_count,
  MIN(created_at) as earliest,
  MAX(created_at) as latest,
  COUNT(DISTINCT customer_id) as unique_customers
FROM ecommerce.orders
'

# Vérifier les nulls dans les colonnes clés
bq query --nouse_legacy_sql '
SELECT
  COUNTIF(customer_id IS NULL) as null_customers,
  COUNTIF(total_amount IS NULL) as null_amounts,
  COUNTIF(status IS NULL) as null_status
FROM ecommerce.orders
'

Claude génère ces commandes naturellement, les exécute en bash et parse la sortie. Les commandes sont compactes ; les résultats arrivent directement.

Approche MCP

Utilisateur : "Explore le dataset ecommerce - montre-moi toutes les tables avec leurs schémas et un profilage basique"

Claude :
1. Appelle list_table_ids(dataset="ecommerce") → retourne ["orders", "customers", "products", "order_items"]
2. Appelle get_table_info(table="orders") → retourne le schéma JSON complet
3. Appelle get_table_info(table="customers") → retourne le schéma JSON complet
4. Appelle get_table_info(table="products") → retourne le schéma JSON complet
5. Appelle get_table_info(table="order_items") → retourne le schéma JSON complet
6. Appelle execute_sql(query="SELECT COUNT(*)...") pour le profilage
7. Retourne un résumé formaté

L’approche MCP fournit des réponses structurées et validées. Mais elle charge les définitions d’outils au départ et fait passer chaque résultat par le contexte.

Comparaison des tokens

Pour une exploration de schéma simple, la CLI gagne en efficacité d’un ordre de grandeur. L’écart se réduit pour les workflows complexes multi-étapes où les réponses structurées de MCP simplifient le traitement en aval, mais il ne disparaît jamais.

Quand MCP gagne vraiment

La thèse « la CLI est meilleur » a des exceptions importantes. Rejeter MCP entièrement serait aussi erroné que de l’adopter sans esprit critique.

Sécurité et conformité en entreprise

Les serveurs MCP peuvent fonctionner dans des conteneurs isolés avec un accès au système de fichiers restreint. Les credentials restent externes, jamais exposés au LLM. Chaque appel d’outil produit une trace d’audit.

Pour les équipes soumises aux exigences SOX, HIPAA ou SOC 2, cela compte. La documentation de Google souligne que les serveurs MCP managés permettent aux agents de « requêter des données sans les risques de sécurité liés au déplacement des données dans les fenêtres de contexte ».

Un praticien soucieux de la sécurité a recommandé : « Utilisez les serveurs MCP plutôt que la CLI BigQuery pour maintenir un meilleur contrôle de sécurité sur ce que Claude Code peut accéder, surtout pour manipuler des données sensibles qui nécessitent de la journalisation ou ont des préoccupations potentielles de confidentialité. »

Si votre équipe conformité exige des logs d’audit de chaque accès aux données, MCP fournit cela par défaut. Les commandes CLI dans Claude Code nécessiteraient une instrumentation supplémentaire.

Parsing de sorties complexes

Les outils CLI produisent souvent des sorties verbeuses et incohérentes. Parser la sortie de bq show de manière fiable à travers différents types de tables nécessite de gérer des cas limites.

Les serveurs MCP pré-traitent les résultats en données structurées propres. Un développeur a noté que son serveur MCP Xcode parse « des milliers de lignes de sortie de build et retourne un objet propre et structuré : {errors: [...], warnings: []} », bien plus simple que le parsing regex de la sortie brute du compilateur.

Pour BigQuery, cela compte le plus quand les schémas sont complexes ou quand vous devez traiter les métadonnées de manière programmatique. Le get_table_info de MCP retourne du JSON cohérent ; bq show --schema retourne aussi du JSON, mais enveloppé dans une sortie que vous devez extraire.

APIs sans équivalent CLI

Beaucoup de systèmes d’entreprise (Salesforce, HubSpot, Jira, Notion) n’exposent que des APIs REST. Il n’y a pas de CLI à invoquer.

Les serveurs MCP fournissent des interfaces structurées qui améliorent considérablement la fiabilité du LLM. Demander à Claude de générer des commandes curl brutes avec des tokens OAuth est sujet aux erreurs. Un serveur MCP gère l’authentification et présente des interfaces d’outils propres.

Si vos workflows intègrent BigQuery avec des plateformes SaaS, MCP fournit le pont que la CLI ne peut pas offrir.

Orchestration multi-outils

La démo d’analytique retail de Google connecte BigQuery pour la prévision des revenus avec Maps pour l’analyse de localisation. L’agent requête les données de ventes, identifie les régions sous-performantes et récupère le contexte géographique, coordonnant à travers les services.

Pour les workflows cross-platform où les données circulent entre systèmes, les transferts structurés de MCP réduisent les erreurs. Les outils CLI fonctionnent en isolation ; les serveurs MCP peuvent partager le contexte.

Analytique en langage naturel pour les utilisateurs métier

L’outil ask_data_insights dans la toolbox BigQuery de Google permet une exploration de données conversationnelle qui nécessiterait un prompt engineering complexe avec la CLI seul.

Si vous construisez des interfaces pour des utilisateurs métier qui ne devraient pas avoir besoin de comprendre SQL, les capacités de langage naturel de MCP ajoutent une vraie valeur. la CLI suppose une maîtrise technique que MCP peut abstraire.

La recommandation pratique

Pour les workflows GCP/BigQuery, une approche hybride fonctionne le mieux. Ni la CLI ni MCP n’est universellement supérieur ; chacun excelle dans des contextes différents.

Utilisez la CLI quand :

• Chargement et export de données : bq load, bq extract, bq cp n’ont pas d’équivalents MCP
• Exploration rapide : Requêtes ad-hoc, vérifications de schéma, comptage de lignes
• Pipelines CI/CD : Portable, scriptable, pas de dépendances serveur
• Couverture complète des fonctionnalités : Partitionnement, clustering, vues autorisées, réservations
• L’efficacité des tokens compte : Workloads sensibles aux coûts, longues conversations
• Développement offline : Pas de processus serveur à maintenir

Utilisez MCP quand :

• Exigences de sécurité : Traces d’audit, isolation des credentials, exécution sandboxée
• Interfaces utilisateurs métier : Analytique en langage naturel sans SQL
• Intégrations SaaS : Systèmes sans équivalent CLI
• Réponses structurées : Quand le code en aval a besoin de JSON prévisible
• Orchestration multi-plateformes : Workflows couvrant BigQuery + autres services

Configuration hybride

Claude Code supporte les deux approches simultanément. Configurez MCP pour les outils qui en bénéficient tout en gardant l’accès CLI pour tout le reste :

{
  "mcpServers": {
    "bigquery": {
      "command": "npx",
      "args": ["-y", "@ergut/mcp-bigquery-server", "--project-id", "your-project-id"]
    }
  },
  "permissions": {
    "allow": [
      "Bash(bq *)",
      "Bash(gcloud *)",
      "Bash(gsutil *)",
      "Bash(dbt *)"
    ]
  }
}

Cette configuration donne à Claude l’accès à l’interface de requête structurée de MCP tout en préservant l’accès CLI pour le chargement de données, les exports et la gamme complète des capacités bq.

Pour les équipes priorisant l’efficacité des tokens, envisagez de commencer avec la CLI seul et d’ajouter les serveurs MCP sélectivement pour des cas d’usage spécifiques, plutôt que l’inverse.

La trajectoire de l’industrie

Cloudflare et Anthropic sont arrivés à des conclusions remarquablement similaires à quelques semaines d’intervalle fin 2025.

Le « Code Mode » de Cloudflare convertit les schémas d’outils MCP en APIs TypeScript, puis demande aux LLMs d’écrire du code contre ces interfaces. Le modèle ne voit jamais les définitions d’outils brutes, juste du TypeScript familier.

L’« exécution de code avec MCP » d’Anthropic prend un chemin d’implémentation différent mais arrive à la même destination : présenter les outils comme des modules de code accessibles par le système de fichiers que les agents découvrent à la demande. Écrire du code, pas des appels d’outils.

Les deux approches exploitent le même insight : les LLMs ont été entraînés sur du code, pas sur des formats d’appel d’outils synthétiques. Autant jouer sur leurs forces.

Pour les data engineers, cela valide ce que beaucoup soupçonnaient. Les outils CLI que vous utilisez depuis des années ne sont pas une technologie legacy en attente de remplacement. Ce sont des interfaces que Claude comprend déjà couramment, avec une décennie d’exemples d’entraînement à exploiter.

L’annonce de Google en décembre 2025 de serveurs MCP managés suggère que le protocole continuera de s’étendre. Les fonctionnalités enterprise (journalisation d’audit, gestion des credentials, sandboxing) s’amélioreront. Plus d’outils gagneront des interfaces MCP.

Mais pour les workflows BigQuery où bq et gcloud fournissent une couverture complète, les avantages fondamentaux d’efficacité du CLI natif demeurent. MCP ajoute un overhead qui peut ou non être justifié par vos exigences spécifiques.

Conclusion

Les preuves soutiennent une position nuancée : pour les workflows GCP/BigQuery, les commandes CLI natives via Claude Code offrent une efficacité de tokens supérieure (jusqu’à 98,7 % d’économies dans les cas extrêmes), une couverture complète des fonctionnalités (chargement de données, exports, gestion de tables) et exploitent l’entraînement extensif de Claude sur les commandes shell du monde réel.

Les serveurs MCP ajoutent une vraie valeur pour les exigences de sécurité enterprise, le traitement de réponses structurées, les intégrations SaaS et l’analytique en langage naturel, mais l’overhead en tokens est réel et s’accumule au fil des longues sessions.

Les outils ne sont pas mutuellement exclusifs. La flexibilité de Claude Code vous permet de configurer les deux approches, en choisissant selon le contexte. Utilisez la CLI pour les opérations de data engineering où vous avez besoin de l’ensemble complet des fonctionnalités bq. Utilisez MCP quand la sécurité, la structure ou l’orchestration cross-platform justifient l’overhead.

La leçon plus large s’étend au-delà de BigQuery. Lors de l’évaluation de toute intégration MCP, demandez-vous : un CLI existe-t-il déjà ? Quelle est l’étendue de son empreinte dans les données d’entraînement ? Quelles capacités MCP ajoute-t-il versus ce qu’il abstrait ?

Parfois le protocole le plus récent est le bon choix. Parfois l’outil que vous utilisez depuis une décennie est celui que votre assistant IA parle déjà couramment.

Pour BigQuery, c’est souvent ce dernier.