Connecter PrestaShop à Odoo : retour d’expérience sur les subtilités d’un ERP en pleine croissance

Le contexte : un ERP incontournable, mais pas comme les autres

Odoo s’est imposé ces dernières années comme l’un des ERP les plus utilisés par les PME et ETI, en France comme à l’international. Sa modularité, son coût d’entrée maîtrisé et l’étendue de son écosystème d’applications en font un choix naturel pour de nombreuses sociétés en croissance qui cherchent à structurer leur gestion commerciale. Mécaniquement, le nombre de projets de connexion entre un Odoo et une boutique PrestaShop augmente lui aussi chez nos clients, qu’il s’agisse d’une première mise en place ou d’une migration depuis un ancien ERP.

Chez Ether Création, nous connectons PrestaShop à plus de 30 ERP différents — Sage, Divalto, Ginkoia, Fastmag, EBP, Cegid, Odoo, et bien d’autres. Cette exposition permanente à des modèles de données très différents nous a appris une chose : chaque ERP a sa propre logique, et la copier-coller d’un connecteur d’un système à l’autre est le plus sûr moyen de perdre des ventes ou de fausser des stocks. Odoo ne fait pas exception. Brancher un ERP sur un site e-commerce n’est jamais un long fleuve tranquille, mais Odoo a ses spécificités propres, qui demandent une compréhension fine de son modèle de données avant même d’écrire la première ligne de flux.

Voici, points par points, les sujets qui nous ont demandé le plus d’attention sur nos projets de connecteurs Odoo — et comment notre expérience sur d’autres ERP nous aide à les anticiper.

Le produit et ses variantes : une notion à retourner

Dans Odoo, l’unité de vente réelle est la variante, rattachée à un modèle de produit qui joue le rôle de fiche générique. Contrairement à d’autres ERP où le produit parent porte sa propre référence et où les déclinaisons en héritent — c’est le cas de la plupart des ERP que nous connectons habituellement — le modèle Odoo ne donne par défaut aucune référence au parent : seules les variantes en possèdent une.

Pour construire un catalogue e-commerce classique avec une fiche produit parent — nécessaire dès qu’une boutique gère des déclinaisons — il faut donc reconstruire artificiellement cette référence parent à partir des références de variantes, en s’appuyant par exemple sur les attributs communs comme la couleur. Ce n’est pas une difficulté insurmontable, mais c’est un choix structurant à faire dès le départ, d’autant plus s’il faut migrer un historique de références provenant d’un ancien système : la logique de recalcul doit composer avec l’existant pour préserver un maximum de continuité (référencement, historique de commandes, habitudes internes des équipes).

Deux autres pièges rencontrés sur nos projets :

• Attributs invisibles sur les mono-variantes. Quand un produit n’a qu’une seule variante, Odoo ne remonte pas systématiquement ses attributs dans l’interface qui leur est dédiée. Pourtant, côté boutique, il est souvent nécessaire de les retrouver sur la fiche produit ou la déclinaison PrestaShop, ne serait-ce que pour l’affichage ou le filtrage — un connecteur bien conçu doit donc aller chercher l’information à la source plutôt que de se fier à l’interface pensée pour l’utilisateur Odoo.
• Une seule image par article. Odoo ne permet nativement qu’une seule image par article. Pour une boutique qui veut présenter plusieurs vues d’un même produit ou de chaque déclinaison, la question se pose vite de recourir à une source complémentaire (PIM, espace de stockage partagé, DAM). C’est une problématique de connexion multi-sources que nous retrouvons régulièrement sur nos projets de PIM et middleware, indépendamment de l’ERP en place.

Prix HT, prix TTC et listes de prix

Odoo raisonne nativement en prix TTC au niveau de la variante : c’est cette valeur qui reflète le prix réellement facturé. Le prix affiché au niveau du produit parent n’est qu’une valeur de référence, identique pour toutes les variantes, à ne surtout pas confondre avec le prix unitaire réel.

