Le Sheet de la PME commence à ramer à 800 000 lignes. Quelqu'un lâche "BigQuery" en réunion. Le dirigeant ouvre la console GCP, voit les pricing, panique, ferme l'onglet. La semaine d'après il lit que "BigQuery c'est gratuit jusqu'à 1 To". Plus personne ne sait s'il faut y aller ou pas.

Voilà ce qu'il y a vraiment derrière BigQuery PME, sans le marketing Google et sans la peur de la facture surprise.

Ce que BigQuery est vraiment (et ce qu'il n'est pas)

Premier malentendu à enlever : BigQuery n'est pas une base de données classique. Tu ne le branches pas à ton site WordPress pour servir un panier. Tu ne le mets pas derrière une appli mobile en prod. Ce n'est pas fait pour ça, et tu vas le regretter si tu essaies.

BigQuery est un entrepôt de données analytique. Il sert à poser des questions SQL sur des gros volumes : combien de clients ont acheté en mars, croisé avec leurs sources d'acquisition, croisé avec leur LTV à 12 mois. Le genre de question que tu poses une fois par jour, pas mille fois par seconde.

Le pricing tient en deux lignes. Le stockage coûte environ 0,02 dollar par Go par mois, c'est presque gratuit. Le compute, lui, est facturé à la requête : 6,25 dollars par To scanné sur le pricing on-demand. Tu paies pour les octets scannés, pas pour le temps machine. C'est cette logique-là qui change tout, en bien comme en mal.

Le BigQuery free tier est réel et plus large qu'on ne le pense : 10 Go de stockage et 1 To de requêtes par mois, à vie, sans carte bleue obligatoire pour démarrer. Pour une PME bien tenue, ça suffit pendant longtemps.

Quand BigQuery PME vaut clairement le coup

Il y a cinq situations où la réponse est oui sans hésiter.

L'export GA4 natif. Depuis la mort d'Universal Analytics, BigQuery est le seul moyen propre d'avoir tes données analytics brutes, événement par événement, sans échantillonnage. L'export est gratuit, le branchement se fait en quatre clics dans l'interface GA4. Si tu fais du marketing data sérieux, tu y passeras de toute façon.

Le reporting multi-source. Tu as ton CRM dans HubSpot, tes paiements dans Stripe, ton acquisition dans Google Ads, ton SAV dans un Sheet. Tant que tu regardes ça séparément, chaque outil a sa version de la vérité. Tu poses tout dans BigQuery, tu écris une requête SQL qui joint les quatre, tu as enfin un seul tableau de bord cohérent.

L'e-commerce avec millions d'événements. Dès que tu fais plus de quelques centaines de transactions par jour avec du tracking comportemental détaillé, Sheets et même Postgres prod commencent à souffrir. BigQuery digère ces volumes sans broncher.

Sheets craque passé le million de lignes. Le seuil pratique où Google Sheets devient pénible tourne autour du million de lignes. Avant ça, tu survis avec des onglets séparés et des QUERY() bien écrits. Après, le calcul rame, les fichiers mettent vingt secondes à ouvrir, les collègues se font éjecter pendant qu'ils éditent. C'est le symptôme qui pousse la majorité des PME à franchir le pas.

L'historique pluriannuel. Tu veux garder 5 ans de logs commerciaux sans saturer ton Postgres de prod ni payer un disque qui grossit chaque mois. BigQuery est pensé pour stocker froid à très bas coût.

Quand c'est de l'overkill

L'inverse est tout aussi vrai. Beaucoup de PME mettent BigQuery dans leur stack par mimétisme, alors que rien ne le justifie.

Une seule source de données et un faible volume ? Sheets suffit. Tu vas passer trois semaines à monter un pipeline pour répondre à des questions que tu pourrais traiter avec un TCD.

Personne en interne ne sait écrire du SQL ? BigQuery ne change rien à ton problème. Tu auras juste déplacé la difficulté d'un endroit à un autre, en plus cher et plus lent à modifier.

Ton vrai besoin c'est un dashboard simple sur les ventes du mois ? Looker Studio se branche directement sur Google Sheets, gratuitement, en deux minutes. Pas besoin d'entrepôt pour ça.

Pas de problème d'échelle aujourd'hui et pas de problème de jointure ? Reste tranquille. BigQuery vs Sheets, ce n'est pas un débat de modernité, c'est un débat de besoin. Le bon outil est celui qui résout un problème que tu as vraiment.

