Quels droits d'accès faut-il pour exporter vos données Search Console vers BigQuery ?

Pourquoi Google impose-t-il ces restrictions de permissions ?

L'export en masse de Search Console vers BigQuery n'est pas qu'un simple téléchargement CSV. C'est un flux automatisé qui écrit directement dans votre infrastructure Google Cloud. Google exige donc un niveau de contrôle élevé : seul un propriétaire de la propriété peut autoriser ce pipeline.

Les rôles BigQuery Job User et Data Editor ne sont pas anodins. Le premier permet au compte de service de lancer des jobs (requêtes, exports), le second lui donne le droit d'écrire dans vos datasets. Sans ces deux permissions, le compte de service Search Console n'a aucun moyen d'alimenter votre entrepôt de données.

Qu'est-ce qu'un compte de service Search Console exactement ?

Un compte de service, c'est une identité machine — pas un utilisateur humain. Google Search Console l'utilise pour communiquer avec BigQuery en votre nom. Concrètement, c'est une adresse email qui ressemble à service-xxxx@gcp-sa-searchconsole.iam.gserviceaccount.com.

Ce compte de service doit être explicitement autorisé dans votre projet Google Cloud. Si vous oubliez cette étape, l'export se configure en apparence, mais échoue silencieusement au moment de l'exécution. Et vous perdez du temps à chercher pourquoi vos données n'arrivent pas.

Quelles sont les étapes précises pour accorder ces permissions ?

Depuis la console Google Cloud, vous devez ajouter ce compte de service comme membre de votre projet. Ensuite, vous lui assignez les deux rôles : BigQuery Job User (pour qu'il puisse soumettre des tâches) et BigQuery Data Editor (pour qu'il puisse écrire dans vos tables).

Google ne laisse aucune marge de manœuvre : un simple « Viewer » ne suffit pas, un « Owner » du projet Cloud n'est pas obligatoire, mais ces deux rôles spécifiques sont non négociables.

• Seul un propriétaire Search Console peut initier l'export en masse — pas un utilisateur avec accès complet ni un utilisateur restreint.
• Le compte de service Search Console doit avoir les rôles BigQuery Job User et BigQuery Data Editor dans votre projet Google Cloud.
• Sans ces permissions, l'export se configure mais n'écrit aucune donnée — erreur silencieuse garantie.
• Ces restrictions visent à protéger votre infrastructure Cloud contre des écritures non autorisées.

Cette déclaration est-elle cohérente avec la logique de sécurité Google Cloud ?

Oui, totalement. Google applique ici le principe du moindre privilège : chaque service ne reçoit que les droits strictement nécessaires. Exiger que seul le propriétaire Search Console puisse lancer l'export, c'est éviter qu'un contributeur lambda ne vide vos données dans un projet Cloud mal sécurisé.

Les deux rôles BigQuery imposés sont aussi bien calibrés. Job User sans Data Editor, ça ne sert à rien (impossible d'écrire). Data Editor sans Job User, pareil (impossible de lancer le processus). Google ne laisse pas d'ambiguïté, et c'est plutôt sain pour éviter les erreurs de config.

Quels pièges faut-il anticiper dans la pratique ?

Le premier piège, c'est de croire que « propriétaire du projet Google Cloud » suffit. [A vérifier] dans certains cas, un propriétaire Cloud qui n'est pas propriétaire Search Console ne peut pas lancer l'export. La hiérarchie des permissions est stricte et cloisonnée entre les deux produits.

Deuxième piège : ne pas identifier le bon compte de service. Si vous avez plusieurs projets Cloud ou plusieurs propriétés Search Console, vous risquez d'accorder les permissions au mauvais service account. Google ne vous prévient pas toujours de manière explicite — l'export échoue juste sans bruit.

Cette approche est-elle vraiment nécessaire pour tous les types d'exports ?

Non. Si vous vous contentez des exports manuels via l'interface Search Console (CSV, Google Sheets), aucune permission BigQuery n'est requise. Ces restrictions ne concernent que l'export en masse automatisé vers BigQuery, qui nécessite une intégration infrastructure.

Soyons honnêtes : la plupart des sites n'ont pas besoin de cet export. Mais dès que vous dépassez les 1 000 lignes de données par jour, ou que vous voulez croiser Search Console avec d'autres sources (Analytics, CRM), BigQuery devient indispensable. Et là, ces permissions deviennent votre sésame.

Que faut-il faire concrètement pour configurer l'export ?

Première étape : vous connecter à Google Search Console avec un compte propriétaire de la propriété. Pas « utilisateur complet », pas « utilisateur restreint » — propriétaire. Ensuite, vous lancez la configuration de l'export en masse vers BigQuery depuis l'interface GSC.

Deuxième étape : vous identifiez le compte de service Search Console. Google vous fournit l'adresse email du service account au moment de la configuration. Notez-la précisément.

Troisième étape : vous allez dans la console Google Cloud, section IAM, et vous ajoutez ce compte de service comme membre de votre projet. Vous lui assignez les rôles BigQuery Job User et BigQuery Data Editor. Sauvegardez, attendez quelques minutes que les permissions se propagent, puis testez.

Quelles erreurs éviter absolument ?

Ne confondez pas « propriétaire Search Console » et « administrateur du site ». Le premier est un rôle GSC, le second peut être un rôle CMS ou hébergement. Seul le rôle GSC compte ici.

Ne donnez pas des permissions BigQuery trop larges « au cas où ». Accorder BigQuery Admin au compte de service, c'est un risque de sécurité inutile. Restez sur Job User + Data Editor, point.

Et ne lancez pas l'export sans avoir vérifié que le dataset BigQuery existe déjà et qu'il est dans la bonne région. Google Cloud refuse d'écrire dans un dataset inexistant ou mal localisé.

Comment vérifier que tout est bien configuré ?

Une fois l'export lancé, attendez 24 à 48 heures et vérifiez que des tables apparaissent dans votre dataset BigQuery. Si rien ne s'affiche, retournez dans Google Cloud IAM et vérifiez que le compte de service a bien les deux rôles requis.

Vous pouvez aussi consulter les logs BigQuery (section « Job history ») pour voir si des tentatives d'écriture ont échoué avec une erreur de permissions. C'est souvent plus bavard que l'interface Search Console.

• Vérifier que vous êtes bien propriétaire de la propriété Search Console, pas juste utilisateur.
• Noter l'adresse email du compte de service Search Console fournie lors de la configuration.
• Accéder à Google Cloud Console > IAM et ajouter ce compte de service avec les rôles BigQuery Job User et BigQuery Data Editor.
• Créer le dataset BigQuery cible avant de lancer l'export (région cohérente avec votre projet).
• Attendre 24-48h puis vérifier l'arrivée des données dans BigQuery.
• Consulter les logs BigQuery en cas d'échec silencieux pour diagnostiquer les erreurs de permissions.