Webhooks RH : relier ATS et SIRH sans perdre d’événement

Webhooks RH ou polling : quel mécanisme choisir ?

Un webhook RH est une notification HTTP envoyée par un ATS, un SIRH ou un autre logiciel dès qu’un événement métier survient. Il réduit le délai et les appels inutiles par rapport au polling, mais ne suffit pas à garantir qu’un processus aboutira : en production, il faut vérifier l’émetteur, enregistrer le message, dédupliquer les livraisons et prévoir le rejeu.

Le polling inverse la responsabilité. L’intégration interroge l’API toutes les quelques minutes pour demander si une candidature, un contrat ou un dossier salarié a changé. La documentation officielle des webhooks Lucca souligne que ces notifications réduisent le nombre de requêtes, le risque d’atteindre les limites d’API et le délai de réaction. Cela ne fait pas du webhook une source de vérité : il reste d’abord un signal de changement.

Le meilleur compromis pour un flux critique est donc hybride : webhook pour réagir, API pour confirmer, polling de réconciliation pour contrôler. Le webhook transporte si possible un identifiant et peu de données ; le worker relit ensuite l’objet courant dans l’outil qui en est propriétaire. Cette séparation limite les données personnelles en transit et évite de prendre une décision à partir d’un payload déjà périmé.

Quels événements RH transmettre entre ATS et SIRH ?

Un catalogue d’événements RH doit décrire des faits métier, pas reproduire toute la base de l’ATS. « Candidature reçue », « entretien planifié », « candidat passé au statut recruté », « date d’arrivée modifiée » ou « embauche annulée » sont des intentions compréhensibles ; leur nom technique exact dépend du catalogue publié par chaque éditeur.

Une seule action utilisateur peut produire plusieurs événements. Lucca documente par exemple que la création d’un employé peut aussi créer un emploi et un poste, donc plusieurs messages distincts. Le consommateur doit connaître ces relations pour ne pas lancer trois fois le même onboarding.

Pour rendre le contrat exploitable, documentez au minimum : identifiant unique de l’événement, source, type, date du fait métier, identifiant de l’objet, version du schéma et identifiant de corrélation. La spécification CloudEvents de la CNCF formalise notamment l’unicité du couple source + id. Elle constitue un bon modèle d’enveloppe, sans signifier que votre ATS ou votre SIRH adopte ce standard nativement.

Avant de choisir un connecteur, vérifiez le catalogue d’événements, les objets lisibles et les droits d’écriture de chaque outil. La page intégrations ATS, SIRH et ERP présente la démarche utilisée par Profilya pour relier les briques existantes sans imposer une migration.

Architecture sécurisée d’un endpoint de webhook RH

Un endpoint de production doit faire peu de travail en synchrone : recevoir le corps brut, authentifier la livraison, contrôler son format, l’écrire dans un stockage durable, puis répondre selon le protocole documenté par l’émetteur. Les appels ATS/SIRH, la génération de documents et les notifications appartiennent au worker asynchrone.

Signature, authentification et attaque par rejeu

Quand l’éditeur signe ses webhooks, calculez la signature sur les octets bruts reçus, avec le secret et l’algorithme qu’il documente. La documentation GitHub sur la validation des livraisons recommande une comparaison en temps constant et avertit qu’un proxy qui transforme le payload peut faire échouer la vérification. Ne recopiez donc pas un exemple GitHub ou Stripe vers un ATS : le nom du header, la chaîne signée et l’algorithme sont propres au fournisseur.

Une signature valide ne prouve pas qu’une livraison est récente. Si le protocole de l’éditeur inclut un horodatage signé, appliquez sa fenêtre de tolérance. S’il fournit un identifiant de livraison, refusez une seconde exécution métier tout en sachant qu’un rejeu légitime peut conserver le même identifiant. En l’absence de ces mécanismes, placez l’endpoint derrière une passerelle et combinez les contrôles officiellement pris en charge — secret statique, mTLS ou liste d’adresses — sans en supposer la disponibilité.

Deux identités, deux niveaux de droits

Le secret du webhook authentifie la notification entrante ; il ne doit pas servir à appeler l’API RH. Le worker utilise une identité de service distincte, limitée aux objets et actions nécessaires. Séparez aussi test et production, prévoyez la rotation des secrets sans interruption et interdisez leur présence dans le code, les payloads de test ou les journaux.

Répondre vite évite les timeouts et les tentatives supplémentaires. Stripe recommande par exemple de retourner un statut 2xx avant la logique complexe. Cette pratique n’est sûre qu’après l’écriture durable du message : répondre avec succès avant la mise en file transforme une panne entre les deux opérations en événement perdu.

Idempotence, ordre, doublons et reprise après erreur

Une intégration fiable part de l’hypothèse qu’un événement peut arriver deux fois, en retard ou jamais. Ces propriétés ne sont pas identiques chez tous les fournisseurs : au 8 août 2026, Lucca documente une livraison au moins une fois et sans ordre garanti ; Stripe documente les doublons, le désordre et ses propres nouvelles tentatives ; GitHub indique au contraire que ses livraisons échouées ne sont pas automatiquement renvoyées. Il faut donc inscrire la garantie de chaque ATS et SIRH dans le dossier d’architecture.

Rendre chaque traitement idempotent

