Construire un suivi de prix Amazon en Python (la vraie méthode)

Je pensais avoir trouvé la PlayStation 5 la moins chère sur Internet.

Mon suivi de prix affichait 74,00 $ à côté d'une PS5, mais si cela semble trop beau pour être vrai en ligne, c'est presque toujours le cas. Ces 74 $ n'étaient pas la console. C'était le scraper qui récupérait le mauvais élément, et c'est exactement le genre de bug silencieux qui rend la plupart des tutoriels « suivi de prix Amazon » discrètement inutiles.

Donc au lieu de simplement publier cinquante lignes de Python et d'appeler ça terminé, ce que font presque tous les guides, j'ai testé correctement. J'ai lancé le code contre Amazon en volume, mesuré exactement ce qui se bloque et ce qui ne se bloque pas, et j'ai corrigé les bugs que les tutoriels ne mentionnent jamais. Les résultats ont été vraiment surprenants : un scraper basique a atteint une page de produit 150 fois sans un seul blocage, mais s'est arrêté à la toute première requête vers une page de résultats de recherche.

Ce guide est le suivi fonctionnel plus tout ce que les tests ont révélé, y compris une astuce Selenium qui vaut la peine d'être connue même si vous avez déjà construit des scrapers : il pilote une vraie fenêtre Chrome, visuellement, pour que vous regardiez la page se charger et le scraping se faire en temps réel.

Amazon va-t-il vraiment vous bloquer ?

Tous les tutoriels vous avertissent qu'Amazon bloquera votre scraper instantanément. Alors j'ai testé, et les résultats m'ont vraiment déconcerté.

J'ai pointé un scraper basique, sans fioritures, vers une page de produit PlayStation 5 et je l'ai laissé envoyer des requêtes. Une requête, deux, dix, cinquante, j'attendais toujours le mur. Il n'est jamais venu. Le script a envoyé 150 requêtes à la même page et chacune est revenue « ok ». Je ne pouvais pas croire à quel point c'était ouvert.

C'était le cas. Les pages de produit, il s'avère, s'en soucient à peine. Ensuite, j'ai pointé le même scraper vers une page de résultats de recherche, et ça s'est arrêté à la toute première requête. Pas la dixième, pas la cinquantième. La première. Un 503 immédiatement.

Les résultats de recherche sont l'endroit où la collecte massive de données se produit, donc c'est là qu'Amazon concentre ses défenses. Les pages de produits individuels ? Grandes ouvertes.

Voici ce que j'ai essayé et ce qui s'est passé :

• Page de produit, scraper basique : 150 requêtes, zéro blocage

• Page de recherche, scraper basique : bloqué à la requête n° 1 (503)

• Page de recherche, meilleurs en-têtes : toujours bloqué à la requête n° 1

• Page de recherche, en-têtes + proxy résidentiel : toujours bloqué à la requête n° 1

• Page de recherche, navigateur réel : a fonctionné, 16 résultats

• Page de recherche, navigateur + proxy US : a fonctionné, 22 résultats

La partie qui m'a le plus surpris : envoyer un proxy résidentiel vers la page de recherche n'a rien aidé du tout. Toujours bloqué, première requête. Le blocage n'a jamais porté sur mon adresse IP, mais sur le fait que je n'étais pas un vrai navigateur. Au moment où j'ai chargé la même page de recherche dans un vrai navigateur au lieu d'un script brut, ça a fonctionné :

Construire le suivi

Construisons la chose. Le suivi entier fait environ 50 lignes de Python. Vous avez besoin de Python 3 et de Google Chrome installés, puis d'une commande pour les bibliothèques :

pip install selenium requests matplotlib

Le pointer vers un produit

Chaque produit Amazon a un identifiant appelé ASIN, le code de 10 caractères dans l'URL juste après /dp/. Par exemple, dans amazon.com/dp/B0F1J12R6N, l'ASIN est B0F1J12R6N. C'est tout ce dont le suivi a besoin pour trouver un produit.

Pourquoi requests ne suffit pas

La façon évidente de scraper une page est la bibliothèque requests de Python : une ligne, récupérer le HTML, c'est fait. Et pour une page de produit, elle retourne même un 200 OK. Mais voici le piège dans lequel je suis tombé : un 200 ne signifie pas que vous avez obtenu les données. Amazon construit le prix dans la page avec JavaScript, et requests n'exécute pas JavaScript. Donc vous récupérez une page, mais le prix n'y est pas.

C'est pourquoi ce suivi utilise Selenium à la place. Selenium pilote un vrai navigateur Chrome : il ouvre réellement la page, exécute le JavaScript, et vous laisse lire le résultat complètement rendu. La première fois que vous l'exécutez, Chrome s'ouvre de lui-même avec une bannière disant « Chrome est contrôlé par un logiciel de test automatisé », et vous regardez ça fonctionner en temps réel.

Scraper le prix (et le bug que tout le monde livre)

