Career Quest — Évaluation des compétences → recommandations d'emploi

En bref

Career Quest est la plateforme d'orientation professionnelle que j'ai construite pendant mon stage chez Guidya, comme développeur principal d'une équipe de trois avec Aymane Bouras et Yassine Mchereg. L'entreprise apportait les besoins métier et l'encadrement ; nous les avons transformés en fonctionnalités.

Un candidat passe des évaluations — cognitives, situationnelles, techniques — et en obtient un profil d'employabilité et des recommandations d'emploi. Notre réalisation a remporté la 1ʳᵉ place au concours des stages de l'EMSI.

Le problème

Un CV dit ce qu'une personne a étudié, pas ce qu'elle sait faire. La plateforme devait mesurer la seconde chose et la rendre exploitable : quels postes correspondent à cette personne, et pourquoi.

Cela se découpe en deux problèmes qui tirent dans des directions opposées. Le score doit être défendable — les mêmes résultats bruts ne doivent pas classer un futur chef de produit comme un futur ingénieur logiciel, et un candidat à qui l'on dit qu'il correspond moins bien à un poste mérite une raison. La recommandation doit fonctionner pour quelqu'un inscrit il y a cinq minutes, sans aucun historique, comme pour quelqu'un que le système connaît bien.

Architecture

Une interface React au-dessus d'une API Django REST, avec le moteur de tests, le calcul des scores et les recommandations en modules distincts.

Évaluations. Six types de tests cognitifs — raisonnement verbal, numérique, logique, abstrait, spatial et diagrammatique — plus le jugement situationnel et des épreuves techniques, chacun joué en session chronométrée par le moteur de tests.
Score. Chaque question porte un coefficient de difficulté, de 1,0× pour une question facile à 2,5× pour une question experte. Les résultats sont agrégés par dimension, pondérés selon le profil visé et ramenés sur une échelle de 0 à 100.
Les recommandations combinent un filtrage par contenu sur les compétences et les exigences, un filtrage collaboratif dès qu'il y a un historique dont apprendre, la similarité cosinus pour l'appariement et un clustering K-Means pour segmenter les candidats.
L'API est authentifiée par JWT et décrite par un schéma OpenAPI généré depuis le code. PostgreSQL conserve tout ce qui doit durer, Redis sert de cache à Django, et Celery exécute les calculs de recommandation qui ne doivent pas bloquer une requête.

Décisions & compromis

Les pondérations appartiennent au poste, pas au candidat

Un score global unique aurait été plus simple, et faux. Le profil ingénieur logiciel pondère les résultats techniques à 35 % et la communication à 5 % ; le profil chef de produit inverse presque tout, avec le jugement situationnel en tête. Les mêmes résultats donnent une adéquation différente pour chaque poste — et comme chaque pondération est explicite et nommée, chaque score se retrace jusqu'à une dimension et un chiffre. Un score sur lequel un candidat peut poser une question, et obtenir une vraie réponse, est le seul qui mérite de lui être montré.

Un système hybride, à cause du premier jour

Le filtrage collaboratif est la moitié puissante — il trouve les postes où des candidats qui vous ressemblent ont réussi — mais il lui faut un historique, et un nouveau candidat n'en a pas. Le filtrage par contenu n'a besoin que des résultats du candidat lui-même : il répond dès la première visite. Les combiner, c'est avoir des recommandations utiles tout de suite et qui s'améliorent à mesure que la plateforme apprend, au lieu d'être vides en attendant d'être bonnes.

Le contrat de l'API est généré, pas rédigé

À trois développeurs, le contrat entre le front et le back est ce qui permet de travailler en parallèle. Générer la description OpenAPI depuis le code Django empêchait la documentation de s'écarter de l'implémentation : le front se construisait contre ce que l'API faisait réellement, pas contre ce qu'on se rappelait qu'elle faisait.

Ce qui a été difficile

Travailler sur un vrai produit avec d'autres personnes. Trois développeurs sur une même base de code, face à la feuille de route d'une entreprise plutôt qu'à un sujet d'école : il fallait s'accorder sur les interfaces avant de construire derrière, relire le travail des autres et décider ensemble de ce qu'on abandonnait. Nous avons abandonné des fonctionnalités, et livré le reste.

C'était aussi la première fois que je dirigeais d'autres développeurs : découper le travail pour que trois personnes avancent en parallèle sans se marcher dessus, et prendre en charge les parties qui reliaient leurs morceaux.

Résultat

La 1ʳᵉ place au concours des stages de l'EMSI, et une plateforme que l'entreprise pouvait mettre entre les mains de candidats : des évaluations cognitives, situationnelles et techniques, un score qui s'explique, et des recommandations dès la première visite.

La suite

Consolider le système de recommandation. À force d'itérer vite en équipe, plusieurs générations cohabitent dans le code — un service de base, un « enhanced » et un « advanced » — et une seule version dotée d'une évaluation hors ligne vaudrait mieux que trois sans. Cette évaluation est la vraie prochaine étape : mettre de côté des candidats dont on connaît le poste final, et mesurer combien de fois les recommandations les auraient trouvés.

Le dépôt porte aussi encore le nom d'origine du stage et quelques fichiers d'environnement versionnés par erreur ; le nettoyage est en retard.