Automatiser l'extraction de données Amazon Seller Central : une approche CLI-first
Amazon Seller Central expose une partie significative de ses données via la SP-API, et une partie plus petite mais opérationnellement significative uniquement via l'interface Seller Central elle-même — des rapports qui nécessitent une interaction navigateur pour être demandés, un délai d'attente pour être générés, et une étape de téléchargement séparée pour être récupérés. Automatiser cela de manière fiable est plus nuancé qu'il n'y paraît initialement.
Le défi n'est pas principalement technique. L'automatisation de navigateur est mature, les endpoints de rapport sont documentés, et les formats de données sont bien compris. Le défi est opérationnel : l'interface d'Amazon change sans préavis, les limites de taux sont agressives, la disponibilité des rapports varie selon le marketplace et le type de compte.
API vs navigateur : le compromis honnête
La SP-API couvre la majorité des types de rapports qui comptent pour les données opérationnelles : commandes, inventaire, règlements, exécution FBA et performance du catalogue. Pour ceux-ci, une approche pure API est clairement préférable — elle est plus rapide, plus fiable, et non soumise aux changements d'interface.
Mais en réalité, certaines catégories de rapports ne sont pas disponibles du tout via la SP-API. Les rapports publicitaires au-delà de ce qu'expose l'API Advertising, certains documents de conformité, et plusieurs formats de résumé financier nécessitent une interaction navigateur. La décision d'utiliser l'automatisation de navigateur doit être prise avec réticence, exactement pour ces cas.
Le nommage déterministe des fichiers comme fondation
La décision de conception la plus conséquente dans un pipeline d'extraction de données n'est pas le mécanisme d'extraction — c'est comment les fichiers extraits sont nommés et stockés. Une convention de nommage déterministe encode les propriétés saillantes de chaque rapport directement dans le nom de fichier : type de rapport, identifiant de marketplace, plage de dates, et un hash de contenu pour la déduplication. Un rapport de règlement pour le marketplace UE couvrant une période spécifique devrait produire le même nom de fichier quelle que soit l'heure à laquelle il a été demandé ou téléchargé.
Suivi d'état YAML
Un CLI d'extraction de données qui s'exécute sans surveillance a besoin d'un état persistant : quels rapports ont été demandés, lesquels sont en attente, lesquels ont été téléchargés avec succès, et lesquels ont échoué avec quelle erreur. Les fichiers YAML par type de rapport fournissent la plupart des fonctionnalités nécessaires avec une infrastructure minimale. Le fichier d'état enregistre chaque demande de rapport avec ses paramètres, l'horodatage de la demande, le délai de disponibilité prévu, le statut du téléchargement, et toute erreur rencontrée.
Le flux de travail en deux passes pour les rapports nocturnes
Plusieurs types de rapports Amazon sont générés de manière asynchrone : vous demandez le rapport, Amazon le met en file d'attente, et le rapport devient disponible entre quelques minutes et plusieurs heures plus tard. Le pattern le plus fiable pour ces rapports est un flux de travail en deux passes — une passe de demande qui soumet toutes les demandes de rapports en attente, et une passe de téléchargement qui récupère les rapports qui sont devenus disponibles depuis la dernière vérification.
La passe de demande s'exécute à une heure définie — typiquement en fin de soirée — et soumet des demandes pour tous les types de rapports couvrant la période complète la plus récente. La passe de téléchargement s'exécute le matin suivant, interroge le statut de toutes les demandes en attente, télécharge celles qui sont prêtes, et les marque comme terminées dans le fichier d'état.
Ce qui casse en production
Le schéma de défaillance le plus courant en production n'est pas l'extraction des rapports elle-même — c'est la gestion des credentials. La SP-API utilise des tokens d'accès LWA (Login With Amazon) qui expirent toutes les heures et doivent être rafraîchis. L'extraction basée sur le navigateur a un mode de défaillance différent : les cookies de session expirent, Amazon introduit de nouvelles étapes de vérification, et l'interface change de façon à casser les sélecteurs CSS ou les flux de navigation.
La discipline opérationnelle qui prévient la plupart des défaillances en production est la validation à chaque étape. Les pipelines qui valident agressivement échouent bruyamment et immédiatement. Les pipelines qui font confiance à leurs entrées échouent silencieusement et coûteusement.