PrestaShop et Zapier : automatiser vos workflows sans écrire de code

Dernière vérification en juin 2026. Le répertoire de Zapier et la prise en charge JSON de PrestaShop évoluent avec le temps, vérifiez les deux pour votre version avant d’écarter une option. Chemins du back-office vérifiés avec PrestaShop 1.6, 1.7, 8.x et 9.x.

« Sans écrire de code » : c’est la promesse qui attire la plupart des marchands vers Zapier, et elle est globalement vraie, mais il y a un fait sur PrestaShop que personne ne vous dit d’emblée : au moment de la rédaction, il n’existe pas d’application maintenue par PrestaShop dans le répertoire de Zapier. Cherchez « PrestaShop » dans Zapier et vous ne trouverez pas le connecteur propre, façon Shopify, que vous attendiez (vérifiez le répertoire de Zapier pour connaître les éventuelles options tierces actuelles avant de les écarter). Cela ne signifie pas que la voie no-code est fermée, cela signifie que le chemin no-code direct passe généralement par l’API Webservice intégrée à PrestaShop et l’étape générique Webhooks de Zapier, avec les modules connecteurs tiers ou les middlewares comme autre possibilité. Savoir exactement comment ces deux pièces s’assemblent, c’est tout l’enjeu. Ce guide détaille le câblage no-code réel dans un vrai back-office PrestaShop, là où il ne demande effectivement aucune ligne de code, ainsi que les deux ou trois endroits où quelqu’un vous glisse discrètement un extrait et appelle tout de même cela du « no-code ».

Si vous êtes encore en train de décider quelle plateforme standardiser, ou si vous voulez une vue d’ensemble des opérations de boutique qui méritent d’être automatisées, commencez par notre article complémentaire, Zapier et Make pour PrestaShop, puis revenez ici pour la mécanique de connexion concrète.

Pourquoi il n’existe pas d’« application PrestaShop », et pourquoi ce n’est pas un problème

Les plateformes hébergées comme Shopify publient et maintiennent une application Zapier parce qu’une seule entreprise contrôle une seule base de code. PrestaShop est auto-hébergé et open source : votre boutique vit sur votre serveur, dans votre version (1.6, 1.7, 8.x, 9.x), avec vos modules. Il n’y a pas d’acteur central pour publier et certifier un connecteur unique couvrant tout cela. À la place d’une application de marque, PrestaShop expose donc une API Webservice, une interface REST standard intégrée au cœur, et Zapier lui parle comme il parlerait à n’importe quelle API personnalisée : via des étapes génériques Webhooks by Zapier. Une fois ce principe accepté, le problème de l’« absence d’application native » devient une configuration de quinze minutes, pas une impasse.

Étape 1, activer le Webservice (vraiment sans code)

C’est la base, et cela se fait uniquement en cliquant dans le back-office :

• Allez dans Paramètres avancés → Webservice (dans PrestaShop 1.6, l’option se trouve sous Paramètres avancés → Service web).
• Passez Activer le service web de PrestaShop sur Oui, puis enregistrez.
• Cliquez sur Ajouter une nouvelle clé webservice. PrestaShop génère une longue clé aléatoire, c’est l’identifiant que Zapier utilisera, traitez-le donc comme un mot de passe.
• Dans la grille des permissions, accordez uniquement les ressources dont vous avez réellement besoin. Pour lire les commandes, cochez orders (et généralement customers, addresses) sous View (GET). Pour réécrire des données, par exemple mettre à jour un stock, cochez stock_availables sous Modify (PUT). Laissez tout le reste désactivé.

Qu’est-ce que cela vous apporte ? Une clé limitée à une tâche précise, et rien d’autre. Si cette clé fuit un jour, le périmètre des dégâts correspond à ce que vous avez coché, pas à toute votre base de données. Un vrai piège qui surprend souvent sur les hébergements mutualisés ou anciens : le Webservice a besoin que la réécriture d’URL fonctionne. Si vous l’activez et que les appels renvoient 404, vérifiez que Paramètres de la boutique → Trafic & SEO → URL simplifiée est activé et que votre serveur réécrit bien les URL ; certaines configurations Apache nécessitent l’activation de mod_rewrite et la présence des règles de réécriture générées par PrestaShop dans .htaccess (les règles qui envoient /api vers le dispatcher du Webservice). C’est un réglage serveur, pas du code à écrire.