Calculer le prix hors taxes suppose donc de connaître précisément la taxe appliquée à chaque produit, et de la retrouver de façon fiable plutôt que de la coder en dur — un pays, un taux de TVA différent, et le calcul doit rester juste sans intervention manuelle. C’est un point sur lequel nous sommes particulièrement vigilants : sur plusieurs ERP que nous intégrons, la tentation de figer un taux « par défaut » côté connecteur revient régulièrement, et c’est systématiquement une source de litiges commerciaux à moyen terme.

Les listes de prix (pricelists) permettent de gérer plusieurs grilles tarifaires, éventuellement affectées par client — un mécanisme flexible qui peut couvrir aussi bien un site B2C avec un tarif unique qu’un contexte B2B avec des conditions différenciées par compte. Sur nos projets B2B, nous rapprochons généralement ce mécanisme de nos développements de groupes clients et de comptes professionnels multi-utilisateurs (voir notre article sur la gestion de comptes pro), pour que la tarification différenciée Odoo se retrouve fidèlement côté boutique, jusqu’au niveau du collaborateur qui commande.

Des promotions à plusieurs visages

Les opérations commerciales dans Odoo s’appuient sur le module de fidélité, initialement pensé pour des programmes de points ou de coupons, mais couramment détourné pour piloter de simples remises catalogue. Une même installation peut faire coexister plusieurs mécanismes de ciblage des produits concernés par une règle :

Un connecteur qui prétend gérer les promotions Odoo doit être capable d’interpréter chacun de ces cas de figure, et pas seulement le plus simple d’entre eux, sous peine de laisser passer des opérations commerciales pourtant bien actives côté ERP. C’est typiquement le genre de règle métier qu’on ne découvre pas en lisant la documentation, mais en confrontant le connecteur à l’usage réel que le client fait de son ERP — d’où l’importance, sur chacun de nos projets, d’un échange approfondi avec les équipes commerciales avant de figer les règles de synchronisation.

Des étiquettes de produit peuvent également porter, indépendamment des promotions, une logique de groupe métier (fin de série, second choix, nouveauté…) qui pilote elle-même des remises fixes ou des règles d’import spécifiques — encore une couche à démêler pour restituer fidèlement l’intention commerciale sur la boutique.

Le stock, entre entrepôts multiples et unités particulières

Odoo distingue la quantité physique en stock de la quantité déjà réservée par des commandes en cours : c’est la différence entre les deux qui représente le disponible réel à afficher sur la boutique. Pour une société travaillant avec plusieurs entrepôts, il faut aussi décider quels emplacements de stockage entrent dans le calcul (stock de vente, en transit, retour…), au risque de survendre ou, à l’inverse, de bloquer artificiellement des ventes possibles. Cette question du périmètre d’entrepôts pris en compte revient sur la quasi-totalité de nos connecteurs ERP, quel que soit l’éditeur, mais chaque système la modélise différemment — chez Odoo, elle passe par les emplacements de stock plutôt que par un simple champ « quantité disponible ».

Certains catalogues comportent également des articles vendus dans une unité de mesure continue, au mètre par exemple : le stock doit alors être raisonné dans une unité plus fine — le centimètre — pour rester précis, tandis que le prix, l’unité affichée et la quantité minimale de vente doivent être adaptés en conséquence côté boutique.

Les commandes : au-delà du simple ajout de lignes

Transmettre une commande à Odoo ne se limite pas à recréer les lignes de produits vendus.

Les frais de port doivent être traduits fidèlement : chaque transporteur et chaque zone de livraison PrestaShop peuvent correspondre à un article de livraison différent côté Odoo, avec un tarif propre. Cette table de correspondance mérite d’être établie transporteur par transporteur, zone par zone, en vérifiant les rattachements réels en base plutôt qu’en se fiant à des libellés qui peuvent recouvrir des réalités différentes une fois le détail vérifié.

Les remises panier (remise globale, livraison offerte…) demandent elles aussi un traitement particulier : elles doivent apparaître comme des lignes de commande dédiées, isolées du prix produit et de la part transport, pour éviter tout double comptage entre le montant réellement payé par le client et celui transmis à l’ERP.

