En six mois, j’ai conçu, corrigé ou supervisé 73 tests techniques sur quatre postes différents — deux back-end Python, un front-end TypeScript, un profil plateforme. Au démarrage, notre processus produisait 3 erreurs de casting sur 8 recrutements : des personnes brillantes en test qui ne tenaient pas le poste, et — plus coûteux encore — des personnes refusées que nous avons vues ensuite exceller ailleurs.
Ce qui suit est la méthode que nous appliquons désormais, en sept étapes numérotées. Elle n’a rien d’original dans ses principes ; ce qui a changé les résultats, c’est l’ordre dans lequel les choses sont faites. Notamment le fait d’écrire la grille de notation avant de recevoir la première copie, ce que nous ne faisions pas et qui a produit à lui seul la moitié du gain.
Étape 1 : décider ce que le test doit prouver, et rien d’autre
Écrivez une seule phrase : « ce test doit prouver que la personne sait ___ ». Puis supprimez de l’exercice tout ce qui ne contribue pas à cette phrase.
C’est brutal et c’est nécessaire, parce que le mode de défaillance par défaut d’un test technique est l’accumulation. Chaque personne consultée ajoute son sujet de prédilection — un peu d’algorithmique, une question de base de données, un soupçon d’architecture, une touche de sécurité. Au bout de trois itérations, l’exercice teste sept choses superficiellement et aucune sérieusement.
Notre premier test back-end était exactement cela. Nous l’avons réduit à une seule phrase : « cette personne sait-elle modifier du code existant qu’elle n’a pas écrit, sans casser le comportement existant ? ». Tout le reste est sorti. Le pouvoir prédictif a immédiatement augmenté, parce que nous mesurions enfin ce qui constituait 80 % du travail réel du poste.
Étape 2 : choisir le format en fonction du poste réel
Il n’existe pas de bon format universel. Il existe un format aligné avec le travail quotidien, et des formats qui ne le sont pas.
| Réalité du poste | Format qui prédit | Format qui trompe |
|---|---|---|
| Maintenir un produit existant | Corriger un bug dans une base de code fournie | Exercice algorithmique sur page blanche |
| Construire des fonctionnalités | Petite fonctionnalité de bout en bout avec tests | Question théorique sur les patrons de conception |
| Poste plateforme ou infra | Diagnostic d’une panne à partir de journaux réels | Écriture de code applicatif |
| Poste orienté données | Nettoyage et jointure sur un jeu volontairement sale | Exercice de requêtes sur un schéma parfait |
Le cas le plus fréquent en PME française est le premier : on recrute quelqu’un pour reprendre du code existant, et on lui fait passer un exercice sur page blanche. Ces deux activités mobilisent des compétences différentes. Beaucoup d’excellents mainteneurs sont médiocres sur page blanche, et l’inverse est tout aussi vrai.
Étape 3 : écrire un énoncé d’une page et le faire relire
Un énoncé ambigu ne teste pas la compétence technique : il teste la tolérance à l’ambiguïté et la capacité à deviner ce qu’attend le correcteur. Ce sont des qualités réelles, mais ce n’est presque jamais ce que vous cherchez à mesurer, et cela pénalise systématiquement les profils rigoureux.
Un bon énoncé tient sur une page et contient quatre éléments : le contexte en trois lignes, la tâche exacte, les critères d’acceptation explicites, et ce qui est hors périmètre. Ce dernier point est le plus souvent oublié et le plus utile : sans lui, les candidats consciencieux passent le double du temps prévu à couvrir des cas dont vous ne vouliez pas entendre parler.
Faites-le relire par quelqu’un qui ne connaît pas le poste. Si cette personne ne peut pas reformuler la tâche attendue après une lecture, l’énoncé n’est pas prêt. Nous avons repris trois énoncés sur quatre à cette étape.
Étape 4 : écrire la grille de notation avant la première copie
Voici l’étape qui a produit la moitié du gain, et celle que nous ne faisions pas.
Tant que la grille n’existe pas avant la correction, vous ne notez pas : vous justifiez une impression. Le mécanisme est parfaitement documenté et parfaitement invisible de l’intérieur. Vous lisez une copie, vous formez un jugement en quarante secondes, puis vous cherchez dans le code les éléments qui confirment ce jugement. Une copie qui vous a plu voit ses raccourcis qualifiés de pragmatisme ; la même dans une copie qui vous a déplu devient de la négligence.
La grille doit contenir 4 à 6 critères, chacun avec sa pondération et une description de ce que vaut un niveau faible, moyen et fort. Exemple sur notre test back-end :
- Le comportement existant est préservé (30 %) — vérifiable objectivement par la suite de tests fournie.
- Le correctif traite la cause et non le symptôme (25 %).
- Un test de non-régression couvre le bug (20 %).
- Lisibilité et cohérence avec le style existant (15 %).
- Qualité de la communication écrite — description du diagnostic (10 %).
Test de validité de la grille : faites corriger cinq copies par deux personnes séparément et comparez. Un écart supérieur à 20 % signale une grille défaillante, pas des correcteurs incompétents. Nous avions 34 % d’écart au premier essai.
Recruter un développeur sans y passer six mois
D-Open met en relation les entreprises françaises avec des développeurs open source déjà évalués techniquement : profils vérifiés, disponibilités réelles, pas d’intermédiaire opaque entre vous et la personne.
Lance-toi — décrire le posteÉtape 5 : calibrer le test sur l’équipe interne
Faites passer votre test à deux membres de l’équipe déjà en poste, en conditions réelles, chronomètre en marche. C’est vingt minutes d’inconfort pour un bénéfice considérable.
Deux résultats possibles, tous deux instructifs. Si vos développeurs en poste mettent le double du temps que vous aviez prévu — ce qui arrive presque toujours — votre estimation était fausse et vos candidats la subissent depuis des mois. Si l’un d’eux échoue à votre propre test, vous venez d’apprendre que votre test rejetterait un membre performant de votre équipe.
Ce second cas nous est arrivé. Notre développeur front-end le plus solide a obtenu une note médiocre à notre test front-end, parce que l’exercice reposait massivement sur une API de navigateur qu’il n’utilisait jamais et cherchait normalement en documentation. Nous mesurions la mémorisation, pas la compétence.
Étape 6 : encadrer le temps et rémunérer au-delà de deux heures
Deux heures est le plafond raisonnable pour un exercice non rémunéré. Une heure trente est un meilleur objectif.
La raison n’est pas morale, elle est statistique. Au-delà de deux heures, vous ne sélectionnez plus les meilleurs développeurs : vous sélectionnez ceux qui ont le plus de temps disponible. Cela exclut mécaniquement les parents de jeunes enfants, les personnes déjà en poste avec des semaines chargées, et les candidats qui mènent plusieurs processus en parallèle — c’est-à-dire, très exactement, les meilleurs candidats du marché.
Trois règles pratiques. Annoncez un temps cible et non une limite couperet. Acceptez les dépassements raisonnables sans les pénaliser, mais demandez au candidat de noter le temps réellement passé — cette information est plus utile que la copie elle-même pour calibrer les tests suivants. Et si votre exercice ne peut vraiment pas descendre sous deux heures, rémunérez-le au tarif journalier du poste, au prorata. Le coût est dérisoire face à celui d’une erreur de casting.
Étape 7 : débriefer avec le candidat et mesurer vos faux négatifs
Consacrez trente minutes à un débriefing technique avec chaque candidat qui a rendu une copie, y compris — et surtout — ceux que vous allez refuser.
Trois bénéfices, dans l’ordre d’importance. D’abord, vous corrigez vos propres erreurs de lecture : environ une copie sur six, chez nous, a été réévaluée après que le candidat a expliqué un choix que nous avions pris pour une erreur. Ensuite, vous observez la personne raisonner sur son propre code, ce qui reste le signal le plus prédictif de tout le processus. Enfin, un candidat refusé après un vrai débriefing reste un candidat qui parlera bien de vous — ce qui compte dans un marché où les développeurs se parlent.
Puis vient la mesure que presque personne ne fait : le suivi des faux négatifs. Notez les personnes refusées, et regardez six à douze mois plus tard où elles sont et ce qu’elles font. Nous avons découvert que deux profils refusés pour « niveau technique insuffisant » occupaient un an plus tard des postes plus seniors que celui que nous proposions. Cela ne prouve rien isolément, mais deux cas sur une trentaine de refus, c’est un signal qui mérite qu’on regarde sa grille.
Un test technique dont on ne mesure jamais les erreurs n’est pas un instrument de mesure. C’est un rituel. — William, D-Open
Et la question des assistants IA ?
Elle revient dans chaque discussion sur le sujet, alors traitons-la franchement : cessez d’essayer de l’empêcher.
Un développeur utilisera des assistants dans son travail quotidien. Interdire leur usage pendant le test revient à évaluer une situation qui n’existera jamais, tout en créant un désavantage pour les candidats honnêtes. La réponse efficace consiste à déplacer l’évaluation : autorisez explicitement les assistants dans l’énoncé, puis consacrez la session en direct à faire évoluer le code produit face à une contrainte nouvelle.
Un candidat qui ne comprend pas le code qu’il a livré se révèle en moins de dix minutes. Et cette révélation-là est infiniment plus informative que n’importe quel dispositif de surveillance. C’est aussi la raison pour laquelle la partie « autonomie » de notre test a été raccourcie : elle sert désormais de base de discussion, plus de note principale.
Les chiffres, six mois plus tard
Sur les 73 tests : taux de complétion passé de 58 % à 84 % après le passage à 1 h 30, écart entre correcteurs ramené de 34 % à 11 % après l’introduction de la grille préalable, erreurs de casting de 3 sur 8 à 1 sur 9, et délai moyen du processus réduit de 5,2 à 3,1 semaines — effet de bord non recherché du raccourcissement de l’exercice.
La seule métrique qui n’a pas bougé est le nombre de candidatures reçues. C’est logique : un meilleur test ne remplit pas votre pipeline, il vous évite de vous tromper sur les personnes qui y sont déjà.
Sur la partie amont — sourcing, cadrage du besoin, définition du niveau réellement nécessaire — notre guide sur le cadrage d’un projet CRM sur mesure illustre bien la méthode de spécification que nous appliquons aussi aux fiches de poste. Et pour les postes touchant à la sécurité applicative, l’approche d’évaluation de WebGuard Agency sur les compétences défensives complète utilement un test généraliste. Côté profils IA et agents en production, l’analyse de Plug-Tech sur les compétences réellement mobilisées en run vaut la lecture avant de rédiger l’annonce.
Votre test technique rejette-t-il vos meilleurs candidats ?
Faites-le passer à deux personnes de votre équipe cette semaine. Si l’une d’elles échoue, vous avez votre réponse — et nous pouvons vous aider à reprendre la grille.
Lance-toi — auditer votre processusFAQ : test technique développeur
Combien de temps doit durer un test technique développeur ?
Deux heures est le plafond raisonnable pour un exercice non rémunéré, une heure trente est un meilleur objectif. Au-delà, vous sélectionnez la disponibilité et non la compétence, ce qui exclut mécaniquement les candidats déjà en poste. Si l’exercice ne peut pas descendre sous deux heures, rémunérez-le au prorata du tarif journalier du poste.
Faut-il faire coder en direct ou en autonomie ?
Les deux mesurent des choses différentes. L’autonomie mesure la qualité de production (structure, tests, cas limites), le direct mesure le raisonnement et la collaboration. La combinaison la plus prédictive est un exercice court en autonomie suivi de trente minutes où le candidat fait évoluer son propre code face à une nouvelle contrainte.
Comment éviter que le test soit résolu par une IA ?
En cessant de le considérer comme un problème. Autorisez explicitement les assistants, puis évaluez en direct la capacité à faire évoluer le code produit. Un candidat qui ne comprend pas ce qu’il a livré se révèle en moins de dix minutes.
Comment mesurer si son test technique est bon ?
Par deux indicateurs : le taux d’accord entre correcteurs (faites corriger cinq copies par deux personnes séparément ; plus de 20 % d’écart signale une grille défaillante) et la corrélation entre les notes obtenues et la performance des recrutés à six mois. Si cette corrélation est nulle, votre test mesure autre chose que ce qui vous intéresse.