Comment nous avons remplacé une stack Shopify de 14 apps par 3 workflows n8n (et ce que ça a coûté)

Ce post est l'audit, l'architecture, les chiffres et la liste honnête de ce que nous referions différemment. Ce n'est pas un argumentaire pour n8n ; n8n est mauvais pour plein de travaux d'automatisation. Mais pour la catégorie spécifique "une app qui tourne une fois par heure et coûte 30 euros par mois", n8n auto-hébergé est généralement la bonne réponse, et la plupart des boutiques ont une stack pleine d'exactement ça.

Si vous n'avez pas lu notre comparatif n8n vs Zapier vs Make ou le guide n8n auto-hébergé sur AWS, ils complètent bien ce post. Nous gardons celui-ci concentré sur le cas client et le cadre de décision.

Ce qu'il y avait dans la stack

Nous avons commencé par un inventaire complet. Le marchand ne savait plus ce que faisait la plupart de ces apps.

Garder (1 app). La plateforme d'avis est restée. Collecter des avis vérifiés demande des intégrations avec les systèmes de commande qui ne sont pas triviales à répliquer, et le coût relativement à la valeur était raisonnable.

Déjà natif dans Shopify (3 apps). L'optimisation d'images, l'affichage de devise, et une des apps de tagging dupliquaient des fonctionnalités que Shopify livre nativement. Le marchand ne le savait pas. Nous les avons retirées.

Remplacer par n8n (8 apps). Sync de stock, récupération de panier abandonné, tagging de commandes, notifications back-in-stock, génération de factures PDF, tagging clients, routage form-vers-CRM, règles de livraison conditionnelles. Tous ces workflows sont planifiés ou event-driven et n'ont pas besoin de leur propre infrastructure SaaS.

Remplacer par une Shopify Function (3 apps). Logique de cross-sell, calcul de points de fidélité, comportement de wishlist. Cela devait tourner sur chaque page panier ou checkout, donc une function ou un petit bloc de thème custom était la bonne réponse, pas n8n.

Après l'audit, l'image était claire : nous avions besoin de trois workflows n8n et d'un petit ensemble de fonctionnalités natives Shopify. C'est ce que nous avons construit.

Les trois workflows

Workflow 1 : pipeline de commande

Déclenché sur chaque webhook de nouvelle commande Shopify. Tourne une fois par commande. Remplace six apps.

Ce qu'il fait, dans l'ordre :

1. Reçoit le webhook orders/create de Shopify.
2. Récupère les données complètes de la commande via l'API GraphQL Admin.
3. Regarde les attributs de la commande (valeur totale, pays, types de produit, tags client) et applique des tags à la commande dans Shopify.
4. Regarde les attributs du client (lifetime value, nombre de commandes, géographie) et applique des tags au client dans Shopify.
5. Génère une facture PDF à partir d'un template, l'attache à la commande et l'envoie par email au client (clients B2B seulement, le B2C utilise la confirmation Shopify standard).
6. Si la commande contient des produits de fournisseurs sur NetSuite, pousse la commande dans NetSuite via l'API REST.
7. Si la commande vient d'un client B2B, envoie une notification Slack à l'équipe commerciale.

Tout le workflow tourne en environ 4 secondes par commande. Le marchand voit les commandes taguées dans l'admin Shopify dans les 10 secondes après la fin du checkout.

Six apps faisaient à peu près ce travail en fragments, chacune avec son propre listener webhook, sa propre logique de retry, sa propre UI admin et sa propre facture mensuelle. La consolidation dans un workflow a tué l'overhead de fragmentation.

Workflow 2 : stock et alertes back-in-stock

Tourne toutes les 5 minutes sur un schedule. Remplace une app (sync) et remplace partiellement une autre (back-in-stock).

Ce qu'il fait :

1. Récupère les niveaux de stock actuels depuis Shopify pour les produits flaggés avec custom.netsuite_sku.
2. Récupère les niveaux NetSuite correspondants.
3. Pour chaque SKU où les niveaux divergent au-delà de la tolérance configurée, écrit le niveau NetSuite dans Shopify comme source de vérité.
4. Pour chaque SKU qui vient de passer de rupture à disponible, regarde la liste des abonnés back-in-stock (stockée dans un metaobject) et met en file un email.

La configuration précédente du marchand avait deux apps qui se battaient : une qui synchronisait Shopify vers NetSuite chaque heure, une autre qui écoutait les changements de stock pour déclencher les emails back-in-stock. Elles étaient parfois en désaccord sur le vrai niveau de stock et un correctif appliqué à un endroit ne se propageait pas à l'autre avant une heure. Le workflow unique élimine complètement cette race condition.

Workflow 3 : panier abandonné et relances comportementales

Tourne toutes les 10 minutes. Remplace deux apps.

Ce qu'il fait :

