Amazon Nova Act peut raisonner sur une page web et agir dessus. En 2026, la partie difficile d’un agent web en production n’est pas le modèle. C’est l’accès au web : atteindre le web en direct de manière fiable, avec le bon ciblage géographique, tout en restant conforme. Cet article associe Nova Act à la couche d’accès web de Bright Data pour les agents IA, et les mesures présentées ici proviennent d’exécutions réelles.
TL;DR
Le goulot d’étranglement pour un agent web IA en production est l’accès au web, pas le modèle. La solution est une division : Amazon Nova Act prend les décisions multi-étapes dans le navigateur, et la couche d’accès web de Bright Data gère l’accès, la conformité et l’échelle. Le rapport Données pour l’IA 2026 de Bright Data révèle que 97 % des organisations IA dépendent des données web en temps réel, et 90 % affirment que les restrictions d’accès limitent leurs initiatives IA.
Le script exécutable complet, avec chaque import, schéma et helper, se trouve dans le dépôt associé. Clonez-le si vous souhaitez l’exécuter, ne copiez pas depuis ici.
Pour suivre, vous avez besoin de Python 3.10+, pip install nova-act, et d’une clé API Nova Act depuis nova.amazon.com/act. Vous avez également besoin d’un compte Bright Data avec une zone Browser API, plus une clé API pour les appels à la couche de données. Node.js n’est nécessaire que pour la section Web MCP.
Pourquoi le comportement par défaut de l’agent navigateur est insuffisant
L’approche évidente avec un agent navigateur est de tout lui laisser faire. Ouvrir une page, fermer la bannière de cookies, faire défiler, extraire. Ça fonctionne bien dans une démo, mais pour la plupart des travaux de données, ce n’est pas le bon réflexe par défaut.
- C’est lourd. Une seule page consommateur réelle (une recherche eBay) a transféré environ 3,4 Mo via le navigateur. Multipliez par des millions de pages et vous payez pour déplacer tout le web rendu, images comprises, pour extraire trois champs.
- C’est fragile à l’action. Pointé sur booking.com, Nova Act a levé
ActActuationErroren combattant les popups et le contenu chargé en différé, même si la page se chargeait correctement. Les lectures simples sont généralement fiables. L’actuation multi-étapes lourde s’y effondre. - C’est non déterministe. La fiabilité chute rapidement. Dix étapes fiables à 90 % donnent environ
0,9¹⁰ ≈ 35 %sans planification adéquate.
Rien de tout cela ne rend les agents navigateurs inutiles. Utilisez-les pour ce qu’eux seuls peuvent faire (les actions et décisions multi-étapes), et déléguez tout le reste à l’infrastructure.
Ce qu’est Amazon Nova Act, et ce qu’il n’est pas
Nova Act est un SDK AWS, version 3.4.x mi-2026, passant de la préversion de recherche vers la production, pour créer des agents navigateur en Python. Son concept de conception est l’opposé d’un seul grand prompt. Vous décomposez un workflow en commandes petites, atomiques et fiables, reliées par du Python ordinaire. Les deux commandes sont une action et une lecture typée :
from nova_act import NovaAct
from pydantic import BaseModel
class Product(BaseModel):
title: str | None = None
price: str | None = None
availability: str | None = None
with NovaAct(starting_page="https://example.com/product/123") as nova:
nova.act("search for wireless headphones") # an action
data = nova.act_get( # a typed read
"Return the product title, price, and availability.",
schema=Product.model_json_schema(),
)Avec un schéma Pydantic, act_get peut transformer une page en données typées sans sélecteurs fragiles. Nova Act pilote un vrai Chromium via Playwright en dessous, un détail qui compte pour la connexion. Nova Act vous offre le raisonnement, la navigation et l’extraction structurée. Il ne fournit aucune réponse à l’hostilité du web ouvert. Il n’a ni portée géographique, ni déblocage à l’échelle, ni conformité intégrée. Ce n’est pas son rôle. C’est le rôle de la couche d’infrastructure.
Bright Data, la couche d’accès web
La couche est construite autour d’une idée : débloquer le web pour votre IA. Web MCP, un serveur Model Context Protocol, donne à un agent des outils web structurés qu’il appelle directement. Le Web Unlocker et l’API SERP renvoient des pages et résultats de recherche propres. Les API Web Scraper et les Jeux de données effectuent la récupération structurée en masse. La Browser API est un Chrome cloud piloté à distance, pour les cas où un agent doit agir. En dessous, un réseau de 400 M+ d’IPs résidentielles dans 195 pays, avec la gestion des défis CAPTCHA courants, la gestion des empreintes et le ciblage géographique.
Dans l’enquête Données pour l’IA 2026 de Bright Data, 87 % des organisations s’accordent à dire qu’un « internet à deux niveaux » émerge, un web agentique de trafic automatisé fonctionnant parallèlement au web humain. Et 65 % s’appuient déjà sur un fournisseur dédié d’infrastructure de données web plutôt que de construire l’accès en interne.
C’est une couche, pas un outil. Votre pile d’agents change. La couche d’accès web en dessous ne change pas. Donc la question d’ingénierie n’est jamais navigateur versus API dans l’abstrait. Vous divisez le travail en deux : l’agent gère les décisions, l’infrastructure gère l’accès.
L’architecture, le cerveau en haut et l’infrastructure en dessous
Nova Act envoie des actions vers le bas, et des données structurées remontent.
Nova Act prend les décisions et les actions. La couche d’accès web de Bright Data gère l’accès, la conformité, la géographie et l’échelle, puis atteint le web en direct.
Pour le mode action, Nova Act se connecte à la Browser API de Bright Data via le Chrome DevTools Protocol (CDP), le même protocole que Playwright (et donc Nova Act) parle déjà. Vous échangez le navigateur et gardez l’agent.
La connexion et les erreurs de configuration à prévoir
Créez une zone Browser API (son solveur CAPTCHA est activé par défaut) et le tableau de bord vous donne une URL :
wss://brd-customer-<id>-zone-<name>:<password>@brd.superproxy.io:9222Cette chaîne provient de l’onglet Vue d’ensemble de la zone, sous Détails d’accès.
Les détails d’accès de la zone Browser API. Le tableau de bord vous fournit la chaîne wss:// avec les identifiants intégrés, la forme auth+@host affichée en haut du panneau. Playwright moderne rejette cette forme intégrée, donc split_cdp() déplace les identifiants dans un en-tête Authorization: Basic. La liste blanche d’IP à gauche est l’autre piège. Si votre IP n’y figure pas, l’appel renvoie un corps vide et la raison arrive dans les en-têtes de réponse plutôt que dans le code de statut.
L’erreur Invalid URL : Playwright rejette les identifiants wss:// intégrés
Collez-le directement dans Nova Act et ça échoue :
playwright._impl._errors.Error: BrowserType.connect_over_cdp:
Invalid URL: wss://brd-customer-...:[email protected]:9222C’est un échec courant à la première exécution. Playwright moderne, version 1.56, fourni avec Nova Act 3.4, rejette les identifiants intégrés dans une URL WebSocket. Le tableau de bord affiche la forme intégrée car elle fonctionne avec les anciens clients, pas avec le Playwright intégré à Nova Act. La solution est d’extraire les identifiants et de les passer dans un en-tête Authorization: Basic via cdp_headers.
import os
import base64
def split_cdp(raw_url: str) -> tuple[str, dict | None]:
"""Bright Data gives an inline-credential wss URL; Playwright rejects that.
Move credentials into a Basic auth header. (Parsed manually because
Python 3.14's urlsplit also rejects the multi-colon netloc.)"""
scheme, sep, rest = raw_url.partition("://")
if not sep or "@" not in rest:
return raw_url, None
creds, _, hostport = rest.rpartition("@")
user, _, pwd = creds.partition(":")
token = base64.b64encode(f"{user}:{pwd}".encode()).decode()
return f"{scheme}://{hostport}", {"Authorization": f"Basic {token}"}
endpoint, headers = split_cdp(os.environ["BRIGHTDATA_CDP_URL"])
with NovaAct(starting_page=URL, cdp_endpoint_url=endpoint, cdp_headers=headers,
logs_directory="runs/demo") as nova: # NOTE: logs dir must already exist
...Le piège intermittent InvalidScreenResolution
L’autre grand piège est la fenêtre d’affichage. Le navigateur distant de Bright Data donne à Nova Act une fenêtre d’environ 1280×585, plus petite que les environ 1600×900 attendus par Nova Act. Nova Act ne se dégrade pas gracieusement. Il lève une erreur InvalidScreenResolution ActError intermittente. C’est intermittent car chaque session cloud obtient une taille légèrement différente. Cela rend le diagnostic difficile, et facile à confondre avec un agent instable nécessitant une nouvelle tentative. Forcez une taille supportée sur la page connectée :
with NovaAct(starting_page=URL, cdp_endpoint_url=endpoint, cdp_headers=headers,
screen_width=1600, screen_height=900, logs_directory="runs/demo") as nova:
nova.page.set_viewport_size({"width": 1600, "height": 900}) # force a supported size to stop InvalidScreenResolution
...Deux pièges mineurs : StartFailed et un logs_directory manquant
Ne passez pas headless=True avec cdp_endpoint_url, car le navigateur distant est déjà sans interface et vous obtenez StartFailed. Et logs_directory doit exister avant le démarrage, car Nova Act valide le chemin et ne le crée pas.
À quoi sert l’agent
Une fois la connexion établie, la question est de savoir quoi faire faire à l’agent. Une lecture simple est ce qu’il offre de moins distinctif, et les API Web Scraper de Bright Data font cela mieux et moins cher. Un agent vaut plus qu’un Scraper car il peut agir.
Son action la plus utile est d’atteindre des données derrière un formulaire. Il n’y a pas d’URL statique à connaître à l’avance et pas d’API, donc un Scraper n’a rien à cibler. Un agent peut remplir le formulaire et lire le résultat. Nous avons donc pointé Nova Act sur Drugs@FDA, la base de données officielle d’approbation des médicaments aux États-Unis, et lui avons demandé de récupérer une fiche médicament :
nova.act("Search for the drug named ibuprofen") # fill the form, submit
drug = nova.act_get("Return the brand name, active ingredient, application number, "
"and marketing status of the first result.", schema=Drug.model_json_schema())Sa propre trace montre un flux en quatre étapes qu’aucune URL ne capture. Il a saisi dans le champ de recherche et appuyé sur Entrée, trouvé le premier résultat réduit et cliqué pour le développer, navigué vers la page de détail, puis lu les champs :
{'drug_name': 'ACETAMINOPHEN AND IBUPROFEN', 'active_ingredient': 'ACETAMINOPHEN; IBUPROFEN',
'application_number': '214836', 'marketing_status': 'Over-the-counter'} # all 4 DOM-groundedCes quatre étapes, dans le navigateur :
Un enregistrement réel de l’exécution, image par image. Nova Act recherche « ibuprofen » sur Drugs@FDA, ouvre le premier résultat et lit ANDA #214836, le même numéro d’application que celui retourné par l’exécution.
Nous l’avons testé sur différents médicaments pour confirmer la cohérence : aspirin a donné 8-HOUR BAYER (#016030), et metformin a donné ACTOPLUS MET (#021842). Avec ibuprofen, c’est 3/3, chaque champ ancré. C’est là que l’agent justifie son coût. L’agent remplit le formulaire et accède à des données publiques faisant autorité, derrière un formulaire, qu’un Scraper ne peut pas atteindre. Ancrer l’IA dans des données publiques du web profond est un vrai problème. Sur un site coopératif et bien structuré, c’est fiable.
La longue traîne
La même approche couvre la longue traîne, les sites de niche sans Scraper préconçu. Les API Web Scraper de Bright Data couvrent déjà plus de 100 des sites à forte valeur. Pointé sur BoardGameGeek, Nova Act a retourné une fiche propre à six champs, Catan / 1995 / 3,4 joueurs / 60,120 min / note 7,1 / prix le plus bas. Vous le vérifiez par rapport au DOM en direct via nova.page, le handle Playwright, dans la même session :
assert game.parsed_response["bgg_rating"] in nova.page.inner_text("body") # 7.1 -> presentDeux leçons d’ancrage ont émergé. Normalisez avant de comparer, car le tiret demi-cadratin de la page 3,4 contre le trait d’union de l’agent 3-4 est une fausse discordance, pas une hallucination. Et vérifiez en session, jamais après, car un prix de marché en direct était ancré au moment de l’extraction et disparu au rechargement, donc une vérification en deuxième passe de données volatiles peut être erronée. Avec ceux-ci, les six champs étaient ancrés. Cela a tenu sous une exécution concurrente à cinq voies également.
La frontière concerne le terrain, pas la tâche. Nova Act peine sur les sites consommateurs hostiles comme eBay et booking.com : e-commerce défendu par des bots avec des murs de cookies, des widgets de variation personnalisés et du contenu chargé en différé. Sur ces sites, les actions multi-étapes ralentissent et deviennent instables, et les chaînes lourdes expirent. Il est fiable sur les sites coopératifs et structurés : bases de données publiques, applications internes et formulaires bien construits. Il est fragile sur les sites consommateurs hostiles. Gardez les actions peu nombreuses, vérifiez chaque champ avec nova.page, réessayez, et laissez la couche de données de Bright Data gérer les cas hostiles et à fort volume.
Ce que le routage géographique change réellement
Aucun navigateur local ne fait cela sans la même infrastructure de routage en dessous. Nous avons effectué la même recherche d’hôtel sur un grand site de réservation, routé à travers trois pays en ajoutant -country-XX au nom d’utilisateur Bright Data :
| Routé via | Devise | Exemples de tarifs nuitée |
|---|---|---|
| États-Unis | US$ | US$30, US$128, US$171 |
| Royaume-Uni | £ | £30, £167, £194 |
| Allemagne | € | €40, €194, €225 |
La devise change proprement et les prix reflètent de vraies différences de marché, pas une conversion. Nous avons lu ces trois avec un navigateur brut, car la géographie est le travail de l’infrastructure, pas de l’agent. L’agent extrait quel que soit le marché sur lequel il est pointé, comme pour l’exécution eBay routée vers les États-Unis. Cela est important pour la surveillance des prix concurrentiels, l’agrégation de tarifs, ou tout cas où vous devez voir les choses comme un client local.
Ce qui compte pour une exécution, c’est l’IP de sortie, donc nous avons vérifié chaque session routée. Les IPs de sortie se sont révélées être de vrais FAI grand public, pas des plages de centres de données : un grand fournisseur câble américain, un opérateur haut débit britannique, un réseau mobile allemand, un opérateur japonais et un FAI régional brésilien.
C’est la différence entre paraître local et l’être vraiment. La requête arrive comme un vrai utilisateur résidentiel dans ce pays. Ainsi, les prix, l’inventaire et le traitement anti-bot sont bien plus proches de ce qu’un client local voit que de ce qu’obtient une plage de centres de données signalée.
La conformité, le problème des 90 %
C’est là que les restrictions d’accès comptent, le problème des 90 % lui-même : la plupart des organisations IA affirment que ces restrictions limitent leurs initiatives IA. Ici Bright Data agit comme garde-fou. Pointé sur un site de métarecherche de vols, l’agent a été refusé :
Page.navigate: Requested URL (kayak.com/flights/...) is restricted in accordance
with robots.txt. Ask your account manager to get full access (brob)Un navigateur local brut a extrait le même site sans problème quelques instants plus tôt. Bright Data a refusé. Refuser est le comportement le plus capable, pas le plus faible. Bright Data applique robots.txt et soumet les cibles sensibles à des vérifications KYC par défaut, une approche qu’une équipe juridique d’entreprise peut approuver.
Pour la plupart des cibles d’entreprise, vous êtes tranquille. Dans nos vérifications, booking.com, Expedia, Hotels.com, Airbnb, eBay, Best Buy et Tripadvisor ont tous été autorisés. Les cibles restreintes sont une conversation avec le Gestionnaire de compte, pas un contournement. L’infrastructure gère la conformité côté accès pour que votre code n’ait pas à le faire.
Le budget de coût et de fiabilité
Un responsable des achats pose deux questions : quelle est la fiabilité, et quel est le coût.
Fiabilité
La fiabilité a un levier principal et un plafond dur. Le levier est la correction de la fenêtre d’affichage. Avant de la définir, environ la moitié de toutes les exécutions échouaient sur InvalidScreenResolution, et ce seul bug représentait la majeure partie de ce qui ressemblait à un agent instable.
Après la correction, nous l’avons mesuré sur un vrai site, pas un bac à sable. Une lecture eBay concurrente à cinq voies a retourné 5/5, chaque valeur confirmée dans le DOM en direct via nova.page, en 47s contre environ 198s en séquentiel, soit 4,2×. Chaque session a utilisé une nouvelle IP Bright Data, ce qui évite de concentrer les requêtes sur une seule IP.
Ce n’est pas une mise à l’échelle linéaire gratuite. Nous avons poussé à 12 concurrent et 8 sur 12 sont revenus propres. C’est le plafond de concurrence des niveaux gratuit et paiement à l’utilisation, pas l’agent qui casse. Le volume entreprise réel signifie augmenter la limite de concurrence de la zone et budgéter les nouvelles tentatives, sans supposer que cinq sessions passent à cinq mille gratuitement.
Le gain de la concurrence est réel mais pas linéaire. Au-delà du plafond de concurrence du plan, 8 lectures concurrentes sur 12 sont revenues propres.
Une seule action légère (trier, puis lire) a nécessité des nouvelles tentatives occasionnelles, et les échecs restants étaient des StartFailed transitoires au démarrage de session. Donc décomposez le travail en petites étapes idempotentes, enveloppez-les dans des nouvelles tentatives, budgétisez environ 1,2 à 1,5×, et vérifiez chaque sortie avec nova.page.
La limite restante est le terrain. Du côté structuré, ça reste fiable. Trois recherches Drugs@FDA ont chacune suivi le même flux : remplir, soumettre, cliquer-développer, naviguer, extraire. Les trois sont revenues 3/3, chaque champ ancré, bien que lentes à environ 50 à 90 secondes chacune. Du côté consommateur, les chaînes multi-étapes ralentissent encore et expirent.
Les chiffres de fiabilité en un coup d’œil :
| Scénario | Résultat | Ce que ça signifie |
|---|---|---|
| Avant la correction de la fenêtre d’affichage | ~la moitié des exécutions ont échoué | InvalidScreenResolution, l’échec dominant |
| Lecture concurrente à 5 voies, post-correction (eBay) | 5/5 ancrés | 47s vs ~198s séquentiel, 4,2×, nouvelle IP par session |
| Poussé à 12 concurrent (brut) | 8/12 | le plafond de concurrence paiement à l’utilisation, pas l’agent |
| Action légère unique (trier, puis lire) | nouvelle tentative occasionnelle | les échecs sont des StartFailed réessayables |
| Formulaire FDA multi-étapes, 3 médicaments | 3/3 ancrés | site coopératif, mais lent à ~50,90s chacun |
Coût
Le coût de bande passante est mesurable, et le coût du modèle est la question ouverte. La Browser API facture par Go, environ 8 $/Go en paiement à l’utilisation (tous les prix ici sont ceux de mi-2026). Nous avons mesuré le poids réel des pages via celle-ci :
| Type de page | Poids | Browser API @ 8 $/Go |
|---|---|---|
| Page consommateur lourde (recherche eBay) | ~3,4 Mo | ~0,027 $/page → ~27 $ / 1 000 pages |
| Page légère (produit sandbox) | ~0,2 Mo | ~0,0016 $/page → ~1,60 $ / 1 000 pages |
Ajoutez le multiplicateur de nouvelles tentatives, puis ajoutez le coût d’inférence de Nova Act, qui n’est pas publiquement tarifé aujourd’hui. Le niveau gratuit mesure ce que vous collectez, et les exécutions en production passent par AWS sans prix publié. Donc le budget se résume à deux lignes. La bande passante de la Browser API est un poste connu et prévisible. L’inférence de l’agent est le coût à confirmer avec AWS avant de passer à l’échelle.
Déplacer 3,4 Mo pour extraire trois champs est aussi la raison pour laquelle, pour le travail en masse, vous ne pilotez pas du tout un navigateur. La couche de données facture par requête plutôt que par gigaoctet. L’API SERP et Web Unlocker coûtent environ 1,50 $ pour 1 000, contre ~27 $ pour 1 000 pages lourdes via le navigateur.
Quand utiliser l’agent, et quand utiliser la couche de données
Bright Data fournit Web MCP et les API Web Scraper pour que vous ne pilofiez pas un navigateur pour tout. La ligne de démarcation est la complexité décisionnelle :
- Extraction fixe à schéma connu, comme le prix et le stock pour 100 000 SKUs. N’utilisez pas d’agent. Une API Web Scraper retourne juste la fiche, sans page de 3,4 Mo, sans coût d’inférence, et avec bien moins d’échecs transitoires. C’est moins cher et plus fiable.
- Raisonnement qu’un Scraper ne peut pas capturer : navigation multi-étapes, logique conditionnelle (par exemple, le tarif remboursable le moins cher répondant à vos contraintes), soumission de formulaire, QA d’application web, ou un portail inconnu sans Scraper préconçu. C’est là que Nova Act et la Browser API justifient leur coût.
La règle : si vous pouvez l’exprimer comme une extraction fixe ou un appel API, faites-le. Dans les systèmes réels, les deux se composent. Nova Act pilote le flux décisionnel et passe la récupération en masse aux API structurées de Bright Data.
La couche de données en pratique
« Utilisez la couche de données pour le volume » est le conseil habituel. Voici, exécuté sur le même compte Bright Data, trois appels, sans navigateur, sans agent.
Recherche structurée en un appel (API SERP), des résultats de recherche analysés frais pour ancrer une IA, retournés en JSON :
requests.post("https://api.brightdata.com/request",
headers={"Authorization": f"Bearer {BRIGHTDATA_TOKEN}"},
json={"zone": "serp_api2", "format": "raw", # gl/hl pin the locale so results are stable
"url": "https://www.google.com/search?q=amazon+nova+act+sdk&brd_json=1&gl=us&hl=en"})9 organic results → 1. github.com/aws/nova-act · 2. nova.amazon.com/act · 3. docs.aws.amazon.com/nova-act …N’importe quelle URL vers du markdown propre prêt pour LLM (Web Unlocker), la même fiche médicament FDA que notre agent a atteinte en remplissant un formulaire, récupérée directement :
json={"zone": "web_unlocker", "format": "raw", "data_format": "markdown",
"url": "https://www.accessdata.fda.gov/.../ApplNo=214836"}→ 8,4 Ko de markdown propre, un seul appel, sans navigateur, sans gestion de CAPTCHA, sans analyse.Une source connue vers juste la fiche structurée (API Web Scraper), déclenchez un collecteur préconçu et obtenez des champs propres, jamais la page. Nous avons exécuté le Scraper Crunchbase pour une entreprise :
requests.post("https://api.brightdata.com/datasets/v3/trigger?dataset_id=gd_l1vijqt9jfj7olije",
headers={"Authorization": f"Bearer {BRIGHTDATA_TOKEN}"},
json=[{"url": "https://www.crunchbase.com/organization/anthropic"}]) # -> snapshot_id, then poll→ 89 champs structurés (employés, siège, rang CB, statut, financement …),
prêts en ~70s, sans navigateur, sans agent, sans page de 3,4 Mo, sans analyse.Le contraste est l’architecture. L’agent était le bon outil ici car vous deviez agir pour atteindre les données. Aucune URL n’existait, donc il a cherché le formulaire et navigué vers l’application 214836. Une fois qu’une URL existe, ou que vous avez besoin de résultats de recherche ou d’enregistrements en masse à schéma connu, vous ne pilotez pas un navigateur. Vous appelez la couche de données. C’est plus déterministe, plus rapide et moins cher, avec bien moins du budget de fiabilité de l’agent. Nova Act découvre et agit. La couche de données de Bright Data récupère à l’échelle.
L’agent appelle directement les outils de Bright Data
Les intégrations jusqu’ici sont orchestrées manuellement. Nous avons appelé SERP et Web Unlocker, puis donné à l’agent un navigateur. Il existe une intégration plus étroite. Vous donnez à Nova Act le serveur Web MCP de Bright Data comme outils, et l’agent lui-même décide quand chercher, extraire ou découvrir. Nova Act fonctionne sur le framework Strands d’AWS, donc il accepte les outils MCP directement :
from strands.tools.mcp import MCPClient
from mcp import StdioServerParameters
from mcp.client.stdio import stdio_client
bd_mcp = MCPClient(lambda: stdio_client(StdioServerParameters(
command="npx", args=["-y", "@brightdata/mcp"], env={"API_TOKEN": BRIGHTDATA_TOKEN})))
with bd_mcp:
tools = bd_mcp.list_tools_sync() # search_engine, scrape_as_markdown, discover, batch…
with NovaAct(starting_page="https://example.com", tools=tools,
cdp_endpoint_url=endpoint, cdp_headers=headers) as nova:
nova.act_get("Use the search_engine tool to find 'Amazon Nova Act SDK'; "
"return the top result's URL.", schema=Out.model_json_schema())Nous l’avons exécuté, et la propre trace de l’agent le montre. « L’appel d’outil a réussi et a retourné des informations sur la recherche. Le premier résultat organique est ‘https://github.com/aws/nova-act’… » et il a retourné {'top_result_url': 'https://github.com/aws/nova-act'}. L’agent a lui-même choisi l’outil search_engine de Bright Data, Bright Data a exécuté la recherche, et l’agent a utilisé le résultat. Cela a pris un seul appel act, environ 32s, sans Scraping d’une page de recherche sur laquelle un agent navigateur serait probablement bloqué de toute façon.
C’est la différence entre utiliser deux outils ensemble et un agent qui appelle l’autre lui-même. L’agent obtient cinq outils directement dans cette exécution : search_engine, scrape_as_markdown, search_engine_batch, scrape_batch et discover. C’est un chemin propre et conforme pour les tâches qu’un agent navigateur fait le moins bien : recherche et récupération en masse.
Le pipeline combiné, largeur et profondeur
Chaque composant jusqu’ici est autonome. Combinés, ils construisent un enregistrement d’intelligence structuré et ancré sur un sujet. Vous tirez la largeur du web ouvert, et la profondeur d’une source faisant autorité derrière un formulaire. Nous l’avons exécuté sur les médicaments GLP-1, une catégorie pharmaceutique très médiatisée :
# 1. BREADTH , Bright Data SERP API discovers authoritative sources (no browser)
sources = serp_api("Ozempic semaglutide")[:3]
# 2. FETCH , Bright Data Web Unlocker pulls the top source as markdown (no browser)
context = web_unlocker(sources[0])
# 3. DEPTH , Nova Act fills the Drugs@FDA form for the authoritative record (agent)
fda = nova_act_fda("semaglutide") # verified against the live DOMSortie réelle, de bout en bout :
{
"web_sources": ["ozempic.com", "mayoclinic.org/…semaglutide…", "accessdata.fda.gov/…/209637lbl.pdf"],
"web_context_chars": 59270,
"fda_authoritative": {"drug_name": "OZEMPIC", "active_ingredient": "SEMAGLUTIDE",
"application_number": "209637", "marketing_status": "Discontinued"},
"fda_grounded": true
}Chaque moitié a fait quelque chose que l’autre ne pouvait pas. La couche de données a cherché le web ouvert en deux appels API et a retourné trois sources faisant autorité et 59 Ko de contexte propre prêt pour LLM, sans navigateur et sans agent. L’agent est allé là où la couche de données ne pouvait pas atteindre seule. Il a rempli le formulaire de recherche FDA et navigué vers l’enregistrement réglementaire faisant autorité, application 209637, statut Discontinued pour cette ligne de produit, des données derrière un formulaire sans URL.
Et les deux se confirment mutuellement. La couche de données a retourné indépendamment l’étiquette FDA 209637lbl.pdf pour le même numéro d’application que l’agent a atteint en agissant. La largeur confirme la profondeur.
Cette exécution montre aussi un échec à planifier. L’étape FDA de l’agent a échoué sur le nom de marque « Ozempic », avec ActAgentFailed trois fois, et a réussi sur le principe actif « semaglutide ». C’est le coût de fiabilité du terrain. C’est pourquoi vous vérifiez avec fda_grounded: true et budgétisez les nouvelles tentatives.
Le même pipeline, une industrie différente
Cela fonctionne au-delà de la pharmacie, et nous l’avons vérifié. Nous avons exécuté le pipeline identique sur une autre industrie, la conformité financière. SERP a trouvé la présence web de la société, son propre site et un profil de données financières. L’agent a navigué sur BrokerCheck de la FINRA (une application Angular plus difficile que le formulaire de la FDA) vers le dossier réglementaire faisant autorité d’un courtier-négociant : nom de la société, numéro CRD, régulateur et nombre de divulgations. Il s’est ancré en une nouvelle tentative.
De la pharma à la finance, le même pipeline a fonctionné sans modifications de code au-delà de la requête et du schéma. Il devrait s’étendre de la même manière à la tarification concurrentielle, à l’étude de marché et à la surveillance de la sécurité des produits. La couche de données gère la largeur et l’échelle, l’agent gère la profondeur protégée, et les champs de l’agent sont ancrés par rapport à la page en direct.
D’un seul enregistrement à un marché
Cela passe aussi d’un seul enregistrement à un marché. Nous avons exécuté le pipeline identique sur le marché des médicaments GLP-1 et obtenu un jeu de données concurrentiel structuré. La couche de données a géré la largeur tandis que l’agent fournissait le dossier FDA faisant autorité de chaque médicament :
| Principe actif | Marque FDA | App # | Statut | Source principale (SERP) |
|---|---|---|---|---|
| semaglutide | OZEMPIC | 209637 | Prescription | drugs.com |
| tirzepatide | MOUNJARO | 215866 | Prescription | ncbi.nlm.nih.gov |
| liraglutide | LIRAGLUTIDE | 212552 | Prescription | drugs.com |
L’exécution sur le marché a même révélé une divergence en direct. L’application 209637 affichait Discontinued dans l’exécution à enregistrement unique ci-dessus et Prescription dans ce tableau. Une application FDA peut contenir plusieurs enregistrements de produits avec des statuts différents, donc chaque lecture d’agent est un instantané d’une ligne. C’est exactement pourquoi vous vérifiez chaque lecture.
Le reCAPTCHA non scripté
Un moment que nous n’avions pas scripté a illustré l’architecture par lui-même. Sur deux des trois recherches, le site FDA a présenté un reCAPTCHA à l’agent.
Le vrai reCAPTCHA que l’agent a rencontré sur Drugs@FDA, capturé en cours d’exécution. Le garde-fou de Nova Act a refusé de le résoudre. La session a quand même atteint l’enregistrement, car elle s’exécute sur la Browser API de Bright Data.
Le garde-fou de Nova Act a refusé de le traiter comme une énigme à résoudre. D’après sa trace, mot pour mot, « Je ne dois pas me faire passer pour un humain, ni me présenter comme tel en résolvant des captchas ou tout autre défi. » C’est le comportement que vous souhaitez d’un agent autonome.
Il a quand même passé, car la session s’exécute sur la Browser API de Bright Data. Un navigateur local nu ne pouvait même pas charger le site FDA. Ce navigateur a expiré deux fois à 90 secondes, bien qu’il ait atteint example.com correctement dans la même exécution. Il n’a atteint ni le CAPTCHA ni les données. La session Bright Data a atteint l’enregistrement.
Donc la division du travail est réelle et vérifiée. L’agent ne résout pas les CAPTCHAs. Il ne le fera pas, et il ne devrait pas. La couche de données ne peut pas naviguer dans le formulaire. Seul l’agent sur Bright Data termine le travail.
Le CAPTCHA est intermittent, et une exécution brute ultérieure n’en avait aucun. Ces deux recherches d’agent avec CAPTCHA ont pris environ 1m50s et 2m37s de friction réelle. Le jeu de données est de trois lignes, mais le schéma s’applique à tout un marché.
C’est Nova Act et Bright Data combinés. Aucun des deux outils ne résout ça seul.
Limitations
- Nova Act est encore précoce. À mi-2026, c’est une préversion de recherche, en anglais uniquement, avec un niveau gratuit qui limite vos interactions. Il affiche « Amazon collecte des données sur les interactions dans cette version » à chaque exécution. La production est couplée à AWS, avec IAM, S3 et Bedrock AgentCore. Confirmez les conditions et la tarification de production avec AWS avant de construire quoi que ce soit de critique dessus.
- L’agent est fragile sur les sites consommateurs à popups nombreux. Sur booking.com, l’
ActActuationErrorétait l’agent qui se battait avec la page, pas Bright Data qui échouait à la servir. Préférez les URLs de résultats directs, fermez les popups explicitement, comptez sur le budget de nouvelles tentatives, ou déchargez vers la couche de données. - La conformité a deux faces. C’est le garde-fou que vous voulez, mais les cibles restreintes impliquent une étape de Gestionnaire de compte ou de vérification KYC, alors planifiez le délai. Et la légalité du Scraping pour l’IA est contestée en 2026, avec des arrêts sur les données publiques, l’AI Act européen et des procès en droits d’auteur encore en cours. Les données publiques ne signifient pas une permission automatique, donc impliquez votre équipe juridique.
- La détection est une course aux armements. L’empreinte des agents et le paiement par exploration s’intensifient continuellement. Rester en avance est un travail continu, c’est exactement pourquoi la couche est une dépendance gérée plutôt qu’un correctif ponctuel.
- Un navigateur autonome est une surface d’attaque. Les pages peuvent contenir des injections de prompt qui orientent l’agent, et les propres docs de Nova Act le signalent. Limitez-le. Utilisez des listes blanches et des listes noires d’URL, et tenez-le éloigné des pages dont il n’a pas besoin. Gérez les entrées sensibles comme les identifiants et les paiements via Playwright direct avec
nova.page, plutôt que de laisser le modèle les saisir.
Prochaines étapes
Remplacez Nova Act par l’agent de l’année prochaine et la division s’applique toujours : la couche en dessous est la partie durable. Commencez donc par classer le travail, pas l’outil. Si la cible a une URL stable ou un collecteur préconçu, envoyez-la à la couche de données et ignorez le navigateur. Réservez Nova Act pour ce qui nécessite une action : un formulaire à remplir, un chemin multi-étapes, un portail sans Scraper derrière lui.
Pour tout ce que vous prévoyez d’exécuter plus d’une fois, définissez ces éléments dès la première session :
- Déplacez les identifiants intégrés de la zone dans un en-tête
Authorization: Basic, et ajoutez votre IP à la liste blanche de la zone. Omettez l’un ou l’autre et vous obtenezInvalid URLou un corps vide avec la raison dans les en-têtes de réponse. - Forcez une fenêtre d’affichage 1600×900 sur la page connectée, et créez
logs_directoryavant le démarrage de l’exécution. - Ancrez chaque champ extrait par rapport à
nova.pagedans la même session, et budgétisez 1,2 à 1,5× pour les nouvelles tentatives.
Quand une zone n’arrive plus à suivre, augmentez sa limite de concurrence avant d’accuser l’agent. Déplacez la récupération en masse vers l’API SERP, Web Unlocker ou une API Web Scraper. La Browser API et Web MCP sont tous deux disponibles avec un niveau gratuit, donc vous pouvez tester la division avant de vous engager. Les cibles restreintes sont une conversation avec le Gestionnaire de compte, pas un contournement.
Le script exécutable pour chaque démo ici se trouve dans le dépôt associé. Clonez-le, pointez-le sur votre propre cible, et voyez quelle moitié de la division votre travail nécessite réellement.
Questions fréquentes
Qu’est-ce qu’Amazon Nova Act ?
Amazon Nova Act est un SDK AWS pour créer des agents navigateur en Python. Vous décomposez un workflow en commandes petites et fiables : act() pour les actions et act_get() pour l’extraction typée. Il pilote un vrai Chromium via Playwright. À mi-2026, c’est une préversion de recherche.
Nova Act fonctionne-t-il avec Bright Data ?
Oui, via le Chrome DevTools Protocol. Nova Act se connecte à la Browser API de Bright Data via cdp_endpoint_url et cdp_headers. Le piège de configuration est que Playwright moderne rejette l’URL wss:// avec identifiants intégrés, donc déplacez les identifiants dans un en-tête Authorization: Basic et forcez une fenêtre d’affichage 1600×900.
Puis-je utiliser un Proxy avec Nova Act ?
Pas avec le paramètre natif proxy quand vous vous connectez via CDP. Nova Act lève ValidationFailed avec le message Cannot specify a proxy when connecting over CDP. Connectez-vous plutôt à la Browser API de Bright Data via CDP, où le déblocage, le routage géographique et la gestion des CAPTCHAs se font du côté de Bright Data.
Nova Act est-il prêt pour la production ?
À mi-2026, c’est une préversion de recherche, en anglais uniquement, avec un niveau gratuit mesuré. La production s’exécute sur AWS avec IAM, S3 et Bedrock AgentCore. Dans nos exécutions, il était fiable sur les sites coopératifs et structurés, et fragile sur les sites consommateurs hostiles. Confirmez les conditions et la tarification de production avec AWS avant de construire dessus.
Quel est le coût d’exécution d’un agent navigateur de cette façon ?
La Browser API de Bright Data facture environ 8 $/Go en paiement à l’utilisation (mi-2026). Une page lourde a déplacé environ 3,4 Mo : environ 27 $ pour 1 000 pages avant nouvelles tentatives. Budgétisez 1,2 à 1,5× en plus. Une page légère est plus proche de 1,60 $ pour 1 000. L’inférence de Nova Act n’est pas publiquement tarifée, donc pour le travail en masse, utilisez la couche de données, pas un navigateur.
Pourquoi ne pas utiliser mon propre navigateur sans interface et des proxies ?
Les modes d’échec mesurés ne sont que la moitié de la réponse. Piloter un navigateur est lourd, fragile sur l’actuation multi-étapes, et non déterministe. Mais la moitié plus difficile à gérer soi-même est la géographie, la conformité et l’échelle : une course aux armements qui ne se termine jamais. Une couche d’infrastructure la gère pour que votre ingénierie n’ait pas à le faire.
Quand utiliser l’agent, et non la couche de données ?
Si le travail est une extraction fixe à schéma connu, utilisez une API Web Scraper, qui retourne l’enregistrement sans page et sans coût d’inférence. Si cela nécessite un raisonnement qu’un Scraper ne peut pas capturer (navigation multi-étapes, soumission de formulaire, logique conditionnelle), utilisez l’agent. Dans les systèmes réels, les deux se composent.
