Connecter une boutique à une place de marché ne prend qu'un après-midi. En revanche, gérer l'intégration de PrestaShop sur Etsy et eBay simultanément est une tout autre affaire : chaque système revendique alors la référence produit officielle d'un SKU, utilise son propre modèle d'authentification et impose ses propres limites de requêtes.
En production, les problèmes que vous rencontrez ne se résument jamais à un simple échec de l'appel API. Il s'agit plutôt d'une unité vendue en trop sur eBay parce qu'une commande Etsy a été validée 400 ms plus tôt. Ou encore d'une fiche produit qui reste en ligne après la suppression d'un article mardi dernier. Ou bien d'une commande importée deux fois à cause d'un webhook qui a été relancé alors que votre processus était bloqué dans une transaction. La question pertinente n'est donc pas de savoir si PrestaShop peut communiquer avec eBay et Etsy (la réponse est évidemment oui), mais plutôt comment concevoir la synchronisation pour qu'elle reste correcte une fois la boutique en ligne.
1.0 API de service Web PrestaShop vs. module de connecteur de place de marché : quand faut-il développer ?
La réponse honnête dépend moins de vos compétences en PHP que de qui prend en charge les coûts de maintenance lorsqu'eBay abandonne une version de son API.
L'API Web de PrestaShop est une couche CRUD générique qui s'appuie sur les entités ObjectModel de la boutique. Accessible à l'adresse /api/, elle s'authentifie à l'aide d'une clé d'accès au back-office envoyée comme nom d'utilisateur HTTP Basic, sans mot de passe (voir la documentation développeur de PrestaShop ). Elle permet d'accéder aux produits, aux combinaisons, aux stocks disponibles et aux commandes, mais ignore tout des marketplaces. La configuration de la taxonomie Etsy, des spécificités des articles eBay, de l'actualisation OAuth, des identifiants d'annonces, de la politique de nouvelles tentatives et des garanties d'idempotence reste à votre charge.
| Développement personnalisé basé sur l'API du service Web | module de connexion Marketplace | |
|---|---|---|
| Délai avant la première synchronisation | Semaines, authentification, cartographie et mise en file d'attente avant tout | De quelques heures à plusieurs jours ; écrans de cartographie inclus |
| Mises à jour de l'API Marketplace | Vous suivez les notes de version d'Etsy et d'eBay | Responsabilité du fournisseur, if le fournisseur reste actif |
| Contrôle du mappage des données | Une logique d'attributs totale par marque est possible | Limité par l'interface de mappage du module |
| Architecture de synchronisation | Votre choix de file d'attente, de travailleurs, de verrous, de délai | Généralement géré par cron ; le comportement en temps réel varie |
| Gestion des conditions de course | Cela dépend de la qualité de votre construction. | Souvent le point faible |
| budget à taux limité | Vous possédez les compartiments de jetons et pouvez les prioriser | Opaque ; vérifiez comment le module régule le débit. |
| Débuggabilité | Vos journaux, vos identifiants de corrélation | Format du journal fournisseur ; le traçage par SKU varie |
| Coût permanent | Temps de développement, indéfiniment | Licence et mise à niveau friction |
| Le mieux adapté à | Plus de 2 canaux, attributs complexes, tarification personnalisée | Synchronisation standard eBay/Etsy, petites équipes |
En pratique, cette approche est préférable à l'alternative « l'un ou l'autre » : acheter le connecteur pour prouver la rentabilité du canal, puis développer d'autres fonctionnalités une fois que le catalogue dépasse les capacités de son modèle de mappage. Des connecteurs comme l'intégration PrestaShop eBay Marketplace de Knowband et l'intégration PrestaShop Etsy Marketplace existent car cette première couche (profils, mappage des catégories, état des annonces, importation des commandes, retour d'information sur les statuts) représente le même travail pour chaque projet. Quel que soit le chemin choisi, les critères ci-dessous restent valables : un module ne change que pour ceux qui l'implémentent.
1.1 Ce que l'API de service Web ne fera pas pour vous
Cette fonction déplace les enregistrements ; elle n'exécute pas la logique métier. La requête POST /api/orders ignore PaymentModule::validateOrder(), empêchant ainsi la décrémentation des stocks, la facturation et l'envoi des e-mails de confirmation de commande. De plus, aucun quota de requêtes n'est documenté, ce qui ne signifie pas qu'il n'y a pas de limite : chaque appel à /api/ lance le framework. La véritable limite est donc le nombre de workers PHP-FPM, et une boucle de resynchronisation les épuise bien avant que les limites d'eBay ne soient atteintes. Une solution consiste à enregistrer les ressources de service web du module ( concepts de service web du module ) et à exposer un seul point de terminaison marketplace_sync au lieu de huit appels génériques par produit.
2.0 Cartographie des données : Combinaisons PrestaShop vs. Taxonomie Etsy et spécificités des articles eBay
C’est là que les projets de marketplace perdent discrètement des semaines. Les trois modèles de catalogue n’utilisent pas seulement des noms de champs différents ; ils divergent sur la définition même d’un produit.
PrestaShop modélise un produit comme une arborescence de catégories imbriquées, un identifiant de catégorie par défaut (id_category_default) et des combinaisons générées à partir de groupes d'attributs. eBay exige un identifiant de catégorie unique (categoryId) ainsi que des spécificités d'article, dont les noms, la cardinalité et les valeurs autorisées sont définis pour chaque catégorie et récupérés via la méthode getItemAspectsForCategory de l'API Taxonomy ( API Taxonomy d'eBay ). Etsy exige un identifiant de taxonomie (taxonomy_id) issu de sa propre taxonomie vendeur, ainsi que les propriétés de ce nœud, et limite les variations à deux propriétés par fiche produit.
Trois conséquences se font sentir lors de la première campagne de lancement du catalogue :
- Un produit comportant trois groupes d'attributs : taille, couleur, finition. ne peut pas Il s'agit d'une seule fiche produit Etsy. Soit vous fusionnez une dimension dans le titre, soit vous divisez le produit ; ainsi, un produit PrestaShop peut désormais correspondre à plusieurs identifiants de fiches produits Etsy.
- eBay refuse une publication lorsqu'un élément requis est manquant ; vérifiez donc la correspondance pour chaque catégorie. avant la poussée plutôt que de la découvrir à partir d'un 400.
- Les deux plateformes révisent leurs taxonomies, ce qui rend l'utilisation d'un identifiant de catégorie codé en dur potentiellement problématique à l'avenir.
2.1 Faites de la référence produit (SKU) la clé d'accès sur chaque canal
Avant toute opération de mappage, définissez l'identité. La référence PrestaShop doit être l'identifiant de synchronisation principal, et chaque combinaison nécessite sa propre référence : TSHIRT-BLK-M, TSHIRT-BLK-L, TSHIRT-WHT-M. L'API Inventory d'eBay utilise par conception les SKU ( API Inventory d'eBay ). Par conséquent, une combinaison sans référence est impossible à synchroniser. Validez ce point lors de l'intégration, et non à chaque envoi.
2.2 Stockez le mappage en tant que données et versionnez-le.
Évitez d'utiliser la fonction mapCategory() en PHP. Les mappings représentent des données métier que le commerçant modifie, et non du code que vous réutilisez.
-- Schéma illustratif de la couche de cartographie
CRÉER TABLE ps_mp_category_map (
id_map INT UNSIGNED NOT NULL AUTO_INCREMENT,
canal ENUM('etsy','ebay') NON NULL,
id_category INT UNSIGNED NOT NULL, -- Catégorie PrestaShop
remote_node VARCHAR(64) NOT NULL, -- etsy taxonomy_id | ebay categoryId
aspects_json TEXT NULL, -- valeurs par défaut statiques des aspects
taxonomy_rev VARCHAR(32) NULL, -- Version de l'arborescence des catégories eBay
CLÉ PRIMAIRE (id_map),
CLÉ UNIQUE channel_cat (channel, id_category)
) MOTEUR=InnoDB JEU DE CARACTÈRES PAR DÉFAUT=utf8mb4;
CRÉER TABLE ps_mp_listing_link (
id_product INT NON SIGNÉ NON NULL,
id_attribute INT UNSIGNED NOT NULL DEFAULT 0, -- 0 = produit simple
canal ENUM('etsy','ebay') NON NULL,
remote_id VARCHAR(64) NOT NULL, -- listing_id | offerId
remote_sku VARCHAR(64) NOT NULL,
dernière_poussée_à DATETIME NULL,
CLÉ PRIMAIRE (id_product, id_attribute, channel),
CLÉ UNIQUE chan_remote (canal, remote_id)
) MOTEUR=InnoDB JEU DE CARACTÈRES PAR DÉFAUT=utf8mb4;
Stockez la version de l'arborescence des catégories d'eBay en parallèle du mappage. Lorsqu'une nouvelle version est renvoyée par getDefaultCategoryTreeId, chaque ligne dont la valeur de taxonomy_rev est obsolète doit être revalidée, ce qui explique pourquoi une mise à jour planifiée peut entraîner des échecs de publication le lundi.
3.0 Architecture de synchronisation des stocks : webhooks, interrogation planifiée ou les deux
Comparez les émissions réelles de chaque camp, et la réponse cessera d'être une question de goût.
| Développement | Capacité de poussée | Lacune de couverture |
|---|---|---|
| PrestaShop | Aucun webhook sortant natif ; un module gère les actions actionUpdateQuantity, actionValidateOrder et actionProductUpdate. | Aucune action n'est déclenchée lors de modifications SQL directes ou pour certains chemins d'importation. |
| Etsy | Les webhooks ne couvrent que quatre événements de commande : order.paid, order.canceled, order.shipped, order.delivered (Webhooks Etsy) | Aucun événement n'a généré de reçu, et aucun événement de modification d'inventaire |
| eBay | API de notification avec abonnements aux sujets et destinations HTTPS (API de notification eBay) | La disponibilité des sujets varie ; utilisez getTopics pour les énumérer plutôt que de supposer qu'ils sont disponibles. |
Etsy n'émet aucune notification lorsqu'une quantité est modifiée dans la commande d'un acheteur, ni lorsqu'un reçu est créé. Ce décalage impose l'utilisation d'interrogations régulières, même avec une gestion optimale des webhooks. La règle à suivre est donc la suivante : les webhooks permettent de réduire la latence, tandis que les interrogations régulières garantissent la fiabilité des données. Les webhooks assurent une mise à jour rapide, tandis qu'une opération de rapprochement toutes les 5 à 15 minutes vérifie les quantités et les reçus récents et corrige les erreurs commises par la mise à jour rapide. Le rapprochement n'est pas une solution de repli à espérer ne jamais avoir à intervenir ; c'est ce qui assure le bon fonctionnement du système.
Si vous utilisez un connecteur, l'architecture reste la même sous forme de tâches cron. Un module parfaitement installé, sous licence et configuré semble toujours dysfonctionnel si sa tâche planifiée ne s'exécute jamais ; la vérification cron doit donc figurer dans la liste de contrôle de mise en production, et non dans les notes de dépannage.
3.1 N’appelez jamais une API de place de marché lors du paiement.
// Exemple : point d’accroche du module. Mise en file d’attente uniquement — n’appelez jamais une API de place de marché ici.
fonction publique hookActionUpdateQuantity($params)
{
$sku = $this->resolveSku((int) $params['id_product'], (int) $params['id_product_attribute']);
si (!$sku) {
retour;
}
Db::getInstance()->insert('mp_sync_queue', [
'sku' => pSQL($sku),
'op' => 'stock.push',
'payload' => pSQL(json_encode(['quantity' => (int) $params['quantity']])),
'dedupe_key' => pSQL('stock:' . $sku), // réduit les variations
'created_at' => date('Ymd H:i:s'),
], false, true, Db::REPLACE); // REPLACE = la dernière intention l'emporte
}
Un appel HTTP au sein du hook ajoute de la latence au processus de paiement et provoque l'échec de la commande en cas de ralentissement d'Etsy. Le hook se contente donc de mettre en file d'attente les commandes. L'instruction REPLACE, appliquée à une clé de déduplication par SKU, transforme vingt mouvements de stock en une minute en un seul appel sortant transmettant la quantité actuelle.
4.0 Conditions de concurrence lorsqu'une même référence est vendue simultanément sur trois canaux.
Prenez quatre unités de TSHIRT-BLK-M. Un acheteur eBay en prend deux, un acheteur Etsy une, et la boutique en ligne la dernière, le tout en deux secondes. Trois employés se réveillent, chacun consulte le stock, calcule une quantité et effectue une préparation. Deux bugs indépendants sont désormais à l'œuvre.
Les calculs relatifs entraînent des pertes de données. Si un processus envoie « décrémenter de 2 » tandis qu'un autre envoie « décrémenter de 1 » pour une valeur lue comme étant 4, le résultat sera 2 ou 3 selon l'ordre. Il faut toujours envoyer les quantités absolues lues au moment de l'envoi. La méthode `StockAvailable::getQuantityAvailableByProduct()` est la seule source de vérité, et les quantités affichées sur la marketplace sont des projections de cette valeur, jamais utilisées comme entrées pour les calculs.
Les écritures entrelacées aboutissent à un état final obsolète. Le processus A lit 2, le processus B lit 1 un instant plus tard, B écrit 1, puis la requête plus lente de A aboutit et écrit 2. eBay propose désormais un article inexistant. Un verrouillage par SKU associé à une vérification de version monotone est la solution la plus économique pour garantir le respect des commandes.
// Exemple : sérialiser toutes les envois pour une même référence produit sur tous les canaux.
$lockName = 'mp_sku_' . md5($sku);
$db = Db::getInstance();
// Verrouillage consultatif MySQL : attend jusqu’à 3 s, renvoie 1 lors de l’acquisition, 0 en cas de délai d’attente dépassé.
if (!(int) $db->getValue("SELECT GET_LOCK('" . pSQL($lockName) . "', 3)")) {
$this->requeue($job, 5); // Un autre worker gère cette tâche ; nouvelle tentative prochainement
retour;
}
essayez {
$qty = (int) StockDisponible::getQuantityDisponibleByProduct($idProduct, $idAttribute);
$ver = (int) $db->getValue(
'SELECT stock_version FROM ' . _DB_PREFIX_ . 'mp_sku_state WHERE sku = "' . pSQL($sku) . '"'
);
si ($job['version'] < $ver) {
Retourner ; // Une nouvelle notification a déjà été envoyée ; ignorer celle-ci
}
$this->etsy->setQuantity($sku, $qty); // valeur absolue
$this->ebay->setQuantity($sku, $qty); // valeur absolue
$db->execute(
'MISE À JOUR ' . _DB_PREFIX_ . 'mp_sku_state
DÉFINIR stock_version = stock_version + 1, synced_qty = ' . $qty . ', synced_at = MAINTENANT()
WHERE sku = "' . pSQL($sku) . '"'
);
} finalement {
$db->execute("SELECT RELEASE_LOCK('" . pSQL($lockName) . "')");
}
L'accès à GET_LOCK est limité à la session ; il s'étend donc aux processus PHP-FPM et cron sur la même base de données et est libéré lorsque la connexion est interrompue, contrairement à un verrou séquentiel. Pour une utilisation sur plusieurs serveurs de bases de données, il est recommandé de déplacer le verrou vers Redis et de conserver la colonne de version comme solution de repli.
Aucun verrouillage ne supprime cependant le risque résiduel. Entre le paiement sur Etsy et votre mise en vente, eBay peut légitimement vendre le même article. Pour limiter ce risque, il est donc conseillé d'adopter une approche commerciale : indiquez « disponible – 1 » pour les articles les plus vendus et mettez à jour le stock du dernier article à 0 immédiatement, plutôt qu'à la prochaine réconciliation.
5.0 Comment les limites de débit des API Etsy et eBay, ainsi que le plafond de PrestaShop, se combinent
Chaque budget semble généreux pris individuellement. Cependant, combinés en trois volets, ils se multiplient en fonction du nombre de références.
| Développement | limites documentées | Signaux à lire |
|---|---|---|
| Etsy | Quotas de requêtes par seconde (QPS) et par paquet (QPD) par application, variables selon les besoins ; la valeur par défaut documentée pour une nouvelle application est de 10 requêtes/seconde et de 10 000 par période de 24 heures, ces quotas pouvant être augmentés sur demande (Limites de débit d'Etsy) | limite par seconde, limite restante pour cette seconde, limite par jour, limite restante aujourd'hui ; réessayer après sur 429 |
| eBay | Limites d'appels quotidiens par application, par API et par ressource, augmentées par le biais du contrôle de croissance des applications (Limites d'appels à l'API eBay) | API Developer Analytics getRateLimits — quota, utilisé, restant, fenêtre de réinitialisation |
| PrestaShop | Aucun quota publié ; limité par le nombre de workers PHP-FPM et le coût de démarrage du framework par appel /api/. | Votre propre taux 5xx et profondeur de file d'attente FPM |
Une resynchronisation complète de 3 000 références nécessite une écriture d'inventaire Etsy par fiche produit, une mise à jour d'offre eBay par référence et une lecture PrestaShop par référence. Avec le débit par défaut d'Etsy de 10 requêtes par seconde, cela représente cinq minutes de traitement continu sans aucune marge de manœuvre pour le processus de collecte des commandes, qui ne doit absolument jamais être interrompu. Trois règles permettent de maîtriser le budget :
- Un seul compartiment de jetons par canal, partagé par tous les travailleurs. Appliquez cette limitation dans Redis, car un limiteur par processus multiplie votre débit réel par le nombre de travailleurs.
- Prioriser les files d'attente. Les annulations d'ordres et les écoulements de stock à zéro sont prioritaires sur les mises à jour de prix et les chargements d'images. Consacrer du temps aux vignettes alors qu'une survente se profile est une erreur de conception.
- Lot et différence. L'API d'inventaire d'eBay propose des mises à jour groupées des prix et des quantités. Il faut donc traiter les données par lots jusqu'au plafond actuel par appel, puis comparer avec la quantité synchronisée et arrêter de dépenser le quota pour confirmer que 7 équivaut toujours à 7.
6.0 Authentification : clés API Etsy OAuth, eBay OAuth 2.0 et PrestaShop
Trois modèles, dont seulement deux expirent.
PrestaShop envoie la clé d'accès sous forme d'identifiant HTTP Basic sans mot de passe. Sans expiration, sans renouvellement ni mécanisme de gestion des erreurs de renouvellement de jeton, le risque est inverse, car une clé ne change jamais, sauf si vous la changez.
Etsy utilise le protocole d'autorisation OAuth 2.0 avec authentification PKCE obligatoire : un code de vérification (code_verifier) de 43 à 128 caractères et un code de vérification S256 (code_challenge). Les jetons d'accès expirent dans 3 600 minutes et les jetons d'actualisation sont valides 90 jours ( authentification Etsy ). Chaque requête nécessite l'en-tête x-api-key et le jeton porteur, dont le format est {user_id}.{token}. Le préfixe numérique appartient à l'identifiant ; le supprimer constitue une faille classique des premières versions.
eBay émet des jetons d'accès utilisateur valides pendant 7 200 secondes et des jetons d'actualisation valides pendant 47 304 000 secondes, soit environ dix-huit mois ( jetons OAuth eBay ). Les jetons d'application couvrent les données publiques, mais toute interaction avec l'inventaire d'un vendeur nécessite le jeton utilisateur.
Ce qui interrompt réellement les tâches de synchronisation, ce n'est pas l'expiration du jeton, mais la détection simultanée de cette expiration par dix nœuds de calcul. Il est donc essentiel de sécuriser l'actualisation avec un verrou de type « un-fly », de revérifier le jeton stocké sous ce verrou et d'effectuer l'actualisation avec une marge de deux minutes plutôt que de réagir à une erreur 401. Il convient également de conserver le jeton d'actualisation renouvelé lors de la même écriture que le jeton d'accès, car une interruption entre deux écritures entraîne la perte de l'autorisation. Enfin, il est nécessaire de générer des alertes en cas de succès ou d'échec de l'actualisation, car une autorisation non actualisée depuis 24 heures constitue un problème, même en l'absence d'erreur ( bonnes pratiques OAuth d'eBay ).
7.0 Synchronisation des commandes Marketplace : taxes, frais de port, devise et idempotence
L'importation des commandes est le point faible de votre système, et les comptables y décèlent souvent des erreurs. Une commande sur une marketplace n'est pas une simple commande PrestaShop avec des noms de champs différents ; il s'agit d'un document financier finalisé. Quatre incohérences doivent être résolues avant de développer l'outil d'importation.
Taxe prélevée par les plateformes de vente en ligne. Etsy et eBay collectent et reversent la TVA pour le compte du vendeur dans de nombreuses juridictions. Cette taxe est incluse dans la déclaration, mais elle ne représente ni une dette ni un revenu pour le vendeur. Par conséquent, son intégration dans une règle fiscale classique gonfle la déclaration de TVA. Il est donc recommandé de l'associer à une règle de taux zéro et à un champ comptable distinct, puis de valider ce traitement avec le comptable du vendeur.
Expédition. Les places de marché facturent un montant déjà calculé selon leurs propres profils d'expédition. Il est inutile de réexécuter les règles de transporteur de PrestaShop, car les totaux divergent et la commande ne correspond jamais au paiement. Créez plutôt un transporteur par canal et définissez le coût à partir de la charge utile.
Devise. Les données sont libellées dans leur propre devise et le paiement peut être effectué dans une devise tierce. Conservez le montant sur la plateforme, le montant dans la devise du magasin et le taux de conversion utilisé lors de l'importation, car la réutilisation du taux actuel pour réimprimer une facture vieille de trois mois produira un document introuvable.
Chemin de création. Constituez le panier, puis appelez PaymentModule::validateOrder() — le seul chemin qui décrémente le stock, génère la facture, définit l'état de la commande et déclenche les hooks dont dépendent les autres modules.
// Exemple : importation d'une commande de marché idempotente.
$externalId = $channel . ':' . $remoteOrderId;
si (Db::getInstance()->getValue(
'SELECT id_order FROM ' . _DB_PREFIX_ . 'mp_order_link
WHERE external_id = "' . pSQL($externalId) . '"'
)) {
retour; // déjà importé — nouvelle tentative de webhook ou sondage chevauchant
}
$cart = nouveau Panier();
$cart->id_customer = $idCustomer;
$cart->id_currency = (int) Currency::getIdByIsoCode($payload['currency']);
$cart->id_carrier = (int) Configuration::get('MP_CARRIER_' . strtoupper($channel));
$cart->id_address_delivery = $idAddress;
$cart->id_address_invoice = $idAddress;
$cart->ajouter();
foreach ($payload['lines'] as $line) {
$cart->updateQty((int) $line['qty'], (int) $line['id_product'], (int) $line['id_attribute']);
}
$module = Module::getInstanceByName('mpsync');
$module->validateOrder(
(int) $cart->id,
(int) Configuration::get('PS_OS_PAYMENT'),
(flottant) $payload['total_paid'],
$channel . ' Marketplace',
nul
['transaction_id' => $remoteOrderId],
(int) $cart->id_currency,
faux,
$cart->clé_sécurisée
);
Db::getInstance()->insert('mp_order_link', [
'external_id' => pSQL($externalId),
'id_order' => (int) $module->currentOrder,
'importé_à' => date('Ymd H:i:s'),
]);
Créez un index UNIQUE sur external_id. La requête SELECT ci-dessus n'est qu'une solution rapide ; l'index garantit la fiabilité, car deux processus peuvent effectuer cette vérification en une milliseconde. Ensuite, paginez les résultats de getOrders d'eBay et les reçus de boutique Etsy à l'aide d'un curseur de mise à jour persistant plutôt que d'un décalage fixe susceptible de se modifier.
L'idempotence s'étend au-delà des commandes. La mise en ligne d'un produit comprend quatre étapes : création de l'article, création de l'offre, chargement des images et publication. Il est donc important d'enregistrer l'état de chaque étape en fonction de (SKU, canal, étape) et de permettre la reprise de la procédure au lieu d'un redémarrage. Etsy signe également les webhooks avec un identifiant, un horodatage et une signature. Il convient donc de dédupliquer les webhooks en fonction de leur identifiant et de rejeter ceux dont l'horodatage diffère de plus de 300 secondes environ. Cet en-tête à lui seul permet d'éviter les tentatives de relance pour les doublons.
8.0 Surveillance de la synchronisation d'une place de marché en production
Une synchronisation qui échoue bruyamment est une tâche de maintenance. Une synchronisation qui échoue silencieusement est une file d'attente de remboursement.
| Consignez chaque opération avec | Alerte sur |
|---|---|
| ID de corrélation couvrant le webhook → file d'attente → appel API | Divergence boursière, local ≠ distant pour plus de N minutes |
| UGS, canal, opération, quantité absolue envoyée | Échec d'authentification, toute erreur d'actualisation OAuth, paginée immédiatement |
| Demande et réponse complètes pour les informations non-2xx, secrets expurgés | limite de vitesse de combustion, le quota journalier restant inférieur à 20 % avant 18h00 |
| Budget restant pour la limitation du débit par canal | Âge de la file d'attente, tâche non traitée la plus ancienne datant de plus de 5 minutes |
| Horodatage de l'expiration du jeton et de la dernière actualisation réussie | Écart de commande, zéro commande provenant d'un canal dans une fenêtre normalement occupée |
| Résultats de la réconciliation : vérifié, réparé, non résolu | Cron silence, une tâche de synchronisation planifiée qui n'a pas été exécutée à temps |
Deux indicateurs méritent une attention particulière. L'âge de la file d'attente est l'indicateur avancé, car il augmente avant même que les clients ne constatent le moindre problème. Le nombre de réparations liées à la réconciliation est l'indicateur de fiabilité : si le processus de 15 minutes corrige systématiquement les mêmes références, votre système de traitement rapide est défaillant et l'interrogation continue de le masquer discrètement.
Enfin, enregistrez la quantité exacte envoyée plutôt que la différence. Si un vendeur demande pourquoi eBay a affiché 3 et PrestaShop 1, la réponse doit pouvoir être trouvée directement dans le journal.
9.0 Dépannage de quatre problèmes de synchronisation de la marketplace PrestaShop que vous rencontrerez réellement
9.1 Les listes affichent des quantités obsolètes alors que les journaux indiquent un code HTTP 200.
Vérifiez le contenu du fichier, et non le code d'état. Sur Etsy, la mise à jour d'un inventaire remplace l'intégralité de la structure ; une mise à jour partielle peut donc réinitialiser des offres que vous n'avez pas l'intention de modifier. Sur eBay, la mise à jour d'un article est différente de la mise à jour de l'offre publiée, et cette dernière inclut la quantité disponible à la vente. Immédiatement après une mise à jour, vérifiez la référence d'un produit et comparez-la champ par champ. Dans une configuration basée sur un connecteur, suivez d'abord la même procédure : le produit est-il associé ? Possède-t-il une référence valide ? La synchronisation est-elle activée ? La tâche cron a-t-elle été exécutée ?
Les 9.2 429 secondes apparaissent uniquement lors de la resynchronisation complète nocturne.
Votre quota de jetons est par processus ; par conséquent, huit tâches cron s'exécutent à un rythme huit fois supérieur à celui prévu. Déplacez le limiteur vers un stockage partagé. Ensuite, remettez en question la resynchronisation complète, comparez-la à la quantité synchronisée et ne transmettez que les modifications. La consommation nocturne de jetons diminue généralement d'un ordre de grandeur. Respectez l'option de nouvelle tentative après les erreurs 429 d'Etsy et vérifiez les limites de débit d'eBay avant un traitement par lots important afin d'éviter une interruption en cours d'exécution.
9.3 La même commande est importée deux fois, à plusieurs heures d'intervalle.
Chevauchement des fenêtres d'interrogation et absence de contrainte. Vérifiez l'existence de l'index UNIQUE sur external_id, car une requête SELECT avec vérification des doublons sans cet index constitue une condition de concurrence plutôt qu'une protection. Vérifiez ensuite le curseur : un système d'interrogation qui demande toutes les 15 minutes les « commandes mises à jour au cours des 30 dernières minutes » propose chaque commande deux fois, et ce, intentionnellement. Définissez une valeur de référence, chevauchez-la volontairement et laissez la base de données garantir l'unicité.
9.4 La synchronisation s'arrête pour une chaîne à 3 h du matin sans erreur.
Il s'agit généralement d'une perte de jeton d'actualisation. Un jeton d'actualisation Etsy a expiré sans avertissement après sa période de 90 jours, ou une actualisation simultanée a entraîné deux rotations du jeton et votre processus a conservé le jeton invalide. Commencez par vérifier les champs `expires_at` et `last-successful-refresh` du magasin de jetons. Ensuite, assurez-vous que le service cron du serveur ou le planificateur externe exécute toujours les tâches de synchronisation ; un planificateur arrêté produit précisément ce symptôme et ces journaux vides.
10.0 Liste de contrôle de préparation à la production pour la vente multicanale PrestaShop
Avant de considérer l'intégration d'Etsy ou d'eBay comme terminée, consultez cette liste :
- Produits, chaque produit et combinaison synchronisés possède une référence unique, les catégories correspondent à des nœuds de marché valides, les aspects requis sont renseignés et les images répondent aux exigences du marché.
- InventairePrestaShop est la source de vérité : les envois contiennent des quantités absolues protégées par un verrouillage par SKU, les envois de produits en stock nul sont effectués immédiatement et le rapprochement s’effectue selon un calendrier prédéfini.
- CommandesL'identifiant de la commande sur la plateforme est stocké sous une contrainte d'unicité, les taxes et les frais d'expédition du facilitateur sont délibérément mappés, et les importations sont traitées par validateOrder().
- API et authentificationLes identifiants sont stockés en toute sécurité, l'actualisation s'effectue en marge derrière un verrou à accès unique et les limites de débit sont partagées entre les nœuds de calcul.
- Cron et surveillance, chaque tâche requise s'exécute de manière vérifiable, l'âge de la file d'attente et les réparations de réconciliation sont visibles, et les échecs d'authentification génèrent une alerte plutôt qu'une ligne de journal.
11.0 Par où commencer
Lors de la création d'une intégration de marketplace PrestaShop à partir de zéro, l'ordre à suivre pour éviter les reprises est le suivant : intégrité des SKU, mappage des tables, envoi des quantités absolues derrière un verrouillage par SKU, importation des commandes avec un identifiant externe unique, rapprochement et webhooks en dernier. Les webhooks constituent l'optimisation. Une boucle d'interrogation correcte avec verrouillages et idempotence est déjà un système fiable.
Si vous préférez partir d'un connecteur fonctionnel et consacrer votre temps de développement aux spécificités de votre catalogue, évaluez le module par rapport à cette même liste : mappage, planification, visibilité des erreurs, protection contre les doublons, réconciliation, et vérifiez ses tâches cron avant la mise en production. Dans tous les cas, l'objectif n'est pas une synchronisation ponctuelle, mais une synchronisation continue dans six mois.
Pour toute question ou assistance concernant les performances ou la migration de votre site web, nos experts sont à votre disposition. Contactez l'équipe Knowband à l'adresse [email protected] dès aujourd'hui pour obtenir des plugins e-commerce fiables et adaptés à vos besoins.
