Que faut-il exporter de son ATS pour construire un dashboard recrutement ?

Une équipe recrutement souhaite construire un dashboard. Elle demande un export de l’ATS et reçoit un fichier de plusieurs dizaines de colonnes, avec des noms, des emails, des numéros de téléphone, des réponses à des questionnaires, des dates, des sources, des statuts et des champs internes. Le fichier paraît complet.

Pourtant, au moment de calculer le nombre de candidatures par offre ou le délai de traitement, certaines données essentielles manquent : l’identifiant de l’offre, la date de candidature, le statut de l’offre, la date de publication, la localisation, ou l’historique des changements d’étape. Le problème n’est donc pas le volume de données disponibles, mais leur utilité pour répondre aux questions de pilotage. Avant de demander quoi que ce soit, une question mérite d’être posée : quelles données faut-il réellement exporter de l’ATS pour construire un dashboard recrutement ?

Commencer par les décisions, pas par les colonnes

Avant de demander un export, il faut définir ce que le dashboard doit permettre de décider. Les questions de pilotage sont concrètes : quelles sources génèrent des candidatures qualifiées, quelles offres actives reçoivent trop peu de candidatures, quels métiers décrochent, quelles régions rencontrent le plus de difficultés, combien de candidats progressent dans le pipeline, où les candidatures restent bloquées, quels jobboards renforcer, quels investissements réorienter, combien de temps il faut pour traiter une candidature et pour recruter.

Ce cadrage change tout, car une colonne n’a de valeur que si elle alimente un indicateur, un filtre, une règle d’alerte, une segmentation ou une décision. Une donnée qui ne sert aucune de ces cinq fonctions n’a pas sa place dans l’export, quelle que soit sa disponibilité. Partir des décisions évite à la fois l’export pauvre, qui empêche de relier les objets, et l’export pléthorique, qui alourdit le traitement et multiplie les risques.

Distinguer candidat, candidature et offre

Trois objets structurent tout reporting recrutement. Le candidat est une personne enregistrée dans l’ATS ; il peut postuler à plusieurs offres, être déplacé dans plusieurs processus, être contacté sans avoir postulé ou revenir plusieurs mois plus tard. La candidature est la relation entre un candidat et une offre ou un processus ; elle possède généralement une date, une source, une étape, un statut et une offre associée. L’offre est le besoin de recrutement ou la publication à laquelle les candidatures sont rattachées.

Un simple export « candidats » se révèle vite insuffisant. Si un même candidat postule à trois offres, compter uniquement les candidats uniques ne permet pas de mesurer correctement le volume de candidatures, la performance de chaque offre, les sources par offre ou la progression par processus. Pour un dashboard opérationnel, l’unité d’analyse est le plus souvent la candidature, ou l’application, et pas uniquement la personne.

Les identifiants indispensables

Relier ces objets suppose des identifiants stables. L’identifiant candidat permet de reconnaître une même personne sans recourir à son nom ou à son email. L’identifiant candidature ou application distingue plusieurs candidatures d’un même candidat. L’identifiant offre relie les candidatures aux données de l’offre. Lorsqu’une demande de recrutement existe en amont, un identifiant de demande de recrutement peut relier la demande, l’ATS, le SIRH et le reporting. Un identifiant emploi ou poste de référence est utile quand l’organisation souhaite rapprocher le recrutement d’un référentiel RH.

Tous ces identifiants ne sont pas toujours disponibles. Le socle minimal doit au moins permettre de relier la candidature, l’offre, et le candidat lorsque cela est nécessaire. En revanche, reconstruire un identifiant à partir du nom et de l’email est à éviter : c’est fragile, sensible sur le plan des données personnelles, et source de doublons dès qu’une orthographe change.

Les données minimales à exporter côté candidatures

