Un générateur de données de CV construit toute une histoire professionnelle — une personne, une succession de postes avec leurs dates de début et de fin, un parcours de formation, une liste de compétences, un ensemble de certifications et une prétention salariale — assemblée de manière que les parties aient du sens ensemble. Alimenter un analyseur champ par champ ne teste presque rien ; lui fournir une chronologie cohérente est ce qui expose les défauts que les équipes livrent réellement.
Ce guide couvre ce qu’un système de recrutement attend d’un dossier de candidat, quelles règles de chronologie un générateur doit respecter, pourquoi les intitulés de poste et les compétences doivent provenir d’une taxonomie sensible au pays, et où se situe la frontière de confidentialité lorsque l’enregistrement ressemble à une personne. À la fin, vous devriez savoir quelles assertions appartiennent à un test de formulaire de recrutement et quelles propriétés d’un CV sont plus difficiles qu’elles n’en ont l’air.
Que fait un système de recrutement d’un dossier de candidat ?
Un système de suivi des candidatures reçoit un document, l’analyse en champs structurés, le dédoublonne par rapport aux candidats existants, le note, le route vers un relecteur et le stocke pour une durée de conservation. Chacune de ces étapes ne peut être testée que si l’entrée ressemble à un vrai parcours professionnel plutôt qu’à une liste de mots-clés.
L’analyse est l’étape où les données générées gagnent leur place. Un analyseur doit trouver l’employeur, l’intitulé, les dates et le lieu dans un texte libre, et ses modes de défaillance sont précis : un intitulé lu comme un employeur, un mois et une année lus comme une plage, un lieu absorbé dans l’intitulé du poste, un document de deux pages concaténé incorrectement. Ces défauts n’apparaissent que lorsque l’entrée a la forme d’un vrai document. Les défaillances se regroupent aussi autour de la gestion de fichiers plutôt que du texte : un document avec un tableau au lieu d’une liste, un en-tête qui se répète à chaque page, un nom contenant un accent qui arrive dans le mauvais encodage, ou une mise en page sur deux colonnes lue de gauche à droite à travers les deux colonnes. Les enregistrements générés rendent ces variantes peu coûteuses à produire et peu coûteuses à conserver comme fixtures.
La mise en correspondance est la deuxième étape, et elle dépend de l’accord entre les champs. Un candidat dont le poste le plus récent est dans un pays et dont l’adresse est dans un autre n’est pas inhabituel en pratique, mais un candidat dont les dates de formation suivent ses dates d’emploi l’est. Un générateur qui respecte la chronologie vous donne des enregistrements qui exercent honnêtement la logique de mise en correspondance. Le dédoublonnage est un test connexe, car il dépend de quasi-correspondances plutôt que de correspondances exactes : la même personne deux fois avec un nom de famille à trait d’union, un nom de jeune fille, une adresse e-mail différente, ou un nom d’entreprise abrégé différemment. Produire ces variantes à dessein est le seul moyen fiable de savoir si l’étape de fusion conserve le bon enregistrement. L’article sur les données de profil professionnel de test couvre l’ensemble de champs plus large, et l’article sur les fixtures de test d’analyse de CV montre comment transformer des enregistrements générés en documents sur lesquels un analyseur peut être exécuté.
Quelles règles de chronologie doivent tenir
La première règle est qu’un poste se termine après avoir commencé. Cela semble trivial et est constamment violé par les fixtures fabriquées à la main, car les deux dates sont saisies à des endroits distincts et rien n’impose la relation entre elles. Tout enregistrement dont la fin précède le début échouera à un validateur de chronologie, et si la suite de tests n’a pas un tel validateur, il sera stocké et finira par casser un rapport.
La deuxième règle concerne les lacunes et les chevauchements. Un parcours professionnel peut contenir une lacune entre deux postes, et les lacunes sont légitimes et courantes. Les chevauchements sont aussi possibles lorsque quelqu’un a occupé deux postes en parallèle, mais ils sont assez rares pour qu’un générateur doive les traiter comme un cas délibéré plutôt que par défaut. Ce qui importe est que le choix soit explicite : un jeu de données qui ne produit jamais de lacunes ne testera jamais le chemin de gestion des lacunes, et un jeu qui ne produit jamais de chevauchements ne testera jamais l’avertissement de chevauchement.
La troisième règle est que la formation précède l’emploi précoce ou se déroule en parallèle. Un candidat peut travailler pendant ses études, donc les deux peuvent se chevaucher, mais un diplôme obtenu avant que la personne ne soit assez âgée pour travailler est un défaut. C’est là qu’une date de naissance générée et une chronologie de formation générée doivent être dérivées l’une de l’autre plutôt que tirées indépendamment.
La quatrième règle concerne le présent. Exactement un poste peut être actuel, et il ne devrait pas avoir de date de fin. Un jeu de données où plusieurs postes sont marqués comme actuels, ou où le poste le plus récent s’est terminé il y a des années alors que le candidat est décrit comme activement en recherche, produit des signaux incohérents qu’un vrai pipeline de présélection signalerait.
Pourquoi les intitulés de poste et les secteurs ont-ils besoin d’une taxonomie ?
Un intitulé de poste n’est pas du texte libre doté d’un sens clair. Le même travail porte un nom différent dans différentes entreprises, différents secteurs et différents pays, et le niveau qu’implique un intitulé varie selon ces trois facteurs. Un générateur qui concatène un mot d’ancienneté aléatoire avec un nom commun aléatoire produit des intitulés qu’aucun système ne regroupera correctement.
L’approche utile est une taxonomie dans laquelle chaque intitulé appartient à une fonction et à un niveau, et chaque fonction appartient à un ensemble de secteurs où elle apparaît plausiblement. Un intitulé issu du mauvais secteur est un enregistrement qu’un algorithme de mise en correspondance notera de manière absurde, et un niveau qui contredit les années d’expérience de l’enregistrement est un enregistrement auquel un relecteur se méfierait immédiatement. L’article sur les intitulés de poste par secteur explique comment les regroupements sont construits.
Les compétences suivent la même logique. Une liste de compétences devrait être plausible pour le poste, et un poste sénior devrait porter un mélange différent de celui d’un poste junior. Les niveaux de compétence sont généralement exprimés sur une échelle, et un enregistrement qui revendique le niveau maximal pour chaque compétence est aussi peu informatif qu’un enregistrement qui ne revendique rien. L’article sur la taxonomie et les niveaux de compétences couvre la façon dont les échelles sont définies et pourquoi le nombre de paliers importe.
Les certifications et les licences ajoutent une troisième dimension, car certains postes les exigent et d’autres non, et une licence est généralement liée à une juridiction. Un enregistrement revendiquant une licence émise par un pays alors que l’historique d’emploi se trouve dans un autre est un défaut de cohérence qui mérite d’être généré délibérément comme cas de test négatif. L’article sur les données de licence et de certification décrit les motifs.
Comment gérer le salaire et la devise
Le salaire est le champ le plus susceptible d’être stocké sous une forme incapable de répondre aux questions plus tard. Un nombre sans devise ni période n’est pas un salaire ; c’est un nombre. Trente mille signifie des choses différentes comme montant annuel dans une devise et comme montant mensuel dans une autre, et un jeu de données qui omet les deux champs produira des rapports que personne ne peut réconcilier.
Le modèle utile stocke un montant, un code de devise et une période telle qu’annuelle ou mensuelle, et traite les trois comme obligatoires ensemble. Lorsque la devise diffère du pays du poste, l’enregistrement devrait le dire délibérément plutôt que par accident, car une rémunération transfrontalière est un cas réel qu’une suite de tests devrait inclure. L’article sur la devise et la période du salaire déroule les combinaisons.
Le formatage des devises introduit une seconde classe de défauts. Les séparateurs de milliers, les séparateurs décimaux, le placement du symbole monétaire et les montants négatifs sont tous dépendants de la locale, et un analyseur qui suppose une convention lira mal des valeurs issues d’une autre. Les enregistrements générés vous offrent un moyen peu coûteux de faire passer plusieurs conventions par le même chemin de code, y compris l’inversion qui transforme une virgule décimale en séparateur de milliers. Garder le code de devise à côté du montant, plutôt que de l’inférer du pays, est ce qui rend ces assertions stables lorsque le même enregistrement est lu sous une autre locale.
Les plages méritent d’être testées séparément. Beaucoup de formulaires acceptent un minimum et un maximum, et la relation entre eux est du même genre de contrainte que les dates d’emploi : le minimum ne doit pas dépasser le maximum. Les valeurs négatives et zéro méritent aussi d’être incluses, car un pipeline qui les stocke sans broncher finira par produire une annonce absurde.
La conservation mérite un test à elle. Un dossier de candidat porte une date de suppression ou un horizon de politique, et le parcours qui anonymise ou supprime un enregistrement lorsque cet horizon est dépassé est facile à rater et rarement exercé avec une horloge contrôlée. Utiliser des enregistrements générés aux dates que vous pouvez déplacer rend ce parcours testable sans attendre que le temps réel s’écoule, ce qui est le seul moyen dont la plupart des équipes le testent jamais.
Que devraient vérifier les tests de formulaire de recrutement
Testez l’analyse, pas seulement la saisie. Soumettez un document généré et vérifiez que les champs analysés correspondent à l’enregistrement qui l’a produit, nom par nom et date par date. Ce seul test est le plus précieux de la suite car il couvre tout le chemin d’extraction plutôt que le formulaire seul.
Testez les validateurs de chronologie avec des enregistrements délibérément cassés : une date de fin avant une date de début, deux postes actuels, une entrée de formation qui commence avant la date de naissance. Chacun devrait produire un rejet précis plutôt qu’une erreur générique, et la précision est elle-même une propriété qui mérite une assertion.
Testez le parcours de conservation et de suppression. Un dossier de candidat porte une durée de conservation, et un système qui conserve les enregistrements indéfiniment est un problème de conformité plutôt que de fonctionnalité, ce qui le rend facile à négliger dans une suite fonctionnelle. L’article sur la conservation des données RH explique à quoi servent les durées et pourquoi elles varient selon la juridiction.
Testez les champs à leurs limites. Une liste de compétences vide, un historique professionnel à un seul poste, un nom contenant une apostrophe ou un diacritique, un nom d’employeur à la limite de longueur du champ. L’article sur les cas de test du formulaire de recrutement les rassemble dans un fichier réutilisable, et le générateur de données de carrière de ce site produit des enregistrements qui satisfont déjà les règles de cohérence, de sorte que les cas limites soient la seule chose restant à faire varier.
Ce qu’un CV synthétique est et n’est pas
Un CV généré ne décrit personne. Le nom est inventé, les employeurs sont inventés, les dates sont inventées et les réalisations sont inventées. Rien dans l’enregistrement ne correspond à l’historique d’une personne réelle, et aucun employeur nommé dans un enregistrement généré n’a jamais employé qui que ce soit.
C’est exactement pourquoi l’enregistrement est sûr à utiliser en test. Comme aucun vrai candidat n’est décrit, une fixture ne peut pas divulguer les données d’un candidat, et une capture d’écran d’un environnement de préproduction ne peut pas révéler l’historique d’emploi de qui que ce soit. L’article sur les données synthétiques et anonymisées explique pourquoi les enregistrements inventés et les enregistrements dé-identifiés sont des choses différentes, et pourquoi seul le premier est exempt de risque de ré-identification.
La frontière compte aussi pour la conservation. Un enregistrement synthétique n’a aucun sujet ayant des droits sur lui, mais il peut se trouver dans le même système que de vrais enregistrements, et un jeu de données qui mélange les deux est un jeu où les demandes de suppression deviennent difficiles à satisfaire. Gardez les enregistrements générés identifiables comme générés, et tenez-les hors de tout stockage qui contient de vrais dossiers de candidats.
Chaque enregistrement produit de cette manière est une donnée de test synthétique réservée au test logiciel. Il ne doit pas être soumis comme la candidature de quelqu’un, servir à usurper l’identité d’un candidat ou d’un employeur, servir à obtenir un emploi ou un diplôme, ni servir à tester un système que vous n’exploitez pas.