Les agents IA peuvent légalement visiter votre site

Le 4 août 2026, la cour d'appel fédérale du Neuvième Circuit a annulé l'injonction préliminaire qui empêchait depuis mars le navigateur Comet de Perplexity d'effectuer des achats sur Amazon. C'est la première décision d'appel fédérale au monde sur la question de savoir si un agent IA agissant pour le compte d'un utilisateur peut légalement accéder à une plateforme qui n'en veut pas.

Si vous exploitez un site, une boutique en ligne ou une API, cette décision change l'outil auquel vous recourez pour défendre votre infrastructure — pas votre capacité à la défendre.

Ce qui s'est réellement passé

La chronologie est courte et mérite d'être exacte, car beaucoup de commentaires la déforment :

L'argument central d'Amazon reposait sur le Computer Fraud and Abuse Act (CFAA) — la loi anti-piratage américaine de 1986. Sa thèse : Comet se faisait passer pour Chrome, contournait les systèmes de détection de bots, se connectait à des comptes clients protégés par mot de passe, et accédait donc aux ordinateurs d'Amazon « sans autorisation » après que la mise en demeure eut révoqué toute permission.

La formation d'appel n'a pas suivi, pour un motif technique et non politique. La question posée par le CFAA est : qui a accédé à l'ordinateur ? Et la réponse, compte tenu de l'architecture de Comet, est : l'utilisateur.

C'est le navigateur de l'utilisateur qui envoie la requête à Amazon. C'est sa machine qui affiche la page localement. Il transmet ensuite des captures d'écran aux serveurs de Perplexity pour que le modèle décide de l'action suivante. L'infrastructure de Perplexity n'ouvre jamais de connexion vers Amazon. Comme l'a formulé la cour : le navigateur de l'utilisateur visite Amazon ; les serveurs de Perplexity reçoivent ce que l'utilisateur leur envoie.

La cour a refusé de traiter l'assistant comme un acteur juridique autonome, le qualifiant d'outil et non de personne au sens de la loi, et a relevé qu'il n'existe pratiquement aucune jurisprudence sur l'attribution de responsabilité aux agents IA au titre de ce texte. Face à cette ambiguïté dans une loi pénale, elle a appliqué la règle de l'interprétation stricte — le doute profite à l'absence de responsabilité. La formation a également observé que la lecture d'Amazon exposerait des utilisateurs ordinaires à une responsabilité pénale pour les logiciels qu'ils choisissent d'exécuter, et qu'une injonction visant un comportement qui ne viole vraisemblablement pas le CFAA ne servirait pas l'intérêt public.

Ce que la cour n'a pas tranché

C'est la partie que la plupart des résumés omettent, et c'est celle qui compte sur le plan opérationnel.

La décision porte sur le CFAA, au stade de l'injonction préliminaire, et sur une architecture précise fonctionnant côté client. Elle n'a pas jugé que :

• Vos conditions d'utilisation sont inapplicables. La responsabilité contractuelle reste une thèse vivante et n'a pas été tranchée. La procédure d'Amazon se poursuit devant le tribunal fédéral de San Francisco.
• Bloquer les agents est illégal. Rien dans la décision ne vous oblige à servir qui que ce soit. Les contre-mesures techniques restent parfaitement licites.
• Les agents côté serveur bénéficient du même traitement. Le raisonnement repose sur le fait que c'est la machine de l'utilisateur qui émet la requête. Un agent qui récupère vos pages depuis le datacenter d'un éditeur est une situation différente, et probablement une issue différente.
• Les actions en trouble de jouissance, enrichissement sans cause ou fondées sur le droit des États échouent. Intactes.

La portée du changement est donc étroite et précise : le marteau pénal du piratage n'est plus disponible contre un agent délégué par l'utilisateur et exécuté côté client. Le contrat, les contrôles techniques et les conditions commerciales le restent tous. Amazon a indiqué son désaccord et pourrait solliciter un réexamen ou saisir la Cour suprême.

