Journal d'audit Teamtailor : à quoi sert-il vraiment et comment l'exploiter ?

Un candidat écrit pour demander l’accès à ses données. Le même mois, un administrateur exporte plusieurs centaines de profils avant de quitter l’entreprise. Un compte utilisateur est supprimé pendant une réorganisation. Une fiche candidat est partagée par lien avec une personne qui ne fait pas partie de l’équipe recrutement. Prises isolément, ces actions sont banales. Plusieurs semaines plus tard, une seule question compte : qui a fait quoi, quand, et dans quel contexte ?

C’est précisément à cette question que le journal d’audit Teamtailor peut répondre, à condition d’être correctement conservé, lu et interprété. Il ne dira pas si une action était justifiée, ni pourquoi elle a eu lieu. Mais il fournit une chronologie fiable des opérations sensibles réalisées dans l’outil. Dans beaucoup d’organisations, ce journal est activé pour cocher une case de sécurité ou de conformité, puis n’est presque jamais consulté. Il devient un historique technique qui dort dans un menu, alors qu’il pourrait servir de véritable point d’appui à la gouvernance des données candidats.

Qu’est-ce que le journal d’audit Teamtailor ?

Le journal d’audit Teamtailor enregistre qui a réalisé une action et à quel moment, sur un ensemble d’opérations considérées comme sensibles dans l’ATS. Il ne s’agit pas d’un tableau de bord d’activité, mais d’une trace horodatée des événements liés à la sécurité et à la protection des données. D’après la documentation officielle Teamtailor, il est accessible aux Company Admins, dans les réglages de confidentialité et de données, une fois la fonctionnalité activée.

Pour bien situer son rôle, il faut le distinguer de deux autres briques que les équipes confondent souvent avec lui.

Les statistiques de recrutement mesurent la performance : volume de candidatures, sources, étapes du pipeline, délais. Elles servent au pilotage et au reporting, pas à la sécurité. L’historique fonctionnel, lui, retrace la vie d’une candidature ou d’une offre du point de vue métier : changements de statut, messages, notes. Le journal d’audit répond à une autre intention. Il documente les actions à enjeu de confidentialité et de conformité : exports, suppressions, partages, demandes relatives aux données, mouvements sur les comptes utilisateurs. Confondre ces trois objets conduit à en attendre ce qu’ils ne fournissent pas. Un journal d’audit n’est ni un rapport de productivité, ni un remplaçant des statistiques Teamtailor.

Le journal peut être recherché, filtré, puis exporté au format CSV, en version complète ou filtrée. C’est ce qui le rend exploitable en dehors de l’interface, dès lors qu’on décide de l’analyser sérieusement. Point important à intégrer d’emblée : l’historique standard est limité dans le temps, et conserver une profondeur plus longue relève d’un réglage, voire d’une option supplémentaire. Nous y revenons plus bas, car cette contrainte de durée conditionne à elle seule une bonne partie de la valeur du dispositif.

Quelles actions le journal d’audit Teamtailor permet-il de retrouver ?

Plutôt que de lister des dizaines de codes techniques, il est plus utile de raisonner par familles d’événements. La documentation Teamtailor organise les traces autour de grands ensembles, que l’on peut regrouper ainsi pour un décideur RH.

Premièrement, les données et droits des candidats : demandes d’accès aux données, demandes de suppression, extensions de consentement. Deuxièmement, les exports, partages et suppressions : export de profils, liens de partage, impressions, suppressions individuelles ou massives. Troisièmement, les utilisateurs et habilitations : création, modification et suppression de comptes, invitations, opérations groupées. Quatrièmement, les offres et paramètres de l’environnement : création, mise à jour et suppression d’offres. Cinquièmement, les accès ou interventions du support : connexion d’un collaborateur Teamtailor, ou connexion en tant qu’un de vos utilisateurs à des fins de dépannage. Sixièmement, lorsque leur présence est confirmée dans votre environnement, les usages de certaines fonctionnalités comme Nurture, et selon les cas les fonctions assistées par l’IA de l’éditeur.

Le tableau suivant donne quelques exemples parlants, traduits pour un usage de gouvernance plutôt que pour un lecteur technique.

