Automatisation de navigateur et scraping : Playwright, Browser Use et l'astuce .har

Vue d'ensemble

L'essentiel du web n'a pas d'API publique, mais chaque site est déjà une surface qu'un humain peut piloter, ce qui veut dire qu'un programme peut la piloter aussi. Playwright est l'outil qui fait cela : il pilote un vrai navigateur comme le ferait une utilisatrice, cliquant, tapant et lisant la page. Par-dessus siègent deux astuces qui transforment un scraping fragile en automatisation fiable. L'astuce non-headless vous laisse vous connecter une fois à la main et réutiliser la session. L'astuce .har vous laisse sauter entièrement la page rendue et appeler l'API que le site appelle lui-même. Cette leçon enseigne les trois, plus quand saisir un navigateur piloté par agent et comment rester du bon côté de l'éthique et de la loi.

Ce que vous allez apprendre

Vous allez apprendre les bases de Playwright, en quoi le browsing piloté par agent (Browser Use et similaires) diffère de l'automatisation scriptée, le pattern navigateur visible avec login manuel qui contourne la partie la plus dure des sites authentifiés, et comment enregistrer un fichier .har et laisser un agent en extraire les appels d'API sous-jacents. Vous apprendrez aussi où sont les limites légales et éthiques et quand céder la mise à l'échelle à un fournisseur comme Brightdata.

Prérequis

Les Cours 1 à 3 et un projet Node fonctionnel. Vous devez être à l'aise avec le code asynchrone, avec le fonctionnement des requêtes HTTP et des headers, et avec la lecture de vos DevTools de navigateur. La page de fondamentaux sur ce qu'est une API aide si requête et réponse sont encore floues, car toute l'astuce .har consiste à trouver l'API qu'une page cache.

Le problème

Vous avez besoin de données ou d'une action d'un site qui ne vous donne pas d'API. L'approche naïve est de scraper le HTML rendu avec des sélecteurs fragiles qui cassent dès que le site change un nom de classe. Les cas plus durs sont les sites derrière un login, avec détection de bots, ou qui chargent tout via JavaScript si bien que le HTML est vide jusqu'à ce que les scripts tournent. Les gens brûlent des jours à lutter contre les sélecteurs et les flux de login, pendant que le site fait tout le temps de propres appels d'API JSON, visibles dans les DevTools, qu'ils pourraient appeler directement.

Les bases de Playwright

Playwright lance et pilote Chromium, Firefox ou WebKit. Vous lui dites d'aller à une URL, d'attendre des éléments, de cliquer, de taper et de lire du texte ou des attributs. Il attend automatiquement que les éléments soient prêts, ce qui retire l'essentiel de la flakiness qui affligeait les outils plus anciens. La même librairie alimente les tests end-to-end de vos quality gates, donc le muscle est réutilisable. Voici la forme d'un script de base qui charge une page et en extrait quelques données.

import { chromium } from 'playwright'

const browser = await chromium.launch()
const page = await browser.newPage()

await page.goto('https://example.com/products')
// Attend automatiquement le sélecteur avant de lire
await page.waitForSelector('.product-card')

const titles = await page.$$eval('.product-card h2', (nodes) =>
  nodes.map((n) => n.textContent?.trim()),
)

console.log(titles)
await browser.close()

L'astuce non-headless avec login manuel

La partie la plus dure de l'automatisation d'un site authentifié est le login : mots de passe, codes à deux facteurs, captchas et détection de bots luttent tous contre vous, et mettre les credentials en dur dans un script est à la fois fragile et un risque de sécurité. L'astuce est de sauter entièrement l'automatisation du login. Lancez le navigateur non-headless (visible), naviguez vers la page de login et mettez le script en pause pendant que vous vous connectez à la main. Une fois entré, Playwright sauvegarde la session authentifiée (cookies et storage) dans un fichier, et chaque run futur charge ce fichier et est déjà connecté. Aucun mot de passe stocké, aucun captcha à résoudre, aucun flux de login fragile.

