Amazon est l'une des plateformes de marché les plus protégées au monde. Son système antibot bloque 90 % des tentatives de collecte automatique de données sur les prix, les stocks et les positions des produits. Pour les vendeurs et les marketeurs, c'est un problème critique : sans données à jour sur les concurrents, il est impossible d'ajuster la stratégie de tarification et de rester rentable.
Dans ce guide, nous allons examiner les mécanismes techniques de protection d'Amazon, montrer des méthodes éprouvées pour contourner l'antibot et configurer un système de surveillance des prix qui fonctionne de manière stable pendant des mois sans blocages.
Pourquoi Amazon bloque le scraping : mécanismes de protection
Amazon perd des millions de dollars à cause du scraping : les concurrents copient les données sur les produits, les prix, les avis, et les vendeurs malhonnêtes utilisent l'automatisation pour manipuler les positions. C'est pourquoi l'entreprise investit d'énormes sommes dans des systèmes antibots qui fonctionnent à plusieurs niveaux simultanément.
Les principaux composants de la protection d'Amazon :
- AWS WAF (Web Application Firewall) — analyse le trafic entrant et bloque les adresses IP suspectes au niveau du réseau. Suit la fréquence des requêtes, la géographie, la réputation des IP.
- Cloudfront CDN — réseau de distribution de contenu distribué avec ses propres algorithmes de filtrage des bots. Vérifie les en-têtes des requêtes, les cookies, les empreintes TLS du navigateur.
- Système de gestion des bots — utilise l'apprentissage automatique pour analyser le comportement des utilisateurs. Suit les mouvements de la souris, la vitesse de défilement, les motifs de clics.
- CAPTCHA et pages de challenge — s'affichent lors d'activités suspectes. Nécessitent de résoudre une énigme ou de saisir un CAPTCHA pour continuer.
- Limitation de taux — restrictions strictes sur le nombre de requêtes d'une seule IP : généralement 10-20 requêtes par minute pour les utilisateurs non connectés.
Tous ces systèmes fonctionnent ensemble et échangent des données. Si l'un d'eux soupçonne un bot, l'IP est mise sur liste noire pendant 24 à 48 heures, voire parfois à jamais.
Important : Amazon affiche des prix différents selon les régions et les types d'utilisateurs. Le blocage ne signifie pas seulement l'absence d'accès, mais aussi l'obtention de données obsolètes, ce qui est critique pour la surveillance des concurrents.
Comment Amazon détecte les bots : 7 signaux principaux
Le système antibot d'Amazon analyse des dizaines de paramètres pour chaque requête. Voici les signaux clés par lesquels il reconnaît l'automatisation :
1. Réputation de l'adresse IP
Amazon maintient une base de données d'adresses IP des centres de données, des services VPN et des proxies publics. Les requêtes provenant de telles adresses reçoivent une attention accrue ou sont immédiatement bloquées. Le système suit également l'historique d'activité : si une IP envoie trop de requêtes vers les pages de produits, cela devient suspect.
Ce qui est vérifié : appartenance à des centres de données connus (AWS, Google Cloud, DigitalOcean), présence dans les bases de données de proxies publics, nombre de requêtes au cours de la dernière heure, géographie (requêtes en provenance de pays inattendus).
2. User-Agent et en-têtes HTTP
De nombreux scrapers utilisent des User-Agent standard de bibliothèques : python-requests/2.28.0 ou n'envoient même pas cet en-tête. Amazon reconnaît instantanément de telles requêtes.
Signes suspects : absence des en-têtes Accept-Language, Accept-Encoding ; incohérence entre User-Agent et d'autres en-têtes (par exemple, User-Agent de Chrome, mais en-têtes comme ceux de Firefox) ; absence de Referer lors de la navigation entre les pages ; anciennes versions de navigateurs.
3. Empreintes TLS/SSL (fingerprinting)
Lors de l'établissement d'une connexion HTTPS, le navigateur envoie un ensemble de paramètres de chiffrement (cipher suites, extensions, version TLS). Cet ensemble est unique à chaque navigateur. Les bibliothèques comme requests ou curl ont des empreintes différentes de celles des véritables navigateurs — Amazon le voit.
4. JavaScript et Canvas fingerprinting
Amazon charge un code JavaScript qui collecte des informations sur le navigateur : résolution d'écran, polices installées, fonctions WebGL prises en charge, paramètres Canvas. Les simples clients HTTP n'exécutent pas JavaScript et se trahissent immédiatement.
5. Cookies et sessions
Amazon établit de nombreux cookies lors de la première visite : session-id, ubid-main, x-main et d'autres. L'absence de ces cookies ou leurs valeurs incorrectes sont des signes de bot. Le système suit également la durée de vie de la session : un utilisateur réel ne fait pas 100 requêtes en 30 secondes.
6. Modèles de comportement
Une personne réelle ouvre la page d'accueil, cherche un produit, navigue dans les catégories, lit les descriptions, revient en arrière. Un bot demande immédiatement des URL spécifiques de produits dans un ordre parfait sans délais.
Modèles suspects : requêtes uniquement vers les pages de produits sans visiter la page d'accueil ; ordre parfait des URL (produit1, produit2, produit3...) ; absence de requêtes vers des ressources statiques (images, CSS, JS) ; intervalles identiques entre les requêtes.
7. Fréquence des requêtes
Même avec une émulation parfaite du navigateur, une fréquence de requêtes trop élevée trahira un bot. Amazon suit le nombre de requêtes d'une IP par minute, heure, jour. Le dépassement des limites (généralement 10-20 requêtes/minute pour les invités) entraîne un blocage.
Choix des proxies pour contourner l'antibot : résidentiels vs centres de données
Le bon choix du type de proxy représente 70 % du succès dans le contournement de la protection d'Amazon. Analysons trois types principaux et leur applicabilité pour le scraping de la plateforme.
| Type de proxy | Niveau de confiance d'Amazon | Vitesse | Utilisation |
|---|---|---|---|
| Résidentiels | Très élevé (IP réelles d'utilisateurs domestiques) | Moyenne (50-150 ms) | Scraping principal, gros volumes |
| Mobiles | Maximal (IP des opérateurs mobiles) | Faible (200-500 ms) | Contourner les blocages stricts, comptes |
| Centres de données | Faible (Amazon connaît ces IP) | Très élevée (10-30 ms) | Tests, tâches ponctuelles |
Proxies résidentiels — le choix optimal
Pour un scraping stable d'Amazon, il est recommandé d'utiliser des proxies résidentiels — ils utilisent des adresses IP réelles d'utilisateurs domestiques, qu'Amazon ne peut pas bloquer massivement sans risquer de bloquer de véritables acheteurs.
Avantages des proxies résidentiels pour Amazon :
- Les IP appartiennent à des fournisseurs d'accès Internet (Comcast, AT&T, Verizon aux États-Unis), et non à des centres de données
- Faible pourcentage de blocages : moins de 2 % avec une bonne configuration de rotation
- Possibilité de choisir la géographie : USA, UK, Allemagne et d'autres pays pour obtenir des prix locaux
- Support des sessions persistantes : une IP peut être utilisée pendant 10-30 minutes pour imiter un utilisateur réel
Paramètres importants lors du choix de proxies résidentiels :
- Taille du pool d'IP : minimum 1 million d'adresses pour une rotation efficace
- Géographie : choisissez un pays où Amazon opère (États-Unis, Royaume-Uni, Allemagne, Japon, etc.)
- Type de rotation : support des sessions persistantes avec une durée de vie de 10-30 minutes
- Protocole : HTTP/HTTPS et SOCKS5 pour la compatibilité avec différents outils
Quand utiliser des proxies mobiles
Les proxies mobiles utilisent des IP d'opérateurs mobiles (4G/5G). Amazon ne bloque pratiquement jamais de telles adresses, car derrière une IP peuvent se trouver des milliers d'utilisateurs réels en raison de la technologie CGNAT.
Quand choisir des proxies mobiles :
- Travailler avec des comptes de vendeurs Amazon (Seller Central) — pour eux, la stabilité de l'IP est critique
- Contourner des blocages stricts après le bannissement des IP résidentielles
- Scraping avec authentification (par exemple, prix pour les abonnés Prime)
- Petits volumes de données (jusqu'à 1000 produits par jour) — les proxies mobiles sont plus chers
L'inconvénient des proxies mobiles est leur coût élevé et leur vitesse inférieure en raison des particularités des réseaux mobiles. Pour le scraping massif de milliers de produits, ils ne sont pas efficaces.
Pourquoi les centres de données ne conviennent pas
Les proxies des centres de données utilisent des IP de serveurs AWS, Google Cloud, DigitalOcean. Amazon reconnaît instantanément de telles adresses — elles figurent dans les bases de données ASN (systèmes autonomes) des centres de données.
Problèmes liés à l'utilisation des centres de données : blocage après 5-10 requêtes ; captchas constantes ; affichage de prix obsolètes ou de pages vides ; bannissement permanent de l'IP après plusieurs tentatives.
Le seul cas où l'on peut utiliser des centres de données est le test d'un scraper sur un petit nombre de produits (10-20) avant de passer à des proxies résidentiels.
Stratégie de rotation des adresses IP : fréquence et géographie
Même avec des proxies résidentiels, une mauvaise rotation des IP entraînera des blocages. Amazon suit le comportement de chaque adresse et bannit celles qui envoient trop de requêtes ou se comportent de manière suspecte.
Fréquence de rotation optimale
Il existe deux approches pour la rotation : après chaque requête (proxies tournants) et avec une durée de vie fixe (sessions persistantes). Pour Amazon, la deuxième option est plus efficace.
Stratégie recommandée pour les sessions persistantes :
- Durée de vie de l'IP : 10-15 minutes — un équilibre optimal entre l'imitation d'un utilisateur réel et le risque de blocage
- Nombre de requêtes par IP : pas plus de 15-20 requêtes pendant la durée de vie de la session
- Délai entre les requêtes : 3-7 secondes (aléatoire, pas fixe !)
- Imitation du comportement : première requête — page d'accueil ou catégorie, puis — pages de produits
Exemple de scénario pour une IP : ouvrir la page d'accueil Amazon.com → attendre 5 sec → ouvrir la catégorie Électronique → attendre 4 sec → ouvrir le produit 1 → attendre 6 sec → ouvrir le produit 2 → ... → après 15 requêtes, changer d'IP.
Conseil pour les charges élevées :
Si vous devez scraper des milliers de produits par heure, utilisez un pool de 50-100 sessions simultanées avec des IP différentes. Chaque session effectue 10-15 requêtes avec des délais, puis change d'IP. Cela donne 500-1500 requêtes par heure sans blocages.
Répartition géographique
Amazon affiche des prix, des assortiments et des conditions de livraison différents en fonction de l'emplacement de l'utilisateur. Pour un suivi correct, il est nécessaire d'utiliser des proxies du même pays que la plateforme cible.
Correspondance des plateformes et géolocalisation des proxies :
- Amazon.com (États-Unis) : utilisez des proxies des États-Unis, de préférence de différents États pour la diversité
- Amazon.co.uk (Royaume-Uni) : proxies du Royaume-Uni
- Amazon.de (Allemagne) : proxies d'Allemagne
- Amazon.co.jp (Japon) : proxies du Japon
Important : n'utilisez pas de proxies d'autres pays pour scraper une plateforme spécifique. Par exemple, les requêtes vers Amazon.com avec des IP d'Inde ou de Russie semblent suspectes et reçoivent souvent des captchas.
Évitez la réutilisation des IP
Même si l'IP n'est pas bloquée, ne la réutilisez pas pendant 2-3 heures. Amazon mémorise l'historique d'activité de chaque adresse. Si la même IP apparaît toutes les 15 minutes pendant la journée, c'est un signe évident d'automatisation.
Règle de rotation : le pool minimum pour un fonctionnement stable est de 500-1000 IP uniques. Cela garantit une diversité suffisante pour que chaque adresse soit utilisée pas plus de 1-2 fois par jour.
Émulation d'un véritable navigateur : en-têtes et empreintes
Même avec des proxies résidentiels et une bonne rotation, le scraper sera bloqué s'il n'émule pas un véritable navigateur. Amazon vérifie des dizaines de paramètres des requêtes HTTP et de l'environnement JavaScript.
En-têtes HTTP corrects
Les simples clients HTTP (requests, curl, wget) envoient un ensemble minimal d'en-têtes qui trahit instantanément un bot. Il est nécessaire de copier les en-têtes d'un véritable navigateur.
En-têtes obligatoires pour Amazon :
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.9 Accept-Encoding: gzip, deflate, br Connection: keep-alive Upgrade-Insecure-Requests: 1 Sec-Fetch-Dest: document Sec-Fetch-Mode: navigate Sec-Fetch-Site: none Sec-Fetch-User: ?1 Cache-Control: max-age=0
Points critiques :
- User-Agent : utilisez une version actuelle de Chrome ou Firefox (vérifiez tous les 2-3 mois). Les anciennes versions de navigateurs sont suspectes.
- Accept-Language : doit correspondre à la géographie des proxies (en-US pour les États-Unis, en-GB pour le Royaume-Uni, de-DE pour l'Allemagne)
- En-têtes Sec-Fetch-* : apparus dans les navigateurs modernes, leur absence est un signe d'un ancien client
- Referer : lors de la navigation entre les pages, envoyez toujours le Referer de la page précédente
Empreinte TLS et contournement
Amazon analyse les paramètres de la connexion TLS : version du protocole, ensemble de chiffrement, extensions. Les bibliothèques standard (OpenSSL dans Python requests) ont des empreintes différentes de celles des navigateurs.
Solution : utilisez des outils qui émulent le TLS des navigateurs :
- curl-impersonate : version de curl qui copie les empreintes TLS de Chrome et Firefox
- tls-client (Python) : bibliothèque avec support du fingerprinting de navigateur
- Playwright/Puppeteer : véritables navigateurs en mode headless — émulation parfaite, mais plus lente
JavaScript et cookies
Amazon exécute du code JavaScript lors du chargement de la page, qui établit des cookies et collecte des informations sur le navigateur. Sans l'exécution de ce code, vous ne recevrez pas de données complètes et serez rapidement bloqué.
Actions obligatoires :
- Utilisez des outils avec support JavaScript : Selenium, Playwright, Puppeteer
- Conservez tous les cookies entre les requêtes dans le cadre d'une session
- Attendez le chargement complet de la page (événement DOMContentLoaded) avant d'extraire des données
- Imitez les actions de l'utilisateur : défilement, pauses aléatoires
Amazon établit des cookies critiques : session-id, ubid-main, x-main. Sans eux, vous obtiendrez un captcha ou une page vide.
Limites de requêtes et délais entre elles
Même une émulation parfaite du navigateur ne vous sauvera pas d'un bannissement si vous faites trop de requêtes. Amazon limite strictement la fréquence des appels d'une seule IP.
Limites documentées d'Amazon
Il n'existe pas de données officielles sur les limites, mais sur la base des tests de la communauté, des valeurs approximatives sont connues :
| Type d'utilisateur | Limite de requêtes/minute | Limite de requêtes/heure |
|---|---|---|
| Utilisateur non connecté | 10-15 | 200-300 |
| Acheteur connecté | 20-30 | 500-800 |
| API Amazon (officiel) | Sans limite | Dépend du tarif |
Le dépassement des limites entraîne un captcha, un blocage temporaire (1-24 heures) ou un bannissement permanent de l'IP en cas de violations systématiques.
Délais optimaux entre les requêtes
Des intervalles fixes (par exemple, exactement 5 secondes) trahissent un bot. Une personne réelle fait des pauses de longueur variable : elle lit la description du produit, compare les prix, se laisse distraire.
Stratégie recommandée pour les délais :
- Délai de base : 3-7 secondes (valeur aléatoire dans la plage)
- Première requête de la session : 5-10 secondes (imitation du chargement de la page d'accueil)
- Après une erreur ou un captcha : 30-60 secondes avant de réessayer
- Entre les changements d'IP : 2-3 secondes pour le "reconnexion"
Exemple de mise en œuvre d'un délai aléatoire : sleep(random.uniform(3, 7)) — chaque pause sera unique.
Répartition de la charge dans le temps
Ne lancez pas le scraping de milliers de produits en même temps à 00h00. Amazon suit les pics d'activité. Répartissez la tâche sur plusieurs heures ou toute la journée.
Exemple : vous devez scraper 5000 produits. Divisez en 10 paquets de 500 produits, lancez chaque paquet avec un intervalle de 1-2 heures. Cela ressemble à une activité organique de différents utilisateurs.
Outils prêts à l'emploi pour le scraping d'Amazon
Écrire un scraper de zéro est difficile et long. Il existe des solutions prêtes à l'emploi qui implémentent déjà le contournement de l'antibot, la rotation des proxies et l'émulation du navigateur.
1. Bright Data Web Scraper IDE
Outil cloud avec des modèles prêts pour Amazon. Ne nécessite pas de programmation — vous configurez les sélecteurs de données via une interface visuelle. Proxies intégrés et contournement de captcha.
Avantages : fonctionne dès la sortie de la boîte, rotation automatique des IP, support de JavaScript. Inconvénients : coûteux (500 $+ par mois), dépendance à un service externe.
2. Octoparse
Application de bureau pour Windows avec un constructeur visuel de scrapers. Il existe une version cloud pour exécuter des tâches 24/7. Supporte l'intégration avec des proxies.
Configuration des proxies dans Octoparse : Paramètres → Paramètres de proxy → ajouter une liste de proxies au format IP:PORT:USER:PASS → activer la rotation.
Avantages : pas besoin de code, interface conviviale, plan gratuit disponible. Inconvénients : limitations sur le nombre de pages dans la version gratuite, difficultés avec les captchas.
3. ScrapingBee API
Service API pour le scraping avec contournement automatique de la protection. Vous envoyez l'URL, vous recevez le HTML. Rotation de proxies intégrée et exécution de JavaScript.
Exemple d'utilisation :
curl "https://app.scrapingbee.com/api/v1/?api_key=YOUR_KEY&url=https://www.amazon.com/dp/B08N5WRWNW&render_js=true&premium_proxy=true&country_code=us"
Avantages : intégration simple, pas besoin de proxies personnels. Inconvénients : payant (à partir de 49 $/mois), limites sur le nombre de requêtes.
4. Playwright + proxies personnels (pour les développeurs)
Si vous savez programmer, la meilleure option est d'utiliser Playwright (ou Puppeteer) avec des proxies résidentiels. Contrôle total sur le processus et coût minimal.
Exemple de configuration des proxies dans Playwright (Python) :
from playwright.sync_api import sync_playwright
import random
import time
proxy_list = [
{"server": "http://proxy1.example.com:8080", "username": "user", "password": "pass"},
{"server": "http://proxy2.example.com:8080", "username": "user", "password": "pass"},
]
with sync_playwright() as p:
proxy = random.choice(proxy_list)
browser = p.chromium.launch(proxy=proxy, headless=True)
context = browser.new_context(
user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
locale="en-US",
timezone_id="America/New_York"
)
page = context.new_page()
# Première requête - page d'accueil
page.goto("https://www.amazon.com")
time.sleep(random.uniform(3, 5))
# Requête produit
page.goto("https://www.amazon.com/dp/B08N5WRWNW")
page.wait_for_load_state("networkidle")
# Extraction des données
title = page.locator("#productTitle").inner_text()
price = page.locator(".a-price-whole").first.inner_text()
print(f"Titre : {title}, Prix : ${price}")
browser.close()
Avantages : contrôle total, moins cher que les services cloud, possibilité d'évoluer. Inconvénients : nécessite des compétences en programmation, besoin de gérer soi-même les captchas.
Recommandations pour le choix de l'outil
| Votre situation | Outil recommandé |
|---|---|
| Je ne sais pas programmer, besoin de 100-500 produits par jour | Octoparse + proxies résidentiels |
| Besoin de tester rapidement une idée, budget disponible | ScrapingBee API |
| Je sais programmer, besoin de milliers de produits | Playwright/Puppeteer + proxies résidentiels |
| Grand budget, besoin de fiabilité maximale | Bright Data Web Scraper |
Que faire en cas de blocage : diagnostic et solutions
Même en respectant toutes les règles, des blocages peuvent parfois survenir. Il est important de comprendre la cause et de corriger rapidement le problème.
Types de blocages et leurs signes
1. CAPTCHA (code d'état 503 ou redirection vers /errors/validateCaptcha) :
- Cause : activité suspecte avec l'IP, mais pas de blocage complet
- Solution : changer d'IP, augmenter les délais entre les requêtes, ajouter une imitation des actions de l'utilisateur
- Automatisation : utiliser des services de résolution de captcha (2Captcha, Anti-Captcha) — mais cela ralentit le scraping
2. Blocage de l'IP (code 403 ou page vide) :
- Cause : l'IP a été mise sur liste noire en raison du dépassement des limites ou de l'utilisation de centres de données
- Solution : changer immédiatement d'IP, vérifier le type de proxy (il se peut que des centres de données soient utilisés au lieu de proxies résidentiels)
- Durée : généralement 24-48 heures, parfois à jamais
3. "Pour discuter de l'accès automatisé aux données d'Amazon, veuillez contacter api-services-support@amazon.com" :
- Cause : Amazon a clairement identifié l'automatisation et propose d'utiliser l'API officielle
- Solution : améliorer l'émulation du navigateur, vérifier l'empreinte TLS, réduire la fréquence des requêtes de moitié
Liste de contrôle pour le diagnostic des problèmes
Si vous recevez des blocages, vérifiez dans l'ordre :
- Type de proxy : assurez-vous d'utiliser des résidentiels et non des centres de données. Vous pouvez vérifier sur whoer.net
- Géographie : l'IP doit provenir du même pays que la plateforme (USA pour .com, UK pour .co.uk)
- User-Agent : version actuelle de Chrome/Firefox (pas plus ancienne que 3-4 mois)
- Cookies : sont-ils conservés entre les requêtes dans le cadre de la session
- JavaScript : est-il exécuté (si vous utilisez Playwright/Puppeteer — il doit être exécuté)
- Fréquence des requêtes : pas plus de 10-15 par minute d'une seule IP
- Délai : aléatoire, pas fixe
- Rotation des IP : chaque adresse est utilisée pas plus d'une fois toutes les 2-3 heures
Mesures d'urgence en cas de blocages massifs
Si la plupart des requêtes sont bloquées (plus de 30 %) :
- Arrêtez le scraping pendant 2-3 heures — laissez Amazon "oublier" votre activité
- Changez de fournisseur de proxy — il se peut que le pool d'IP soit déjà compromis
- Réduisez la charge de 3 à 5 fois — au lieu de 100 requêtes par heure, faites 20-30
- Changez pour des proxies mobiles — ils sont pratiquement jamais bloqués, même s'ils sont plus chers
- Ajoutez plus d'imitation humaine : transitions aléatoires entre les catégories, recherche de produits via la barre de recherche, et non des URL directes
Attention : Si votre IP est bannie à jamais (blocage de plus de 72 heures), ne tentez pas de l'utiliser à nouveau. Amazon retire rarement les bans permanents. Passez à un nouveau pool de proxies.
Conclusion
Contourner l'antibot d'Amazon est une tâche complexe qui nécessite une combinaison de proxies appropriés, une émulation précise du navigateur et des limites de requêtes raisonnables. Les points clés pour un scraping réussi : utiliser des proxies résidentiels du même pays que la plateforme ; rotation des IP toutes les 10-15 minutes avec une limite de 15-20 requêtes par session ; émulation complète d'un navigateur moderne avec des en-têtes corrects et exécution de JavaScript ; délais aléatoires de 3-7 secondes entre les requêtes.
En respectant ces règles, le pourcentage de requêtes réussies atteint 95-98 %, et les blocages deviennent rares. L'essentiel est de ne pas se précipiter et d'imiter le comportement d'un utilisateur réel, plutôt que d'essayer de scraper des milliers de produits en quelques minutes.
Pour un fonctionnement stable avec Amazon, nous recommandons d'utiliser des proxies résidentiels...