1 – Définir ce que vous évaluez réellement avant de lancer un test technique
Un test technique React sans grille de lecture, c'est du temps perdu des deux côtés. Avant d'envoyer quoi que ce soit au candidat, vous devez verrouiller trois éléments : le périmètre technique réel du poste, les critères éliminatoires et le seuil d'acceptation. Sans ça, vous évaluerez au feeling, et le feeling ne scale pas.
1.1 : Cartographier votre stack front-end réelle, pas une wishlist
Ouvrez votre package.json. Listez les dépendances réellement utilisées en production. C'est votre cahier des charges, pas une fiche de poste copiée sur LinkedIn. Si votre app tourne sur React 18 avec Zustand, React Query et Tailwind, vous n'avez pas besoin de tester Redux Saga. Si vous utilisez Next.js en SSR, le candidat doit démontrer qu'il comprend le cycle de rendu serveur, pas réciter la doc de Create React App.
Créez un document d'une page avec trois colonnes : "indispensable dès le jour 1" (ce qui est en prod), "nécessaire sous 30 jours" (ce qui arrive dans la roadmap), "bonus" (ce qui serait appréciable). La colonne 1 définit vos critères éliminatoires. La colonne 2 définit le potentiel de montée en compétence. La colonne 3, vous l'oubliez pendant l'évaluation.
Ce travail prend 20 minutes si vous connaissez votre propre code. Si vous ne le connaissez pas, c'est un signal : vous avez besoin de cartographier vos processus internes avant d'externaliser quoi que ce soit.
1.2 : Séparer les critères éliminatoires des critères de progression
Toute évaluation technique doit distinguer ce qui est rédhibitoire de ce qui s'apprend en deux semaines. Un développeur React qui ne comprend pas le cycle de vie des composants, qui mute le state directement ou qui n'a jamais touché un hook custom : éliminatoire. Un développeur qui ne connaît pas votre convention de nommage CSS ou qui n'a jamais utilisé Storybook : formable en quelques jours.
Les critères éliminatoires pour un poste React front-end en 2025 tiennent en une liste courte. Maîtrise des hooks fondamentaux (useState, useEffect, useRef, useCallback, useMemo). Compréhension du rendu conditionnel et des listes avec keys. Capacité à structurer des composants réutilisables avec des props typées. Gestion basique de l'asynchrone (fetch, promesses, gestion d'erreurs). Lecture et écriture de TypeScript si votre projet l'utilise.
Tout le reste (librairies de state management spécifiques, frameworks de test, outils de CI/CD) relève de la montée en compétence. Confondre les deux, c'est éliminer des profils solides pour des raisons cosmétiques.
1.3 : Fixer un seuil d'acceptation chiffré avant de lire la première ligne de code
Avant de recevoir le moindre livrable, écrivez votre grille de scoring. Pas après. Avant. Chaque critère reçoit une note de 0 à 3. 0 : absent. 1 : compris mais mal exécuté. 2 : fonctionnel et propre. 3 : élégant, bien structuré, avec gestion des cas limites. Fixez un score minimum global et un score minimum par critère éliminatoire.
Exemple concret : sur 8 critères, score maximum de 24. Seuil d'acceptation à 16. Aucun critère éliminatoire en dessous de 2. Ce cadre empêche deux biais fréquents : le biais de confirmation ("il est sympa, je lui mets un bon score") et le biais d'exigence excessive ("personne n'atteint 24, on continue à chercher").
Partagez cette grille avec quiconque participe à l'évaluation. Si vous faites évaluer par votre lead dev et par vous, vous devez noter indépendamment puis comparer. C'est la seule façon d'obtenir un recrutement reproductible, surtout quand vous recrutez à distance un développeur front-end offshore que vous ne verrez pas en physique.
2 – Le test technique en 48h : format, contenu et signaux à observer
Un test technique pour un développeur React offshore doit être réalisable en 3 à 4 heures, livrable sous 48 heures et évaluable en 30 minutes. Plus long, vous perdez les bons candidats. Plus court, vous ne voyez rien. Voici comment structurer chaque étape.
2.1 : Le test asynchrone de 3h : un mini-projet calqué sur votre réalité
Oubliez les quiz à choix multiples et les algorithmes LeetCode. Vous cherchez un développeur front-end capable de livrer des interfaces, pas un chercheur en algorithmique. Construisez un exercice qui ressemble à ce que le candidat fera réellement. Prenez une fonctionnalité simple de votre produit (ou une version simplifiée) et demandez de la recréer.
Un bon test React en 3 heures : consommer une API REST ou un mock JSON, afficher les données dans une liste filtrable, gérer un état de chargement et d'erreur, permettre une action utilisateur (ajout, suppression, modification). Fournissez un boilerplate avec votre stack réelle (Vite + React + TypeScript si c'est ce que vous utilisez). Ajoutez un README avec les consignes précises, le résultat attendu sous forme de wireframe ou capture, et les critères d'évaluation.
Donnez exactement 48 heures calendaires. Le candidat organise son temps comme il veut. Ce format respecte le décalage horaire (nul entre la France et Madagascar, mais le principe reste bon pour vos process futurs) et filtre les profils qui ne savent pas livrer dans un délai.
2.2 : Le live coding de 45 minutes : ce que le code asynchrone ne révèle pas
Le test asynchrone montre le résultat. Le live coding montre le raisonnement. Après réception du test, planifiez une session vidéo de 45 minutes. Les 15 premières minutes : le candidat présente son code, explique ses choix d'architecture, justifie ses compromis. Vous observez sa capacité à verbaliser en français (critère non négociable pour un développeur dédié qui intègre votre équipe au quotidien).
Les 20 minutes suivantes : vous demandez une modification en temps réel. Ajoutez un filtre, changez la structure de la réponse API, introduisez un cas limite. Vous ne cherchez pas la perfection. Vous cherchez la méthode. Est-ce qu'il lit l'erreur dans la console avant de chercher sur Google ? Est-ce qu'il décompose le problème ou fonce tête baissée ? Est-ce qu'il pose des questions de clarification ?
Les 10 dernières minutes : questions ouvertes. Comment gèrerait-il le cache de cette requête ? Que ferait-il si cette liste contenait 10 000 éléments ? Ces questions révèlent la profondeur technique au-delà du code livré. Un profil qui répond "je mettrais React Query avec une staleTime" ou "je virtualiserais la liste avec react-window" sait de quoi il parle. Un profil qui hésite sur les concepts fondamentaux après avoir livré un test propre a probablement été assisté par IA.
2.3 : Les 6 signaux d'alerte à détecter pendant l'évaluation
Premier signal : le code fonctionne mais aucun composant n'est découpé. Tout dans un seul fichier de 400 lignes. Ce développeur livrera de la dette technique dès le sprint 1. Si vous voulez comprendre pourquoi c'est critique à distance, consultez notre article sur comment éviter la dette technique offshore dès le premier sprint.
Deuxième signal : aucune gestion d'erreur. Le happy path fonctionne, le reste crash silencieusement. Troisième signal : des dépendances npm ajoutées pour des tâches triviales (une librairie entière pour formater une date, par exemple). Cela trahit un manque de maîtrise du JavaScript natif.
Quatrième signal : le candidat ne peut pas expliquer son propre code en live. Copier-coller intelligent d'un code généré par IA sans compréhension réelle. Cinquième signal : aucune question posée sur les consignes. Un bon développeur clarifie les zones grises. Un exécutant devine et livre à côté. Sixième signal : le code ignore complètement le typage TypeScript (si requis) ou utilise "any" partout. Ce profil ne vous fera pas gagner de temps, il vous en fera perdre en code review.
3 – Intégrer le développeur dans votre stack en 5 jours, pas en 3 semaines
Le test est passé, le profil est validé. Reste le piège classique : un onboarding qui traîne, un développeur qui attend des accès, des réunions d'introduction qui ne débouchent sur rien. Voici comment rendre un développeur React offshore opérationnel en 5 jours ouvrés.
3.1 : Jour 1 et jour 2, accès, environnement et premier commit
Avant le jour 1, tout doit être prêt. Accès Git (avec les bons droits sur les bons repos), accès Jira ou votre outil de ticketing, accès Slack ou Teams, accès à l'environnement de staging. Si vous manquez de méthode sur ce sujet, notre guide sur la gestion des accès et droits informatiques pour une équipe offshore détaille chaque étape.
Jour 1 : le développeur clone le repo, installe les dépendances, lance le projet en local. Son objectif de fin de journée : le projet tourne sur sa machine et il a lu le README (vous en avez un, n'est-ce pas ?). Jour 2 : premier ticket. Pas un ticket critique. Un bug mineur ou une amélioration cosmétique. L'objectif n'est pas la production de valeur, c'est de parcourir le cycle complet : lire le ticket, créer une branche, coder, pousser, ouvrir une pull request. Ce premier commit valide que toute la chaîne technique fonctionne et que le développeur sait naviguer dans votre workflow.
Chez TARAM, chaque développeur intégré travaille sur l'infrastructure du client (Git, Jira, Slack du client) dès le premier jour. Pas d'environnement intermédiaire, pas de proxy technique. Le développeur est dans votre équipe, point.
3.2 : Jour 3 et jour 4, montée en charge progressive avec code review systématique
Jour 3, le développeur prend un ticket fonctionnel réel. Une feature de complexité moyenne : un formulaire avec validation, un composant d'affichage avec filtres, une intégration d'endpoint API. Le livrable passe en code review avant merge. C'est là que vous calibrez le niveau réel en conditions de production.
La code review du jour 3 est votre vrai moment de vérité. Vous voyez si le développeur respecte vos conventions (ou s'adapte vite aux retours), s'il structure ses composants de façon cohérente avec l'existant, s'il gère les edge cases. Documentez vos retours dans la pull request, pas à l'oral. Chaque commentaire écrit devient une référence pour les futures contributions. Pour structurer cette mécanique à distance, notre protocole de code review asynchrone couvre les formats et les outils.
Jour 4 : deuxième ticket, complexité similaire ou légèrement supérieure. La code review doit montrer une réduction des retours par rapport au jour 3. Si le développeur reproduit les mêmes erreurs malgré des commentaires explicites, c'est un signal. Un bon profil intègre les retours immédiatement.
3.3 : Jour 5, autonomie contrôlée et premier point de vélocité
Fin de la première semaine. Le développeur doit être capable de prendre un ticket, le traiter de bout en bout et ouvrir une pull request sans assistance. Pas de ticket complexe à ce stade, mais des tickets de production réels qui font avancer votre roadmap.
Faites un point de 30 minutes en fin de jour 5. Trois questions. Quels blocages avez-vous rencontrés ? Quelles parties du code sont encore floues ? De quoi avez-vous besoin pour doubler votre vélocité la semaine prochaine ? Les réponses vous diront si le profil est sur la bonne trajectoire ou si un ajustement est nécessaire.
Mesurez le concret : nombre de tickets traités, nombre de retours en code review, temps moyen entre l'ouverture d'un ticket et la pull request. Ces métriques deviennent votre baseline. Semaine 2, vous attendez une amélioration de 30 à 50 %. Semaine 3, le développeur doit être au rythme de croisière. Trois semaines d'onboarding, c'est ce que les autres vous vendent. Cinq jours avec un process structuré, c'est ce que ça prend réellement quand le recrutement technique a été fait sérieusement en amont.
Votre prochain sprint commence sans ce développeur
Chaque semaine sans bras supplémentaire sur votre front-end, c'est une feature qui ne sort pas, un client qui attend et un concurrent qui avance. Vous connaissez maintenant la méthode : grille de scoring avant le test, mini-projet calqué sur votre stack réelle, live coding pour valider le raisonnement, intégration en 5 jours avec code review dès le jour 3. Le process existe. Les profils React francophones à Madagascar existent. La seule variable qui manque, c'est votre décision. TARAM recrute, teste et intègre un développeur front-end dédié exclusivement à votre équipe. Un développeur, un client, zéro mutualisation. Pendant que vous relisez cet article, quelqu'un d'autre est en train de signer.
