Webhooks ou interrogation périodique : choisir son mode de synchronisation

Deux systèmes RH qui doivent rester cohérents se synchronisent de deux façons : le système source prévient, ou le système destinataire demande. Le choix détermine la fraîcheur des données, le coût, et surtout la manière dont la synchronisation va échouer — parce qu'elle échouera.

Les deux modes

Le webhook. L'ATS envoie une requête vers une adresse que vous exposez dès qu'un événement se produit. Fraîcheur immédiate, aucune requête inutile.

L'interrogation périodique. Votre système demande à intervalles réguliers ce qui a changé depuis la dernière fois. Fraîcheur limitée par l'intervalle, requêtes majoritairement vides.

Les deux dernières lignes sont les plus importantes et les moins regardées.

Le défaut structurel du webhook

Un webhook est un envoi unique vers un système qui doit être disponible à cet instant précis. S'il ne l'est pas, l'événement est perdu — et rien ne le signale.

Le scénario complet : votre service redémarre pendant trente secondes, trois candidatures arrivent, l'ATS tente trois envois qui échouent. Selon l'éditeur, il réessaie quelques fois, puis abandonne. Trois dossiers n'existeront jamais dans le système destinataire. Personne ne le saura, parce qu'un webhook qui n'arrive pas ressemble exactement à une journée sans activité.

Trois questions à poser à l'éditeur avant de choisir ce mode :

1. Combien de tentatives, sur quelle durée ? Trois essais en cinq minutes ne couvrent pas une indisponibilité d'une heure.
2. Existe-t-il une file de rejeu consultable ? Pouvoir renvoyer les événements d'une période donnée transforme un incident en non-événement.
3. Les événements sont-ils ordonnés et identifiés ? Sans numéro de séquence, vous ne pouvez pas détecter un trou.

Le défaut structurel de l'interrogation périodique

Elle est robuste mais coûteuse et lente. À cinq minutes d'intervalle, une intégration émet plus de cent mille requêtes par an, dont l'écrasante majorité ne retourne rien. Sur une API plafonnée, ce quota est consommé pour rien.

Elle exige aussi un curseur fiable : « donne-moi ce qui a changé depuis tel horodatage ». Deux pièges classiques :

• Le décalage d'horloge. Si votre horloge avance de quelques secondes sur celle du serveur, vous sautez des enregistrements. Reculez systématiquement le curseur d'une marge — une minute suffit — et acceptez de retraiter des éléments déjà vus.
• Le champ de date qui ne bouge pas. Certains ATS ne mettent pas à jour la date de modification pour tous les changements. Un changement d'étape peut passer inaperçu si vous filtrez sur le mauvais champ. Vérifiez lequel bouge, empiriquement, avant de vous engager.

Conséquence directe : l'idempotence est obligatoire. Traiter deux fois le même événement doit produire le même résultat qu'une seule fois. Sans cela, un retraitement crée des doublons — le problème traité dans la note sur la déduplication.

Le mode qui marche vraiment

En production, l'architecture robuste n'est ni l'un ni l'autre : c'est les deux.

Le webhook pour la réactivité. Il traite le cas normal et donne la fraîcheur.

Une réconciliation périodique pour la sécurité. Une fois par heure, ou une fois par nuit selon l'enjeu, on demande à l'ATS tout ce qui a changé sur la période écoulée et on compare avec ce qu'on a reçu. Les écarts sont rattrapés, et surtout ils sont comptés.

Ce compteur d'écarts est l'indicateur de santé de l'intégration. À zéro en permanence, tout va bien. S'il monte, quelque chose se dégrade, et vous le savez avant que quelqu'un s'en aperçoive dans la paie.

Rendre une synchronisation observable

Quatre règles qui séparent une intégration exploitable d'une intégration qu'on redoute de toucher.

Alerter sur le silence, pas seulement sur l'erreur. Une intégration qui ne reçoit plus rien depuis vingt-quatre heures un mardi doit déclencher une alerte. L'absence de signal est le mode de défaillance le plus fréquent et le seul qui ne produit aucune erreur.

Journaliser la charge utile brute. Conservez ce que l'ATS a envoyé, pas seulement votre interprétation. Le jour où un champ arrive dans un format inattendu, c'est la seule trace qui permet de comprendre.

Distinguer l'échec temporaire de l'échec définitif. Une indisponibilité réseau se réessaie ; un champ obligatoire manquant ne se réessaiera jamais avec succès et doit partir dans une file d'erreurs à traiter à la main. Confondre les deux produit soit des boucles infinies, soit des pertes silencieuses.

Nommer un destinataire. Une alerte qui part dans un canal que personne ne lit n'existe pas. Si l'intégration alimente la paie, l'alerte doit atteindre quelqu'un qui sait quoi en faire — voir les notifications.

Sécuriser le point d'entrée

Un webhook expose une adresse publique qui écrit dans vos systèmes. Trois précautions minimales :

• Vérifier la signature. Les éditeurs sérieux signent leurs envois avec un secret partagé. Sans vérification, n'importe qui peut fabriquer une embauche.
• Répondre vite, traiter après. Accusez réception immédiatement et déposez l'événement dans une file. Un traitement long dans la requête finit en délai dépassé côté éditeur, qui réessaie, et vous traitez deux fois.
• Ne jamais faire confiance au contenu. Un identifiant reçu doit être vérifié auprès de l'API avant d'être utilisé pour écrire.

Questions fréquentes

Quel intervalle choisir pour une interrogation périodique ?

Cinq minutes pour ce qui déclenche une action visible, une heure pour de l'alimentation de tableau de bord, une fois par nuit pour de la réconciliation. Descendre sous la minute n'a de sens que si un humain attend le résultat, et consomme un quota disproportionné.

Que faire si l'ATS ne propose pas de webhooks ?

Interrogation périodique, avec un curseur sur le bon champ de date et une idempotence stricte. C'est parfaitement viable pour un flux de recrutement, où la fraîcheur à cinq minutes est largement suffisante. L'absence de webhooks n'est pas un motif d'élimination ; l'absence d'API l'est.

Faut-il un outil d'automatisation tiers ou du code ?

Un outil tiers convient pour un flux simple et non critique. Dès que le flux alimente la paie ou qu'il faut gérer les reprises sur erreur, l'absence de journal exploitable et de supervision devient un vrai problème. La ligne de partage : si une perte silencieuse a des conséquences, il faut un système qui sait dire qu'il a perdu quelque chose.

Comment tester une intégration avant de la mettre en production ?

Sur un environnement de test de l'ATS s'il en propose, sinon sur une offre factice en production avec des candidatures que vous créez vous-même. Testez explicitement les cas d'échec — service destinataire arrêté, champ manquant, événement envoyé deux fois — et pas seulement le chemin nominal. Ce sont ces cas qui se produiront.