Début août 2026, des dizaines d'acheteurs Amazon ont découvert qu'ils ne voyaient sur la fiche produit que huit avis — sans tri, sans filtres, sans possibilité d'ouvrir les autres. Aucun avertissement n'a été donné. Le service client a expliqué que cela était dû à une violation des conditions d'utilisation « en ce qui concerne la collecte et l'extraction de contenu communautaire ». Autrement dit, la plateforme a pris des personnes réelles pour des scrapers.
L'histoire aurait semblé être un simple incident si elle n'avait pas coïncidé avec un autre événement : le 4 août 2026, la Cour d'appel du neuvième circuit a annulé l'injonction judiciaire qui bloquait l'agent IA Perplexity Comet. Le chemin juridique pour lutter contre l'automatisation a échoué — et presque simultanément, le cadre technique s'est considérablement durci. Analysons ce qui s'est passé et pourquoi cela change les règles du jeu pour tous ceux qui collectent des données publiques.
Que s'est-il passé : huit avis et appel de cinq jours
Des restrictions massives ont été signalées les 3 et 4 août 2026 par TechSpot, Android Authority et Shopifreaks. Le tableau pour les victimes est le même :
- sur n'importe quel produit, seuls 8 avis sont disponibles au lieu de la liste complète ;
- les outils de tri et de filtrage des avis ont disparu ;
- aucune notification de restriction — l'utilisateur en prend connaissance par lui-même ;
- pour lever le blocage, il faut écrire au support et attendre une réponse jusqu'à cinq jours ouvrables.
Un des victimes, Fred Hall, a rencontré cette restriction à la mi-juillet en étudiant des déshumidificateurs. L'opérateur du chat a évoqué une violation des Conditions d'utilisation concernant l'extraction de contenu utilisateur ; l'appel a été approuvé quelques jours plus tard sans explications. Le deuxième cas est plus révélateur : Sean Kaufman a reçu la même limite de huit avis sur tous les produits consécutivement. Il n'utilise ni VPN, ni bloqueurs de publicité, ni navigateurs IA — sa seule particularité est qu'il compare longuement des produits concurrents et lit attentivement les avis. Amazon lui a proposé 10 dollars sur son compte, et l'accès a été rétabli après cinq jours.
Le commentaire officiel de l'entreprise est le suivant : « Nous comprenons qu'il pourrait y avoir eu des cas isolés où les clients n'ont pas pu accéder aux avis, et nous avons travaillé pour garantir l'accès ». Cependant, Amazon a refusé de divulguer des détails significatifs : ni le nombre de comptes touchés, ni le comportement qui déclenche le détecteur, ni la date de début des restrictions, ni les principes d'examen des appels. Selon les discussions, des plaintes individuelles ont été signalées depuis novembre 2025 — ce qui signifie que le mécanisme fonctionne depuis longtemps, mais qu'il est devenu visible en août.
Pourquoi maintenant : le tribunal a retiré à Amazon un outil pratique
Pour comprendre le contexte, il est nécessaire de retracer la chronologie du conflit entre Amazon et Perplexity.
- Novembre 2024 — novembre 2025. Amazon, selon ses propres déclarations, a envoyé à Perplexity au moins cinq avertissements exigeant de cesser les achats d'agents au nom des utilisateurs.
- Août 2025. Amazon met en place une barrière technique contre Comet. Selon Amazon, Perplexity a publié un contournement dans les 24 heures, déguisant son agent en session Chrome ordinaire au lieu de se présenter honnêtement.
- 10 mars 2026. La juge Maxine Chesney à San Francisco délivre une injonction préliminaire : Comet ne peut pas accéder aux sections protégées par mot de passe d'Amazon et acheter au nom de l'utilisateur. La formulation clé est que l'agent agit « avec l'autorisation de l'utilisateur d'Amazon, mais sans autorisation de la part d'Amazon ».
- 4 août 2026. Le neuvième circuit annule l'injonction. Le tribunal a estimé qu'Amazon avait peu de chances de gagner en vertu de la Computer Fraud and Abuse Act : lorsque l'utilisateur confie une tâche à l'assistant, c'est l'utilisateur lui-même qui accède aux serveurs d'Amazon via l'assistant, et non Perplexity. La CFAA exige de prouver un accès non autorisé intentionnel et un préjudice supérieur à 5000 dollars par an — ces éléments n'ont pas été observés par le tribunal.
Amazon a répondu qu'il « ne s'accorde pas respectueusement » avec la décision et se réserve le droit de demander un réexamen. L'affaire devant le tribunal de San Francisco n'est pas close — seule l'injonction préliminaire a été annulée. Mais le signal a déjà été envoyé au marché : la tentative d'assimiler les actions d'un agent agissant sur ordre direct d'un humain à un piratage ne passe pas encore devant les tribunaux.
Perplexity, d'ailleurs, a toujours soutenu que le procès ne protège pas la sécurité, mais les revenus publicitaires : l'agent achète des produits en contournant l'affichage publicitaire que voit l'humain. L'argument n'est pas si farfelu : le secteur publicitaire d'Amazon était évalué à 56 milliards de dollars dès 2025, et tous ces revenus dépendent du fait qu'un acheteur vivant consulte lui-même la vitrine.
Que reste-t-il à la plateforme lorsque le tribunal n'aide pas
Amazon mène depuis longtemps une bataille sur deux fronts. En plus des tribunaux, l'entreprise ferme systématiquement l'accès aux crawlers IA via robots.txt : dans la liste des bloqués se trouvent des bots de Meta, Google, Huawei et Mistral, et même plus tôt — des crawlers d'Anthropic, Perplexity et Google Project Mariner. Pour comparaison : Walmart et eBay n'ont pas mis en place de tels blocages dans robots.txt. Le problème est que robots.txt est une demande, et non une barrière : il ne fonctionne qu'avec ceux qui choisissent de le respecter.
Voici donc une étape logique — transférer la protection à un niveau où il n'est pas nécessaire de demander de consentement. C'est exactement ce qui se passe avec les avis : au lieu de bloquer des bots spécifiques par leur nom, la plateforme commence à évaluer le comportement de la session et à réduire l'affichage pour ceux dont le modèle ressemble à celui d'une machine. Les avis sont l'actif le plus précieux et le plus copié du marché, c'est pourquoi l'expérimentation a commencé avec eux.
Le problème pratique de cette approche est les faux positifs. La classification comportementale repose sur la dynamique d'interaction : le rythme et la vitesse des mouvements, les pauses, la séquence des transitions, la profondeur et la répétabilité des consultations. Une personne qui compare méthodiquement dix modèles de déshumidificateurs et ouvre tous les avis de chacun d'eux consécutivement, selon ces métriques, ressemble exactement à un parser. Le cas de Kaufman est une illustration pédagogique : IP propre, navigateur ordinaire, aucune automatisation, et pourtant un ban.
Conclusion principale : un IP propre n'est plus un laissez-passer
Pour ceux qui collectent des données publiques, cette histoire entraîne une réalité désagréable. Auparavant, la logique était simple : réputation de l'IP mauvaise — blocage, réputation bonne — accès. Maintenant, Amazon a montré que la décision peut être prise malgré des signaux réseau idéaux. L'utilisateur est assis avec un fournisseur domestique, de son pays, dans un véritable Chrome, avec un historique d'achats complet sur des années — et il est quand même soumis à une restriction parce qu'il lit trop d'avis consécutivement.
Cela change les priorités dans l'infrastructure de collecte de données. Un proxy résidentiel de qualité est toujours nécessaire — sans lui, vous ne passerez même pas le premier niveau de filtres et ne verrez pas le même affichage qu'un acheteur local. Mais ce n'est plus une condition suffisante : si un robot avec un rythme machine fonctionne sur un bon IP, le détecteur vous attrapera au deuxième niveau. Une analyse détaillée de la façon dont ce niveau est structuré se trouve dans notre article sur la biométrie comportementale et les proxies.
Que faire en pratique
- Séparez « personnel » et « professionnel » physiquement. Si vous surveillez les prix et les avis des concurrents depuis le même navigateur et la même IP où vous vous connectez à votre compte d'acheteur, vous risquez de compromettre à la fois vos données et votre compte. Un profil séparé, une adresse de sortie distincte, une session distincte.
- Un pool — une tâche. La surveillance du Buy Box, la collecte d'avis et la vérification de la disponibilité ne doivent pas passer par le même ensemble d'adresses : ces tâches ont des motifs de requêtes différents, et les mélanger signifie collecter une empreinte composite, qui est plus visible que n'importe quel composant.
- Limitez la profondeur par session. Huit avis ne sont pas un nombre aléatoire : c'est le seuil en dessous duquel la plateforme considère l'intérêt comme normal. Collectez les avis par portions à travers différentes sessions au lieu de tirer toute la filière d'un seul coup.
- Maintenez un rythme humain. Des pauses aléatoires, une vitesse de transition irrégulière, une séquence naturelle (fiche produit → avis → retour à l'affichage) coûtent moins cher que de faire tourner mille adresses sur une rafale de requêtes.
- Surveillez la dégradation, pas seulement les erreurs. Le plus sournois dans l'approche d'Amazon est que vous ne recevez pas un 403. Vous recevez un HTTP 200 avec un contenu réduit. Un parser qui ne vérifie que le code de réponse écrira pendant des mois dans la base huit avis sur trois mille et n'émettra aucun signal d'alarme. Ajoutez une vérification de la complétude : le nombre d'éléments, la présence de pagination, la présence d'un bloc de filtres.
- Prévoyez une réserve. Selon l'étude State of Web Scraping 2026 (Apify et The Web Scraping Club), 65,8 % des spécialistes ont commencé à utiliser plus de proxies qu'un an auparavant, et 58,3 % ont augmenté leurs budgets — alors que les prix par gigaoctet tendaient globalement à diminuer. Ce n'est pas le prix qui augmente, mais le volume et la complexité nécessaires. 43,1 % des équipes ont déjà deux ou trois fournisseurs pour assurer la résilience.
Il convient également de garder à l'esprit la tendance opposée : pendant que certaines plateformes masquent leurs filtres, l'industrie tente de légaliser les « bons » robots — via une signature cryptographique des requêtes et une identification explicite de l'agent. Comment cela fonctionne, nous l'avons examiné dans l'article sur Web Bot Auth et les agents signés. Le problème est qu'un agent signé se livre par définition à la merci de la plateforme : Amazon est ravi de savoir qu'il a affaire à un bot — et refusera.
Qui sera touché dans les mois à venir
La réduction discrète de l'affichage au lieu d'un blocage franc est une technique facilement reproductible. Il est fort probable que nous la voyions chez d'autres plateformes : elle est moins coûteuse qu'un captcha, ne nuit pas aux métriques de rebond et ne donne pas au scraper un signal clair qu'il a été détecté.
Les scénarios où la complétude des données est importante, et non simplement le fait d'accéder, sont les plus à risque : analyse des avis pour l'analyse de produits, surveillance de la réputation, formation de modèles sur du contenu utilisateur, renseignement concurrentiel des vendeurs. Si vous travaillez avec une marketplace, il est utile de relire les pratiques de base pour contourner les filtres — par exemple, notre analyse sur la protection anti-bot d'Amazon lors du scraping des prix — et d'ajouter à cela une vérification de l'incomplétude de la réponse.
Cela touche aussi les gens ordinaires. Un utilisateur pris pour un bot perd exactement la fonction pour laquelle il est venu sur la marketplace : la possibilité de lire ce que les autres disent du produit. Ni avertissement, ni explication, ni délai de rétablissement clair — juste un message au support et cinq jours d'attente.
Conclusion
Août 2026 a marqué un tournant. La cour du neuvième circuit a en fait déclaré : un agent agissant sur ordre d'un humain est un humain, et ne peut pas être soumis à la loi sur les abus informatiques. Les plateformes ont compris la réponse et ont déplacé la lutte là où les décisions sont prises sans tribunal — dans les filtres comportementaux de leur propre frontend. Les dommages collatéraux sous forme d'acheteurs vivants avec une limite de huit avis les préoccupent modérément, selon les commentaires d'Amazon.
La conclusion pour la pratique est simple : l'infrastructure de collecte de données n'est plus une question de « trouver un bon IP ». Un bon IP est un billet d'entrée, et ensuite vous êtes évalué en fonction de votre comportement et de vos demandes. Planifiez votre budget, la profondeur des requêtes et le contrôle de la complétude de la réponse en fonction de cela — et vérifiez non seulement que les données sont arrivées, mais aussi qu'elles sont arrivées en quantité suffisante.
```