Automatiser Shopify : quand Flow suffit, quand passer à n8n

Une boutique Shopify a accès, sans supplément, à un outil d'automatisation : Shopify Flow, une application gratuite incluse dans les forfaits Basic, Grow, Advanced et Plus. Beaucoup ne s'en servent pas, et font tourner à côté un Zapier ou un n8n pour des tâches que Flow aurait faites sans rien coûter.

L'inverse existe aussi : des scénarios montés dans Flow qui contournent ses limites à force d'étiquettes et de conditions, alors qu'un webhook aurait réglé la question en une étape.

Le critère qui tranche entre les deux n'est pas la complexité. C'est le déclencheur.

Avant d'automatiser : ce qui est déjà dans Shopify

Une partie des demandes d'automatisation que je reçois se règle sans automatisation du tout.

Répartir une commande entre plusieurs entrepôts. C'est le rôle des règles de routage des commandes, dans les réglages d'expédition. Shopify choisit l'emplacement qui expédie, ou découpe la commande entre plusieurs, selon l'ordre de priorité que vous définissez. Aucun scénario à maintenir.

Relancer un panier abandonné. L'e-mail de relance est natif. Il ne devient un sujet d'automatisation que lorsqu'on veut aller au-delà : une séquence en plusieurs temps, un canal différent, une condition sur le contenu du panier.

La règle : c'est le déclencheur qui choisit l'outil

Flow propose près d'une centaine de déclencheurs. Une commande créée, payée, expédiée, annulée ; un remboursement ; un stock qui change ou tombe à zéro ; une étiquette ajoutée à un client ; un panier abandonné ; et un déclencheur planifié, qui lance un scénario à heure fixe.

Ce qui manque est aussi important que ce qui existe :

Il ne voit pas non plus ce qui se passe hors de Shopify, sauf si une application installée le lui transmet : certaines ajoutent leurs propres déclencheurs à Flow, beaucoup ne le font pas. Un stock mis à jour dans l'ERP, un fichier fournisseur déposé : sans application qui fasse le pont, rien de tout ça n'est un déclencheur Flow.

D'où la règle que j'applique :

L'argument économique compte. Sur n8n Cloud, chaque exécution est décomptée de votre forfait : consommer ce quota pour étiqueter des commandes, quand Flow le fait sans rien facturer, c'est payer deux fois. Le détail des modèles de facturation.

Un détail à connaître avant de construire : l'action qui permet à Flow d'appeler un service extérieur, l'envoi de requête HTTP, n'est disponible qu'à partir du forfait Grow. Sur Basic, Flow reste dans Shopify.

Ce que Flow fait très bien

Étiqueter les commandes pour la préparation. Selon le montant, le pays de livraison ou le mode d'expédition choisi. L'équipe filtre la liste des commandes sur l'étiquette au lieu de les ouvrir une à une. C'est souvent le premier scénario utile sur une boutique qui expédie tous les jours.

Prévenir d'un stock bas. Le déclencheur Product variant inventory quantity changed, une condition sur le seuil, un message à la personne qui passe les commandes fournisseur. Trois blocs, et plus personne ne découvre la rupture en même temps que le client.

Retirer un produit en rupture, et le remettre au réassort. Deux déclencheurs dédiés, Product variant out of stock et Product variant back in stock. Le catalogue affiché reste fidèle au stock réel sans intervention.

Relancer les commandes qui n'avancent pas. Le déclencheur planifié, Scheduled time, chaque matin, qui cherche les commandes payées et toujours pas expédiées au-delà de quelques jours, et prévient la logistique. C'est le genre de retard qu'on ne voit jamais en regardant la liste, parce qu'il est noyé dans les commandes du jour.

Aller au-delà de l'e-mail de panier abandonné. Le déclencheur Customer abandons checkout permet d'ajouter une condition ou une étiquette avant la relance, par exemple pour traiter différemment un panier élevé.

Là où il faut passer à n8n

Réagir à une modification

