Automatiser la gestion des commandes e-commerce avec n8n (Shopify, WooCommerce)

Une boutique Shopify ou WooCommerce qui tourne sans automatisation repose sur des humains qui vérifient le stock, copient la commande dans un ERP, envoient l'email de confirmation et suivent la livraison à la main. Ça tient tant que le volume reste faible. Dès que les commandes arrivent en rafale — un lancement produit, une période de soldes — les oublis et les doublons apparaissent. n8n permet de construire un pipeline qui reçoit la commande, vérifie le stock, la pousse dans l'outil de facturation, prévient le client et suit la livraison, sans intervention manuelle sur le cas nominal.

Ce constat déborde largement le cas Shopify ou WooCommerce : dès 1990, Davenport et Short posaient dans une étude fondatrice de la Sloan Management Review les bases de ce qu'on appellera plus tard le BPM (business process management), en montrant que le vrai gain de l'informatisation d'un processus ne vient pas de l'automatisation d'une tâche isolée, mais de la refonte du processus entier autour des capacités du système d'information (Davenport & Short, 1990, Sloan Management Review). C'est exactement ce que fait un pipeline n8n bien conçu : il ne se contente pas d'automatiser l'envoi de l'email de confirmation, il repense la chaîne complète — réception, vérification, écriture, notification, suivi — comme un seul processus cohérent plutôt que comme cinq tâches isolées reliées à la main.

Le déclencheur : webhook Shopify ou WooCommerce

Shopify propose des webhooks natifs configurables dans l'admin (Settings > Notifications > Webhooks) ou via l'API Admin, sur l'événement orders/create. Pointez-le vers un node Webhook n8n en mode POST ; WooCommerce fonctionne de façon similaire via ses propres webhooks (Order created), configurables dans WooCommerce > Settings > Advanced > Webhooks.

Dès réception, la charge utile contient l'essentiel : articles commandés, quantités, adresse de livraison, montant, email client. Un node Set en début de workflow normalise ces champs sous une forme commune (order_id, items, customer_email, total) — utile si vous gérez plusieurs boutiques ou plateformes en parallèle et voulez que la suite du workflow reste identique quelle que soit la source.

{{ $json.body.id }}
{{ $json.body.line_items[0].sku }}
{{ $json.body.customer.email }}

Idempotence : ne jamais traiter deux fois la même commande

Les webhooks Shopify et WooCommerce ne garantissent pas une livraison unique : un timeout réseau ou une erreur 5xx côté n8n déclenche un retry automatique de la plateforme, avec le même order_id. Sans protection, cela peut créer une commande en double dans l'ERP ou envoyer deux emails de confirmation au client.

La solution : une table (Supabase ou Postgres) avec une contrainte UNIQUE sur order_id, consultée en tout début de workflow.

1. Node HTTP Request (ou Supabase) — recherche de l'order_id dans la table processed_orders.
2. Node IF — si trouvé, on répond immédiatement au webhook (200 OK) et le workflow s'arrête là, sans rejouer la logique métier.
3. Sinon, on insère l'order_id en tout début de traitement (avant même la fin du workflow), pour que même un retry pendant l'exécution ne rejoue pas la même commande.

Ce principe rejoint celui détaillé dans notre guide sur la sécurisation d'un webhook n8n : valider la source et neutraliser les rejeux sont les deux réflexes de base avant de laisser un webhook piloter des actions métier.

Vérification de stock avant confirmation

Avant de confirmer quoi que ce soit au client, interrogez la source de vérité du stock — l'inventaire Shopify lui-même, ou un ERP externe si le stock y est centralisé.

• Node HTTP Request vers l'API d'inventaire (Shopify inventory_levels ou l'endpoint de l'ERP).
• Node Code pour comparer, article par article, la quantité disponible à la quantité commandée :

const items = $input.first().json.items;
const stock = $('Get Inventory').first().json.levels;

const shortages = items.filter((item) => {
  const available = stock.find((s) => s.sku === item.sku)?.available ?? 0;
  return available < item.quantity;
});

return [{ json: { hasShortage: shortages.length > 0, shortages } }];

• Node IF sur hasShortage : la branche « vrai » part vers la gestion de rupture (notification interne + email client + mise à jour du statut de commande), la branche « faux » continue vers la création dans l'ERP.

Création automatique dans l'ERP ou l'outil de facturation