1. Interroge Shopify pour les checkouts créés dans les dernières 24 heures qui n'ont pas été finalisés.
2. Pour chaque checkout abandonné, vérifie l'historique du client : a-t-il finalisé un checkout dans les 60 derniers jours ? Est-ce son premier panier ? Qu'y a-t-il dans le panier ?
3. Route vers un des trois templates de message : premier abandon, client revenant, panier de forte valeur.
4. Planifie des envois à 1 heure, 24 heures et 72 heures après l'abandon, chaque envoi suivant conditionné au fait que le panier soit toujours abandonné.
5. Si un abonné back-in-stock a ajouté le produit au panier mais n'a pas acheté dans les 12 heures, envoie une relance ponctuelle.

La raison pour laquelle c'est un workflow et pas trois, c'est que les trois flux partagent le même état sous-jacent ("ce panier est-il toujours abandonné ?") et ne doivent pas se contredire. Un client qui revient via la relance back-in-stock ne doit pas recevoir aussi l'email d'abandon générique.

Les chiffres

Les chiffres honnêtes de ce projet.

Avant : 392 euros par mois en abonnements d'apps. Environ 18 heures par mois de temps marchand passé à réconcilier des données entre apps qui ne sont pas d'accord. Checkout TTI 4,2 secondes, en partie attribuable aux scripts des apps qui chargent sur chaque page.

Après : 47 euros par mois, décomposés en 20 pour le VPS qui héberge n8n, 12 pour l'app d'avis gardée, 9 pour l'affichage de devise gardé (nous avons gardé l'app payante parce qu'elle s'intègre avec la configuration TVA du marchand), et 6 pour du stockage cloud annexe. Environ 2 heures par mois de temps marchand sur les sujets d'automatisation. Checkout TTI 1,8 seconde.

Coût d'implémentation : 2 semaines de notre temps, à notre taux standard. Le marchand a rentabilisé sur les économies récurrentes vers le mois 6.

Risques pris : héberger et maintenir l'instance n8n. Nous avons mis le marchand sur un hébergement managé pour qu'il ne soit pas exposé à l'ops. S'il veut un jour internaliser, nous avons écrit les runbooks pour le backup, le monitoring et les procédures de mise à jour.

Ce n'est pas un résultat universel. Les économies ici ont été amplifiées par la situation spécifique : trop d'apps, faible utilisation de chacune, un catalogue à forte composante B2B qui bénéficie d'une logique custom. Une boutique B2C pure avec 4 apps bien choisies aurait des chiffres bien moins spectaculaires. Nous avons fait cet exercice sur des boutiques où la conclusion était "votre stack est correcte, gardez ce que vous avez." Cela dépend entièrement de ce que l'audit révèle.

Ce que nous referions différemment

Trois erreurs honnêtes sur ce projet.

Nous avons sous-estimé la migration de données. Cinq des apps stockaient des données dans leur propre base que le marchand ne possédait pas. Listes d'abonnés back-in-stock, soldes de points de fidélité clients, files de modération d'avis. Sortir ces données avant de désinstaller a demandé des exports custom, des attentes de tickets support, et dans un cas la reconstruction d'une liste depuis les logs email. Nous mettons maintenant cela en avant dans la phase d'audit et le devisons séparément.

Nous avons commencé par le workflow de commande. C'était le plus complexe et le plus visible s'il cassait. Nous aurions dû commencer par la sync de stock, qui avait un rayon d'impact plus petit en cas de problème. Nous séquençons maintenant : workflow le plus simple en premier, workflow qui modifie le comportement en deuxième, workflow customer-facing en dernier.

Nous n'avons pas construit l'observabilité assez tôt. Pendant les deux premières semaines, le marchand ne pouvait pas voir ce que faisaient les workflows. Nous avons ajouté des notifications Slack sur les échecs et un dashboard Looker Studio pour le volume quotidien seulement en troisième semaine, après que le marchand l'ait demandé. Cela aurait dû être semaine 1.

Quand n8n est la mauvaise réponse

Nous le disons dans chaque post sur l'automatisation que nous publions, mais ça vaut le coup de le répéter dans un cas client. n8n n'est pas toujours la bonne réponse.

Automatisation haute fréquence et basse latence. Si votre automatisation doit tourner dans les 200 millisecondes d'un événement (scoring de fraude temps réel, pricing dynamique sur chaque chargement de panier), l'architecture polling et file de n8n n'est pas adaptée. Utilisez une Shopify Function ou une app custom avec un handler webhook direct.

Automatisation qui doit être embarquée dans le storefront. Si la logique doit s'afficher sur une page produit ou en checkout, c'est du code de thème ou une Shopify Function, pas un workflow externe. Cross-sells, affichage des points de fidélité, UI de wishlist tombent ici.

Cas où l'app SaaS fait un vrai travail produit, pas que de la plomberie. L'infrastructure de délivrabilité, la détection de fraude d'une plateforme d'avis, les taux négociés transporteurs d'une app de livraison : ce n'est pas de la plomberie. C'est du travail produit qui serait un projet d'un an à répliquer. Gardez-les.

