Évaluer la recherche candidats d’un ATS avant de choisir son logiciel

Une démonstration peut faire apparaître dix profils convaincants en quelques secondes sans montrer ceux que le moteur a oubliés. Avant de choisir un ATS, la bonne question est plus précise : sur vos besoins, quelles personnes retrouve-t-il, lesquelles manque-t-il et pouvez-vous comprendre pourquoi ? La vitesse et la présentation comptent, mais elles ne suffisent pas à établir la qualité d’une recherche.

Ce guide propose un protocole de recette pour un recruteur indépendant, un cabinet, une ESN ou une équipe RH. Vous construirez un petit corpus connu, des résultats attendus et une grille d’anomalies. Il complète le guide pour comparer deux logiciels avec des scénarios concrets, en approfondissant uniquement la recherche de candidats.

Commencer par trois situations de travail réelles

Écrivez trois tâches que votre équipe répète : retrouver un profil déjà rencontré, constituer une liste à partir de critères explicites et explorer des parcours proches sans connaître leur intitulé exact. Ces tâches sollicitent des mécanismes différents. Un outil performant pour retrouver un nom peut être moins utile lorsqu’il faut repérer une compétence décrite autrement.

Pour chaque tâche, précisez qui cherche, dans quel périmètre et pour quelle décision. Un consultant doit-il retrouver une personne de son équipe ou de toute la base autorisée ? Cherche-t-il dans les CV, les champs structurés, les notes ou seulement les intitulés ? La réponse attendue dépend autant du périmètre que de la formule saisie.

Préparez également une question qui ne devrait produire aucun résultat. Si le moteur affiche malgré tout une liste séduisante, vérifiez s’il propose des approximations, ignore une condition ou recherche ailleurs. Une suggestion peut être utile à condition d’être identifiable. Elle ne doit pas être confondue avec un résultat respectant toutes les conditions demandées.

Construire un corpus témoin que vous pouvez expliquer

Un corpus de recette est un ensemble limité de profils dont vous connaissez le contenu. Pour commencer, utilisez des documents entièrement fictifs ou des données autorisées dans un environnement adapté. Une vingtaine de fiches bien choisies peut révéler des problèmes, sans constituer une validation statistique de toute la base. La taille proposée ici est un point de départ pratique.

Incluez des cas contrastés : compétence explicite, synonyme, expérience ancienne, outil cité uniquement dans une formation, localisation manquante, document scanné et homonyme. Ajoutez un profil pertinent dont le titre est inhabituel. Le but est d’observer des comportements, pas de piéger le fournisseur avec des formulations sans rapport avec votre activité.

Conservez une copie datée des documents et indiquez les champs remplis manuellement. Si une information est ajoutée pendant la démonstration, notez-le. Sinon, vous risquez d’attribuer au moteur de recherche une réussite obtenue grâce à un enrichissement que votre équipe ne réaliserait pas dans son usage quotidien.

Écrire les résultats attendus avant la démonstration

Pour chaque requête, identifiez les profils qui devraient être retrouvés et ceux qui ne devraient pas l’être. Ajoutez une catégorie « à discuter » pour les cas ambigus. Cette annotation doit être réalisée avant de voir les résultats, sinon vous risquez de redéfinir la pertinence pour faire correspondre votre grille à la réponse du logiciel.

Faites relire quelques cas par un collègue métier. Si vous n’êtes pas d’accord sur la pertinence d’un profil, précisez le besoin avant de noter le moteur. Par exemple, « expérience de déploiement » peut désigner une contribution, une coordination ou un pilotage complet. Un désaccord de définition ne constitue pas automatiquement un défaut logiciel.

La documentation Greenhouse sur les requêtes booléennes illustre un autre point : opérateurs, expressions exactes et caractères spéciaux ont une signification propre à l’outil. Demandez la syntaxe effectivement prise en charge. Une requête copiée depuis un autre moteur n’est pas un test équitable si son interprétation change.

Tester séparément extraction, recherche et filtres

Lorsqu’un profil manque, suivez la chaîne dans l’ordre. Le document a-t-il été importé ? Le texte est-il exploitable ? L’information apparaît-elle dans le champ ou le document recherché ? L’index a-t-il été mis à jour ? Un filtre masque-t-il ensuite le profil ? Cette démarche évite de corriger une requête alors que le problème se situe à l’import.

Testez un filtre à la fois, puis leur combinaison. Comparez une recherche sans localisation, avec une localisation précise, puis avec plusieurs zones si le produit le permet. Vérifiez le comportement des champs vides. Un filtre strict peut être cohérent tout en excluant des candidats dont l’information reste à confirmer ; le recruteur doit savoir reconnaître cette situation.

Rejouez une recherche après la correction d’une fiche. Notez le délai réellement observé avant que la modification soit prise en compte, sans le généraliser à tous les volumes. Si le résultat diffère selon les droits de l’utilisateur, demandez une explication du périmètre autorisé. N’élargissez pas les accès pour faire artificiellement réussir le test.

Mesurer ce qui est retrouvé et ce qui encombre la liste