Type d’événement	Exemple	Pourquoi il peut être sensible	Question à se poser
Export de données candidats	Un utilisateur exporte plusieurs centaines de profils	Sortie de données personnelles hors de l’outil, difficilement traçable ensuite	Cet export était-il prévu, autorisé et proportionné ?
Suppression massive	Suppression groupée de candidatures ou de profils	Perte de données potentiellement irréversible	Qui a lancé l’opération, et selon quelle règle de conservation ?
Lien de partage	Partage d’une fiche candidat par lien	Diffusion possible en dehors de l’équipe habilitée	Le destinataire avait-il vocation à voir ce profil ?
Demande d’accès aux données	Un candidat demande la copie de ses données	Obligation de traitement dans un délai encadré	La demande a-t-elle été prise en charge, par qui et quand ?
Demande de suppression	Un candidat demande l’effacement de ses données	Droit du candidat à documenter et à honorer	La suppression a-t-elle été réalisée et tracée ?
Mouvement sur un compte utilisateur	Création, modification ou suppression d’un compte	Élargissement ou perte de droits d’accès aux données	Ce changement d’accès correspond-il à une décision validée ?
Intervention du support	Connexion d’un collaborateur Teamtailor pour dépannage	Accès temporaire à l’environnement par un tiers	L’intervention était-elle demandée et bornée ?

Ce tableau reste indicatif. La liste exacte des événements et la précision de leurs libellés dépendent de votre environnement et des fonctionnalités activées. Un test sur un export réel reste nécessaire pour savoir ce que vous voyez concrètement.

Cinq usages concrets pour une organisation

La valeur du journal n’apparaît pas dans le comptage des lignes, mais dans quelques usages précis. En voici cinq, tirés de situations que rencontrent les équipes RH et data.

Reconstituer les faits après une erreur ou un incident. Une candidature disparaît, un profil semble avoir été modifié, une donnée manque. Le journal permet de retrouver la dernière action enregistrée sur l’objet concerné, son auteur et son horodatage. Cela ne dit pas si l’action était justifiée, mais cela remplace les suppositions par une chronologie.

Suivre le traitement des demandes relatives aux données. Quand un candidat exerce ses droits, la documentation Teamtailor indique qu’un Company Admin peut voir, dans le journal, qu’une demande a été traitée, par qui et quand, pour les demandes gérées manuellement. C’est un point d’appui utile pour démontrer qu’une demande n’est pas restée sans réponse.

Contrôler les opérations massives. Les exports groupés et les suppressions massives sont les événements où le risque se concentre. Les repérer, même a posteriori, permet de vérifier qu’ils correspondaient à un besoin réel et à une personne habilitée, plutôt que de les découvrir trop tard.

Sécuriser la gouvernance des administrateurs et des utilisateurs. Dans une organisation multisite ou décentralisée, les comptes se créent, se modifient et se suppriment au fil des mouvements internes. Suivre ces changements aide à éviter les accès qui traînent après un départ, ou les élévations de droits jamais réexaminées.

Disposer d’éléments lors d’un audit interne ou d’une investigation. Lorsqu’une question sérieuse se pose, avoir sous la main une trace horodatée change la conversation. On ne part plus de zéro, on part d’un fait daté. Encore faut-il que le journal ait été conservé assez longtemps pour couvrir la période concernée, ce qui nous conduit à ses limites.

Ce que le journal d’audit ne permet pas de conclure

Une trace n’est pas une explication. Le journal indique qu’une action a eu lieu, pas l’intention qui la sous-tend. Un export de données peut être une opération de maintenance parfaitement légitime ou un signal préoccupant : le journal, seul, ne tranche pas.

Plusieurs prudences s’imposent. Un événement générique de type mise à jour peut être trop peu détaillé pour être interprété sans contexte. Le volume d’actions d’un utilisateur ne mesure ni la qualité ni l’utilité de son travail, et vouloir en tirer une évaluation individuelle serait un contresens. Une activité élevée n’est pas, en soi, une anomalie : un pic peut simplement refléter une campagne de recrutement intense. À l’inverse, l’absence d’alerte ne prouve pas la conformité ; elle prouve seulement que rien n’a déclenché de signal dans le périmètre observé.

