Envoyer les commandes Shopify vers Google Sheets avec Make (une ligne par commande ou par article)

Ce guide présente le scénario que nous construisons dans Make pour ce besoin : choix du déclencheur, mappage des champs, articles de la commande, protection contre les doublons, remboursements et annulations, et une alerte Slack pour finir. Vous pouvez le suivre étape par étape, même s'il s'agit de votre premier vrai scénario.

D'abord, décidez : une ligne par commande ou par article ?

Tranchez avant d'ouvrir Make, car cela change toute la structure du fichier.

• Une ligne par commande convient si vous suivez le chiffre d'affaires, les clients et le statut des commandes. La commande #1042 tient sur une ligne, avec les produits regroupés dans une cellule « Articles ».
• Une ligne par article convient si vous suivez les produits : gestion du stock, réassort fournisseur, quels SKU se vendent ensemble. La commande #1042 avec trois produits devient trois lignes qui partagent le même numéro de commande.

Besoin des deux ? Utilisez deux onglets dans le même fichier, alimentés par le même scénario. N'essayez pas de faire tout tenir dans un seul onglet.

Étape 1 : Choisir le déclencheur : Watch orders ou Watch events

L'app Shopify dans Make propose deux points de départ réalistes.

Shopify > Watch orders est un déclencheur par polling. Make interroge votre boutique selon la planification du scénario (toutes les 15 minutes, toutes les heures, comme vous voulez) et récupère les commandes qu'il n'a pas encore vues. C'est le plus simple à configurer, et ça suffit pour la plupart des petites boutiques. Deux points à connaître :

• Ce n'est pas instantané. Une commande passée à 10 h 01 peut arriver dans le fichier à 10 h 15.
• Chaque vérification planifiée consomme des credits, même sans nouvelle commande. Une planification toutes les 5 minutes sur une boutique calme brûle des credits sur des exécutions vides.

