1 – Rédiger une fiche de poste front-end qui filtre les bons profils offshore
Une fiche de poste générique attire des candidatures génériques. Pour un développeur front-end offshore, le document doit répondre à des contraintes que vos offres françaises ignorent : fuseau horaire, autonomie technique sans pair review instantanée, maîtrise d'outils de communication asynchrone. Voici comment structurer chaque section.
1.1 : Les 6 rubriques non négociables de votre fiche de poste
Votre fiche de poste doit contenir exactement six blocs. Le premier : le contexte projet. Décrivez votre produit en trois phrases, la stack existante (React, Vue, Next.js, Tailwind, etc.), et le volume de commits hebdomadaire attendu. Le deuxième : les responsabilités quotidiennes. Pas de liste générique type "participer au développement". Écrivez : "Intégrer les maquettes Figma en composants React réutilisables", "Corriger les régressions CSS cross-browser dans un délai de 4h", "Rédiger les tests unitaires Jest pour chaque composant livré". Le troisième : le stack technique obligatoire versus souhaité. Séparez clairement ce qui est requis dès le jour 1 de ce qui peut être appris en poste. Le quatrième : les outils de collaboration (Git, Jira/Linear, Slack, Loom). Le cinquième : les horaires de chevauchement avec l'équipe française. Madagascar est en GMT+3, la France en GMT+1 ou GMT+2 selon la saison. Précisez la plage commune attendue. Le sixième : les critères de performance à 30, 60 et 90 jours. Un candidat sérieux veut savoir comment il sera évalué.
1.2 : Les erreurs qui attirent les mauvais profils
Première erreur : lister 15 technologies. Un front-end malgache solide maîtrise deux ou trois frameworks. Si vous demandez React, Vue, Angular, Svelte, Ember et Lit dans la même offre, vous signalez que vous ne savez pas ce que vous cherchez. Les bons candidats passent leur chemin. Deuxième erreur : ne pas mentionner le niveau de français attendu. À Madagascar, le français est langue officielle, mais le niveau varie. Précisez si votre développeur devra participer à des calls clients ou uniquement communiquer par écrit avec l'équipe technique. Troisième erreur : copier une fiche de poste française sans adapter le contexte. Un développeur offshore a besoin de savoir s'il aura un référent technique côté client, s'il accédera au repository dès le jour 1, et quel est le processus de code review. Omettre ces informations, c'est garantir un décalage d'attentes dans les deux premières semaines. Notre guide sur l'outsourcing RH B2B détaille comment structurer le sourcing sans perdre votre culture d'entreprise.
1.3 : Modèle de fiche de poste prêt à l'emploi
Voici la structure exacte à copier. Intitulé : Développeur Front-End React.js (ou Vue.js) dédié, temps plein. Contexte : "[Nom de l'entreprise] développe [produit/service]. L'équipe technique compte [X] personnes. Vous serez le [premier/deuxième] front-end et travaillerez directement avec [lead dev / CTO / product owner]." Stack requis : React 18+, TypeScript, Tailwind CSS, Git, Jest. Stack apprécié : Next.js, Storybook, Cypress. Responsabilités : intégration Figma-to-code, développement de composants UI, tests unitaires, participation aux sprints de deux semaines, documentation technique des composants dans Storybook. Outils : GitHub, Linear, Slack, Loom, Figma (lecture). Horaires : présence obligatoire de 9h à 13h heure de Paris. Évaluation : premier composant livré à J+5, autonomie sur le design system à J+15, vélocité cible de [X] story points par sprint à J+30. Ce modèle a été testé sur des recrutements réels. Il filtre environ 70 % des candidatures non pertinentes dès la lecture.
2 – Tester les compétences techniques d'un front-end offshore sans perdre une semaine
Un CV ne prouve rien. Un portfolio non plus : impossible de vérifier qui a réellement écrit le code. Votre processus de test doit évaluer cinq dimensions en moins de 48 heures, sans mobiliser votre lead dev plus de deux heures au total.
2.1 : Les 5 épreuves de votre grille d'évaluation technique
Épreuve 1 : le quiz technique chronométré (20 minutes). 15 questions sur les fondamentaux : closures JavaScript, cycle de vie React, spécificité CSS, accessibilité ARIA. Pas de questions piège, uniquement des bases que tout front-end confirmé maîtrise sans réfléchir. Épreuve 2 : le challenge de code en direct (45 minutes, en visio). Donnez une maquette Figma simple (une carte produit avec variantes) et demandez au candidat de la coder en partage d'écran. Vous observez sa méthode, son organisation des fichiers, et sa capacité à penser en composants. Épreuve 3 : la revue de code (30 minutes). Soumettez un composant React avec cinq erreurs intentionnelles (mauvaise gestion du state, fuite mémoire dans un useEffect, accessibilité manquante). Le candidat doit identifier et corriger. Épreuve 4 : l'intégration responsive. Envoyez une maquette mobile-first et évaluez le rendu sur trois breakpoints. Épreuve 5 : l'entretien de mise en situation (20 minutes). "Votre PR est bloquée depuis 24h, le reviewer est en congé, le sprint se termine demain. Que faites-vous ?" Vous testez l'autonomie et la communication, deux qualités critiques pour un profil à distance.
2.2 : Barème de scoring et seuils d'élimination
Chaque épreuve est notée sur 20. Le score total est sur 100. Seuil de passage : 65/100 minimum, avec aucune épreuve en dessous de 10/20. Un candidat qui score 18 en quiz mais 6 en code review n'est pas fiable en production. Pondérez davantage les épreuves 2 et 3 (coefficient 1.5 chacune) : elles reflètent le travail quotidien réel. Le quiz et l'intégration responsive restent en coefficient 1. L'entretien de mise en situation en coefficient 1. Ce barème donne un score pondéré sur 130. Le seuil passe à 85/130. Documentez tout dans un tableur partagé avec votre lead dev. Si vous confiez le recrutement à un partenaire comme TARAM, la grille est co-construite avec vous et les résultats vous sont présentés avant toute décision. Vous gardez le dernier mot sur le profil retenu. L'article sur le développement React.js offshore à Madagascar détaille les standards de qualité à exiger sur une équipe front-end.
2.3 : Ce que le test ne mesure pas et comment le compenser
Aucun test technique ne mesure la fiabilité dans la durée, la capacité à poser les bonnes questions quand un brief est flou, ni la réaction face à un feedback direct. C'est exactement pour cela que l'intégration des deux premières semaines est un test grandeur nature. Prévoyez une période d'essai structurée avec des jalons clairs (voir section 3). Un autre angle mort : la compatibilité avec vos outils. Un développeur qui code parfaitement en local mais n'a jamais utilisé Linear ou GitHub Actions perdra deux jours à se configurer. La solution : incluez dans votre test une étape où le candidat clone un repo d'exemple, crée une branche, pousse un commit et ouvre une PR. Dix minutes, zéro ambiguïté. Enfin, le test ne mesure pas la qualité de l'infrastructure du candidat. Avec TARAM, chaque collaborateur travaille sur une machine Ryzen 7 avec connexion fibre et 5G de secours. Ce n'est pas un détail : un front-end qui met 40 secondes à compiler un build Next.js ne livre pas au même rythme qu'un développeur équipé correctement.
3 – Intégrer votre développeur front-end malgache en 15 jours : le plan jour par jour
Le recrutement ne s'arrête pas à la signature. La majorité des échecs offshore viennent d'un onboarding bâclé. Voici le plan d'intégration découpé en trois phases : accès et contexte (J1 à J3), première livraison guidée (J4 à J10), autonomie validée (J11 à J15).
3.1 : J1 à J3, les accès, le contexte et le premier commit
Jour 1 : le développeur reçoit ses accès Git, Slack, Figma, outil de gestion de projet, VPN si nécessaire. Pas "dans la journée". Avant 10h heure de Paris. Chaque heure perdue à attendre un accès érode la confiance du nouveau collaborateur. Il reçoit aussi un document de contexte de 3 pages maximum : architecture front, conventions de nommage, workflow de branche, et contact du référent technique. Jour 2 : call de 45 minutes avec le référent technique. Tour du repo, explication du design system, démonstration d'un cycle complet ticket-branche-PR-merge. Le développeur clone le repo, installe l'environnement, et fait tourner le projet en local. Jour 3 : premier commit. Un ticket simple, volontairement facile (corriger un padding, ajouter un alt text manquant, renommer un composant). L'objectif n'est pas la difficulté technique. C'est de valider que la chaîne complète fonctionne : le dev prend un ticket, code, pousse, ouvre une PR, reçoit une review, et merge. Le guide sur le transfert de compétences offshore détaille comment rendre un dev malgache opérationnel en deux semaines sans improviser.
3.2 : J4 à J10, la première livraison réelle et la boucle de feedback
À partir du jour 4, le développeur travaille sur un vrai ticket de production. Choisissez un ticket de complexité moyenne : un nouveau composant UI avec deux ou trois variantes, connecté à une API existante. Ni trop simple (il ne progressera pas), ni trop complexe (il se bloquera seul). Instaurez un point quotidien de 15 minutes entre J4 et J10. Pas un stand-up formel avec toute l'équipe. Un échange direct entre le dev et son référent, en visio ou en vocal Slack. L'objectif : détecter les blocages avant qu'ils ne deviennent des retards. Évaluez trois choses : la qualité du code livré, le respect des conventions du projet, et la capacité du développeur à communiquer un blocage au lieu de le subir en silence. Ce dernier point est critique. Piloter une équipe offshore sans manager intermédiaire explique comment structurer ces rituels sans y passer vos journées. À J10, le développeur doit avoir livré au moins deux tickets en production et reçu au minimum trois code reviews. Si ces jalons ne sont pas atteints, il faut ajuster le niveau d'accompagnement, pas attendre la fin du mois.
3.3 : J11 à J15, l'autonomie validée et les critères de confirmation
Les cinq derniers jours servent à prouver l'autonomie. Le développeur prend ses tickets seul dans le backlog, estime sa charge, et gère son cycle de livraison sans que le référent intervienne. Le point quotidien passe à un point tous les deux jours. Trois critères de confirmation à J15. Premier critère : le développeur a livré au moins quatre tickets sans régression en production. Deuxième critère : ses PR sont acceptées en moins de deux itérations de review en moyenne. Troisième critère : il a posé au moins trois questions pertinentes de manière proactive (ce qui prouve qu'il lit le contexte, anticipe les problèmes, et communique au lieu de deviner). Si les trois critères sont remplis, le développeur est confirmé. Si un critère manque, prolongez la phase d'accompagnement d'une semaine avec un plan d'action ciblé. À ce stade, vous avez un front-end dédié, intégré dans votre stack, aligné sur vos conventions, qui produit au même rythme qu'un membre de votre équipe française. Notre article sur la structuration du ramp-up offshore explique pourquoi ces 15 premiers jours déterminent la réussite ou l'échec des 12 mois suivants.
Votre prochain front-end est prêt à coder. Vous, non.
Vous avez maintenant la fiche de poste, la grille de test et le plan d'intégration. Trois documents que vos concurrents n'ont pas et qu'aucun prestataire offshore ne publie parce qu'ils préfèrent que vous dépendiez de leur processus opaque. Chaque jour sans front-end dédié, c'est du backlog UI qui s'accumule, des tickets Figma qui vieillissent, et un lead dev qui compense seul. Votre dev français à 5 000 euros par mois ne suffit plus, et le prochain freelance ghostera comme le précédent. TARAM recrute votre développeur front-end malgache sur mesure, le teste avec vous selon cette grille, l'équipe en Ryzen 7 et fibre, et le rend opérationnel dans votre repo en 15 jours. Un collaborateur dédié, un seul client, intégré dans votre Slack comme s'il était au bout du couloir. Contactez-nous maintenant. Pendant que vous hésitez, votre backlog grandit.