Enfin, le journal d’audit ne remplace pas les statistiques de recrutement comme le time-to-hire ou l’analyse des sources. Ce sont deux mondes distincts : l’un documente la sécurité et la conformité, l’autre mesure la performance. Les faire jouer l’un contre l’autre revient à mal utiliser les deux.

La principale limite : conserver des traces ne suffit pas

Voici la conviction que nous portons après avoir paramétré et lu ce type d’environnement : un journal d’audit ne vaut pas par ce qu’il stocke, mais par ce que l’organisation en fait. Et la première contrainte est la durée. L’historique standard de Teamtailor est court, de l’ordre de quelques jours, avec une extension possible jusqu’à un mois par réglage, et une conservation plus longue soumise à une option supplémentaire auprès de l’éditeur. Pour la CNIL, la journalisation des accès mérite pourtant une conservation de l’ordre de six mois à un an sur une période glissante. Cet écart n’est pas un détail : si vos traces s’effacent avant que vous ne les regardiez, elles ne servent à rien le jour où une question se pose.

La réponse pratique tient en une idée simple : une collecte périodique. Exporter régulièrement le journal, le conserver dans un espace sécurisé et définir qui y a accès permet de dépasser la limite de rétention native. Cela suppose de sécuriser ces exports, car un fichier qui recense des actions sur des données candidats est lui-même une donnée sensible, et de désigner clairement les destinataires légitimes.

Restent des règles d’usage à poser en amont. Qui déclenche une investigation, et à partir de quel signal ? Les utilisateurs sont-ils informés qu’un journal existe, comme le recommande la CNIL au titre de la transparence ? La question du RGPD dans l’ATS ne se limite d’ailleurs pas au journal d’audit, et nous l’avons développée du côté des réglages ATS à vérifier face aux contrôles CNIL. Un point de vigilance domine tous les autres : la CNIL rappelle qu’utiliser des traces pour surveiller le temps de travail constitue un détournement de finalité. Un journal d’audit n’est pas un outil de contrôle de la productivité des recruteurs, et le présenter comme tel exposerait l’organisation au lieu de la protéger. Cela dit, ces éléments relèvent de la gouvernance interne et d’un cadrage juridique propre à chaque organisation, qu’un article ne saurait remplacer.

Faut-il construire un dashboard du journal d’audit ?

La réponse honnête est : cela dépend. Un dashboard dédié au journal d’audit apporte une réelle valeur dans certaines configurations, et très peu dans d’autres.

Il devient pertinent lorsque le nombre d’utilisateurs ou d’administrateurs est important, lorsque l’organisation est multisite ou décentralisée, lorsque les exports et les partages sont fréquents, ou lorsque le DPO, la DSI ou le RSSI ont besoin d’une vue synthétique plutôt que d’un CSV brut à éplucher. Deux conditions rendent l’exercice réellement utile : que les données soient collectées régulièrement, et qu’une personne soit chargée de traiter les événements remontés. Un dashboard sans destinataire ni responsable retombe vite en décoration. Cette logique rejoint celle que nous appliquons à nos dashboards RH et recrutement : un indicateur n’existe que s’il déclenche une décision.

Il apporte peu de valeur, en revanche, quand l’historique est ponctuel, quand les événements sont trop génériques pour être interprétés, quand personne n’est responsable de leur analyse, ou quand le résultat se limite à compter toutes les actions sans hiérarchie. Un tableau qui affiche des milliers de lignes sans procédure d’action derrière chaque signal ne fait que déplacer le problème : on remplace un journal non lu par un dashboard non exploité.

Comment tester l’intérêt du journal d’audit sur son propre environnement ?

Avant d’investir dans un dispositif de suivi, la meilleure approche est un test court et concret sur vos propres données. Une démarche en quelques étapes suffit à décider.

