Relancer les paniers abandonnés avec n8n et l’IA (Shopify, WooCommerce)

Un client ajoute un article au panier, arrive jusqu’à la page de paiement, puis disparaît. Sans intervention, ce panier reste une donnée morte : personne ne le relance, la vente n’a jamais lieu, et rien ne distingue ce client d’un simple visiteur curieux. C’est pourtant l’un des signaux commerciaux les plus riches d’une boutique en ligne — une intention d’achat déjà exprimée, à un doigt de la conversion. Une étude de référence de Kukar-Kinney et Close, publiée en 2010 dans le Journal of the Academy of Marketing Science, a identifié les déterminants concrets de cet abandon (recherche du meilleur prix, comparaison entre boutiques, simple hésitation avant achat) et montré qu’il s’agit rarement d’un rejet du produit lui-même (étude sur Google Scholar) — une raison de plus pour relancer plutôt que d’abandonner la vente à son tour. n8n permet de construire ce filet de rattrapage sans dépendre d’un service SaaS tiers facturé au volume.

Pourquoi ce n’est pas la même chose qu’une confirmation de commande

Notre guide sur l’automatisation des commandes e-commerce couvre ce qui se passe après qu’une commande a été validée : vérification de stock, écriture dans l’ERP, notification client. La relance de panier abandonné se situe en amont, sur une commande qui n’a jamais été finalisée. La logique de déclenchement diffère donc complètement : au lieu de réagir à un événement orders/create, il faut détecter une absence d’événement — un panier qui existe mais qui n’a jamais abouti dans le délai attendu.

Étape 1 — Détecter le panier abandonné

Sur Shopify : un vrai webhook dédié

Shopify expose une ressource Abandoned Checkouts dans son API Admin, alimentée par les événements checkouts/create et checkouts/update : dès qu’un client renseigne son email en page de paiement sans finaliser, le checkout apparaît dans cette liste avec le contenu du panier, l’adresse, et surtout un champ abandoned_checkout_url qui pointe directement vers la reprise du tunnel d’achat. Configurez un webhook sur checkouts/update (Settings > Notifications > Webhooks, ou via l’API Admin) pointé vers un node Webhook n8n : c’est l’équivalent exact du orders/create utilisé pour les commandes confirmées, mais côté paiement non abouti.

Sur WooCommerce : un polling en l’absence d’événement natif

WooCommerce ne propose pas d’événement webhook natif sur l’abandon de panier — le client peut fermer l’onglet sans jamais toucher le serveur. La solution robuste sans plugin payant consiste à interroger périodiquement l’API REST WooCommerce (GET /wp-json/wc/v3/orders?status=pending) via un Schedule Trigger toutes les 15 à 30 minutes, et à filtrer les commandes au statut pending ou on-hold dont la date de création dépasse le délai de relance choisi. Une commande WooCommerce en statut « pending » correspond à un client qui a rempli le formulaire de commande sans finaliser le paiement — un proxy fiable de l’abandon, même s’il ne capture pas les paniers qui n’ont jamais atteint cette étape.

Étape 2 — Journaliser avant d’attendre

Dès qu’un panier ou une commande en attente est détecté, insérez-le dans une table Supabase (paniers_abandonnes : checkout_id, email, articles, montant, statut_relance, detecte_le) avant même de programmer la première relance. Cette étape sert deux objectifs : garder une trace exploitable pour un reporting mensuel, et surtout éviter les doublons si le polling WooCommerce redétecte la même commande « pending » au cycle suivant — le même principe d’idempotence que celui détaillé dans notre guide sur les webhooks n8n et les doublons, appliqué ici à un identifiant de panier plutôt qu’à un identifiant d’événement.

Étape 3 — Attendre, puis revérifier avant d’envoyer

C’est l’étape où la plupart des implémentations artisanales se trompent : programmer un envoi différé sans revérifier l’état au moment de l’envoi. Un client qui finalise son paiement 20 minutes après l’abandon initial ne doit jamais recevoir l’email de relance programmé pour la 30e minute — rien n’agace davantage un client que de recevoir une relance pour un achat déjà effectué.

