Un flow n8n qui écoute les nouvelles candidatures Ashby, récupère le dossier du candidat plus le rubric des critères incontournables du poste, demande à Claude de scorer la candidature par rapport au rubric avec des preuves citées depuis le CV, et route le résultat vers l’un des trois canaux Slack : #review-needed (la majorité), #fast-track (décile supérieur, par score agrégé et récence), ou #surfaced-not-rejected (en dessous du seuil mais maintenu visible — le flow ne rejette jamais automatiquement). Remplace l’heure quotidienne de désherbage de boîte mail du recruteur par une file Slack classée qui prend 12-15 minutes à parcourir.
Quand l’utiliser
- Vous recevez ≥30 candidatures inbound par poste par semaine, et le recruteur passe plus d’une heure par jour à lire des CVs qui ne correspondent majoritairement pas.
- Le poste dispose d’un rubric écrit avec des ancres comportementales par dimension (correspondance de compétences, niveau, localisation/autorisation de travail, probabilité de réponse). Le modèle de rubric se trouve dans le
_README.mddu bundle. Sans lui, le flow score sur des intuitions. - Vous utilisez Ashby ou un autre ATS qui livre un webhook par candidature. Greenhouse, Lever, Workable sont tous compatibles ; le nœud d’intake du flow s’échange proprement. Les plateformes ATS en mode polling uniquement fonctionnent mais avec un plancher de latence de 5 minutes.
- Un recruteur parcourt la file
#review-neededau moins quotidiennement et traite chaque entrée. Le flow ne déplace pas les candidats vers une étape dans l’ATS.
Quand NE PAS l’utiliser
- Rejet automatique dans la boucle. Le flow classe et route ; il ne rejette jamais. Câbler une action
rejectsur un seuil de score transforme ceci en prise de décision automatisée — ce qui déclenche les obligations d’audit de biais de la NYC Local Law 144 dans l’année suivant le déploiement, et les obligations de système à haut risque de l’Annexe III de l’EU AI Act pour tout candidat résidant dans l’UE. Le troisième bucket du flow (#surfaced-not-rejected) existe précisément pour que le recruteur voie qui aurait été rejeté et puisse intervenir. - Données démographiques comme input de scoring. Le flow refuse de scorer sur le nom, la photo, le nom de l’école comme signal autonome, l’adresse, l’âge inféré depuis l’année de diplôme, les pronoms de genre, les pénalités de lacune d’emploi, ou « culture fit » sans ancres comportementales. La checklist de conformité dans le
_README.mddu bundle s’exécute comme pré-vol sur le rubric. - Remplacer le jugement du recruteur sur les cas limites. Un score agrégé dans les 15 % du seuil route vers
#review-needed, pas vers l’une ou l’autre des queues. C’est un buffer de zone de discrétion délibéré. - Postes où vous recevez moins de 10 candidatures par semaine. Le triage manuel est plus rapide que d’affiner un rubric et une file Slack. Le coût de configuration du flow (60 minutes plus la rédaction du rubric) s’amortit à partir de 30 candidatures par semaine, pas à partir de 5.
- Rôles confidentiels / exécutifs. Posture de consentement différente. Chaîne d’audit différente. Routage différent — ceux-ci vont directement vers un recruteur nommé, pas dans un canal Slack partagé.
Configuration
- Importez le flow. Déposez
apps/web/public/artifacts/inbound-applicant-triage-n8n/inbound-applicant-triage-n8n.jsondans votre instance n8n. Chaque nœud portenotesInFlow: truepour que les notes intégrées expliquent les choix. - Câblez les credentials. Le flow en a besoin de trois :
PLACEHOLDER_ASHBY_CRED_ID(clé API Ashby, portée lecture uniquement),PLACEHOLDER_ANTHROPIC_CRED_ID(clé API Claude),PLACEHOLDER_SLACK_CRED_ID(token bot Slack avecchat:writepour les trois canaux). Chaque section dans_README.mdindique où trouver la valeur. - Rédigez le rubric. Par poste, écrivez un fichier JSON sous
n8n/data/rubrics/<role-slug>.jsonavec les quatre dimensions (compétence, niveau, localisation, probabilité de réponse) et des ancres comportementales par dimension. Le flow recherche le rubric parrole_slugdepuis le payload de candidature Ashby. Pas de rubric pour un poste → le flow s’arrête avec une entrée de logmissing_rubricplutôt que de scorer sur des valeurs par défaut. - Configurez les seuils de routage. Dans le nœud IF
Route by Aggregate:aggregate >= 16route vers#fast-track,12-15vers#review-needed, tout en dessous de 12 vers#surfaced-not-rejected. Ajustez après une semaine de test à blanc. - Test à blanc sur un poste clôturé. Rejouez la dernière semaine de candidatures pour un poste que vous avez sourcé manuellement. Comparez le bucket
#fast-trackdu flow à votre liste réelle de candidats passés en entretien téléphonique. Ajustez les ancres du rubric si elles divergent — ce sont les ancres, pas le modèle, qui sont généralement fautives. - Activez le déclencheur. Passez le webhook Ashby de
disabledàenableduniquement après que le test à blanc semble correct. Le trafic webhook en production est plus difficile à déboguer que l’historique rejoué.
Ce que le flow fait
Huit nœuds, dans l’ordre. Le flow garde les pré-vols de conformité et les filtres déterministes avant l’appel LLM, car laisser le modèle travailler sur un payload contaminé produit un scoring rapide, confiant et inutilisable.
- Ashby Webhook — reçoit les événements
application.created. La signature du webhook est vérifiée à l’étape suivante ; un payload non vérifié est supprimé. - Verify Signature — HMAC-SHA256 contre le secret webhook configuré. Signature non correspondante → log + arrêt. La vérification de signature est non optionnelle car les webhooks Ashby sont accessibles depuis l’internet ouvert.
- Fetch Application + Rubric — extrait le dossier complet du candidat + la candidature depuis
/candidate.info(Ashby est POST uniquement, même pour les lectures — voir le_README.mddu bundle), et charge le fichier rubric du poste. S’arrête surmissing_rubricau lieu de recourir à un défaut. - Fairness Pre-Flight — fait passer le rubric par une checklist de proxies de classes protégées. Scoring par rang de l’école, filtrage basé sur le nom, pénalités de lacune d’emploi, présence de photo, « culture fit » sans ancres → arrêt et remontée vers l’auteur du rubric. Le choix d’échouer avant l’appel LLM est intentionnel : un rubric biaisé chargé dans une API de scoring laisse une entrée de log qui compte déjà comme traitement automatisé sous l’Article 22 du RGPD.
- Deterministic Pre-Filter — vérifie l’autorisation de travail par rapport à l’exigence de localisation du poste, supprime les candidatures depuis la liste des récemment rejetés (période silencieuse de 6 mois), confirme que la candidature dispose des documents requis (CV, lettre de motivation optionnelle). Ces filtres sont auditables et le LLM ne les retranche pas.
- Claude Score — envoie rubric + CV + données du formulaire de candidature à Claude. Retourne un objet JSON avec des scores par dimension de 1-5, une chaîne de preuves verbatim par dimension au-dessus de 1, et un agrégat. Les scores sans chaîne de preuves sont ramenés à 1. L’exigence de preuves est ce qui ancre le modèle dans le texte du CV plutôt que d’inférer depuis le nom ou l’école.
- Route by Aggregate — nœud IF. Trois branches par fourchette de score comme défini à l’étape 4 de configuration.
- Slack Notify + Audit Append — poste dans le canal Slack approprié avec un lien vers la page du candidat Ashby, les extraits de preuves par dimension, et un lien
view-rubric. Ajoute une ligne JSONL àaudit/<YYYY-MM>.jsonlavecapplication_id,role_slug,rubric_sha256, scores par dimension, agrégat, route, modèle. Pas de PII. Le journal d’audit est ce qui rend une enquête NYC LL 144 ou EU AI Act survivable.
Réalité des coûts
Pour 100 candidatures scorées, sur Claude Sonnet 4.5 :
- Tokens API Anthropic — typiquement 8-12k tokens d’entrée par candidature (rubric ~1k + CV + données de formulaire) et 400-700 tokens de sortie (JSON scoré + preuves). Au tarif affiché de Sonnet 4.5, ça atterrit à environ 0,05-0,08 $ par candidature. Une équipe scorant 1 000 candidatures inbound par semaine dépense 50-80 $ par semaine en coût de modèle.
- Coût n8n — n8n auto-hébergé en conteneur est gratuit. Le plan Starter de n8n Cloud couvre ~5k exécutions de workflow par mois à 20 $ ; les équipes à volume moyen (>5k/semaine) ont besoin du Pro ou de l’auto-hébergement.
- Quota API Ashby — appels en lecture uniquement. Le flow fait 1
/candidate.infopar candidature ; bien dans la limite par défaut de 100 requêtes/min d’Ashby. - Temps du recruteur — le gain. Lire manuellement 100 candidatures représente ~8 heures ; parcourir la file Slack
#review-neededavec les preuves et les liens pré-préparés prend ~20-30 minutes. La file fast-track prend 5-10 minutes supplémentaires pour la prise de contact plus soignée. - Temps de configuration — 60 minutes pour le flow lui-même, plus 30-60 minutes par poste pour le rubric. Le rubric est le coût contraignant ; la réutilisation entre familles de postes l’amortit.
Métriques de succès
Suivez trois chiffres par poste par mois, dans l’ATS :
- Taux de passage à l’entretien téléphonique depuis
#fast-track— devrait être ≥75 % sur un rubric calibré. En dessous, le rubric ou le seuil est trop lâche ; resserrez les ancres avant d’augmenter le seuil. - Taux de passage à l’entretien téléphonique depuis
#review-needed— devrait être de 25-40 %. S’il tombe sous 20 %, le buffer de zone de discrétion est trop large et vous lisez trop. S’il dépasse 50 %, le seuil fast-track est trop haut et des candidats qualifiés sont manqués. - Délai de la candidature au premier contact du recruteur — devrait tomber de jours à moins de 4 heures. C’est la métrique d’expérience candidat, et c’est ce qui rend le flow défendable auprès du responsable TA.
Alternatives
- vs scoring natif d’Ashby (ou Greenhouse Predictive Hire) — le scoring natif de l’ATS convient pour la question binaire « probabilité de correspondance », mais le score est une boîte noire et le rubric n’est pas le vôtre. Choisissez le flow si vous avez besoin d’un score par dimension avec des preuves verbatim (défendable sous NYC LL 144), d’un rubric que vous versionnez, ou d’un modèle que vous pouvez remplacer. Choisissez le natif ATS si votre équipe ne maintiendra pas le rubric.
- vs Eightfold / Findem inbound matching — ce sont des produits plus profonds : ils re-scorent par rapport à vos embauches historiques, gèrent l’outbound, possèdent un graphe de candidats. Choisissez-les si le budget supporte la plateforme et que vous voulez un produit géré. Choisissez le flow si vous voulez le rubric et le journal d’audit dans votre repo et que le reste de votre stack est déjà câblé.
- vs script Python DIY qui poll l’API Ashby — même qualité de scoring si vous construisez le prompt avec soin, mais vous construisez aussi la vérification de signature webhook, le pré-vol de conformité, le chargeur de rubric, le journal d’audit, le routage Slack et l’UX de débogage n8n vous-même. Le bundle les livre.
- vs statu quo (le recruteur lit tout) — le manuel est correct à moins de 10 candidatures/semaine par poste, où un rubric est une surcharge et la tête du recruteur est déjà calibrée. Le flow amortit son coût de configuration sur les postes qui évoluent.
Points de vigilance
- Amplification de biais. Protection : le pré-vol de conformité à l’étape 4 arrête le flow si le rubric contient des proxies de classes protégées. Le journal d’audit capture
rubric_sha256par candidature scorée, de sorte que le rubric utilisé à une date donnée est reproductible sous revue EU AI Act ou NYC Local Law 144. - Replay webhook / double scoring. Protection : la signature webhook Ashby inclut
application.created.id. Le journal d’audit du flow est clé surapplication_id; une seconde arrivée est détectée et sautée sans re-scoring. - Dérive de sortie du modèle lors des modifications du rubric. Protection :
rubric_sha256dans le journal d’audit rend visibles les changements de rubric entre deux exécutions. Si un score agrégat pour une candidature re-scorée diverge, la différence est dans le hash du rubric, pas dans le non-déterminisme du modèle. - Dérive du routage automatique vers le rejet. Protection : le flow n’a pas de branche
reject. Le troisième bucket est#surfaced-not-rejected, et le message Slack inclut un bouton « promouvoir vers la revue » qui reroutage la candidature vers#review-needed. Le recruteur est la seule autorité de rejet. - PII du CV dans le message Slack. Protection : le message Slack inclut uniquement le prénom du candidat, son titre actuel et les extraits de preuves par dimension (max 200 caractères chacun). Le contenu complet du CV reste dans l’ATS. Les canaux Slack ont une rétention plus courte qu’Ashby ; le flow ne transforme pas Slack en base de données de candidats.
- Risque de candidats UE non testés. Protection : le nœud
Verify Signaturedu flow vérifie aussi la localisation déclarée de la candidature. Les candidatures avec des codes de localisation UE routent vers#review-neededquel que soit le score, et le message Slack signaleCandidat UE — confirmez que l'avis de dépistage IA a été servi. Le dépistage IA de résidents UE sans avis est une violation de système à haut risque de l’EU AI Act.
Stack
Le bundle d’artifact se trouve dans apps/web/public/artifacts/inbound-applicant-triage-n8n/ et contient :
inbound-applicant-triage-n8n.json— l’export du flow n8n (chaque nœud configuré, aucun paramètre stub)_README.md— configuration des credentials, format du rubric, checklist de conformité, procédure de test à blanc
Outils utilisés par le workflow : Ashby (l’ATS — remplacez par Greenhouse ou Lever en remplaçant le nœud d’intake), Claude (le modèle de scoring), n8n (l’orchestration), Slack (la surface de file du recruteur). Pour le flow de sourcing parallèle, voir le Claude Skill de sourcing de candidats ; pour la construction de loop d’entretien par poste, voir le constructeur de loop d’entretien.
Concepts liés : biais du dépistage IA, expérience candidat, métriques du funnel de recrutement, entretiens structurés.