import { chromium } from 'playwright'

// Une fois : se connecter à la main, puis sauvegarder la session.
const browser = await chromium.launch({ headless: false }) // visible
const context = await browser.newContext()
const page = await context.newPage()

await page.goto('https://app.example.com/login')
console.log('Log in manually in the window, then press Enter here...')
// Attendre que VOUS ayez fini le login avant de continuer
await page.waitForURL('**/dashboard', { timeout: 0 })

// Sauvegarder la session authentifiée pour tous les runs futurs
await context.storageState({ path: 'auth.json' })
await browser.close()

// Chaque run ultérieur démarre déjà connecté :
// const context = await browser.newContext({ storageState: 'auth.json' })

Gardez auth.json hors de Git (c'est un token de session vivant) et traitez-le comme un secret. Les sessions expirent, donc c'est normal de rejouer occasionnellement l'étape de login unique. Ce pattern est de loin le plus gros upgrade de fiabilité pour l'automatisation authentifiée.

Le browsing piloté par agent

Le Playwright scripté est précis mais fragile : changez la page et vos sélecteurs cassent. Les outils de navigateur pilotés par agent comme Browser Use prennent l'approche inverse. Vous donnez à un agent un objectif en langage normal (« trouve le vol le moins cher de Zurich à Londres vendredi prochain et mets-le au panier ») et il lit la page, décide quoi cliquer et s'adapte quand le layout diffère de l'attendu. C'est plus lent et moins déterministe, mais cela survit aux changements de site et gère des tâches que vous ne pouvez pas spécifier entièrement d'avance. Le trade-off honnête : prenez le Playwright scripté pour les jobs stables, à fort volume, répétables où vous contrôlez l'objectif, et un navigateur piloté par agent pour les tâches ponctuelles ou floues où l'adaptabilité bat la vitesse. Beaucoup de vrais systèmes combinent les deux - un agent pour découvrir le flux une fois, puis un script généré pour le faire tourner à bas prix à grande échelle.

L'astuce .har

C'est le coup à plus haut levier de toute la leçon. Avant de scraper le moindre HTML rendu, ouvrez les DevTools, allez à l'onglet Network, effectuez l'action que vous voulez automatiser, puis clic droit et « Save all as HAR ». Un fichier .har est un enregistrement complet de chaque requête réseau que la page a faite, y compris les appels d'API JSON en coulisses. La plupart des sites modernes rendent depuis de propres API internes, ce qui veut dire que les données que vous voulez siègent souvent dans une réponse JSON bien rangée que vous pouvez appeler directement - pas de sélecteurs, pas de navigateur headless, bien plus rapide et bien plus robuste. Le fichier est gros et bruyant, ce qui est exactement là où un agent brille : donnez-lui le .har et demandez-lui d'en extraire les endpoints pertinents.

## Task
Here is a .har file I recorded while loading the product list page.

Extract the underlying API the page uses to fetch products. I want:
1. The exact request URL and method.
2. Which headers actually matter (auth token, content-type) vs noise.
3. Query params or request body, with what each field appears to mean.
4. The shape of the JSON response (the fields I care about: name, price, id).
5. A minimal fetch() call in TypeScript that reproduces just that request.

Ignore analytics, fonts, images and tracking pixels. Focus only on the
call that returns the product data.

Une fois que l'agent vous donne l'appel fetch, vous avez remplacé un scrape de navigateur fragile par un appel d'API direct, plus rapide, moins cher et bien plus stable. Si l'API a besoin d'un token d'auth, vous le tirez de la session non-headless ci-dessus. Cette combinaison - login manuel pour le token, astuce .har pour l'endpoint - gère une énorme part des vrais problèmes « ce site n'a pas d'API ».

Éthique, légalité et mise à l'échelle

Automatiser le web est puissant et non sans conséquences, alors soyez conscient. Cette section est de l'orientation, pas du conseil juridique - quand de l'argent ou des données personnelles sont en jeu, parlez à une avocate.

• Lisez les conditions d'utilisation et robots.txt. Certains sites interdisent l'accès automatisé, et l'ignorer peut rompre un contrat ou, dans certaines juridictions, violer une loi sur l'abus informatique.
• Ne scrapez jamais de données personnelles sans base légale. Les lois de protection des données du CLAUDE.md (RGPD, FADP, lois d'États américains) s'appliquent aux données scrapées comme à toutes les autres.
• Auto-limitez votre débit et identifiez-vous honnêtement. Marteler un site est abusif et vous met sur la liste de blocage ; un scraper poli et lent est un meilleur citoyen et plus fiable.
• Pour une mise à l'échelle légitime, prenez un fournisseur comme Brightdata. Ils gèrent la rotation de proxy, la distribution géo et l'outillage de conformité, ce qui est la façon responsable de faire tourner de gros jobs, au lieu de bâtir une armée de bots clandestine.

Erreurs fréquentes

Les classiques : scraper du HTML fragile alors qu'une propre API JSON siégeait tout le temps dans le .har ; mettre les credentials en dur au lieu d'utiliser l'astuce de session non-headless ; committer auth.json ou un token dans Git ; faire tourner un navigateur piloté par agent pour un job stable à fort volume où un script bon marché suffirait ; et ignorer les conditions d'utilisation et les rate limits jusqu'à être bloqué ou pire. Inspectez l'onglet Network avant d'écrire un seul sélecteur.

ROI business

L'automatisation de navigateur débloque des données et des actions qui nécessiteraient sinon une intégration que le fournisseur n'a jamais bâtie. L'astuce .har seule peut transformer un projet de scraping de plusieurs jours en un après-midi, parce que vous sautez la page rendue et appelez la vraie API. L'astuce non-headless retire la partie la plus fragile de toute automatisation authentifiée. Ensemble, elles laissent une petite équipe automatiser la recherche concurrentielle, la saisie de données interne à travers des systèmes legacy et les tâches répétitives de portails fournisseurs sans API - du travail qui resterait sinon manuel pour toujours.

Checklist

Confirmez que vous savez faire chacun de ces points avant d'avancer, car la prochaine leçon suppose que vous savez exécuter du code non fiable en sécurité.

• Écrire un script Playwright de base qui charge une page et lit des données.
• Utiliser l'astuce non-headless pour vous connecter une fois et réutiliser la session en headless.
• Expliquer quand prendre le browsing piloté par agent au lieu d'un script fixe.
• Enregistrer un fichier .har et en extraire un appel d'API répétable avec votre agent.
• Nommer deux limites légales ou éthiques que vous respectez toujours en scrapant.

Ressources

Gardez en favoris les docs Playwright pour la référence des sélecteurs et de l'auto-attente et les docs Browser Use pour le browsing piloté par agent. L'onglet Network de vos DevTools de navigateur est de loin l'outil le plus utile de cette leçon - apprenez à couramment y enregistrer et sauvegarder un HAR. Pour les jobs gros ou sensibles à la conformité, Brightdata et fournisseurs similaires sont la voie documentée et supportée.

Votre mission

Choisissez un site que vous utilisez et qui n'a pas d'API. Enregistrez un .har de l'action qui vous intéresse, donnez-le à votre agent avec le prompt ci-dessus et voyez si vous pouvez reproduire l'action avec un appel fetch direct. Si le site a besoin d'un login, sauvegardez d'abord une session avec l'astuce non-headless. Notez quelle approche (script, piloté par agent ou API directe depuis le .har) vous livreriez.

Prochaine leçon

Exécuter sur votre propre machine du code qu'un agent a généré - ou qu'un scrape a ramené - est risqué. La prochaine leçon couvre les sandboxes : des environnements isolés et jetables d'E2B, Daytona et outils similaires qui enferment un mauvais run pour qu'il ne puisse pas toucher votre système.