Español
English
Català
Deutsch
Português
Italiano
Nederlands
Polski
Presque toutes les entreprises qui connectent Amazon Seller Central à Odoo vivent la même histoire : le premier mois, tout fonctionne bien pendant les tests, puis, après quelques semaines avec un volume réel, les mêmes symptômes apparaissent. Un stock qui ne tombe pas juste, des commandes qui se dupliquent, un suivi qui arrive en retard, l'API qui se met à renvoyer des erreurs 429, ou un token qui cesse de fonctionner un lundi matin sans prévenir.
Idée clé : presque aucune de ces erreurs n'est un problème d'Amazon ni d'Odoo pris séparément. Elles apparaissent dans la couche de synchronisation, quand le connecteur ne respecte pas le modèle asynchrone de la SP-API (notifications en temps réel, limites de requêtes par endpoint, tokens OAuth à courte durée de vie) et se contente d'un simple sondage toutes les X minutes, en espérant que tout arrive à temps.
Pourquoi l'intégration Amazon-Odoo échoue (et ce n'est pas toujours évident)
La SP-API d'Amazon n'est pas une simple API REST de requête-réponse. Elle combine des appels synchrones avec un système de notifications asynchrone (Notifications API, livrée via SQS ou EventBridge), un modèle de rapports générés en arrière-plan qu'il faut interroger jusqu'à ce qu'ils soient prêts, et une limite de requêtes par seconde différente pour chaque opération, et non une limite globale pour tout le compte. L'authentification passe par Login With Amazon (LWA) : l'access token expire toutes les heures et doit être renouvelé avec le refresh_token avant son expiration.
Beaucoup d'intégrations (surtout celles montées avec des automatisations génériques de type Zapier, Make ou un iPaaS sans logique spécifique à Amazon) réduisent tout cela à un cron qui interroge les commandes toutes les X minutes et considère que cela suffit. Cette simplification est à l'origine directe de la plupart des erreurs du tableau suivant.
Tableau : symptôme, cause probable et comment l'éviter
Huit symptômes réels que nous voyons se répéter dans les opérations qui vendent sur Amazon depuis Odoo, avec la cause technique la plus probable dans chaque cas et la solution qu'applique un connecteur conçu pour fonctionner réellement, et pas seulement pour réussir une démo.
| Symptôme | Cause probable | Comment l'éviter |
|---|---|---|
| Stock décalé / survente sur Amazon | Synchronisation par sondage toutes les 30 à 60 minutes ; la Notifications API d'inventaire en temps réel n'est pas utilisée | Abonnement aux notifications d'inventaire avec envoi immédiat après chaque mouvement de stock dans Odoo, plus une marge de sécurité configurable |
| Commandes en double dans Odoo | Nouvelles tentatives du connecteur sans idempotence ; l'AmazonOrderId n'est pas utilisé comme clé unique | Upsert idempotent indexé sur l'AmazonOrderId, avec une contrainte d'unicité au niveau de la base de données |
| Le suivi arrive en retard chez Amazon (le Late Shipment Rate augmente) | L'envoi du suivi se fait dans un cron nocturne par lots, au lieu de se faire à la validation du bon de livraison | Action automatique qui appelle la Shipping API à l'instant où la livraison est validée dans Odoo |
| Erreurs 429 / « Request throttled » | La limite de requêtes propre à chaque opération de la SP-API n'est pas respectée (chaque endpoint a son propre bucket) | File de tâches avec backoff exponentiel et un rate limiter propre à chaque endpoint, et non un limiteur global |
| Token OAuth expiré ou refresh_token invalide | Pas de renouvellement automatique de l'access token LWA, ou le consentement a été révoqué dans Seller Central sans que personne ne s'en aperçoive | Renouvellement automatique avec une marge de sécurité, plus une alerte quand le refresh échoue (et non quand une vraie commande échoue déjà) |
| Prix différents entre Amazon et les autres canaux | Pas de source de vérité unique ; le prix est modifié à la main dans Seller Central | Odoo comme source de vérité des prix, avec des règles de conflit explicites si une modification manuelle est détectée sur Amazon |
| Remboursements et retours qui ne concordent pas en comptabilité | Seules les commandes sont traitées ; les rapports de Returns/Refunds d'Amazon ne sont pas importés | Importation automatique des Returns Reports vers des pièces comptables d'avoir, et pas seulement vers le stock |
| Fonctionne en test mais échoue avec plusieurs comptes ou marketplaces | Identifiants et état de synchronisation codés en dur pour un seul compte vendeur | Modèle d'identifiants par société/marketplace dès le modèle de données, et non comme un correctif ajouté après coup |
Checklist : ce que doit avoir un connecteur Amazon-Odoo bien construit
Avant de valider un connecteur Amazon-Odoo (le vôtre ou un que vous envisagez d'acheter), passez en revue cette liste. Ce n'est pas de la théorie : ce sont les points exacts où nous avons vu échouer des intégrations réelles.
- Il consomme la Notifications API d'Amazon (SQS/EventBridge) au lieu de dépendre uniquement d'un sondage périodique
- Il importe les commandes de façon idempotente en utilisant l'AmazonOrderId comme clé unique
- Il envoie le suivi à Amazon au moment de valider le bon de livraison, et non par lots dans un cron nocturne
- Il applique un rate limiter et un backoff exponentiel par endpoint, et non une limite globale approximative
- Il renouvelle automatiquement le token OAuth (LWA), avec une alerte précoce si le refresh échoue
- Il journalise chaque appel à l'API avec son code de réponse et son payload, et pas seulement un « sync OK » générique
- Il prend en charge plusieurs comptes et marketplaces dès le modèle de données, et non comme un ajout ultérieur
Ce que nous faisons chez FlexigoTech : notre Connecteur Amazon pour Odoo
Notre Connecteur Amazon pour Odoo est construit avec FBA et FBM en production réelle via la SP-API, précisément pour ne tomber dans aucun des huit points du tableau précédent : importation idempotente par AmazonOrderId, envoi du suivi à la validation du bon de livraison et renouvellement automatique des tokens, entre autres. Ce n'est pas une couche d'automatisation générique montée sur l'API : c'est un module Odoo natif pensé pour fonctionner avec un volume réel, et pas seulement pour réussir une démo.
Si vous avez déjà Odoo mais que le connecteur actuel (interne ou tiers) vous donne l'un de ces symptômes, le problème n'est souvent pas de changer de connecteur, mais de revoir la façon dont il est déployé dans votre instance. Cela se règle généralement dans le cadre d'un projet d'implémentation d'Odoo 19 bien mené, avec la synchronisation des marketplaces dans le périmètre dès le départ, et non comme un correctif ultérieur.
Liens utiles chez FlexigoTech
Questions fréquentes
Pourquoi le stock se désynchronise-t-il entre Amazon et Odoo alors que j'ai un connecteur installé ?
Presque toujours parce que le connecteur synchronise par sondage (polling) à intervalles réguliers, au lieu de réagir aux notifications d'inventaire d'Amazon en temps réel. Entre deux passages, il existe une fenêtre pendant laquelle Amazon et Odoo ne concordent pas, et sur un catalogue à forte rotation, cela suffit pour vendre un article que vous n'avez plus.
Comment éviter les commandes en double quand Amazon renvoie la même notification ?
Amazon peut renvoyer plus d'une fois la même notification de commande ; cela fait partie normale de son modèle de livraison. La solution n'est pas de filtrer les renvois à la main, mais que le connecteur utilise l'AmazonOrderId comme clé unique et fasse un upsert idempotent : si la commande existe déjà, il la met à jour ; sinon, il la crée. Il n'insère jamais deux fois.
Qu'est-ce qu'une erreur 429 de l'Amazon SP-API et comment la résoudre depuis Odoo ?
C'est une erreur de throttling : vous avez dépassé la limite de requêtes par seconde de cet endpoint précis (chaque opération de la SP-API a sa propre limite, il n'y en a pas de globale). Elle se résout avec une file de tâches qui respecte le rate limit de chaque endpoint et réessaie avec un backoff exponentiel, et non en rappelant quelques secondes plus tard.
Que se passe-t-il si mon token OAuth Amazon expire en production ?
Amazon utilise Login With Amazon (LWA) : l'access token expire toutes les heures et doit être renouvelé avec le refresh_token avant son expiration. Si le connecteur n'automatise pas ce renouvellement, ou si le vendeur a révoqué le consentement dans Seller Central sans prévenir personne, les appels se mettent à échouer avec des erreurs d'autorisation jusqu'à ce que le compte soit reconnecté à la main.
Un suivi qui arrive tard chez Amazon affecte-t-il vraiment mon compte ?
Oui. Amazon mesure le Late Shipment Rate et, s'il dépasse son seuil, il peut affecter la santé du compte et la visibilité de vos fiches produit, en plus de l'impact direct sur l'expérience de l'acheteur. Si le suivi est envoyé dans un cron nocturne au lieu du moment où le bon de livraison est validé dans Odoo, ce retard est imputable au connecteur, et non à Amazon.
Ce que nous faisons à ce sujet
Souhaitez-vous que nous examinions votre intégration avec Amazon ?
Dites-nous quel symptôme vous rencontrez (stock, commandes en double, suivi ou tokens) et, lors du premier appel, nous vous dirons s'il s'agit d'un ajustement ponctuel ou si le connecteur nécessite une révision de fond. Écrivez-nous à comercial@flexigobe.com ou appelez le +34 616 809 504.