Supabase vs Google Sheets : L'Erreur que Font 90% des Automatiseurs (et Comment L'Éviter)

Supabase vs Google Sheets : L'Erreur que Font 90% des Automatiseurs

Tu as 50 workflows n8n qui écrivent dans Google Sheets. Ton client est content. Et puis un jour, tout casse — en production, un lundi matin, pendant le pic de trafic. Bienvenue dans l'erreur la plus commune de l'automatisation moderne.

C'est une scène qu'on a vécue des dizaines de fois.

Un client vient nous voir avec un workflow Make ou n8n "qui marchait très bien". Des centaines de lignes dans un Google Sheet. Des données importantes — leads, commandes, logs, résultats d'API. Et un jour, les données sont incomplètes, dans le désordre, ou tout simplement perdues.

Google Sheets n'est pas une base de données. C'est un tableur. Et utiliser un tableur comme infrastructure de données pour des workflows d'automatisation en production, c'est l'une des erreurs les plus coûteuses que l'on voit chez les automatiseurs débutants et intermédiaires.

Dans cet article, je vais vous expliquer exactement pourquoi — avec des chiffres, des cas concrets — et vous montrer comment Supabase règle ces problèmes définitivement. Pas pour vendre Supabase à tout prix, mais pour vous donner un framework de décision honnête : quand utiliser quoi, et comment migrer si vous êtes déjà coincé dans un Google Sheet.

---

