Google Sheets comme source de données analytics

Google Sheets est l’une des « sources de données fantômes » les plus communes en analytics engineering. Les parties prenantes métier maintiennent des tables de correspondance, des données de référence, des chiffres budgétaires, des inputs ad hoc et des tables de lookup dans des feuilles de calcul. Ces Sheets sont souvent faisant autorité — l’équipe commerciale vit dans son tracker de pipeline, la finance possède la Sheet d’allocation budgétaire — mais elles existent en dehors du plan de contrôle du data warehouse.

La lacune que cela crée : vos modèles dbt ont besoin des données, mais les données ne sont pas dans BigQuery. Votre pipeline a besoin que les données soient à jour, mais la Sheet se met à jour de manière imprévisible. Vos contrôles de qualité des données doivent valider la structure de la Sheet, mais les Sheets n’ont pas d’application de schéma.

Comment les Sheets entrent dans BigQuery

BigQuery supporte trois patterns principaux pour consommer des données Google Sheets.

Les tables externes permettent à BigQuery d’interroger directement une Sheet sans copier les données. La Sheet reste la source de vérité ; BigQuery la lit au moment de la requête. La configuration nécessite de partager la Sheet avec le compte de service BigQuery et de créer une définition de table externe pointant vers l’URL de la Sheet :

CREATE EXTERNAL TABLE my_dataset.budget_allocation
OPTIONS (
  format = 'GOOGLE_SHEETS',
  uris = ['https://docs.google.com/spreadsheets/d/SHEET_ID/edit'],
  skip_leading_rows = 1
);

Les tables externes ont des limitations : pas de partitionnement, pas de clustering, pas de cache. Chaque requête sollicite l’API Sheet, donc les performances se dégradent pour les grandes Sheets ou les requêtes fréquentes. Elles conviennent aux petites données de référence peu interrogées.

L’import par snapshot copie les données de la Sheet dans une table BigQuery native selon un planning. C’est plus approprié pour les données qui alimentent des pipelines — vous obtenez les performances du stockage natif tout en capturant un snapshot à un instant précis. Nécessitait auparavant Apps Script ou des exports manuels ; gws automatise cela.

Les seeds dbt représentent le chemin le plus simple pour les données véritablement statiques : téléchargez la Sheet en CSV, committez-la dans le projet dbt et référencez-la comme ref('seed_name'). Les seeds fonctionnent bien pour les tables de lookup qui changent rarement et dont les changements doivent être tracés dans le contrôle de version.

Ce que gws change

Avant [[fr/cli-google-workspace-gws|gws]], automatiser les interactions avec les Sheets nécessitait soit Google Apps Script (limité, sujet aux timeouts, sans intégration CI/CD) soit l’API REST brute (boilerplate substantiel d’authentification et de pagination). Le CLI gws encapsule cela derrière une interface cohérente que les agents IA peuvent utiliser directement.

Un agent avec gws disponible peut :

# Découvrir quelles Sheets existent dans Drive avec une convention de nommage
gws drive files list --params '{
  "q": "name contains \"Budget\" and mimeType = \"application/vnd.google-apps.spreadsheet\"",
  "fields": "files(id,name,modifiedTime)"
}'

# Lire les données d'une Sheet spécifique
gws sheets spreadsheets.values.get --params '{
  "spreadsheetId": "SHEET_ID",
  "range": "Sheet1!A1:Z100"
}'

# Écrire des résultats vers un tableau de bord Sheet
gws sheets spreadsheets.values.update --params '{
  "spreadsheetId": "DASHBOARD_ID",
  "range": "Summary!A2",
  "valueInputOption": "USER_ENTERED"
}' --json '{"values": [["2026-03-27", "1234", "99.2%"]]}'

Le dépôt inclut également des recettes organisées pour les patterns courants, notamment la lecture depuis une Sheet pour créer des événements Calendar (recipe-create-events-from-sheet) et la rédaction de brouillons d’e-mail depuis un contenu Doc (recipe-draft-email-from-doc).

Le pattern de convergence

La tendance plus large que gws représente : les outils d’infrastructure data (BigQuery, dbt, Airflow) et les outils de productivité (Gmail, Sheets, Docs, Calendar) convergent via des couches d’agents IA.

Un workflow concret maintenant réalisable sans code personnalisé :

L’agent découvre quelles Sheets existent dans Drive pour un projet client
L’agent inspecte la structure de la Sheet et valide les colonnes par rapport à une définition de table BigQuery
L’agent crée ou rafraîchit une table externe BigQuery pointant vers la Sheet
L’exécution dbt intègre les données de la Sheet comme source
L’agent rédige un e-mail récapitulatif via gws gmail avec les métriques clés de l’exécution dbt
L’agent met à jour un Google Doc runbook avec les changements de schéma détectés
L’agent crée un événement Calendar pour la prochaine révision de qualité des données

Les étapes 5 à 7 étaient précédemment manuelles. gws les rend automatisables depuis la même session agent qui exécute les étapes 1 à 4.

Le propre agent BigQuery Data Engineering de Google (expérimental début 2026) automatise la création de pipeline depuis le langage naturel. La couche sémantique dbt s’intègre directement avec Sheets et Excel pour l’accès des utilisateurs métier aux métriques. Ce n’est pas une coïncidence — ce sont des expressions de la même convergence.

Gérer les Sheets comme sources de données

Éliminer les Sheets de la chaîne de données n’est généralement pas faisable. Les parties prenantes métier utilisent les Sheets pour la saisie de données flexible, l’édition collaborative, les calculs pilotés par des formules et une interface ne nécessitant aucune formation. Les équipes qui ont tenté de remplacer les Sheets par des outils natifs de base de données ont généralement constaté que les parties prenantes créent de nouvelles Sheets en parallèle.

L’approche pratique est de traiter les Sheets comme faisant partie de l’infrastructure data pour les inputs appartenant aux utilisateurs métier, avec des outils qui les rendent des sources fiables. Cela signifie :

Validation de schéma lors de l’ingestion — vérifier les noms de colonnes et les types avant de charger dans BigQuery
Détection des changements — alerter quand la structure d’une Sheet change d’une manière qui casserait les modèles en aval
Imports de snapshot automatisés — ne pas interroger les Sheets au moment de l’exécution dbt ; importez-les d’abord dans des tables natives
Piste d’audit — journaliser quelle version de la Sheet a alimenté quelle exécution dbt

gws rend le côté automatisation de tout cela praticable. Le pattern de table externe BigQuery gère le côté requête. Ensemble, ils suffisent à faire des Sheets une source de données de première classe (bien que maladroite).