Connecter Google Cloud Storage à n8n : buckets, objets et compte de service

Un workflow n8n qui génère des factures PDF, télécharge des pièces jointes ou produit des images par IA bute toujours sur la même question : où déposer ces fichiers sans saturer le disque de l'instance ni le quota d'un Drive partagé ? Quand l'organisation vit déjà dans l'écosystème Google, la réponse s'appelle Google Cloud Storage. n8n expose un node Google Cloud Storage natif qui couvre buckets et objets, et le seul vrai obstacle est l'authentification. Ce guide couvre le compte de service, le rôle IAM minimal, les opérations du node, les classes de stockage et le partage d'un objet sans rendre le bucket public.

GCS, S3 ou Google Drive : trancher avant de configurer

La bonne question n'est pas le prix au gigaoctet, c'est : qui lit ces fichiers ? Drive est fait pour les humains — permissions par personne, aperçu, corbeille ; si vos utilisateurs manipulent les documents à la main, automatiser Google Drive reste le bon réflexe. GCS et S3 sont faits pour les machines : une clé plate, aucune interface de travail, mais une durabilité, un coût au Go et des règles de cycle de vie qu'aucun espace collaboratif n'offre.

Entre les deux, le critère est l'écosystème. GCS gagne si les fichiers doivent alimenter un entrepôt BigQuery ou si le projet GCP existe déjà. S3 gagne côté AWS, et surtout si vous voulez une porte de sortie : son credential accepte un endpoint personnalisé, donc Backblaze B2, Scaleway ou un MinIO auto-hébergé — tout l'intérêt de notre pipeline d'archivage vers S3. Le node Google Cloud Storage, lui, ne parle qu'à Google — et ce choix se rediscute mal. L'étude de Justice Opara-Martins, Reza Sahandi et Feng Tian, Critical analysis of vendor lock-in and its impact on cloud computing migration: a business perspective (Journal of Cloud Computing, 2016 — voir sur Google Scholar), menée auprès de 114 professionnels de l'informatique, montre que le verrouillage fournisseur reste un frein majeur à l'adoption du cloud : 35 % des répondants citent la dépendance excessive à un fournisseur unique parmi leurs principales réserves.

L'authentification : compte de service ou OAuth2

C'est ici que la plupart des gens abandonnent. Le champ Authentication du node propose deux valeurs, qui ne pointent pas vers la même credential :

• OAuth2 utilise la credential Google Cloud Storage OAuth2 API (Client ID et Client Secret créés dans la console GCP, scopes devstorage.full_control et cloud-platform), selon la procédure de notre guide OAuth2 Google.
• Service Account utilise la credential générique Google API, alimentée par le fichier JSON d'un compte de service.

Pour un workflow qui tourne la nuit, le compte de service s'impose : aucun utilisateur rattaché, des droits restreignables à un seul bucket. Trois étapes :

1. IAM & Admin → Comptes de service → Créer un compte de service, avec un nom explicite (n8n-storage).
2. Onglet Clés → Ajouter une clé → Créer une clé → JSON. Le fichier se télécharge une seule fois ; Google n'en garde aucune copie.
3. APIs & Services → Library → Cloud Storage JSON API → Activer. Systématiquement oubliée, cause n°1 des 403 décrites plus bas.

Le JSON contient bien plus que ce dont n8n a besoin :

{
  "type": "service_account",
  "project_id": "mon-projet-2026",
  "private_key": "-----BEGIN PRIVATE KEY-----\nMIIEv…\n-----END PRIVATE KEY-----\n",
  "client_email": "n8n-storage@mon-projet-2026.iam.gserviceaccount.com"
}

