Pourquoi j’ai quitté n8n Cloud pour une instance self-hostée

Je vais être direct : si vous lisez cet article, c’est que vous avez déjà buté sur la facturation de n8n Cloud, ou que la simple idée de confier vos données à un tiers vous hérisse. Je suis passé par là. En accompagnant des TPE/PME sur des projets d’automatisation, j’ai rapidement compris que la version cloud de n8n n’était pas adaptée à tous les budgets ni à toutes les contraintes réglementaires.

La question que tout le monde me pose est simple : comment synchroniser n8n avec Google Sheets quand on veut une alternative self-hosted ? La réponse tient en une phrase : c’est tout à fait possible, et c’est même plus simple que ce que laissent croire les guides officiels.

Le vrai coût d’une automatisation cloud vs un VPS à 5 €/mois

Parlons chiffres, car c’est le premier déclencheur. Un abonnement n8n Cloud démarre autour de 50 à 60 € par mois pour des exécutions limitées. Dès que vos workflows dépassent un certain volume, vous passez au plan supérieur. La note grimbe vite.

En face, un petit VPS chez Hostinger, Hetzner ou DigitalOcean coûte entre 5 et 20 € par mois. Avec 2 Go de RAM et un peu de stockage SSD, vous faites tourner n8n sans sourciller. Sur un an, l’économie est considérable. Et vous ne dépendez plus d’un quota d’exécutions.

Le calcul est simple. Pour une PME qui exécute quelques milliers de tâches par mois, le self-hosted s’amortit en moins de deux mois. Ensuite, tout est économie.

Ce que le self-hosted change pour vos données et vos workflows

La différence ne se limite pas au portefeuille. Héberger n8n chez vous, ou sur un serveur que vous contrôlez, change votre rapport à la donnée. Vos credentials OAuth, vos identifiants Google Sheets, vos logs d’exécution : tout reste sous votre responsabilité.

C’est un argument décisif pour les métiers soumis à des obligations de confidentialité. Je pense notamment aux cabinets comptables et aux consultants qui manipulent des données financières sensibles. Avec le self-hosted, vous pouvez dire à votre client : « Vos données ne quittent pas mon serveur. » C’est un argument commercial imparable.

Et puis, il y a le catalogue de nœuds. La version self-hosted donne accès aux community nodes. Ces nœuds communautaires sont souvent ce qu’il manque cruellement dans la version cloud. Vous voulez un connecteur vers un logiciel métier obscur ? Il existe probablement un node. Vous voulez bidouiller une API non documentée ? Le nœud HTTP fait le travail. Bref, vous passez d’un outil puissant à un couteau suisse.

Les prérequis avant toute configuration Google Sheets

Avant de vous lancer dans la configuration, posons les fondations. Une installation n8n self-hosted ne s’improvise pas. Il faut un minimum de matériel et une URL publique propre.

Le matériel et l’environnement serveur minimal : 2 Go de RAM, Node.js, Docker

Pour faire tourner n8n confortablement, visez un serveur avec au moins 2 Go de RAM. C’est le strict minimum pour éviter les ralentissements. Un petit VPS avec 2 vCPU, 20 Go de SSD et 2 Go de RAM suffit pour des dizaines de workflows.

Côté environnement, vous avez deux options : installer Node.js directement sur la machine, ou passer par Docker. Mon conseil : choisissez Docker Compose. C’est plus simple à maintenir, à sauvegarder et à migrer. Si vous êtes un développeur aguerri, vous pouvez utiliser Node.js, mais pour un usage professionnel, la containerisation est la solution la plus propre.

Pourquoi une URL HTTPS publique est obligatoire pour OAuth2

Voici le point qui bloque tout le monde. Google Sheets, via l’API Google Sheets, exige une autorisation OAuth2. Or, OAuth2 requiert une URL de redirection. Et cette URL doit être accessible publiquement, en HTTPS.

Pourquoi ? Parce que Google doit renvoyer le navigateur de l’utilisateur vers votre instance n8n après l’autorisation. Si votre n8n tourne en local sur localhost:5678, Google ne peut pas y accéder. Périphérique de test, arrêtez-vous là : il vous faut une URL publique.

La solution la plus simple pour un test rapide est un tunnel HTTPS comme ngrok ou Pinggy. Mais pour un usage durable, je recommande un reverse proxy Caddy ou Nginx avec un certificat Let’s Encrypt. Nous verrons cela en détail plus bas.

Configurer Google Cloud Console pour connecter n8n à Google Sheets

Cette étape est le cœur du dispositif. La configuration dans Google Cloud Console est la partie que tout le monde redoute, mais elle se résume à trois actions : créer un projet, activer une API, générer des identifiants.

Créer un projet Google Cloud et activer l’API Google Sheets