Côté candidatures, un socle raisonnable combine des identifiants, des dates, des données de pipeline, de source et de périmètre. Les identifiants relient les objets. Les dates permettent de mesurer les délais. Le pipeline situe la candidature dans le processus. La source alimente l’analyse d’acquisition. Le périmètre autorise la segmentation par métier, région et contrat. Le tableau ci-dessous résume ce socle et son niveau de priorité.

Donnée	Utilité	Priorité
Identifiant candidature	Compter et relier chaque candidature	Indispensable
Identifiant candidat	Dédupliquer et reconnaître une personne	Indispensable
Identifiant offre	Relier la candidature à l’offre	Indispensable
Date de création de la candidature	Point de départ des délais	Indispensable
Étape et statut actuels	Lecture du pipeline	Indispensable
Source brute et source normalisée	Analyse d’acquisition	Indispensable
Département	Segmentation métier	Indispensable
Localisation et région	Segmentation géographique	Utile
Type de contrat	Segmentation par contrat	Utile
Date de rejet, de recrutement, d’entretien	Délais et funnel	Utile
Campagne et paramètres de tracking	Analyse fine des sources	Utile
Poste	Détail métier quand renseigné	Avancé
Mode d’entrée (candidature, import, sourcing, cooptation)	Distinguer les origines	Avancé
Motif de rejet structuré	Qualité des candidatures	Avancé
Recruteur responsable	Pilotage opérationnel	Avancé

Le recruteur responsable mérite une précaution : cette donnée sert le pilotage opérationnel, pas la construction d’un classement individuel simpliste, qui serait à la fois injuste et trompeur compte tenu des écarts de métiers et de volumes.

Les données minimales à exporter côté offres

L’export offres est tout aussi structurant, et souvent oublié. Il rassemble d’abord les identifiants : identifiant offre, identifiant de demande de recrutement et identifiant emploi ou poste de référence lorsqu’ils existent. Il décrit ensuite l’offre elle-même, avec son titre, son département, son poste lorsqu’il est renseigné, sa division ou entité, sa localisation, sa région, son type de contrat, son statut, le recruteur ou l’équipe responsable, et ses dates de création, de publication, de clôture et de dernière mise à jour.

Quelques informations complètent utilement le pilotage : le nombre de postes à pourvoir lorsque la donnée est fiable, la campagne ou le dispositif associé, le jobboard ou la diffusion activée lorsque l’information existe, le statut actif, historique, archivé ou clôturé, la date de désactivation, le motif de clôture lorsqu’il est structuré et l’ancienneté de l’offre. Sans cet export, il devient impossible d’identifier proprement les offres actives, les offres anciennes, les offres sans candidatures, les offres clôturées, les offres ayant reçu peu de candidatures et les écarts entre métiers, régions et contrats.

Pourquoi le statut de l’offre est indispensable

Un dashboard ne doit jamais mélanger sans distinction offres actives, clôturées, archivées, brouillons, historiques ou annulées. Une offre fermée depuis plusieurs mois ne doit pas être lue comme une offre actuellement en difficulté, sous peine de déclencher de fausses alertes. La logique est simple à poser. Les offres actives servent aux alertes, au pilotage immédiat, au suivi des candidatures et aux décisions de sourcing. Les offres historiques servent aux bilans, aux comparaisons, à l’analyse des délais, à la performance des sources et à l’apprentissage.

Les libellés de statut varient d’un ATS à l’autre, ce qui impose de créer une règle de regroupement stable pour distinguer clairement ces deux mondes. Sans cette règle, les moyennes de délai et les taux se retrouvent faussés par des offres qui n’auraient pas dû entrer dans le calcul.

Département, Poste et Division : quelles données conserver ?

Dans certaines organisations, la hiérarchie de l’ATS est structurée sous la forme Division, puis Département, puis Poste. La Division peut représenter une entité, une société, une marque, un réseau ou une grande direction. Le Département peut représenter une famille de métiers, un périmètre fonctionnel ou une direction métier. Le Poste apporte un niveau de détail supplémentaire, mais son champ peut être complètement renseigné, partiellement renseigné, vide sur certains départements ou inutilisé dans certaines entités.

