Connecteur ERP PrestaShop : synchroniser stocks, prix et commandes sans ressaisie

Un connecteur ERP PrestaShop relie la boutique au logiciel de gestion (l’ERP, le progiciel qui tient stocks, achats et facturation) par quatre flux : stocks et prix vers la boutique, commandes et statuts dans l’autre sens. Il se cadre flux par flux : qui possède la donnée, qui déclenche l’échange, que devient l’échange quand il échoue. Au 14 octobre 2026, le Webservice de PrestaShop 1.7, 8 et 9 en fournit le canal.

• L’API de PrestaShop fournit le canal d’un connecteur ERP
• Chaque donnée d’un connecteur ERP PrestaShop a un seul propriétaire
• Le déclencheur d’un échange décide de ce qui se perd en cas de panne
• Le coût d’un connecteur ERP PrestaShop varie avec le périmètre, pas avec la fréquence
• Cinq exigences cadrent le livrable d’un connecteur ERP
• Deux oublis faussent un connecteur ERP après la mise en service
• Sources consultées
• Foire aux questions

L’API de PrestaShop fournit le canal d’un connecteur ERP

Le Webservice est l’API de la boutique : une interface par laquelle un logiciel tiers lit et écrit des données au moyen de requêtes. La page « Resources » de la documentation développeur de PrestaShop 9 y range notamment les ressources products, combinations, stock_availables, orders, order_histories et customers. Il s’active dans Paramètres avancés > Service web (Advanced Parameters > Web service). Chaque application y reçoit sa propre clé, avec des droits réglés ressource par ressource.

La clé tient lieu d’identifiant, sans mot de passe : le guide « Getting started » de la version 9 recommande de la transmettre dans un en-tête HTTP, et le tutoriel de création d’accès conseille de ne pas donner tous les droits sur toutes les ressources à une même clé. Un flux de stocks n’a pas besoin de lire la ressource customers. La page française de la version 1.7 recommande de vérifier que le serveur accepte les connexions SSL, c’est-à-dire chiffrées.

Pour la 1.6, le prestataire contrôle le Webservice de votre boutique avant de chiffrer.

Chaque donnée d’un connecteur ERP PrestaShop a un seul propriétaire

Le propriétaire d’une donnée est le système dont la valeur l’emporte en cas de désaccord. Il s’écrit pour chaque donnée avant le premier développement.

D’après la FAQ « Stock » de la documentation de PrestaShop 9, la seule source fiable du stock est l’entité StockAvailable, la fiche de stock d’un produit ou d’une déclinaison. Les quantités « physique » et « réservée » y sont recalculées et se lisent seulement. Écrire directement la quantité disponible expose à écraser une modification survenue entre-temps ; la même FAQ décrit le mouvement de stock comme un delta, une variation appliquée au stock existant.

Scénario : l’ERP compte 12 pièces à 10 h 00. Une commande de 2 pièces arrive à 10 h 01. Le connecteur écrit 12 à 10 h 02, et la boutique propose deux pièces qu’elle n’a plus. Un connecteur qui envoie des variations, ou relit la quantité juste avant d’écrire, évite cet écart.

Quatre propriétaires à faire inscrire au cahier des charges :

• le stock : l’ERP quand un magasin ou une place de marché vend le même article, la boutique sinon ;
• le prix de base : l’ERP ; les prix spécifiques de la ressource specific_prices restent une couche à part, dont le contrat nomme le propriétaire ;
• la commande : la boutique la crée, l’ERP la reprend, et le statut (expédiée, facturée) revient dans la boutique ;
• la fiche produit (texte, images) : aucun des deux sans décision écrite ; ce sujet relève du PIM.

Décrire mon besoin →

Le déclencheur d’un échange décide de ce qui se perd en cas de panne

Deux mécanismes lancent un échange. Le premier est une lecture périodique : le connecteur interroge la ressource orders à intervalle régulier. Le tutoriel « Additional list parameters » décrit des filtres par intervalle (`filter[id]=[1,10]`), un tri et une limite ; il ne documente pas d’opérateur « supérieur à ». On en déduit que reprendre à la dernière commande traitée demande de borner la plage.

Le second est un hook, un point d’accroche où un module réagit à un événement de la boutique. La page « List of hooks » de PrestaShop 9 donne actionValidateOrder (« New orders »), actionOrderStatusPostUpdate (« Post update of order status ») et actionUpdateQuantity (« Quantity update »).

Un module qui appelle l’ERP au moment du hook, quand l’ERP est hors ligne, fait attendre le client ou perd l’événement. La conception à exiger : le module consigne l’événement dans une file d’attente, une liste enregistrée et traitée dans l’ordre, et un traitement séparé l’envoie.

