SEEGEA

Make Shopify : scénarios d’automatisation et limites réelles

Make est le couteau suisse des équipes techniques qui trouvent Zapier trop rigide. Le pricing par opérations et les modules Shopify natifs attirent, mais au-delà d'un certain volume, la complexité explose et les rate limits GraphQL cassent tout. Audit technique.

11 min de lecture17 avril 2026

Make (anciennement Integromat) est le choix naturel des équipes techniques qui ont dépassé Zapier. Interface visuelle en scénario, facturation à l'opération, modules natifs pour Shopify, PrestaShop, Stripe, PostgreSQL — on peut effectivement bâtir des pipelines très propres. Le souci arrive avec la volumétrie et avec l'absence de rollback côté catalogue.

Ce guide est pensé pour les devs et freelances qui arbitrent entre Make, une intégration GraphQL directe, ou une couche d'édition comme Seegea. On parle scénarios concrets, coûts réels, et patterns d'erreur observés en audit.

Stack type autour de Make Shopify

MakeShopifyPrestaShopWebhookPostgreSQL

Les 3 scénarios Make les plus robustes avec Shopify

Sync ERP → Shopify (produits + stocks)

PostgreSQLCron + GraphQL
Scénario planifié (toutes les 15 min) qui lit une table products côté ERP, filtre les deltas, et pousse via productUpdate + inventoryAdjustQuantities. Robuste si on respecte le bucket GraphQL (batch de 50 max).

Shopify webhook → Data warehouse

Webhookorders/create → PG
Webhook orders/create reçu par Make, enrichi avec customer + products, inséré dans PostgreSQL/BigQuery. Latence typique : 2 à 5 secondes, parfait pour un dashboard temps quasi réel.

Shopify → CRM (HubSpot, Pipedrive)

Création automatique de deals/contacts dans le CRM à partir des commandes Shopify. Module Shopify natif pour lire la commande + module CRM natif pour créer le deal. Moins de code custom qu'avec Zapier.

Anatomie d'une requête GraphQL Admin depuis Make

Pour un cas non trivial, le module natif Shopify de Make ne suffit pas : il faut passer par Make an API Call + GraphQL. Voici à quoi ressemble une mutation typique pour mettre à jour un prix variante :

Mutation GraphQL Admin via Make an API Call

POST /admin/api/2024-10/graphql.json
Headers:
  X-Shopify-Access-Token: {{shpat_xxx}}
  Content-Type: application/json

Body:
{
  "query": "mutation productVariantsBulkUpdate($productId: ID!, $variants: [ProductVariantsBulkInput!]!) { productVariantsBulkUpdate(productId: $productId, variants: $variants) { productVariants { id price } userErrors { field message } } }",
  "variables": {
    "productId": "gid://shopify/Product/{{1.id}}",
    "variants": [{ "id": "gid://shopify/ProductVariant/{{1.variants[].id}}", "price": "{{1.new_price}}" }]
  }
}

Coût : 10 points par variante mise à jour. Bucket Standard = 100 variantes avant rate limit.

Les 5 pièges Make Shopify qu'on voit en audit

1. L'Iterator qui explose le quota

Classique : un Iterator sur 2 000 produits en sortie d'un scénario "ERP → Shopify". Chaque itération = 1 opération + 1 appel HTTP + 1 parser = 3 opérations minimum. Sur 2 000 items, on consomme 6 000 opérations — soit 60 % du plan Core d'un coup.

2. Les erreurs 429 non gérées

Make ne retry pas automatiquement les 429 GraphQL Admin. Il faut ajouter un module Break avec retry exponentiel (3 tentatives, délai 2^n secondes) sur chaque appel sensible. Beaucoup d'équipes l'oublient et perdent 10 à 20 % des updates en heures de pointe.

3. Le webhook désactivé en silence

Make désactive un scénario après 3 erreurs consécutives. Si votre scénario webhook orders/create plante un dimanche matin (ex: HubSpot down), votre scénario est stoppé et les commandes des 24 h suivantes sont perdues. Toujours prévoir un monitoring externe (UptimeRobot, Better Stack) sur l'URL webhook.

4. Les metafields écrasés en update