Commencez par exporter une période représentative du journal, assez large pour couvrir des exports et des mouvements d’utilisateurs. Inventoriez ensuite les catégories d’événements réellement présentes, sans présumer de ce que contient l’export : c’est souvent une surprise. Repérez les opérations sensibles, exports, suppressions, partages, demandes relatives aux données, et mesurez la qualité et la précision des descriptions associées. Un libellé clair permet une lecture ; un libellé trop générique demandera un recoupement manuel qui coûte du temps. Cette étape rejoint la question plus large des données à exporter d’un ATS lorsqu’on veut en tirer un usage fiable.

Identifiez alors les événements qui justifieraient réellement une vérification, en visant un nombre limité de signaux plutôt qu’une surveillance générale. Définissez ensuite qui utiliserait ce reporting : RH, DPO, DSI, RSSI, chacun n’a pas les mêmes besoins ni le même seuil d’attention. Enfin, décidez du bon format : une lecture ponctuelle au fil des incidents, une revue périodique cadencée, ou un dashboard alimenté par des exports réguliers. Ce test évite deux erreurs symétriques : surinvestir dans un outillage inutile, ou négliger un dispositif qui aurait de la valeur dans votre contexte.

Du journal technique à un outil de gouvernance

Le journal d’audit Teamtailor peut rester un historique technique oublié, ou devenir une brique de gouvernance des données candidats. Ce qui fait la différence n’est pas la technologie : c’est le fait de relier chaque trace à une finalité, à une responsabilité et à une capacité d’action. Une trace sans lecteur ne protège personne. Une trace lue par la bonne personne, au bon moment, avec une procédure claire derrière, change la manière dont une organisation gère ses données et ses accès.

C’est le travail que mène Inside Linkers dans le cadre de son accompagnement auprès des équipes RH et data : analyser un premier export pour voir ce qu’il contient vraiment, qualifier les événements réellement exploitables, définir les usages et les indicateurs pertinents, évaluer la pertinence d’un dashboard, et articuler le tout avec la gouvernance Teamtailor et les interlocuteurs concernés, DPO, DSI ou RSSI. L’objectif n’est pas de produire un certificat de conformité, qui relève d’un cadre juridique dédié, mais de transformer un stock de traces en un dispositif réellement utile.

FAQ

Qui peut consulter le journal d’audit Teamtailor ?

Selon la documentation Teamtailor, le journal d’audit est accessible aux Company Admins, dans les réglages de confidentialité et de données, une fois la fonctionnalité activée. Les autres profils n’y ont pas accès par défaut. Il est donc utile de vérifier qui dispose du rôle Company Admin dans votre environnement, car ce sont ces personnes qui pourront lire et exporter les traces.

Combien de temps les événements du journal sont-ils conservés ?

L’historique standard est limité à quelques jours, avec une extension possible jusqu’à environ un mois via un réglage. Une conservation plus longue peut nécessiter une option supplémentaire auprès de Teamtailor. Cette durée native étant courte au regard des recommandations de la CNIL, qui évoque une conservation de l’ordre de six mois à un an, une collecte périodique des exports est souvent nécessaire, sous réserve de vérification sur votre environnement.

Peut-on exporter le journal d’audit Teamtailor ?

Oui. Le journal peut être recherché, filtré, puis exporté au format CSV, en version complète ou filtrée selon les critères appliqués. Cet export permet d’analyser les données en dehors de l’interface et de les conserver au-delà de la durée native, à condition de sécuriser le fichier obtenu, qui contient lui-même des informations sensibles sur les actions réalisées.

Peut-on automatiser son analyse avec l’API ou des webhooks ?

Une automatisation est envisageable. La documentation Teamtailor indique que les webhooks peuvent notamment porter sur des audit events, avec une configuration par un Company Admin et une vérification de signature. L’API de la plateforme ouvre d’autres possibilités. La granularité exacte des événements disponibles et les conditions techniques doivent toutefois être testées sur l’environnement concerné avant toute promesse d’automatisation.

Le journal d’audit suffit-il pour garantir la conformité RGPD ?

Non. Le journal d’audit est un outil de traçabilité parmi d’autres. Il aide à documenter certaines opérations sensibles, mais il ne constitue pas à lui seul une preuve de conformité et ne remplace ni le DPO, ni le RSSI, ni un audit juridique. La conformité RGPD repose sur un ensemble de mesures, dont la journalisation n’est qu’une composante.