Rendez-vous sur Google Cloud Console. Si vous n’avez jamais créé de projet, c’est le moment. Nommez-le simplement, par exemple « n8n-production ». Une fois le projet créé, activez l’API Google Sheets. C’est une formalité : cliquez sur « Bibliothèque », cherchez « Google Sheets API », activez.

Notez votre numéro de projet. Il vous servira plus tard pour identifier votre application dans les logs.

Configurer l’écran de consentement OAuth (type externe, test users, publication de l’app)

C’est ici que les choses se corsent. Ouvrez la section « Écran de consentement OAuth ». Choisissez le type externe. Même si vous êtes seul à utiliser l’application, Google impose ce paramétrage pour toute application qui n’est pas limitée à un domaine Google Workspace interne.

Renseignez les champs obligatoires : nom de l’application, email de support, coordonnées du développeur. Rien de sorcier. Ensuite, ajoutez les utilisateurs de test. C’est l’étape piège : si vous ne vous ajoutez pas comme utilisateur de test, l’autorisation OAuth échouera systématiquement.

Enfin, publiez l’application en cliquant sur « Publier l’application ». Attention : quand vous êtes en mode « Test », vos credentials expirent après 7 jours. Publier l’application rend le refresh token persistant. C’est indispensable pour une automatisation qui tourne en continu.

Créer vos identifiants OAuth 2.0 et renseigner les URI de redirection

Direction « Identifiants », puis « Créer des identifiants » et « ID client OAuth ». Choisissez « Application Web ». Deux champs apparaissent : URI d’autorisation et URI de redirection.

Pour n8n, ces valeurs sont presque toujours les mêmes, avec des noms différents selon la version. La version récente de n8n exige l’URI de redirection suivante : https://votre-domaine.com/rest/oauth2-credential/callback. Dans les versions plus anciennes, c’était https://votre-domaine.com/oauth2-credential/callback. Vérifiez votre version avant de copier.

Copiez ensuite votre Client ID et votre Client Secret. Vous en aurez besoin immédiatement après.

Installer n8n en self-hosted avec Docker Compose

Passons à l’installation. Le plus rapide est de déployer n8n avec Docker Compose. Voici ma configuration de base, que je fais évoluer selon les besoins du client.

Script Docker Compose prêt à l’emploi avec variables d’environnement

Créez un fichier docker-compose.yml sur votre serveur. Le contenu ci-dessous fonctionne tel quel pour une installation standard.

version: '3.8'

services:
  n8n:
    image: n8nio/n8n
    container_name: n8n
    restart: unless-stopped
    environment:
      - N8N_HOST=your-domain.fr
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://your-domain.fr/
      - GENERIC_TIMEZONE=Europe/Paris
      - TZ=Europe/Paris
    volumes:
      - n8n_data:/home/node/.n8n
    ports:
      - "5678:5678"
    networks:
      - proxy

volumes:
  n8n_data:

networks:
  proxy:
    external: true

Remplacez your-domain.fr par votre nom de domaine. La variable WEBHOOK_URL est cruciale : elle indique à n8n son URL publique. Sans elle, les webhooks et OAuth fonctionneront mal, voire échoueront.

Lancez ensuite votre instance : docker compose up -d. n8n démarre et écoute sur le port 5678.

Exposer n8n en HTTPS avec un reverse proxy Caddy ou Nginx (+ Let’s Encrypt)

Pour que l’URL publique fonctionne, vous devez configurer un reverse proxy. J’utilise personnellement Caddy pour sa simplicité. Ajoutez dans un fichier Caddyfile :

your-domain.fr {
    reverse_proxy n8n:5678
    encode gzip
}

Caddy génère automatiquement un certificat HTTPS via Let’s Encrypt. Aucune configuration SSL supplémentaire. C’est radicalement plus simple que Nginx, même si Nginx reste une excellente option si vous l’utilisez déjà pour d’autres sites.

Vérifiez que votre serveur laisse passer les ports 80 et 443 dans le pare-feu, et que votre nom de domaine pointe sur l’IP de votre VPS. Ensuite, ouvrez https://votre-domaine.fr dans un navigateur et terminez la configuration de n8n.

Ajouter les credentials Google Sheets dans n8n (OAuth2 pas à pas)

Votre n8n est opérationnel. Il est temps de connecter Google Sheets.

Dans l’interface n8n, ouvrez « Credentials », puis « Add Credential ». Cherchez « Google Sheets ». Vous verrez qu’il faut choisir entre OAuth2, service account et API key. Commençons par OAuth2, la méthode recommandée.

Tester la connexion avec un workflow simple : lire une ligne, écrire une ligne

Collez votre Client ID et votre Client Secret dans les champs correspondants. Cliquez sur « Sign in with Google ». Une fenêtre s’ouvre, choisissez le compte Google qui a accès au Google Sheet. Autorisez les accès demandés. Vous êtes connectés.

