Pourquoi vos modules natifs Shopify ↔ Odoo finissent toujours par casser

Tous les six mois, un client me contacte avec la même phrase : “On avait un module Shopify ↔ Odoo natif, ça marchait au début, et puis…”. Voici ce qui se passe, et pourquoi je n’utilise jamais ces modules en architecture cible.

Les promesses des modules natifs

Sur le papier, les modules officiels Odoo cochent toutes les cases : sync produits bidirectionnelle, commandes en temps réel, stocks, clients, paiements. Tout est dans la doc, tout est cliquable, tout est “supporté”.

Et pour 80 % des cas, ça suffit. Une boutique mono-site, < 5 000 SKU, peu de variantes, pas de marketplace : aucune raison d’investir dans du custom.

Là où ça casse

C’est dans les 20 % restants que la peinture craque :

1. Volumétrie

Au-delà de 10 000 SKU, la plupart des modules tombent en time-out sur les sync de stocks. L’API Shopify Admin a des rate limits stricts (2 req/s, leaky bucket à 40), et les modules natifs n’ont pas de logique de back-pressure. Résultat : sync qui plante, écrans rouges, équipe qui rebascule en manuel.

2. Multi-boutiques

Aucun module natif que j’ai vu ne tient correctement le multi-store Shopify Plus avec un Odoo central. Soit on duplique la conf trois fois (et on accumule la dette), soit on bricole avec des préfixes SKU (et on se tire une balle dans le pied au premier merge).

3. Variantes complexes

Une boutique avec des matrices de variantes (taille × couleur × matière) qui change saisonnièrement = catastrophe assurée. Les modules natifs gèrent les variantes Shopify et les variantes Odoo, mais pas leur évolution dans le temps.

4. Comptabilité

C’est souvent là que ça finit par exploser. Les écritures comptables générées par les modules natifs sont génériques, elles ne tiennent pas compte de la TVA spécifique (ventes UE, B2C / B2B, marketplaces avec commission), ne mappent pas correctement les comptes de produits, et ne rapprochent pas avec les paiements Shopify Payments.

Ce que je fais à la place

Trois principes :

1. Odoo = source of truth produit et stock, toujours. Shopify n’écrit jamais le master ; il consomme.
2. Connecteur custom (Oodify dans mon cas), avec une queue de sync différée, du back-pressure, du retry idempotent, et un référentiel d’erreurs visible.
3. Comptabilité explicite : mapping TVA / compte / journal défini une fois, jamais générique.

Quand garder le natif

Si vous êtes en mono-store Shopify, < 5 000 SKU, sans marketplace, sans complexité comptable particulière : gardez le natif. C’est gratuit, c’est maintenu, c’est largement suffisant.

Si vous cochez ne serait-ce qu’une des cases ci-dessus (multi-store, > 10K SKU, marketplaces, comptabilité spécifique), prévoyez le custom dès le départ. C’est cher au démarrage, mais infiniment moins cher que de migrer en urgence dans deux ans.