Le take-home assignment est un exercice technique que le candidat réalise chez lui, à son rythme, et qu'il rend sous forme de livrable. C'est la méthode la plus représentative du travail réel mais aussi la plus controversée, car elle peut devenir chronophage et biaisée. Ce guide détaille comment scoper l'exercice, le concevoir, l'évaluer avec une grille transparente et l'accompagner d'un debrief oral.
Qu'est-ce qu'un take-home assignment ?
Un take-home assignment est un exercice technique remis au candidat pour qu'il le réalise en autonomie, dans son propre environnement et sur un délai donné, avant de rendre un livrable évaluable (code, document, prototype). Contrairement au live coding, il supprime le stress de l'observation directe et laisse le candidat travailler comme il le ferait au quotidien : documentation ouverte, IDE familier, rythme choisi.
C'est sa force et son piège. La force : un livrable proche du travail réel, plus juste pour les profils que le stress paralyse. Le piège : mal calibré, il devient chronophage, favorise les candidats disposant de temps libre, et alourdit la charge d'évaluation côté entreprise.
Avantages et limites du take-home
Le take-home brille quand le travail réel se prête mal à une démonstration en temps réel et quand vous voulez un signal sur la qualité d'un livrable abouti. Il pénalise en revanche les candidats contraints par leur temps, parents, personnes en poste, foyers à double carrière, qui ne peuvent pas y consacrer des soirées entières.
Cette tension d'équité est le cœur du débat. Un exercice raisonnable de quelques heures reste défendable ; un exercice qui exige un week-end entier exclut mécaniquement une partie des bons profils et envoie un signal négatif sur le respect que l'entreprise porte au temps des candidats.
La règle d'or : 3 à 4 heures maximum
La règle d'or est qu'un take-home ne doit jamais dépasser trois à quatre heures de travail effectif pour un candidat expérimenté. Au-delà, il devient abusif : les meilleurs candidats, souvent en poste et sollicités ailleurs, refusent simplement de le faire, et vous ne gardez que ceux qui ont du temps à sacrifier.
Scopez donc l'exercice pour qu'un profil confirmé le termine en trois heures et un junior en cinq au maximum. Annoncez ce budget temps à l'avance, et précisez explicitement que vous n'attendez pas un travail poli au-delà : cela protège les candidats qui auraient tendance à sur-investir par peur de mal faire.
Concevoir un bon exercice
Un bon exercice de take-home reproduit un mini-problème métier réaliste, borné et auto-suffisant, plutôt qu'un projet ouvert au scope démesuré. Le candidat doit pouvoir comprendre l'attendu en cinq minutes et produire quelque chose de présentable dans le temps imparti.
Un bon exemple
« Construire un endpoint REST qui retourne la liste paginée des utilisateurs, avec filtres sur le nom et la date de création, tests unitaires inclus. » Le périmètre est clair, le problème est réaliste, et un candidat confirmé le termine en deux à trois heures.
Un mauvais exemple
« Construire un MVP complet de place de marché avec authentification, paiement et panneau d'administration. » Le scope est absurde : il signale une entreprise qui ne respecte pas le temps des candidats et qui, parfois, cherche du travail gratuit. Aucun bon profil senior n'acceptera.
La grille d'évaluation transparente
Une grille d'évaluation publiée à l'avance est ce qui rend le take-home équitable et comparable. Communiquez-la au candidat avec l'énoncé : il sait sur quoi il est jugé, et vous notez tous les rendus sur les mêmes axes.
| Critère évalué | Note /5 | Ce qu'on regarde |
|---|---|---|
| Qualité du code | __ | Lisibilité, structuration, présence et pertinence des tests |
| Choix techniques | __ | Décisions justifiées dans un README clair |
| Gestion des erreurs et cas limites | __ | Robustesse face aux entrées invalides |
| Performance (si pertinent) | __ | Solution raisonnable pour le volume attendu |
| Documentation | __ | README utile, instructions de lancement, hypothèses explicitées |
Fixez un seuil de passage avant de lire les rendus, par exemple une moyenne minimale et aucun axe en dessous de 2/5. Décider du seuil après lecture rouvre la porte à la rationalisation a posteriori et aux biais d'affinité.
Le debrief oral est indispensable
Un take-home sans entretien de debrief est une perte de temps, car vous ne savez pas qui a réellement écrit le code. Organisez un appel de 30 à 45 minutes où le candidat présente son approche, défend ses choix et répond à des questions de mise en situation.
Ce debrief remplit trois fonctions : vérifier la paternité réelle du travail (un candidat qui n'a pas codé sa solution se trahit en quelques questions), explorer les trade-offs que le format écrit ne montre pas, et observer la posture de communication. Avec la généralisation des assistants de code, ce contrôle oral est devenu non négociable.
L'alternative : le mini-challenge de 60 minutes
Pour les contextes où un take-home de plusieurs heures est trop lourd, un mini-challenge focalisé de 60 minutes capte une grande partie du signal pour une fraction du temps demandé. L'idée : un problème unique, précis et borné, par exemple implémenter un parseur simple ou une petite fonction métier avec ses tests.
Ce format réduit le biais d'équité (tout le monde y consacre le même temps), allège l'évaluation, et reste représentatif si le problème est bien choisi. Pour un premier filtre technique, il constitue souvent un bon compromis entre take-home et live coding.
FAQ, Take-home assignment
Combien de temps un take-home doit-il prendre ?
Trois à quatre heures de travail effectif pour un candidat confirmé, grand maximum. Au-delà, l'exercice exclut les bons profils en poste et favorise ceux qui disposent de temps libre, introduisant un biais d'équité. Annoncez le budget temps à l'avance et précisez que vous n'attendez pas un effort supérieur à celui annoncé.
Faut-il rémunérer un take-home ?
Si l'exercice reste sous quatre heures et porte sur un problème générique, la rémunération n'est pas attendue. En revanche, dès qu'un take-home s'allonge ou s'appuie sur un problème réel de votre produit, le rémunérer devient une marque de respect et améliore nettement votre image employeur auprès des candidats sollicités.
Comment détecter un take-home réalisé par une IA ?
Le debrief oral est la meilleure défense. Demandez au candidat d'expliquer une décision précise, de modifier une partie en direct ou de justifier un trade-off non documenté. Quelqu'un qui maîtrise réellement son code répond avec aisance ; celui qui a simplement généré la solution butte sur les questions de fond.
Concevez des take-home respectueux et discriminants avec Rocket4RPO
Un take-home mal conçu écarte les bons candidats et n'évalue pas mieux pour autant, un coût réel quand on sait que remplacer un salarié représente de 50 % à 200 % de son salaire annuel (SHRM/Gallup). Rocket4RPO aide ses clients à scoper des exercices courts, à rédiger des grilles transparentes et à cadrer le debrief, dans le cadre d'un process d'évaluation cohérent. Estimez l'enjeu de vos recrutements avec notre calculateur.