Et si les données du recrutement répondaient à nos questions ?

Piloter un recrutement, c'est une boucle : mesurer (KPI), repérer ce qui bloque, agir, puis mesurer à nouveau. Notre groupe a construit la partie « mesure » de l'application HackAVP : un tableau de bord Power BI branché sur l'API, et des données qui en disent long.
🛣️ Track : SaaS no limit (une chaîne de services reliés par des standards : API REST, modèle de langage appelé par API, tableau de bord Power BI).

🎓 Hackathon HackAVP · Master MIAGE · groupe Insight Squad · profils fictifs.

Certaines offres d'emploi ne trouvent jamais de candidat. Pas parce qu'elles sont mauvaises, mais parce que personne ne voit qu'elles sont ignorées. Or ce qu'on ne voit pas, on ne le corrige pas.

Dès qu'une offre ignorée apparaît sur un écran, l'action devient évidente : la relancer sur les réseaux sociaux, la remettre en avant dans la communication interne, retoucher son titre. Puis on regarde si les candidatures remontent. Mesurer, agir, mesurer encore : c'est ça, piloter.

🎯 Le défi : une offre publiée n'est pas une offre trouvée

L'OPT-NC, un employeur d'environ 1 000 personnes réparties sur 12 familles de métiers, publie ses avis de vacance de poste (AVP) depuis des années. Entre l'offre et le candidat, il reste des sites peu confortables sur mobile, un vocabulaire administratif qui décourage, et des recherches qui ne comprennent pas ce que le candidat sait faire.

HackAVP, présenté comme le premier hackathon consacré à l'emploi dans la fonction publique calédonienne, laisse sept semaines pour construire ce qui manque entre les deux. Il est co-organisé par l'OPT-NC, la Station N et la commission Data & IA d'OPEN NC. Quatre fonctions sont imposées : faire entrer un profil, le confronter aux offres ouvertes, produire les pièces de candidature, transmettre le dossier.

Notre promotion de Master MIAGE a répondu par une application façon « Tinder » 👉 : le candidat fait glisser une offre vers la droite pour postuler, le recruteur répond de la même façon, et la candidature est validée quand il dit oui à son tour. Chaque groupe a pris une partie de l'application. La nôtre : le pilotage.

📈 Notre part : savoir si ça marche

Une application ne suffit pas, il faut savoir si elle fonctionne. Notre tableau de bord Power BI s'adresse aux RH et aux managers : il montre ce qui marche, ce qui bloque et ce qu'il faut corriger. C'est la double compétence de la MIAGE en pratique : l'informatique pour fiabiliser les données, la gestion pour les transformer en décisions.

🔧 D'où viennent les données ?

• Les offres viennent de l'open data de l'OPT-NC : le jeu de données AVP sur data.gouv.nc, que l'OPT expose aussi par une API des AVP et un dataset Hugging Face. Elles sont importées dans l'API de notre application.
• Les familles de métiers et les codes ROME correspondent au référentiel des métiers de l'OPT-NC.
• Les candidats, swipes et décisions sont des profils fictifs, comme l'exige le règlement du hackathon.

Le tableau de bord se connecte à l'API comme le ferait un utilisateur et écarte noms et e-mails dès l'import. Nous avons renoncé aux indicateurs sans données fiables, comme le score de matching : un chiffre douteux trompe plus qu'il n'éclaire.

🔍 Le tableau de bord en action

Ces constats viennent de profils fictifs : ils montrent ce que l'outil permet de voir, pas l'état réel du recrutement.

• 🚪 Certaines offres ne reçoivent aucune candidature, et d'autres ne sont même jamais vues. 💡 Solution : relancer leur diffusion (réseaux sociaux, communication interne), revoir leur rédaction, puis vérifier sur le tableau de bord que les candidatures remontent.
• 📄 Beaucoup de candidats s'inscrivent sans compléter leur CV. 💡 Solution : simplifier la création du profil.
• ⏱️ Une partie des candidatures attend encore une réponse du recruteur. 💡 Solution : raccourcir les délais de traitement.
• ⚖️ Les candidats likent beaucoup plus d'offres que les recruteurs n'en valident. 💡 Solution : clarifier les attentes dès la rédaction de l'offre.

💬 La suite : un assistant pour discuter avec ses données

Imaginons un manager qui prépare sa réunion du lendemain. Il est 18 h 🕕, il veut savoir combien de candidatures attendent encore une réponse, et la DRH n'est pas disponible. Il ouvre un chat et pose sa question comme à un collègue. L'assistant consulte les chiffres de l'application et répond en quelques secondes ⚡. Si le manager lui demande l'adresse e-mail d'un candidat, il refuse poliment 🙅 : il ne manipule que des chiffres.

Comment c'est construit. Un petit service web (Python, FastAPI, environ 150 lignes) reçoit la question et la transmet à un modèle de langage, en lui décrivant trois « outils » : compter les candidatures, les offres, ou une ressource. Le modèle choisit l'outil, le service interroge l'API REST de l'application avec un compte en lecture seule et ne renvoie que des compteurs. Le modèle rédige alors la réponse en une phrase.

Pourquoi c'est simple à mettre en œuvre. Tout repose sur des standards d'interopérabilité : une API REST documentée avec Swagger, des échanges en JSON, un accès par jeton et l'appel d'outils du modèle. Un seul fichier, un seul point d'entrée, et un test possible depuis une page Swagger. Notre chaîne assemble des services en ligne (une API REST, un modèle de langage appelé par API) sans les coupler : chacun peut être remplacé sans toucher aux autres.

Et demain : MCP. Ces outils sont de simples fonctions : elles peuvent être exposées via MCP (Model Context Protocol), le standard ouvert qui permet de brancher les mêmes outils sur n'importe quel assistant compatible. L'OPT-NC propose d'ailleurs un serveur MCP pour ses AVP.

Le prototype est écrit ; le brancher sur la vraie API est notre prochaine étape.

✅ En bref

Repérer un problème, construire, tester, corriger, présenter : en quelques semaines, nous avons suivi le chemin d'un créateur d'entreprise 🚀. Des données bien lues ne remplacent pas le recruteur. Elles l'aident à mieux décider.