Le défi
Un benchmark de juin 2026 par ApplyArc a testé cinq scrapers d'emplois LinkedIn sur 200 extractions réelles. Trois d'entre eux ont vu leur compte signalé ou discrètement restreint après environ 50 sauvegardes. Seuls deux ont survécu sans problème.
Ce benchmark résume toute l'histoire. Les sites d'emploi étaient autrefois des cibles faciles. Aujourd'hui, ils sont parmi les plus difficiles du web ouvert.
Si vous construisez quoi que ce soit qui dépend des données d'offres d'emploi (planification des effectifs, évaluation des salaires, cartographie des talents, l'embauche comme signal pour la recherche en actions), votre couche de collecte se heurte à une pile de défenses qui n'existait pas il y a deux ans. Indeed envoie des CAPTCHA aux sessions inconnues. LinkedIn corrèle les signaux côté navigateur à travers les rotations d'IP. Glassdoor applique un rate limit par ASN, pas par IP. ZipRecruiter pousse la fourchette de salaire et la date de publication dans du JavaScript qui ne s'affiche que si vos headers ressemblent à ceux d'une personne, pas d'un script.
Ainsi, le mur des 50 sauvegardes n'est pas un problème exclusif à LinkedIn. C'est une propriété de toute la catégorie.
Pourquoi les sites d'emploi deviennent de plus en plus difficiles
Trois choses ont changé en 2026, et elles se sont accumulées.
La première est que la détection de bots est devenue comportementale. Les vérifications statiques (User-Agent, réputation IP, requêtes par seconde) suffisaient pour arrêter les scrapers amateurs. Plus maintenant. Les défenses actuelles observent comment vous naviguez sur le site : quelles pages vous chargez et dans quel ordre, combien de temps vous y passez, si vous récupérez les mêmes bundles JS qu'un vrai navigateur mettrait en cache. Nous avons écrit sur ce changement dans Bot Detection Went Behavioral. Les sites d'emploi l'ont adopté tôt car leurs visiteurs effectuent un petit nombre d'actions répétables (chercher, cliquer, lire, sauvegarder), et cela rend un script facile à repérer lorsqu'il saute la moitié de la séquence.
La deuxième est que la taille du pool de proxy n'a plus d'importance. Un pool résidentiel de 50 millions d'IP n'aide pas lorsque la défense repose sur la corrélation d'empreintes à la couche de connexion couplée à la réputation ASN. Nous avons couvert cela dans Why Proxy Pool Size Stopped Mattering. Ce qui fonctionne, c'est de choisir la bonne sortie pour le site cible, et non d'avoir plus de sorties que n'importe qui d'autre.
La troisième est d'ordre légal. Indeed et LinkedIn ont tous deux des équipes juridiques qui portent plainte. L'ère où l'on exécutait un scraper public depuis son IP personnelle est révolue pour quiconque prévoit de vendre ce qu'il collecte.
À quoi ressemble la collecte maintenant
Pour le travail d'intelligence des talents en 2026, le modèle qui continue de fonctionner est une pile divisée : une véritable récupération rendue par navigateur pour les sites protégés, plus une sélection minutieuse des sorties pour ne pas provenir du même fournisseur que tous les autres bots.
Avec une plateforme comme FourA, cela représente deux produits qui communiquent entre eux.
Le navigateur gère la partie rendu : envoyez une URL avec unblocker: true, récupérez le HTML rendu, les cookies et une capture d'écran d'une vraie session de navigateur. Le JS est évalué, les champs chargés en différé se remplissent, et la request passe les vérifications de la couche de connexion qui attrapent la plupart des clients basiques. La sélection de proxy s'exécute en arrière-plan : la plateforme choisit une sortie par request et renvoie son identifiant opaque en base36 dans la response (au niveau supérieur r.proxy sur Single/Browser, ou r.session.proxy sur Auto), afin que les appels de suivi puissent réutiliser la même sortie lorsque vous avez besoin d'une continuité de session. Pour la plupart des travaux sur les sites d'emploi, Auto est le bon point d'entrée, il orchestre Single, Proxy et Browser en fonction de ce dont chaque cible a besoin, de sorte que votre code n'ait pas à le faire.
import requests
r = requests.post(
"https://api.foura.ai/api/auto",
headers={"Authorization": "Bearer pk_live_..."},
json={
"url": "https://www.example-jobs.com/search?q=data+engineer&l=Remote",
"validate": {
"status": {"accept": [200]},
"data": {"accept": ["data-testid=\"job-card\""],
"fail": ["Just a moment", "captcha"]},
},
},
).json()
# r["data"] or r["body"] — rendered content (Auto picks Single→"data" or Browser→"body" per host)
# r["session"] — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# Reuse r["session"]["proxy"] on the next call to stick to the same exit, or pass it
# via `ignoreProxies: [<id>]` to force a different one.
Deux notes sur ce que cela vous apporte réellement.
Le mur des 50 sauvegardes de type ApplyArc est principalement un problème de session, pas un problème de pool. Une véritable session de navigateur, pivotée de manière réfléchie, dure beaucoup plus longtemps avant de déclencher le rate limit qu'un client HTTP brut. Et la response contient un identifiant de proxy opaque plutôt qu'une sortie brute, ce qui permet à votre code de rester simple et vous évite d'avoir à suivre quelle sortie a traité quelle request.
La deuxième note concerne ce qui N'EST PAS dans l'extrait. Dédupliquer à travers les sites d'emploi (le même poste d'ingénieur data sur LinkedIn, Indeed et la propre page carrières de l'entreprise, avec trois titres légèrement différents) est votre problème, pas celui de la couche de collecte. Nous avons vu des équipes sous-estimer cela. La normalisation consomme plus de temps d'ingénierie que la récupération, et c'est là que la plupart des produits d'intelligence des talents finissent par rivaliser.
Résultats
Une équipe d'intelligence des talents qui suit 200 entreprises sur trois sites d'emploi a besoin d'environ 50 000 récupérations de pages par semaine : résultats de recherche, pages de détails d'emploi et actualisation occasionnelle de la page entreprise. Les chiffres que vous voudriez atteindre sur cette charge de travail :
- Taux de réussite supérieur à 95 % sur des cibles de la catégorie Indeed, où le succès signifie un HTML rendu avec la fourchette de salaire et la date de publication renseignées.
- Coût par offre inférieur à 0,004 $ de bout en bout, incluant le rendu et la sélection de la sortie.
- Cadence d'actualisation de 6 à 12 heures pour les rôles actifs, afin que vos tableaux de bord de signaux d'embauche ne soient pas en retard sur le marché.
Ces chiffres sont illustratifs, basés sur ce que rapportent les équipes exécutant ce modèle de pile divisée. Votre coût réel dépend des sites d'emploi que vous ciblez et de la manière dont vous filtrez les nouvelles publications.
Point clé à retenir
Les sites d'emploi sont désormais plus proches en difficulté de l'ad-tech et de la billetterie que du commerce électronique général. C'est un véritable changement, et cela explique pourquoi les bibliothèques de scraping qui fonctionnaient en 2024 continuent de se heurter au même mur en 2026.
Les équipes qui parviennent à évoluer au-delà arrêtent de penser au "scraper" comme à une unité de travail. Elles considèrent les sessions, les sorties et la déduplication comme trois préoccupations distinctes, et elles achètent l'infrastructure pour les deux premières afin que leurs ingénieurs puissent passer leur semaine sur la troisième. Les données d'offres d'emploi les moins chères sont celles que vous n'avez pas dû collecter de nouveau après un signalement.