Scoring de candidats par modèle de langage : garde-fous

Faire lire des CV par un modèle de langage fonctionne mieux que les moteurs à mots-clés de la génération précédente. C'est précisément pour cette raison que c'est risqué : un système visiblement mauvais est corrigé, un système plausible et parfois faux est adopté puis oublié. Cette note décrit l'architecture de garde-fous à poser avant de mettre quoi que ce soit en production.

Ce qu'un modèle de langage fait bien

Résumer. Produire cinq lignes fiables à partir d'un CV de trois pages. Vérifiable d'un coup d'œil contre le document d'origine, gain de temps réel.

Extraire ce qui résiste au parsing classique. Les CV mal structurés, les formulations inhabituelles, les intitulés hors référentiel — voir la note sur le parsing.

Répondre à une question fermée et factuelle. « Ce CV mentionne-t-il une expérience en pharmacie ? » Une question vérifiable, dont la réponse se contrôle en cherchant dans le document.

Reformuler une offre d'emploi. Détecter les formulations discriminantes, proposer une version plus claire. Sans enjeu sur le candidat.

Ce qu'il ne doit pas faire

Produire une note globale. « 7,5 sur 10 » agrège des critères dont personne ne connaît les poids, avec une précision décimale qui donne une fausse impression de mesure. Le chiffre devient ensuite un critère de tri, puis une décision.

Classer les candidats entre eux. Un classement est une décision déguisée. Celui qui est en dernière position ne sera pas lu.

Écarter seul. C'est le point dur. Un filtre automatique produit des faux négatifs structurellement invisibles : le candidat écarté à tort ne se plaint pas, il ignore l'existence du filtre. Aucun signal ne remonte jamais, donc l'erreur ne se corrige jamais.

Inférer ce qui n'est pas écrit. Deviner un âge à partir d'une date de diplôme, une origine à partir d'un nom, une situation familiale à partir d'une interruption de parcours. Un modèle le fait spontanément si on ne le contraint pas, et ces inférences sont exactement les critères prohibés.

L'architecture qui tient

Six règles. Elles se posent au moment de la conception, pas après.

1. Extraire, jamais juger. Le modèle produit des faits vérifiables — « mentionne une certification X », « quatre ans d'expérience déclarés sur ce poste » — pas des appréciations. La pondération des faits est une règle métier écrite par un humain, lisible et modifiable.

2. Citer la source. Chaque fait produit s'accompagne du passage du CV dont il est tiré. Le recruteur vérifie en une seconde, et une invention se voit immédiatement parce que la citation est absente ou ne dit pas ce qui est affirmé.

3. Autoriser « je ne sais pas ». Le mode de défaillance principal d'un modèle est de produire une valeur plausible plutôt que rien. L'instruction doit rendre l'abstention explicitement acceptable, et l'interface doit afficher l'abstention comme un résultat normal, pas comme une erreur.

4. Masquer les champs sensibles. Nom, prénom, adresse, photo, date de naissance, nationalité retirés du texte soumis au modèle. Le traitement porte sur l'expérience et les compétences. Ce masquage ne supprime pas tout risque de biais indirect, mais il retire les signaux les plus directs et il est simple à implémenter.

5. Journaliser. Version du modèle, instruction utilisée, entrée, sortie, horodatage. Sans ce journal, vous ne pouvez ni expliquer une décision passée, ni détecter qu'un changement de version a modifié le comportement du système.

6. Mesurer les faux négatifs. Un échantillon de ce que le système a déclassé doit être relu par un humain, régulièrement. C'est la seule mesure qui compte et c'est celle que personne ne fait. Sans elle, vous ne saurez jamais que le système écarte systématiquement une catégorie de profils.

Le protocole d'évaluation avant mise en production

Le jeu de référence. Cinquante CV dont vous connaissez l'issue réelle : des gens recrutés, des gens rejetés en entretien, des gens rejetés sur dossier. Faites-les passer dans le système et comparez.