Dans la credential Google API, reportez deux champs : client_email dans Service Account Email, private_key dans Private Key (sans les guillemets qui l'entourent, sauts de ligne conservés). Le fichier n'a ensuite sa place que dans un gestionnaire de secrets, comme toute credential à sécuriser.

Le rôle IAM minimal

Le réflexe paresseux attribue roles/storage.admin au niveau du projet — une clé capable de vider tous les buckets. Le bon périmètre est roles/storage.objectAdmin sur un bucket précis :

gcloud storage buckets add-iam-policy-binding gs://factures-archive-2026 \
  --member="serviceAccount:n8n-storage@mon-projet-2026.iam.gserviceaccount.com" \
  --role="roles/storage.objectAdmin"

Plus étroits encore : roles/storage.objectCreator (déposer sans lire ni supprimer, idéal pour un archivage à sens unique) et roles/storage.objectViewer (lecture seule).

Les deux ressources du node : Bucket et Object

Le node expose deux ressources et les mêmes cinq verbes de chaque côté : Create, Delete, Get, Get Many, Update.

Bucket. Create et Get Many demandent un projet — un sélecteur Project en resource locator dans les versions récentes, un champ texte Project ID en version 1. Le Create accepte un bloc Additional Parameters calqué sur l'API JSON de Google (Location, Storage Class, Lifecycle, Versioning, Retention Policy). En pratique, on crée le bucket une fois dans la console.

Object est la ressource utile au quotidien.

• Create dépose un objet : Bucket Name, Object Name (la clé complète, archives/2026/08/facture-1042.pdf), et l'interrupteur Use Input Binary Field. Activé, il lit le binaire du node précédent via Input Binary Field (data par défaut) ; désactivé, un champ File Content apparaît. Le bloc Create Fields pose les métadonnées : Content Type, Cache Control, Storage Class, et un objet Metadata libre.
• Get lit un objet, et son paramètre décisif est Return Data : Metadata renvoie la fiche JSON, Object Data le contenu, placé dans la propriété nommée par Put Output File in Field. Un workflow qui « ne récupère pas le fichier » a souvent juste laissé Return Data sur Metadata.
• Get Many liste les objets via un bloc List Filters : Prefix pour ne remonter qu'un pseudo-dossier, Delimiter pour un listing en mode répertoire, Versions. La pagination passe par Return All ou Limit.
• Update et Delete ferment la liste, avec des préconditions optionnelles (Generation Match, Metageneration Match) qui évitent d'écraser une version plus récente que prévu.

Classes de stockage et cycle de vie

GCS propose quatre classes : Standard, Nearline, Coldline, Archive. Le principe tient en une phrase, sans citer le moindre tarif : plus la classe est froide, moins le stockage coûte au gigaoctet, mais plus la récupération est facturée — et plus la durée minimale de stockage facturée est longue (30 jours en Nearline, 90 en Coldline, 365 en Archive). Supprimer un objet Archive au bout d'un mois revient à payer onze mois de vide.

Ce compromis est une contrainte physique, pas un artefact commercial. Shobana Balakrishnan, Richard Black, Antony Rowstron et leurs coauteurs de Microsoft Research l'ont documentée dans Pelican: A Building Block for Exascale Cold Data Storage (OSDI 2014 — voir sur Google Scholar) : leur rack de stockage froid ne provisionne alimentation, refroidissement et bande passante que pour un usage rare, au point que seuls 8 % des disques peuvent tourner simultanément. C'est ce qui rend le froid économique, et ce qui explique son délai de récupération.

Conséquence côté n8n : n'implémentez pas la rétention dans le workflow. Une règle de cycle de vie posée sur le bucket bascule les objets vers une classe plus froide après N jours puis les supprime à l'échéance, sans consommer d'exécution — la même séparation des responsabilités que pour une purge RGPD automatique.

Partager un objet sans ouvrir le bucket

La tentation, quand un client doit récupérer une facture, est de cocher Public Read. Mauvaise idée : un bucket public est indexable, énumérable et hors de contrôle dès qu'une URL a circulé. Activez plutôt les deux garde-fous de GCS, l'accès uniforme au niveau du bucket et la prévention de l'accès public.

La bonne réponse est l'URL signée : un lien qui embarque une signature et une expiration, valable pour un objet et une méthode HTTP donnés, sans toucher aux permissions. Le node ne propose aucune opération de signature. Deux chemins : un node Code qui construit la chaîne canonique V4 et la signe avec la private_key via crypto, ou un node HTTP Request vers la méthode signBlob de l'API IAM Credentials, qui évite de manipuler la clé privée. Gardez l'expiration courte.

Cinq cas d'usage

• Archiver les factures PDF : le pipeline de devis et factures produit un binaire, qu'un Create range sous la clé factures/{{ $now.year }}/{{ $now.month }}/{{ $json.numero }}.pdf.
• Stocker les pièces jointes d'une boîte mail : en sortie du traitement par IA, le fichier brut part dans le bucket, seule la métadonnée reste en base.
• Déposer un export CSV que BigQuery ira lire : un export généré depuis n8n atterrit dans un bucket de staging avant ingestion — plus efficace que des insertions ligne à ligne.
• Sauvegarder les exports de workflows : un JSON quotidien dans un bucket versionné, en complément de la sauvegarde Git.
• Conserver les images produites par IA, qu'un workflow de génération d'images laisserait sinon grossir l'historique d'exécution.

Les pièges à connaître

• La clé JSON collée dans un node : une private_key en dur se retrouve dans l'export du workflow, dans Git et dans chaque copie partagée.
• L'API non activée : une 403 PERMISSION_DENIED évoquant « Cloud Storage JSON API has not been used in project … before or it is disabled » n'a rien à voir avec les rôles. Le sélecteur Project en mode liste appelle en plus l'API Cloud Resource Manager, à activer séparément si la liste reste vide.
• Le nom de bucket est globalement unique : factures ou backup sont pris depuis des années. Préfixez avec votre organisation — ce nom apparaît dans chaque URL.
• Les frais de sortie réseau : déposer coûte peu, relire coûte. Un workflow qui retélécharge le même objet à chaque exécution pour en extraire trois champs paie de l'egress à répétition ; stockez ces métadonnées en base au moment du dépôt.
• Rien ne s'efface tout seul : sans règle de cycle de vie, un bucket ne fait que grossir, et la facture reste le seul mécanisme d'alerte.
• Les gros fichiers : le binaire transite par l'instance et tient en RAM le temps de l'opération. Basculez le stockage binaire en mode filesystem, comme expliqué dans notre guide sur les fichiers volumineux.

En résumé

Le node tient en deux ressources et dix opérations, mais son adoption se joue ailleurs : un compte de service, une credential Google API alimentée par client_email et private_key, la Cloud Storage JSON API activée, et un roles/storage.objectAdmin limité à un bucket. Ensuite, trois réglages suffisent : Use Input Binary Field côté Create, Return Data côté Get, et le cycle de vie posé sur le bucket plutôt que dans le workflow.

Pour aller plus loin

Un bucket GCS prend tout son sens en bout de chaîne d'un pipeline qui produit des fichiers en continu. Le Pack Inbox IA (79 €) trie les emails entrants et isole les pièces jointes qui méritent d'être conservées, plutôt que de laisser la boîte mail jouer les archives par défaut. Et si la conservation répond à une obligation légale, le Pack Conformité & Audit (149 €) fournit la piste d'audit horodatée qui documente quel fichier a été déposé, quand et par quel workflow.