Étape 2, choisir le sens : de la boutique vers Zapier ou de Zapier vers la boutique

Toute automatisation fonctionne dans l’un de ces deux sens, et PrestaShop les gère très différemment. Bien comprendre cette distinction, c’est ce qui sépare une configuration fiable d’un système qui laisse silencieusement passer des commandes.

Étape 3, le sens déclencheur (là où le « temps réel » cache une subtilité)

Vous voulez un Zap qui se déclenche dès qu’une nouvelle commande arrive. Il existe deux façons honnêtes de le faire, avec des sensations très différentes à l’usage.

La méthode purement no-code : l’interrogation planifiée

Utilisez un déclencheur Schedule by Zapier (par exemple toutes les 15 minutes), suivi d’une étape Webhooks by Zapier → GET qui appelle votre endpoint de commandes :

• URL: https://yourstore.com/api/orders?display=full&sort=[id_DESC]&limit=5&output_format=JSON
• Authentification : Basic Auth, nom d’utilisateur = votre clé Webservice, mot de passe = laissé vide.

Le paramètre display=full compte autant que le reste de l’URL : sans lui, le Webservice ne renvoie que des références de ressources (une liste d’ID), pas les champs de commande que vous voulez mapper, vous devez donc soit ajouter display=full, soit faire une récupération en deux temps (lister les ID, puis faire un GET sur chaque commande par son id). Le paramètre output_format=JSON est l’autre élément clé, par défaut, le Webservice renvoie du XML, et la sortie JSON dépend de la prise en charge par votre version de PrestaShop ; confirmez donc que votre boutique l’honore réellement. Ce type d’interrogation exige aussi une logique de déduplication : stocker le dernier id ou la dernière date de commande vu, puis n’agir que sur les lignes plus récentes. Sinon, vous retraiterez les mêmes commandes à chaque exécution ou vous manquerez une rafale arrivée entre deux passages. Autre compromis : l’interrogation n’est pas instantanée (vous attendez jusqu’à la durée de votre intervalle) et elle consomme une tâche à chaque exécution, qu’il y ait une nouvelle commande ou non. Pour la plupart des petites et moyennes boutiques, c’est un prix raisonnable à payer pour se passer totalement de développeur. C’est la voie par laquelle nous vous recommandons de commencer.

La méthode en temps réel : un webhook envoyé par votre boutique

Si vous avez réellement besoin qu’une commande arrive dans Zapier à l’instant où elle est passée, la boutique doit pousser l’information. Le cœur de PrestaShop n’envoie pas de webhooks sortants tout seul : il faut donc installer un module de webhooks qui déclenche un POST HTTP sur des événements comme la création de commande (en s’accrochant en interne à actionValidateOrder ou actionOrderStatusPostUpdate) vers une URL Catch Hook fournie par Zapier. Bonne nouvelle : un module de webhook bien conçu se configure entièrement depuis le back-office, vous collez l’URL de réception Zapier dans un champ et vous choisissez les événements à envoyer. Aucun code. La réserve honnête : vous dépendez désormais d’un module qui doit rester compatible avec chaque version de PrestaShop et de PHP que vous utilisez, exactement le genre de casse-tête de compatibilité sur lequel nous nous acharnons pour que vous n’ayez pas à le faire.

Étape 4, le sens action (l’astérisque du « no-code »)

Écrire dans PrestaShop, c’est là que la promesse no-code gagne son astérisque. Le Webservice accepte les changements en XML, pas sous forme de champs de formulaire conviviaux comme ceux que Zapier affiche pour les applications natives. Pour mettre à jour le stock d’un produit, le bon enchaînement est le suivant : faire un GET sur la ligne stock_available exacte de ce produit (avec le bon id_product_attribute pour les déclinaisons et le bon contexte boutique en multiboutique), modifier la valeur <quantity>, puis renvoyer tout le bloc XML en PUT en conservant chaque champ obligatoire. C’est facile à corrompre : PUT remplace toute la ressource, donc un champ supprimé ou mal associé, l’id de déclinaison, l’id de boutique, une dépendance. Peut écrire le mauvais stock ou casser la ligne. Testez toujours cela sur une copie de préproduction avant de le pointer vers votre boutique en production. Dans une étape Webhooks by Zapier, vous collez un modèle XML et vous y insérez des champs mappés. Ce n’est pas de la programmation. Il n’y a ni boucles, ni variables, ni logique, mais c’est plus que déplacer des blocs, et un guide honnête doit le dire au lieu de faire croire que tout se résume à pointer et cliquer.

