.4UVmK5aw_1uGpNi.svg){kind=small}
.AzQB9McO_PVSYK.svg){kind=small}
.DjhlE8MO_Z1DYVxU.svg){kind=small}
.DM2pllEO_1cxFXE.svg){kind=small}
.CvN5042A_Z10D5qc.svg){kind=small}
.Dcqs_gC__NRL3p.svg){kind=small}
<div id="root"></div> <!-- data still in the bundle -->
Les sessions sont gratuites : ne payez que le trafic
Navigateur cloud pour le scraping web
Une session de navigateur cloud charge la page comme pour un véritable visiteur, scripts compris : quand votre code la lit, le contenu est déjà là.
- Les pages React, Vue et Angular s'affichent intégralement, sans coquille vide
- IP résidentielles, mobiles ou de centre de données, persistantes ou rotatives
- Playwright et Puppeteer : généralement une seule ligne à modifier
Web scraping
Votre code pilote
le navigateur.
Connectez-vous en CDP à notre Chromium au lieu de récupérer du HTML. Il charge la page comme un vrai visiteur (tout le JS, nos proxys, une empreinte crédible) et vous lisez le DOM rendu.
Pourquoi utiliser un navigateur cloud plutôt que de simples requêtes HTTP ?
Une simple requête HTTP récupère le HTML envoyé par le serveur, rien de plus. C'est suffisant pour une page statique, mais cela ne fonctionne plus sur la majeure partie du web moderne : les sites bâtis sur React, Vue ou Angular n'envoient pas leur contenu dans cette première réponse, ils le construisent dans le navigateur, une fois le JS exécuté. Lancez un scraper qui ne fait que des requêtes sur l'une de ces pages et vous obtiendrez une coquille vide, tandis que les vraies données restent dans un bundle que personne n'a exécuté.
Le scraping web avec des sessions de navigateur cloud évite ce problème. La page se charge comme pour un véritable visiteur, scripts compris, et quand votre code la lit, le contenu est déjà là. Inutile de deviner quel endpoint alimente la page ni de décortiquer un bundle pour trouver le schéma de requête : vous récupérez directement le résultat final.
Contourner les blocages et la protection anti-bot au niveau du navigateur
Il suffisait autrefois d'envoyer les bons en-têtes pour obtenir une page. Ce n'est plus le cas : les sites évaluent des dizaines de petits signaux avant de décider si une requête semble même légitime :
-
L'ordre des en-têtes, et pas seulement leur présence
-
Les écarts de temps entre les actions
-
Si la souris ou le défilement se comportent comme ceux d'une personne
-
Les particularités de l'empreinte : polices installées, rendu canvas, etc.
Rendu JavaScript dynamique et applications monopage (SPA)
Les applications monopage se chargent une fois, puis se réécrivent au fil des clics : des onglets s'ouvrent, des filtres s'appliquent, les résultats s'actualisent, et rien de tout cela n'apparaît dans la première réponse. Un navigateur cloud passe par le même processus qu'un visiteur, puis lit la page une fois celle-ci stabilisée. Sans cette étape, un nombre surprenant de scrapings échouent silencieusement sur les sites qui reposent largement sur le côté client.
Résolution automatique des CAPTCHA et gestion des empreintes
Polices, rendu canvas, comportement audio, taille d'écran : l'ensemble forme une empreinte, comparée à ce à quoi un vrai navigateur est censé ressembler. Si elle est incorrecte, les sites la repèrent vite, parfois dès une ou deux requêtes. Que l'on parle de navigateur cloud anti-détection, de configuration anti-détection ou simplement de mode indétectable, le but est le même : garder cette empreinte crédible sans intervention manuelle. La résolution de CAPTCHA est généralement incluse dans la même session, si bien qu'une tâche n'attend pas une résolution manuelle chaque fois qu'un CAPTCHA apparaît.
Intégration avec des proxys rotatifs (résidentiels et de centre de données)
Une session peut passer par des IP résidentielles, mobiles ou de centre de données, selon la sensibilité du site cible. La rotation peut rester fixe pendant toute la session ou changer selon un minuteur, et ce choix a son importance. Le scraping derrière une connexion exige la même IP du début à la fin, pour que les cookies et l'état de session restent cohérents. Le scraping à grand volume demande l'inverse : répartir les requêtes pour qu'aucune adresse ne concentre toute la charge.
Compatible avec Playwright et Puppeteer
Inutile de jeter votre code de scraping existant pour que tout cela fonctionne. Playwright et Puppeteer se connectent en CDP au lieu de lancer un binaire Chrome local, et tout le reste (sélecteurs, attentes, extraction) reste exactement tel qu'écrit. Un crawler conçu il y a deux ans pour Chrome headless en local nécessite généralement une seule ligne modifiée, pas une réécriture.
- Playwright
- Puppeteer
- Python
- Node.js
Démarrage rapide : exemple de code pour se connecter
Lancer une session ne demande que quelques lignes :
Ajoutez un type de proxy et un pays à l'ouverture de la session, et le reste du script change à peine par rapport à ce qui tournerait de toute façon en local.
scrape.js
const browser = await chromium.connectOverCDP(connectUrl);const page = await browser.newPage();await page.goto('https://example.com');const data = await page.textContent('body');scrape.js
const browser = await puppeteer.connect({ browserWSEndpoint: connectUrl });const page = await browser.newPage();await page.goto('https://example.com');const data = await page.evaluate(() => document.body.innerText);Comparaison d'efficacité : scraping par requêtes ou par navigateur cloud
Le scraping par navigateur cloud coûte plus cher par page qu'une requête brute : c'est inévitable, une session de navigateur complète fait simplement plus de travail. Voici où les deux approches se distinguent vraiment :
| Requêtes HTTP simples | Scraping avec Floppydata Cloud Browser | |
|---|---|---|
| Pages rendues par JavaScript | Retour vide | Rendu complet, comme pour un vrai visiteur |
| Coût par page | Plus faible | Plus élevé, mais le blocage des ressources inutiles le réduit |
| Contenu protégé par connexion | Aucune session conservée | Les cookies et la session persistent d'une page à l'autre |
| Empreinte anti-bot | Aucune, facile à repérer | Gérée automatiquement |
| Bande passante | Charge tout | Peut ignorer images, polices et CSS |
Pour du contenu statique sans JavaScript ni protection anti-bot, les requêtes simples restent plus avantageuses en coût : inutile de lancer un navigateur complet pour une page qui n'en a jamais eu besoin. Au-delà, le scraping par navigateur cloud revient souvent moins cher une fois comptés les nouvelles tentatives, les proxys et les correctifs manuels dont une configuration à base de requêtes finit par avoir besoin. Le calcul favorise rarement les requêtes dès qu'un site cible commence à se défendre activement.