Publié le 19 octobre 2026
Les cabinets de recrutement et de staffing génèrent une masse énorme de connaissances internes qui, pour l’essentiel, ne sont stockées dans aucun endroit consultable. Les notes d’un recruteur après un appel de présélection, les retours d’un responsable du recrutement sur les raisons pour lesquelles un candidat n’a pas avancé, les propres préférences du candidat concernant la mobilité ou la rémunération — tout cela se retrouve généralement éparpillé dans les champs texte libre d’un applicant tracking system, les fils d’e-mails et la mémoire de chaque recruteur. Lorsqu’un poste similaire se rouvre des mois plus tard, le cabinet repart en pratique de zéro, alors que quelqu’un dans l’équipe a peut-être déjà évalué un excellent candidat pour un poste presque identique.
C’est un cas d’usage assez propre pour le retrieval-augmented generation, car le problème sous-jacent n’est pas un manque de données — c’est le fait que ces données existent sous forme non structurée, réparties sur plusieurs systèmes, et qu’elles ne sont pas retrouvables autrement que par la mémoire d’un recruteur sur les personnes qu’il a rencontrées et à quel moment.
Pourquoi la recherche dans l’ATS ne suffit pas
La plupart des applicant tracking systems permettent une recherche par mots-clés dans les CV et les fiches candidats, ce qui fonctionne assez bien pour les champs structurés comme les compétences, les années d’expérience et la localisation, mais montre vite ses limites dès qu’il s’agit des informations nuancées qui prédisent réellement si une reprise de contact vaut la peine. Une recherche par mots-clés ne fera pas remonter le fait qu’un candidat précis a bien passé un entretien pour un poste similaire dans le passé mais l’a refusé à cause d’un écart de rémunération qui n’existe peut-être plus, ou qu’un responsable du recrutement a donné un retour précis, non générique, sur ce qu’il recherchait vraiment au-delà des exigences listées dans la description du poste.
Cette information existe dans les notes d’appel, les retours d’entretien et les résumés d’e-mails, mais elle est rédigée en langage naturel, incohérente dans sa forme et, en pratique, invisible pour tout autre qu’un humain qui la lit. Un recruteur avec de l’ancienneté et une bonne mémoire peut parfois tout reconstituer manuellement. Un recruteur qui prend un poste en main, ou un cabinet qui veut rendre cette connaissance accessible à toute son équipe plutôt que de la laisser enfermée dans la mémoire de chacun, ne le peut pas.
Ce que fait un système RAG ici
L’architecture utile consiste en une couche de retrieval au-dessus de l’historique des interactions candidats du cabinet, associée à un language model capable de répondre à des questions précises en s’appuyant sur ce contenu récupéré plutôt qu’en générant des réponses à partir de connaissances générales. Lorsqu’un recruteur ouvre une nouvelle demande, au lieu de repartir d’une recherche vide, il peut poser une question proche d’un vrai besoin : des candidats solides pour un poste similaire d’ingénierie backend au cours de la dernière année, mais qui ont refusé une offre pour des raisons de rémunération, ou des candidats qui ont bien passé un entretien pour un rôle en clinical operations mais n’ont pas été retenus pour des raisons sans rapport avec leurs compétences.
Le système récupère les interactions spécifiques qui sont réellement pertinentes pour cette question, pas seulement des correspondances de mots-clés mais aussi des conversations passées sémantiquement proches, et le language model résume ce qu’il a trouvé avec des références vers les enregistrements sources, afin que le recruteur puisse vérifier le résumé à partir des notes réelles plutôt que de lui faire aveuglément confiance. Cette étape d’ancrage est essentielle : un système qui produit des résumés plausibles sans les relier aux véritables enregistrements est un risque dans le recrutement, où une erreur sur l’historique d’un candidat a des conséquences concrètes, à la fois pour la relation avec ce candidat et pour la crédibilité du cabinet auprès d’un responsable du recrutement.
Sources de données et travail nécessaire pour les rendre exploitables
La partie difficile d’un projet comme celui-ci n’est rarement l’architecture de retrieval elle-même — c’est de rendre les données sous-jacentes exploitables. Les notes d’appel sont souvent incohérentes dans leur forme et leur qualité selon le recruteur qui les a rédigées. Les retours d’entretien peuvent se trouver dans un système séparé de l’ATS. Il faut extraire les fils d’e-mails pour en isoler le contenu pertinent et le séparer de la logistique de planification et du reste du bruit. Avant qu’un système de retrieval soit utile, il faut généralement une phase importante de consolidation et de nettoyage des données : extraire depuis l’ATS, les e-mails et tout autre système où les interactions avec les candidats sont enregistrées, normaliser les formats et, dans certains cas, utiliser un language model pour résumer des notes historiques désordonnées dans une structure plus cohérente avant de les indexer pour le retrieval.
C’est aussi là que les contrôles d’accès comptent davantage que dans une base de connaissances interne classique. Les données candidats sont sensibles, et un cabinet de recrutement qui travaille pour plusieurs clients doit s’assurer que le retrieval respecte les frontières de confidentialité entre les comptes clients. Un candidat évalué confidentiellement pour un client ne doit pas apparaître dans le résultat d’une recherche sans rapport menée par une autre équipe, et le système doit faire respecter cette frontière au niveau de la donnée, sans compter sur le fait que les recruteurs se souviennent de ne pas consulter.
Garder le système à jour
Une base de connaissances comme celle-ci ne se construit pas une seule fois — elle a besoin que de nouvelles interactions avec les candidats y arrivent en continu, sinon elle finit par se périmer et perd la valeur pour laquelle elle a été créée. Cela suppose généralement un pipeline d’ingestion qui récupère en permanence les nouvelles notes d’appels, les formulaires de retour et les synthèses d’e-mails, les traite et les indexe, puis les rend accessibles à la recherche sans exiger d’effort manuel des recruteurs au-delà de la prise de notes qu’ils effectuent déjà dans le cadre de leur flux de travail habituel. L’objectif est de faire du système un sous-produit du travail existant, et non une tâche supplémentaire greffée par-dessus.
Pièges Courants à Anticiper
Le mode d’échec le plus fréquent dans un système de ce type consiste à considérer le résultat de la recherche comme une réponse finalisée plutôt que comme un point de départ pour une décision humaine. Un résumé des interactions passées avec un candidat est utile précisément parce qu’il ramène rapidement un recruteur vers les notes d’origine ; il cesse d’être utile, et devient risqué, dès que les recruteurs traitent le résumé généré comme une vérité sans vérifier la source. Garder les citations visibles et faciles à ouvrir, plutôt que de les enfouir derrière un lien générique « sources », fait une vraie différence dans la mesure où les recruteurs vérifient effectivement ce qu’ils lisent.
Un deuxième piège concerne la conservation des données et le consentement. Les données des candidats ont une durée de vie limitée, et de nombreuses juridictions ainsi que certains accords clients imposent des limites à la durée de conservation ou de réutilisation de certaines informations, en particulier pour les candidats qui n’ont pas été retenus. Un système de recherche bâti sur des interactions historiques doit respecter les politiques de conservation et de suppression qui s’appliquent déjà à ces données, ce qui signifie que l’index de recherche doit rester synchronisé avec les suppressions dans les systèmes sources, plutôt que de devenir une seconde copie oubliée de données qui auraient dû être effacées.
Un troisième piège est le biais de récence. Comme les interactions récentes sont naturellement plus nombreuses et plus détaillées que les anciennes, un système de recherche peut avantager involontairement des candidats évalués récemment par rapport à des candidats tout aussi solides mais plus anciens, simplement parce qu’il y a davantage de texte à retrouver. Ajuster la recherche pour pondérer la pertinence plutôt que la récence — au lieu de se rabattre par défaut sur les enregistrements les plus récents — demande généralement une attention délibérée, et ne se produit pas automatiquement.
Là Où Cela Crée de la Valeur
Le retour le plus évident d’un système de ce type se voit dans une baisse du délai de recrutement pour les postes qui ressemblent à ceux que le cabinet a déjà pourvus, ainsi que dans un nombre réduit d’occasions manquées de reprendre contact avec de bons candidats qui n’étaient pas adaptés à un poste précédent mais correspondent parfaitement à un poste actuel. Il offre aussi un avantage moins visible : il réduit la perte de connaissances institutionnelles qui survient lorsqu’un recruteur expérimenté quitte le cabinet, car une part importante de ce qui faisait son efficacité reposait sur un historique exploitable qui, sans cela, s’en va avec lui.
Si votre équipe dispose d’années d’historique d’interactions avec des candidats, mais que celui-ci est en pratique introuvable, il vaut la peine d’évaluer à quoi ressemblerait concrètement un système de recherche basé sur ces données avant de vous engager dans un projet plus vaste. Nous abordons les considérations d’architecture plus larges sur notre page RAG et systèmes de connaissances d’entreprise, ainsi que le contexte spécifique au recrutement sur notre page logiciel IA pour le recrutement et le staffing. Si vous souhaitez discuter de ce que cela impliquerait pour les systèmes spécifiques de votre cabinet, lancez une conversation projet avec nous.
Lié