Le corps XML pour ce PUT de stock, avec les champs attendus par PrestaShop conservés, ressemble à ceci, notez que vous faites d’abord un GET de la ligne pour connaître les vrais ids, puis que vous ne modifiez que <quantity> :

<?xml version="1.0" encoding="UTF-8"?>
<prestashop xmlns:xlink="http://www.w3.org/1999/xlink">
  <stock_available>
    <id>42</id>
    <id_product>15</id_product>
    <id_product_attribute>0</id_product_attribute>
    <id_shop>1</id_shop>
    <id_shop_group>0</id_shop_group>
    <depends_on_stock>0</depends_on_stock>
    <out_of_stock>2</out_of_stock>
    <quantity>37</quantity>
  </stock_available>
</prestashop>

Et alors ? Pour les automatisations de lecture et de notification (nouvelle commande → Slack, nouveau client → tableur), vous n’aurez probablement jamais à toucher au XML. Pour les automatisations qui réécrivent dans la boutique (synchroniser le stock, changer un statut de commande, créer un client), prévoyez un après-midi pour obtenir la première charge utile correcte, ensuite, vous la copierez pour chaque Zap similaire.

Les options de connexion, classées de la moins intrusive à la plus technique

Les limites que Zapier ne vous signalera pas

L’automatisation no-code est le bon outil pour énormément de tâches, et le mauvais pour quelques autres. Connaître la limite avant de la heurter vous épargne une migration pénible plus tard :

• Volume. Zapier facture à la tâche. Une boutique qui traite 30 commandes par jour sur quatre automatisations reste dans une zone confortable ; une boutique qui en traite des milliers par jour verra la facture grimper vite, à ce stade, une intégration directe ou une intégration ERP lorsque votre boutique dépasse le travail manuel coûte moins cher par transaction.
• Synchronisation bidirectionnelle à gros volume. Maintenir les stocks, les prix et les commandes en accord permanent dans les deux sens entre PrestaShop et un autre gros système, ce n’est pas le rôle de Zapier, consultez les modèles qui tiennent vraiment la route dans les schémas d’intégration ERP qui fonctionnent.
• Précision comptable. Vous pouvez pousser des commandes vers un logiciel de comptabilité via Zapier, mais les règles de taxe, les avoirs et les remboursements deviennent vite délicats ; une passerelle dédiée est généralement plus saine, comme nous l’expliquons dans la connexion de PrestaShop à votre logiciel de comptabilité.
• E-mail transactionnel. Ne faites pas passer les confirmations de commande par un Zap, cela relève du système d’e-mails de PrestaShop, correctement configuré. Voir la configuration des e-mails dans PrestaShop.

Trois habitudes pour éviter que les automatisations no-code se retournent contre vous

• Limitez la clé, puis oubliez-la. Le plus gros gain de sécurité vient de la grille de permissions de l’étape 1, accordez le minimum, et une clé divulguée ne pourra presque rien faire.
• Testez d’abord avec une commande jetable. Passez une vraie commande de test et observez tout le Zap de bout en bout avant de lui faire confiance. Une automatisation silencieuse qui perd une commande sur trois est pire que pas d’automatisation du tout, parce que vous arrêtez de vérifier. (Si la confirmation d’une commande de test disparaît pendant que vous y êtes, c’est un problème de délivrabilité e-mail, pas un problème Zapier. Resend Order Confirmation vous permet de la renvoyer depuis la commande pendant que vous corrigez la cause.)
• Surveillez l’historique des tâches pendant une semaine. Zapier journalise chaque exécution ; un Zap qui réécrit dans PrestaShop et commence à échouer parce que PrestaShop a renvoyé une erreur XML peut rester là sans faire de bruit. Cinq minutes le lundi suffisent à le repérer.