La règle qui en découle est claire : le dashboard ne doit pas rendre le Poste obligatoire. Il fonctionne avec le Département seul et n’active le filtre Poste que lorsque la donnée est suffisamment renseignée. Cette organisation n’est pas universelle, elle sert d’exemple pragmatique. L’idée générale vaut au-delà de Teamtailor : le reporting doit s’adapter à la qualité réelle du référentiel plutôt que de refuser les données lorsque le niveau le plus fin est incomplet.

Les dates indispensables pour mesurer les délais

Les délais se calculent à partir de dates précises. La date de candidature est le point de départ minimal. La date de première consultation, lorsqu’elle est disponible, mesure la réactivité. La date de qualification éclaire le délai de traitement initial. La date d’entretien mesure le temps jusqu’au premier entretien. La date de recrutement permet de calculer le délai entre candidature et embauche. Les dates de publication et de clôture de l’offre complètent l’analyse en donnant l’ancienneté, la durée de diffusion et la vitesse d’acquisition.

Ces dates sont le socle d’une lecture du time-to-hire déclinée par étape plutôt qu’en moyenne globale. Il faut toutefois garder à l’esprit que tous les ATS ne fournissent pas l’ensemble de ces dates dans un export standard, et qu’il vaut mieux le vérifier avant de promettre un indicateur qui reposerait sur une date absente.

Une étape actuelle ne permet pas toujours de reconstruire le pipeline

Un export peut indiquer qu’une candidature se trouve aujourd’hui à l’étape « Entretien », sans permettre de savoir quand elle y est entrée, combien de temps elle est restée en boîte de réception, si elle a été déplacée puis replacée, quelles étapes intermédiaires elle a traversées ni combien de jours ont été nécessaires pour chaque transition. Il faut distinguer deux choses. La photographie actuelle indique l’étape ou le statut au moment de l’export. L’historique des événements enregistre les changements d’étape et leurs dates.

Pour analyser le funnel actuel, le nombre de candidats par étape, les recrutements et les rejets, la photographie actuelle peut suffire à une première version. Pour analyser le temps passé dans chaque étape, les blocages historiques, les mouvements du pipeline et les délais précis, un historique d’événements ou des snapshots réguliers deviennent nécessaires. Un export standard ne permet pas toujours de reconstituer cet historique, et il est plus honnête de le dire que de calculer des durées à partir de données absentes.

Les données nécessaires pour analyser les sources

L’analyse des sources mobilise un ensemble de champs cohérent : source brute, source normalisée, famille de source, dispositif, campagne, distinction du direct et de l’inconnu, paramètres UTM lorsqu’ils sont disponibles, date de candidature, offre, département, poste, région, étape, statut et recrutement. Cette combinaison permet de relier chaque source à sa contribution réelle dans le pipeline plutôt qu’à un simple volume d’entrée.

Ces valeurs peuvent être normalisées après export, dans une table de correspondance, sans jamais modifier la donnée brute. La méthode pour construire et maintenir ce référentiel est détaillée dans notre article sur le nettoyage des sources de candidatures dans un ATS. L’export doit donc systématiquement conserver la source brute, même lorsqu’une source normalisée est ajoutée par la suite.

Les données nécessaires pour analyser les offres en difficulté

Repérer une offre qui décroche suppose de croiser plusieurs champs : statut actif, date de publication, nombre de candidatures, nombre de candidats qualifiés, département, poste, localisation, région, type de contrat, source ou diffusion, recruteur responsable et date de dernière candidature. Une règle d’alerte simple pourrait viser les offres actives depuis moins de trente jours ayant reçu moins de trois candidatures.

Ce seuil n’est qu’un exemple, à adapter au contexte. Une offre technique très pénurique, une offre saisonnière ou une offre en alternance ne s’analyse pas avec le même repère qu’un poste à fort volume. Le rôle de l’export est de fournir les colonnes qui rendent l’alerte possible ; le calibrage du seuil reste une décision métier.