Reprise sur erreur : chaque échange porte un identifiant, par exemple la référence de commande, pour qu’un rejeu ne crée pas de doublon ; une commande en échec reste visible dans un journal avec son message d’erreur.

Le coût d’un connecteur ERP PrestaShop varie avec le périmètre, pas avec la fréquence

Le prix se discute sans montant sur ses facteurs : le nombre de flux et leur sens, le nombre de références et de déclinaisons, les règles de prix à reproduire, la présence de plusieurs boutiques (le stock se règle alors par `id_shop` ou `id_shop_group`), l’existence d’une préproduction et la reprise d’un historique de commandes. L’interface de l’ERP est un facteur à demander au prestataire : API documentée ou échange de fichiers.

Un module d’éditeur et un développement sur mesure se comparent sur trois questions : la version de PrestaShop et celle de l’ERP prises en charge, la conduite en cas d’erreur, la mise à jour à chaque version mineure.

Cinq exigences cadrent le livrable d’un connecteur ERP

Le livrable comprend un schéma écrit des flux (sens, propriétaire, déclencheur, fréquence) et une clé du Webservice dédiée à ce connecteur. Il comprend aussi un journal des échanges que le marchand consulte, un essai sur une copie de la boutique avec des données de test, et une procédure de rattrapage : rejouer les commandes d’une plage donnée.

Au contrat s’ajoutent la remise de la documentation du connecteur et de son code, et la clause sur qui paie quand une synchronisation écrase des stocks. Cette clause se discute avec le contrat de maintenance.

Décrire mon besoin →

Deux oublis faussent un connecteur ERP après la mise en service

La fiche de stock d’une déclinaison est distincte de celle du produit : le produit associe des stock_availables par `id_product_attribute`. L’ERP voit une référence là où la boutique en voit plusieurs, et la correspondance passe par la référence ou le code EAN13, des champs de la ressource products. Un code absent ou en double casse le lien.

Le second oubli concerne les places de marché : leurs commandes entrent par un autre chemin que la boutique, et le stock s’y vend en parallèle. Leur raccordement fait l’objet d’une page à part, vendre sur les places de marché.

Dans le message du formulaire de cette page, reportez les flux voulus, votre version de PrestaShop et le nom de votre logiciel de gestion.

Sources consultées

• PrestaShop, documentation développeur de PrestaShop 9, « Webservice » et « Resources », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de PrestaShop 9, « Creating access » (tutoriel Webservice), consulté le 14 octobre 2026.
• PrestaShop, documentation développeur, « Getting started » du Webservice pour les versions 1.7, 8 et 9, consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de PrestaShop 9, « Additional list parameters », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de PrestaShop 9, « Stock », section « Sources of truth » et « Caveats », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de PrestaShop 9, « Create a product from start to finish with Webservices », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de PrestaShop 9, « List of hooks », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de PrestaShop 9, ressources « products » et « stock_availables », consulté le 14 octobre 2026.
• PrestaShop, documentation de la version 1.7 en français, « Paramètres du service web », consulté le 14 octobre 2026.

Foire aux questions

Une synchronisation en temps réel est-elle nécessaire ?

Pas pour tous les flux. Le stock d’un article vendu aussi en magasin demande un échange rapide, alors que les prix et les statuts de commande s’accommodent d’un passage planifié. La fréquence se fixe flux par flux, après le propriétaire de la donnée : un échange plus rapproché ne corrige pas une règle de propriété absente.

Que devient une commande si l’ERP est hors ligne ?

Avec une file d’attente, elle reste enregistrée et part au retour de l’ERP, dans l’ordre. Sans elle, l’événement peut se perdre ou retarder le client. Faites demander où l’événement est consigné et comment un responsable rejoue une plage de commandes.

Le module d’un éditeur ou un développement sur mesure ?

Un module convient quand ses versions prises en charge, ses flux et sa conduite en cas d’erreur recouvrent votre besoin. Le sur mesure se justifie pour une règle de prix ou un ERP que personne ne couvre. Dans les deux cas, demandez le journal des échanges et la mise à jour à chaque version.

Un connecteur ERP est-il possible sur PrestaShop 1.7 ?

Oui : la page « Getting started » du Webservice de la 1.7 le décrit. Elle ne prévoit pas la mise à jour partielle : une écriture renvoie la ressource entière par PUT. Pour une boutique en 1.7, le connecteur s’écrit autour de cette contrainte, et une migration vers 8 ou 9 la supprime.

Qui paie si le connecteur écrase les stocks ?

La règle se fixe au contrat, avant l’intervention. Faites écrire qui rétablit les quantités, dans quel délai, et si le prestataire a testé le flux en préproduction. Sans clause, la discussion s’ouvre après l’incident, sur un stock devenu faux.