Automatiser WooCommerce avec n8n permet de connecter votre boutique WordPress à vos outils sans écrire de plugin sur mesure ni payer un abonnement par intégration. Voici 5 workflows n8n concrets, branchés sur l'API REST et les webhooks, avec leur déclencheur, leur logique et le temps qu'ils font gagner.
Je suis Tommy Bordas, développeur full-stack à Nantes (10+ ans, freelance via Sumotori). J'installe ce type d'automatisation chez des e-commerçants WooCommerce depuis plusieurs années, et le constat est toujours le même : la valeur n'est pas dans un plugin de plus, mais dans l'orchestration. Voyons comment poser ça proprement.
Pourquoi n8n plutôt qu'empiler des plugins SaaS
WooCommerce expose deux portes d'entrée souvent sous-exploitées : une API REST complète (/wp-json/wc/v3/...) pour lire et écrire commandes, produits, stock, clients ; et des webhooks natifs qui poussent un événement (order.created, order.updated, product.updated...) vers une URL dès qu'il se produit. n8n, outil d'automatisation open source que vous pouvez auto-héberger, se branche directement sur les deux : il reçoit les webhooks et appelle l'API en retour.
Le réflexe habituel, c'est d'installer un plugin par besoin : un pour les paniers abandonnés, un pour la synchro stock, un pour les avis... Chacun ajoute du code dans WordPress, des hooks qui tournent à chaque requête, et une surface d'attaque supplémentaire. n8n déporte toute cette logique hors de WordPress.
| Approche | Coût | Maintenance | Flexibilité | Impact perf WordPress |
|---|---|---|---|---|
| Plugin SaaS par intégration | Abonnement × N | Externe, opaque | Limitée au périmètre du plugin | Charge à chaque requête |
| Plugin sur mesure | Dév + maintenance | À votre charge | Totale | Charge à chaque requête |
| n8n auto-hébergé | Hébergement seul (~5 €/mois) | Centralisée, un seul endroit | Totale | Quasi nul (logique externalisée) |
À retenir : chaque plugin tiers ajoute du poids et une faille potentielle. n8n centralise la logique d'intégration hors du serveur WordPress, ce qui garde le site léger et la maintenance lisible : un seul endroit à auditer au lieu de dix plugins.
Comment WooCommerce se branche à n8n
Deux mécanismes, deux usages :
- Webhook (push, temps réel) : WooCommerce appelle une URL n8n dès qu'un événement survient. Idéal pour réagir vite : commande payée, statut changé. À créer dans WooCommerce → Réglages → Avancé → Webhooks, ou par code.
- API REST (pull, à la demande) : n8n interroge WooCommerce quand il veut, via une clé API (Consumer Key/Secret générée dans WooCommerce → Réglages → Avancé → REST API). Idéal pour les traitements planifiés : lister les paniers, mettre à jour le stock en masse.
Pour enregistrer un webhook par code dans le functions.php (ou un petit plugin maison) :
add_action( 'woocommerce_init', function () {
if ( ! function_exists( 'wc_get_webhook' ) ) {
return;
}
// Créé une fois, idempotent : on ne duplique pas si l'URL existe déjà.
$existing = wc_get_webhooks( [ 'search' => 'n8n-order-paid' ] );
if ( ! empty( $existing ) ) {
return;
}
$webhook = new WC_Webhook();
$webhook->set_name( 'n8n-order-paid' );
$webhook->set_topic( 'order.updated' );
$webhook->set_delivery_url( 'https://n8n.exemple.fr/webhook/wc-order' );
$webhook->set_secret( getenv( 'N8N_WC_SECRET' ) ); // sert à signer le payload
$webhook->set_status( 'active' );
$webhook->save();
} );
Le secret est crucial : WooCommerce s'en sert pour signer chaque envoi (en-tête X-WC-Webhook-Signature). On vérifie cette signature côté n8n (j'y reviens dans les bonnes pratiques).
Workflow n°1 : relance de panier abandonné
Le grand classique du ROI. Un panier abandonné, c'est un client à un clic de l'achat. Un cron interroge les paniers inactifs depuis plus d'une heure et déclenche un e-mail de relance personnalisé avec le contenu du panier.
Déclencheur : nœud Schedule toutes les 30 minutes. Gain : entre 5 et 15 % du chiffre d'affaires « perdu » récupéré, sans intervention manuelle.
{
"trigger": "Schedule (toutes les 30 min)",
"steps": [
"HTTP Request: GET /wp-json/wc/v3/orders?status=pending&after={{il y a 1h}}",
"Filter: e-mail présent ET meta 'relance_envoyee' absent",
"Send Email: relance avec récap du panier + lien de reprise",
"HTTP Request: PUT /orders/{{id}} → meta_data 'relance_envoyee' = now"
]
}
À retenir : ne relancez qu'une seule fois, et tracez l'envoi par une meta côté commande. Sans ce garde-fou, un client peut recevoir la même relance toutes les 30 minutes, l'effet inverse de celui recherché.
Workflow n°2 : synchro du stock fournisseur via CSV
Votre fournisseur publie un CSV de stock chaque nuit (FTP, e-mail, ou URL). n8n le récupère, le parse, le mappe sur les SKU WooCommerce et met à jour les quantités en lot. Fini la ressaisie et les ruptures fantômes.
Déclencheur : Schedule nocturne (ex. 04 h 00) ou Email Trigger quand le fournisseur envoie le fichier. Gain : suppression de la ressaisie manuelle (souvent 1 à 2 h par jour) et stock fiable au réveil.
// Node Function : mapper une ligne CSV → payload d'update WooCommerce
return items.map((item) => {
const qty = parseInt(item.json["Qté dispo"], 10) || 0;
return {
json: {
sku: String(item.json["Référence"]).trim(),
stock_quantity: qty,
stock_status: qty > 0 ? "instock" : "outofstock",
manage_stock: true,
},
};
});
WooCommerce ne permet pas d'écrire un produit par SKU directement : on résout d'abord le SKU en product_id, puis on utilise l'endpoint batch pour limiter les appels.
# Mise à jour groupée : 1 requête pour 100 produits au lieu de 100 requêtes
curl -X POST "https://boutique.fr/wp-json/wc/v3/products/batch" \
-u "$WC_KEY:$WC_SECRET" \
-H "Content-Type: application/json" \
-d '{ "update": [
{ "id": 412, "stock_quantity": 12, "stock_status": "instock" },
{ "id": 588, "stock_quantity": 0, "stock_status": "outofstock" }
] }'
Workflow n°3 : facture automatique vers la compta
À chaque commande payée, un webhook WooCommerce déclenche la création d'une facture dans votre outil comptable (Sellsy, Pennylane, Indy, QuickBooks...), l'archive et l'envoie au client.
Déclencheur : webhook order.updated filtré sur status = processing ou completed.
Gain : compta toujours à jour, zéro oubli, zéro PDF généré à la main.
WooCommerce (webhook order.updated, status=processing)
→ Vérification signature HMAC (secret partagé)
→ Idempotence : facture déjà créée pour cet order_id ? → stop si oui
→ Mapping commande → schéma de l'API compta
→ POST facture (API compta) → récupère l'URL du PDF
→ Email client avec PDF + archivage Drive/S3
→ PUT /orders/{{id}} → meta 'invoice_id' (trace + idempotence)
La meta invoice_id posée sur la commande joue un double rôle : elle relie la facture à la commande et sert de verrou d'idempotence. Si le webhook arrive deux fois (ça arrive), le second passage voit la meta et s'arrête.
Workflow n°4 : demande d'avis au bon moment
Demander un avis trop tôt ne sert à rien : le client n'a pas encore reçu le produit. Ce workflow attend que la commande passe en « terminée » (proxy de la livraison), laisse 3 jours, puis envoie une demande d'avis ciblée avec le lien produit.
Déclencheur : webhook order.updated, filtré sur status = completed.
Gain : taux de réponse nettement supérieur, donc plus d'avis qualifiés et de preuve sociale.
{
"trigger": "WooCommerce webhook: order.status = completed",
"steps": [
"Wait: 3 jours",
"HTTP Request: vérifier que le statut est toujours 'completed' (pas de retour/remboursement)",
"Send Email: demande d'avis avec lien produit + incitation légère",
"If clic: tag client 'ambassadeur_potentiel'"
]
}
À retenir : revérifiez le statut de la commande après le délai d'attente. Entre le déclenchement et l'envoi, un retour ou un remboursement a pu survenir. Demander un avis dans ce cas est contre-productif.
Workflow n°5 : alerte rupture de stock sur Slack
Quand un produit best-seller passe sous un seuil, l'équipe est prévenue immédiatement sur Slack, avant la rupture, pas après. On évite le « rupture surprise » sur le produit qui fait le chiffre.
Déclencheur : webhook product.updated (réactif), ou Schedule horaire qui balaie les produits sous seuil.
Gain : zéro rupture surprise sur les références critiques, réappro déclenché à temps.
// Node Function : ne garder que les produits sous le seuil défini
const SEUIL = 5;
return items
.filter((i) => i.json.manage_stock && i.json.stock_quantity <= SEUIL)
.map((i) => ({
json: {
sku: i.json.sku,
name: i.json.name,
stock: i.json.stock_quantity,
url: i.json.permalink,
},
}));
// → Node Slack : ":warning: Stock bas - {{name}} ({{sku}}) : {{stock}} restants"
Récapitulatif : déclencheur → gain
| Workflow | Déclencheur | Mécanisme | Gain |
|---|---|---|---|
| Panier abandonné | Cron 30 min | API REST (pull) | CA récupéré (5-15 %) |
| Synchro stock | CSV nocturne | Schedule + batch API | Fin de la ressaisie |
| Facturation | Webhook order.updated |
Webhook (push) | Compta à jour, zéro oubli |
| Demande d'avis | Webhook completed + délai |
Webhook + Wait | Plus d'avis qualifiés |
| Alerte rupture | product.updated / seuil |
Webhook ou Schedule | Zéro rupture surprise |
Bonnes pratiques pour des workflows fiables
Un workflow qui marche en démo et un workflow qui tourne en production six mois sans surveillance, ce sont deux choses différentes. Voici ce que j'applique systématiquement.
Sécuriser les webhooks avec signature et secret
Une URL de webhook publique est une porte ouverte si elle n'est pas authentifiée. WooCommerce signe chaque envoi avec le secret via l'en-tête X-WC-Webhook-Signature (HMAC-SHA256 du corps, encodé en base64). Vérifiez-la dans un nœud Function en tête de workflow, et rejetez tout ce qui ne correspond pas.
// Node Function (tout début du workflow) : vérifier la signature WooCommerce
const crypto = require("crypto");
const secret = $env.N8N_WC_SECRET;
const rawBody = $json.body; // corps brut reçu
const received = $headers["x-wc-webhook-signature"];
const expected = crypto
.createHmac("sha256", secret)
.update(JSON.stringify(rawBody), "utf8")
.digest("base64");
if (received !== expected) {
throw new Error("Signature webhook invalide - requête rejetée");
}
return items;
Rendre chaque workflow idempotent
Un webhook peut arriver deux fois (retry réseau, double clic, relivraison WooCommerce). Sans garde-fou, vous créez deux factures ou envoyez deux e-mails. La parade : poser une meta de trace sur la commande (invoice_id, relance_envoyee) et vérifier sa présence avant d'agir. La clé d'idempotence, c'est l'order_id + le type d'action.
Logger les exécutions et alerter sur les échecs
Activez l'historique d'exécution dans n8n et branchez un workflow d'erreur (Error Trigger) qui notifie sur Slack ou par e-mail dès qu'une exécution échoue. Sans ça, une intégration peut tomber en panne en silence pendant des semaines, et vous ne le découvrez que quand le client se plaint.
Versionner les workflows en Git
Les workflows n8n s'exportent en JSON. Committez-les dans un dépôt Git : vous gardez l'historique, vous pouvez relire les changements en revue, et vous restaurez en cas de fausse manip. C'est aussi ce qui permet de reconstruire l'instance à l'identique en cas de crash serveur.
Checklist avant la mise en production
- Signature HMAC vérifiée sur tous les webhooks entrants.
- Secret et clés API stockés en variables d'environnement, jamais en dur dans un nœud.
- Idempotence garantie (meta de trace ou clé unique par action).
- Workflow d'erreur global branché sur Slack/e-mail.
- Appels API en mode batch quand le volume le justifie.
- Workflows exportés en JSON et versionnés dans Git.
- Retry configuré avec back-off sur les nœuds HTTP critiques.
Pour aller plus loin
Sur la logique de connecteurs et d'intégrations côté WooCommerce (ERP, CRM, marketplaces), voir aussi : Connecteurs et intégrations WooCommerce.
Vous voulez automatiser votre boutique WooCommerce et libérer du temps sur les tâches répétitives, sans alourdir WordPress ? Parlons de vos workflows.