Faut-il exporter les noms, emails et CV des candidats ?

Pour la majorité des dashboards de pilotage, ces éléments ne sont pas nécessaires : nom, prénom, email, téléphone, adresse, photo, CV, lettre de motivation, réponses détaillées à des questionnaires, commentaires recruteurs et données sensibles. Un identifiant candidat ou candidature suffit généralement à compter, dédupliquer, relier, suivre les étapes et analyser les sources.

S’en tenir à ce socle apporte des bénéfices concrets : minimisation des données, réduction du risque, fichiers plus légers, accès plus simple à gouverner et analyses moins intrusives. Il ne s’agit pas ici d’un conseil juridique personnalisé, mais d’un principe de minimisation et de bonne gouvernance des données. Un dashboard de pilotage n’a pas besoin de connaître l’identité des candidats pour mesurer des volumes, des délais et des taux.

Comment gérer les motifs de rejet

Les motifs de rejet peuvent éclairer la qualité des candidatures, les critères bloquants, les écarts entre sources, les besoins de reformulation des offres et les problèmes de ciblage. Ils sont pourtant souvent difficiles à exploiter, notamment lorsque les recruteurs utilisent des commentaires libres, que les catégories se recouvrent, que les motifs sont trop nombreux, que les équipes ne les emploient pas de façon homogène ou que le motif reflète une appréciation individuelle imprécise.

Pour en tirer quelque chose, mieux vaut une liste courte, des catégories compréhensibles, une utilisation homogène, une gouvernance claire et une lecture agrégée plutôt que ligne à ligne. Les commentaires libres, en revanche, n’ont pas leur place dans un dashboard standard : ils sont peu structurés, parfois sensibles, et ajoutent du bruit sans améliorer la décision.

CSV ou API : par quoi commencer ?

L’export CSV convient à une première version, un pilote, un besoin ponctuel, des contrôles manuels, une fréquence hebdomadaire ou mensuelle et la validation du modèle de données. Il est rapide, lisible, peu coûteux, facile à tester et précieux pour repérer les champs manquants. Ses limites tiennent à la manipulation manuelle, au risque de fichier incomplet, aux variations de format, à une fréquence limitée et à la difficulté de conserver l’historique.

La connexion API devient pertinente quand le dashboard est utilisé régulièrement, que plusieurs équipes en dépendent, que les volumes augmentent, que les exports manuels deviennent fragiles, qu’une synchronisation régulière s’impose ou que les données doivent être historisées. Elle apporte automatisation, fréquence, stabilité et accès à des données plus détaillées selon les endpoints disponibles, au prix d’un coût de développement, d’une maintenance, d’une authentification, d’une documentation, d’une exposition aux changements d’API et d’un besoin de supervision. Le CSV est souvent une bonne manière de valider le besoin et le modèle avant d’automatiser. Quant au temps réel, il n’est pas un objectif par défaut : une synchronisation régulière, par exemple hebdomadaire, suffit largement au pilotage dans la plupart des cas.

Pourquoi conserver des snapshots réguliers

Lorsque l’ATS ne fournit pas tout l’historique, des exports réguliers permettent de conserver l’évolution des étapes, le statut des offres, le nombre de candidatures, les changements de source ou de classement, les mouvements dans le pipeline et la photographie d’une période. Un snapshot est simplement une copie datée des données prise à intervalles réguliers.

Un stockage tampon complété chaque semaine peut suffire à suivre les évolutions, comparer les périodes, limiter les appels API, conserver un historique et éviter une architecture temps réel disproportionnée. Il n’est pas nécessaire de bâtir une infrastructure lourde pour disposer d’une profondeur historique utile : la régularité compte plus que la sophistication.

Les contrôles qualité à réaliser sur un export ATS

Avant d’exploiter un export, quelques contrôles évitent de mauvaises surprises :

