Note éditoriale
Lecteur unique : vous êtes product owner du recrutement ou architecte intégration et on vous demande que les scores d’entretien asynchrone et les décisions de tri de CV « vivent » dans l’ATS sans double saisie ni statuts incohérents.
Scénario de pression : l’outil amont est prêt, mais le statut candidat dans l’ATS ne bouge pas ; les managers complètent des tableurs parallèles — la traçabilité et le reporting cassent.
Problème central : l’API seule ne suffit pas sans machine à états partagée, mapping des champs avec source d’autorité, et gouvernance des rôles (qui lit quoi, quand).
Critères d’acceptation :
- Diagramme d’états publié avec transitions valides, propriétaires et SLA par transition critique.
Document de mapping approuvé : pour chaque donnée issue du tri de CV ou de l’entretien asynchrone, système faisant foi et règle de résolution de conflit.
Signe d’échec : après trois mois de production, la ressaisie manuelle ou les exports non contrôlés vers des postes non maîtrisés restent la norme pour les managers — l’intégration n’a pas modifié le comportement réel.
Trois erreurs typiques : connecter l’API avant de figer les états ; même libellé de champ, sens différent entre SIRH et outil de screening ; droits d’export trop larges.
Tableau de décision
| Contexte | Prérequis | Risques majeurs | Quand éviter |
|---|---|---|---|
ATS ou SIRH en place, volume croissant, besoin d’une source de vérité pour candidats, scores et étapes de recrutement. | Sponsor RH + IT ; inventaire des systèmes ; capacité API / batch connue ; politiques internes d’accès et de conservation à appliquer. | Statuts incohérents, doublons, fuite de données via exports, latence qui décourage l’usage de l’ATS. | Tout petit pilote sans volonté d’écriture dans le référentiel — dans ce cas, assumez un mode manuel temporaire plutôt qu’une fausse intégration « prod ». |
Établir la machine à états avant toute intégration technique
Action concrète : modéliser de la candidature au refus ou à l’embauche : tri de CV, entretien asynchrone, entretiens managers, offre, clôture — avec transitions autorisées, interdites et propriétaires.
Rôle responsable : RH processus + métier pour les règles ; IT pour la faisabilité technique.
Livrable : diagramme d’états validé + catalogue des transitions avec SLA interne.
Les patterns « API sans machine à états » mènent à des statuts bloqués ou incohérents dès que plusieurs équipes écrivent en parallèle.
Rédiger le mapping des champs et la source d’autorité
Action concrète : pour scores détaillés, liens médias, identifiants des évaluateurs, synthèses manager : indiquer le système faisant foi, le format, la fréquence de synchronisation et la résolution de conflit — document signé par les parties prenantes.
Rôle responsable : product owner recrutement avec validation IT et fournisseurs si besoin.
Livrable : tableau de mapping versionné + règles d’idempotence pour les synchronisations.
Configurer rôles, journaux d’accès et limitation des exports
Action concrète : moindre privilège pour les profils ; journalisation des accès sensibles ; retrait des droits lors des mutations ; limiter les exports complets vers des environnements non maîtrisés conformément à vos politiques internes.
Rôle responsable : sécurité / IT + RH pour la matrice des rôles métier.
Livrable : matrice RBAC approuvée + procédure de revue des accès après changement de poste.
Clauses contractuelles et accords de sous-traitance : hors périmètre de cet article ; suivez votre programme conformité interne.
Pilote, mesurer, industrialiser
Action concrète : pilote sur un type de poste avec écriture ATS obligatoire ; mesurer champs manquants, latence d’écriture, états bloqués, ressaisies ; élargir par vagues.
Rôle responsable : product owner avec équipe run IT.
Livrable : rapport de go-live + seuils d’alerte + plan de remédiation.
Aligner conservation, médias et contexte multi-sites
Action concrète : classer médias (vidéos, transcriptions) ; définir durées et restrictions de téléchargement selon vos règles ; ne pas isoler l’intégration des chantiers multi-sites ou traçabilité.
Rôle responsable : conformité / juridique interne + RH + IT — décisions selon politiques internes uniquement.
Livrable : runbooks suppression / archivage exécutables et testés.
Liste de contrôle
- Machine à états publiée avec propriétaires ?
- Document de mapping approuvé ?
- Indicateurs de succès et latence d’écriture ?
- Revues d’accès après changements de poste ?
- Runbooks suppression/archivage exécutables ?
Liens produits
Questions fréquentes
Questions fréquentes des dirigeants et des équipes RH :
Un ATS est-il indispensable ?
Non, mais sans référentiel unique, volume et multi-sites augmentent ressaisies et risques de traçabilité.
Pourquoi les intégrations échouent-elles ?
Sémantique floue des champs et transitions d’état non définies — commencez par la machine à états avant l’API.
Qui pilote ?
RH (processus), IT/sécurité (interfaces, droits), métier (définition des états), avec un product owner unique.
Vidéos et transcriptions ?
Classification, durées, restrictions de téléchargement ; sous-traitants et transferts selon vos règles internes.
Que mesurer après le go-live ?
Champs manquants, latence d’écriture, états bloqués et ressaisies manuelles — tendance vers zéro.