Le piège du coût (celui qui fait peur en silence)

C'est ici que ça se gâte pour ceux qui foncent sans réfléchir. Le free tier endort. Tu démarres, tout est gratuit, tu te sens malin. Six mois plus tard, un développeur lance un SELECT * sur une table de 50 millions de lignes pour debugger un truc, et tu te retrouves avec une facture à trois chiffres pour une seule requête.

Le BigQuery coût n'est pas mystérieux, il est juste différent. Tu paies les octets scannés. Donc trois règles simples à graver.

Le partitionnement et le clustering ne sont pas optionnels au-delà de 10 millions de lignes. Une table partitionnée par date, c'est la différence entre scanner la plage de dates utile et scanner toute l'histoire. Le coût peut chuter d'un facteur 50 sur la même requête, parfois plus, et c'est gratuit à mettre en place le jour où tu crées la table.

SELECT * sur une grosse table est une punition automatique. Tu sélectionnes les colonnes dont tu as besoin, point. Cette discipline est plus importante que ton choix d'outil de BI.

Les budget alerts s'activent le jour 1, avant même de charger la première ligne. Un mail à 50 dollars de dépense, un autre à 200, un kill switch à 500. Trois clics dans la console GCP. Si tu ne fais pas ça, tu apprendras le pricing par la facture.

Le free tier suffit à 80 % des PME. Les 20 % qui dépassent oublient juste le partitionnement.

Avant de migrer : savoir ce qu'on stocke et pourquoi

Le réflexe classique du dirigeant qui découvre BigQuery, c'est "on balance tout dedans, on triera après". C'est exactement comme ça qu'on construit un entrepôt de données PME illisible et cher.

Migrer un bordel sur BigQuery, c'est juste un bordel plus cher à interroger. Le bon ordre est inverse : tu cartographies d'abord ce que tu as, tu identifies ce qui sert vraiment, tu jettes le reste, tu modélises le reliquat. C'est exactement ce que je détaille dans par où commencer un audit data, et c'est l'étape que les PME zappent le plus souvent.

Une heure passée à cadrer le périmètre fait économiser dix heures de pipelines mal foutus.

Stack typique d'une PME qui passe à BigQuery

Côté sources, presque toujours les mêmes briques : un CRM (HubSpot, Pipedrive, Zoho), Stripe pour le paiement, GA4 pour le web, des Google Sheets pour les saisies métier que personne ne migrera jamais.

Pour l'ingestion : Airbyte ou Fivetran pour les connecteurs prêts à l'emploi (HubSpot, Stripe, Shopify). Fivetran est plus stable, Airbyte moins cher et open source. Pour les cas custom, n8n fait le job sans coder un service backend.

Pour la modélisation, dbt si l'équipe a un data analyst, sinon des vues SQL bien commentées suffisent.

Pour la restitution, Looker Studio : gratuit, branchement natif sur BigQuery, suffisant pour la quasi-totalité des dashboards d'une PME.

Coût mensuel typique d'une stack comme ça : entre 0 et 50 euros par mois si tu auto-héberges Airbyte et que tu restes discipliné sur les requêtes. Compte 100 à 300 euros en plus si tu pars sur Fivetran SaaS, qui facture au volume de lignes synchronisées.

Alors, BigQuery ou pas ?

BigQuery ne résout pas un problème de données, il résout un problème d'échelle ou de jointure. Si tes données tiennent dans Sheets et qu'une seule personne les regarde, oublie. Si tu jongles avec cinq sources et que tu en as marre des exports manuels du lundi matin, c'est probablement le bon moment.

Le risque n'est pas BigQuery en soi. Le risque, c'est de l'utiliser sans avoir clarifié ce qu'on cherche à mesurer. Un entrepôt de données mal pensé coûte plus cher qu'un Sheet qui rame, parce que tu paies en plus le temps de le maintenir.

Si tu hésites entre rester sur Sheets ou monter une vraie stack analytique, c'est typiquement la conversation que j'ai avec les dirigeants en mission consultant data. Trente minutes pour poser le problème honnêtement et voir si BigQuery est la réponse, ou si c'est autre chose. Parlons-en, je te dirai franchement de quel côté tu te situes.