Connecteur · PrestaShop
Connecteur Odoo ↔ PrestaShop
Le webservice PrestaShop fonctionne bien — à condition de connaître ses trois pièges silencieux, qui renvoient tous une erreur d'authentification alors que la clé est bonne.
/api/<ressource>Le webservice de PrestaShop est ancien, stable et bien documenté. Il a un défaut : ses messages d’erreur mentent. Trois problèmes de configuration très différents produisent tous la même réponse — un 401 — et l’intégrateur qui ne les connaît pas passe une journée à régénérer des clés qui étaient bonnes depuis le début.
Ce que le webservice expose
Toutes les ressources du cœur : products, combinations, stock_availables, orders, order_histories, customers, addresses, carriers, categories, product_options. Chaque ressource s’active par méthode — GET, POST, PUT, DELETE — dans les permissions de la clé.
C’est un point à ne pas sous-estimer : une permission oubliée ne se voit qu’à l’exécution, sur le premier flux qui en a besoin, souvent des semaines après la mise en production. Nous grantons l’union de ce que le code consomme réellement, et nous la documentons.
Les trois pièges qui font perdre une journée
www compris. Pire, il reconstruit mal l'URL de redirection. Le client HTTP suit le redirect, la clé n'est plus transmise, et vous recevez un 401. Le diagnostic : lire le domaine canonique dans la table des URL de boutique et le comparer, caractère par caractère, à l'URL configurée.Aucun de ces trois cas ne se devine. Tous coûtent une demi-journée à qui les découvre.
Les versions : ce qui change
| Version | Points d’attention |
|---|---|
| 1.6 | Fin de vie. PHP ancien, webservice fonctionnel, mais tout le reste est un risque. |
| 1.7 | Charnière : structure produit et thèmes revus. Beaucoup de sites y sont encore. |
| 8.x | Stable, bon compromis. Base de la majorité de nos intégrations. |
| 9.x | Plus récent. Certaines méthodes historiques ont disparu ; les scripts d’intégration écrits pour la 1.7 ne s’exécutent pas tels quels. |
La question à poser avant de chiffrer n’est jamais « c’est du PrestaShop ? » mais « c’est quelle version, avec quels modules ? ».
Le stock : la ressource qui compte
stock_availables est le point d’entrée pour pousser les quantités. Une déclinaison a sa propre ligne de stock, distincte de celle du produit parent.
Deux règles que nous appliquons systématiquement :
- Odoo fait autorité sur le stock, PrestaShop reçoit. Le stock physique est dans l’entrepôt.
- On ne pousse que les écarts. Balayer 20 000 déclinaisons toutes les dix minutes pour en modifier trois est le meilleur moyen de mettre le site à genoux — et il n’y a aucune limite de débit pour vous en empêcher.
Ce que nous livrons
- Le connecteur dans un module Odoo distinct, versionné chez vous.
- La configuration du webservice documentée : clé, permissions accordées ressource par ressource, association boutique.
- Polling avec fenêtre de rattrapage, ou module de notification côté PrestaShop si la réactivité l’exige.
- Idempotence sur la référence de commande : rejouer un lot ne crée pas de doublon.
- Le mapping des déclinaisons et des axes, écrit.
Les limites, dites franchement
Pas de webhook natif. La réactivité se paie soit en fréquence de polling, soit en module à maintenir côté boutique. Nous préférons souvent le polling : moins élégant, beaucoup moins fragile.
Les modules tiers réécrivent le comportement. Un module de prix, de TVA ou de gestion des statuts peut modifier ce que l’API renvoie. Sur une boutique chargée en modules, l’audit préalable n’est pas une formalité.
Le multiboutique double la complexité. Stocks, prix et catalogues par boutique : ce n’est pas une case à cocher, c’est un modèle à décider.
Pour la comparaison des flux et des arbitrages d’autorité, voir WooCommerce. Si votre boutique alimente aussi des places de marché, voir marketplaces.
Questions fréquentes
Pourquoi mon webservice renvoie 401 alors que la clé est correcte ?
Dans la majorité des cas, ce n’est pas un problème d’authentification. PrestaShop redirige en 302 toute requête /api/... qui n’arrive pas sur le domaine canonique déclaré — www compris — et reconstruit mal l’URL de redirection. Le client suit le redirect et tombe sur un 401. Vérifiez que l’URL d’API correspond exactement au domaine canonique de la table shop_url.
Qu'est-ce que l'erreur 132 « No permission for this key on this shop » ?
Même en mono-boutique, un compte de webservice doit être associé au magasin. Si l’association manque, toutes les requêtes échouent alors que les permissions par ressource sont correctes. C’est une ligne à ajouter dans la table de liaison compte-boutique.
PrestaShop a-t-il des webhooks ?
Non, rien de natif. Deux options : interroger périodiquement les commandes depuis Odoo — simple et suffisant dans la plupart des cas — ou déployer un petit module côté PrestaShop qui pousse un événement à la validation de commande. La seconde option donne la réactivité, au prix d’un module à maintenir.
Le connecteur gère-t-il les déclinaisons ?
Oui. Une déclinaison PrestaShop correspond à une variante Odoo, avec sa propre référence, son stock et son prix. Le mapping des axes — taille, couleur — doit être décidé au cadrage : c’est là que les catalogues explosent quand les axes sont mal posés.
Et le multiboutique ?
Il est géré, mais il change tout : la clé doit être associée à chaque boutique, les stocks et les prix peuvent différer par boutique, et il faut décider si Odoo voit une seule entité ou plusieurs. C’est une conversation de cadrage, pas un paramètre.
Un point technique à valider ?
Décrivez le contexte : version d'Odoo, systèmes en jeu, volumétrie. Réponse d'un intégrateur sous 24 h ouvrées.