L’enchaînement correct dans n8n :

1. Wait — délai jusqu’à la première relance (30 à 60 minutes selon la nature du produit).
2. HTTP Request — revérification du statut réel du checkout (Shopify Abandoned Checkouts API) ou de la commande (GET /orders/{id} WooCommerce).
3. IF — si le statut est passé à « payé » ou « complété », le workflow s’arrête ici sans envoyer d’email ; sinon, il continue vers la génération du message.

Ce même triplet Wait → revérification → IF se répète à chaque étape d’une séquence à plusieurs relances (une heure, 24 heures, 48-72 heures), chaque itération partant du principe que la conversion a pu avoir lieu entretemps.

Étape 4 — Générer une relance personnalisée par IA plutôt qu’un template figé

Un email générique (« Vous avez oublié quelque chose ! ») convertit, mais moins bien qu’un message qui reprend le contenu réel du panier et adapte son ton à la position dans la séquence. Un Basic LLM Chain connecté à Claude ou GPT reçoit les articles, le montant total et le numéro de relance (1re, 2e ou 3e), et génère un texte court adapté :

• Relance 1 (30-60 min) : simple rappel factuel, ton neutre, lien direct vers le panier.
• Relance 2 (24h) : répond à une objection courante identifiée pour votre boutique (frais de livraison, politique de retour, sécurité du paiement) plutôt qu’une simple redite du premier message.
• Relance 3 (48-72h) : ton plus direct, dernière chance avant que le panier ne soit considéré comme définitivement perdu dans votre reporting.

Comme pour les emails de confirmation de commande, ne laissez jamais le modèle inventer le prix, la quantité ou la référence produit : ces données doivent être injectées via des expressions n8n ({{ $json.montant }}, {{ $json.articles }}) dans le prompt et dans le template final, l’IA se limitant au ton et à la formulation. Le même garde-fait est décrit en détail dans notre guide sur l'automatisation des commandes e-commerce.

Étape 5 — Envoyer, journaliser, arrêter la séquence à la conversion

Un node Gmail ou Email Send referme l’étape, suivi d’une mise à jour de la ligne Supabase (statut_relance: "envoyee_1", horodatage). Si une relance ultérieure du panier détecte une conversion (via le node IF de l’étape 3), la table doit être mise à jour en conséquence (statut_relance: "converti") pour que les relances suivantes de la séquence — encore programmées via des nodes Wait en parallèle — s’arrêtent net dès leur propre vérification, sans jamais atteindre le node d’envoi.

Pièges fréquents

• Se fier au statut détecté à l’origine : sans revérification avant chaque envoi, la séquence finit par relancer des clients déjà convertis — l’erreur la plus visible et la plus coûteuse en image de marque.
• Confondre panier WooCommerce et commande « pending » : le polling sur les commandes en attente ne capture que les clients arrivés jusqu’au formulaire de commande, pas ceux qui ont quitté plus tôt dans le tunnel ; c’est une limite connue de l’approche sans plugin, à assumer plutôt qu’à ignorer.
• Trop de relances, trop vite : au-delà de trois messages sur 72 heures, le gain de conversion marginal ne compense plus le risque de désabonnement ou de plainte pour spam.
• Oublier le consentement marketing : contrairement à un email de confirmation de commande (transactionnel), une relance de panier abandonné relève généralement du marketing — vérifiez que l’email du client a été collecté avec une base légale adaptée avant d’automatiser l’envoi.

Pour aller plus loin

Cette architecture — détection par webhook ou polling, anti-doublons, séquence de relance avec revérification systématique, génération de message par IA — réutilise directement les briques déjà décrites dans notre guide sur l'automatisation des commandes e-commerce et dans celui sur les relances de paiement échoué avec Stripe, qui suit le même principe de détection d’un état incomplet suivi d’une relance tracée. Pour la rédaction des emails eux-mêmes, le Pack Inbox IA (79 €) embarque déjà les mêmes patterns de génération de texte contraint par des données structurées, directement transposables à une séquence de relance panier.