Le test technique à faire chez soi, souvent appelé take-home, est devenu une étape courante des recrutements de développeurs, en particulier dans les startups et les scale-up. L’entreprise envoie un énoncé (une petite API, une interface, un traitement de données), fixe un délai, puis organise une séance où vous présentez votre travail. Pour le candidat, la difficulté n’est pas seulement technique : il faut décider combien de temps y consacrer, quoi livrer et comment présenter des choix forcément incomplets. Cet article se place du point de vue de l’équipe qui corrige, pour vous aider à rendre un travail qui se défend.
Ce que l’équipe regarde en corrigeant
L’équipe qui reçoit votre rendu ne cherche presque jamais la solution parfaite. Elle a souvent corrigé des dizaines de versions du même exercice, et sait exactement ce qu’elle veut évaluer. Sa grille, explicite ou implicite, porte généralement sur cinq points.
- Le respect de l’énoncé. Les fonctionnalités demandées sont-elles présentes et fonctionnent-elles ? Un rendu qui ajoute des fonctions non demandées mais oublie une exigence de base est mal noté.
- La lisibilité. Le code se lit-il facilement ? Les noms sont-ils clairs, les responsabilités séparées, la structure cohérente ? Un correcteur doit pouvoir comprendre votre logique en quelques minutes.
- Les tests. Y en a-t-il, et testent-ils ce qui compte ? Quelques tests bien choisis sur la logique métier valent mieux qu’une couverture élevée sur du code trivial.
- Les choix et leur justification. Pourquoi cette architecture, cette bibliothèque, cette modélisation ? Qu’avez-vous laissé de côté, et pourquoi ?
- La facilité de lancement. Le correcteur peut-il installer et lancer le projet en suivant vos instructions, sans deviner ? Un projet qui ne démarre pas part avec un handicap sérieux, quelle que soit sa qualité.
Ce dernier point est souvent sous-estimé. Testez votre propre procédure d’installation dans un environnement propre avant d’envoyer le lien.
Combien de temps y consacrer
C’est la question la plus fréquente, et la plus délicate. Les énoncés indiquent souvent une durée indicative (« environ trois heures »), parfois aucune.
Quelques repères :
- Respectez l’ordre de grandeur annoncé. Si l’entreprise parle de trois heures, elle a calibré sa grille pour ce temps. Y passer un week-end entier ne vous donnera pas un avantage proportionnel, et certaines équipes voient d’un mauvais œil un rendu manifestement surdimensionné.
- Notez le temps réellement passé et indiquez-le dans le README. C’est une information utile pour le correcteur, qui jugera votre travail à l’aune de ce temps.
- Priorisez. Commencez par un chemin complet qui fonctionne, même simple, puis améliorez. Un rendu incomplet mais fonctionnel sur l’essentiel vaut mieux qu’une architecture élégante qui ne fait rien.
- Listez ce que vous auriez fait avec plus de temps. C’est la meilleure façon de montrer que vous voyez plus loin que ce que vous avez livré, sans y passer des heures.
Si le délai ou l’ampleur de l’exercice vous semble disproportionné, par exemple parce que vous menez plusieurs processus en parallèle ou que vous êtes en poste, il est légitime d’en parler. Beaucoup d’entreprises acceptent un délai supplémentaire, une version réduite ou un autre format, comme une séance de pair programming. Notre article sur la préparation d’un entretien technique détaille les différents formats d’exercice et ce que chacun évalue.
Le README qui explique vos choix
Le README est la pièce la plus importante de votre rendu après le code lui-même. C’est la première chose que lit le correcteur, et c’est lui qui donne le cadre de lecture de tout le reste.
Un bon README de test technique contient :
- un résumé en deux ou trois lignes de ce que fait le projet ;
- les instructions de lancement, précises et testées : prérequis, commandes d’installation, commande de lancement, commande des tests, éventuelles variables d’environnement ;
- les choix techniques, avec leur raison : « J’ai choisi une base SQLite pour simplifier le lancement ; en production, j’utiliserais PostgreSQL pour les accès concurrents » ;
- les hypothèses que vous avez faites quand l’énoncé était ambigu, au lieu de les laisser deviner ;
- les limites connues et ce que vous feriez avec plus de temps : pagination, gestion fine des erreurs, authentification, tests de charge ;
- le temps passé.
Exemple de section « choix et limites » :
J’ai séparé la logique de calcul des tarifs dans un module sans dépendance au framework, testé unitairement, pour pouvoir la faire évoluer indépendamment de l’API. L’API valide les entrées avec un schéma ; les erreurs renvoient un format homogène. Non traité faute de temps : la pagination de la liste des réservations et la gestion des fuseaux horaires, que j’aborderais en stockant toutes les dates en UTC.
Ce paragraphe dit au correcteur ce que vous avez voulu montrer, ce que vous savez manquer, et comment vous le traiteriez. Il prépare aussi la discussion de la restitution.
Tests, structure et historique Git
Les tests
Testez en priorité la logique métier, c’est-à-dire la partie de l’énoncé qui comporte des règles : un calcul, une validation, un filtrage, une transition d’état. Ajoutez un ou deux tests d’intégration sur le chemin principal (une requête à l’API qui crée puis lit une ressource, par exemple). Inutile de viser une couverture exhaustive ; visez des tests qui montrent que vous savez où se trouvent les risques.
Assurez-vous que les tests passent avec une seule commande, documentée dans le README. Un correcteur qui doit chercher comment lancer vos tests risque de ne pas les lancer du tout.
La structure
Adoptez une structure proportionnée à l’exercice. Une petite API n’a pas besoin d’une architecture hexagonale complète avec dix couches d’abstraction ; elle a besoin d’une séparation claire entre la couche HTTP, la logique métier et l’accès aux données. Une sur-ingénierie visible inquiète autant qu’un code désordonné : elle laisse craindre un développeur qui complexifie tout.
Gardez aussi une configuration propre : un fichier d’exclusion pour les dépendances et les fichiers générés, des réglages de formatage et de lint, aucun secret dans le code.
L’historique Git
Beaucoup de correcteurs regardent l’historique des commits, qui montre votre façon de travailler. Faites des commits réguliers, avec des messages clairs, qui racontent la progression : mise en place du projet, modèle de données, première route, tests, gestion des erreurs, documentation. Un seul commit géant intitulé « rendu » efface toute cette information. Le livre de Git 🔗 rappelle les bonnes pratiques si besoin, et notre article sur le lien GitHub dans un CV détaille ce qu’un lead lit dans un historique.
Préparer la restitution
La plupart des tests à la maison sont suivis d’une séance de restitution, d’une demi-heure à une heure, avec un ou plusieurs membres de l’équipe. C’est souvent elle qui décide du résultat.
Préparez-vous à :
- présenter votre solution en cinq minutes : ce que vous avez construit, l’architecture, les choix principaux ;
- expliquer un choix que vous referiez autrement : les correcteurs posent presque toujours la question, et une réponse lucide est très bien reçue ;
- faire évoluer le code en direct : ajouter une fonctionnalité, corriger un bug introduit volontairement, gérer un nouveau cas. Révisez votre propre code avant la séance pour le retrouver rapidement ;
- discuter de la mise à l’échelle : que se passerait-il avec beaucoup plus de données ou d’utilisateurs ? Où seraient les goulets d’étranglement ?
- recevoir des critiques : un correcteur peut pointer une faiblesse. Écoutez, reconnaissez si c’est juste, expliquez votre raisonnement sinon. L’équipe observe votre réaction autant que votre code.
La restitution est aussi le moment de poser des questions à l’équipe : comment elle travaille, comment elle fait ses revues de code, comment elle teste. C’est une information précieuse pour votre décision.
Le test technique et votre CV doivent raconter la même histoire. Si votre CV annonce une pratique des tests et de l’intégration continue, le rendu doit en contenir. Le modèle de CV de développeur full-stack montre des expériences où les tests de bout en bout et le déploiement continu sont décrits précisément, ce qui prépare naturellement ce type d’échange. Un CV clair, mis en page par un outil qui évite les colonnes et les éléments graphiques que les logiciels de recrutement lisent mal, vous amène jusqu’à cette étape : vous pouvez préparer le vôtre avant d’envoyer vos candidatures.
Questions fréquentes
Peut-on utiliser un assistant de code pour un test à la maison ?
Lisez l’énoncé : certaines entreprises l’autorisent, d’autres l’interdisent. En l’absence de règle, soyez transparent dans le README sur l’usage que vous en avez fait. Dans tous les cas, vous devrez expliquer et modifier chaque ligne pendant la restitution.
Faut-il ajouter des fonctionnalités non demandées ?
Seulement une fois l’énoncé entièrement couvert, et avec parcimonie. Mieux vaut une liste de pistes dans le README qu’une fonction supplémentaire qui introduit un bug. Les correcteurs évaluent d’abord ce qui était demandé.
Que faire si je ne termine pas dans le temps imparti ?
Livrez ce qui fonctionne, indiquez clairement ce qui manque et comment vous l’auriez fait. Un rendu partiel bien documenté est souvent mieux noté qu’un rendu complet mais fragile, envoyé en retard.
Mon code de test technique peut-il rester public sur GitHub ?
Vérifiez les consignes de l’entreprise : beaucoup demandent de ne pas publier l’énoncé ni la solution, pour pouvoir réutiliser l’exercice. Dans le doute, utilisez un dépôt privé partagé avec l’équipe, ou supprimez le dépôt public après le processus.