Le Défi
Un benchmark d'ApplyArc de juin 2026 a testé cinq scrapers d'offres d'emploi LinkedIn sur 200 extractions réelles. Trois ont vu leur compte signalé ou discrètement bridé après environ 50 enregistrements. Seuls deux ont survécu sans encombre.
Ce benchmark résume toute la situation. Les plateformes de recrutement étaient autrefois des cibles faciles. Elles font aujourd'hui partie des plus difficiles du web ouvert.
Si vous développez une solution qui dépend des données d'offres d'emploi (planification des effectifs, analyse comparative des salaires, cartographie des talents, suivi des recrutements comme signal d'investissement), votre couche de collecte affronte un ensemble de défenses qui n'existait pas il y a deux ans. Indeed affiche des pages de vérification aux sessions inconnues. LinkedIn corrèle les signaux côté navigateur à travers les rotations d'IP. Glassdoor applique son rate limit par ASN, et non par IP. ZipRecruiter intègre la fourchette salariale et la date de publication dans un code JavaScript qui s'exécute uniquement si vos headers imitent ceux d'un humain, et non ceux d'un script.
Le mur des 50 enregistrements n'est donc pas un problème propre à LinkedIn. C'est une caractéristique de l'ensemble du secteur.
Pourquoi les sites de recrutement deviennent de plus en plus difficiles d'accès
Trois facteurs ont évolué en 2026, et ils se sont cumulés.
Le premier est que la détection de bots est devenue comportementale. Les vérifications statiques (User-Agent, réputation de l'IP, requêtes par seconde) suffisaient autrefois à stopper les scrapers amateurs. Ce n'est plus le cas. Les défenses actuelles analysent votre navigation sur le site : quelles pages vous chargez, dans quel ordre, combien de temps vous y passez, si vous rechargez les mêmes bundles JS qu'un vrai navigateur mettrait en cache. Nous avons décrit cette transition dans Bot Detection Went Behavioral. Les plateformes d'emploi l'ont adoptée tôt car leurs visiteurs effectuent un nombre restreint d'actions répétables (rechercher, cliquer, lire, enregistrer). Cela rend un script facile à repérer lorsqu'il saute la moitié de la séquence.
Le deuxième est que la taille du pool de proxys n'a plus d'importance. Un pool résidentiel de 50 millions d'IP n'est d'aucune aide lorsque la défense repose sur la corrélation d'empreintes à la couche de connexion combinée à la réputation de l'ASN. Nous avons abordé ce point dans Why Proxy Pool Size Stopped Mattering. Ce qui fonctionne, c'est de choisir le bon point de sortie pour le site cible, et non d'avoir plus d'adresses que les autres.
Le troisième est d'ordre juridique. Indeed et LinkedIn disposent tous deux d'équipes juridiques qui engagent des poursuites. L'époque où l'on pouvait exécuter un scraper public depuis son IP personnelle est révolue pour quiconque prévoit de commercialiser les données collectées.
À quoi ressemble la collecte aujourd'hui
Pour les activités d'intelligence RH en 2026, la méthode qui fonctionne repose sur une architecture scindée : une récupération via un rendu de navigateur réel pour les plateformes protégées, associée à une sélection rigoureuse de la sortie pour ne pas provenir du même fournisseur que tous les autres bots.
Avec une plateforme comme FourA, cela se traduit par deux produits qui interagissent.
Browser gère le rendu : envoyez une URL avec unblocker: true, récupérez le code HTML rendu, les cookies et une capture d'écran issus d'une véritable session de navigateur. Le JS est évalué, les champs en lazy-loading se chargent et la requête passe les contrôles de couche de connexion qui bloquent la plupart des clients basiques. La sélection de proxy s'exécute en arrière-plan : la plateforme choisit une sortie par requête et renvoie son identifiant opaque en base36 dans la réponse (au niveau racine r.proxy sur Single/Browser, ou r.session.proxy sur Auto), afin que vos appels suivants puissent réutiliser la même sortie lorsque vous avez besoin de continuité de session. Pour la majorité des tâches sur les sites d'emploi, Auto est le point d'entrée idéal : il orchestre Single, Proxy et Browser selon les besoins de chaque cible, sans logique supplémentaire dans votre code.
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 remarques sur ce que cela vous apporte concrètement.
Le blocage des 50 enregistrements type ApplyArc relève principalement d'un problème de session, pas d'un problème de pool. Une session de navigateur réelle, alternée intelligemment, dure bien plus longtemps avant de déclencher le rate limit qu'un simple client HTTP brut. De plus, la réponse contient un proxy id opaque plutôt qu'une sortie brute, ce qui simplifie votre code et vous évite d'avoir à suivre quelle sortie a traité quelle requête.
La seconde remarque concerne ce qui ne figure PAS dans l'extrait. La déduplication entre les différentes plateformes (le même poste de data engineer sur LinkedIn, Indeed et le site carrières de l'entreprise, avec trois intitulés légèrement différents) est votre problème, pas celui de la couche de collecte. Nous avons vu de nombreuses équipes sous-estimer ce point. La normalisation consomme plus de temps d'ingénierie que la récupération elle-même, et c'est là que la plupart des produits de talent intelligence finissent par se différencier.
Résultats
Une équipe de talent intelligence suivant 200 entreprises sur trois plateformes a besoin d'environ 50 000 récupérations de pages par semaine : résultats de recherche, pages de détail des offres et actualisation occasionnelle des pages d'entreprise. Les indicateurs à viser pour cette charge de travail :
- Taux de réussite supérieur à 95 % sur des cibles du niveau d'Indeed, où le succès signifie un HTML rendu avec la fourchette salariale et la date de publication renseignées.
- Coût par offre inférieur à 0,004 $ de bout en bout, rendu et sélection de la sortie inclus.
- Fréquence d'actualisation de 6 à 12 heures pour les postes actifs, afin que vos tableaux de bord de signaux de recrutement ne soient pas en décalage avec le marché.
Ces chiffres sont illustratifs, basés sur les retours d'équipes exploitant cette architecture découplée. Votre coût réel dépend des plateformes ciblées et de la rigueur de vos filtres sur les offres récentes.
À retenir
La difficulté des sites d'emploi est désormais plus proche de celle de l'ad-tech et de la billetterie que de celle du e-commerce classique. C'est une vraie rupture, et cela explique pourquoi les bibliothèques de scraping fonctionnelles en 2024 butent systématiquement sur les mêmes obstacles en 2026.
Les équipes qui passent à l'échelle cessent de concevoir « le scraper » comme un bloc unique. Elles traitent les sessions, les sorties et la déduplication comme trois problématiques distinctes, et délèguent l'infrastructure des deux premières pour que leurs ingénieurs se concentrent sur la troisième. La donnée d'offre d'emploi la moins chère est celle que vous n'avez pas eu à collecter à nouveau après un blocage.