Ce que vous cherchez n'est pas « le système retrouve-t-il nos décisions » — s'il y arrive parfaitement, il a appris vos biais. Ce que vous cherchez, c'est : parmi les profils que le système déclasse, y en a-t-il que nous avons recrutés ? Chacun est un faux négatif documenté.

Le test de stabilité. Soumettez deux fois le même CV. Les réponses doivent être identiques ou très proches. Une variation importante d'un passage à l'autre signifie que le système n'est pas déterministe, donc pas défendable : vous ne pourrez pas expliquer pourquoi ce dossier-là a été traité ainsi.

Le test de permutation. Prenez un CV, changez uniquement le prénom pour un prénom d'une autre origine apparente, ou l'adresse pour un autre quartier. Le résultat doit être identique. S'il change, vous avez une preuve de biais direct, et le système ne doit pas être déployé en l'état.

Ces trois tests demandent une demi-journée et constituent la trace qui permettra, le jour où la question se pose, de démontrer que le sujet a été traité.

La question des données

Envoyer un CV à un service tiers est un transfert de données personnelles. Trois points à trancher et à écrire dans le registre des traitements :

• Où tourne le modèle ? Un service hors UE impose un mécanisme de transfert valide.
• Les données sont-elles conservées par le fournisseur ? Certaines formules conservent les requêtes ; d'autres non. C'est une clause contractuelle, pas un réglage.
• Servent-elles à entraîner ? La réponse doit être écrite, et négative.

Un modèle exécuté sur une infrastructure que vous contrôlez supprime ces trois questions, au prix d'une qualité généralement inférieure et d'un coût d'exploitation. Pour une tâche d'extraction factuelle, l'écart de qualité est souvent acceptable ; pour du résumé, il se voit davantage.

Le compromis qui marche

L'usage le plus rentable et le moins risqué d'un modèle de langage sur un flux de candidatures n'est pas le tri : c'est le résumé structuré et la mise en évidence. Cinq lignes de synthèse, les faits vérifiables liés aux critères de l'offre, les passages correspondants surlignés dans le document.

Le recruteur lit tous les dossiers, mais trois fois plus vite. Aucun candidat n'est écarté par la machine, aucun faux négatif invisible n'est possible, et le gain de temps est réel et mesurable. C'est moins spectaculaire qu'un tri automatique, et c'est la seule configuration qui reste défendable à froid.

Questions fréquentes

Un modèle de langage peut-il présélectionner des candidats ?

Il peut préparer la présélection — extraire, résumer, mettre en évidence — mais pas la décider. La distinction n'est pas rhétorique : dans le premier cas un humain voit tous les dossiers, dans le second certains sont écartés sans jamais être lus, et l'erreur ne remonte jamais.

Comment savoir si notre système de scoring est biaisé ?

Par le test de permutation : même CV, prénom ou adresse modifiés, résultat comparé. S'il change, le biais est direct et démontré. S'il ne change pas, cela ne prouve pas l'absence de biais indirect — d'où la nécessité de relire régulièrement un échantillon des profils déclassés.

Faut-il prévenir les candidats qu'un traitement automatisé intervient ?

Oui, l'information sur les traitements mis en œuvre fait partie de vos obligations, et c'est aussi une bonne pratique : une mention claire dans la notice de confidentialité du site carrière suffit. Elle coûte deux phrases et évite d'avoir à s'expliquer dans de mauvaises conditions.

Vaut-il mieux un modèle spécialisé RH ou un modèle généraliste ?

Pour de l'extraction factuelle, un modèle généraliste correctement instruit fait le travail. Les solutions spécialisées apportent surtout un référentiel de compétences et une interface ; elles apportent rarement une meilleure compréhension du texte. Ce qui change vraiment le résultat, c'est la précision de l'instruction et la présence des garde-fous, pas le choix du modèle.

Combien coûte le traitement d'un CV par un modèle de langage ?

À l'unité, une fraction de centime pour une extraction, davantage pour un résumé détaillé. Le coût du service n'est jamais le facteur limitant sur un volume de recrutement normal : ce qui coûte, c'est le temps de conception des instructions, le protocole d'évaluation et la maintenance quand le modèle change de version.