Connecteur Odoo PrestaShop,ce que je décide avant de brancher

Vous vendez sur PrestaShop, votre stock et vos factures vivent dans Odoo, et quelqu'un recopie encore les commandes à la main. La première idée est d'acheter un connecteur Odoo PrestaShop sur la boutique d'applications et de le brancher dans l'après-midi. Ça peut marcher. Mais le module n'est pas le plus difficile. Le plus difficile, ce sont les décisions à prendre avant de l'installer, et qu'on oublie souvent de prendre.

J'ai piloté une intégration entre un ERP et un site marchand, et je construis des machines de contenu qui publient seules sur ce blog. Ce sont deux métiers où un logiciel agit sans qu'on le regarde, et où une erreur se répète en silence. Je ne suis pas intégrateur Odoo et je ne fais pas de refonte d'ERP. Ce qui suit, c'est ce que je décide et ce que je vérifie avant qu'un connecteur touche une vraie commande.

01Connecteur du marché ou développement sur mesure

Première question, souvent sautée : avez-vous besoin de deux logiciels ? Odoo a sa propre boutique, et sa documentation la présente comme une boutique en ligne open source moderne. Si votre site PrestaShop n'a ni modules spécifiques, ni thème travaillé, ni référencement à protéger, la question mérite d'être posée avant de payer pour faire parler deux outils.

Si les deux restent, il y a deux voies. Un module du marché couvre les flux courants (produits, stock, commandes, clients) et coûte peu à mettre en place. Un développement sur mesure ne fait que ce dont vous avez besoin, mais il faut quelqu'un pour le maintenir.

Mon critère est simple. Si vos règles métier rentrent dans les réglages d'un module (un entrepôt, une seule boutique, des taxes classiques), je prends le module. Si chaque réunion fait apparaître une exception, plusieurs entrepôts, des conditions de vente propres à chaque client, des produits composés, je commence par écrire la liste des flux et je ne choisis qu'après.

02Décider qui est maître de chaque donnée

C'est la décision qui évite le plus d'ennuis. Pour chaque donnée, un seul logiciel fait foi, et l'autre ne fait que recevoir. Quand les deux peuvent modifier la même chose, vous finissez avec une fiche modifiée dans PrestaShop et écrasée la nuit suivante par Odoo, sans que personne ne comprenne pourquoi.

Voici la répartition que je propose comme point de départ, à discuter avec l'équipe :

• les fiches produits, leurs conditions de vente et le stock partent d'Odoo vers PrestaShop ;
• les commandes et les clients partent de PrestaShop vers Odoo ;
• les statuts de commande (expédiée, annulée) et les numéros de suivi repartent d'Odoo vers PrestaShop ;
• les textes de vente, les images et le référencement restent dans PrestaShop, que l'ERP n'a pas à toucher.

Pour chaque flux, j'écris aussi la fréquence et ce que coûte un retard. Un stock en retard d'une heure peut vendre un produit qui n'existe plus. Une fiche produit en retard d'une nuit ne gêne personne. Tout cela tient dans un tableau d'une page, que je versionne : sur une intégration entre un ERP et un site marchand, la spécification a bougé presque à chaque réunion, et numéroter les versions était le seul moyen que tout le monde parle du même document. J'ai détaillé cette méthode dans ma façon d'écrire une spécification d'intégration.

03Ce que les API d'Odoo et de PrestaShop imposent

Un connecteur, même acheté, passe par les API des deux logiciels. Quelques contraintes de la documentation officielle changent la façon de concevoir les flux.

Côté Odoo

La première est commerciale : la documentation indique que l'accès aux données par l'API externe n'est disponible que sur les plans Custom, pas sur les plans One App Free ni Standard. À vérifier avant tout le reste.

La deuxième est technique. Avec la nouvelle API JSON-2, chaque appel s'exécute dans sa propre transaction, et la même page précise qu'on ne peut pas en enchaîner plusieurs dans une seule. Créer une commande puis ses lignes en deux appels, c'est risquer une commande à moitié créée si le second échoue. La documentation recommande d'appeler une seule méthode qui fait tout le travail.

La troisième concerne les accès. Les clés d'API ne peuvent pas durer plus de trois mois, et Odoo conseille un utilisateur robot dédié avec les droits minimum. Une clé qui expire en silence arrête la synchronisation : il faut que quelqu'un ait la date dans son agenda. Enfin, les anciennes API XML-RPC et JSON-RPC sont dépréciées, avec une suppression annoncée pour Odoo 22. Un connecteur qui repose encore dessus a une date de fin.

Odoo a consacré une conférence à ces changements, Odoo API 101 à l'Odoo Experience 2025, dont les chapitres couvrent les clés d'API, les transactions, les limites de débit et le versionnage. Je n'ai pas pu en lire la transcription, mais le découpage confirme que ces sujets font partie de toute intégration sérieuse.

