Zapier et Make pour PrestaShop : automatisez les opérations de votre boutique

Dernière révision en juin 2026. Les tarifs et les intervalles d’interrogation changent souvent sur les deux plateformes, considérez ces chiffres comme des repères et vérifiez les offres actuelles avant de vous engager. Chemins du back-office vérifiés avec PrestaShop 1.7, 8.x et 9.x.

Toutes les boutiques PrestaShop perdent du temps par la même brèche : de petites tâches opérationnelles qui prennent chacune deux minutes, mais finissent par avaler un après-midi par semaine. Une nouvelle commande doit être transmise à l’entrepôt. Un statut "Expédié" devrait déclencher un SMS, pas seulement un e-mail. Un nouveau client devrait arriver dans le CRM. Rien de tout cela n’est difficile, c’est simplement incessant. Zapier et Make (anciennement Integromat) existent pour faire ce travail de liaison à votre place, en connectant les données de PrestaShop à la centaine d’autres outils que votre entreprise utilise déjà. La vraie question n’est pas de savoir s’il faut automatiser ; c’est de savoir avec quel moteur automatiser, et, tout aussi souvent, à quel moment une plateforme d’automatisation n’est tout simplement pas le bon moteur et doit laisser la place à un module natif.

Ce guide tranche cette question. Nous allons comparer Zapier et Make directement, dans le contexte précis d’une boutique PrestaShop, montrer les trois vraies façons de connecter PrestaShop à l’un ou l’autre outil (avec les chemins exacts du back-office), et vous donner une méthode pour décider quand une plateforme externe justifie son abonnement mensuel, et quand elle devient discrètement un risque. Si vous cherchez un tutoriel progressif, scénario par scénario, pour créer votre premier flux de travail sans code, c’est un autre article, consultez PrestaShop et Zapier : automatiser des flux de travail sans écrire de code. Ici, il est question de choisir et d’exploiter la bonne plateforme.

Zapier vs Make : la comparaison honnête pour PrestaShop

Les deux plateformes font fondamentalement la même chose, surveiller un événement dans une application, puis déclencher une action dans une autre. Zapier appelle un flux de travail un Zap ; Make l’appelle un Scénario. Les différences qui comptent vraiment pour un propriétaire de boutique PrestaShop sont la profondeur d’intégration, le modèle tarifaire et la façon dont la plateforme mesure votre usage.

Concrètement, qu’est-ce que cela change pour vous ? Pour la plupart des boutiques PrestaShop, Make est le meilleur choix par défaut, tout simplement grâce à son connecteur PrestaShop natif (l’application de Make, non maintenue par PrestaShop SA). Il supprime la partie la plus sujette aux erreurs de toute la configuration (le câblage manuel des webhooks et du Webservice), et sa facturation par opération vieillit mieux quand votre volume de commandes augmente. Choisissez plutôt Zapier lorsque les autres applications de votre flux de travail sont prioritaires et disposent d’un connecteur Zapier plus solide, ou lorsque vous voulez le chemin le plus court entre une idée et une automatisation fonctionnelle, avec PrestaShop connecté de toute façon par un simple webhook. Les tarifs des deux plateformes évoluent, donc considérez les chiffres ci-dessus comme des repères et vérifiez les offres actuelles avant de vous engager, la différence structurelle (par tâche vs par opération, application officielle vs aucune) est la partie durable.

Trois façons de connecter PrestaShop, et laquelle choisir

Quelle que soit la plateforme choisie, PrestaShop doit lui fournir des données. Il existe trois voies courantes pour une automatisation de type Zapier/Make, avec un compromis entre effort de configuration et temps réel. (Les vraies boutiques utilisent aussi des modules dédiés de marketplace, des connecteurs ERP/comptabilité et middleware/iPaaS, des échanges directs par base de données ou fichiers dans les anciens ERP, ainsi que des modules sur mesure, mais les trois options ci-dessous sont celles que vous relierez à Zapier ou Make.)