• identifiants candidatures uniques ;
• identifiants offres renseignés ;
• aucune candidature sans offre lorsqu’elle devrait en avoir une ;
• dates au bon format ;
• statuts cohérents ;
• offres actives identifiables ;
• sources brutes conservées ;
• champs Département et Poste analysés séparément ;
• localisations harmonisées ;
• types de contrat normalisés ;
• totaux identiques avant et après préparation ;
• doublons identifiés ;
• valeurs vides mesurées ;
• cohérence entre statut recruté et date de recrutement ;
• absence de données personnelles inutiles ;
• stabilité des noms de colonnes entre deux exports.

Un contrôle mérite une attention particulière : comparer les colonnes et les formats entre plusieurs exports successifs, afin de détecter une modification du modèle de l’ATS. Un renommage de colonne ou un changement de format silencieux peut casser un dashboard sans prévenir.

Exemple de structure de fichiers

En pratique, trois tables suffisent à couvrir la plupart des besoins d’un premier dashboard : une table Candidatures, une table Offres et une table Référentiel des sources. Les noms de colonnes peuvent être en français ou en anglais ; ce qui compte est leur stabilité dans le temps.

Table Candidatures	Table Offres	Table Référentiel sources
application_id	job_id	source_raw
candidate_id	recruitment_request_id	source_normalized
job_id	job_title	source_family
application_created_at	entity	source_detail_or_campaign
current_stage	department	attribution_quality
application_status	position	mapping_rule
source_raw	location	mapping_version
source_normalized	region
department	contract_type
position	job_status
location	created_at
region	published_at
contract_type	closed_at
hired_at	recruiter
rejected_at	number_of_positions

La table Candidatures et la table Offres se relient par job_id. Le référentiel des sources se relie à la table Candidatures par source_raw. Ce modèle reste volontairement simple : il peut s’enrichir ensuite, mais il permet déjà de produire l’essentiel des analyses attendues.

Ce qu’un premier dashboard peut déjà produire

Avec ce socle, un premier dashboard produit déjà beaucoup : volume de candidatures, candidatures par source, par département, par poste lorsque disponible et par région, taux de qualification, entretiens, recrutements, lecture du pipeline, offres actives, offres avec peu de candidatures, évolution mensuelle, sources inconnues, comparaisons de jobboards, délais simples et exports filtrés.

Ces analyses recoupent directement la mesure de la performance des sources de recrutement et la comparaison de plusieurs jobboards, qui reposent toutes deux sur ce même socle de données bien reliées. Autrement dit, un modèle simple mais complet ouvre l’accès à la majorité des décisions de pilotage, sans attendre une architecture avancée.

Le rôle du dashboard dans l’architecture

Un dashboard de pilotage du recrutement ne doit pas devenir une seconde base RH normative. Il sert à lire, comparer, filtrer, détecter, alerter, exporter et piloter, pas à reproduire l’ensemble des systèmes existants. Chaque brique garde son rôle : l’ATS reste la source opérationnelle du recrutement, la demande de recrutement porte le besoin initial lorsqu’elle existe, et le SIRH porte les données RH finales.

On peut résumer cette répartition simplement. La demande de recrutement est la source riche et évolutive du besoin. L’ATS est la couche stable du processus de recrutement. Le dashboard est la couche de lecture et de pilotage. Le SIRH est le référentiel final des données RH. Les identifiants permettent de rapprocher ces systèmes sans chercher à tout reproduire dans l’ATS, ce qui garde chaque outil dans son périmètre et évite les doublons de données.

Les erreurs fréquentes

Plusieurs réflexes compromettent un export utile :

• demander toutes les colonnes disponibles ;
• oublier l’identifiant candidature ;
• utiliser uniquement l’identifiant candidat ;
• ne pas exporter les offres ;
• ne pas conserver le statut des offres ;
• confondre étape actuelle et historique ;
• reconstruire les délais avec des dates absentes ;
• rendre le champ Poste obligatoire ;
• exporter des données personnelles inutiles ;
• utiliser les noms ou emails comme identifiants ;
• ignorer les candidatures multiples ;
• mélanger offres actives et historiques ;
• ne pas harmoniser les types de contrat ;
• ne pas contrôler les formats entre deux exports ;
• commencer par une API avant d’avoir validé le modèle ;
• chercher du temps réel sans besoin opérationnel ;
• ne pas documenter les colonnes ;
• modifier les règles sans conserver l’historique.