Une catégorie pour laquelle le web n'a jamais été conçu

Le problème de fond révélé par cette affaire est une erreur de modélisation. Tout système de contrôle d'accès conçu avant 2025 trie le trafic en deux cases : humains et bots. Un agent agissant sur instruction directe d'un client connecté n'est ni l'un ni l'autre, et les règles écrites pour ce binaire produisent des absurdités appliquées à lui.

Considérez les conséquences pratiques d'une erreur dans chaque sens. Bloquez indistinctement les agents délégués et vous bloquez vos propres clients payants, qui découvrent de plus en plus votre boutique à travers un assistant. Autorisez tout et vous perdez la capacité de distinguer l'agent d'achat d'un client de la flotte de scraping tarifaire d'un concurrent — les deux ressemblant désormais à une véritable session Chrome sur une IP résidentielle.

Le filtrage par chaîne User-Agent est terminé comme mécanisme de contrôle. Le camouflage présumé de Comet en Chrome en est précisément l'illustration : tout client qui affiche votre page localement peut présenter l'identité de son choix, et la décision ne lui donne aucune raison juridique de s'en abstenir.

Choisissez une posture, puis construisez-la

Trois positions sont cohérentes. Choisissez-en une délibérément par surface — la bonne réponse pour votre catalogue public est rarement la bonne réponse pour un tunnel de paiement authentifié.

1. Les accueillir. Traitez le trafic agent comme un canal de distribution. C'est le bon choix pour les surfaces de contenu, de catalogue et de documentation, où la découverte est tout l'enjeu. Cela suppose de publier un llms.txt, de fournir des données structurées propres, de garder le contenu critique hors des chemins de rendu uniquement JavaScript, et d'envisager un point d'accès MCP pour que les agents vous interrogent correctement au lieu de scraper des captures d'écran.

2. Les encadrer. Servez les agents via un chemin authentifié, limité en débit et encadré commercialement. C'est là que devraient se situer la plupart des acteurs e-commerce et SaaS pour leurs surfaces transactionnelles : une API agents avec clés, quotas et conditions, plutôt que de tolérer une automatisation de navigateur non déclarée sur votre tunnel de paiement.

3. Les bloquer. Position légitime, inchangée par la décision — mais comprenez qu'après Amazon c. Perplexity, votre levier d'exécution est contractuel et technique, non le droit pénal fédéral. Dites-le explicitement dans vos conditions, et attendez-vous à perdre ce trafic.

Ingénierie de la voie médiane

La primitive technique qui rend la posture encadrée praticable est l'identité cryptographique de l'agent. Web Bot Auth, fondé sur les signatures de messages HTTP (RFC 9421), permet à un agent bien élevé de signer ses requêtes avec une clé que vous vérifiez auprès d'un annuaire publié. Le trafic non signé n'est pas automatiquement hostile : il est simplement non attesté, et relève d'une autre catégorie avec d'autres limites.

La classification recherchée est ternaire, pas binaire :

// middleware.ts — classifier avant de décider
import { NextResponse, type NextRequest } from 'next/server'
import { verifyBotSignature } from '@/lib/agent-identity'
 
type Visitor = 'verified-agent' | 'unattested' | 'session-user'
 
export async function middleware(req: NextRequest) {
  const signature = req.headers.get('signature')
  const hasSession = Boolean(req.cookies.get('session'))
 
  let visitor: Visitor = 'unattested'
  let agentId: string | null = null
 
  if (signature) {
    const result = await verifyBotSignature(req)
    if (result.valid) {
      visitor = 'verified-agent'
      agentId = result.keyId
    }
  } else if (hasSession) {
    visitor = 'session-user'
  }
 
  const res = NextResponse.next()
  res.headers.set('x-visitor-class', visitor)
  if (agentId) res.headers.set('x-agent-id', agentId)
  return res
}
 