Pourquoi Google Sheets séduit les automatiseurs (et c'est normal)

Soyons honnêtes : Google Sheets est un excellent point de départ. Il a des atouts réels que personne ne peut nier.

Zéro configuration, interface universelle

Il n'y a rien à installer. Pas de compte développeur, pas de schéma à définir, pas de migration à gérer. Vous ouvrez un onglet, vous nommez vos colonnes, et vous commencez. Pour un prototype ou un MVP, c'est imbattable.

L'interface est connue de tout le monde dans l'entreprise. Le client non-technique peut ouvrir le Sheet, voir les données, les modifier manuellement si besoin. C'est une transparence immédiate que peu d'outils offrent.

Intégration native dans tous les outils d'automatisation

n8n, Make, Zapier, Activepieces — ils proposent tous un nœud Google Sheets natif. Lecture, écriture, mise à jour, suppression : tout fonctionne en quelques clics, sans configuration avancée. C'est un accélérateur de développement considérable au démarrage.

Gratuit et collaboratif

Pour un budget serré, difficile de faire mieux. Google Sheets fait partie de Google Workspace (souvent déjà payé) et ne coûte rien de plus. On peut partager le lien, collaborer en temps réel, ajouter des formules pour visualiser les données.

Résultat : Google Sheets est parfait pour les prototypes rapides, les tests de concept, les workflows à faible volume. Le problème, c'est que beaucoup d'automatiseurs ne passent jamais à l'étape suivante. Ils gardent Google Sheets en production, avec des volumes qui explosent, et c'est là que tout déraille.

---

Les 5 points de rupture que personne ne vous dit

Point de rupture #1 — Les rate limits de l'API Google

L'API Google Sheets a des limites strictes :

• 300 requêtes par minute par projet
• 100 requêtes par 100 secondes par utilisateur
• 60 requêtes par minute par utilisateur pour les opérations d'écriture

Ces limites semblent élevées. Elles ne le sont pas.

Un seul workflow n8n qui tourne toutes les 30 secondes, qui lit 5 lignes et en écrit 3, consomme déjà 16 requêtes par minute. Ajoutez 3 ou 4 workflows de ce type sur le même projet, et vous approchez rapidement de la limite — sans même le réaliser.

Ce qui se passe quand vous atteignez la limite : L'API retourne une erreur 429 Too Many Requests. Selon la façon dont votre workflow gère les erreurs, les données sont soit perdues, soit en doublon, soit stockées dans un état intermédiaire incohérent. n8n retente automatiquement, ce qui aggrave parfois le problème.

Cas réel chez un client : Un workflow de scoring de leads qui tournait toutes les 15 minutes sur une liste de 2 000 prospects. À partir de 800 requêtes par jour, l'API commençait à throttler. Résultat : 30% des leads n'étaient pas scorés, sans aucune alerte visible.

Point de rupture #2 — L'absence de vraie concurrence

Google Sheets n'est pas conçu pour être écrit par plusieurs processus simultanément. Quand deux workflows n8n essaient d'écrire dans le même Sheet en même temps, vous obtenez l'un de ces scénarios :

• L'écriture la plus récente écrase la précédente — des données sont perdues sans erreur visible
• Une erreur de conflit — un des deux workflows échoue silencieusement
• Des données partiellement écrites — une ligne commence à s'écrire pendant qu'une autre finit, créant une ligne corrompue

Dans une vraie base de données comme PostgreSQL (sur lequel repose Supabase), ce problème est réglé depuis des décennies par les transactions ACID — Atomicité, Cohérence, Isolation, Durabilité. Soit l'écriture réussit complètement, soit elle est annulée complètement. Il n'existe pas d'état intermédiaire.

Scénario classique : Un workflow de synchronisation WooCommerce ↔ CRM. Deux commandes arrivent en même temps. Les deux workflows veulent lire le compteur de commandes sur la ligne 1, l'incrémenter de 1, et réécrire. Les deux lisent "47", les deux écrivent "48". Le compteur aurait dû afficher "49". Vous avez perdu une commande dans vos statistiques — sans aucune erreur visible.

Point de rupture #3 — Zéro typage, zéro intégrité

Dans Google Sheets, tout est une chaîne de caractères. Il n'existe pas de type "entier", "date", "booléen" ou "UUID" au niveau de l'API. Cette absence de types entraîne une série de bugs insidieux :

• Les dates changent de format selon l'OS, la locale, ou la configuration du Sheet. "2026-05-23" peut devenir "23/05/2026", "May 23, 2026", ou "45789" (numéro de série Excel). Vos formules de calcul d'intervalle cassent sans explication.
• Les nombres deviennent du texte quand ils contiennent un espace ou une virgule. Vos agrégations retournent des résultats faux.
• Les doublons sont invisibles — il n'existe pas de contrainte d'unicité. Rien ne vous empêche d'écrire deux fois la même commande, le même client, ou le même ID.
• Les valeurs NULL n'existent pas — une cellule vide et une cellule avec un espace sont indiscernables pour l'API.

Dans Supabase (PostgreSQL), vous définissez un schéma : order_id UUID PRIMARY KEY, amount DECIMAL(10,2) NOT NULL, created_at TIMESTAMPTZ DEFAULT NOW(). Il est physiquement impossible d'insérer une donnée invalide. La base refuse l'opération et retourne une erreur claire.

Point de rupture #4 — Pas de sécurité des données

Google Sheets repose sur un modèle de partage tout-ou-rien. Quand vous donnez accès à un Sheet, la personne voit toutes les lignes de ce Sheet. Il est impossible, nativement, de restreindre la visibilité à certaines lignes selon l'utilisateur connecté.

Implication pour les automatiseurs : Si vous gérez des données de plusieurs clients dans un seul Sheet (leads, commandes, logs), et qu'un client vous demande un accès en lecture — vous devez soit lui donner accès à tout, soit créer un Sheet séparé par client (ce qui multiplie les workflows et la complexité).

Supabase intègre nativement la Row Level Security (RLS) — un mécanisme PostgreSQL qui filtre les lignes automatiquement selon l'identité de l'appelant. Vous définissez des politiques du type : "Un utilisateur ne peut lire que les lignes où client_id correspond à son ID JWT". Le filtrage est appliqué au niveau de la base de données, pas dans votre code.

Point de rupture #5 — Scalabilité nulle passé 10 000 lignes

Google Sheets a une limite officielle de 10 millions de cellules par fichier. En pratique, les performances se dégradent bien avant :

• À 10 000 lignes : les formules VLOOKUP et QUERY commencent à ramer
• À 50 000 lignes : les temps de chargement de l'interface dépassent 5 secondes
• À 100 000 lignes : les opérations via l'API prennent plusieurs secondes par requête, et les formules de synthèse sont souvent incorrectes

Ce n'est pas un problème hypothétique. Un workflow qui capture 100 leads par jour atteint 36 500 lignes en un an. Un webhook de suivi de commandes pour un site e-commerce moyen peut générer 200 000 lignes en 18 mois.

PostgreSQL, lui, gère des milliards de lignes avec les bons index. Aucune dégradation de performance perceptible entre 1 000 et 10 millions de lignes, pour autant que le schéma soit bien conçu.

---

Le coût réel de cette erreur

L'erreur Google Sheets a trois types de coûts que les automatiseurs sous-estiment systématiquement.

Coût 1 : Le temps de debug

Quand vos données sont corrompues ou manquantes, vous ne savez pas toujours pourquoi. Pas d'historique de transactions, pas de logs d'erreur natifs, pas de contraintes qui auraient bloqué l'écriture invalide. Vous passez des heures à reconstituer ce qui s'est passé en croisant les logs de n8n avec les horodatages du Sheet.

Estimation : 2 à 4 heures par incident sur un workflow de production. Sur 12 mois avec un Sheet mal dimensionné, nos clients ont perdu en moyenne 18 heures de debug.

Coût 2 : La dette technique

Chaque workaround que vous ajoutez pour contourner les limites de Sheets — feuilles multiples, logique de déduplication dans n8n, formules de vérification, scripts Apps Script — crée de la dette technique. Cette dette s'accumule jusqu'au moment où refactoriser est plus long que de tout reconstruire.

Coût 3 : La refonte complète

C'est le coût le plus brutal. Quand un client veut passer à l'échelle et que votre architecture ne suit pas, il faut tout reconstruire. Nouveau schéma de données, nouvelle logique de mapping dans n8n, tests de migration, re-formation du client.

Chez BOVO Digital, la migration Google Sheets → Supabase représente en moyenne 60 à 70% du coût qu'aurait coûté une architecture correcte dès le départ. Vous payez deux fois.

---

Ce que Supabase change concrètement

Supabase n'est pas "juste une autre base de données". C'est une plateforme qui rend PostgreSQL accessible sans DevOps.

PostgreSQL full avec toutes ses garanties

Vous obtenez une vraie base de données relationnelle : types stricts, contraintes NOT NULL et UNIQUE, clés étrangères, transactions ACID, index pour les requêtes rapides. Votre workflow n8n qui écrit des commandes peut avoir une contrainte order_id UUID PRIMARY KEY — il devient physiquement impossible d'insérer un doublon.

API REST + Realtime out of the box

Supabase génère automatiquement une API REST pour chaque table, protégée par votre clé service_role. Dans n8n, vous utilisez le nœud HTTP Request ou le nœud Supabase natif pour lire, écrire, mettre à jour et supprimer des lignes — exactement comme avec Google Sheets, mais sans rate limits et avec toutes les garanties de PostgreSQL.

Le mode Realtime vous permet de déclencher un webhook n8n dès qu'une ligne est insérée ou modifiée — sans polling. C'est la base d'architectures event-driven propres.

Row Level Security sans écrire de middleware

Les politiques RLS de Supabase sont définies en SQL pur et appliquées au niveau de la base :

CREATE POLICY "client_isolation" ON orders
  FOR ALL USING (client_id = auth.uid());

Avec cette politique, un utilisateur ne voit que ses commandes — peu importe comment il accède à la base. Pas de filtre dans votre code, pas de risque d'oubli.

Gratuit jusqu'à un niveau professionnel réel

Le tier gratuit de Supabase inclut :

• 2 projets actifs
• 500 MB de stockage
• 50 000 requêtes actives par mois
• 1 GB de bande passante

Pour un projet de taille moyenne, vous ne payez rien pendant les premiers mois. Le tier Pro à 25 $/mois inclut 8 GB de stockage et des backups quotidiens automatiques — bien moins cher qu'Airtable à volume équivalent.

Pas de rate limits sur les lectures

Contrairement à l'API Google Sheets, Supabase/PostgreSQL n'impose pas de rate limits sur les opérations de lecture. Vos workflows peuvent requêter la base aussi souvent qu'ils en ont besoin, sans risque de throttling. Les seules limites sont celles de votre serveur, que vous contrôlez entièrement.

---

Tableau comparatif complet

---

Framework de décision : quel outil pour quel contexte

Utilisez Google Sheets quand :

• Vous construisez un prototype en moins d'une journée pour valider un concept
• Le volume de données ne dépassera jamais 500 lignes
• Les données doivent être visibles et modifiables directement par un non-tech (client, comptable, manager)
• L'usage est ponctuel et non critique — un rapport hebdomadaire, un export manuel
• Vous avez zéro budget et zéro besoin de garanties

Utilisez Airtable quand :

• Votre équipe non-technique gère activement les données (gestion de projet, CRM léger, base de contenu)
• Vous avez besoin d'interfaces de formulaire intégrées pour la saisie
• Le volume restera sous les 50 000 lignes
• Le prix d'Airtable est justifié par l'autonomie que vous donnez à votre équipe
• Vous n'avez pas besoin de RLS ni de garanties ACID

Utilisez Supabase quand :

• Plusieurs workflows écrivent simultanément dans la même source de données
• Le volume attendu dépasse 5 000 lignes dans les 6 prochains mois
• Les données sont sensibles (données personnelles, financières, médicales)
• Vous avez besoin d'isoler les données par client (multi-tenant)
• La donnée doit être exacte et jamais perdue — logs, commandes, transactions
• Vous construisez quelque chose qui doit scaler sans refonte

Règle empirique : Si votre workflow écrit dans Google Sheets plus de 100 fois par jour, commencez à planifier la migration vers Supabase. Vous en aurez besoin dans moins de 6 mois.

---

Migrer de Google Sheets vers Supabase : les 4 étapes

La migration fait peur, mais elle est moins complexe qu'il n'y paraît.

Étape 1 — Analyser et nettoyer les données existantes

Avant de migrer, exportez votre Sheet en CSV et auditez vos données : cherchez les doublons, les valeurs manquantes, les formats de dates incohérents. C'est le moment de définir votre schéma cible en SQL.

Étape 2 — Créer le schéma Supabase

Dans l'éditeur SQL de Supabase, créez vos tables avec des types stricts :

CREATE TABLE leads (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  email TEXT UNIQUE NOT NULL,
  first_name TEXT,
  score INTEGER DEFAULT 0,
  source TEXT,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

Étape 3 — Importer les données existantes

Supabase permet d'importer un CSV directement depuis l'interface — en un clic. Supabase valide les types au passage et vous alerte sur les lignes invalides.

Étape 4 — Mettre à jour les workflows n8n

Remplacez les nœuds "Google Sheets" par des nœuds "HTTP Request" vers l'API Supabase, ou utilisez le nœud Supabase natif disponible depuis n8n 1.0. La logique de vos workflows ne change pas — seule la destination des données change.

Temps de migration estimé : 2 à 4 heures pour un projet de taille moyenne (1 à 3 tables, moins de 10 000 lignes). Une demi-journée pour un projet complexe.

---

Conclusion

Google Sheets est un excellent outil — pour ce pour quoi il a été conçu : les tableurs collaboratifs. Ce n'est pas une base de données, et l'utiliser comme telle dans des workflows d'automatisation de production est une bombe à retardement.

Le bon outil ne se choisit pas au moment où tout casse. Il se choisit au moment où vous concevez le workflow.

Supabase ne vous demande pas d'être développeur. Il vous demande d'apprendre 10 minutes de SQL et de changer vos habitudes. En échange, vous obtenez une infrastructure qui ne vous trahira pas à 50 000 lignes, qui ne corrompt pas vos données quand deux workflows tournent en même temps, et qui protège les données de vos clients par défaut.

Si vous avez des workflows en production qui écrivent dans Google Sheets et que vous avez parfois des données manquantes ou des comportements étranges — ce n'est pas un bug de n8n. C'est l'architecture.

---

Chez BOVO Digital, nous migrons des architectures Google Sheets → Supabase et construisons des systèmes d'automatisation solides depuis le premier jour. Si vous voulez qu'on audite votre stack d'automatisation actuelle, contactez-nous.