Shopify > Watch events est le déclencheur instantané, basé sur les webhooks. Shopify envoie la commande à Make au moment où l'événement se produit. Vous choisissez un topic de webhook Shopify comme orders/create, orders/paid, orders/cancelled ou refunds/create (Make peut les afficher au format enum de Shopify, par exemple ORDERS_CREATE). Pas de vérifications à vide, pas d'attente. La contrepartie : chaque déclencheur écoute un seul topic, et si Shopify envoie deux fois le même événement (il réessaie quand la livraison n'est pas confirmée), il vous faut votre propre contrôle des doublons. On y revient à l'étape 5.

Notre choix par défaut : Watch events sur orders/paid si le fichier sert à la comptabilité, orders/create s'il sert à la préparation des colis. Watch orders uniquement quand le client veut la solution la plus simple et que le délai ne le gêne pas.

Un piège avec Watch orders : le module mémorise où il s'est arrêté. Si vous cliquez deux fois sur « Run once » pendant vos tests, la deuxième exécution ne renvoie souvent rien. Faites un clic droit sur le module et choisissez le point de départ, ou passez une nouvelle commande test.

Étape 2 : Préparer le fichier

Créez la ligne d'en-tête avant de configurer le module Google Sheets, pour que Make puisse lire les colonnes. Une structure qui tient la route pour un suivi par commande :

Gardez l'ID commande en colonne A. C'est la clé dont tout le reste dépend. Le numéro de commande (#1042) est plus lisible, mais c'est l'ID numérique que Shopify utilise dans les données de remboursement et d'annulation. Les champs source sont les noms du webhook de commande de Shopify, celui que livre Watch events. Watch orders peut nommer certains champs autrement : choisissez-les dans le panneau de mapping.

Étape 3 : Mapper les champs (une ligne par commande)

Ajoutez Google Sheets > Add a Row, choisissez le fichier et l'onglet, réglez « Table contains headers » sur Yes : les colonnes apparaissent comme champs.

La plupart se mappent directement. Quelques-uns demandent une fonction :

• Date : formatDate(1.created_at; "YYYY-MM-DD HH:mm"; "Europe/Paris"). Remplacez le fuseau par celui de votre boutique. Les dates ISO brutes se trient bien, mais se lisent mal.
• Total : Shopify envoie les prix sous forme de texte. Pour que le fichier puisse les additionner, utilisez parseNumber(1.total_price; ".") ou formatez la colonne en nombre dans Sheets.
• Articles : join(map(1.line_items; "title"); ", ") donne « Chemise en lin, Tote bag » dans une seule cellule. Vous voulez les quantités ? Utilisez un Iterator puis un Tools > Text aggregator avec {{quantity}} × {{title}}, et mappez le texte agrégé.
• Statut d'expédition est vide pour les commandes non expédiées. Encadrez-le : ifempty(1.fulfillment_status; "unfulfilled").

Lancez le scénario une fois avec une vraie commande test et vérifiez chaque colonne.

Étape 4 : Une ligne par article avec l'Iterator

Pour un suivi par produit, ajoutez Flow Control > Iterator entre le déclencheur et le module Sheets, et mappez line_items[] dans son champ Array. Chaque produit de la commande devient un bundle distinct.

Dans Add a Row, mappez les champs de commande depuis le déclencheur (numéro, date, e-mail) et les champs produit depuis l'Iterator (title, variant_title, sku, quantity, price). Ajoutez une colonne ID ligne et mappez l'id de l'Iterator. ID commande + ID ligne forment ici votre clé unique.

Côté credits : chaque bundle qui passe par Add a Row coûte des credits, donc une commande de 10 articles, c'est 10 exécutions de ce module. Si vos commandes sont volumineuses, remplacez Add a Row par un Array aggregator (Source module : l'Iterator) suivi de Google Sheets > Bulk Add Rows (advanced). Une écriture par commande au lieu d'une par article, et beaucoup moins de risques de buter sur les limites de Google pendant les soldes.

Étape 5 : Éviter les lignes en double (chercher avant d'ajouter)

Les doublons viennent de trois sources : les nouvelles tentatives du webhook, quelqu'un qui relance le scénario, et un Watch orders remis à un point antérieur. La solution reste la même : vérifier avant d'écrire.

L'approche évidente consiste à utiliser Google Sheets > Search Rows filtré sur l'ID commande, puis à n'ajouter une ligne que si rien n'est trouvé. Le hic : quand Search Rows ne trouve rien, il ne renvoie rien, et les modules suivants ne s'exécutent tout simplement pas. Votre branche « ajouter si absent » ne se déclenche jamais.

Deux solutions :

• L'astuce de l'agrégateur. Placez un Array aggregator juste après Search Rows (Source module : Search Rows). L'agrégateur renvoie un bundle même quand la recherche est vide. Ajoutez un Router : route 1 avec le filtre length(Array) = 0 → Add a Row ; route 2 avec length(Array) > 0 → Update a Row (avec le numéro de ligne issu du tableau) ou fin du scénario.
• Data store. Créez un data store Make avec l'ID commande comme clé. Avant d'écrire, utilisez Data store > Check the existence of a record ; il renvoie un oui/non sur lequel filtrer. Après l'écriture, Add/replace a record. C'est plus rapide qu'une recherche dans un gros fichier, et ça ne dépend pas du fait que personne ne touche à la colonne A.

En mode article, cherchez sur ID commande + ID ligne, ou vérifiez la commande une fois avant l'Iterator et ignorez-la entièrement si elle existe déjà.

Étape 6 : Gérer remboursements et annulations

Ne supprimez pas de lignes quand une commande est remboursée. Des lignes supprimées faussent des totaux que quelqu'un a déjà communiqués. Mettez plutôt la ligne à jour.

Construisez un second petit scénario :

• Shopify > Watch events avec le topic refunds/create (et une copie avec orders/cancelled).
• Google Sheets > Search Rows sur l'ID commande. Pour un remboursement, l'ID se trouve dans le champ order_id ; pour une annulation, c'est l'id de la commande elle-même.
• Google Sheets > Update a Row avec le numéro de ligne trouvé : passez le Statut à « Remboursé », « Remboursement partiel » ou « Annulé », et inscrivez le montant remboursé dans sa propre colonne. Les remboursements partiels sont fréquents : n'écrasez pas le total d'origine.

Si une commande annulée n'a jamais été enregistrée (annulée avant paiement alors que vous déclenchez sur orders/paid), la recherche ne trouve rien et le scénario s'arrête sans bruit. C'est généralement ce qu'on veut.

Étape 7 : Ajouter une alerte Slack

Ajoutez Slack > Create a Message à la fin du scénario principal. N'alertez pas pour chaque commande : l'équipe coupera le canal en une semaine. Placez plutôt un filtre sur la route :

• total de commande au-dessus d'un seuil de votre choix,
• commandes avec une note client (note n'est pas vide),
• ou un produit ou mode de livraison précis.

Un message utile : Nouvelle commande {{1.name}}, {{1.total_price}} {{1.currency}}, {{1.email}} avec un lien vers la commande dans l'admin Shopify.

Une gestion des erreurs vraiment utile

Clic droit sur un module, puis Add error handler :

• Sur le module Google Sheets, utilisez Retry (anciennement Break) avec nouvelles tentatives automatiques. Google renvoie des erreurs de limite de requêtes aux heures chargées, et une nouvelle tentative quelques minutes plus tard passe presque toujours.
• Sur le module Slack, utilisez Skip (anciennement Ignore). Une alerte qui échoue ne doit pas marquer l'exécution en erreur si la ligne a bien été écrite.
• Resume est pratique quand une recherche échoue et que vous préférez écrire une valeur de repli (« inconnu ») plutôt que de tout arrêter.
• Commit et Rollback ne concernent que les modules qui gèrent les transactions, comme les data stores. Les écritures dans Google Sheets ne peuvent pas être annulées : une raison de plus de vérifier les doublons en amont.

Activez aussi Store incomplete executions dans les paramètres du scénario : une commande en échec vous attendra au lieu de disparaître, et Retry en a besoin. Autre raison de gérer les erreurs : par défaut, Make désactive un scénario après 3 erreurs consécutives, et un scénario qui démarre par un déclencheur instantané comme Watch events dès la première.

Check-list de test rapide

• Passez une commande test avec deux produits différents et vérifiez les deux onglets.
• Relancez le même bundle et confirmez qu'aucune deuxième ligne n'apparaît.
• Remboursez un article et vérifiez la mise à jour des colonnes statut et remboursement.
• Annulez une commande non payée et confirmez que rien ne casse.
• Consultez l'historique du scénario au bout d'une journée pour voir votre consommation de credits.