🎓 Hackathon HackAVP · Master MIAGE · groupe Insight Squad ·
📊 #HACKAVP : Et si les données du recrutement répondaient à nos questions ?
*Voici une vidéo explicative pour résumer cet article : *
Piloter un recrutement, c'est une boucle : mesurer (KPI), repérer ce qui bloque, agir (en planifiant une action ou en l'automatisant), puis mesurer à nouveau. Notre groupe a construit la partie « mesure » de l'application HackAVP : un tableau de bord Power BI branché sur l'API de notre application, et des données qui en disent long.
🛣️La track utilisée: SaaS no limit (une chaîne de services reliés par des standards : API REST, tableau de bord Power BI en ligne, et demain un modèle de langage appelé par API).
👁️ L'angle mort : les offres que personne ne voit
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.
C'est le cœur de notre projet : rendre visible l'invisible. 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. Et quand une action revient toujours dans les mêmes conditions, on peut la planifier, voire l'automatiser : c'est ce qui transforme un tableau de bord qu'on regarde en cockpit qui travaille.
🎯 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 du Master MIAGE en pratique :
💻 l'informatique pour fiabiliser les données ;
📊 la gestion pour les transformer en décisions.
📚 Quels indicateurs, et pourquoi ?
Pour ne pas choisir nos indicateurs au hasard, nous nous sommes inspirés de deux référentiels RH :
ISO 30414, la norme internationale du reporting RH. Elle dit quelles données mesurer sur ses ressources humaines et comment les présenter, en interne comme en externe. Un de ses domaines est le recrutement, la mobilité et la rotation du personnel : c'est celui qui nous concerne.
ISO/TS 30411, une spécification technique qui définit comment mesurer la qualité d'une embauche : le nouvel arrivant répond-il aux attentes fixées avant son recrutement ? Notre application s'arrête à la candidature, donc nous ne pouvons pas encore la mesurer : elle reste notre horizon.
Chaque indicateur a ensuite été classé (issu d'une norme, pratique RH courante, ou spécifique au projet), puis gardé, corrigé ou retiré, avec sa justification. Nous nous en sommes inspirés, sans prétendre à une conformité.
🔧 D'où viennent les données ?
Les offres : un gros travail de préparation de l'OPT-NC. L'OPT-NC ne se contente pas de publier ses avis de vacance de poste : elle les a préparés pour qu'on puisse s'en servir, avec des données propres, normalisées et documentées. Elles sont disponibles de plusieurs façons : le jeu de données AVP sur data.gouv.nc, une API des AVP, un dataset Hugging Face et un serveur MCP, le tout avec un référentiel des métiers. Des données propres et disponibles : c'est ce travail en amont qui a rendu possible tout ce que nous avons construit.
Les offres sont donc réelles : ce sont les AVP de l'OPT-NC, importés dans l'API de notre application.
Les familles de métiers et les codes ROME viennent du référentiel des métiers de l'OPT-NC.
Les candidats, swipes et décisions sont fictifs, comme l'exige le règlement du hackathon.
Deux API à ne pas confondre. Il y a l'API de l'OPT-NC, qui fournit les offres, et l'API de notre application HackAVP, développée par un camarade de la promo : elle importe ces offres, et stocke les candidats, les swipes et les décisions. Notre tableau de bord se connecte à cette seconde 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.
🔗 Un cas d'école d'interopérabilité
Quatre systèmes qui ne se connaissent pas : l'open data de l'OPT-NC, l'API de notre application, Power BI et, demain, un assistant. Ils se parlent grâce à des standards : une API REST documentée avec Swagger, des échanges en JSON, un accès par jeton. Aucun n'est couplé aux autres : on peut remplacer l'un sans toucher aux autres. C'est le cœur de l'interopérabilité des systèmes d'information, et c'est ce qui a rendu le projet réalisable avec peu de moyens.
🔍 Le tableau de bord en action
Les offres sont réelles, mais les candidats, les swipes et les décisions sont fictifs : notre plateforme a été alimentée avec des données de test pour générer de l'activité. Ces constats reflètent donc ce qui se passe sur notre plateforme, pas l'état réel du recrutement à l'OPT-NC.
🚪 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.
⚙️ De la mesure à l'action : planifier ou automatiser
Un indicateur qui ne déclenche rien finit par ne plus être regardé. Notre démarche tient en trois temps : on mesure, on remarque, puis on agit, soit en planifiant une action (une relance prévue au calendrier), soit en l'automatisant.
L'automatisation tient dans une règle simple : si un indicateur passe sous un seuil, alors une action se déclenche. Par exemple : si le nombre de candidatures par offre passe sous 5, une alerte part vers l'équipe communication, avec le lien vers la liste des offres à relancer. Plus besoin d'attendre que quelqu'un ouvre le tableau de bord et remarque le problème.
Avec notre chaîne, c'est une piste réaliste : Power BI Service peut déclencher une alerte quand une carte, un KPI ou une jauge franchit un seuil à l'actualisation des données (chez nous, chaque jour), et Power Automate peut enchaîner une action (e-mail, message, tâche). Nous ne l'avons pas encore mis en place : c'est, avec l'assistant, la suite logique.
💬 La suite logique : 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 notre 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.
Pas encore réalisé, mais simple à faire. Faute de temps, nous n'avons pas construit cet assistant. C'est pourtant la suite logique du tableau de bord, et nous estimons qu'il se met en place en une demi-journée.
Comment nous le construirions. Un petit service web (Python, FastAPI, environ 150 lignes d'après notre esquisse) recevrait la question et la transmettrait à un modèle de langage, en lui décrivant trois « outils » : compter les candidatures, les offres, ou une ressource. Le modèle choisirait l'outil, le service interrogerait l'API REST de notre application avec un compte en lecture seule et ne renverrait que des compteurs. Le modèle rédigerait alors la réponse en une phrase.
Pourquoi c'est simple. 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. La chaîne assemblerait des services (API REST, Power BI Service, modèle de langage appelé par API) sans les coupler : chacun peut être remplacé sans toucher aux autres.
Et ensuite : 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.
Notre prochaine étape : construire cet assistant et le brancher sur notre application.
✅ 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, et quand l'action devient une routine, à la déclencher toute seule.
