L'agent : un outil, pas une personne - Le neuvième arrondissement annule l'interdiction d'Amazon sur Perplexity

Le 4 août 2026, la Cour d'appel du neuvième circuit des États-Unis a annulé l'injonction préliminaire qui, depuis mars, empêchait le navigateur agent Perplexity Comet d'accéder aux comptes des utilisateurs sur Amazon. Formelement, il s'agit d'un litige entre deux entreprises concernant les achats via l'IA. En réalité, c'est la première décision d'appel qui répond à une question importante bien au-delà du commerce agent : qui exactement « accède » à un serveur tiers lorsque la demande est envoyée par une automatisation. Et la réponse de la cour s'est étonnamment heurtée non pas au droit, mais à l'architecture réseau.

Ce qui s'est passé : du procès à l'annulation de l'injonction

La chronologie du litige est la suivante :

• Novembre 2025 — Amazon intente une action en justice contre Perplexity AI, se référant à la loi fédérale sur la fraude et les abus informatiques (CFAA) et à son équivalent californien. La réclamation : l'agent Comet se connecte aux comptes des utilisateurs, consulte des produits et initie des achats, c'est-à-dire qu'il opère dans une zone protégée par mot de passe sans autorisation de la plateforme elle-même.
• Contexte — selon Amazon, la société a averti Perplexity au moins cinq fois depuis novembre 2024, en août 2025, elle a mis en place une barrière technique, mais Perplexity a publié une mise à jour contournant celle-ci en moins de 24 heures. Un autre reproche : l'agent se faisait passer pour une session normale de Google Chrome.
• 9 mars 2026 — La juge Maxine Chesney (District Nord de Californie) rend une injonction préliminaire et ordonne de détruire les données obtenues auprès d'Amazon. Sa formule : l'accès se faisait avec l'autorisation de l'utilisateur d'Amazon, mais sans autorisation de la part d'Amazon.
• 4 août 2026 — Le neuvième circuit (affaire n° 26-1444) annule l'injonction : Amazon a peu de chances de gagner sur le fond des réclamations CFAA.

Amazon a déclaré qu'elle n'était pas d'accord avec la décision et poursuivra le litige. Perplexity a répondu qu'elle défendrait le droit des utilisateurs de choisir n'importe quelle IA. L'affaire, quant à elle, n'a pas disparu : le procès en première instance se poursuit, et Amazon peut demander un réexamen ou aller plus haut.

Mouvement clé : l'agent est un outil, pas une personne

Le CFAA punit l'accès à un « ordinateur protégé » sans autorisation. Tout le litige se résume à un verbe : qui a effectué l'acte d'accès. Amazon affirmait — Perplexity, car c'était son agent qui agissait sur la plateforme. Perplexity répondait — l'utilisateur, qui a donné l'ordre à l'agent.

La Cour d'appel a pris la seconde position et l'a formulée clairement : quel que soit le degré d'avancement de l'agent, aux fins de la loi « c'est un outil, pas une personne » — un outil, et non une personne. Lorsque l'utilisateur confie à l'agent de faire quelque chose sur Amazon.com, l'accès aux ordinateurs d'Amazon est effectué par l'utilisateur lui-même.

C'est la suite logique de la ligne de la Cour suprême dans l'affaire Van Buren v. United States (2021), qui a restreint le CFAA : la loi punit l'intrusion là où il n'y a pas d'accès du tout, et non l'utilisation d'un accès légal « à des fins non autorisées ». L'utilisateur d'Amazon a un compte et a le droit d'y accéder. L'outil par lequel il le fait ne devient pas en soi un sujet de piratage.

Pourquoi tout a été décidé par l'architecture du trafic

La partie de la décision la plus intéressante pour les praticiens est technique. La cour a examiné comment Comet Assistant est physiquement conçu, et c'est précisément cela qui a déterminé le résultat.

Le schéma de fonctionnement est le suivant : l'agent prend des captures d'écran de la fenêtre du navigateur sur la machine de l'utilisateur, les envoie aux serveurs de Perplexity, et de là viennent des instructions de navigation — de retour sur l'ordinateur de l'utilisateur, qui exécute les actions. Les serveurs de Perplexity ne communiquent pas directement avec les serveurs d'Amazon. Tout le trafic que voit Amazon provient de l'appareil et de l'adresse IP de l'utilisateur lui-même.

D'où la conclusion de la cour. Si la demande provient physiquement de l'utilisateur, alors c'est lui qui a effectué l'« accès » au sens du CFAA.

En quoi cela diffère-t-il de Power Ventures

Jusqu'à présent, l'histoire canonique sur l'accès tiers avec le consentement de l'utilisateur était l'affaire Facebook v. Power Ventures (2016). Là, la cour a décidé que la plateforme pouvait révoquer l'accès à un service tiers, même si les utilisateurs lui avaient volontairement transmis leurs identifiants. C'est précisément sur ce précédent que s'est appuyée la juge de première instance, l'étendant aux agents IA.

Le neuvième circuit a distingué ces affaires sur un seul critère — et encore une fois sur un critère architectural. Dans Power Ventures, les systèmes du défendeur envoyaient directement des messages à la plateforme Facebook, contournant la machine de l'utilisateur. Perplexity n'a pas ce canal. Une topologie de trafic différente — une réponse différente à la question « qui a obtenu l'accès ».

