# Pourquoi un extracteur d'offres renvoie moins de résultats que prévu

Vérifiez les filtres d'entrée demandés, le plafond de lignes partagé, la limite de pages, la raison d'arrêt de l'exécution et les échecs de source avant de conclure qu'une recherche d'emploi n'a donné aucun résultat. Une recherche réussie avec zéro offre, une exportation arrêtée par une limite et une requête web en échec exigent des corrections différentes. Un plafond est un nombre maximal fixe de lignes que vous autorisez le système à collecter. Une raison d'arrêt est un message enregistré qui explique pourquoi la collecte de données s'est terminée.

Un collecteur automatisé sur le web s'appelle un Actor. Un ensemble enregistré de réglages pour un Actor s'appelle une Task. Quand un extracteur d'offres n'exporte que 5 offres alors qu'une page web en montre 50 ou plus, on suppose souvent que la pagination a causé les lignes manquantes. La pagination est la façon dont un site web répartit une longue liste sur plusieurs pages. Cette supposition n'est pas fiable, car des filtres, des limites de lignes ou des pages bloquées peuvent produire exactement le même résultat. Vous devez tester chaque cause avec des preuves claires avant de modifier vos réglages.

```text
+-----------------------------------------------------------------------+
|                       Check Output Summary                            |
+-----------------------------------------------------------------------+
                                   |
         +-------------------------+-------------------------+
         |                                                   |
         v                                                   v
[stopReason matches reported cap]                   [failedRequests > 0]
         |                                                   |
         v                                                   v
Row cap or page limit hit based                      Request failures recorded;
on actual stored stop evidence.                      cause remains unresolved.
```

Pourquoi un extracteur d'offres renvoie moins de résultats que prévu

