Le défi
En juin 2026, un benchmark de ApplyArc a testé cinq scrapers de LinkedIn sur 200 extractions d'offres réelles. Trois d'entre eux ont vu leur compte signalé ou discrètement bridé après environ 50 sauvegardes. Seuls deux ont survécu sans encombre.
Ce benchmark résume toute la situation. Les job boards étaient autrefois des cibles faciles. Ils figurent désormais parmi les plus difficiles du web ouvert.
Si vous développez un produit qui dépend des données d'offres d'emploi (planification des effectifs, analyse comparative des salaires, cartographie des talents, recrutement comme signal pour la recherche d'actions), votre couche de collecte fait face à un ensemble de défenses inexistantes il y a deux ans. Indeed impose des CAPTCHAs aux sessions inconnues. LinkedIn corrèle les signaux côté navigateur à travers les rotations d'IP. Glassdoor applique un rate limit par ASN, et non par IP. ZipRecruiter injecte la fourchette de salaire et la date de publication dans un JavaScript qui ne s'exécute que si vos headers imitent un humain, pas un script.
La barrière des 50 sauvegardes n'est donc pas un problème propre à LinkedIn. C'est une caractéristique de toute cette catégorie de sites.
Pourquoi les job boards deviennent de plus en plus difficiles à scraper
Trois facteurs ont changé en 2026, et ils se cumulent.
Le premier est que la détection de bots est devenue comportementale. Les vérifications statiques (User-Agent, réputation d'IP, requêtes par seconde) suffisaient autrefois à bloquer les scrapers amateurs. Ce n'est plus le cas. Les défenses actuelles analysent votre navigation sur le site : quelles pages vous chargez et dans quel ordre, le temps que vous y passez, ou si vous téléchargez à nouveau les mêmes bundles JS qu'un vrai navigateur mettrait en cache. Nous avons décrit cette transition dans La détection de bots est devenue comportementale. Les job boards l'ont adoptée très tôt car leurs visiteurs effectuent un nombre restreint d'actions répétitives (rechercher, cliquer, lire, sauvegarder), ce qui rend un script facile à repérer lorsqu'il saute la moitié des étapes.
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 ne sert à rien quand la défense repose sur la corrélation d'empreintes (fingerprinting) au niveau de la connexion et sur la réputation de l'ASN. Nous avons traité ce sujet dans Pourquoi la taille du pool de proxys n'a plus d'importance. Ce qui fonctionne, c'est de choisir le bon point de sortie pour le site cible, et non d'avoir plus de sorties 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 faire tourner un scraper public depuis son IP domestique est révolue pour quiconque souhaite commercialiser les données collectées.
À quoi ressemble la collecte aujourd'hui
Pour le travail de talent intelligence en 2026, l'approche qui fonctionne toujours repose sur une architecture hybride : une récupération avec rendu par un vrai navigateur pour les sites protégés, combinée à une sélection rigoureuse des points de sortie pour éviter de provenir du même fournisseur que tous les autres bots.
Avec une plateforme comme FourA, cela revient à faire communiquer deux produits entre eux.
Browser gère la partie rendu : envoyez une URL avec unblocker: true, et récupérez le HTML rendu, les cookies ainsi qu'une capture d'écran d'une session de navigation réelle. Le JS est évalué, les champs chargés en différé (lazy-loaded) se remplissent, et la requête passe les contrôles au niveau de la connexion qui bloquent la plupart des clients basiques. La sélection de proxy s'effectue en arrière-plan : la plateforme choisit un point de sortie par requête et renvoie son identifiant opaque en base36 dans la réponse (au niveau supérieur r.proxy sur Single/Browser, ou r.session.proxy sur Auto), permettant aux appels suivants de réutiliser la même sortie lorsque vous avez besoin de continuité de session. Pour la plupart des tâches sur les job boards, Auto est le point d'entrée idéal : il orchestre Single, Proxy et Browser selon les besoins de chaque cible, évitant à votre code de s'en charger.
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.
La barrière des 50 sauvegardes de type ApplyArc est principalement un problème de session, pas de pool. Une session de navigation réelle, pivotée intelligemment, dure beaucoup plus longtemps avant de déclencher le rate-limiter qu'un simple client HTTP. De plus, la réponse contient un identifiant de proxy opaque plutôt qu'une sortie brute, ce qui simplifie votre code et vous évite de suivre quelle sortie a géré quelle requête.
La seconde remarque concerne ce qui n'apparaît pas dans l'extrait de code. La déduplication entre les différents sites (le même poste de data engineer sur LinkedIn, Indeed et la page recrutement de l'entreprise, avec trois intitulés légèrement différents) relève de votre responsabilité, pas de celle de la couche de collecte. Nous avons vu des équipes sous-estimer cet aspect. La normalisation consomme plus de temps d'ingénierie que la récupération des données, et c'est là que se joue la concurrence entre la plupart des produits de talent intelligence.
Résultats
Une équipe de talent intelligence qui suit 200 entreprises sur trois job boards a besoin d'environ 50 000 récupérations de pages par semaine : résultats de recherche, pages de détails des offres et rafraîchissements occasionnels des pages d'entreprises. Voici les chiffres que vous devriez viser pour cette charge de travail :
- Un taux de réussite supérieur à 95 % sur les cibles de type Indeed, où la réussite se traduit par un HTML rendu contenant la fourchette de salaire et la date de publication.
- Un coût par offre inférieur à 0,004 $ de bout en bout, incluant le rendu et la sélection du point de sortie.
- Une cadence de rafraîchissement 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 et basés sur les retours d'équipes utilisant cette architecture hybride. Votre coût réel dépendra des job boards ciblés et de la rigueur de vos filtres pour obtenir les publications récentes.
Ce qu'il faut retenir
Les job boards se rapprochent désormais plus de l'ad-tech et de la billetterie en termes de difficulté que de l'e-commerce classique. C'est un véritable changement de paradigme, qui explique pourquoi les bibliothèques de scraping fonctionnelles en 2024 butent systématiquement sur cette barrière en 2026.
Les équipes qui parviennent à passer à l'échelle cessent de considérer « le scraper » comme une unité de travail unique. Elles abordent les sessions, les points de sortie et la déduplication comme trois problématiques distinctes, et achètent l'infrastructure pour les deux premières afin 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.