Les adresses de facturation et de livraison posent un dernier piège classique : quand une commande est liée à des adresses distinctes, s’appuyer sur un identifiant technique stable et propre au connecteur, plutôt que sur un champ natif de la boutique dont l’usage peut diverger d’un cas à l’autre, évite des rapprochements hasardeux entre les fiches contact de l’ERP et les clients de la boutique. C’est un piège d’autant plus sournois qu’il ne se révèle qu’au moment où deux comptes distincts se retrouvent mélangés — un scénario que nous avons déjà dû corriger a posteriori sur plusieurs connecteurs, Odoo ou non, et que nous verrouillons désormais systématiquement dès la conception.

Les clients, un rapprochement par l’e-mail

Là où beaucoup d’ERP raisonnent par identifiant interne ou par code client, la fiche contact Odoo est le plus souvent rapprochée d’un client e-commerce par son adresse e-mail — un pivot naturel côté B2C, mais qui suppose une hygiène de données rigoureuse (unicité, normalisation) pour éviter les faux rapprochements.

Les étiquettes ou informations complémentaires poussées vers la fiche contact (préférences, consentement, tags marketing…) doivent s’ajouter à ce qui existe déjà côté ERP sans jamais effacer les informations saisies par ailleurs : deux systèmes qui s’alimentent mutuellement doivent rester prudents l’un envers l’autre. C’est un principe que nous appliquons à l’ensemble de nos connecteurs bidirectionnels, quel que soit l’ERP : la synchronisation ne doit jamais devenir un écrasement silencieux.

Ce que notre expérience multi-ERP change concrètement

Développer des connecteurs pour plus de 30 ERP différents nous a appris que les vraies difficultés d’une intégration ne sont presque jamais dans la technique brute (appeler une API, écrire une requête SQL), mais dans la traduction fidèle d’un modèle métier vers un autre :

• Anticiper plutôt que découvrir en production. Savoir, avant même de démarrer un projet Odoo, que la référence parent n’existe pas nativement, que les remises passent par le module de fidélité, ou que le stock disponible se calcule et ne se lit pas directement, nous évite des allers-retours coûteux avec le client.
• Réutiliser une architecture éprouvée. Nos connecteurs, quel que soit l’ERP cible, s’appuient sur les mêmes briques génériques (mapping de références, gestion des taxes, table de correspondance transporteurs/zones, réconciliation clients) — seule la couche d’adaptation au modèle de données de l’ERP change. Cela nous permet de livrer plus vite et avec moins de régressions.
• Dialoguer avec les équipes métier, pas seulement avec la documentation technique. La bonne interprétation d’une règle de promotion ou d’un mécanisme de stock ne se trouve pas toujours dans la doc de l’éditeur, mais dans l’usage réel qu’en font les équipes commerciales et logistiques du client.

Conclusion

Odoo n’échappe pas à la règle qui vaut pour tout ERP connecté à un site e-commerce : la donnée brute ne suffit jamais, il faut la comprendre pour la transformer fidèlement. Son modèle très orienté variante, sa gestion des prix et son module de fidélité détourné en moteur de promotions imposent des choix techniques spécifiques, différents de ceux qu’on retrouverait avec un ERP plus classique comme Sage, Divalto ou Cegid.

C’est précisément ce travail d’interprétation minutieuse — comprendre le modèle de données, dialoguer avec les équipes métier pour lever les ambiguïtés, et sécuriser chaque rapprochement entre les deux systèmes — qui fait la différence entre un import de données qui fonctionne en apparence et une synchronisation réellement fiable au quotidien.

Chez Ether Création, la connexion d’ERP à PrestaShop est au cœur de notre métier depuis plus de 15 ans, sur plus de 30 systèmes différents. Que vous démarriez un projet Odoo ou que vous cherchiez à fiabiliser un connecteur existant, contactez-nous pour en discuter.