De Shopify à Pennylane : automatiser la facturation B2B sans ressaisie
Récit d'un call : brancher Shopify à Pennylane avec n8n pour créer le client et la facture à chaque commande B2B, sans doublons ni ressaisie.
Cette semaine, j’ai eu un appel avec une PME qui vend en B2B. Des commandes qui rentrent sur une boutique , et derrière, toute la compta qui se fait dans . Entre les deux, une personne de l’équipe qui, pour chaque commande, allait retrouver le client dans Pennylane (ou le créer s’il n’existait pas), puis générait la facture à la main. Vingt, trente commandes par jour. Multiplie par les jours ouvrés, et tu as un temps plein qui part en ressaisie.
Le call, c’était justement pour valider le workflow que je leur avais monté pour tuer cette corvée. Connecter Shopify à Pennylane, c’est la partie facile. Le vrai travail, c’est tous les petits pièges qui font qu’une synchro naïve finit par créer plus de bordel qu’elle n’en enlève : les doublons de clients, l’API compta qui sature, les commandes qu’il faut traiter en plusieurs fois. Je te déroule ce qu’on a posé, et surtout pourquoi.
Le point de départ : deux outils qui ne se parlent pas
Shopify sait tout de la commande : qui a acheté, quoi, pour combien, avec quelle adresse de facturation. Pennylane, lui, attend une facture propre rattachée au bon client pour faire la compta et la relance. Le problème, c’est que par défaut personne ne fait le pont. Alors quelqu’un le fait à la main, et ce quelqu’un passe sa journée à recopier des infos qui existent déjà, d’un écran à l’autre.
L’idée du workflow tient en une phrase : dès qu’une commande tombe sur Shopify, n8n s’occupe de retrouver ou créer le client dans Pennylane, puis d’y générer la facture. Personne ne touche à rien. La personne qui faisait la ressaisie peut balancer ses commandes et passer à autre chose.
1. Le cœur : commande → client → facture
Le workflow principal, c’est trois temps :
- Shopify Trigger sur l’événement Order created (paiement validé). Dès qu’une commande passe, n8n reçoit tout le détail.
- Un appel à l’API Pennylane pour chercher si le client existe déjà. S’il existe, on récupère son identifiant. Sinon, on le crée avec les infos de la commande.
- Un dernier appel qui crée la facture dans Pennylane, rattachée à ce client, avec les lignes de produits et les montants repris de Shopify.
Pennylane n’a pas de node natif prêt à l’emploi dans n8n comme peut l’avoir Google Sheets, mais ça ne change rien : il expose une API REST, et le node HTTP Request de n8n sait dialoguer avec n’importe quelle API. Tu poses ton authentification une fois, et ensuite tu appelles les endpoints “clients” et “factures” comme tu appellerais n’importe quel service.
Ce premier bloc, à lui seul, il supprime 90% de la charge. Mais c’est le reste qui fait qu’il tient dans le temps.
2. Le piège des doublons (et pourquoi l’email ne suffit pas)
Voilà le sujet qui a pris le plus de temps sur le call, et c’est normal, parce que c’est celui qui casse tout si tu le rates.
Quand tu cherches un client “existant” dans Pennylane, tu le cherches sur quoi ? Le réflexe, c’est l’adresse email. Sauf qu’en B2B, l’email est instable : le contact change, la personne qui commande n’est pas toujours la même, quelqu’un se trompe d’une lettre. Le jour où l’email bouge, ton système ne reconnaît plus le client, le considère comme nouveau, le recrée et te génère un doublon dans la compta. Deux fiches pour la même boîte, c’est le début des ennuis pour les relances et le lettrage.
La solution qu’on a retenue : matcher sur un identifiant qui, lui, ne bouge jamais. En France, pour une entreprise, c’est le SIREN. Deux commandes de la même société auront toujours le même SIREN, même si le contact ou l’email change. Tu cherches par SIREN, tu ne crées un client que si ce SIREN n’existe pas encore, et les doublons disparaissent.
Le hic : encore faut-il que le SIREN soit renseigné partout. Sur la base clients existante dans Pennylane, il manquait sur beaucoup de fiches. Recopier ça à la main sur des centaines de clients, c’est exactement la corvée qu’on cherche à éviter.
Une fois la base assainie et le matching SIREN en place dans le workflow, le problème des doublons est réglé à la source, pas rattrapé après coup.
3. Ne pas cramer l’API : le rate limiting
Autre point qui a l’air technique mais qui se paie cash en production. Sur le call, la question était : “si je balance trente factures d’affilée, ça passe ?”
Si tu envoies tout d’un coup, non. Une API compta comme celle de Pennylane a des limites de débit. Tu lui balances 200 créations de factures en dix secondes, elle te renvoie des erreurs, et une partie de tes factures ne part jamais. Le pire des scénarios : tu crois que c’est traité, ce ne l’est pas, et tu t’en rends compte trois semaines plus tard.
La parade dans n8n, c’est de traiter par lots. Plutôt qu’un webhook qui déclenche une création immédiate, on met les commandes dans une file, et un workflow planifié (Schedule Trigger) vient en piocher un paquet raisonnable toutes les cinq minutes. Le node Loop Over Items (ex Split in Batches) découpe le flux, et on ajoute un petit délai entre chaque appel.
| Sans rate limiting | Avec traitement par lots |
|---|---|
| 200 factures envoyées en bloc | 15-20 factures par cycle de 5 min |
| L’API sature, des factures se perdent | Chaque lot passe proprement |
| Tu ne sais pas ce qui a échoué | La file se vide, tout finit traité |
Le résultat pour l’utilisateur : il ne voit pas la file. Il balance ses commandes quand il veut, et tout ce qu’il fait dans la journée est traité dans l’heure. La notification tombe juste un peu après, mais rien ne se perd. C’est le genre de détail invisible qui fait la différence entre une automatisation qui “marche en démo” et une qui tient en production.
4. La notification quand un humain doit trancher
Toutes les commandes ne se traitent pas les yeux fermés. En B2B, il arrive qu’une commande parte en plusieurs fois (stock partiel, envoi fractionné). Là, tu ne veux pas que le système décide tout seul : tu veux prévenir la bonne personne.
On a ajouté un node IF qui repère ces cas particuliers (par exemple une quantité disponible insuffisante), et qui envoie une notification sur le canal de l’équipe : “Commande #1234 à traiter en plusieurs envois.” Pas de blocage, pas de validation lourde, juste une alerte au bon endroit pour que quelqu’un s’en occupe.
C’est un principe que j’aime beaucoup : l’automatisation prend tout ce qui est mécanique, et elle passe la main sur ce qui demande un vrai jugement, en amenant l’info directement là où l’humain regarde. Tu n’automatises pas la décision, tu automatises le fait de ne rien rater.
Cloud ou auto-hébergé pour ce genre de projet ?
Question qu’on me pose à chaque fois. n8n existe en deux versions : tu l’héberges toi-même sur un serveur, ou tu prends la version managée n8n Cloud où tout est géré.
Pour une PME qui veut une synchro qui tourne sans avoir à gérer un serveur, des sauvegardes et la sécurité des webhooks, je conseille de démarrer sur n8n Cloud. Tu te concentres sur la logique métier (le matching SIREN, le batching, les notifications), pas sur la plomberie système. Le jour où tu as une raison technique ou réglementaire de rapatrier chez toi, n8n est portable, tu migres. Mais pour valider que la synchro te fait gagner du temps, le Cloud enlève une montagne de friction.
Ce que ça change vraiment
À la fin du call, on n’avait pas construit une usine à gaz. On avait un workflow qui écoute Shopify, retrouve ou crée le bon client dans Pennylane sans jamais faire de doublon, génère la facture, encaisse la charge sans saturer l’API, et sait alerter un humain quand c’est nécessaire. La personne qui passait ses journées à recopier des commandes récupère ses journées.
C’est ça, une bonne automatisation de facturation : pas juste “connecter deux outils”, mais penser aux cas tordus (l’email qui change, le pic de volume, la commande à traiter en deux fois) pour que le système tienne quand la vraie vie s’en mêle. Shopify d’un côté, Pennylane de l’autre, n8n au milieu qui fait le travail que personne n’a envie de faire.
Tu veux apprendre à monter ce genre de synchro toi-même, du premier webhook Shopify jusqu’aux appels API et à la gestion des lots ? La formation n8n complète t’emmène de débutant à autonome : on part des bases et on construit des workflows concrets qui tournent pour ton activité.
Et si tu veux juste tester, tu peux ouvrir un compte n8n Cloud et brancher ton premier workflow en quelques minutes.
Sources : n8n Docs · Shopify Trigger node, n8n Docs · HTTP Request node, n8n Docs · Loop Over Items (Split in Batches), Pennylane · Documentation API.
Reçois les prochains articles
Cet article t'a été utile ? Reçois les prochains.
Un mail quand un nouvel article ou guide sort. Pas de spam, désabonnement en 1 clic.
Confirmation par email · désabonnement en 1 clic.