Tests techniques en recrutement : évaluer les compétences sans perdre de candidats
Comment concevoir des tests techniques efficaces pour recruter développeurs, Product Owners et designers. Formats, durée, erreurs à éviter.
Le test technique fait débat. Certains candidats le redoutent, certaines entreprises en abusent. Pourtant, bien conçu, c'est un outil précieux — autant pour évaluer que pour créer du lien.
Cet article approfondit la partie évaluation du process de recrutement. Consultez-le pour une vue d'ensemble des étapes.
Pourquoi faire un test technique ?
| Objectif | Ce qu'on évalue vraiment |
|---|---|
| Valider les compétences | Le candidat sait-il faire ce qu'on attend de lui ? |
| Calibrer le salaire | À la hausse ou à la baisse selon le niveau réel |
| Créer un échange | Le candidat sait-il dialoguer avec l'équipe ? |
| Montrer comment on travaille | Stack, outils, méthodes — éviter les surprises |
Le dernier point est souvent négligé. Un test technique basé sur votre environnement réel montre au candidat ce qui l'attend. S'il n'adhère pas, mieux vaut le savoir avant qu'il signe — plutôt que de le perdre pendant sa période d'essai.
Le test comme outil d'échange
La vraie valeur du test technique n'est pas de noter une copie. C'est d'observer comment le candidat interagit avec l'équipe lors de la restitution :
- Est-il capable d'expliquer ses choix ?
- Accepte-t-il la critique ?
- Sait-il répondre aux questions sans se braquer ?
- A-t-on envie de travailler avec lui au quotidien ?
Les échecs après un test technique sont rarement des problèmes de code, de maquette ou de user story. Ce sont des incompatibilités humaines : quelqu'un qui n'écoute pas, qui se braque, qui ne veut pas s'intégrer dans une dynamique d'équipe.
Le test n'est qu'un prétexte pour faire émerger ces signaux.
Format recommandé par rôle
Développeurs
Le format : un exercice à faire chez soi, à partir d'une base de code existante.
Partez d'un projet simple qui ressemble à votre environnement réel : même stack, mêmes outils, même type de tests automatisés. Demandez au candidat d'ajouter 1 à 3 fonctionnalités simples.
Ce format a plusieurs avantages :
- Réaliste : la majorité du code est écrit seul, pas en pair programming
- Pas de travail dissimulé : on ne lui fait pas développer une feature de votre roadmap
- Révélateur : on voit s'il sait se débrouiller dans un environnement existant
Ensuite, le candidat revient présenter son travail à l'équipe. C'est là que tout se joue.
Product Owners
Le format : un cas pratique simple à préparer, puis une présentation type Poker Planning.
Prenez un cas qui ne nécessite pas de connaître votre métier — un processus de création de compte par exemple. Donnez-le sous forme de wireframes. Demandez au candidat de l'améliorer et de le découper en tâches exploitables par une équipe.
Lors de la restitution, mettez-vous dans la peau de l'équipe. Ce qu'on évalue :
- Sa capacité à transmettre une vision
- La clarté de son découpage
- Sa réaction face aux questions et objections
On cherche à voir s'il sait embarquer une équipe, pas s'il sait estimer des story points.
Designers
Le format : le même cas que les PO, mais avec un livrable différent.
Donnez les mêmes wireframes (création de compte). Demandez de commenter, améliorer et décliner en maquettes exploitables.
La nuance selon le profil recherché :
- Profil UX : fournissez un design system existant (ShadCN par exemple) et concentrez-vous sur le parcours
- Profil UI : demandez de créer un design system minimal et de l'appliquer à 1-2 écrans
Même logique de restitution : on veut voir le candidat expliquer ses choix et dialoguer.
Les règles d'or
Durée : 3 heures maximum
Un test technique ne doit pas prendre plus de 3 heures de travail chez soi. Au-delà, vous demandez un investissement déraisonnable — surtout si le candidat passe plusieurs processus en parallèle.
Uniquement pour la short list
Le test technique vient après un premier filtre (appel, visio, entretien). Les candidats qui passent le test doivent être des personnes avec qui vous vous sentez déjà à l'aise. On ne fait pas perdre du temps à quelqu'un dont on sait que ça ne marchera pas.
3 personnes maximum côté entreprise
Pour la restitution : le manager et 2 membres de l'équipe. Plus, vous risquez d'inhiber le candidat. Si vous voyez plusieurs candidats, le manager reste présent mais les membres de l'équipe peuvent varier.
C'est aussi un excellent exercice pour des collaborateurs qu'on aimerait préparer à mener des entretiens un jour.
Feedback obligatoire
Le candidat s'est impliqué : il a travaillé chez lui, il est venu présenter quelque chose. Même en cas de refus, expliquez pourquoi.
En pratique, je fais ce retour par téléphone après l'entretien. J'ai besoin que l'équipe s'exprime d'abord — difficile de donner un feedback pertinent en live.
Les erreurs à éviter
| Mauvaise pratique | Pourquoi ça ne marche pas |
|---|---|
| Test sur tableau blanc | Personne n'écrit du code sur un tableau au quotidien |
| Test algorithmique (tri à bulle, arbre binaire) | Déconnecté du travail réel |
| Test sans base de code | Partir de zéro prend trop de temps et n'est pas réaliste |
| Test de plusieurs jours | Investissement déraisonnable pour le candidat |
| Test qui ressemble à du travail gratuit | Éthiquement discutable, mauvais signal |
Le bon test est court, réaliste, et basé sur votre façon de travailler.
En résumé
| Rôle | Format | Durée | Ce qu'on évalue vraiment |
|---|---|---|---|
| Développeur | Code à compléter chez soi + restitution | 3h max | Dialogue, intégration, pragmatisme |
| Product Owner | Cas pratique + présentation type Poker | 3h max | Vision, clarté, écoute |
| Designer | Wireframes à améliorer + maquettes | 3h max | Démarche, argumentation, collaboration |
Le test technique n'est pas un examen. C'est une mise en situation qui permet au candidat et à l'équipe de se découvrir mutuellement — et de décider ensemble si ça peut fonctionner.
En création d'équipe technique ou création d'équipe produit, je vous aide à définir des processus de recrutement efficaces — tests inclus.