Un bon test technique est court (3 heures maximum), basé sur votre environnement réel plutôt que sur des exercices algorithmiques, réservé à la short list, et toujours suivi d'un feedback. Sa vraie valeur n'est pas de noter une copie mais d'observer comment le candidat dialogue avec l'équipe. Voici comment le concevoir par rôle (développeur, Product Owner, designer) sans perdre vos meilleurs candidats en route.
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. La plupart des erreurs viennent d'une confusion sur ce qu'on cherche à mesurer : on croit tester la compétence brute, alors que le vrai sujet est la compatibilité de travail.
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.
Un exemple qui m'a marqué. Lors d'un recrutement de développeur senior chez Wizbii, deux candidats avaient rendu un test techniquement irréprochable. À la restitution, le premier a pris chaque remarque de l'équipe comme une attaque : il défendait chaque ligne, justifiait au lieu d'écouter, refusait l'idée même qu'un choix puisse être discuté. Le second, sur exactement le même exercice, a accueilli les questions comme une discussion entre pairs : « tiens, je n'avais pas vu ça sous cet angle, comment vous géreriez ce cas chez vous ? ». Même niveau de code, décision opposée. On a recruté le second, et il est devenu un pilier de l'équipe. Le test n'avait rien révélé sur la compétence (elle était équivalente), mais tout sur la manière de collaborer. C'est précisément pour faire émerger ce signal-là qu'on organise une restitution, pas pour corriger une copie.
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.
En création d'équipe tech & produit, je vous aide à définir des processus de recrutement efficaces, tests inclus.
Adapter le test au contexte
Ces formats sont des points de départ, pas des moules rigides. Le bon test dépend de qui vous recrutez et de votre stade. Pour un profil junior, l'exercice à la maison sur une base de code existante peut être intimidant et peu révélateur : un junior a moins de réflexes pour naviguer dans un projet qu'il ne connaît pas, et vous risquez de mesurer son stress plutôt que son potentiel. Mieux vaut alors un exercice plus guidé, voire une session en binôme où vous observez sa façon de raisonner et de poser des questions, c'est précisément ce qui compte à ce niveau. À l'autre bout, pour un lead ou un futur manager technique, l'enjeu n'est plus le code mais l'architecture et la transmission : faites-le réagir à des décisions de conception, demandez-lui comment il embarquerait une équipe sur un chantier. Le stade de l'entreprise joue aussi : une structure de trois personnes qui recrute son premier développeur n'a ni la même base de code ni le même temps qu'une équipe établie. Dans ce cas, un exercice court et une longue discussion valent souvent mieux qu'un protocole formalisé. L'esprit reste le même partout (observer comment on travaille ensemble), seule la forme s'ajuste.
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.
Et l'IA dans tout ça ?
La question revient systématiquement depuis deux ans : faut-il autoriser l'IA pendant le test ? Interdire un outil que le candidat utilisera tous les jours en poste n'a aucun sens, autant tester sa capacité à conduire en lui retirant le volant. Le vrai sujet a changé. On ne cherche plus à savoir si quelqu'un sait écrire une fonction de tri à la main, mais s'il sait piloter ses outils, juger la qualité de ce qu'ils produisent, et expliquer ses choix.
Concrètement, j'autorise l'IA et je l'assume dans l'énoncé. Ce qui devient révélateur, alors, c'est la restitution : « pourquoi avoir gardé cette suggestion et écarté celle-là ? », « qu'est-ce que tu aurais fait différemment sans l'outil ? ». Un bon candidat sait exactement où il a fait confiance à l'IA et où il a repris la main. C'est d'ailleurs le même constat que je fais sur le terrain, détaillé dans L'IA n'invente pas l'expertise, elle l'amplifie : l'outil ne distingue pas un bon candidat d'un mauvais, c'est le jugement qui le pilote qui fait toute la différence.
Comment évaluer un développeur quand on n'est pas technique ?
Vous n'avez pas besoin d'écrire une ligne de code pour juger un développeur. Posez une question ouverte (« comment construirais-tu la v1 de ce produit ? »), puis écoutez : pose-t-il des questions sur le besoin avant de parler technique, explique-t-il simplement, raisonne-t-il en priorités ? La clarté du discours révèle la qualité du raisonnement.
Quand je n'ai pas la compétence interne pour trancher sur le code, je m'appuie sur trois leviers décideur, accessibles à n'importe quel fondateur.
Le premier est la question « comment construirais-tu la v1 ? ». Un bon développeur startup commence par interroger le besoin (« pour qui, pour quoi, à quelle échéance ? ») avant de dégainer une stack. Il propose le chemin le plus court vers quelque chose d'utilisable, quitte à couper des fonctionnalités. S'il ouvre direct sur l'architecture idéale sans avoir compris le problème, c'est un signal.
Le deuxième est le test de vulgarisation : demandez-lui d'expliquer un choix technique à quelqu'un qui n'y connaît rien (vous). Celui qui sait simplifier sans vous noyer de jargon est celui qui saura aussi dialoguer avec le reste de votre équipe. Celui qui se réfugie derrière les termes compliqués vous le fera payer à chaque arbitrage.
Le troisième est de faire challenger le candidat par un pair externe. Une grille d'entretien non-tech ne remplace pas un regard technique sur le code, mais elle vous fait gagner 80 % du tri toute seule. Pour structurer tout ça de bout en bout, je détaille la mécanique complète dans le process de recrutement, et je peux la mettre en place avec vous en création d'équipe tech & produit.
Quels red flags pour recruter un développeur startup ?
Les principaux red flags d'un développeur en contexte startup : la sur-ingénierie (microservices ou Kubernetes dès le jour un, pour un produit sans utilisateurs), le jargon défensif (se cacher derrière les termes compliqués), l'incapacité à prioriser, et le refus de couper du périmètre pour livrer plus vite. Livrer vite et apprendre prime sur la perfection technique.
Concrètement, voici les signaux qui doivent vous alerter pendant l'entretien, sans avoir besoin de lire le code.
La sur-ingénierie d'abord. Un candidat qui propose une architecture de licorne (microservices, Kubernetes, event sourcing) pour un produit qui n'a pas encore un seul utilisateur confond solidité et complexité. En early stage, chaque brique technique en trop est du temps volé à la recherche de product-market fit. Le bon réflexe est l'inverse : le système le plus simple qui marche aujourd'hui, qu'on fera évoluer quand le besoin sera réel.
Le jargon défensif ensuite. Quand vous posez une question simple et qu'on vous répond par un mur de termes techniques qui ferme la discussion plutôt que de l'ouvrir, méfiance. Souvent ce n'est pas de la pédagogie ratée, c'est une manière d'éviter d'être challengé. Un développeur qui collaborera bien avec un fondateur non-technique cherche à se faire comprendre, pas à impressionner.
Le rapport au périmètre, enfin. Demandez : « si on doit sortir dans la moitié du temps, qu'est-ce que tu coupes ? ». Celui qui répond « rien, tout est essentiel » ne sait pas prioriser. Celui qui assume des coupes franches et les justifie par la valeur utilisateur a le bon logiciel mental pour une startup. La capacité à dire non au superflu vaut, à ce stade, plus que la virtuosité technique.
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.
Envie d'en discuter ?
Réservez un créneau de 30 minutes pour un premier échange. Je vous aiderai à y voir plus clair sur votre situation.
Prendre rendez-vous