Voie 1 : le Webservice intégré (API de type REST)

PrestaShop intègre un Webservice : une API HTTP de type REST, en XML par défaut, avec une sortie JSON disponible dans les versions compatibles. C’est la connexion la plus flexible, car elle expose presque toutes les ressources, commandes, clients, produits, stock, paniers, adresses, mais elle fonctionne par interrogation : la plateforme d’automatisation doit la consulter selon un planning. Pour l’activer :

• Allez dans Paramètres avancés → Webservice dans le back-office.
• Passez Activer le service web de PrestaShop sur Oui (cela définit le drapeau de configuration PS_WEBSERVICE).
• Cliquez sur Ajouter une nouvelle clé de service web, puis accordez les permissions ressource par ressource, cochez uniquement les ressources nécessaires à l’automatisation (par exemple GET sur orders et customers, rien de plus).
• Copiez la clé générée dans Make ou Zapier comme identifiant d’authentification. L’authentification se fait en HTTP Basic, avec la clé comme nom d’utilisateur et un mot de passe vide, via HTTPS.

Sur cette voie, une interrogation pour "récupérer les nouvelles commandes" est un simple GET. Celui-ci renvoie les cinq commandes les plus récentes, avec tous les champs, au format JSON :

GET https://yourstore.com/api/orders?display=full&output_format=JSON&sort=[id_DESC]&limit=5

# Auth: HTTP Basic – username = your Webservice key, password = blank
curl -u "YOUR_WEBSERVICE_KEY:" \
  "https://yourstore.com/api/orders?display=full&output_format=JSON&sort=[id_DESC]&limit=5"

Le paramètre display=full est celui que tout le monde oublie, sans lui, le Webservice ne renvoie qu’une liste d’identifiants de ressources, pas les champs de commande que vous voulez réellement faire correspondre dans votre Zap ou Scénario. output_format=JSON n’est respecté que dans les versions qui le prennent en charge ; la sortie par défaut est le XML. Dans la plateforme, stockez l’identifiant de commande le plus élevé déjà traité et n’agissez que sur les lignes au-dessus, sinon vous retraiterez les mêmes commandes à chaque interrogation.

Deux points sont non négociables ici : servez toujours l’API via HTTPS (la clé circule dans la requête), et limitez les permissions au strict nécessaire, une clé avec accès en écriture à orders qui fuit peut réécrire votre historique de ventes. Si votre plateforme propose des IP sortantes statiques, placez-les sur liste blanche au niveau du serveur ou du pare-feu afin que seule votre automatisation puisse atteindre le point d’accès.

Voie 2 : les webhooks (push, temps réel)

Les webhooks inversent le sens : au lieu que la plateforme demande "du nouveau ?" toutes les quelques minutes, PrestaShop pousse l’événement dès qu’il se produit. C’est le bon modèle pour tout ce qui est sensible au temps. Une notification Slack dès qu’une commande arrive, un contrôle antifraude déclenché au moment du paiement. Le hic : le cœur de PrestaShop n’a pas d’émetteur de webhooks intégré. Quelque chose doit écouter le bon hook (actionValidateOrder pour une nouvelle commande, actionOrderStatusPostUpdate pour un changement de statut, actionObjectCustomerAddAfter pour un nouveau client) et envoyer la charge utile en POST vers l’URL de votre scénario. Ce "quelque chose" est un petit module, soit un module de marketplace, soit quelques lignes reliées à ces hooks. En échange, vous obtenez un vrai comportement en temps réel, sans coût d’interrogation et sans tâche facturée gaspillée sur des vérifications vides.

Voie 3 : le connecteur PrestaShop natif de Make

Si vous avez choisi Make, son connecteur PrestaShop natif (l’application de Make, non maintenue par PrestaShop SA) est la voie la plus simple. Il gère l’authentification Webservice pour vous et expose des déclencheurs prêts à l’emploi pour surveiller les commandes, produits et clients nouveaux ou mis à jour : il suffit d’indiquer l’URL de votre boutique et votre clé, puis de commencer à construire. Il interroge toujours sous le capot (et hérite donc de la latence ci-dessous), mais vous évitez toutes les étapes manuelles de la voie 1. C’est pourquoi "utiliser Make" et "utiliser son connecteur natif" reviennent souvent à la même recommandation pour une boutique typique.