Le [LinkedIn Jobs Scraper](https://apify.com/chronometrica/linkedin-jobs-scraper) public et son [exemple de Task préréglée](https://apify.com/chronometrica/linkedin-jobs-scraper/examples/linkedin-jobs-scraper) définissent les règles de collecte. L'entrée enregistrée actuelle a `searchTerm` réglé sur software engineer, `maxItems` réglé sur 100, `maxPagesPerSearch` réglé sur 2, `postedWithin` réglé sur 7d, `saveOnlyUniqueItems` réglé sur true et `fetchJobDetails` réglé sur true. Votre test pilote remplace la requête, règle `maxItems` sur 3 et règle `maxPagesPerSearch` sur 1. Les différents modes d'entrée partagent un seul plafond de lignes. Conservez ces champs de sortie exacts : `jobId`, `jobUrl`, `title`, `companyName`, `locationRaw`, `descriptionStatus` et `scrapedAt`. Examinez ces clés exactes disponibles dans le résumé de sortie : `candidateItemsSeen`, `jobsSaved`, `duplicatesSkipped`, `stopReason`, `pagesParsed`, `pageLimitSearches`, `blockedRequests`, `failedRequests`, `detailRequests`, `detailPagesParsed`, `detailFailures`, plus les compteurs de filtre séparés `rowsExcludedByCompany`, `rowsExcludedByDate`, `rowsExcludedByJobType`, `rowsExcludedByWorkplace`, `rowsExcludedByExperience` et `rowsExcludedByTitle`. Utilisez les compteurs d'exclusion enregistrés, exacts et séparés ; chacun décrit sa propre catégorie. Une exécution témoin réussie de trois lignes prouve seulement qu'une entrée positive fonctionne ; elle ne prouve pas la cause d'une requête cible vide.

## Comment diagnostiquer un nombre de résultats plus bas

Suivez ces étapes pour trouver pourquoi votre nombre d'offres est plus bas que prévu.

1. Enregistrez les réglages d'entrée exacts, l'heure d'exécution, la sortie du résumé et un petit échantillon de lignes avant de rien modifier. Confirmez que votre nombre attendu vient exactement du même intitulé de poste, du même pays, de la même plage de dates, du même ordre de tri et du même compte utilisateur.
2. Validez votre mode d'entrée. Les recherches par mot-clé, les liens web de recherche directs et les numéros d'identification d'offres précis fonctionnent différemment. Si vous mélangez ces modes, ils partagent quand même un seul plafond total de lignes. Un mot de recherche restant peut élargir ou changer votre recherche sans que vous le sachiez.
3. Contrôlez les filtres restrictifs et les unités. Un rayon de distance exige un lieu. Un filtre sur le dernier jour peut réduire le périmètre des candidats par rapport à un filtre sur la semaine récente, sans garantir moins de lignes enregistrées, surtout avec des plafonds. Comparez le même périmètre d'entrée et de source, et examinez les preuves réelles. Les exclusions de titre et d'entreprise peuvent retirer des candidats. Modifiez une seule entrée justifiée à la fois et conservez les anciennes preuves.
4. Contrôlez `jobsSaved`, le plafond partagé `maxItems`, `maxPagesPerSearch` et `stopReason`. Des lignes enregistrées égales au plafond actif ne prouvent pas automatiquement qu'un plafond de lignes a causé l'arrêt, sauf si la preuve d'arrêt réellement enregistrée le dit. Une limite de pages peut arrêter la découverte avant toutes les pages visibles. N'affirmez pas que l'un ou l'autre a causé l'écart, sauf si la raison d'arrêt réelle du résumé le confirme.
5. Examinez les nombres de candidats, les doublons ignorés et les comptes de filtres. La clé du total d'éléments trouvés est `candidateItemsSeen`. La clé des doublons ignorés est `duplicatesSkipped`. Vous pouvez voir 20 annonces candidates, mais n'enregistrer que 5 lignes distinctes, chacune comptée une fois, car les annonces répétées ou filtrées sont ignorées. Vérifiez que les nombres du résumé s'additionnent selon la définition exacte de chaque champ.
6. Examinez séparément les erreurs d'accès à la source et les résultats des pages de détail. Une recherche peut trouver des intitulés d'offres même quand les [descriptions en texte intégral](/fr/articles/verification-descriptions-completes-export-emplois/) ne se chargent pas. La clé de l'état du texte intégral est `descriptionStatus`. Des descriptions textuelles manquantes ne signifient pas que le nombre d'annonces était zéro. Une requête web en échec est une erreur, pas une recherche réussie avec zéro offre.
7. Lancez un petit contrôle témoin, connu comme positif, avec la même version pour tester la collecte de base. Un contrôle témoin connu comme positif et réussi montre seulement que le témoin a fonctionné ; la recherche cible reste incertaine, sauf si le périmètre réel et les preuves de source la tranchent. Si le témoin échoue aussi, maintenez un gel de la source et de l'exécution, et contactez le support avec une entrée sûre et les preuves du résumé.
8. Lancez un seul test ciblé selon vos constats. N'augmentez pas sans cesse les limites et ne relancez pas un extracteur bloqué. Votre résultat final doit être un tableau de diagnostic qui indique une seule prochaine étape claire.

## Tableau de décision pour le diagnostic

Utilisez la preuve d'arrêt et de page réellement enregistrée, avec les descriptions pour le lecteur, pour diagnostiquer votre exécution.

| Nombre enregistré face au plafond | Preuve de raison d'arrêt | Échecs de requête | Activité des filtres | Diagnostic |
| --- | --- | --- | --- | --- |
| `jobsSaved` correspond au plafond actif | La raison d'arrêt enregistrée signale que le plafond est atteint | 0 | 0 | La collecte s'est arrêtée parce qu'elle a atteint la limite de lignes, ce que confirme la preuve d'arrêt réelle. |
| `jobsSaved` est sous le plafond actif | La raison d'arrêt enregistrée signale que la limite de pages est atteinte | 0 | 0 | La collecte s'est arrêtée parce qu'elle a atteint la limite de pages, ce que confirme la preuve d'arrêt réelle. |
| `jobsSaved` est sous le plafond actif | La raison d'arrêt enregistrée signale un épuisement normal | 0 | Des compteurs de filtres actifs sont présents | Les règles de filtre ont retiré des lignes candidates correspondantes pendant l'épuisement normal de l'entrée. |
| 0 | La raison d'arrêt enregistrée signale des problèmes de requête ou de blocage | Supérieur à 0 | 0 | Échecs de requête enregistrés ; cause non résolue. |

## Exemples résolus fictifs

Quatre exécutions inventées, chacune avec sa propre entrée et son propre résumé :

- A : `maxItems` 3, `jobsSaved` 3, avec une raison d'arrêt par plafond explicitement signalée. Diagnostic : le plafond d'enregistrement partagé est atteint, d'après la preuve d'arrêt explicite ; aucune inférence sur le total des offres du marché.
- B : `maxItems` 20, `maxPagesPerSearch` 1, `jobsSaved` 5, avec une raison d'arrêt par page explicitement signalée. Diagnostic : la limite de pages explique l'arrêt de collecte de cette exécution, d'après la preuve d'arrêt explicite ; essayez une page de plus si la source le permet, pas une pagination illimitée.
- C : `candidateItemsSeen` 10, `duplicatesSkipped` 3, `rowsExcludedByTitle` 2, `jobsSaved` 5, avec un épuisement normal de l'entrée signalé dans les descriptions pour le lecteur. Dans cet exemple fictif, les catégories de décompte ne se chevauchent pas : une même annonce n'est pas comptée à la fois comme doublon et comme exclusion. Ainsi, 10 moins 3 moins 2 égale 5. Diagnostic : la politique d'éléments distincts et de filtre explique le nombre enregistré. Notez que 3 offres enregistrées sur 5 ont un texte intégral prêt, tandis que 2 textes manquent ; cet état de détail ne change pas le compte de 5 annonces.
- D : `jobsSaved` 0, 1 requête en échec, 1 requête bloquée. Diagnostic : les échecs de requête sont établis, mais la cause, problème de réseau ou blocage d'accès, n'est pas résolue. Ces échecs ne prouvent pas qu'il n'y a aucune offre sur le marché.

## Registre de diagnostic

Notez les mesures de votre exécution dans un registre comme celui-ci pour comparer les réglages et choisir votre prochain contrôle.

| Exécution | Périmètre actif | Plafond actif | État des pages | Preuves candidats / filtres | État de la source | Diagnostic et contrôle suivant |
| --- | --- | --- | --- | --- | --- | --- |
| A | Software Engineer, US | 3 | Page 1 sur 2 | 3 vus / 0 filtrés | Sain | Arrêt explicite par plafond. Augmentez `maxItems` si c'est justifié. |
| B | Software Engineer, US | 20 | Page 1 sur 1 | 5 vus / 0 filtrés | Sain | Arrêt explicite par page. Passez `maxPagesPerSearch` à 2 si c'est permis. |
| C | Software Engineer, US | 100 | Page 2 sur 2 | 10 vus / 3 doublons, 2 exclusions de titre | Sain | Épuisement normal de l'entrée. Revoyez les réglages d'exclusion de titre. |
| D | Software Engineer, US | 100 | Page 0 sur 2 | 0 vus / 0 filtrés | 1 en échec, 1 bloquée | Source incertaine au-delà des échecs signalés. Suspendez l'exécution et signalez les preuves du journal. |

## Action suivante

Ouvrez le [LinkedIn Jobs Scraper](https://apify.com/chronometrica/linkedin-jobs-scraper) ou son [exemple de Task préréglée](https://apify.com/chronometrica/linkedin-jobs-scraper/examples/linkedin-jobs-scraper) avec un seul terme de recherche cible, réglez maxItems sur 3, lancez l'Actor, enregistrez les clés du résumé de sortie, et utilisez le tableau de décision ci-dessus pour choisir votre seul test suivant.

## Sources et lectures complémentaires

- [LinkedIn Jobs Scraper](https://apify.com/chronometrica/linkedin-jobs-scraper)
- [Aide sur le workflow n8n LinkedIn Job Scraper, sur Reddit](https://www.reddit.com/r/n8n/comments/1t9trjv/n8n_linkedin_job_scraper_workflow_help/)