# Comment recevoir de nouvelles alertes d'emploi sans annonces répétées

Pour créer une seule fois le travail de notification de chaque nouvelle clé combinée, formée d'une plateforme non vide et d'un identifiant d'emploi, et pour traiter les nouvelles tentatives des éléments existants éligibles en attente ou en échec, stockez chaque annonce publique collectée dans un registre persistant.

Une exécution de collecte rassemble des annonces publiques collectées, mais un filtre de date ne permet pas d'établir si une offre est active. Des identifiants d'annonce différents peuvent aussi désigner le même poste vacant sous-jacent. Cette méthode n'apporte ni prévention des doublons ni garantie d'exécution exactement une fois. Une livraison inconnue doit être examinée avant une nouvelle tentative.

```text
New Collection Batch
   |
   +---> New Nonblank Platform + Job ID? ---> Create Pending Notice Work (Once)
   |
   +---> Existing Eligible Pending/Failed ID? ---> Retry Notice Work
```

Comment recevoir de nouvelles alertes d'emploi sans annonces répétées

## Termes essentiels

Comprendre ces termes de base aide à garder votre suivi d'emploi de qualité et exact :

- Annonce : une publicité d'emploi publique publiée sur un site d'offres, identifiée par une chaîne de texte appelée identifiant d'emploi.
- Actor : un programme de collecte hébergé qui récupère des données d'emploi depuis des pages web publiques.
- Tâche : un ensemble enregistré d'entrées de recherche, comme des mots-clés cibles et un lieu, utilisé par un Actor.
- Heure de première observation : l'heure exacte à laquelle votre système de suivi enregistre pour la première fois un identifiant d'annonce précis. Elle est différente de l'heure de publication d'origine sur le site d'offres.
- État d'alerte : un enregistrement qui indique si un avis pour un emploi est en attente, envoyé avec succès, ou en échec.

## Configurer votre collecte source