Créez maintenant un workflow de test. Ajoutez un nœud « Google Sheets » et sélectionnez l’opération « Get Row » ou « Append Row ». Attachez-le à un nœud « Manual Trigger ». Exécutez le workflow.

Si les données s’affichent dans votre feuille, le setup est validé. Sinon, vérifiez que votre compte a bien accès au document Google Sheets en question. Un credential OAuth n’a que les permissions de l’utilisateur qui a autorisé l’accès.

Automatiser l’ajout de lignes avec le trigger Google Sheets

Le vrai intérêt de n8n se révèle avec les triggers. n8n propose trois triggers natifs pour Google Sheets : « Ligne ajoutée », « Ligne modifiée », « Ligne ajoutée ou modifiée ». Rien à configurer de plus que le credential et le fichier concerné.

Le trigger « Ligne ajoutée » suffit pour synchroniser des entrées, par exemple les réponses d’un formulaire. Vous ajoutez ensuite un nœud « HTTP Request » ou « Slack » pour transmettre l’information. L’automatisation démarre dès qu’une ligne apparaît dans la feuille.

Astuce de terrain : ces triggers utilisent des webhooks internes à n8n. Il est donc indispensable que votre instance soit exposée sur une URL HTTPS publique, comme vu plus haut. Sinon, les triggers ne recevront pas la notification de Google.

L’alternative sans OAuth : le service account Google Sheets

Parfois, l’OAuth2 est un obstacle. Vous voulez un accès sans interaction humaine, sans écran de consentement. C’est là qu’intervient le service account.

Quand utiliser un service account à la place d’OAuth2

Un service account est une identité technique. Il n’appartient à aucune personne, et il peut accéder à un Google Sheet via une clé JSON. C’est idéal pour des automatisations internes où vous ne voulez pas dépendre d’une session utilisateur.

Dans Google Cloud Console, créez un service account, puis générez une clé au format JSON. Ensuite, ouvrez votre Google Sheet et partagez-le avec l’adresse email du service account (il ressemble à votre-sa@votre-projet.iam.gserviceaccount.com).

Dans n8n, choisissez le credential « Google Service Account » et téléversez la clé JSON. L’avantage est immédiat : aucun refresh token à gérer, aucune expiration. Le service account fonctionne en continu.

Limites pratiques du service account pour les workflows n8n

Mais gardez en tête les limites. Un service account ne peut pas accéder aux documents créés par un utilisateur si celui-ci ne l’ajoute pas explicitement aux personnes autorisées. Et les permissions sont parfois plus restrictives sur les feuilles partagées dans un domaine Google Workspace.

De plus, les triggers n8n « Ligne ajoutée » ou « Ligne modifiée » fonctionnent mal avec un service account. Le webhook de Google est lié à l’utilisateur qui a créé l’abonnement. Avec un service account, l’abonnement est plus fragile. Dans ma pratique, je réserve le service account aux opérations de lecture/écriture ponctuelles, pas aux workflows event-driven.

Trois workflows concrets pour synchroniser Google Sheets avec vos autres outils

Avant de conclure, je vous propose trois exemples issus de mes missions. Ils montrent concrètement ce que vous pouvez automatiser avec n8n self-hosted et Google Sheets.

Formulaire → Google Sheets → notification Slack

Le premier workflow consiste à collecter les réponses d’un formulaire, de les envoyer dans un Google Sheet, puis de notifier l’équipe sur Slack.

Le setup est simple : un trigger HTTP ou un nœud « Form » de n8n capture les données. Un nœud Google Sheets écrit la ligne, puis un nœud Slack envoie un message récapitulatif. Résultat : chaque lead ou chaque demande entrante est enregistrée et partagée en temps réel.

Google Sheets → génération de factures PDF

Le deuxième exemple me paraît bien plus convaincant. Vous tenez un tableau des heures passées par projet dans une feuille Google Sheets. À la fin du mois, vous voulez envoyer une facture PDF à votre client.

Votre workflow n8n lit les lignes du Google Sheet, les agrège par projet, puis utilise un nœud « PDF » comme pdfme pour générer un document. Ensuite, il envoie la facture par email via un nœud Gmail ou SMTP. Le gain de temps est immense par rapport à une saisie manuelle.

Google Sheets → mise à jour CRM ou base de données

Enfin, la synchronisation inverse est souvent nécessaire. Vous voulez que les données saisies dans un Google Sheet (par un commercial, par exemple) alimentent automatiquement votre CRM ou votre base de données.