Côté PrestaShop

Le webservice fonctionne avec une clé dont les droits se règlent ressource par ressource. La documentation recommande de la passer dans un en-tête d'autorisation plutôt que dans l'URL, et rappelle que depuis la version 8.1 le webservice sait répondre en JSON mais ne lit pas le JSON : les écritures restent en XML.

Le point qui piège le plus souvent, c'est le stock. PrestaShop le tient par produit, par déclinaison et, le cas échéant, par boutique. Chaque taille ou couleur d'Odoo doit donc correspondre exactement à une déclinaison de PrestaShop. Si la correspondance se fait sur un libellé plutôt que sur une référence stable, le premier renommage casse tout. C'est la même leçon qu'un mélange de centimètres et de millimètres entre deux outils : la donnée de référence doit être explicite.

04Vérifier un connecteur avant de l'installer

Je ne juge pas un module sur sa page de vente. Je le juge sur ce qu'il fait quand ça se passe mal. Voici ma liste, dans l'ordre où je la déroule.

Avant l'achat

1. Les versions couvertes : la vôtre d'Odoo, la vôtre de PrestaShop, et la date de la dernière mise à jour du module.
2. L'API utilisée côté Odoo : JSON-2 ou les anciennes API dépréciées.
3. Le sens de chaque flux, et la possibilité de couper un flux sans couper les autres.
4. La gestion des déclinaisons, des taxes et des plusieurs boutiques si vous en avez.

Sur un environnement de test

1. Importer deux fois la même commande, en coupant la connexion au milieu de la première. Une relance doit reprendre sans créer de doublon. C'est une règle que j'impose à mes propres pipelines de publication : chaque étape est journalisée, et relancer ne recrée rien.
2. Envoyer une commande avec une référence inconnue d'Odoo. Je veux une erreur visible et lisible, pas une commande qui disparaît.
3. Faire expirer la clé d'API. Le connecteur doit le dire, quelque part où quelqu'un regarde.
4. Comparer le stock affiché sur la fiche produit, vue comme un visiteur non connecté, avec le stock d'Odoo, sur une dizaine de références avec déclinaisons.

Le troisième point compte plus qu'il n'en a l'air. Dans mes machines de contenu, une vérification qui n'a pas tourné est un rouge, jamais un vert par défaut. Un connecteur muet pendant trois jours ressemble beaucoup à un connecteur qui marche, jusqu'au premier client qui appelle. Pour la recette complète, ma checklist de recette et de mise en production s'applique telle quelle.

05Ce qui casse après la mise en route

Le jour du lancement, tout a l'air de marcher. Ce sont les semaines suivantes qui révèlent les cas oubliés : une commande payée en plusieurs fois, un avoir, un produit supprimé dans PrestaShop mais encore actif dans Odoo. Je garde une liste de ces cas et je la transforme en jeu de tests.

C'est ce que j'ai fait chez Moonworkers, ma propre entreprise, pour un autre sujet : un oracle écrit à partir des textes officiels a rejoué plusieurs centaines de cas de cotisations et trouvé quatre erreurs d'un penny dues à une règle d'arrondi. Je raconte ce travail dans l'article sur les tests par oracle et sur la page Moonworkers. Pour un connecteur, l'équivalent est plus modeste : une vingtaine de commandes types, rejouées à chaque mise à jour du module ou d'Odoo.

Car les mises à jour arrivent. La documentation d'Odoo indique que chaque version majeure est supportée trois ans, et qu'une base avec des modules personnalisés ne peut pas être mise à niveau tant que ces modules n'existent pas pour la version cible. Votre connecteur fait partie de ces modules. Si son éditeur arrête de le suivre, c'est votre migration d'Odoo qui s'arrête.

Une limite honnête pour finir : tout ce travail de cadrage a un coût, et il n'est pas toujours justifié. Pour une petite boutique avec une centaine de références et un seul entrepôt, un module bien noté et une après-midi de tests suffisent souvent. Je ne sortirais pas la grosse artillerie pour ça.

06Par où commencer lundi

Prenez une feuille et faites trois colonnes : la donnée, le logiciel qui fait foi, la fréquence. Remplissez-la avec la personne qui prépare les commandes et celle qui fait la comptabilité, pas seulement avec la personne qui achètera le module. Vérifiez ensuite votre plan Odoo et vos versions. Puis demandez à l'éditeur du connecteur de vous montrer, sur un environnement de test, ce qui se passe quand la même commande arrive deux fois.

Si vous avez un projet de ce type et que vous voulez quelqu'un pour cadrer les flux et piloter les prestataires, mes services de direction de projet et de direction technique sont décrits sur le site. On peut en parler.