Avant de suivre les nouvelles publications, vous avez besoin d'un flux d'emplois quotidien stable. Vous pouvez utiliser le [LinkedIn Jobs Scraper](https://apify.com/chronometrica/linkedin-jobs-scraper) pour collecter des annonces d'emploi brutes.

Commencez par un préréglage de recherche étroit afin de tester facilement votre registre de suivi. La tâche par défaut utilise plusieurs mots-clés, mais vous devez d'abord modifier l'entrée pour cibler un seul mot-clé.

```json
{
  "searchTerm": "software engineer",
  "location": "United States",
  "maxItems": 3,
  "postedWithin": "7d", "distance": 25,
  "sortBy": "date",
  "jobType": "any",
  "workplaceType": "any",
  "experienceLevel": "any",
  "maxPagesPerSearch": 5,
  "saveOnlyUniqueItems": true,
  "balanceKeywordCoverage": true,
  "fetchJobDetails": true,
  "requestDelayMillis": 500
}
```

Configurer votre collecte source

Régler `saveOnlyUniqueItems` sur `true` retire les annonces en double à l'intérieur d'une seule exécution. Cependant, cela n'arrête pas les répétitions d'un jour à l'autre. La limite `maxItems` s'applique à tous les termes de recherche d'une exécution. Si une exécution atteint une limite numérique ou rencontre un échec de la source, certains emplois peuvent être manqués. Traitez les collectes manquées ou en échec comme des données inconnues plutôt que de supposer qu'aucun nouvel emploi n'a été publié.

Quand une exécution réussit, extrayez ces champs clés pour votre pipeline de suivi :

Le collecteur produit des champs précis pour chaque annonce.

| Nom du champ | Description |
| --- | --- |
| `jobId` | Identifiant d'emploi de la plateforme source |
| `jobUrl` | Lien d'emploi de la plateforme source |
| `title` | Intitulé du poste |
| `companyName` | Nom de l'entreprise qui recrute |
| `locationRaw` | Texte brut du lieu |
| `postedAt` | Heure de publication dérivée ou analysée |
| `postedAtRaw` | Libellé brut de publication issu de la source |
| `scrapedAt` | Heure de la collecte |
| `descriptionStatus` | État de la récupération de la description d'emploi |

Les libellés bruts restent avec les heures analysées ou dérivées. Un âge relatif n'est pas une heure de publication d'origine exacte. Les champs du lecteur pour la première observation, la dernière observation et l'action sont distincts. Le contrôle d'acceptation actuel connu, limité à trois lignes, n'établit que l'identité de la source et la structure du temps. Il ne prouve pas un système d'alertes déployé sur plusieurs jours.

## La méthode de suivi quotidien en 8 étapes

Suivez ces huit étapes pour traiter les annonces entrantes et gérer les alertes sans envoyer de doublons.

1. Définissez une alerte éligible : une alerte éligible est un identifiant d'annonce collecté qui répond à vos critères de base (comme l'intitulé du poste ou le lieu) et qui n'a pas encore été traité. Gardez vos règles de filtre à côté de vos enregistrements d'exécution.
2. Conservez les lignes source et inspectez la sortie de l'exécution : enregistrez les sorties brutes des lots. Vérifiez les erreurs de collecte, les plafonds d'éléments ou les avertissements avant de traiter les lignes. Un lot en échec signifie que les conditions du marché sont inconnues, et non qu'il y a zéro nouvelle annonce.
3. Créez une table de suivi indexée par une plateforme non vide et jobId sous forme de texte. Les observations dont l'identifiant est manquant restent séparées et non résolues. Ne les fusionnez jamais au motif que leurs identifiants sont vides. Conservez les champs du lecteur `first_seen_at`, `last_seen_at`, `jobUrl`, `review_status`, `alert_state`, `alert_attempt_at` et `error_note`. La collecte source `scrapedAt` diffère de l'heure d'action du flux de travail.
4. Traitez les identifiants du lot entrant : pour chaque clé distincte du lot actuel, vérifiez si elle existe dans votre table de suivi. Si elle existe, mettez à jour seulement `last_seen_at`. Si elle manque, créez une nouvelle ligne avec `review_status` réglé sur en attente et `alert_state` réglé sur en attente. N'écrasez jamais `first_seen_at`.
5. Examinez l'éligibilité avant l'envoi : vérifiez les conditions requises, comme le [lieu ou le statut de travail à distance](/fr/articles/%C3%A9ligibilit%C3%A9-emploi-%C3%A0-distance/). Si une condition requise ne peut pas être vérifiée, gardez `review_status` en attente. Si un emploi ne respecte pas vos règles, marquez-le comme exclu avec une raison claire afin que les exécutions futures ne l'examinent plus.
6. Donnez à l'avis une clé stable liée à la plateforme et à l'identifiant d'emploi. Envoyez seulement les avis éligibles en attente. Marquez envoyé seulement après que le service du fournisseur confirme son action. Envoyé signifie une soumission confirmée par le fournisseur, et non la preuve d'arrivée dans la boîte de réception. L'acceptation HTTP 200 seule n'est pas une confirmation de livraison. Une confirmation inconnue signifie que la livraison est inconnue et doit être inspectée avant une nouvelle tentative. Il n'y a pas de garantie de livraison exactement une fois.
7. Gérez les échecs de livraison en sécurité : si un avis ne s'envoie pas, retentez la livraison plus tard sans effacer `first_seen_at` ni recollecter les emplois depuis la source. Gardez les erreurs de collecte séparées des erreurs de livraison. Enregistrez votre état après chaque étape afin de pouvoir redémarrer en sécurité.
8. Signalez les mesures clairement : séparez vos mesures en annonces distinctes collectées, identifiants nouvellement observés, avis éligibles, avis envoyés confirmés, et avis en attente ou en échec. L'absence de nouveaux avis signifie qu'aucune nouvelle correspondance acceptée n'a été trouvée aujourd'hui, et non que le marché de l'emploi dans son ensemble a cessé de recruter.

## Exemple résolu fictif

