Anatomie d'un ATS : les objets, les états et les événements

Tous les ATS du marché partagent le même modèle de données à quelques variantes près. Le connaître permet de lire une documentation d'API en dix minutes, d'anticiper ce qui va mal se passer dans une intégration, et de repérer en démonstration qu'un outil modélise mal votre métier.

Les cinq objets

Candidat — une personne. Identité, contacts, éventuellement un CV de référence. C'est l'objet le plus stable dans le temps et celui sur lequel portent les obligations RGPD.

Offre (ou Job, Requisition) — un poste à pourvoir. Intitulé, description, lieu, statut, service demandeur. Une offre est ouverte puis close.

Candidature (ou Application) — le lien entre un candidat et une offre. C'est l'objet central, et celui que tout le monde confond avec le candidat. Une même personne qui postule à trois offres produit un candidat et trois candidatures.

Étape (ou Stage, Status) — l'état d'une candidature dans le pipeline. Nouveau, présélection, entretien, proposition, recruté, refusé.

Évaluation (ou Scorecard, Feedback) — l'avis d'une personne sur une candidature à une étape donnée. Rattaché à la candidature, à l'auteur et à l'étape.

Ce qui gravite autour

• Pièce jointe — CV, lettre, portfolio. Rattachée au candidat ou à la candidature selon les outils, ce qui a des conséquences directes sur l'export et sur la suppression RGPD.
• Message — un échange, entrant ou sortant, rattaché à la candidature.
• Utilisateur — un recruteur, un manager, un administrateur. Avec un rôle qui détermine ce qu'il voit.
• Source — d'où vient la candidature. Champ souvent mal alimenté, ce qui rend ensuite impossible de savoir quel canal produit les recrutements, voir le tableau de bord.
• Vivier (ou Talent pool, Tag) — un regroupement de candidats hors de toute offre. Juridiquement, c'est un traitement distinct avec sa propre base légale.

Le pipeline : des états et des transitions

Un pipeline est une machine à états. Chaque candidature occupe exactement un état, et passe de l'un à l'autre par une transition.

Trois propriétés à vérifier dans n'importe quel outil :

Les états sont-ils configurables ? Ajouter une étape, la renommer, changer l'ordre. Si cela exige un ticket au support, chaque évolution de votre processus coûtera de l'argent et du délai.

Les états sont-ils par offre ou globaux ? Un pipeline commercial et un pipeline technique n'ont pas les mêmes étapes. Un outil à pipeline unique vous force au plus petit dénominateur commun.

Les transitions déclenchent-elles des effets ? Passer en « refusé » doit pouvoir envoyer un mail ; passer en « entretien » doit pouvoir créer un événement d'agenda. Sans effets sur transition, il n'y a rien à automatiser.

Deux états terminaux existent toujours : recruté et refusé. Un troisième mérite d'exister et manque souvent : retiré par le candidat. Le confondre avec un refus fausse durablement vos statistiques de conversion.

Les événements

Les ATS modernes émettent des événements consommables par des systèmes tiers. La liste typique :

• application.created — une candidature arrive
• application.stage_changed — elle change d'étape
• application.hired / application.rejected — issue
• candidate.updated — une fiche est modifiée
• job.published / job.closed — cycle de vie d'une offre
• interview.scheduled — un entretien est posé

application.stage_changed et application.hired couvrent à eux seuls la majorité des besoins d'intégration. Si l'API n'expose que le premier, on peut déduire le second de l'état d'arrivée.

Quand aucun événement n'est émis, il faut interroger l'API périodiquement, avec les conséquences décrites dans la note sur les webhooks et l'interrogation périodique.

Les variantes qui compliquent les intégrations

Le candidat dupliqué par construction. Certains outils créent un nouveau candidat à chaque candidature et ne rapprochent qu'après coup, ou jamais. Cela change entièrement la stratégie de déduplication.

Les champs personnalisés. Tous les ATS en proposent. Certains les exposent dans l'API avec leur identifiant technique, d'autres avec leur libellé — ce qui signifie qu'un renommage en interface casse l'intégration. Demandez lequel des deux avant de développer.

Le multi-entités. Une entreprise à plusieurs filiales a besoin de cloisonner offres et candidats. Beaucoup d'ATS de milieu de gamme le gèrent mal, ou seulement par les droits d'accès, ce qui n'est pas la même chose.

Les dates. Date de candidature, date de dernière modification, date de changement d'état. La deuxième est presque toujours disponible et presque toujours inutile pour la synchronisation, parce qu'elle bouge pour des raisons non métier. Synchronisez sur la date de changement d'état quand elle existe.

Lire une documentation d'API en dix minutes

Dans l'ordre :

1. Cherchez l'objet Application. S'il n'existe pas et qu'il n'y a que Candidate, le modèle est pauvre, et tout ce qui suit sera compliqué.
2. Regardez si les états du pipeline sont exposés et modifiables par l'API, ou seulement lisibles.
3. Cherchez la section webhooks. Absente, prévoyez de l'interrogation périodique.
4. Cherchez les limites de débit. Elles déterminent si une synchronisation complète est réaliste.
5. Cherchez comment sont exposées les pièces jointes : URL signée temporaire, contenu encodé, ou rien. C'est le point qui bloque le plus souvent les reprises de données.

Questions fréquentes

Quelle différence entre un candidat et une candidature ?

Le candidat est la personne ; la candidature est le lien entre cette personne et une offre précise. Le statut, l'étape et les évaluations appartiennent à la candidature. Confondre les deux est l'erreur d'intégration la plus fréquente et elle se manifeste dès qu'un profil postule deux fois.

Peut-on modifier le modèle de données d'un ATS du marché ?

Uniquement par les champs personnalisés. Les objets et leurs relations sont figés. C'est la raison pour laquelle un processus atypique — évaluation croisée, validation à plusieurs niveaux, cooptation avec règle de rémunération — finit soit tordu dans un modèle qui ne le prévoit pas, soit géré hors de l'outil.

Comment savoir si un ATS gérera notre processus avant d'acheter ?

Dessinez votre pipeline avec ses états et ses transitions sur une page, puis demandez en démonstration de le reproduire en direct dans l'outil. S'il faut un ticket, une prestation ou un contournement, vous avez la réponse en quinze minutes plutôt qu'en six mois.

Faut-il un identifiant unique de candidat côté entreprise ?

Oui, dès que plusieurs systèmes se parlent. L'identifiant interne de l'ATS disparaît le jour où vous changez d'outil. Conserver son propre identifiant stable, porté dans un champ personnalisé, rend la migration et les intégrations nettement plus simples — c'est cinq minutes de configuration au départ et des semaines gagnées plus tard.