- Blog
- Les erreurs qui font fuir les développeurs en process de recrutement
Les erreurs qui font fuir les développeurs en process de recrutement
- Un process trop long qui tue l'engagement
- Pas de fourchette salariale affichée
- Le test technique hors sol
- Le ghosting post-entretien
- Une offre d'emploi qui ne dit rien
- L'entretien RH qui ne comprend pas la tech
- Trop de décideurs dans le process
- Ne pas vendre le poste au candidat
- L'offre qui arrive trop tard
- Comment diagnostiquer votre process
Le marché IT est un marché de candidats. Les bons développeurs reçoivent entre 5 et 15 sollicitations par semaine sur LinkedIn. Ils ont le choix. Et quand votre process de recrutement contient ne serait-ce qu'une erreur majeure, ils disparaissent — sans vous dire pourquoi.
J'ai été développeur avant de devenir recruteur. J'ai vécu ces process de l'intérieur, subi les tests techniques absurdes, attendu des retours qui ne venaient jamais. Aujourd'hui, côté cabinet, je vois les mêmes erreurs se répéter chez des dizaines d'entreprises. Voici les plus courantes — et comment les corriger.
Un process trop long qui tue l'engagement
C'est l'erreur numéro un. Un process de recrutement qui dure plus de 3 semaines entre le premier contact et l'offre perd la majorité des bons candidats. Chaque semaine supplémentaire, c'est 10 à 15 % de candidats en moins dans le pipeline. Les meilleurs développeurs reçoivent des offres en continu — ils n'attendent pas que vous organisiez votre cinquième round d'entretien.
La solution : trois étapes maximum. Un premier échange de 30 minutes (culture fit + motivations), un entretien technique de 60 à 90 minutes (code ou system design), et un dernier entretien avec le futur manager ou l'équipe. Tout cela en deux semaines. Si votre process a plus de trois étapes, demandez-vous ce que chaque étape supplémentaire apporte réellement. La réponse est souvent : du confort pour le recruteur, de la frustration pour le candidat.
Pas de fourchette salariale affichée
"Salaire selon profil" est la phrase qui fait fuir le plus de développeurs. Dans un marché transparent où les grilles salariales sont accessibles sur Glassdoor, Levels.fyi ou WeLoveDevs, ne pas afficher de fourchette envoie un signal clair : soit l'entreprise paie en dessous du marché et ne veut pas le montrer, soit elle n'a pas fait le travail de calibrage.
Les données sont sans appel : les offres avec fourchette salariale reçoivent 30 à 50 % de candidatures en plus que les offres sans. Et les candidats qui postulent sont mieux alignés, ce qui réduit le temps perdu en entretiens avec des profils hors budget. Affichez une fourchette réaliste, quitte à la rendre large. "50-65k selon expérience" vaut infiniment mieux que "selon profil".
Le test technique hors sol
Un algorithme de tri sur un tableau blanc. Un exercice LeetCode medium qui n'a aucun rapport avec le travail quotidien du poste. Un test à faire chez soi qui prend 8 heures. Ces formats de test technique sont non seulement inefficaces pour évaluer un candidat, mais ils sont activement repoussants pour les profils seniors.
Un développeur senior avec 10 ans d'expérience et un GitHub rempli de projets open source n'a pas envie de prouver qu'il sait inverser une liste chaînée. Ce qu'il veut, c'est un exercice qui ressemble au travail réel : une code review sur un PR existant, un exercice de system design, ou un petit projet qui reflète la stack et les problématiques de l'entreprise. Le test technique doit évaluer la capacité à résoudre des problèmes réels, pas la capacité à passer des tests.
Et surtout : limitez le temps. Un test à faire chez soi ne devrait pas dépasser 2 à 3 heures. Au-delà, vous sélectionnez les candidats qui ont le plus de temps libre, pas les plus compétents.
Le ghosting post-entretien
Un candidat passe deux entretiens, fait un test technique, investit 5 à 6 heures de son temps — et n'a jamais de retour. C'est le ghosting, et c'est beaucoup plus fréquent qu'on ne le croit. Selon les enquêtes terrain, plus de 40 % des candidats IT déclarent avoir été ghostés après un entretien.
L'impact va au-delà du candidat individuel. Un développeur ghosté en parle à ses collègues, publie sur les réseaux, note l'entreprise sur Glassdoor. Votre marque employeur prend un coup dont vous ne mesurez même pas l'ampleur. La règle est simple : chaque candidat qui passe un entretien mérite un retour, même négatif, dans un délai de 5 jours ouvrés maximum. Un email de deux phrases suffit.
Une offre d'emploi qui ne dit rien
"Vous êtes passionné par le code et aimez travailler en équipe dans un environnement dynamique et bienveillant." Cette phrase ne dit rien. Elle est dans la moitié des offres d'emploi IT en France. Un développeur qui lit cette annonce n'apprend rien sur le poste, la stack, les projets, les enjeux.
Ce que veulent les développeurs dans une offre : la stack technique précise (versions incluses), la taille de l'équipe, la méthodologie (Scrum, Kanban, Shape Up), le type de produit, les défis techniques concrets, la politique de remote, et la fourchette salariale. Tout le reste est du bruit. Une offre bien rédigée attire les bons profils et repousse les candidatures non pertinentes — c'est du temps gagné pour tout le monde.
L'entretien RH qui ne comprend pas la tech
Quand un recruteur RH pose des questions génériques ("Où vous voyez-vous dans 5 ans ?", "Quel est votre plus grand défaut ?") à un développeur, le signal est immédiat : cette entreprise ne comprend pas les profils tech. Les développeurs veulent parler de code, d'architecture, de produit — pas répondre à des questions tirées d'un manuel de management des années 90.
La solution n'est pas de supprimer le filtre RH, mais de le rendre pertinent. Un premier échange RH efficace aborde la motivation pour le poste spécifique, les attentes en termes de remote et de rémunération, et le contexte de changement du candidat. Il dure 20 à 30 minutes, pas une heure. Et idéalement, le recruteur a un minimum de culture technique pour ne pas confondre React et React Native.
Trop de décideurs dans le process
"Il faut que vous rencontriez le CTO, le lead dev, le PM, le VP Engineering et le CEO." Cinq entretiens pour un poste de développeur senior, c'est un signal d'alarme pour le candidat. Cela signifie que l'entreprise ne fait pas confiance à ses managers pour prendre des décisions de recrutement, ou que la structure décisionnelle est floue.
Chaque personne ajoutée au process ajoute du délai (coordination des agendas), de la complexité (avis contradictoires) et du risque de perte de candidat. Deux à trois personnes maximum doivent être impliquées dans la décision finale. Les autres peuvent rencontrer le candidat de manière informelle après l'offre, lors d'un déjeuner d'équipe par exemple.
Ne pas vendre le poste au candidat
Beaucoup d'entreprises abordent l'entretien comme un examen que le candidat doit passer. Elles oublient que le candidat, lui aussi, évalue l'entreprise. Dans un marché où les développeurs ont le choix, l'entretien est une vente bilatérale. Le candidat doit se vendre, mais l'entreprise aussi.
Ce que les développeurs veulent entendre en entretien : les défis techniques concrets du poste, la vision produit à 12 mois, la culture engineering (code review, tests, déploiement continu), les possibilités d'évolution technique, et le quotidien réel de l'équipe. Les entreprises qui présentent ces éléments de manière authentique convertissent significativement mieux leurs candidats.
L'offre qui arrive trop tard
Le candidat a passé tous les entretiens, le test technique est réussi, tout le monde est aligné — mais il faut "attendre la validation de la direction" ou "finaliser le budget". Chaque jour de délai entre le dernier entretien et l'offre augmente le risque de perdre le candidat. Les bons développeurs n'attendent pas. Ils ont d'autres process en cours.
La bonne pratique : le budget et la fourchette salariale doivent être validés avant de lancer le process, pas après. L'offre doit pouvoir être formulée dans les 48 heures suivant le dernier entretien. Si vous ne pouvez pas le faire, votre process interne a un problème que le candidat ne devrait pas subir.
Comment diagnostiquer votre process
Mesurez trois indicateurs. Le taux de conversion candidat (pourcentage de candidats qui vont au bout du process) : s'il est inférieur à 30 %, votre process a un problème. Le délai moyen entre premier contact et offre : s'il dépasse 3 semaines, c'est trop long. Le taux d'acceptation des offres : s'il est inférieur à 70 %, vos offres ne sont pas compétitives ou arrivent trop tard.
Pour identifier vos angles morts en 3 minutes, faites notre quiz de maturité recrutement (10 questions, plan d'action personnalisé) :
👉 novera-talent.com/outils/quiz-recrutement-it
Et si vous perdez régulièrement des candidats en cours de process, documentez-les avec notre tracker post-mortem — le pattern dominant émerge dès 3 entrées :
👉 novera-talent.com/outils/post-mortem-candidat
Et pour mesurer concrètement ce que coûte chaque erreur en euros (les 7 postes de coût, du salaire chargé à la productivité d'équipe perdue), notre calculateur gratuit :
👉 novera-talent.com/outils/cout-mauvais-recrutement
Chez Novera Talent, nous auditons les process de recrutement de nos clients avant de commencer à sourcer. Parce que trouver les bons candidats ne sert à rien si le process les fait fuir. Contactez-nous si vous voulez optimiser votre process de recrutement tech.
Questions fréquentes
Combien de temps doit durer un process de recrutement développeur ?
Un process efficace ne dépasse pas 2 à 3 semaines entre le premier contact et l'offre. Trois étapes maximum : un échange de 30 minutes (culture fit), un entretien technique de 60 à 90 minutes, et un dernier entretien avec le manager ou l'équipe. Au-delà, vous perdez 10 à 15 % de candidats par semaine supplémentaire.
Faut-il afficher le salaire dans une offre développeur ?
Oui, systématiquement. Les offres avec fourchette salariale reçoivent 30 à 50 % de candidatures en plus. Affichez une fourchette réaliste (par exemple 50-65k selon expérience) plutôt que 'selon profil', qui est perçu comme un signal négatif par les candidats tech.
Quel type de test technique utiliser pour recruter un développeur ?
Privilégiez les exercices qui reflètent le travail réel : code review sur un PR, exercice de system design, petit projet sur la stack de l'entreprise. Évitez les algorithmes sur tableau blanc et les exercices LeetCode déconnectés du poste. Limitez le temps à 2-3 heures maximum pour les tests à domicile.
Comment éviter le ghosting des candidats ?
Règle simple : chaque candidat qui passe un entretien reçoit un retour (même négatif) dans les 5 jours ouvrés. Un email de deux phrases suffit. Le ghosting détruit votre marque employeur — les candidats ghostés en parlent à leurs collègues et publient sur Glassdoor.
Combien de personnes doivent participer au process de recrutement ?
Deux à trois personnes maximum pour la décision finale. Chaque personne ajoutée au process ajoute du délai et de la complexité. Les autres membres de l'équipe peuvent rencontrer le candidat de manière informelle après l'offre, lors d'un déjeuner d'équipe par exemple.