Deux mesures simples peuvent compléter la lecture qualitative. La précision correspond aux profils jugés pertinents parmi les résultats examinés. Le rappel correspond aux profils pertinents retrouvés parmi tous les profils pertinents connus du corpus. Le rappel n’est calculable que si votre ensemble de référence est suffisamment connu. Sur une base réelle non annotée, vous ne connaissez généralement pas tous les profils manqués.

Exemple entièrement fictif : votre corpus contient huit profils pertinents pour une tâche. Le moteur affiche dix résultats, dont six pertinents. La précision est de 6 sur 10, soit 60 %, et le rappel de 6 sur 8, soit 75 %. Ces valeurs décrivent ce test ; elles ne représentent ni un niveau normal du marché ni une performance d’Oxaibo.

Si vous ne lisez que les dix premiers résultats, annoncez une précision sur les dix premiers. Ne présentez pas cette mesure comme celle de l’ensemble de la liste. Notez également le temps nécessaire pour comprendre les correspondances et éliminer les faux positifs. Un classement utile réduit le travail de lecture sans prétendre évaluer automatiquement la personne pour le poste.

Examiner les suggestions de profils proches dans Oxaibo

La recherche peut aussi partir d’un vivier existant. Dans le fonctionnement prévu par Oxaibo, des profils similaires peuvent être proposés parmi les profils déjà présents dans la base de l’espace de travail. Le recruteur ouvre un vivier cohérent, consulte les suggestions, puis revient aux expériences et conditions de chaque profil avant de l’ajouter à sa sélection.

Pour tester ce parcours, préparez un vivier témoin homogène et quelques profils proches restés en dehors. Observez si les propositions apportent des pistes pertinentes. Recommencez avec un vivier beaucoup plus hétérogène : la qualité de votre point de départ peut modifier l’utilité de la suggestion. Le bénéfice recherché est de repérer des profils déjà disponibles que la première recherche n’avait pas mis en avant.

Ce mécanisme, vérifié dans le code du produit, s’appuie sur la proximité avec les profils du vivier ; il ne constitue pas une preuve d’adéquation à une mission ni une recherche sur tout Internet. Sa disponibilité et son comportement doivent être vérifiés dans votre environnement. N’en déduisez pas qu’une absence de suggestion signifie qu’aucun candidat approprié n’existe.

Tenir un registre d’anomalies exploitable

Une capture d’écran isolée ne suffit pas à reproduire un problème. Pour chaque écart, notez la requête exacte, les filtres, le profil attendu, la source de la preuve et l’heure du test. Ajoutez la version du corpus et le compte ou rôle utilisé, sans enregistrer de secrets. Le fournisseur doit pouvoir comprendre le scénario sans recevoir inutilement des données de candidats.

Classez ensuite les anomalies par conséquence métier. Une information difficile à lire peut être acceptable si elle se vérifie rapidement. L’omission répétée d’un type de document fréquent peut être bloquante. Une fonction annoncée mais impossible à démontrer doit rester « non vérifiée », même si une évolution est prévue. Séparez les capacités actuelles des engagements futurs.

Décider avec un seuil lié à votre usage

Fixez vos conditions d’acceptation avant la dernière démonstration : cas indispensables réussis, anomalies bloquantes corrigées, effort de lecture acceptable et périmètre compris. N’utilisez pas un seuil universel de précision. Une recherche exploratoire peut tolérer davantage de bruit qu’une opération destinée à retrouver un profil précis pour préparer un entretien imminent.

Rejouez le même corpus après une correction, puis ajoutez quelques cas nouveaux pour éviter une validation limitée aux exemples déjà montrés. Gardez les deux résultats. Le second passage ne doit pas effacer l’historique du premier. Dans votre décision, distinguez ce qui fonctionne immédiatement, ce qui demande une configuration et ce qui reste incertain.

Enfin, demandez à un recruteur qui n’a pas assisté à la démonstration de refaire une tâche à partir d’une consigne courte. Vous évaluerez ainsi la transmissibilité de la méthode. Une recherche qui ne fonctionne qu’avec l’intervention permanente d’un expert peut rester utile, mais son coût d’apprentissage doit apparaître dans le choix du logiciel.

Questions fréquentes

Faut-il importer toute sa base pour tester un ATS ?

Commencez par un corpus limité et maîtrisé, puis élargissez si les premiers résultats justifient un pilote. Le corpus réduit sert à comprendre les comportements ; un pilote représentatif sert à vérifier les volumes, les usages et l’organisation. Respectez les règles applicables aux données utilisées, en vous appuyant notamment sur le guide du recrutement de la CNIL.

Un moteur sémantique dispense-t-il de préparer les critères ?

Non. Il peut proposer des rapprochements utiles, mais la pertinence dépend toujours du besoin et de la qualité des informations. Conservez une définition des exigences, puis vérifiez les expériences et les conditions du poste. Le guide sur la combinaison des mots-clés et de la recherche sémantique aide à distinguer leurs usages.

Que faire si deux outils retrouvent les mêmes profils ?

Comparez le temps de vérification, la visibilité des preuves, la compréhension des filtres et la possibilité de reproduire le résultat. À pertinence comparable, ces éléments déterminent la facilité d’usage. Documentez également les cas non résolus : une égalité sur quelques requêtes ne démontre pas une équivalence sur tous vos recrutements.