Pourquoi l'intégration ERP e-commerce est importante
Une activité e-commerce sans intégration ERP fonctionne avec du scotch. Les commandes sont saisies à la main de Shopify vers la comptabilité. Les niveaux de stock mentent parce que le système d'entrepôt et la vitrine se mettent à jour à des rythmes différents. La taxe de vente est calculée de trois manières différentes par trois outils. Les remboursements sont rapprochés avec dix jours de retard, quand ils le sont. Le jour où un opérateur a 200 commandes par jour sur un seul site, il a besoin d'une vraie intégration — et à 1 000 commandes par jour, son absence devient un problème de marge.
Le bon état final est une pile intégrée où la vitrine, le processeur de paiement, le moteur fiscal et l'ERP partagent automatiquement leurs données. Une commande passée sur Shopify crée une commande de vente dans Odoo, réserve le stock, enregistre le paiement de Stripe, calcule et reverse la taxe via Avalara, génère la liste de prélèvement pour l'entrepôt et émet la facture — sans intervention humaine. Nous câblons cette pile pour des clients régulièrement. Ce guide est le manuel structurel.
Pour une discussion plus approfondie sur les capacités e-commerce d'Odoo, voir Au-delà de la vitrine — le vrai ROI d'Odoo pour l'e-commerce en 2026. Pour les services d'intégration que nous proposons, la page services d'intégration couvre notre méthodologie.
Les quatre schémas d'intégration
Toute intégration e-commerce vers ERP suit l'un des quatre schémas. Choisir le mauvais schéma est l'une des erreurs les plus coûteuses dans ce domaine.
Schéma 1 : API REST directe (temps réel)
La vitrine appelle directement l'API REST de l'ERP, l'ERP rappelle via webhook. Idéal pour : événements transactionnels à faible volume (nouvelle commande, mise à jour de stock). Implémentation la plus rapide, le moins de pièces mobiles. Tient mal sous fort volume et n'offre aucune file de réessai si l'ERP est en panne.
Schéma 2 : Bus d'événements piloté par webhooks
Les deux côtés publient des événements vers un bus de messages (Pub/Sub, EventBridge, Kafka), et les consommateurs lisent à leur propre rythme. Idéal pour : volume moyen, fan-out multi-systèmes (une commande Shopify doit mettre à jour Odoo, Klaviyo, ShipStation et un entrepôt analytique simultanément). Coût d'infra plus élevé mais résilient.
Schéma 3 : Middleware (iPaaS — Workato, Tray, Celigo)
Une plateforme d'intégration tierce s'interpose. Configurez des connecteurs au lieu d'écrire du code. Le délai le plus court vers la première intégration, mais coût récurrent par connexion et gestion limitée de la logique métier qui ne peut pas être exprimée dans l'interface du connecteur. Idéal pour : cas d'usage simples ou équipes non techniques.
Schéma 4 : Module Python personnalisé dans Odoo
Écrivez un module Odoo personnalisé qui appelle directement Shopify, Stripe, Avalara. Contrôle total des cas limites, aucun coût par connexion. Coût d'ingénierie le plus élevé, mais c'est la bonne réponse pour les opérateurs à fort volume (1 000+ commandes/jour) qui ont besoin d'un comportement exact et de zéro frais mensuels de plateforme. C'est le schéma qu'Octura utilise pour la plupart des clients d'entreprise.
Intégration Shopify ↔ Odoo en pratique
Odoo est livré avec un connecteur Shopify natif qui gère les bases : synchronisation des produits, mises à jour de stock, import des commandes et création de clients. Pour les opérateurs à faible volume (moins de 100 commandes/jour), il fonctionne dès l'installation. La configuration prend quelques heures, et il n'y a pas de frais récurrents.
Au-dessus de ce volume, le connecteur standard commence à atteindre ses limites. Les motifs que nous rencontrons :
- Dérive de la synchronisation des stocks. Le connecteur interroge en mode polling ; sous charge, il prend du retard. Remplacer par un écouteur d'événements piloté par webhook.
- Stock multi-canaux. Si la même référence est vendue sur Shopify, Amazon et un portail B2B, le connecteur ne peut pas réserver correctement. Une logique personnalisée dans Odoo décide quel canal obtient quel pool de stock.
- Rapprochement des remboursements. Les remboursements Shopify et Stripe sont deux événements. Le connecteur crée un avoir ; le second événement doit être rapproché à la main sans code personnalisé.
- Gestion fiscale B2B vs B2C. Les acheteurs en gros ne devraient pas payer la taxe de vente ; le connecteur standard ne différencie pas par type de client.
Référence de coût réelle : un opérateur Shopify Plus avec 800 commandes/jour, 12 références sur 3 entrepôts, B2B et B2C, Stripe + Avalara complets — environ 4 à 6 semaines de construction d'intégration, 30 à 60 K $, plus 300 $/mois de surcoût d'hébergement Odoo.sh.
Intégration Stripe ↔ Odoo
L'intégration de Stripe avec Odoo est simple : le connecteur Stripe natif d'Odoo gère les paiements, les remboursements, la facturation par abonnement et le rapprochement par webhook. Là où ça devient intéressant, c'est du côté comptable.
Par défaut, Odoo enregistre chaque paiement Stripe comme une écriture vers un compte bancaire « Stripe Clearing ». Quand Stripe verse un lot (généralement T+2 aux États-Unis, T+5 ailleurs), le versement est rapproché des paiements compensés. La complication : Stripe déduit les frais de traitement du versement, donc le montant du relevé bancaire et le montant brut des ventes diffèrent. Le rapprochement standard d'Odoo gère cela — mais seulement si le plan comptable a un compte de charges « Frais de processeur de paiement » configuré en amont.
Pour les opérateurs à fort volume, les pièges :
- Litiges et chargebacks nécessitent un workflow structuré — typiquement un statut « Litigieux » sur la fiche client et une notification vers un alias e-mail finance.
- Reporting multi-devises — Stripe règle dans la devise de votre banque mais facture dans la devise du client. Le taux de change utilisé par Stripe diffère de votre taux comptable ; l'écart se passe en « Gain/Perte de change ».
- Descripteurs de relevé — ils doivent être configurés dans Odoo par produit ou par unité d'affaires pour correspondre à ce qui apparaît sur le relevé de carte du client.
Budget d'implémentation réaliste pour une intégration Stripe-Odoo propre avec une comptabilité correcte : 1 à 2 semaines, 5 à 15 K $.
Intégration Avalara (ou Vertex / TaxJar) ↔ Odoo
La taxe de vente est la raison la plus fréquente pour laquelle les opérateurs e-commerce nous contactent pour de l'aide en intégration. La combinaison des règles de nexus état par état aux États-Unis, de la TPS/TVP/TVQ canadienne, de la TVA européenne et de la TVA britannique post-Brexit fait que le traitement manuel des taxes ne tient pas au-delà de 5 à 10 juridictions.
Odoo dispose d'un connecteur Avalara AvaTax natif. Il appelle Avalara au moment du devis et au moment de l'émission de la facture, récupère les taux spécifiques à la juridiction et stocke la taxe calculée sur la facture. Le connecteur gère 80 % des cas d'usage américains.
Là où nous avons généralement besoin de travail personnalisé :
- Clients exonérés de taxe. Certificats de revente, organismes à but non lucratif et acheteurs publics nécessitent un workflow d'exonération structuré avec gestion des certificats au dossier.
- Règles de marketplace facilitator. Quand vous vendez sur Amazon, Walmart ou eBay, la marketplace reverse la taxe — mais seulement pour ce canal. Odoo doit savoir ignorer Avalara pour les commandes marketplace et appliquer les règles normales pour les commandes directes.
- Déclarations TVQ + TPS empilées au Québec. Les opérateurs canadiens ont besoin de déclarations fédérales et provinciales, et le flux canadien d'Avalara n'est pas aussi profond que son flux américain. Nous complétons souvent avec une logique personnalisée.
- OSS / IOSS UE. Les vendeurs transfrontaliers UE ont besoin de l'enregistrement guichet unique ; Avalara gère le calcul mais Odoo doit déposer les déclarations.
Repères de coûts et de calendrier
- Shopify + Odoo, faible volume (moins de 100 commandes/jour) : 1 à 2 semaines, 5 à 15 K $, connecteur standard.
- Shopify + Stripe + Odoo, volume moyen (100 à 500 commandes/jour) : 3 à 4 semaines, 20 à 40 K $, connecteurs standards avec personnalisation des workflows.
- Shopify + Stripe + Avalara + Odoo, fort volume (500 à 2 000 commandes/jour) : 4 à 8 semaines, 40 à 80 K $, module Python personnalisé + connecteurs standards.
- Multi-canaux (Shopify + Amazon + B2B + Avalara + Stripe + Odoo) : 8 à 14 semaines, 80 à 180 K $, couche d'orchestration personnalisée.
Ces repères se basent sur environ 30 intégrations e-commerce-ERP qu'Octura a livrées au cours des 24 derniers mois. Au-dessus de 2 000 commandes/jour, chaque implémentation est sur mesure — le motif cesse d'être un repère et devient une architecture sur mesure.