Tous les identifiants, dates et événements sont fictifs. La base avant le 3 octobre ne contient que deux clés : `J1` vu pour la première fois le 1er oct., envoyé, et `J2` vu pour la première fois le 2 oct., envoyé. Le registre final contient quatre clés, tandis que la base n'en contient que deux.

Le 3 octobre, la collecte renvoie quatre lignes brutes ou d'import qui contiennent les clés `J1`, `J2`, `J3` et `J3`. Cela représente 4 observations, 3 clés distinctes, 2 clés existantes et 1 clé non vue (`J3`). L'examen de `J3` est réussi. Sa première tentative d'avis est confirmée comme non acceptée, donc une nouvelle tentative ultérieure est sûre dans ce cas fictif.

Le 4 octobre, la collecte renvoie 3 clés : `J2`, `J3` et `J4`. Cela représente 3 clés distinctes, 2 clés existantes et 1 clé non vue (`J4`). Pour `J4`, le lieu manquant laisse l'examen en attente, sans avis. Une soumission confirmée par le fournisseur le 4 oct. n'est pas une livraison dans la boîte de réception.

Le 5 octobre, une collecte en échec ne change aucun historique et ne permet aucune affirmation d'absence.

Table de suivi principale :

| Clé | Première observation | Dernière observation | État de l'examen | État de l'alerte | Heure de la tentative | Note d'erreur |
| --- | --- | --- | --- | --- | --- | --- |
| linkedin:J1 | 2026-10-01T08:00:00Z | 2026-10-03T08:00:00Z | Réussi | Envoyé | 2026-10-01T08:05:00Z | Aucune |
| linkedin:J2 | 2026-10-02T08:00:00Z | 2026-10-04T08:00:00Z | Réussi | Envoyé | 2026-10-02T08:05:00Z | Aucune |
| linkedin:J3 | 2026-10-03T08:00:00Z | 2026-10-04T08:00:00Z | Réussi | Envoyé | 2026-10-04T08:05:00Z | Réussite de la nouvelle tentative le 4 oct. |
| linkedin:J4 | 2026-10-04T08:00:00Z | 2026-10-04T08:00:00Z | En attente | En attente | Aucune | Lieu manquant |

Journal distinct des avis tentés et confirmés :

| Clé | Heure de la tentative | Type d'événement | Réponse du service | État résultant |
| --- | --- | --- | --- | --- |
| linkedin:J3 | 2026-10-03T08:05:00Z | Tentative de livraison | 500 Rejeté | Échec |
| linkedin:J3 | 2026-10-04T08:05:00Z | Nouvelle tentative de livraison | 200 Accepté | Envoyé |

Résumé d'activité :

- Identifiants observés pour la première fois le 3 oct., absents de l'historique de suivi antérieur : 1 (`J3`)
- Identifiants observés pour la première fois le 4 oct., absents de l'historique de suivi antérieur : 1 (`J4`)
- Actions confirmées du fournisseur sur ces jours : 1 (nouvelle tentative de `J3`)
- Total des clés suivies : 4

## Action finale

Pour commencer à recevoir des alertes sans répétition, ouvrez le [LinkedIn Jobs Scraper](https://apify.com/chronometrica/linkedin-jobs-scraper) ou sa tâche préréglée [Scrape Fresh LinkedIn Jobs From the Last 7 Days](https://apify.com/chronometrica/linkedin-jobs-scraper/examples/scrape-fresh-linkedin-jobs-from-the-last-7-days), définissez un seul mot-clé cible avec un petit plafond d'éléments, et construisez votre table de suivi avant d'exécuter votre prochain lot de collecte.

## Sources et lectures complémentaires

- [Actor source LinkedIn Jobs Scraper](https://apify.com/chronometrica/linkedin-jobs-scraper)
- [Préréglage de tâche Scrape Fresh LinkedIn Jobs](https://apify.com/chronometrica/linkedin-jobs-scraper/examples/scrape-fresh-linkedin-jobs-from-the-last-7-days)
- [Discussion de la communauté sur les alertes d'emploi en double](https://www.reddit.com/r/n8nforbeginners/comments/1teylba/built_a_linkedin_job_notifier_using_n8n_local_db/)