Le code compile.
Les tests passent.
Et pourtant, la mission part à quelqu'un d'autre.
Un test technique en entretien freelance n'évalue pas seulement si le code fonctionne — il évalue la façon dont tu prends des décisions sous contrainte de temps, avec un niveau d'exigence souvent plus proche d'une vraie mission qu'un entretien d'embauche salarié classique.
Ce qu'un test technique freelance évalue vraiment
Le raisonnement, pas seulement le résultat.
Un client qui recrute un freelance regarde comment tu abordes le problème avant de regarder si la solution finale est parfaite. Expliciter ton raisonnement à voix haute (ou par commentaire) vaut souvent plus qu'un code muet, même juste.
Les choix de compromis sous contrainte de temps.
Un test technique a une limite de temps volontairement serrée. Savoir dire «j'aurais fait X en conditions réelles, mais j'ai priorisé Y compte tenu du temps imparti» montre une maturité professionnelle que le code seul ne montre pas.
La qualité du code produit sous pression, pas en isolation.
Un freelance travaille rarement dans des conditions idéales en mission réelle non plus — le test cherche à vérifier si ta rigueur tient même quand le temps manque.
Les différents formats de test, et ce que chacun cherche vraiment
Tous les tests techniques ne se préparent pas de la même façon — connaître le format à l'avance change directement la stratégie à adopter :
| Format | Durée typique | Ce qui est vraiment évalué | Le piège fréquent |
|---|---|---|---|
| Live coding (en visio, observé) | 45 à 90 min | Communication du raisonnement, gestion du stress | Coder en silence sans verbaliser |
| Take-home (à rendre sous quelques jours) | 2 à 6h de travail effectif | Qualité de code, choix d'architecture, respect des consignes | Sur-ingénierie pour «impressionner» |
| Pair programming avec un membre de l'équipe | 45 à 60 min | Fit d'équipe, capacité à écouter et intégrer un feedback en direct | Vouloir avoir raison plutôt que collaborer |
| System design / architecture (tableau blanc) | 30 à 60 min | Capacité à structurer un problème flou, à poser les bonnes questions | Se jeter sur une solution avant d'avoir cadré le besoin |
👉 Réserve un diagnostic gratuit, prépare ton test
Les erreurs qui coulent un bon profil
Vouloir tout faire parfaitement, et manquer de temps sur l'essentiel.
Un test inachevé mais bien priorisé vaut souvent mieux qu'un test complet mais bâclé sur les parties critiques.
Ne pas poser de questions de clarification avant de commencer.
Un client technique apprécie qu'on lève les ambiguïtés avant de coder — ça montre une méthode, pas une faiblesse.
Livrer sans expliquer les compromis pris.
Le code seul ne raconte pas pourquoi tu as fait tel choix plutôt qu'un autre. Un court résumé écrit ou oral de tes décisions vaut souvent plus que le code lui-même pour le client qui évalue.
Où se situe la limite du raisonnable, en temps non rémunéré
Il n'existe pas de règle universelle, mais quelques repères pratiques aident à trancher :
En dessous de 2 à 3h de travail effectif.
Reste dans la norme pour évaluer un profil freelance, y compris pour des missions bien rémunérées — rarement un signal d'alerte en soi.
Entre 3 et 6h.
Encore acceptable pour une mission complexe ou très bien payée, à condition que le périmètre du test soit clair et proportionné à la mission proposée.
Au-delà de 6 à 8h, ou un livrable qui ressemble à du travail productisable.
Le moment de questionner ouvertement le périmètre avant d'accepter — certains clients utilisent des «tests» comme travail gratuit déguisé. Demander une rémunération partielle ou une réduction du périmètre est une demande légitime, pas un manque de motivation.
Les signaux qui doivent alerter avant d'accepter un test
Le test porte exactement sur un problème métier réel et actuel du client.
Un signal fréquent de travail gratuit déguisé, surtout si plusieurs candidats reçoivent le même brief précis lié à un besoin opérationnel immédiat.
Aucune limite de temps ni de périmètre n'est communiquée.
Un client sérieux cadre son test — l'absence de cadrage laisse la porte ouverte à une dérive du périmètre.
Le client demande la cession des droits sur le code produit.
Une clause à lire attentivement avant d'accepter — un test d'évaluation n'a normalement pas vocation à devenir la propriété du client.
FAQ
Faut-il refuser un test technique trop long ou non rémunéré ?
C'est une décision personnelle — un test de quelques heures est courant, un test qui représente plusieurs jours de travail non rémunéré mérite d'être questionné ou négocié avant d'être accepté.
Comment gérer un test technique en live, sous observation ?
Verbaliser ton raisonnement pendant que tu codes rassure l'observateur — le silence total pendant un exercice en live donne moins d'information au client qu'un raisonnement expliqué à voix haute.
Peut-on demander à être payé pour un test technique ?
Oui, et c'est une pratique de plus en plus courante pour les tests longs (au-delà de quelques heures) — la formuler simplement, en expliquant que c'est ta pratique standard pour ce type de format, passe généralement bien auprès d'un client sérieux.
Faut-il rendre un test parfait ou un test qui respecte le temps imparti ?
Un test rendu dans les temps avec des choix expliqués convainc généralement plus qu'un test hors délai, même plus abouti — le respect du cadre fait partie de l'évaluation, au même titre que le code.
Une précision : ce contenu s'adresse aux freelances IT (dev, data, product, delivery). Si tu es dans un autre métier, la logique reste transposable mais le format du test ne s'appliquera pas de la même façon.
Si tu as un test technique prévu dans les prochains jours, c'est le moment où cette préparation change vraiment l'issue.
👉 Réserve un diagnostic gratuit, prépare ton test
Pour retravailler ce moment précis de l'entretien : Coach entretien d'embauche pour profils tech et freelances IT. Teste où tu en es avant de réserver : Diagnostic : es-tu prêt pour ton prochain entretien freelance IT ? (10 questions). Vue d'ensemble du coaching : Coaching entretien : se préparer avec un coach (profils tech).
Rudolph B., fondateur de DevAtScale — 15 ans business manager en ESN, plus de 300 consultants placés, 100+ entreprises accompagnées. Profil LinkedIn.