Le sens pratique de cette distinction est difficile à surestimer. Cela signifie que la conception du système — un agent client sur l'appareil de l'utilisateur ou un service serveur accédant à la plateforme depuis sa propre infrastructure — a cessé d'être un choix purement technique et est devenu un argument juridique.

Ce que la décision N'A PAS fait

La cour a elle-même essayé de limiter au maximum le rayon d'action et a clairement stipulé qu'elle ne créait pas un nouveau régime juridique pour l'IA agent. Ce qui est resté en dehors des considérations :

• Violation des conditions d'utilisation. Les réclamations découlant du contrat, du délit et des règles de la plateforme ne sont pas couvertes par la décision — elles peuvent être présentées séparément.
• Actions contre les utilisateurs eux-mêmes. Si l'accès est effectué par l'utilisateur, alors la plateforme peut choisir de s'adresser à lui.
• Architectures serveur. La conclusion a été faite pour un schéma spécifique. Un scraper cloud ou un agent SaaS accédant à la plateforme depuis sa propre infrastructure ne tombe pas automatiquement sous cette logique.
• Blocages techniques. Aucun mot dans la décision n'interdit à Amazon de détecter et de couper l'automatisation. Le droit de bloquer n'a pas disparu — la possibilité de soutenir le blocage par un article pénal a disparu.

C'est, d'ailleurs, un retournement de la situation habituelle : auparavant, le risque juridique pesait sur celui qui automatisait, et la protection technique était considérée comme une seconde ligne. Maintenant, pour les plateformes, la protection technique est devenue la première ligne.

Ce que cela change en pratique

Pour tous ceux qui collectent des données, automatisent des comptes ou construisent des agents, la décision entraîne trois conclusions opérationnelles.

1. Le point de sortie du trafic a acquis un poids juridique

Auparavant, le choix entre « faire passer tout par son propre centre de données » et « travailler à partir d'adresses indiscernables de celles des utilisateurs » était une question de faisabilité et de coût. Maintenant, c'est aussi une question de qui est considéré comme l'auteur de la demande. L'architecture, où la demande à la plateforme provient du côté de l'utilisateur, s'est révélée plus défendable en justice — et en même temps, elle passe historiquement mieux les filtres anti-bots. C'est un cas rare où l'incitation juridique et technique coïncident et pointent dans la même direction : vers des proxies résidentiels et des points de sortie utilisateurs au lieu de sous-réseaux serveur. Pour des tâches neutres comme la surveillance des prix publics ou la vérification des résultats par région, des proxies de centre de données restent suffisants — il n'y a ni zone de connexion, ni litige sur le compte de quelqu'un.

2. Le CFAA s'est affaibli — le contrat et la détection se sont renforcés

Il ne faut pas lire la décision comme « maintenant c'est permis ». La plus lourde massue — l'article fédéral avec un potentiel criminel — a été retirée. Il restent l'accord utilisateur, le blocage de compte, la poursuite civile et, surtout, le stack anti-bots. Les plateformes, ayant perdu une partie de leur levier juridique, compenseront cela par la détection : par le fingerprinting, l'analyse comportementale et les agents signés. Nous avons examiné comment l'industrie tente de légaliser les « bons » bots par des moyens techniques dans un article sur Web Bot Auth et les agents signés.

3. Le risque s'est déplacé vers l'utilisateur final

Le revers de la victoire de Perplexity : si l'utilisateur agit, alors c'est l'utilisateur qui est responsable. Pour les services qui offrent aux clients l'automatisation comme produit, c'est l'occasion de clarifier dans la documentation au nom de qui et avec quelle adresse IP les actions sont effectuées et quelles règles de la plateforme sont concernées.

Que faire dès maintenant

1. Décrivez votre topologie d'accès. Répondez à une question : quelle adresse IP la plateforme cible voit-elle dans les journaux — votre serveur ou celle de l'utilisateur. Cela dépend de la position juridique et du profil de détection.
2. Séparez le public et le connecté. La collecte de pages ouvertes et les actions à l'intérieur d'un compte tiers sont fondamentalement des histoires différentes en termes de risque. Il ne faut pas les mélanger dans un même pipeline.
3. Ne vous camouflez pas de manière agressive après une interdiction directe. Dans cette affaire, c'est précisément le contournement de la barrière établie et la substitution du client par Chrome qui ont donné à Amazon les faits les plus solides. La réclamation CFAA s'est effondrée, mais les autres motifs sont toujours valables.
4. Choisissez le type de sortie en fonction de la tâche. Le côté pratique — comment déployer un agent sur Playwright ou MCP et envelopper correctement son trafic — a été examiné en détail dans le guide sur les proxies pour les agents IA.

Conclusion

Le neuvième circuit n'a pas légalisé l'automatisation et n'a pas donné aux agents un laissez-passer pour aller n'importe où. Il a fait quelque chose de plus étroit, mais de plus important : il a lié le concept d'« accès » à l'endroit d'où provient physiquement la demande. L'outil fonctionnant sur la machine de l'utilisateur n'effectue pas d'accès — c'est l'homme qui le fait. L'infrastructure qui accède à la plateforme depuis elle-même reste dans la zone des anciens risques.

Pour le marché, cela signifie un déplacement du centre de gravité. Le litige juridique sur la question de « est-ce permis » se heurtera de plus en plus à la question technique « quelle adresse figure dans le journal ». Et la lutte pour l'accès se déplace définitivement là où elle s'est toujours déroulée — dans la détection anti-bots, le fingerprinting et la qualité des points de sortie.