Connecteur Shopify ↔ Odoo sur mesure.

Comment sait-on que son connecteur dérive ?

Rarement par une alerte. Presque toujours par un symptôme métier, découvert des semaines après la cause. Les signes qui reviennent :

• Le stock Odoo ne correspond plus au stock physique, et personne ne sait depuis quand.
• Des commandes qui n'arrivent jamais dans l'ERP, ou qui y arrivent en double.
• Un chiffre d'affaires qui n'est pas comptabilisé parce que les écritures ne se génèrent plus.
• Des alertes d'anomalie par milliers, que plus personne ne lit · le bruit a tué le signal.
• Une clôture comptable qui prend deux semaines parce que le rapprochement est manuel.
• Des webhooks tombés dont l'échec n'a déclenché aucune alerte.

Le point commun de ces situations : le connecteur ne dit pas qu'il va mal. Un connecteur sérieux doit être observable : journaux structurés, file d'échecs, alertes sur écart, et réconciliation périodique qui compare les deux systèmes ligne à ligne.

Pourquoi les modules du marché cassent

Le mur des quotas d'API

L'API Admin de Shopify fonctionne en seau à jetons : un budget de coût par requête qui se régénère à débit fixe. Un module générique qui traite les enregistrements un par un consomme son budget en quelques secondes, se fait limiter, et se met à réessayer · ce qui aggrave la saturation. La parade tient en trois techniques : le traitement par lots en GraphQL, un limiteur à seau percé côté client qui respecte le débit annoncé par l'API, et des réessais avec délai aléatoire pour éviter que tous les workers repartent en même temps. Sur une base de 30 000 clients, passer d'une résolution unitaire à un traitement par lots de 50 fait tomber un traitement de plus de quatre heures à une quinzaine de minutes. Les patterns GraphQL Admin en détail.

La caisse, angle mort du marché

C'est la limite la plus structurante et la moins documentée : les connecteurs du marché récupèrent les commandes Shopify POS comme des commandes web. Ils ne créent pas de véritable session de caisse Odoo, avec son fond de caisse, ses moyens de paiement, sa clôture et son écriture de trésorerie. Résultat : le retail est réconcilié à la main tous les soirs. Gérer correctement le POS suppose de suivre les sessions de caisse Shopify, de les faire correspondre aux sessions Odoo, et de générer les écritures qui vont avec. Architecture Shopify POS ↔ Odoo.

La synchronisation bidirectionnelle

Autoriser l'écriture dans les deux sens semble pratique. C'est la garantie d'une divergence. Sans propriétaire désigné par champ, deux modifications concurrentes créent un conflit que personne n'arbitre, et l'écart s'installe. La règle qui tient dans le temps : un champ, un propriétaire, écrit noir sur blanc dans la spécification. Comment tenir un référentiel produit unique.

Le coût réel d'une licence

Un module sous licence se paie à l'achat, puis à nouveau à chaque version majeure d'Odoo, plus l'abonnement de support. Mais le coût visible n'est pas le problème : le vrai coût, c'est le temps passé à contourner ce que le module ne sait pas faire, et la dépendance au calendrier de son éditeur quand une API change. Pourquoi les modules natifs finissent par casser.

Oodify : le connecteur que je développe et maintiens

Oodify est né d'un constat simple : sur les architectures qui mêlent e-commerce, retail et comptabilité française, aucun module du marché ne tenait. C'est aujourd'hui un module Odoo en production, pas un prototype.

Ce qu'il fait, concrètement :

1. Stock et prix descendants. Odoo pousse le stock disponible par canal et par entrepôt vers Shopify, avec les règles d'allocation et la déduplication des événements.
2. Commandes ascendantes. Chaque commande Shopify · vitrine comme point de vente · est récupérée par webhook signé en HMAC, rejouée en GraphQL en cas d'échec, puis transformée en commande Odoo avec son écriture comptable.
3. Caisse retail. Les sessions de caisse Shopify POS deviennent de vraies sessions Odoo : fond de caisse, moyens de paiement, clôture, écriture de trésorerie.
4. Référentiel produit miroir. Odoo reste propriétaire du produit ; l'écriture inverse est bloquée par conception, ce qui rend la divergence structurellement impossible.
5. Réconciliation et observabilité. Des audits périodiques comparent les deux systèmes et remontent les écarts réels · pas des milliers de faux positifs.

Oodify a trois déclinaisons, toutes nées de besoins clients : la synchronisation e-commerce et caisse, un PLM pour les marques de mode qui gèrent des collections et des certifications, et un module d'inventaire au scan depuis un téléphone connecté à Odoo, avec lecture de codes-barres EAN et GS1.

L'architecture qui tient

