Relier n8n à Google Sheets devient risqué quand on traite la feuille comme une base transactionnelle. Le nœud sait créer, lire, mettre à jour et ajouter des données, mais la feuille reste un tableur partagé. Le bon objectif n’est donc pas “zéro doublon garanti dans tous les cas”, c’est : une clé métier stable, un mapping explicite, une politique de mise à jour claire, une rétention minimale et un contrôle des cas concurrents.
Repère documentaire : documentation officielle du fonctionnement présenté.
Ce guide documentaire décrit une procédure à vérifier sur votre installation ; nous ne présentons pas ces manipulations comme un test exécuté.
Le principe : un identifiant métier avant la ligne
Avant le nœud Google Sheets, construisez une colonne id_commande ou id_evenement. Idéalement, elle vient du système source : ID Stripe, numéro de commande WooCommerce, ID formulaire, ID CRM. Exemple pédagogique :
{
"id_commande": "CMD-2026-004218",
"email_client": "client@example.com",
"montant_ttc": 129.90,
"statut": "payee",
"source": "webhook_checkout"
}Dans la feuille, gardez une colonne nommée exactement id_commande. Dans n8n, mappez le champ JSON {{$json.id_commande}} vers cette colonne. La décision devient simple : si CMD-2026-004218 existe déjà, on met à jour la ligne ; si cet ID n’existe pas, on ajoute une ligne. Une relance du même événement avec le même ID doit donc faire un update ; une nouvelle commande avec un nouvel ID doit faire un append.
Configurer sans fuite de données
Ne journalisez pas tous les payloads bruts “au cas où”. Un webhook de commande peut contenir email, téléphone, adresse, note client ou identifiants internes. Dans la feuille, ne gardez que les colonnes utiles à l’action : ID, date normalisée, statut, montant, source, lien interne si besoin. Si vous devez conserver un extrait technique, masquez ou tronquez : email partiellement caché, téléphone supprimé, JSON réduit aux champs nécessaires. Définissez aussi une durée de rétention : par exemple, feuille opérationnelle sur 90 jours puis archivage ou purge.
Évitez la fausse bonne idée du hash email + date comme clé universelle. Deux commandes du même client le même jour peuvent entrer en collision selon la granularité. À l’inverse, une faute dans l’email crée une nouvelle clé. Un hash peut dépanner pour un formulaire simple, mais il doit être documenté comme approximation, pas comme identité infaillible.
Workflow recommandé
- Trigger : Webhook, Cron ou source déjà contrôlée.
- Set / Code : normaliser les noms de champs, convertir le montant, forcer la date ISO, construire ou lire l’ID stable.
- Google Sheets — Append or Update Row : sélectionner Sheet Within Document, puis Append or Update Row, choisir le document et l’onglet, et utiliser
id_commandecomme colonne de correspondance. - Contrôle : vérifier les valeurs associées à chaque colonne avant l’exécution. Si vous utilisez l’opération “append or update”, vérifiez précisément la colonne de matching et testez les deux branches.
- Réponse : retourner l’ID et l’action réalisée, pas tout le payload.
Exemple de décision
| Événement reçu | ID dans Sheets ? | Action | Résultat attendu |
|---|---|---|---|
| CMD-004218 statut payée | non | append | nouvelle ligne |
| CMD-004218 statut expédiée | oui | update | même ligne modifiée |
| CMD-004219 statut payée | non | append | autre ligne |
La limite à connaître : concurrence
Si deux exécutions arrivent exactement en parallèle, elles peuvent toutes deux lire “ligne absente” avant que l’une écrive. Google Sheets n’est pas un moteur SQL avec contrainte unique. Pour un besoin critique, mettez la contrainte d’unicité dans le système amont, une base de données ou une file qui sérialise les événements. Pour un reporting léger, ajoutez un contrôle périodique : grouper par id_commande, détecter les IDs répétés et corriger manuellement ou automatiquement.
Checklist de validation
- Envoyer deux fois le même payload : la deuxième passe doit mettre à jour la ligne existante.
- Envoyer un ID différent : une nouvelle ligne doit apparaître.
- Tester un email vide, un montant texte, une date invalide.
- Vérifier que les logs n’exposent pas les données personnelles complètes.
- Documenter qui peut ouvrir la feuille, combien de temps elle est conservée et quoi faire en cas de doublon.
Pour un usage opérationnel, Google Sheets est excellent comme surface de suivi. Dès que l’unicité, les droits, l’audit ou la concurrence deviennent critiques, gardez Sheets comme tableau de bord et placez la vérité dans un système conçu pour ça.
Mapping conseillé dans n8n
Dans un nœud Set, renommez les champs avant Sheets. Exemple : id_commande reçoit l’ID source, valeur reçoit le montant numérique, email_masque reçoit une version tronquée, date_reception reçoit l’horodatage ISO. Ne mappez pas directement les noms internes du webhook si ces noms peuvent changer. Cette étape sert de contrat entre la source et la feuille.
Ajoutez une colonne derniere_mise_a_jour. Quand une relance du même ID arrive, cette colonne doit changer si la mise à jour a bien eu lieu. Ajoutez aussi origine_evenement pour distinguer création, relance, paiement, remboursement ou statut expédition.
Quand Sheets reste acceptable
Sheets convient pour un back-office léger : suivi de leads, commandes à traiter, état d’une file éditoriale, contrôle humain. Il devient fragile si plusieurs automations écrivent en même temps, si la feuille est modifiée manuellement sans règle, si les données sont sensibles ou si le volume devient important. Dans ces cas, faites de Sheets une vue ou un export, pas la source de vérité.
Pour les bases : définition d’une API REST.