Raccourci de décision : besoin d’un déclenchement instantané (alertes, antifraude, timing de relance panier abandonné) ? Utilisez les webhooks (voie 2). Besoin d’un accès large et planifié à votre catalogue ou à vos commandes, et vous utilisez Make ? Utilisez le connecteur natif (voie 3). Vous êtes sur Zapier ou vous avez besoin d’une ressource non couverte par l’application ? Câblez le Webservice à la main (voie 1).

La taxe de latence, pourquoi "automatisé" ne veut pas dire "instantané"

C’est le point le plus mal compris au sujet de Zapier et Make, et il change complètement les automatisations réellement pertinentes. Les déclencheurs basés sur l’interrogation ne réagissent pas au moment exact où quelque chose se produit, ils vérifient à intervalle régulier. Selon l’offre, Zapier interroge environ toutes les 1 à 15 minutes, et Make peut descendre jusqu’à une minute sur les offres payantes (plus longtemps sur l’offre gratuite). Pour un journal "nouvelle commande vers Google Sheets", quelques minutes de retard sont invisibles et sans conséquence. Pour une relance de panier abandonné, où la fenêtre optimale se mesure en dizaines de minutes, cette latence d’interrogation plus une planification de scénario trop espacée peuvent vous faire manquer le bon moment. Les hooks propres à PrestaShop s’exécutent de manière synchrone, instantanément. C’est précisément pour cela que certains traitements doivent vivre dans un module sur votre serveur, et non dans une plateforme cloud de l’autre côté d’Internet.

Quand une plateforme d’automatisation n’est pas le bon outil

Zapier et Make excellent dans un domaine : connecter PrestaShop à un outil de niche que votre entreprise utilise et qui n’aura jamais de module dédié, un 3PL spécifique, une feuille Google interne, un canal Discord, une passerelle SMS régionale. Pour cette longue traîne de liaisons ponctuelles, difficile de faire mieux. Mais il existe des cas clairs où s’appuyer sur une plateforme externe coûte plus qu’elle ne fait gagner :

• Coût à grande échelle. Une boutique qui traite 200 commandes/jour avec cinq automatisations par commande génère environ 30 000 tâches/opérations par mois. Avec la facturation par tâche de Zapier, vous montez vite dans une offre élevée ; avec le modèle par opération de Make, c’est moins cher, mais un module natif s’achète une fois et ne coûte plus rien ensuite. Faites vos propres calculs avant de supposer que la plateforme est le choix économique.
• Traitements en temps réel. Tout ce dont le timing est l’enjeu principal. Relance de paniers abandonnés, alertes de stock qui doivent éviter une survente, signaux de fraude, se heurte à la latence d’interrogation décrite plus haut. Un module branché sur un hook gagne sans discussion.
• Le modèle de données de PrestaShop. Prix spécifiques, déclinaisons, règles panier, multiboutique, règles de taxes : tout cela est vraiment complexe. Un scénario externe qui doit les reconstruire à coups d’appels API devient fragile et pénible à maintenir ; un bon module natif peut utiliser directement le modèle et les services de PrestaShop au lieu de reconstituer ces règles à l’extérieur.
• Risque de dépendance. Chaque plateforme externe est un élément de plus susceptible de tomber en panne. Quand Zapier ou Make est indisponible, vos automatisations s’arrêtent avec lui. Le code qui tourne sur votre propre serveur, lui, continue.