export const config = { matcher: ['/api/:path*', '/products/:path*'] }

Trois règles découlent de cette classification, et c'est là que se trouve le vrai travail :

Limitez le débit sur l'identité, pas sur l'IP. Une clé d'agent signée est un sujet stable, mesurable et révocable. Une adresse IP ne l'est pas — les proxys résidentiels et les agents côté client en font du bruit. Allouez généreusement aux agents vérifiés, par clé ; serrez fortement l'automatisation non attestée, par empreinte comportementale.

Séparez la lecture de l'écriture. Un agent délégué qui lit votre catalogue coûte peu et vous sert probablement. Le même agent qui finalise un achat, change une adresse ou résilie un abonnement relève d'une tout autre classe de risque. Les actions à conséquence méritent une étape de confirmation qui atteint l'humain, pas seulement l'agent — ce qui constitue aussi votre défense contre l'injection de prompt, car un agent manipulé enverra une requête parfaitement bien formée.

Écrivez la politique. Vos conditions d'utilisation doivent distinguer les agents délégués par l'utilisateur des crawlers non supervisés, et énoncer votre position sur chacun. Ce document est désormais votre principal instrument d'exécution. S'il se contente encore d'interdire « tout accès automatisé », il décrit un web qui n'existe plus.

Pourquoi cela compte dans la région MENA

Il n'existe pas de CFAA en Tunisie, en Arabie saoudite ou aux Émirats. Les opérateurs régionaux n'ont jamais disposé du levier pénal américain — l'exécution y a toujours reposé sur le contrat, sur les législations saoudienne et émirienne en matière de cybercriminalité, de facture très différente, et sur ce que votre infrastructure peut réellement imposer. Le Neuvième Circuit a, en pratique, rapproché les plateformes américaines de la position où les équipes régionales se trouvaient déjà.

L'implication concrète est concurrentielle plus que juridique. Les achats médiatisés par assistants arrivent sur les marchés arabophones via les mêmes navigateurs et modèles mondiaux, et les boutiques régionales lisibles par un agent — données structurées, sélecteurs stables, balisage arabe propre, véritable API — seront celles par lesquelles les transactions passeront. Celles qui sont un labyrinthe JavaScript derrière une détection de bots agressive seront simplement écartées, en silence, sans message d'erreur ni événement analytique pour vous prévenir.

Si vous construisez pour le commerce agentique, la décision lève une incertitude sur la viabilité juridique du canal. Elle ne lève pas le travail d'ingénierie.

À faire cette semaine

• Mesurez la part de trafic déjà automatisée, et combien vos règles actuelles en bloqueraient.
• Décidez votre posture par surface : contenu public, lecture authentifiée, écriture transactionnelle.
• Relisez vos conditions d'utilisation à la recherche de la catégorie « agent délégué par l'utilisateur ». La plupart ne l'ont pas.
• Déplacez la limitation de débit de l'IP vers l'identité partout où c'est possible.
• Publiez des données structurées et un llms.txt si vous voulez le trafic de découverte.

Le message de la cour est plus étroit que ne le suggèrent les titres : le CFAA n'est pas le bon instrument pour ce litige. Le message d'ingénierie, lui, est plus large. Le trafic agent est une classe d'accès permanente, votre infrastructure est la couche d'exécution, et la configuration par défaut que la plupart des sites font encore tourner a été conçue pour un web où chaque visiteur était une personne.

Pour le détail des mécaniques d'identité et de vérification, consultez notre guide sur l'ingénierie du trafic des agents IA avec Web Bot Auth et le standard navigateur WebMCP.

Besoin d'aide pour définir une politique agents sur votre plateforme ? Noqta accompagne les équipes e-commerce et SaaS en Tunisie et dans le Golfe sur l'architecture prête pour les agents, des données structurées aux points d'accès MCP et à la limitation de débit par identité signée.