Le module natif Shopify "Update Product" ne préserve pas toujours les metafields custom. Il faut systématiquement passer par productUpdate + metafieldsSet en GraphQL, jamais par productSet qui est destructif.

5. Aucun rollback possible

Make conserve un historique des exécutions (7 à 30 jours selon le plan), mais aucun moyen de "rejouer à l'envers" un scénario qui a bulk-updaté 1 500 produits. Si un stagiaire a poussé un mauvais CSV dans un scénario, les produits Shopify sont modifiés — sans retour arrière natif.

Make est puissant mais n'est pas un outil de gestion catalogue. C'est un orchestrateur. Pour l'édition métier (corrections en masse, enrichissement IA, rollback), il faut une couche dédiée comme Seegea.

Make vs Seegea : comparatif technique

CritèreMake + Shopify GraphQLSeegea
Temps de setup2 à 10 jours (selon scenarios)48 heures
Coût mensuel 5 000 produits16 à 29 € Make + Shopify59 € tout inclus
Bulk edit 500 fichesScénario custom à coderGrille inline native
Rollback produitNon natifCtrl+Z + re-push GraphQL
Respect rate limits GraphQLÀ coder (Break + retry)Géré automatiquement
Accès équipe marketingScénarios incompréhensiblesGrille type Excel
IA description produitVia OpenAI + prompt customNative, contextualisée

Combien coûte vraiment une stack Make + Shopify ?

On part d'un marchand Shopify avec 5 000 produits et 500 commandes/mois :

  • Shopify Standard : 39 $/mois.
  • Make Pro (10 000 opérations) : 16 €/mois.
  • Développement initial des scénarios : 3 à 8 jours freelance = 2 400 à 6 400 € one-shot.
  • Maintenance mensuelle : 4 à 8 h/mois pour debugger les 429, les webhooks désactivés, les mappings cassés = 200 à 600 €/mois.

Soit un TCO première année entre 5 000 et 14 000 €, hors licences Shopify. Pour un outil de gestion catalogue comme Seegea (708 à 1 548 €/an selon le plan), le ROI est atteint dès que vous passez plus de 4 h/semaine sur Make.

Auditez votre stack Make + Shopify avec nous

30 min Google Meet · on trace les scénarios qui peuvent être supprimés

Auditez votre stack Make + Shopify avec nous

Quand Make reste le bon choix

Make n'est pas un outil à abandonner — c'est un excellent orchestrateur pour ce qui sort du catalogue pur :

  • Synchro commandes vers ERP (Sage, Cegid, Dynamics 365), logistique (Sendcloud, Boxtal), comptabilité (Pennylane, QuickBooks).
  • Enrichissement CRM : push HubSpot/Pipedrive sur événement Shopify.
  • Notifications métier complexes : Slack/Teams conditionnées par des règles métier ("alerter si commande > 500 € d'un client VIP").
  • Pipelines data : Shopify → PostgreSQL → Metabase/Looker.

La bonne architecture : Make + Seegea en parallèle

Chez les marques qu'on accompagne, le pattern gagnant est clair : Make pour les flux transactionnels (commandes, ERP, CRM, logistique), Seegea pour le catalogue (édition, enrichissement, rollback, médias). Les deux outils ne se croisent pas, et on évite les scénarios Make qui tentent de gérer le catalogue — ils sont toujours fragiles.

Seegea est conçu en France entre Annecy et Chantilly. Si vos scénarios Make "catalogue" consomment plus de 5 000 opérations/mois, on vous montre comment réduire ça à zéro en déplaçant ces scénarios dans Seegea — sans toucher au reste de votre stack.

Créé en France, entre Annecy et Chantilly · Assistance email & visio Google Meet

FAQ

Make propose les deux côtés : un module Shopify natif qui consomme la REST Admin pour les cas courants (products, orders, customers) et un module HTTP / Make an API Call qui permet d'appeler directement la GraphQL Admin. Pour rester à jour avec les dépréciations REST de Shopify (2024-10, 2025-01), on recommande de passer sur le module GraphQL dès que possible.

Voyez Seegea en action

Réservez une démo visio de 30 minutes sur Google Meet. Sans engagement.

Réserver une démo