Questions fréquentes

N’y a-t-il vraiment aucune application PrestaShop sur Zapier ?

Au moment de la rédaction, il n’existe aucune application maintenue par PrestaShop dans le répertoire de Zapier, parce que PrestaShop est auto-hébergé, avec de nombreuses versions et de nombreux modules, et qu’aucun acteur unique ne peut en publier et certifier une pour tout le monde. Vous vous connectez donc via l’API Webservice intégrée de PrestaShop et les étapes génériques Webhooks by Zapier. Vérifiez le répertoire pour les éventuels connecteurs tiers actuels avant de les écarter, mais la voie Webservice reste le chemin no-code le plus fiable.

Connecter PrestaShop à Zapier est-il vraiment « sans code » ?

Pour lire et notifier, nouvelle commande vers Slack, nouveau client vers un tableur, oui, tout se fait par clics : activer le Webservice, limiter une clé et interroger avec un GET Webhooks. Pour réécrire dans votre boutique (mettre à jour le stock, changer un statut de commande), vous rencontrerez un peu de XML, car le Webservice accepte les changements sous forme de corps XML plutôt que de champs de formulaire. Il n’y a ni boucles ni logique, mais c’est plus que déplacer des blocs, et mieux vaut le savoir avant de commencer.

Comment envoyer les commandes PrestaShop vers Zapier en temps réel ?

L’interrogation planifiée ne peut pas être vraiment instantanée, elle vérifie selon votre calendrier (par exemple toutes les 15 minutes). Pour du temps réel, la boutique doit pousser : un module de webhooks déclenche un POST HTTP à la création de commande (via le hook actionValidateOrder) vers une URL Zapier Catch Hook. Le cœur de PrestaShop n’a pas d’expéditeur de webhooks sortants, donc il faut un module, mais un bon module se configure entièrement depuis le back-office en collant l’URL de réception.

Pourquoi mon appel Webservice renvoie-t-il 404 ?

Presque toujours à cause de la réécriture d’URL. L’endpoint /api du Webservice dépend des URL simplifiées et des règles de réécriture dans le fichier .htaccess généré par PrestaShop. Vérifiez que Paramètres de la boutique → Trafic & SEO → URL simplifiée est activé et que votre serveur réécrit bien les URL (certaines configurations Apache nécessitent l’activation de mod_rewrite). C’est un réglage serveur, pas du code.

Pourquoi mon GET Webservice ne renvoie-t-il que des numéros d’ID au lieu des détails de commande ?

Il manque display=full. Sans lui, le Webservice renvoie une liste de références de ressources (seulement des ID), pas les champs que vous voulez mapper. Ajoutez &display=full à l’URL, ou faites une récupération en deux étapes, lister les ID, puis faire un GET de chaque commande par son id.

À lire aussi

• Zapier et Make pour PrestaShop, choisir et exploiter la plateforme, avec la comparaison Make vs Zapier
• Configuration des e-mails dans PrestaShop. Pourquoi les confirmations de commande doivent rester dans votre système d’e-mails, pas dans un Zap
• Quand votre boutique dépasse le travail manuel. Le signal qu’il est temps de passer du bricolage à une vraie intégration

Ce que vous devez retenir

La promesse « sans écrire de code » résiste au contact avec PrestaShop, avec une correction honnête : il n’existe pas d’application prête à brancher, vous passez donc par l’API Webservice et les étapes webhook génériques de Zapier. Pour lire les données de votre boutique et envoyer des notifications, cette voie se fait réellement par clics. Pour réécrire dans votre boutique, vous rencontrerez un peu de XML, et mieux vaut le savoir avant de le découvrir au milieu de la configuration. Commencez par une automatisation de lecture basée sur l’interrogation planifiée, validez-la avec une commande de test, puis ajoutez le reste progressivement. Quand le volume ou la complexité bidirectionnelle dépasse ce qu’un Zap peut porter proprement, c’est le signal qu’il faut passer à une intégration plus profonde, pas la preuve que vous vous êtes trompé sur la partie no-code.