Le contexte. Une marque B2C au panier moyen élevé. À ce prix, un client pose des questions avant d'acheter, attend sa livraison, et a parfois besoin du service après-vente ensuite. La vente a un vrai cycle — ce qui est rare en B2C.
Ce que j'ai construit. Une synchronisation bilatérale entre Shopify et le CRM :
- les contacts, dans les deux sens ;
- les affaires, qui suivent la vente du premier échange jusqu'à la commande Shopify ;
- la livraison et le SAV, suivis par des tickets : une demande arrive avec tout l'historique du client.
Sous le capot : n8n porte une logique métier complexe, et Google Cloud Pub/Sub, en amont, absorbe les événements de Shopify. Shopify peut envoyer plusieurs fois le même webhook : une déduplication sur une fenêtre de trois secondes écarte les doublons avant qu'ils ne créent deux affaires ou deux tickets, et des reprises automatiques rejouent ce qui a échoué au lieu de le perdre.
Deux versions. La première, avec Pipedrive, tournait sur Zapier ; n8n est arrivé avec la migration. Quand le client est passé à HubSpot, la synchronisation est passée à une seconde version, celle décrite ici : n8n pour la logique, Google Cloud Pub/Sub en amont, déduplication et reprises automatiques.
Ce que ça montre. En B2C, créer une affaire CRM par commande est généralement une erreur : une commande payée n'est pas une négociation. Quand le panier est élevé, c'en est une. Le bon schéma dépend du parcours d'achat, pas de l'outil.
Ce qu'on retrouve d'un projet à l'autre
La donnée est rangée dans un endroit qui appartient au client, la logique est écrite là où on peut la rouvrir, et chaque échec se voit au lieu de passer en silence. C'est ce qui permet de changer d'outil, de prestataire ou de volume sans tout reconstruire. Comment je choisis entre réglage natif, connecteur, automatisation et développement.
Pour le même client : un outil de pilotage de la marge réelle par produit, alimenté par Shopify.