Recruter un développeur : la méthode, la fiche de poste et la grille de scoring

Le cadrage technique ne s’improvise pas seul devant une feuille blanche. Asseyez-vous une heure avec la personne qui encadrera le poste — développeur en interne, directeur technique, prestataire — et faites-lui décrire ce que la nouvelle recrue fera pendant ses trois premiers mois. Pas les technologies : les tâches. Reprendre une application existante mal documentée, construire une nouvelle fonctionnalité de zéro ou fiabiliser une base fragile ne demandent pas les mêmes qualités.

Séparez ensuite deux choses que les annonces mélangent constamment : la stack et les fondamentaux. La stack, ce sont les outils du moment — un langage, un framework, une base de données, un hébergeur. Les fondamentaux, ce sont la capacité à structurer du code lisible, à comprendre un système existant, à raisonner sur un bug, à tester et à travailler avec d’autres. Un développeur solide change de framework en quelques semaines ; l’inverse n’est pas vrai.

Décidez donc explicitement de ce qui est éliminatoire. Sur une équipe d’une seule personne qui doit être opérationnelle immédiatement sur un code existant, exiger le langage exact se défend. Dans une équipe où quelqu’un peut accompagner l’arrivée, exiger la stack complète vous prive de la majorité des bons candidats pour un gain de quelques semaines. Le piège classique est la liste de dix technologies obligatoires, qui décrit une équipe entière et non un poste.

Terminez par le contexte, que les développeurs lisent avant tout le reste : quel produit, quels utilisateurs, quelle taille d’équipe, quelle part de code existant, quel niveau de dette technique. Un candidat expérimenté juge un poste là-dessus. Le cacher ne vous protège pas, cela vous fait simplement perdre les meilleurs au deuxième entretien.

Une fiche de poste développeur se juge en dix secondes, et sur des critères précis : que fait le produit, avec quoi il est construit, dans quelle équipe, et est-ce qu’on m’explique honnêtement l’état du code. Une annonce qui parle d’« environnement stimulant » et d’« esprit start-up » sans décrire une seule ligne du travail réel sera ignorée par ceux que vous voulez attirer.

Nommez la stack avec précision, mais distinguez visuellement ce qui est indispensable de ce qui est un plus. Écrire « TypeScript et React au quotidien ; PostgreSQL et Docker, que vous pouvez découvrir ici » vous ouvre à des candidats que « TypeScript, React, PostgreSQL, Docker, Kubernetes, AWS, CI/CD » aurait fait fuir. Le second paragraphe décrit une équipe, pas un poste.

Décrivez aussi la façon de travailler : revues de code, tests, mises en production, astreintes éventuelles, télétravail réel. Et indiquez une fourchette de rémunération avec la structure du package : sur ces profils, une annonce sans fourchette est souvent écartée d’emblée. Pour situer la vôtre, appuyez-vous sur les études de l’APEC et sur les données de France Travail plutôt que sur une moyenne entendue en conférence.

Les développeurs sont sollicités en permanence et répondent surtout à ce qui les intéresse. Une annonce générique sur un jobboard généraliste produit peu de résultats ; la même annonce, précise sur le produit et la stack, sur un site spécialisé, en produit nettement plus. Commencez donc par soigner le texte avant de multiplier les canaux : c’est l’investissement le plus rentable.

Les communautés techniques et les jobboards spécialisés sont le premier canal utile. L’approche directe sur les réseaux professionnels fonctionne aussi, à condition d’écrire un message qui montre que vous avez lu le profil : un message type reçu pour la dixième fois de la semaine ne reçoit pas de réponse. Mentionnez le produit, la stack et la fourchette dès le premier message, cela fait gagner du temps à tout le monde.

N’oubliez pas les candidatures spontanées et les CVthèques, notamment pour les profils juniors et les personnes en reconversion, qui ne sont pas sollicitées de la même manière. Sur un poste junior que vous acceptez d’accompagner, les écoles et les organismes de formation constituent un vivier direct et souvent sous-utilisé.

Ces huit questions ne demandent pas d’être développeur pour être posées, ni pour être exploitées. Elles cherchent la même chose : la capacité du candidat à expliquer son travail à quelqu’un qui n’est pas du métier, et la trace de décisions réelles dans son parcours. Un développeur expérimenté sait vulgariser ; un candidat qui ne peut décrire son projet qu’en jargon a souvent un problème de recul, parfois un problème de fond.

Gardez l’évaluation proprement technique pour une étape dédiée, menée par quelqu’un du métier. Un test court et représentatif du travail réel — quelques heures au maximum, ou une revue de code existant — en dit bien plus qu’un exercice d’algorithmique chronométré, et respecte le temps du candidat.

La première erreur, et de loin la plus coûteuse, est le tri par mots-clés. Chercher un terme exact dans une pile de CV valide le candidat qui a listé quinze technologies sans en maîtriser trois, et écarte celui qui a écrit « Next.js » quand vous cherchiez « React », ou « Symfony » quand vous cherchiez « PHP ». Une lecture qui comprend le contexte évite les deux erreurs : elle voit qu’un expert React connaît nécessairement JavaScript, et qu’une technologie citée dans une liste sans jamais réapparaître dans les expériences n’a probablement jamais été pratiquée.

La deuxième erreur est la liste de technologies obligatoires trop longue. Elle donne l’impression d’être exigeant ; elle signale surtout que le besoin n’a pas été cadré. Trois technologies réellement éliminatoires suffisent presque toujours, et cela multiplie le nombre de candidatures pertinentes.

La troisième erreur est le test technique disproportionné. Un exercice de plusieurs jours, non rémunéré et sans rapport avec le travail réel, fait abandonner les candidats qui ont le choix — c’est-à-dire ceux que vous vouliez. Gardez un test court, représentatif, et annoncez sa durée dès le premier échange.

La quatrième erreur est de juger sur le diplôme ou l’école plutôt que sur le travail produit : beaucoup d’excellents développeurs sont autodidactes ou viennent d’une reconversion. Et un rappel qui vaut pour tout ce guide : vos critères de sélection doivent porter uniquement sur les compétences et l’expérience professionnelle, jamais sur l’âge, le sexe, l’origine, la situation de famille, l’état de santé ou le lieu de résidence.

Appliquer cette grille à la main sur cinquante CV techniques est un travail long et, surtout, inégal : le vingtième CV de la journée n’est pas lu avec l’attention du troisième, et les parcours atypiques — reconversions, autodidactes, profils venus d’une stack voisine — en font les frais les premiers.

ResumeRank fait ce travail à votre place. Vous collez votre fiche de poste, l’outil lit chaque CV en une trentaine de secondes et lui attribue un score sur 100 par rapport à cette fiche, avec le détail des cinq critères et une justification écrite. L’analyse tient compte du contexte plutôt que de la présence littérale d’un terme : une expérience longue sur un framework vaut plus qu’une technologie citée une fois dans une liste. Les pondérations sont réglables poste par poste ; pour un développeur, les compétences techniques portent l’essentiel du score, comme dans le tableau ci-dessous.

Vous récupérez un classement, une synthèse par candidat et des questions d’entretien générées à partir de ses zones d’ombre — utiles à transmettre à la personne qui mènera l’évaluation technique. Sur le tri, les recruteurs qui utilisent l’outil récupèrent environ huit des dix heures qu’ils y passaient chaque semaine. Le score hiérarchise la pile ; il ne remplace ni le test technique ni votre décision.