Une méthode simple pour commencer

Une démarche en dix étapes permet de partir sur des bases saines.

1. Lister les décisions attendues.
2. Définir les KPI et filtres nécessaires.
3. Distinguer candidat, candidature et offre.
4. Identifier les clés de liaison.
5. Créer un export candidatures.
6. Créer un export offres.
7. Ajouter un référentiel de sources.
8. Retirer les données personnelles inutiles.
9. Tester les calculs sur une période courte.
10. Stabiliser le modèle avant d’automatiser.

Trois questions de validation aident à vérifier que le modèle tient debout. Chaque indicateur peut-il être relié à une colonne identifiable ? Chaque candidature peut-elle être reliée à une offre ? Les données exportées sont-elles nécessaires à une décision réelle ? Si l’une de ces réponses est non, il faut corriger le modèle avant de construire le dashboard, pas après.

Conclusion

Construire un dashboard recrutement ne commence pas par un outil de visualisation. Le premier travail consiste à définir ce que l’on veut piloter, quelles données permettent de le mesurer, comment les relier, quelles limites doivent être documentées et quelles informations ne doivent pas être exportées. Un modèle simple, stable et compréhensible est plus utile qu’un export exhaustif impossible à maintenir. C’est cette structuration fonctionnelle des données que mène Inside Linkers avec les équipes RH et recrutement, en amont des dashboards, pour que le pilotage repose sur des données fiables plutôt que sur un fichier surchargé.

Questions fréquentes sur l’export des données ATS

Quelles données faut-il exporter d’un ATS pour suivre les recrutements ?

Un socle utile combine des identifiants stables (candidature, candidat, offre), des dates (candidature, entretien, recrutement), l’étape et le statut, la source brute et normalisée, et des données de périmètre comme le département, la région et le type de contrat. Il faut aussi un export des offres avec leur statut et leurs dates. Ce socle suffit à la plupart des indicateurs, sans exporter de données personnelles.

Quelle différence entre un candidat et une candidature dans un ATS ?

Le candidat est une personne enregistrée dans l’ATS, la candidature est la relation entre ce candidat et une offre. Un même candidat peut avoir plusieurs candidatures. Pour un dashboard, l’unité d’analyse est le plus souvent la candidature, car compter uniquement les candidats uniques masque le volume réel, la performance par offre et les sources par offre.

Faut-il exporter les données personnelles des candidats ?

Dans la plupart des cas, non. Un identifiant candidat ou candidature suffit à compter, dédupliquer, relier et suivre les étapes. Les noms, emails, téléphones, CV et réponses détaillées ne sont généralement pas nécessaires au pilotage. S’en tenir à un socle minimal réduit le risque, allège les fichiers et facilite la gouvernance des accès, dans une logique de minimisation des données.

Un fichier CSV suffit-il pour construire un dashboard recrutement ?

Oui, souvent pour commencer. Un export CSV hebdomadaire ou mensuel permet de valider le modèle de données, de repérer les champs manquants et de produire une première version du dashboard. Une connexion API devient pertinente quand l’usage se régularise, que les volumes augmentent ou que les données doivent être historisées, mais le temps réel n’est presque jamais nécessaire au pilotage.

Pourquoi faut-il exporter séparément les candidatures et les offres ?

Parce que ces deux objets portent des informations différentes et se relient par un identifiant d’offre. L’export candidatures mesure le volume, les sources et la progression ; l’export offres permet d’identifier les offres actives, anciennes ou sans candidatures et de segmenter par métier, région et contrat. Sans l’export offres, il est impossible de repérer proprement les offres en difficulté ou de comparer des périmètres.