C'est là que la plupart des tutoriels se cassent discrètement. L'approche courante récupère l'élément .a-price et lit son texte. Le problème : Amazon met le prix dans cet élément deux fois, une fois visible, une fois pour les lecteurs d'écran, donc vous obtenez un 449,00 $449,00 $ brouillé au lieu d'un nombre propre.

La solution est de cibler la copie propre et unique du prix à l'intérieur de la boîte d'achat et de la lire attentivement, en vérifiant d'abord le prix de la boîte d'achat principale pour ne pas prendre accidentellement le prix d'un accessoire, ce qui est exactement comment je me suis retrouvé avec cette « PS5 à 74 $ ». Les sélecteurs exacts sont dans le code sur GitHub.

Une fois qu'il cible le bon élément, le prix revient propre :

Stocker l'historique et le mettre en graphique

Un suivi de prix n'est utile que s'il mémorise. Le script enregistre chaque relevé dans un fichier, organisé par produit, en stockant le prix comme un nombre réel accompagné de sa devise, pas une chaîne « 54,00 $ ». C'est important : les nombres, vous pouvez les mettre en graphique, les comparer et trouver le plus bas ; les chaînes, non. Laissé seul, le script vérifie une fois et s'arrête ; ajoutez une option de boucle et il revérifie selon un calendrier, constituant un historique au fil du temps qu'un deuxième petit script transforme en graphique de prix dans le temps.

Le bug qui aurait pu me coûter cher : vous pourriez scraper le mauvais pays

Vous vous souvenez de cette PlayStation à 74 $ ? C'était le premier signe que quelque chose n'allait pas. Le deuxième était pire, car c'était plus difficile à repérer.

Quand j'ai exécuté le suivi pour la première fois sans proxy, Amazon ne m'a pas seulement donné des prix bizarres — pour certains produits, il ne m'a donné aucun vrai prix du tout, juste un avis « cet article ne peut pas être expédié à votre emplacement ». Le suivi n'avait rien d'utile à enregistrer.

Alors je l'ai routé via un proxy pour ressembler à un acheteur américain. Le prix est revenu en euros. Au début, j'ai supposé que le proxy n'avait pas du tout fonctionné. Ensuite, j'ai remarqué que la page disait « Livrer en Irlande », et tout s'est éclairé : le proxy fonctionnait bien, il m'avait juste placé sur une IP irlandaise. Bonne idée, mauvais pays.

La solution est un proxy résidentiel ancré sur le pays qui vous intéresse vraiment. Une fois que j'ai verrouillé le mien sur les États-Unis, le suivi a récupéré le prix correct, 54,00 $, en dollars, à chaque fois.

Et cet ancrage par pays n'est pas un simple plus, c'est tout l'intérêt. Disons que vous suivez les prix des concurrents pour décider ce que vous allez facturer sur un marché donné. Ces chiffres n'ont de sens que s'ils sont les prix que ce marché voit réellement. Le même produit pourrait être à 449 $ aux États-Unis et à 499 € en Irlande. Si votre scraper renvoie discrètement le prix irlandais, vous prenez des décisions pour un marché sur la base des données d'un autre marché, et parce que ça a l'air valide, personne ne s'en aperçoit.

Donc un proxy ici n'est pas question de contourner des blocages — mes tests ont montré que les pages de produit bloquent à peine de toute façon. C'est pour s'assurer que les données que vous collectez sont les bonnes données.

Si vous voulez des données de prix ancrées sur un pays spécifique, les proxies résidentiels de FlashProxy vous permettent de cibler n'importe quel emplacement, pour que vous collectiez toujours les prix que ce marché voit réellement.

Alors… est-ce que ça aurait dû être plus difficile ?

Voici mon vrai bilan : si vous avez un jour besoin de scraper des prix sur une page Web, vous n'avez pas à lire cent blogs, regarder une pile de vidéos YouTube, ou harceler une IA jusqu'à ce qu'elle finisse par avoir raison. Vous pouvez simplement le faire vous-même. C'est extrêmement facile, et honnêtement, c'est presque inquiétant à quel point c'est facile.

Avant de commencer, je supposais que ce serait difficile. J'étais vraiment nerveux en exécutant les premiers tests sans proxy connecté — je m'attendais à être bloqué pour toujours, ou bridé jusqu'à l'oubli. J'attendais des conséquences.

Rien ne s'est passé. Littéralement rien. 150 requêtes sur une page de produit, pas de proxy, pas de blocages, pas d'interdiction, pas d'e-mail furieux. Le mur auquel je me préparais n'était pour l'essentiel pas là, et là où il était (les pages de recherche), un vrai navigateur l'a traversé sans difficulté.

Donc si la seule chose qui vous retenait d'en construire un était l'idée que c'est difficile ou risqué : ce ne l'est pas. Construisez-le. Restez simplement raisonnable, suivez les prix publics, ne martelez pas le site, et respectez leurs conditions. Mais la peur ? Surtout dans votre tête, comme c'était dans la mienne.

Le code complet

Le projet complet — le suivi, l'assistant proxy, les graphiques et les scripts de test — est open source : amazon-price-tracker-python sur GitHub. Clonez-le et exécutez-le, ou parcourez exactement comment ça fonctionne.