Quand l'équipe ne peut pas maintenir le workflow. Un workflow que le marchand ne peut pas debugger quand il casse est un passif. S'il n'y a pas de ressource technique chez le marchand et pas de budget pour la maintenance continue, une app payante avec support vendeur est parfois la réponse plus honnête.

La décision est rarement "n8n ou app". C'est "cette automatisation spécifique est meilleure en n8n, cette autre est meilleure en app ou function". Une stack propre mélange les deux.

Le cadre d'audit que nous utilisons

Nous le déroulons pour chaque boutique Shopify qui nous demande sur l'automatisation ou l'app bloat. Cela prend une demi-journée avec le marchand.

Inventaire. Lister chaque app installée, coût mensuel, date d'installation, date de dernière utilisation (quand on peut la déterminer), et la compréhension qu'a le marchand de ce qu'elle fait. Environ un tiers des apps reviennent en "je n'en ai aucune idée, c'était le développeur précédent".

Carte des fonctions. Pour chaque app, écrire une phrase sur la fonction métier qu'elle accomplit réellement. Beaucoup d'apps couvrent la même fonction avec des UI différentes.

Vérification native. Shopify a-t-il livré cette fonctionnalité nativement depuis l'installation de l'app ? Optimisation d'images, affichage basique de devise, plusieurs opérations de tagging et quelques cas de règles de livraison sont maintenant natifs et il arrive fréquemment que des apps de 2022 à 2024 fassent encore un travail redondant.

Fréquence et exigences de latence. À quelle fréquence cela doit tourner ? À quelle vitesse cela doit répondre ? Tout ce qui tourne moins d'une fois par heure à une latence minute-ou-mieux est un candidat n8n.

Propriété des données. L'app détient-elle des données que le marchand doit garder ? Sont-elles exportables ? Certaines apps verrouillent les données clients, les soldes de fidélité ou le contenu d'avis d'une manière qui rend la migration douloureuse.

Risque et complexité. Quel est le pire cas si ce workflow casse ? Les workflows critiques pour le checkout ont une barre différente de l'automatisation back-office.

À la fin vous avez un tableau à quatre colonnes : garder, remplacer par du natif Shopify, remplacer par n8n, remplacer par une app custom ou une Shopify Function. Le plan s'écrit tout seul à partir de là.

FAQ

n8n auto-hébergé est-il conforme RGPD pour les boutiques UE ?

Cela peut l'être, si vous contrôlez la région d'hébergement et les flux de données. Nous avons couvert la configuration UE-spécifique dans auto-héberger n8n sur AWS. En résumé : hébergez en région UE, chiffrez au repos, paramétrez la rétention sur les données d'exécution n8n, documentez le traitement des données dans votre notice de confidentialité.

Que se passe-t-il si le serveur n8n tombe ?

Pour les workflows event-driven (le pipeline de commande), Shopify réessaie les webhooks pendant 48 heures, donc une courte panne est invisible pour le business. Pour les workflows planifiés (sync de stock, panier abandonné), le run suivant rattrape. Nous ajoutons une alerte Slack sur les échecs de workflow et sur la santé serveur pour que l'équipe sache immédiatement plutôt que de découvrir des jours plus tard.

Comment gérez-vous le versioning des workflows n8n ?

Nous exportons les workflows en JSON et les committons dans un repo Git aux côtés du reste du projet. Les changements passent par revue de pull request. Pour les setups plus gros, nous faisons tourner une instance n8n de staging pour tester avant promotion en production.

Aurions-nous pu utiliser Zapier ou Make au lieu de n8n pour cela ?

Zapier ou Make auraient fonctionné pour certains de ces workflows. L'économie bascule à l'échelle : le compteur de tasks Zapier sur une stack comme celle-là aurait été d'environ 800 euros par mois pour le même volume, plus que ce que nous avons remplacé. Make est moins cher que Zapier mais reste dans la fourchette de 100 à 150 euros par mois pour ce volume. n8n auto-hébergé à 20 euros par mois gagne sur le coût dès que vous faites tourner plus de quelques workflows.

Combien de temps prend généralement la migration ?

Pour une stack comme celle ci-dessus, deux à trois semaines de travail concentré. L'audit est une demi-journée. Construire les trois workflows nous a pris environ huit jours ouvrés. Le reste du temps était migration de données, tests, mise en place du monitoring et retrait propre des anciennes apps.

Pour aller plus loin

Si vous soupçonnez que votre stack Shopify a de l'app bloat, le cadre d'audit ci-dessus est une manière gratuite de le savoir. Si vous voulez que nous le déroulions sur votre boutique et que nous écrivions le plan de remédiation, contactez-nous. Nous livrons typiquement l'audit dans un atelier d'une demi-journée avec votre équipe et les changements recommandés dans un plan d'une page que vous pouvez exécuter vous-même ou avec nous.

Pour la série plus large, voir n8n vs Zapier vs Make pour le comparatif de plateformes et sync de stock Shopify et NetSuite pour l'architecture de workflow spécifique utilisée dans le workflow 2 de ce cas client.