Comment construire un matching de recrutement grâce à l’IA basé sur les projets livrés plutôt que sur les mots-clés
Le tri de CV par mots-clés a un problème de fond : il mesure la déclaration, pas la réalité. Sur ce post, je détaille le raisonnement produit et technique derrière une approche différente qui pourrait être utilisée par une plateforme de recrutement spécialisée en IA (LLM, MLOps, Data Science, Computer Vision, AI Safety) en France ou ailleurs.
Le problème avec le matching par mots-clés
Un ATS classique fonctionne à peu près comme un moteur de recherche full-text sur un CV : il cherche des occurrences de termes (« Python », « Kubernetes », « RAG », « fine-tuning ») et score le profil en fonction du nombre de matchs.
Deux limites structurelles :
- Aucune vérification de la profondeur. « RAG » peut désigner un pipeline en production servant des milliers de requêtes par jour, ou un exemple copié depuis la doc LangChain. Le mot-clé ne fait pas la différence.
- Un jeu à somme nulle pour les candidats. Dès que le marché comprend que le tri se fait sur des mots-clés, l’incitation rationnelle est de maximiser leur densité — ce qui dégrade le signal pour tout le monde, recruteurs compris.
Une alternative : indexer sur les livrables, pas sur le vocabulaire
L’idée derrière l’approche consiste à restructurer le profil candidat autour de projets réellement livrés plutôt que d’une liste de compétences déclarées :
- Contexte du projet : quel problème, quelle contrainte de production (charge, latence, budget)
- Stack réellement utilisée, pas la stack « connue »
- Rôle exact de la personne dans le projet (contributeur vs responsable technique)
- Résultat mesurable quand c’est disponible (mise en prod, adoption, métriques)
Ce type de structuration change fondamentalement ce qui est comparable entre deux candidats. Deux profils qui citent tous les deux « MLOps » ne sont plus interchangeables si l’un a mis en place un pipeline CI/CD de modèles avec monitoring de drift en production, et l’autre a suivi une formation théorique.
Ce que ça implique côté architecture de matching
D’un point de vue systèmes, ça pousse vers un modèle de matching en deux couches plutôt qu’un simple scoring lexical :
- Couche de structuration : extraction et normalisation des projets déclarés (stack, rôle, contexte, résultat) — un travail proche du NLP d’extraction d’entités plutôt qu’un simple TF-IDF sur mots-clés.
- Couche de matching sémantique : comparaison entre les besoins réels d’une offre (pas seulement son titre) et les projets structurés du candidat, avec une pondération qui favorise la correspondance de contexte de production plutôt que la simple présence d’un terme.
C’est plus coûteux à construire qu’un matcher par mots-clés classique, mais le signal produit est beaucoup plus difficile à gamer — on ne peut pas « spammer » un projet livré de la même façon qu’on spamme une liste de compétences.
Pourquoi ça compte particulièrement en IA
Le secteur IA est probablement celui où ce problème est le plus aigu en ce moment. L’explosion du vocabulaire (« agentic », « RAG », « fine-tuning », « AI Safety ») s’est faite plus vite que la capacité du marché à vérifier qui maîtrise réellement ces sujets en production. Un matching indexé sur les projets livrés, avec une spécialisation par sous-domaine (LLM & GenAI, MLOps, Research Engineering, Computer Vision), réduit mécaniquement ce bruit — pour les recruteurs comme pour les candidats qui ont un vrai historique à montrer.
Une telle plateforme centraliserait les offres IA au niveau national (LLM, MLOps, Data Science, Computer Vision, AI Safety) avec un matching basé sur les projets livrés plutôt que sur les mots-clés déclarés.