Comment évaluer les compétences techniques d’un candidat

Un CV bien rédigé et un candidat à l’aise à l’oral ne prouvent pas un niveau technique. Un fondateur ou un responsable RH qui recrute un développeur, un data engineer ou un DevOps risque alors de juger l’assurance plutôt que la compétence. Le discours peut être fluide alors que la maîtrise de la stack ou la qualité du code restent invisibles.

La méthode tient en trois temps. Vous fixez d’abord une scorecard en amont, avant le premier entretien. Vous menez ensuite un échange technique structuré et proposez un exercice proche du travail réel. Si vous n’êtes pas technique, vous ajoutez l’avis d’un pair.

Mal dosée, cette évaluation fait fuir les meilleurs profils ou laisse passer ceux qui ne tiendront pas le poste.

Que faut-il évaluer avant de rencontrer le candidat ? La scorecard technique

Pour évaluer les compétences techniques d’un candidat, l’essentiel se décide avant le premier entretien. Une scorecard technique fixe ce qu’on évalue, le poids de chaque critère et le niveau attendu. Le recruteur et le lead technique notent ensuite sur la même grille, ce qui rend les avis comparables d’un candidat à l’autre.

Un écart de niveau se voit vite en production. D’où l’intérêt de fixer des critères avant de rencontrer qui que ce soit. Pour construire la grille pas à pas, voir notre guide pour créer une scorecard de recrutement. Elle repose ici sur quatre axes :

• Stack et langages : maîtrise réelle des outils du poste.
• Architecture et scalabilité : capacité à concevoir un système qui tient la charge.
• Qualité du code et livraison : tests, revue, déploiement.
• Culture d’engineering : documentation, dette technique, collaboration.

Voici un exemple pour un développeur backend confirmé :

Une grille complète existe dans notre scorecard développeur back end, à télécharger et à adapter. Les autres métiers tech ont la leur dans la bibliothèque de scorecards.

Formulez chaque critère en comportement observable. « Sait expliquer pourquoi il a choisi PostgreSQL plutôt que MongoDB » se note. « Bon en base de données » ne se note pas.

Les pondérations bougent avec le poste. Un rôle d’infrastructure fait monter l’architecture. Une équipe qui a accumulé beaucoup de dette technique renforce la qualité du code. Une fois les critères posés, il reste à choisir les méthodes qui permettent de les observer.

Quelles méthodes utiliser pour évaluer les compétences techniques d’un candidat ?

Un candidat brillant en entretien peut échouer sur un exercice simple, et l’inverse arrive aussi. Aucune méthode ne suffit seule : chacune mesure une partie des compétences et n’en mesure pas d’autres.

Le tableau compare les huit plus courantes. Les durées sont des ordres de grandeur, à adapter au poste.

Les premières lignes servent à filtrer. Elles ne suffisent pas pour décider. Un GitHub vide ne dit rien d’un développeur qui code depuis des années sur des dépôts privés en entreprise, et un dépôt actif peut très bien contenir du code copié.

Le reste se partage en deux familles. Le system design, le pair programming et la code review montrent le raisonnement du candidat, sa façon de penser et d’arbitrer. Le test automatisé et l’exercice à rendre montrent plutôt ce qu’il produit. Associez donc au moins une méthode de chaque famille.

Des plateformes proposent des tests automatisés clés en main. Leur limite commune tient à ce qu’elles mesurent : la résolution d’exercices calibrés, rarement la capacité à reprendre une codebase écrite par d’autres. La bonne combinaison dépend surtout du niveau du poste.

Quelle combinaison de méthodes choisir selon le niveau du poste ?

Plus le poste est senior, plus l’évaluation porte sur les arbitrages et moins sur la syntaxe.

Pour un confirmé, le débrief compte autant que l’exercice : le candidat doit justifier ses choix et accepter la critique.

Le recrutement d’un développeur ne se limite pas à cette évaluation. Sourcing, fiche de poste et rémunération sont détaillés dans notre guide complet pour recruter un développeur.

Comment évaluer un profil tech quand on n’est pas technique ?

