Les exports BigQuery Search Console s'accumulent-ils vraiment sans limite ?

Pourquoi Google ne gère-t-il pas l'expiration automatiquement ?

L'export en masse de Search Console vers BigQuery est conçu comme un flux unidirectionnel : Google pousse les données, point final. La gestion du cycle de vie — combien de temps conserver ces données, quand les archiver ou les supprimer — reste entièrement sous votre responsabilité.

C'est cohérent avec la logique de BigQuery : c'est votre entrepôt de données, pas un service managé par Google Search Console. Vous décidez de ce que vous en faites, mais aussi de ce que ça vous coûte.

Que se passe-t-il concrètement si on ne fait rien ?

Les données s'accumulent mois après mois. Chaque jour apporte son lot de nouvelles lignes : requêtes, impressions, clics, positions moyennes. Sur un site avec du volume, ça peut représenter des millions de lignes mensuelles.

Sans politique d'expiration, vous vous retrouvez avec un dataset qui grossit indéfiniment. Et qui dit stockage croissant dit coûts croissants — BigQuery facture au volume stocké et au volume scanné lors des requêtes.

Quelles sont les options pour contrôler la rétention ?

BigQuery propose plusieurs mécanismes : expiration au niveau de la table, expiration au niveau du dataset, ou encore des scripts de suppression conditionnelle via SQL. Vous pouvez aussi utiliser des tables partitionnées avec expiration automatique des partitions anciennes.

• Configurer une date d'expiration par défaut sur le dataset (ex : 13 mois)
• Définir une expiration spécifique par table si vous voulez une granularité plus fine
• Utiliser des partitions temporelles avec expiration automatique des partitions dépassant un seuil
• Mettre en place un script automatisé qui supprime les données au-delà d'une certaine ancienneté

Cette logique est-elle vraiment justifiée côté Google ?

Soyons honnêtes : du point de vue de Google, c'est logique. BigQuery n'est pas un produit Search Console, c'est un service d'entreposage de données généraliste. Google ne peut pas deviner combien de temps vous voulez garder vos données — certains analystes veulent 3 ans d'historique, d'autres purgent après 6 mois.

Par ailleurs, imposer une expiration par défaut rigide serait source de frustrations : imaginez perdre 2 ans d'historique parce qu'une règle automatique a viré vos tables sans prévenir. Donc oui, c'est à vous de gérer. Mais — et c'est là que ça coince — Google ne fait aucun effort pour prévenir les utilisateurs naïfs. Pas d'alerte dans l'interface, pas de rappel lors de la configuration initiale. Résultat : beaucoup découvrent le problème en recevant une facture salée. [À vérifier] qu'une notification soit ajoutée dans Search Console lors de la première configuration.

Dans quels cas cette accumulation devient-elle problématique ?

Sur un petit site avec 10k impressions mensuelles, l'impact financier reste marginal même après 2 ans sans nettoyage. Mais sur un site avec plusieurs millions d'impressions quotidiennes — e-commerce, média, marketplace — les données explosent vite.

Le vrai risque, au-delà du coût de stockage, c'est le coût de requêtage. Si vos dashboards scannent systématiquement 3 ans de données alors que vous n'analysez que les 6 derniers mois, vous brûlez du budget inutilement. C'est là qu'une stratégie de partitionnement intelligent devient indispensable.

Quelle est la bonne durée de rétention pour un site SEO classique ?

Ça dépend. Pour une analyse SEO standard, 13 mois est souvent suffisant : ça couvre une année complète + 1 mois de comparaison glissante. Si vous travaillez sur des analyses de saisonnalité pluri-annuelles ou des études longitudinales, 24-36 mois peuvent se justifier.

Au-delà, l'utilité décroît rapidement. Les données de Search Console de plus de 3 ans sont rarement actionnables — le paysage concurrentiel, l'algorithme, votre site ont trop changé. Mieux vaut exporter des agrégats annuels dans un autre outil si vous voulez garder des traces historiques légères.

Comment configurer l'expiration sur BigQuery concrètement ?

Plusieurs niveaux d'action possibles. Le plus simple : définir une expiration par défaut au niveau du dataset. Ça s'applique à toutes les tables qu'il contient, présentes et futures.

Vous pouvez le faire via l'interface BigQuery (onglet « Détails » du dataset, section « Expiration des tables par défaut ») ou via la CLI bq : bq update --default_table_expiration 31536000 mon_dataset (durée en secondes, ici 365 jours).

Pour une approche plus fine, utilisez des tables partitionnées par date avec expiration automatique des partitions. Exemple : une partition par jour, expiration après 395 jours. Ça permet de garder un historique précis tout en purgeant automatiquement l'ancien.

Quelles erreurs éviter absolument ?

• Ne pas définir d'expiration du tout — le piège par défaut, celui dans lequel tombent 80% des utilisateurs
• Configurer une expiration trop courte et perdre des données stratégiques en pleine analyse
• Oublier de tester la configuration sur un dataset de dev avant de l'appliquer en prod
• Ne pas documenter la politique de rétention dans votre équipe — 6 mois après, personne ne sait pourquoi les données disparaissent
• Scanner systématiquement toutes les données sans filtrer par partition — coût de requête explosif

Que faut-il surveiller une fois la config en place ?

Vérifiez régulièrement que l'expiration fonctionne comme prévu. Un coup d'œil rapide dans BigQuery : est-ce que les tables anciennes disparaissent bien ? Si vous voyez des tables datant de 2 ans alors que votre politique prévoit 13 mois, quelque chose cloche.

Surveillez aussi vos coûts BigQuery via Google Cloud Console. Si le stockage continue de grimper malgré l'expiration configurée, vous avez peut-être un problème de configuration ou des tables hors dataset principal qui échappent à la règle.