Les tâches que nous éviterions de confier à une plateforme générique : l’e-mail marketing et les paniers abandonnés (un connecteur PrestaShop dédié pour Mailchimp, Brevo ou Klaviyo synchronise les segments, l’historique d’achat et tout le catalogue, et suit l’activité du panier en temps réel au lieu de subir une fenêtre d’interrogation), la comptabilité (la création de factures est bien plus propre avec une intégration conçue pour cela, nous détaillons les compromis dans connecter PrestaShop à votre logiciel de comptabilité), et la synchronisation sérieuse des stocks ou des commandes entre canaux et systèmes back-office, qui relève plutôt d’un ERP.

Ce dernier point mérite sa propre ligne, car c’est là que les boutiques vont le plus souvent trop loin avec Zapier : une prolifération de Scénarios qui tentent de garder stocks, commandes et clients synchronisés entre PrestaShop et un système back-office indique que vous avez dépassé le stade du simple collage et qu’il vous faut un vrai modèle d’intégration. Nous cartographions ces modèles dans connecter PrestaShop à votre ERP, ainsi que les signaux montrant que vous avez franchi cette limite dans quand votre boutique dépasse le travail manuel.

Où mypresta.rocks intervient

Nous développons des modules PrestaShop qui gèrent nativement les intégrations lourdes et critiques pour la boutique, sur votre serveur, sur un hook, sans compteur mensuel de tâches et sans aller-retour Internet entre un événement et sa réponse. Quel est donc l’impact concret ? Les tâches pénalisées par l’interrogation et la facturation par tâche, notifications de commande instantanées, synchronisation en temps réel des stocks et des canaux, timing des paniers abandonnés, connexions CRM et plateformes e-mail en profondeur, tournent plus vite et moins cher sous forme de code que vous possédez plutôt que d’opérations louées. Ce n’est pas un argument contre Zapier et Make ; c’est une répartition des rôles. Gardez les plateformes cloud pour les connexions vraiment personnalisées, à faible volume, vers des outils pour lesquels personne ne créera jamais de module, et déplacez les opérations à fort volume, sensibles au temps et conscientes de PrestaShop vers du natif. Pour les tâches planifiées qui restent sur votre serveur, un export nocturne, une synchronisation récurrente. Cron Manager donne à chaque tâche un enregistrement et une dernière exécution visible, afin qu’un traitement qui cesse silencieusement de se lancer se signale au lieu de passer inaperçu. Et si vos automatisations poussent le catalogue ou les segments vers une plateforme e-mail, un connecteur Mailchimp natif garde cette synchronisation sur un hook plutôt que sur une interrogation facturée. Les gains s’additionnent dans les deux sens : moins de dépenses en tâches facturées, moins de pièces mobiles susceptibles de tomber en panne, et des opérations qui réagissent au même instant que votre boutique.

Exploiter les automatisations sans se brûler les ailes

Quel que soit le côté de la ligne où tombe un flux de travail, quelques bonnes habitudes d’exploitation évitent que l’automatisation ne devienne un risque silencieux :

• Un flux de travail à la fois. Faites fonctionner de manière fiable un seul Zap ou Scénario sur des commandes de test avant de construire le suivant. Tester une automatisation directement sur des données de commande réelles est le meilleur moyen de découvrir une charge utile mal formée après son arrivée dans votre système comptable.
• Surveillez les échecs silencieux. Un Zap qui s’arrête discrètement est pire qu’un Zap qui casse bruyamment, les notifications de commande manquées et les SMS non envoyés ne s’annoncent pas. Consultez les journaux d’exécution chaque semaine et activez les alertes d’échec de la plateforme.
• Nommez et documentez tout. Au-delà d’une douzaine de flux de travail, "Copie du scénario 7" devient une urgence future. Utilisez les champs de description ; notez ce que chacun touche.
• Renouvelez et limitez vos clés. Faites tourner la clé Webservice selon un calendrier et gardez ses permissions de ressources limitées exactement à ce que l’automatisation lit ou écrit, n’accordez jamais toute l’API "au cas où".
• Envoyez les e-mails transactionnels via SMTP, pas via la plateforme. Si vos automatisations déclenchent des notifications, la fiabilité e-mail propre à votre boutique devient plus importante que jamais, commencez par fiabiliser l’envoi sous-jacent dans configuration e-mail PrestaShop : SMTP, Gmail et e-mails transactionnels.

