À l'échelle du million de pages, ce n'est généralement pas le crawler lui-même qui fait grimper la facture, mais la bande passante des proxies, les réessais après échec et le rendu par navigateur. Pour évaluer les alternatives à Apify, comparer les prix affichés ne suffit donc pas : ce qui compte, c'est la manière dont chaque outil gère ces coûts en pratique.
Le simple fait de quitter Apify pour une autre plateforme ne rend pas automatiquement le scraping moins cher. Une première étape plus efficace consiste à isoler les pages qui ont réellement besoin d'un navigateur. Si une API ou une simple requête HTTP renvoie déjà les données dont vous avez besoin, servez-vous-en. Seules les tâches qui impliquent du rendu JavaScript, des clics de pagination, l'envoi de formulaires ou une session authentifiée doivent passer par un navigateur.
Une fois la charge de travail découpée ainsi, on voit beaucoup plus clairement quel outil convient à quelle tâche. Apify, Firecrawl ou un crawler auto-hébergé conviennent aux gros volumes de données publiques et directement accessibles. Quand le flux de travail atteint les étapes qui dépendent réellement de l'état du navigateur et de l'interaction, ego (lite) peut prendre le relais.
La raison : ces tâches ne consistent plus simplement à récupérer une page. L'agent doit composer avec le contenu rendu, l'état actuel du navigateur et l'interaction avec la page, et l'action suivante peut changer selon ce que la page renvoie. ego (lite) s'exécute directement dans un vrai navigateur : l'agent peut donc lire la page courante, poursuivre l'interaction et vous rendre la main naturellement quand une étape demande un jugement humain ou une prise en charge manuelle.
Pour les projets de grande envergure, le meilleur plan n'est donc généralement pas de trouver un outil unique qui remplace tout le flux de travail Apify. Il consiste plutôt à choisir le bon mode d'exécution selon le type de tâche : garder simples les parties qu'une API ou un appel HTTP peut traiter, confier le gros du crawl public à un crawler dédié, et utiliser ego (lite) pour les étapes qui dépendent réellement d'un environnement de navigateur et de l'interaction. Ainsi, les coûts restent sous contrôle et vous évitez de payer du temps de navigateur pour des tâches qui n'en ont jamais eu besoin.
Combien coûte un crawl d'un million de pages sur Apify ?
Environ 430 $ à 1 300 $ d'après les chiffres ci-dessous, et plus de 80 % de ce montant correspond à la bande passante des proxies plutôt qu'au crawl lui-même.
Les tarifs derrière ce calcul sont publiés sur la page de tarification d'Apify.
La façon dont les unités de calcul sont comptées est documentée sur la documentation d'Apify sur l'utilisation et les ressources.
Cette estimation est construite à partir des tarifs publiés par Apify, et non d'une facture ou d'un devis. Elle suppose un million d'URL cibles, une passe HTTP de type Cheerio pour la majorité qui supporte la charge, un rendu par navigateur sur environ 100 000 pages qui ont réellement besoin de JavaScript, et des proxies résidentiels pour toute l'exécution.
Une distinction compte plus que toutes les autres quand on planifie à ce volume. Le volume de requêtes n'est pas le volume de pages. Si 85 % de vos requêtes réussissent du premier coup, un million de pages cibles représente plutôt 1,15 à 1,3 million de requêtes après les réessais. Vous payez pour les requêtes, et vous payez pour leur bande passante, même celles qui reviennent vides.
Notre modèle de coût, ligne par ligne.
À lire comme un exercice d'arithmétique sur des prix publiés. Nous appliquons les tarifs d'Apify à une charge de travail définie, et les hypothèses de cette charge sont énoncées pour que vous puissiez y substituer les vôtres.
| Poste de coût | Hypothèse retenue | Coût modélisé | Ce qui le détermine |
|---|---|---|---|
| Calcul, passe HTTP | 1 M d'URL cibles, workers de 1024MB, ~85 % de réussite au premier passage, concurrence du palier Starter | ~170 CU, environ 27 $ | CU = mémoire (GB) x durée (h). Doubler la mémoire divise la durée par deux, donc le total de CU ne bouge presque pas |
| Calcul, rendu | 100 000 pages qui nécessitent un vrai navigateur | ~532 CU, environ 85 $ | Un navigateur headless a besoin d'au moins 1024MB, et les pages lourdes peuvent consommer jusqu'à trois fois le CPU et la mémoire d'une récupération ordinaire |
| Proxy résidentiel | 1 M de pages d'environ 50KB de HTML compressé chacune, soit à peu près 50GB | ~400 $, jusqu'à 1 200 $ et plus | Apify affiche le proxy résidentiel à 8 $/GB. Les cibles anti-bot gonflent le poids des pages et le volume par page |
| Transfert de données et stockage | Charge utile livrée, plus le jeu de données stocké et les enregistrements clé-valeur | Généralement quelques dizaines de dollars | Le transfert est à 1 $/GB ; le stockage coûte 1 $ par 1 000 GB-heures, donc une longue exécution accumule des frais même au repos |
| Total | La charge de travail ci-dessus, en un passage | environ 430 $ à 1 300 $ | 0,0004 $ à 0,0013 $ par page, avec des dépenses de proxies supérieures à 80 % du total |
Deux chiffres de ce tableau méritent un second regard, car c'est là que les budgets dérapent vraiment.
Le premier est la ligne des 1024MB. Les nouveaux utilisateurs d'Apify supposent souvent que payer plus de mémoire coûte plus cher. En termes de CU, c'est faux : une tâche qui a besoin de deux fois plus de mémoire se termine en deux fois moins de temps, et c'est le produit des deux qui vous est facturé. La mémoire est un réglage d'ordonnancement, pas un levier de coût.
Le second est la ligne des proxies. Notez que la plateforme ne peut littéralement pas être le coût dominant ici : à 0,20 $ à 0,13 $ par CU selon le palier, il faudrait brûler plus de 2 000 unités de calcul pour égaler une seule facture de bande passante modérée.
Si votre crawl coûte cher, vous payez de la bande passante, pas de l'orchestration.
Comment le modèle d'unités de calcul d'Apify facture-t-il réellement ?
Une unité de calcul correspond à 1GB de mémoire occupée pendant une heure, mesurée avec une granularité d'une seconde, et c'est la seule unité sur laquelle la plateforme facture le crawl.
Mémoire multipliée par durée. Une exécution qui occupe 1024MB pendant une heure consomme exactement un CU. La même exécution dimensionnée à 4096MB pendant quinze minutes consomme aussi un CU. C'est pourquoi la colonne CU de notre modèle bouge si peu quand on change la taille des workers : le travail reste le travail.
Quelques propriétés du modèle méritent d'être intégrées :
- Cheerio n'est pas une petite optimisation. La propre documentation d'Apify indique qu'une passe HTTP de type Cheerio est jusqu'à 20 fois plus rapide que la même tâche dans un navigateur. C'est ce facteur qui maintient les 170 CU pour un million de pages à portée de main.
- C'est la concurrence, et non la taille des workers, qui détermine votre durée d'exécution. Les limites par offre vont de 25 exécutions simultanées en formule Free à 256 en Business, avec des plafonds de mémoire combinée de 16 384MB, 65 536MB, 262 144MB et 524 288MB selon ces paliers. À 32 tâches simultanées et environ 3 200 pages par minute, un million de pages prend à peu près 5,2 heures.
- Certains actors ont un plancher de mémoire incompressible. Un actor de navigateur ne s'exécute pas en dessous de 1024MB et le scraper Google Maps nécessite 4096MB ou plus. 4096MB est la valeur par défaut pragmatique quand vous préférez ne pas régler chaque actor.
- Les crédits ne sont pas reportés. Les crédits mensuels inutilisés expirent. Si votre crawl est en rafales, une énorme exécution par trimestre au lieu d'un flux régulier, vous payez pour une capacité que vous n'avez pas utilisée.
Rien de tout cela ne plaide contre Apify. C'est l'une des rares plateformes dont on peut raisonner l'économie unitaire à partir de sa documentation publiée, et le modèle de CU est réellement honnête : il facture le travail plutôt que les lignes. Le problème, c'est ce qu'il n'inclut pas.
Les proxies. Les actors gourmands en rendu. Le stockage qui continue de s'accumuler tant qu'un jeu de données reste en place. Ce sont ces postes qui décident si un crawl d'un million de pages coûte des centaines ou des milliers de dollars, et ce sont les mêmes postes chez toutes les alternatives à Apify que vous pourriez envisager.
Quelles sont les principales alternatives à Apify pour le scraping à grande échelle ?
Il existe quatre types d'alternatives, et une seule est facturée sur le même modèle qu'Apify.
La plupart des listes d'alternatives à Apify sont en réalité des listes d'autres outils qui scrapent des sites web, ce qui est une question différente. Si votre crawl est coûteux plutôt qu'irréalisable, l'axe pertinent n'est pas les fonctionnalités : c'est ce que chaque fournisseur vous facture. Le prix par heure de calcul, le prix par crédit, le prix par gigaoctet de trafic proxy et le prix par heure d'opérateur évoluent tous différemment à mesure que le volume augmente.
- Firecrawl. API de scraping à crédits avec une sortie prête pour les LLM. Un scrape équivaut à un crédit, et chaque format de sortie optionnel coûte davantage : le mode JSON est à +4, l'extraction de questions ou de points saillants à +4 par format, l'anonymisation des données personnelles à +4. Les paliers sont à 0 $, 20 $, 106 $, 424 $ et 762 $ pour 1 000, 5 000, 100 000, 500 000 et 1 000 000 de crédits par mois.
- ZenRows. Récupération gérée avec rendu JS et rotation de proxies. Les crédits vont de 5 000 sur le palier à 16 $ à 5 millions sur celui à 456 $, avec une concurrence de 5 à 200 et sur mesure au-delà. Le rendu JavaScript multiplie le coût en crédits par 10, et le mode combiné JS plus proxy par 25. Les requêtes échouées et réessayées ne sont pas facturées.
- ScraperAPI. Récupération à crédits avec une échelle de concurrence simple, de 20 sur le palier à 49 $ jusqu'à plus de 500 en haut de gamme, couvrant 100 000 à 10,5 millions de crédits.
- Bright Data et Oxylabs. Fournisseurs axés proxies qui vendent aussi des scrapers gérés. Oxylabs affiche une tarification SERP de 0,50 $ à 1,35 $ par séquence d'unités et une bande passante résidentielle de 3 $/GB jusqu'à 2 $/GB selon le volume. La page web-scraper de Bright Data s'appuie sur une promesse de concurrence illimitée sans publier de prix, une affirmation que nous ne pouvons pas vérifier et que nous ne répétons donc pas comme un fait.
- Crawlers auto-hébergés. Un pipeline Scrapy ou Playwright sur votre propre infrastructure. Aucun frais par page ni par CU, et votre facture de proxies reste votre facture de proxies. La contrepartie : la gestion de la file d'attente, les réessais, la planification et la supervision deviennent votre problème, de façon permanente.
- Navigateurs pilotés par agent. C'est la voie sur laquelle nous travaillons, donc lisez ce qui suit en gardant cela à l'esprit. ego (lite) est un navigateur Chromium qui récupère vos connexions et extensions existantes, et un agent de codage le pilote via le skill ego-browser dans son propre Space isolé. C'est là qu'un flux de travail se dirige quand les requêtes statiques ne suffisent plus : une étape de connexion, une vue qui ne s'affiche qu'avec JavaScript, une pagination cachée derrière un clic, un filtre qui est un formulaire, un code à lire dans une boîte de réception. Il est gratuit et fonctionne sur macOS aujourd'hui, Windows et Linux étant sur la feuille de route. Il n'y a pas de tarif par page à comparer à celui d'Apify : la question n'est donc pas de savoir lequel est le moins cher par page, mais si votre flux de travail a besoin d'une session tout court.
Pourquoi la bande passante des proxies domine-t-elle la facture ?
Parce que c'est le seul poste qui évolue avec la taille des pages téléchargées plutôt qu'avec la quantité de travail effectué.
Pour savoir comment cette voie se compare sur une tâche de navigateur comparable, ego (lite) vs Playwright est la comparaison directe.
Maintenir une session connectée active d'une exécution à l'autre est traité dans les sessions de navigateur persistantes entre les exécutions d'agent.
Le calcul évolue avec le temps CPU. La concurrence évolue avec le palier d'offre. La bande passante évolue avec l'internet. Un mégaoctet de HTML reste un mégaoctet, qu'il ait mis une milliseconde ou une seconde à arriver, et le trafic proxy résidentiel se facture au gigaoctet : 8 $/GB chez Apify, 3 $/GB jusqu'à 2 $/GB selon le volume chez Oxylabs.
À 50KB de HTML compressé par page, un million de pages représente environ 50GB. Cela fait 400 $ au tarif affiché par Apify avant même de compter les réessais, et la situation empire à mesure que la cible est difficile : les pages protégées contre les bots sont plus lourdes, nécessitent souvent plusieurs requêtes pour aboutir et peuvent consommer jusqu'à trois fois les ressources d'une page coopérative.
Voici le point dérangeant. La majeure partie de cette bande passante est gaspillée, et vous le savez déjà. Une page de liste de produits peut représenter 400KB de HTML, CSS, JavaScript, de polices et de pixels de suivi juste pour vous permettre de lire un prix et une disponibilité, alors que le signal réel fait peut-être 2KB. Vous payez des tarifs résidentiels pour transporter l'emballage.
Trois leviers permettent de la réduire, et ils valent plus que n'importe quel changement de fournisseur. Limitez le crawl aux pages qui portent les données au lieu de suivre chaque lien. Récupérez les points de terminaison structurés quand un site les expose, car les réponses JSON représentent une fraction du poids de la page rendue. Et ne rendez que là où le rendu est nécessaire, ce qui, dans notre modèle, concerne 100 000 pages sur un million.
Comment les alternatives à Apify se comparent-elles ?
Aux tarifs publiés, l'écart entre la voie la moins chère et la plus chère est d'environ dix fois, et rien dans cet écart ne vient du crawl lui-même.
Lisez chaque ligne pour deux choses : ce que le fournisseur facture et ce qu'il vous empêche de faire. Un prix sans plafond, c'est du marketing. Un plafond sans prix, c'est un rendez-vous commercial.
| Voie | Ce qu'elle facture | Coût modélisé pour 1 M de pages | Plafond documenté |
|---|---|---|---|
| Apify, passe Cheerio sans proxies | CU = GB x heures, granularité d'une seconde | ~27 $ de calcul | Concurrence et mémoire combinée selon l'offre : 25 exécutions et 16 384MB en Free jusqu'à 256 exécutions et 524 288MB en Business |
| Apify, exécution complète avec proxies résidentiels | CU plus 8 $/GB de proxy, 1 $/GB de transfert, 1 $ par 1 000 GB-heures de stockage | ~430 $ à 1 300 $ | Les requêtes échouées consomment quand même de la bande passante et des CU. Les crédits expirent chaque mois au lieu de s'accumuler |
| Firecrawl, palier Scale | Crédits : 1 par scrape, +4 pour le mode JSON ou l'extraction | ~749 $ = 1 M de crédits, environ 0,00075 $ par page | Avec le mode JSON, la couverture effective tombe à 200 000 ou 250 000 pages, soit 0,003 $ à 0,00375 $ par page. Plus un plafond strict de 100 navigateurs simultanés |
| ZenRows | Crédits, avec des multiplicateurs pour le rendu JS et le mode proxy | Le palier à 456 $ couvre 5 M de crédits | Le rendu JS multiplie le coût par 10 et le mode combiné par 25, ce qui réduit le volume effectif dans les mêmes proportions. Les requêtes échouées et réessayées ne sont pas facturées |
| ScraperAPI | Crédits sur une échelle de 49 $ à 1 975 $ | 100 000 à 10,5 M de crédits selon les paliers | Concurrence de 20 à plus de 500, et coût en crédits par page variable selon les fonctionnalités activées |
| Scrapy ou Playwright auto-hébergé | Des heures de serveur plus les proxies que vous achetez | Aucun frais de plateforme, quel que soit le volume | Toutes les problématiques opérationnelles vous incombent : file d'attente, réessais, supervision et réduction du poids des pages |
| ego (lite) avec un agent de codage | Votre machine et l'agent que vous payez déjà | Aucun tarif par page à comparer | Navigateur Chromium reprenant vos vraies connexions, piloté dans un Space isolé. Couvre les étapes de connexion, de rendu, de pagination, de formulaire et de vérification qu'une récupération ne peut pas terminer. Gratuit, macOS aujourd'hui |
La ligne Firecrawl est celle que les gens interprètent mal, cela vaut donc la peine de l'expliquer. Un million de crédits ressemble à un million de pages, et pour un scrape brut c'est le cas. Ajoutez l'extraction JSON et vous avez dépensé cinq crédits par page : les mêmes 749 $ couvrent alors 200 000 pages. Ce n'est pas une astuce tarifaire. C'est un coût réel pour un travail réel, et cela signifie que le chiffre que vous budgétez n'est pas celui affiché sur la carte du palier.
La documentation de Firecrawl est inhabituellement franche sur l'autre contrainte : votre véritable goulot d'étranglement sera le nombre de navigateurs simultanés. La formule Free commence à deux, Hobby à cinq, Standard à 25, Growth à 50, Scale à plus de 100. À 100 pages simultanées et deux secondes généreuses chacune, cela fait environ 50 pages par seconde, soit à peu près 5,6 heures pour un million. Ça fonctionne, mais vous ne pouvez pas contourner cette limite à coups de crédits.
Les paliers de concurrence de Firecrawl proviennent de sa propre page de tarification.
Pour la comparaison des bibliothèques de scraping derrière ce choix, voir Playwright vs Puppeteer pour le scraping web.
ZenRows résout une autre version du même problème en rendant les réessais gratuits. Ne pas facturer les requêtes échouées ou réessayées est un vrai avantage sur des cibles hostiles, et c'est le genre de détail qu'il vaut la peine de vérifier avant de supposer qu'un tarif affiché plus bas l'emporte.
Quels critères déterminent le choix d'une alternative à Apify ?
Quatre chiffres décident du choix, et trois d'entre eux sont des propriétés de votre charge de travail plutôt que d'un fournisseur.
Les matrices de fonctionnalités sont surtout du bruit à cette échelle, car tous les fournisseurs font le même travail de base. Ce qui les distingue, c'est le comportement de leur facturation quand votre crawl est multiplié par dix, et si le plafond qu'ils imposent arrive avant ou après cette croissance.
| Critère | Pourquoi il décide du résultat | Favorise | À vérifier en demandant |
|---|---|---|---|
| Ratio de rendu | Tous les fournisseurs multiplient le coût pour le rendu par navigateur : la part de pages qui ont réellement besoin de JavaScript fixe donc votre plancher avant même de commencer à comparer les prix | Favorise l'auto-hébergement et les plateformes facturées en CU, et pénalise les API à crédits | « Quel pourcentage de mes URL a besoin d'un vrai navigateur ? » |
| Bande passante des proxies | Le poste le plus important dans la plupart des exécutions d'un million de pages, et celui sur lequel les fournisseurs se livrent la concurrence la plus agressive | Favorise quiconque vend de la bande passante bon marché, et en particulier les fournisseurs axés proxies | « Quel est mon prix par gigaoctet à mon volume, réessais compris ? » |
| Plafond de concurrence | Détermine le temps d'horloge, et ne peut être contourné à aucun prix. Un solde de crédits ne crée pas de places de navigateur | Favorise les plateformes dont la concurrence dépend du palier et évolue de façon prévisible | « Combien de requêtes puis-je réellement exécuter en même temps, et quel palier en débloque davantage ? » |
| Facturation des réessais | Sur des cibles hostiles, les requêtes gaspillées peuvent dépasser les requêtes réussies et doubler silencieusement une estimation | Favorise les fournisseurs qui ne facturent pas les échecs, et pénalise les modèles à la requête sur des cibles difficiles | « Suis-je facturé pour un 403 ou un délai d'attente dépassé ? » |
| Besoin de session et de connexion | Ce n'est pas un critère de coût mais de faisabilité. Une API de crawl est le mauvais instrument pour des données authentifiées, à n'importe quel prix | Favorise les navigateurs pilotés par agent et les sessions auto-gérées plutôt que les flottes hébergées | « Ces données sont-elles derrière une connexion que je suis autorisé à utiliser ? » |
Remarquez à quel point ce tableau parle peu de fonctionnalités. Les fournisseurs qui se disputent la requête « alternatives à Apify » se livrent surtout la concurrence sur la même liste de critères : pools de proxies, rendu JS, gestion des CAPTCHA, intégrations. Ces listes convergent. La forme de la facturation, elle, ne converge pas, et c'est elle qui décide de votre facture.
Comment choisir une alternative à Apify ?
Faites correspondre la réponse à votre ratio de rendu et à votre état d'autorisation, et la liste se réduit à une seule ligne.
- HTML statique, public, plus d'un million de pages. Restez sur une plateforme facturée en CU ou auto-hébergez, et consacrez votre énergie aux tarifs de proxies et à la réduction du poids des pages. Changer de plateforme à ce ratio de rendu ne fait gagner qu'un pourcentage à un chiffre.
- Majoritairement statique, avec une minorité rendue récalcitrante. Découpez le crawl. Des récupérations peu coûteuses pour la majorité, une voie de rendu pour le reste. C'est la décision au meilleur rendement qui soit, et elle ne coûte rien à prendre.
- Fortement dépendant de JavaScript, données publiques. Les API à crédits justifient ici leur surcoût si elles font l'extraction à votre place, car vous achetez des tokens et une sortie structurée plutôt que de simples octets. Budgétez les multiplicateurs de format avant de choisir un palier.
- Cibles hostiles et blocages fréquents. Facturez les réessais, pas les requêtes. Un fournisseur qui ne facture pas les échecs peut être moins cher malgré un tarif affiché plus élevé.
- Derrière une connexion, ou un tableau de bord interne. Cessez de comparer les prix des crawlers. Il s'agit d'un travail autorisé qui dépend d'une session, et il s'exécute dans un navigateur qui détient déjà la session, ce qui est à quoi sert ego (lite). Consultez nos notes sur le scraping derrière les murs de connexion pour les détails techniques, et gardez à l'esprit qu'aucun outil ici ne contourne les contrôles d'accès d'un site.
- Quelques centaines de pages, actualisées souvent. Rien de tout cela ne s'applique. Vous n'êtes pas dans le régime de volume qui rend les modèles de coût intéressants, et un outil no-code est probablement le bon choix. Notre guide des outils de scraping web par IA couvre les voies no-code, API et agent-browser en gardant cette ampleur à l'esprit.
Si vous évaluez une infrastructure de navigateurs hébergés plutôt que des crawlers proprement dits, la même logique s'applique un niveau en dessous : navigateur headless ou vrai navigateur est la décision qui détermine si votre coût par page est dominé par le rendu, tout simplement.
Quand vaut-il la peine d'ajouter ego (lite) au flux de travail ?
Une requête statique cesse de suffire à cinq moments précis : une connexion, une vue qui ne s'affiche qu'avec JavaScript, une pagination derrière un clic, un filtre qui est en réalité un formulaire et une étape de vérification.
Ces cinq cas méritent d'être nommés, car ce sont ceux dont une simple récupération ne peut pas se remettre toute seule. curl renvoie la page de connexion et répond 200. Le HTML arrive, mais les lignes ne s'y trouvent pas. La page deux existe, mais seulement après un clic qui n'a jamais lieu à l'intérieur d'une requête. Les données que vous voulez se trouvent derrière un formulaire plutôt que dans une chaîne de requête. Le compte demande un code envoyé dans une boîte de réception que vous avez ouverte dans un autre onglet.
Quand cela se produit, la solution n'est pas un crawler plus gros. C'est d'exécuter le même flux de travail dans un navigateur qui porte déjà la session.
Pour que cela ne reste pas théorique, nous avons exécuté une même tâche des deux façons et conservé les preuves. La tâche : extraire les trois premières annonces non sponsorisées d'huile de poisson d'une recherche Amazon, avec le nom, la marque, le prix, la note, le nombre d'avis et le format. Une passe via ego (lite), une passe en HTTP simple avec un script. Les deux ont tourné sur la même machine le même jour, et les deux exécutions sont présentées ci-dessous.
La voie navigateur, étape par étape
La passe navigateur se déroule en quatre parties : les entrées que vous fournissez, les étapes que l'agent suit, ce qui se passe quand il tombe sur quelque chose qu'il ne doit pas décider seul et la façon dont vous vérifiez le résultat. Voici chacune d'elles face à une vraie recherche de produits.
- Entrées. L'URL de recherche, un compte Amazon déjà connecté et une phrase qui décrit les champs à collecter. ego (lite) est Chromium et reprend vos connexions, extensions et votre historique existants, donc aucune étape d'export de cookies et aucun identifiant à coller où que ce soit. La skill ego-browser est liée au navigateur et installée avec ego (lite), et vous l'activez en tapant /ego-browser dans la zone de chat de l'agent.
- Étapes clés. L'agent ouvre son propre Space, une fenêtre distincte marquée d'une lueur bleue pour ne pas piloter les onglets que vous utilisez. À l'intérieur, l'agent navigue, prend un snapshot de la page pour en lire la structure et capture ce qu'il trouve. Ces snapshots lisent les iframes imbriquées, là où l'extraction dépendante du rendu échoue habituellement.
- Reprise sur échec. Quand l'exécution atteint une connexion, un code de vérification ou tout autre point qu'elle ne doit pas décider seule, elle s'arrête et vous attire dans son Space au lieu de deviner. Le comportement documenté tient aussi sur le versant plus risqué : une candidature attend votre confirmation avant l'envoi final, et un parcours de réservation va jusqu'à la page de paiement puis s'arrête là. Un crawler qui heurte un mur de connexion enregistre un 200 et continue. Celui-ci demande.
- Validation du résultat. Vérifiez les lignes collectées par rapport à la page sur laquelle l'agent se trouvait réellement, et non par rapport à l'URL que vous lui avez fournie. Le snapshot à partir duquel l'agent a travaillé constitue la preuve. C'est là que la seule véritable anomalie de l'exécution a fait surface, et c'est le genre de chose qui n'existe que sur une page rendue.
La même tâche en HTTP simple à la place
Voici l'autre moitié, honnête, car le résultat intéressant n'est pas que HTTP a échoué. C'est l'endroit où il a eu du mal et ce qu'il a fallu dépenser pour le faire fonctionner.
La passe HTTP a exécuté la même tâche avec un script et sans navigateur. Elle y est arrivée au bout du compte. Le journal consigne la quantité de travail de transport qui a séparé les deux.
Une requête soumise à un challenge est un arrêt net. Mais la plupart des 503 ici n'étaient pas des challenges, et distinguer les deux a demandé une expérience.
Réécrire le transport était le milieu du problème, pas la fin. L'extracteur a ensuite dû être corrigé deux fois sur la même page.
Ainsi, les deux passes ont atteint les trois produits. La différence réside dans ce que chacune a dépensé pour y arriver. L'exécution navigateur a ouvert un Space, lu des pages et terminé avec une capture d'écran pour chaque valeur rapportée. L'exécution HTTP a écrit six scripts, changé de client HTTP à cause d'une incompatibilité d'empreinte TLS, ajouté une couche de réessai, corrigé un bug de détection des sponsors, corrigé un bug de devise et clos sur un rapport admettant n'avoir aucune sortie pour le premier produit.
C'est la part qu'un modèle de coût par page manque. Ni l'une ni l'autre approche n'est fausse, et les compteurs de tokens et de temps d'horloge de ces captures sont assez proches pour que la vitesse seule ne tranche pas. Ce qui les sépare, c'est où va le temps. Une voie le passe à lire une page. L'autre le passe à construire et déboguer la machinerie qui remplace la lecture d'une page.
Pour trois produits, cette machinerie constitue tout le coût et ne s'amortit pas. À cent mille pages, le même code tourne sans surveillance pendant une journée et l'arithmétique s'inverse complètement.
Quand vous n'avez pas du tout besoin d'ego (lite)
Le HTTP simple couvre plus de ce travail que la conversation sur l'outillage ne le suggère. Si la page renvoie ses données dans le HTML, récupérez-la. Si le site publie une API, utilisez l'API, car c'est la voie d'accès que le site prévoit et elle survit aux refontes qui cassent les sélecteurs. Et si un gros crawl public constitue toute la tâche, sans aucune étape nécessitant une session, une plateforme hébergée ou une API à crédits battra un navigateur local en débit.
Lisez aussi le cas Amazon à la bonne échelle. Ce n'est pas la preuve que HTTP est cassé, puisque HTTP a atteint les données. Et ce n'est pas la preuve que le navigateur était rapide, puisque l'exécution navigateur a aussi pris plus de vingt minutes et que son propre rapport consigne un échec. Ce qu'il montre, c'est où le travail est parti de chaque côté. Le seul vrai problème de la voie navigateur était celui du site, pas celui de l'outil. Les problèmes de la voie HTTP étaient tous les siens.
Ajouter un navigateur à un flux de travail qui n'en a pas besoin est la façon la plus courante de rendre un travail de scraping plus lent et plus cher qu'il ne devait l'être. Vérifiez d'abord la voie la moins chère, et notez ce qu'elle coûte quand la cible nécessite une session.
Auto-héberger son propre crawler vaut-il encore la peine ?
Souvent oui, et la raison relève de l'arithmétique plutôt que de l'artisanat : à ce volume, vous payez une file d'attente et un ordonnanceur, et les deux sont des produits de base.
Scrapy et Playwright sont gratuits, bien documentés et ennuyeux de la façon dont une infrastructure de production doit l'être. Si votre crawl est une tâche récurrente sur des cibles stables, un pipeline auto-hébergé supprime entièrement les frais de plateforme et ne vous laisse que le coût des serveurs et la facture de proxies que vous auriez payée de toute façon.
Le contrepoids honnête, c'est que les frais de plateforme achètent quelque chose de réel. Une logique de réessai qui gère cinq modes de défaillance différents. Un ordonnanceur qui ne dérive pas. Du stockage, de la journalisation et la possibilité de relancer un jeu de données sans toucher à la production. Les équipes sous-estiment systématiquement ce que cela coûte en heures d'ingénierie, parce que ces heures apparaissent dans l'agenda d'une personne plutôt que sur une facture.
Une règle approximative : auto-hébergez quand le crawl est récurrent et les cibles stables. Louez quand le crawl est exploratoire, ou quand le site que vous crawlez change de forme toutes les quelques semaines. Les frais de plateforme sont surtout des frais de gestion du changement.
Où toutes ces options atteignent-elles leurs limites ?
Trois endroits, et ce sont ceux qui transforment un modèle de coût propre en dépassement.
Le premier est que les promesses marketing de chaque fournisseur dépassent sa documentation, et l'écart est le plus large précisément là où vous avez besoin de précision. La page web-scraper de Bright Data affirme une concurrence illimitée et ne publie aucun prix sur la même page. Ce n'est pas un mensonge que nous pouvons réfuter ; c'est une affirmation que nous ne pouvons pas vérifier, ce qui est une information différente et plus utile. Traitez tout terme comme illimité, de classe entreprise ou infini comme une invitation à aller chercher le chiffre, et si le chiffre n'est pas publié, supposez que le plafond existe et qu'il se négocie.
Le deuxième est la protection anti-bot, qui n'est pas une fonctionnalité que vous achetez mais une condition dans laquelle vous opérez. Les gains d'efficacité d'une voie de récupération plus rapide s'évaporent quand chaque requête exige une IP résidentielle, une session chaude et un budget de réessais. Notre modèle atteint 1 300 $ non pas parce qu'un fournisseur abuse, mais parce que des cibles plus difficiles signifient des pages plus lourdes et davantage de requêtes gaspillées.
Le troisième est celui que personne ne met dans un tableau comparatif : c'est une infrastructure de données publiques, et l'utiliser comme telle relève de votre responsabilité. Les conditions d'utilisation, les directives robots, les données personnelles au titre du RGPD ou du CCPA, et la différence entre les pages publiques d'un site et les informations privées de ses utilisateurs sont autant de questions distinctes de celle de l'outil que vous choisissez. Un crawler bon marché ne rend pas un crawl inadmissible admissible. Nous ne sommes pas juristes et ceci n'est pas un avis juridique, mais le crawl le moins cher est celui que votre organisation peut réellement défendre.
FAQ
Quelle est l'alternative à Apify la moins chère pour un million de pages ?
Aux tarifs publiés, un pipeline Scrapy auto-hébergé avec des proxies bon marché, puisqu'il n'y a aucun frais de plateforme. Parmi les options gérées, une plateforme facturée en CU exécutant une passe HTTP bat les API à crédits en volume brut. Mais la réponse honnête est que le choix de la plateforme ne représente que la plus petite moitié de la facture : à 8 $/GB de trafic résidentiel, un million de pages de 50KB coûte environ 400 $ de bande passante, quel que soit celui qui récupère.
Firecrawl est-il un bon remplacement d'Apify ?
Pour du Markdown prêt pour les LLM et de l'extraction structurée, oui : c'est plus simple à prévoir et la sortie vous épargne une couche de parsing. Pour une simple récupération d'un million de pages, son plafond de concurrence devient la contrainte avant même son solde de crédits. La formule Free autorise deux navigateurs simultanés et le palier Scale plus de 100, donc le débit est plafonné par l'offre plutôt que par la dépense.
Apify facture-t-il les requêtes échouées ?
Oui, indirectement. Les unités de calcul s'accumulent pendant la durée d'exécution quel que soit ce que la requête a renvoyé, et la bande passante des proxies est consommée par le transfert. Une requête réessayée est facturée deux fois sans rien à montrer pour la première tentative.
Pourquoi les alternatives à Apify sont-elles souvent plus chères à grande échelle ?
Elles ne le sont généralement pas, en termes de plateforme. Elles paraissent chères parce que les multiplicateurs de crédits ne correspondent pas proprement aux pages : un scrape vaut un crédit, mais le mode JSON en vaut cinq, et le rendu JavaScript chez un fournisseur basé sur les proxies peut coûter dix ou vingt-cinq fois une simple récupération. Multipliez le tarif affiché par le multiplicateur dont vous avez réellement besoin, et l'écart se referme ou s'inverse.
Ai-je besoin du rendu par navigateur pour un million de pages ?
Presque jamais pour la totalité. Une hypothèse de travail est que 90 % des pages sont lisibles en HTML statique et que 10 % nécessitent JavaScript, ce qui explique pourquoi notre modèle rend 100 000 pages et récupère le reste. Mesurez votre ratio sur un échantillon de 1 000 pages avant de budgéter, car il déplace le coût plus que n'importe quel choix de fournisseur.
Et Bright Data et Oxylabs comme alternatives à Apify ?
Ils sont les plus performants quand les proxies sont le problème. Oxylabs affiche une bande passante résidentielle de 3 $/GB jusqu'à 2 $/GB selon le volume, bien en dessous des 8 $/GB d'Apify, et une tarification SERP de 0,50 $ à 1,35 $ par séquence d'unités. Bright Data ne publie aucun prix sur sa page web-scraper et s'appuie sur une promesse de concurrence illimitée que nous n'avons pas pu vérifier : traitez donc cela comme un devis à demander plutôt que comme un fait sur lequel planifier.
Les tarifs de bande passante résidentielle cités ici sont indiqués sur la page de tarification d'Oxylabs.
Les offres de Bright Data, qui ne publient pas de tarifs au GB sur la page du scraper, commencent sur sa page de tarification.
Puis-je remplacer Apify par ego (lite) ?
Ils couvrent des étapes différentes, cela ressemble donc moins à un remplacement qu'à une transmission. Apify exécute des crawls hébergés à grande échelle. ego (lite) est un navigateur macOS gratuit qu'un agent de codage pilote à travers une session à laquelle vous êtes déjà connecté, et vous y avez recours quand une étape nécessite une connexion, une vue rendue, un clic dans la pagination, un formulaire ou un code de vérification. Si votre travail est un gros crawl public et que rien dedans ne nécessite de session, vous n'avez pas du tout besoin d'ego (lite) dans le pipeline.
Comment estimer la bande passante des proxies avant un crawl ?
Récupérez 1 000 URL représentatives, mesurez la taille des réponses compressées et multipliez. Ajoutez ensuite le facteur de réessai : à un taux de réussite de 85 % au premier passage, un million de cibles représente 1,15 à 1,3 million de requêtes. Budgétez le chiffre le plus élevé, car le poids des pages augmente avec la protection anti-bot.
Apify reste-t-il le bon choix à ce volume ?
Parfois, oui. Son modèle de CU est transparent, il facture le travail plutôt que les lignes et son écosystème d'actors élimine beaucoup de code de liaison. Si votre crawl fait quelques centaines de milliers de pages et que vos proxies viennent d'un fournisseur moins cher, la plateforme n'est pas votre problème. Ce qui pousse généralement à partir, ce sont des crédits qui expirent, une concurrence liée à l'offre qui arrive avant que vous soyez prêt, ou des tarifs de bande passante que vous pouvez battre ailleurs.
Qu'est-ce qui casse en premier sur un million de pages ?
Le budget, pas la technologie. Les plafonds de concurrence et la facturation des réessais sont documentés et prévisibles. Ce qui surprend les équipes, c'est la facture de bande passante, l'hypothèse sur le nombre de pages nécessitant un rendu et la part du crawl qui se révèle être des pages que personne n'a demandées. Corrigez le périmètre avant de corriger le fournisseur.
La plupart des comparaisons d'alternatives à Apify répondent à une question sur les fonctionnalités. La question qui coûte de l'argent sur un million de pages porte sur la forme de la facturation, et elle a trois volets : pour quoi le fournisseur applique-t-il un multiplicateur, quel est son plafond et qui paie pour une requête échouée ?
Apify répond bien à ces questions. Son unité de calcul est une unité de travail propre, et il vous facture la navigation de pages plutôt que le comptage de lignes. Ce qu'il ne maîtrise pas, c'est la part de la facture que vous allez réellement fixer : la bande passante résidentielle à 8 $/GB, sur des pages où la plupart des octets ne sont que de l'échafaudage.
Le bon réflexe n'est donc pas de changer de plateforme. C'est de réduire le crawl aux pages qui portent les données, de récupérer la majorité statique avec quelque chose 20 fois moins cher qu'un navigateur, et de ne rendre que les 10 % qui en ont besoin. Faites cela, et la comparaison de fournisseurs devient une décision d'arrondi.
Les parties qu'un crawler ne peut pas atteindre, les pages derrière une connexion et les outils internes sont là où le crawl s'arrête et où une session commence. ego (lite) exécute ce même flux de travail avec la connexion déjà rattachée, et s'arrête pour vous demander quand une étape nécessite un humain. Et quand une simple récupération renvoie déjà les lignes, c'est toute la réponse. Laissez le navigateur de côté.
Nous abordions ce premier crawl d'un million de pages en pensant que la plateforme serait la part chère. C'est la bande passante qui a répondu.