Créez une table d’inbox indexée par la source, l’abonnement et l’identifiant d’événement. Dans une même transaction, le worker réserve cet identifiant, applique l’évolution locale et marque le traitement comme terminé. Si le message revient, il renvoie le résultat connu sans recréer le salarié, renvoyer un e-mail ou relancer une commande de matériel.

Pour l’écriture dans un système distant, transmettez une clé d’idempotence uniquement si son API la documente. Sinon, conservez une correspondance stable entre l’objet source et l’objet cible, puis relisez la cible avant toute création. Un hash du payload peut aider au diagnostic, mais constitue une mauvaise clé principale : deux changements légitimes peuvent produire le même contenu et un champ sans importance peut modifier le hash.

Gérer l’ordre par objet, pas par arrivée

Comparez une version de ressource ou l’heure du fait métier lorsqu’elle est fournie avec une sémantique documentée. Un message ancien ne doit pas remettre « recruté » un candidat dont l’embauche a ensuite été annulée. Quand le payload ne donne pas assez d’information, utilisez-le comme invalidation de cache : relisez l’état courant dans l’API de la source et convergez vers cet état au lieu de rejouer aveuglément chaque transition.

Une dead-letter queue isole les messages qui échouent après plusieurs tentatives afin de les diagnostiquer et de les rejouer. La documentation Amazon SQS sur les files d’échec rappelle aussi qu’une DLQ peut rompre l’ordre strict d’une file FIFO. Le rejeu doit donc repasser par les contrôles d’idempotence et d’obsolescence, jamais contourner le worker normal.

Exemple : automatiser un onboarding de l’ATS au SIRH

Prenons un candidat dont le statut métier devient « recruté » dans l’ATS. Ce libellé décrit le scénario ; le nom de l’événement, le payload et les opérations disponibles doivent être vérifiés dans la documentation de vos logiciels. L’objectif n’est pas de copier tout le dossier candidat, mais d’ouvrir un onboarding contrôlé sans double saisie.

1. Recevoir et mettre en file : la passerelle valide la signature et le schéma, conserve l’identifiant de livraison, écrit le message dans la file durable et retourne la réponse attendue par l’ATS.
2. Dédupliquer : le worker consulte l’inbox. Si cet événement a déjà créé ou retrouvé un dossier SIRH, il s’arrête avec le même résultat.
3. Relire la candidature : avec une identité de service restreinte, il récupère dans l’ATS l’état actuel et uniquement les champs nécessaires au pré-onboarding. Si le statut a changé depuis l’émission, l’état courant prévaut.
4. Valider le mapping : l’intégration contrôle les champs obligatoires, normalise les valeurs autorisées et place les ambiguïtés — établissement, manager, type de contrat — dans une file de validation RH.
5. Créer ou retrouver le dossier : elle utilise l’opération officiellement exposée par le SIRH et enregistre la correspondance entre identifiant ATS et identifiant SIRH. Une reprise réutilise cette correspondance au lieu de créer un doublon.
6. Déclencher les tâches autorisées : après validation, le workflow peut notifier le manager ou préparer la checklist. La création de comptes, les droits et les envois contractuels suivent leurs propres validations et dates d’effet.
7. Réconcilier : un contrôle planifié vérifie que chaque recrutement éligible possède exactement un dossier cible et remonte les écarts avec l’identifiant de corrélation.

Le modèle de processus d’onboarding aide à définir les responsabilités et jalons métier avant de les automatiser. Pour un exemple d’intégration centré sur l’ATS, consultez également le workflow Teamtailor et n8n.

RGPD, monitoring et checklist avant mise en production

Les événements ATS–SIRH concernent des candidats et salariés identifiables. Le payload doit donc être limité à ce que le routage exige : identifiants, type, date et version sont souvent préférables à un CV, une adresse ou un contrat complet. La recommandation de la CNIL sur le partage par API insiste sur la minimisation, la sécurité dès la conception et la documentation des données partagées.

Définissez une durée de conservation séparée pour le message en file, la DLQ, la clé de déduplication et le journal d’audit. Les logs doivent référencer les données concernées plutôt que les dupliquer. Dans sa fiche sur la traçabilité des opérations, la CNIL recommande de journaliser les actions, anomalies et événements de sécurité, de protéger ces traces et d’en vérifier l’exploitabilité ; elle déconseille d’y conserver excessivement les données personnelles.

Les indicateurs qui détectent une panne silencieuse

• —Réception : événements acceptés, signatures invalides et schémas rejetés par source.
• —File : profondeur, âge du plus ancien message et temps d’attente avant traitement.
• —Traitement : succès, erreurs par catégorie, nombre de tentatives et latence de bout en bout.
• —Qualité : doublons détectés, événements obsolètes et écarts trouvés par la réconciliation.
• —Reprise : volume et âge de la DLQ, messages rejoués et résultats du rejeu.

Les seuils d’alerte dépendent du volume, des horaires RH et du délai métier convenu : ils ne doivent pas être copiés d’un fournisseur. Alertez au minimum sur l’absence anormale d’événements, l’augmentation de l’âge de file, tout message en DLQ et les échecs de réconciliation. Chaque alerte doit renvoyer vers un runbook avec propriétaire, diagnostic, décision de rejeu et procédure d’escalade.

Profilya peut auditer le catalogue d’événements de vos outils, prototyper le flux ATS–SIRH et tester les doublons, pannes et reprises avant ouverture en production. Découvrez notre accompagnement d’automatisation RH sur-mesure pour cadrer une intégration adaptée à vos données et à vos contraintes d’exploitation.