Une fois le stock validé, un node HTTP Request pousse la commande vers l'ERP ou l'outil de facturation (QuickBooks, Sage, un ERP interne, ou même une table Supabase qui sert de source pour la compta). Pour les intégrations qui exposent une API REST classique, le node HTTP Request avec authentification par header ou OAuth2 couvre la majorité des cas ; certains outils disposent d'un node n8n dédié qui simplifie l'authentification.

Points d'attention :

• Mappez explicitement les champs (SKU, quantité, prix unitaire, TVA) plutôt que de transmettre le payload brut de Shopify — les deux systèmes n'utilisent presque jamais la même structure.
• Stockez l'identifiant retourné par l'ERP (erp_order_id) dans votre table de suivi, pour pouvoir faire le lien dans les deux sens ensuite (mise à jour de statut, remboursement).

Notification client : email de confirmation personnalisé

Un node Set prépare les variables (nom, articles, montant, délai estimé), puis soit un template statique avec expressions n8n, soit un node AI Agent ou LLM Chain génère un texte de confirmation plus naturel à partir de ces données structurées.

Le point important : ne laissez pas le modèle inventer les données chiffrées. Injectez montant, articles et numéro de commande via expressions ({{ $json.total }}, {{ $json.order_id }}) dans le template final, et réservez la génération IA au ton et à la formulation d'accompagnement — un message plus chaleureux qu'un email générique, adapté par exemple au type de produit acheté. Le node Email Send (ou l'intégration de votre fournisseur transactionnel) referme la boucle.

Synchronisation des statuts de livraison

Une fois la commande expédiée, le transporteur (Colissimo, Chronopost, ou une plateforme d'agrégation comme AfterShip) envoie généralement ses propres webhooks de suivi. Le pattern est identique à celui du webhook de commande :

1. Webhook n8n dédié pour les événements du transporteur (shipped, in_transit, delivered, exception).
2. Node Switch sur le type d'événement, pour router vers la bonne action : mise à jour du statut dans l'ERP, email de suivi au client, ou alerte interne en cas d'incident de livraison.
3. Mise à jour de la table de suivi pour garder une trace centralisée de l'état réel de chaque commande.

Gérer les remboursements et annulations

Une annulation peut venir de deux côtés : le client (via un formulaire ou un email) ou la boutique elle-même (rupture détectée après coup, fraude suspectée). Dans les deux cas, le workflow doit :

• Vérifier l'état actuel de la commande (déjà expédiée ou non) avant d'autoriser un remboursement automatique — un node IF sur le statut suffit à distinguer les cas simples des cas à traiter manuellement.
• Appeler l'API de remboursement Shopify/WooCommerce ou de votre prestataire de paiement.
• Mettre à jour l'ERP et notifier le client, en réutilisant les mêmes briques (Set + email) que pour la confirmation initiale.

Pour les cas ambigus (commande partiellement expédiée, litige), mieux vaut router vers une approbation humaine plutôt qu'automatiser à 100 % — voir notre article sur l'approbation humaine avec Wait et Slack pour le pattern exact.

Gérer les rate limits de l'API Shopify (429)

L'API Shopify plafonne le débit de requêtes (limite par leaky bucket, généralement 2 requêtes par seconde en plan standard sur l'API REST). Sur un pic de commandes ou une synchronisation en masse, les 429 apparaissent vite. Le réflexe : un node Loop Over Items pour traiter les commandes par lots plutôt qu'en parallèle, associé à un node Wait entre chaque lot. Pour le détail des mécanismes (Retry On Fail, lecture du header retry-after, dimensionnement des lots), notre guide sur les rate limits des API IA dans n8n s'applique presque à l'identique à l'API Shopify — seul le fournisseur change.

En résumé

Un pipeline de commandes e-commerce robuste dans n8n tient sur cinq briques : un webhook fiable et idempotent en entrée, une vérification de stock avant toute confirmation, une création structurée dans l'ERP, une notification client soignée, et une synchronisation des statuts de livraison qui boucle l'information. Ajoutez une gestion explicite des ruptures et des remboursements plutôt que de les traiter comme des exceptions non prévues, et le workflow tient la charge d'un lancement produit sans supervision humaine constante. Si vous partez de zéro sur la partie IA (email généré, classification de litiges), notre guide pour débuter avec les nodes IA couvre les bases avant d'aller plus loin.