N8n lit les nouvelles lignes, les transforme, puis effectue une requête vers votre CRM via HTTP ou un node natif. C’est une excellente alternative aux connecteurs coûteux de Zapier ou même de Make. Si vos besoins restent simples, notre guide sur l’alternative gratuite à Zapier pour une micro-entreprise vous aidera à comparer. Attention toutefois : pour des volumes de données massifs, Google Sheets n’est pas une base de données. Je le dis souvent à mes clients : à partir de 20 000 lignes, remplacez le tableau par une vraie base de données (PostgreSQL, MySQL). La scalabilité et l’intégrité des données seront meilleures.

Les erreurs fréquentes que je corrige dans les configurations n8n + Google Sheets

Je vais maintenant vous épargner les heures de débuggage que j’ai passées pour vous. Voici les trois erreurs que je vois le plus souvent.

L’autorisation OAuth échoue à cause d’un test user non ajouté

C’est l’erreur numéro une. Vous configurez vos credentials, vous cliquez pour autoriser, et Google affiche un écran d’erreur indiquant que l’accès est bloqué. La cause est presque toujours la même : votre compte n’est pas dans la liste des utilisateurs de test.

Retournez dans Google Cloud Console, section « Écran de consentement OAuth », et ajoutez votre adresse email. Puis retentez. Résolution en moins de deux minutes.

Le refresh token expire ou est révoqué après quelques heures

Autre frustration classique : le credential fonctionne, puis échoue au bout d’une journée. Le message d’erreur est souvent « Invalid_grant » ou « Refresh token expired ».

Vérifiez deux choses. D’abord, votre application est-elle en mode « Test » ou « Production » ? En mode test, les refresh tokens expirent après 7 jours. Publiez l’application pour résoudre cela. Ensuite, regardez si votre application a été récemment révoquée par l’utilisateur, parfois sans raison apparente.

Dans tous les cas, publiez votre application et gardez le même compte Google pour l’autorisation. Changer de compte en cours de route invalide le refresh token.

Le problème des URI de redirection en HTTP ou avec un tunnel instable

Enfin, les erreurs liées aux URI de redirection sont monnaie courante. Si Google affiche la fameuse erreur « redirect_uri_mismatch », c’est que l’URI déclarée dans la Google Cloud Console ne correspond pas exactement à celle utilisée par n8n.

Pensez à bien déclarer l’URL avec le chemin de callback en fonction de votre version de n8n. Le port 5678 n’est pas nécessaire si vous passez par un reverse proxy. Et évitez les tunnels tiers comme ngrok pour un usage en production : les URL changent à chaque redémarrage, ce qui casse définitivement l’autorisation OAuth.

Privilégiez Caddy et Let’s Encrypt pour disposer d’une URL stable et sécurisée.

Checklist finale pour valider votre synchronisation n8n self-hosted

Nous y voilà. Voici une checklist rapide pour vous assurer que tout est en ordre avant de lancer votre automatisation.

Vérifier l’URL WEBHOOK_URL, les scopes Google Sheets et la publication de l’application OAuth

  • Votre fichier docker-compose.yml contient les variables N8N_HOST, N8N_PROTOCOL et WEBHOOK_URL avec l’URL HTTPS de votre domaine.
  • Votre instance n8n est accessible depuis l’extérieur via https://votre-domaine.fr.
  • L’API Google Sheets est activée dans votre projet Google Cloud.
  • L’écran de consentement OAuth est public (ou au minimum en mode « Production » avec votre compte comme utilisateur de test).
  • Les scopes Google Sheets demandés incluent bien /auth/spreadsheets pour la lecture et l’écriture.
  • Les URI de redirection correspondent à votre version de n8n (/rest/oauth2-credential/callback ou /oauth2-credential/callback).
  • Votre credential n8n se connecte et exécute un test de lecture/écriture.

Tester les droits du service account et les performances de votre VPS avant de passer en production

  • Si vous utilisez un service account, ajoutez son adresse email dans le partage de votre Google Sheet et testez l’accès avec un workflow simple.
  • Surveillez la consommation de RAM de votre VPS lors de l’exécution de plusieurs workflows simultanés. 2 Go de RAM sont confortables tant que vous ne lancez pas d’images ou de fichiers volumineux en parallèle.
  • Pensez à configurer un hébergement sécurisé : un pare-feu et des sauvegardes régulières du volume Docker n8n_data.

Une fois cette checklist cochée, vous êtes officiellement indépendant. Vous entrez dans le cercle restreint des utilisateurs qui synchronisent n8n avec Google Sheets sans abonnement cloud.

Si vous rencontrez un blocage sur une étape, relisez la section correspondante. Dans la plupart des cas, l’erreur est dans l’écran de consentement OAuth. Et si vous hésitez entre OAuth2 et service account, posez-vous une question : votre workflow est-il déclenché par un événement ou simplement par un schedule ? Événement = OAuth2. Schedule = service account.

L’automatisation, enfin entre vos mains.