Une commande modifiée après coup. Le client appelle, l'adresse change, un article est ajouté. Si la commande est déjà transmise à la préparation, il faut prévenir. Le webhook orders/updated de Shopify le signale — sans dire ce qui a changé : il envoie la commande telle qu'elle est, pas son état précédent. n8n garde donc la trace de la version transmise, compare, et n'alerte que si la différence compte pour la logistique.

Un produit mis à jour. Un prix, une description ou un métachamp qui change dans Shopify et doit suivre ailleurs : un autre canal de vente, un outil métier, un catalogue partagé. Même principe, avec le webhook products/update.

Sur ces deux sujets, le passage aux webhooks plutôt qu'à l'interrogation régulière de l'API change le coût et la réactivité : le détail est ici.

Écrire dans les autres outils

Le client dans le CRM à chaque commande. Créer ou mettre à jour la fiche dans HubSpot ou Pipedrive, avec l'historique d'achat. HubSpot a une application native qui couvre le cas standard — ce qu'elle synchronise vraiment ; Pipedrive n'en a pas, et c'est là qu'il faut choisir sa méthode.

Les annulations et les remboursements. Flow les voit, mais la destination est ailleurs : le CRM qui affiche encore une vente, la comptabilité qui a enregistré un chiffre d'affaires qui n'existe plus. C'est le scénario que presque toutes les intégrations oublient, et celui qui produit les écarts qu'on découvre à la clôture.

Les factures vers la comptabilité. Pousser les commandes et les factures dans Pennylane ou l'outil de l'expert-comptable, avec la bonne correspondance de TVA et de comptes. C'est un scénario où la correspondance des champs est tout le travail, et où l'on veut une trace de chaque envoi.

Les segments d'e-mailing. Alimenter des listes Brevo ou Klaviyo à partir des étiquettes et de l'historique des clients, pour des campagnes qui ne parlent pas de la même façon à un premier acheteur et à un client récurrent.

Lire ce qui vient de l'extérieur

Le stock tenu ailleurs. Un ERP, un entrepôt, un fichier fournisseur : quand la vérité du stock n'est pas dans Shopify, c'est une synchronisation planifiée ou déclenchée par la source, pas un scénario Flow.

Le catalogue d'un fournisseur. Import et mise à jour en masse depuis un fichier ou une API fournisseur. À partir de quelques centaines de produits, les limites de l'API Shopify décident du rythme, et l'import se conçoit pour les respecter.

Le transporteur et le suivi. Transmettre la commande au logisticien, récupérer le numéro de suivi, le reporter dans Shopify. Et, dans le même esprit, demander un avis au client une fois le colis livré plutôt qu'au moment de la commande : l'événement « livré » vient du transporteur. Flow ne le reçoit que si un logisticien tiers le fait remonter dans Shopify (déclencheur Fulfillment event created) ; sinon, c'est un scénario n8n.

Piloter et surveiller

Le résumé des ventes. Chaque lundi, un message sur Slack ou par e-mail avec ce qui compte : chiffre d'affaires, nombre de commandes, panier moyen, produits en rupture. Personne n'ouvre le tableau de bord tous les jours ; tout le monde lit un message de cinq lignes.

La surveillance des intégrations elles-mêmes. Le point que je pose dès le début de chaque mission : une alerte quand une synchronisation échoue. Une intégration qui tombe en panne ne prévient personne, les données cessent simplement de circuler, et on le découvre des semaines plus tard.

Le récapitulatif

Quand ne pas automatiser

Avant de construire quoi que ce soit, j'écris le process : ce qui le déclenche, les données dont il a besoin, ce qui se passe en cas d'erreur, et qui est prévenu. Quand ces réponses n'existent pas encore, on les pose ensemble, et on les fixe avant de toucher à un outil. C'est souvent la partie la plus utile de la mission.

Le choix de l'outil, lui, revient toujours au marchand. Mon rôle est de poser l'arbitrage : ce que Flow couvre gratuitement, ce qui justifie n8n, et ce qui demande un développement.

Si vous voulez qu'on regarde votre boutique, c'est le cœur de mes missions Shopify.