• Odoo est la source de vérité du produit, du stock, du prix d'achat et de la comptabilité. Shopify est un canal.
• Événementiel d'abord, réconciliation ensuite. Les webhooks portent le temps réel ; des tâches planifiées rattrapent ce qui a été perdu. Les deux sont nécessaires · les webhooks tombent.
• Idempotence partout. Chaque opération critique est rejouable sans effet de bord. C'est ce qui permet de relancer un traitement sans crainte.
• File d'échecs. Un message qui échoue trois fois va dans une file dédiée, il ne disparaît pas.
• Migrations versionnées et tests. Chaque changement de schéma a son script ; chaque comportement critique a son test.

Comment se déroule une mission

1. Audit (2 à 5 jours, gratuit). Lecture de la base, du connecteur existant, des volumes réels et des écarts constatés. Vous repartez avec le diagnostic écrit, même sans suite.
2. Cadrage (1 à 2 semaines). Matrice de propriété champ par champ, architecture cible, séquence de bascule, plan de rollback.
3. Développement (4 à 8 semaines). Sprints courts, démos sur un environnement de staging alimenté par vos vraies données.
4. Bascule (1 à 2 jours + 30 jours de suivi). Hors période de pointe, surveillance renforcée, documentation remise, équipes formées.

Questions fréquentes

Pourquoi les connecteurs Shopify ↔ Odoo du marché finissent-ils par casser ?

Trois raisons reviennent systématiquement. D'abord le volume : les modules génériques traitent les produits un par un, ce qui tient jusqu'à quelques milliers de références puis s'effondre sur les rate limits de l'API Shopify. Ensuite la caisse : aucun connecteur du marché ne sait créer de véritables sessions de point de vente Odoo à partir des ventes Shopify POS, donc le retail est ressaisi à la main. Enfin le sens de la synchronisation : la plupart autorisent l'écriture dans les deux sens, ce qui garantit une divergence du référentiel produit en quelques mois.

À partir de quel volume un module natif ne suffit-il plus ?

En pratique, la bascule se joue entre 5 000 et 10 000 SKU, mais le volume seul est un mauvais indicateur. Les vrais déclencheurs sont ailleurs : des variantes à axes multiples, du stock réparti sur plusieurs entrepôts avec des règles d'allocation, de la vente en boutique physique, du cross-border avec plusieurs devises et positions fiscales, ou une exigence de rapprochement comptable automatique. Une boutique de 3 000 références avec trois magasins pose plus de problèmes qu'une de 30 000 en pur e-commerce.

Combien coûte un connecteur Shopify ↔ Odoo sur mesure ?

Entre 8 et 18 K€ selon le périmètre pour une mise en production : le bas de la fourchette couvre la synchronisation produits, stocks, prix et commandes ; le haut ajoute le POS retail multi-boutiques, les écritures comptables automatiques, le cross-border et les marketplaces. À comparer au coût réel d'un module sous licence : abonnement annuel, licence à racheter à chaque version majeure d'Odoo, et surtout le temps passé à contourner ce qu'il ne sait pas faire.

Que se passe-t-il quand Shopify ou Odoo publie une nouvelle version ?

Les versions d'API Shopify sont datées et supportées environ un an, ce qui laisse le temps de migrer sans urgence. Côté Odoo, une version majeure sort chaque année : un connecteur sur mesure se migre avec des scripts de migration versionnés et une suite de tests qui vérifie qu'aucune régression n'est passée. C'est précisément ce qu'un module tiers ne vous garantit pas · vous dépendez du calendrier de son éditeur.

Peut-on garder Odoo comme source de vérité tout en laissant l'équipe travailler dans Shopify ?

Oui, et c'est même l'architecture recommandée, à condition de trancher champ par champ. Le produit, le prix d'achat, le stock et la comptabilité descendent d'Odoo. Le contenu marchand · titres, descriptions, visuels, SEO, collections · peut légitimement vivre dans Shopify. Ce qui casse un référentiel, c'est l'ambiguïté : tout champ dont les deux systèmes se croient propriétaires finira par diverger.

Combien de temps pour une mise en production ?

Comptez six à douze semaines pour un périmètre standard : deux semaines d'audit et de cadrage, quatre à huit semaines de développement avec des démos régulières sur un environnement de staging alimenté par vos vraies données, puis une bascule planifiée hors période de pointe avec trente jours de suivi renforcé. Les projets qui prennent plus longtemps sont presque toujours ceux où la reprise de l'historique de données est sous-estimée.

Pour aller plus loin

• Expertise Odoo · paramétrage, modules sur mesure, migrations
• Expertise Shopify · thèmes, apps, POS, migrations entrantes
• Synchroniser un stock sur plusieurs canaux sans survendre
• PIM Odoo ou Akeneo : comment trancher
• Cas client : connecteur, PLM et inventaire mobile en retail multi-boutiques