Prenez un CEO de start-up qui recrute son premier développeur backend. Il n’a jamais écrit une ligne de code, et le candidat parle de microservices avec assurance. Sans repère, il risque de signer sur la seule aisance orale.

Trois moyens lui évitent cette erreur :

1. Faire intervenir un pair sur au moins une étape : un lead de l’équipe, un CTO de votre réseau ou un freelance mandaté. Il note sur la même scorecard que le recruteur, ce qui rend les avis comparables.
2. Demander un arbitrage vécu : le contexte, les options écartées, le choix retenu, ce que le candidat referait autrement. Un récit précis, avec des contraintes chiffrées et une part d’autocritique, montre une expérience réelle. Méfiez-vous d’une histoire où tout s’est bien passé.
3. Prendre des références techniques auprès d’un ancien lead ou d’un pair plutôt que d’un RH. Restez factuel : quel était son périmètre réel, avec quelle autonomie, et fallait-il repasser derrière ses livrables ?

Pour un dirigeant technique, l’évaluation porte sur d’autres critères : voir notre page recruter un CTO en startup.

Quels pièges faussent l’évaluation technique d’un candidat ?

Certains réflexes font fuir les bons candidats, d’autres laissent passer des profils qui ne tiendront pas le poste. Voici les quatre plus fréquents, avec leur correctif.

1. Le test trop long ou non rémunéré. Les profils en poste abandonnent, alors que ce sont souvent les plus recherchés. Limitez l’exercice à quelques heures et, au-delà, rémunérez le temps passé ou réduisez le périmètre.
2. La question hors sujet. Inverser un arbre binaire au tableau ne dit rien d’un développeur qui maintiendra une API. Rattachez chaque question à un critère de la scorecard.
3. L’évaluation sans grille. Chaque évaluateur note seul, sur la scorecard, avant le débrief collectif. Ainsi, l’avis du plus convaincant ou du plus gradé ne s’impose plus aux autres.
4. L’IA pendant le test. Annoncez la règle à l’avance et autorisez l’IA si elle fait partie du poste. Faites ensuite expliquer chaque choix en direct : un candidat incapable de défendre son propre code se repère vite.

Comment Lity évalue les profils tech avant de les présenter

Chez Lity, l’évaluation technique s’inscrit dans un process en six étapes, le même pour chaque recrutement tech :

1. Définition du besoin et scorecard : la grille sur quatre axes, construite avec vous à partir de vos enjeux tech.
2. Ciblage et stratégie de chasse : la liste des entreprises et des profils à approcher.
3. Qualification et évaluation : chaque candidat est noté sur la scorecard avant toute présentation.
4. Présentation des candidats et rapports : vous recevez les profils retenus avec leur évaluation.
5. Accompagnement jusqu’au closing : entretiens, offre et négociation.
6. Analyse des KPIs et amélioration continue : délais, pertinence des profils et ajustements pour les recrutements suivants.

Chez Waltio (crypto et fintech), il fallait recruter un Head of Engineering. Lity a approché 10 profils à forte séniorité. 4 n’ont pas été présentés, car leur état d’esprit n’était pas en phase avec la culture de Waltio. Les 6 autres ont été envoyés au client. Le process comptait 4 entretiens, dont une évaluation technique et une rencontre avec l’équipe.

Cas client · Crypto / Fintech

Comment Waltio a recruté un Head of Engineering en 30 jours.

Structurer le pôle technique et libérer du temps aux cofondateurs pour permettre à Waltio d'accélérer son déploiement dans 40 nouveaux pays.

30 j

Time to fill

23 j

Time to hire

100 %

Pertinence CV

Lire le cas client Waltio →

Le poste a été pourvu en 30 jours, avec 100 % de pertinence CV et un time to hire de 23 jours. Sur l’ensemble de nos cas clients, le délai moyen pour pourvoir un poste est de 29 jours.

Le détail de la mission est à lire dans le cas client Waltio. Pour recruter un profil tech avec cette méthode, découvrez le cabinet de recrutement tech de Lity.