Questions fréquentes

Existe-t-il une application PrestaShop officielle sur Zapier ou Make ?

Sur Make, il existe un connecteur PrestaShop natif, mais c’est l’application de Make, non maintenue par PrestaShop SA. Sur Zapier, il n’existe aucune application PrestaShop officielle ; vous passez par l’API Webservice intégrée et les étapes Webhooks génériques de Zapier. Cette différence est la principale raison pour laquelle Make est le choix par défaut le plus simple pour une boutique typique.

Pourquoi mon flux de travail "automatisé" n’est-il pas instantané ?

Parce que les déclencheurs basés sur l’interrogation vérifient à intervalle régulier au lieu de réagir au moment exact où quelque chose se produit, environ toutes les 1 à 15 minutes sur Zapier, et jusqu’à une fois par minute sur les offres payantes de Make. Pour une tâche de journalisation ou de notification, ce délai est invisible ; pour un travail critique en temps réel comme la relance de panier abandonné ou la prévention des surventes, il peut vous faire manquer la bonne fenêtre. Ces tâches doivent s’appuyer sur un hook PrestaShop (qui s’exécute instantanément) via un webhook ou un module natif, pas sur une interrogation.

Zapier ou Make pour une boutique PrestaShop ?

Make est le meilleur choix par défaut pour la plupart des boutiques, principalement grâce à son connecteur PrestaShop natif et à sa facturation par opération, moins coûteuse quand le volume augmente. Choisissez Zapier lorsque les autres applications de votre flux de travail ont un meilleur connecteur Zapier, ou lorsque vous voulez le chemin le plus court possible vers une automatisation fonctionnelle et que vous connectez de toute façon PrestaShop par un simple webhook.

Quand dois-je utiliser un module natif plutôt qu’une plateforme d’automatisation ?

Quand la tâche est à fort volume, sensible au temps ou profondément liée au modèle de données de PrestaShop, notifications de commande instantanées, synchronisation en temps réel des stocks/canaux, timing des paniers abandonnés, comptabilité et connexions CRM/plateformes e-mail. Un module natif tourne sur votre serveur, sans compteur par tâche et sans aller-retour Internet. Gardez Zapier et Make pour les connexions personnalisées à faible volume vers des outils de niche pour lesquels personne ne construira de module.

Comment protéger ma clé Webservice quand une plateforme cloud la détient ?

Limitez-la exactement aux ressources touchées par l’automatisation (n’accordez jamais toute l’API), servez toujours l’API via HTTPS, renouvelez la clé selon un calendrier et, si votre plateforme propose des IP sortantes statiques, placez-les sur liste blanche au niveau du serveur ou du pare-feu afin que seule votre automatisation puisse atteindre le point d’accès. Une clé strictement limitée signifie que l’impact d’une fuite se limite à ce que vous avez coché, pas à toute votre base de données.

Lectures complémentaires

• PrestaShop et Zapier sans écrire de code, le câblage pratique, recette par recette
• Connecter PrestaShop à votre logiciel de comptabilité. Pourquoi le grand livre fait partie des tâches à garder hors d’une plateforme générique
• Configuration e-mail dans PrestaShop, fiabilisez l’envoi transactionnel avant que vos automatisations ne s’appuient dessus

L’automatisation ne consiste pas à remplacer le jugement, elle sert à supprimer les minutes répétitives qui finissent par devenir des heures perdues. Zapier et Make sont les bons outils pour les extrémités personnalisées et à faible volume de ce travail ; les modules PrestaShop natifs sont les bons outils pour le cœur à fort volume et critique en temps réel. Savoir distinguer les deux, et connecter chacun correctement via le Webservice, un webhook ou un hook natif. Fait toute la différence entre une automatisation qui vous fait gagner du temps et un enchevêtrement de scénarios cloud qui devient une nouvelle chose à surveiller.