Marketplaces de bricolage allemandes dans Odoo : données produit, colis lourds et retours de matériel

Commençons par l'essentiel : nous n'avons pas de connecteur publié pour OBI ni pour Hornbach. Aucun des deux n'est dans notre catalogue de modules et nous n'allons pas prétendre le contraire pour que vous continuiez à lire. Si vous vendez sur des marketplaces de bricolage allemandes et que vous voulez que les commandes arrivent seules dans Odoo, c'est aujourd'hui du développement sur-mesure. Ce que nous pouvons vous expliquer, c'est ce que ce secteur a de particulier, car ce n'est pas une marketplace de mode avec un autre logo : les données produit changent, le transport change et les retours changent.

Ce qui existe déjà et ce qu'il faut construire

Dans le bricolage, nous avons bien des connecteurs publiés : ManoMano et les opérateurs qui fonctionnent sur Mirakl, comme Leroy Merlin, Brico Dépôt, Decathlon ou GACD. Si l'opérateur qui vous intéresse tourne sur Mirakl, le travail est fait et il suffit de le configurer. OBI et Hornbach ne figurent pas sur cette liste. Là, il faut écrire l'intégration contre leur API, et cela se chiffre comme une intégration sur-mesure, pas comme une licence de module. La première chose que nous demandons dans ces cas, c'est leur documentation d'API et un accès de test : sans cela, tout délai qu'on vous donne est inventé.

La fiche produit d'un Baumarkt est la plus exigeante que vous aurez à remplir

Une perceuse ne se vend pas avec deux photos et un titre. Il faut fournir le poids et les dimensions réels du colis, le matériau, la puissance ou la tension, et dans beaucoup de familles un document joint : fiche de données de sécurité pour les peintures, solvants et adhésifs ; étiquette énergétique pour l'éclairage et la climatisation ; classe de réaction au feu pour les isolants. L'EAN est souvent exigé par variante, pas par produit, et la variante en bricolage est longue : dimension, finition, quantité par boîte. Tout cela doit vivre dans Odoo sous forme de champs du produit, pas dans un tableur que quelqu'un met à jour à la main, parce que la marketplace rejette la fiche incomplète et que le rejet arrive par lot. Le même travail, raconté avec Amazon, se trouve dans synchroniser les données produit.

Des colis qui ne rentrent pas dans un paquet

Sacs de mortier, portes, sanitaires, panneaux : une bonne partie du catalogue d'un Baumarkt relève du Sperrgut et voyage par transporteur de fret, pas par messagerie colis. Cela casse trois choses dans une intégration classique. Le tarif, car le prix ne découle pas du poids mais du poids volumétrique, de la longueur maximale et parfois de la nécessité de monter la marchandise à l'étage. Le suivi, car une expédition par transporteur de fret ne donne pas d'événements toutes les heures : elle donne un rendez-vous de livraison, et si votre bon de livraison attend un numéro de suivi avec des événements, il reste vide. Et le colisage, car une commande peut partir sur quatre palettes et la marketplace veut le savoir avant la livraison. Dans Odoo, cela se modélise avec des colis par bon de livraison et un transporteur choisi par règle de poids et de volume ; l'approche est décrite dans intégration logistique.

Retourner du matériel n'est pas retourner un T-shirt

Le matériel découpé sur mesure ne revient pas. Le sac ouvert non plus. Le sanitaire cassé revient, mais le retour est géré par le transporteur et peut coûter plus cher que le produit. Une intégration de bricolage doit accepter les retours partiels par quantité, cinq carreaux sur vingt, distinguer le motif (défaut, dommage de transport, rétractation) parce que chacun décide qui paie, et ne pas émettre l'avoir avant que quelqu'un ait regardé ce qui est arrivé. Si le connecteur rembourse tout seul dès que la marketplace prévient, la marge s'en va sans que personne ne le voie et on le découvre à la clôture du trimestre.

Ce qui se réutilise d'un connecteur à l'autre

La bonne nouvelle, quand il n'existe pas de connecteur, c'est que la partie coûteuse est déjà résolue dans d'autres. L'identifiant de commande que l'on vérifie avant de créer quoi que ce soit, la table d'équivalence entre le SKU de l'opérateur et le vôtre, la répartition du stock entre canaux, la position fiscale par pays de destination et la facturation sont identiques chez OBI, chez Hornbach et chez n'importe quel autre. Ce qui est propre à chaque opérateur, c'est son API, son format de catalogue et sa machine à états de commande. Dans un vrai projet, cette distinction fait la différence entre des semaines et des mois. Et si vous vendez la même chose à plusieurs endroits, la répartition du stock est le problème de plusieurs marketplaces dans un seul Odoo, pas un problème d'OBI.

Quand vous ne devriez pas nous engager

Si vous avez deux cents références et cinq commandes par semaine chez un seul opérateur, une intégration sur-mesure n'est pas rentable. Un CSV et vingt minutes par jour coûtent moins cher que n'importe quel développement, et vous laissent en plus changer de canal sans avoir rien investi. La conversation change quand des commandes arrivent tous les jours, quand vous vendez la même chose à trois endroits et tombez en rupture sur le pire, ou quand le rapprochement de fin de mois occupe une personne à temps plein. Là, le développement se rentabilise tout seul. Avant, non, et nous préférons vous le dire plutôt que de vous facturer un projet dont vous n'avez pas besoin.

Questions fréquentes

Liens utiles chez FlexigoTech