Votre développeur offshore ne convient pas : le protocole pour trancher vite et ne pas perdre votre trimestre

Un développeur qui ne convient pas ne se révèle pas le jour 1. Les signaux sont progressifs, souvent masqués par la politesse, la distance, et votre propre envie que ça fonctionne. Voici les trois catégories de signaux que vous devez surveiller dès la première semaine.

C'est le signal le plus objectif, et pourtant celui qu'on rationalise le plus longtemps. Votre lead ou votre développeur senior passe plus de temps à relire, commenter et corriger les pull requests qu'il n'en gagnerait à coder lui-même la feature. Les conventions de nommage ne sont pas respectées. Les tests unitaires sont absents ou superficiels. Le code fonctionne mais n'est pas maintenable.

La distinction à faire est simple : un développeur en phase d'onboarding produit du code correct mais lent. Un développeur qui ne convient pas produit du code qu'il faut réécrire. La différence se mesure sur les deux premières semaines. Si après quinze jours d'accès complet au repo, à la documentation et aux outils du projet, chaque merge request déclenche une session de refactoring, vous n'avez pas un problème d'intégration. Vous avez un problème de niveau.

Quantifiez le ratio : temps passé en review / temps gagné par la livraison. Si ce ratio dépasse 50 %, le profil vous ralentit au lieu de vous accélérer. C'est le premier seuil de décision. Pour comprendre comment structurer des protocoles de contrôle qualité dès le départ, lisez Externaliser son développement sans perdre en qualité : les protocoles qui séparent le code fiable du code jetable.

Les premiers jours, le développeur pose des questions. C'est normal et même sain. Ce qui n'est pas normal : après deux semaines, il ne pose toujours aucune question pertinente sur le métier, ne reformule jamais un ticket ambigu, et attend passivement qu'on lui dise exactement quoi coder, ligne par ligne.

L'autre versant du problème : les délais de réponse qui s'allongent. Un message Slack envoyé à 9h qui obtient une réponse à 14h sans justification. Des stand-ups où le dev dit "j'avance" sans détailler sur quoi. Des daily reports vides ou copiés-collés d'un jour à l'autre. Ces signaux indiquent soit un manque d'engagement, soit un profil qui travaille pour plusieurs clients en parallèle, ce qui est exactement le scénario que vous cherchiez à éviter en choisissant un développeur dédié.

Un développeur intégré à votre équipe communique comme un membre de votre équipe. Si après le premier sprint complet il ne le fait toujours pas, la suite ne sera pas meilleure. Le problème ne vient pas du décalage horaire (Madagascar est sur le même fuseau que la France en été, une heure de décalage en hiver). Le problème vient du profil.

Vous avez transmis la documentation, donné accès au Git, organisé les sessions de passation, partagé les SOP. Pourtant chaque ticket nécessite un appel de cadrage. Chaque feature revient avec une interprétation décalée. Votre équipe passe plus de temps à expliquer qu'à collaborer.

Le piège ici est de confondre patience et complaisance. Un développeur compétent sur votre stack technique gagne en autonomie de façon visible, semaine après semaine. Moins de questions sur les mêmes sujets, des propositions techniques spontanées, une compréhension progressive du contexte métier. Si cette progression n'existe pas, vous n'avez pas un problème de documentation (consultez SOP documentation équipe offshore : le format en 6 sections qui tue les questions répétitives et les erreurs de process pour vérifier que vos process sont clairs). Vous avez un profil qui ne peut pas monter au niveau requis par votre projet.

Fixez un jalon clair : à la fin du premier mois, le développeur doit être capable de prendre un ticket de complexité moyenne et de le livrer sans appel de cadrage supplémentaire. S'il n'y arrive pas, vous avez votre réponse.

Attendre d'avoir un développeur qui ne convient pas pour se demander quoi faire, c'est trop tard. La garantie se négocie avant la signature. Voici les trois mécanismes contractuels qui font la différence entre un trimestre perdu et un remplacement en deux semaines.

La plupart des prestataires offshore affichent une "garantie de remplacement" dans leurs conditions. La réalité est souvent différente : délais flous, processus inexistant, profil de remplacement inférieur au premier. Ce que vous devez exiger, c'est une période d'évaluation formalisée avec des critères objectifs de validation.

Chez TARAM, la logique est inversée. Le développeur est en CDI local à Madagascar, et une période d'essai structurée est intégrée au démarrage. Si le profil ne convient pas selon des critères définis avec vous (qualité du code, autonomie, communication, respect des deadlines), le remplacement est déclenché sans frais supplémentaires. Ce n'est pas un geste commercial. C'est un mécanisme contractuel, parce que quand on recrute un développeur spécifiquement pour un client après des tests techniques et du live coding, on assume le résultat.

Ce qu'il faut vérifier avant de signer : la durée exacte de la période d'essai, les critères de non-validation, le délai de remplacement garanti, et surtout, si le prestataire a un vivier de profils disponibles ou s'il devra relancer un recrutement de zéro.

Un développeur qui part (ou qu'on remplace) sans passation, c'est du contexte métier qui disparaît, des choix d'architecture non documentés, et un nouveau dev qui repart de zéro sur des parties entières du code. C'est la deuxième perte de temps, après le mauvais recrutement initial.

Votre contrat doit prévoir une période de passation obligatoire entre l'ancien et le nouveau développeur. Même courte (trois à cinq jours), cette passation couvre les points critiques : architecture du projet, dépendances spécifiques, conventions de code non écrites, workflow de déploiement, et contexte métier sur les modules en cours.

Si votre prestataire ne prévoit pas cette passation, vous porterez seul le coût du transfert de connaissances. Chez TARAM, la passation est un protocole structuré : le management européen supervise le transfert, la documentation est mise à jour, et le nouveau développeur est évalué sur sa capacité à reprendre les tickets en cours, pas sur des exercices théoriques. Consultez Passation de poste vers une équipe offshore à Madagascar : le protocole de transfert sans perte ni dépendance pour voir le détail de ce protocole.

Vous avez identifié les signaux. Votre contrat prévoit (ou aurait dû prévoir) un mécanisme de remplacement. Reste la partie la plus difficile pour un dirigeant : décider. Voici le cadre de décision qui vous empêche de perdre un trimestre supplémentaire.

Trente jours. C'est le délai maximum pour évaluer si un développeur offshore convient à votre projet. Pas six mois, pas "après le prochain sprint", pas "quand il aura pris ses marques". Trente jours, avec des points de contrôle à J+7, J+15 et J+30.

À J+7, le développeur doit avoir livré au moins un ticket complet, même simple. Vous évaluez la qualité du code, le respect des conventions, et la communication. À J+15, il doit être capable de prendre un ticket de complexité moyenne sans appel de cadrage détaillé. Le ratio review/valeur doit s'améliorer visiblement. À J+30, il travaille en autonomie sur les tickets standards et commence à contribuer aux discussions techniques.

Si à J+30 vous en êtes encore à expliquer les bases, à corriger chaque livraison, ou à relancer pour obtenir une réponse, la décision est prise. Ne laissez pas la culpabilité ("on ne lui a peut-être pas assez expliqué") ou l'inertie ("relancer un recrutement, c'est pénible") vous faire perdre un trimestre de plus. Le coût d'un mauvais développeur ne se limite pas à son salaire : c'est le temps de votre équipe interne, le retard sur votre roadmap, et l'énergie de vos meilleurs éléments détournée vers du babysitting technique.

La crainte de beaucoup de dirigeants : "Si je dis que le dev ne convient pas, mon prestataire va mal le prendre, et la suite de la collaboration sera compliquée." Cette crainte est légitime si votre prestataire fonctionne comme une ESN classique, où le remplacement est perçu comme un échec commercial.

Chez un prestataire structuré, le remplacement fait partie du processus. Vous ne demandez pas une faveur. Vous activez une clause contractuelle. La bonne approche : factuelle, documentée, sans affect. "Voici les livrables des trente derniers jours, voici les points de non-conformité par rapport aux critères définis ensemble, voici les feedbacks de code review. Le profil ne correspond pas au niveau requis. Nous activons la procédure de remplacement."

Un prestataire qui réagit mal à ce type de demande vous donne une information précieuse : vous n'êtes pas avec le bon partenaire. TARAM considère le remplacement comme un indicateur de qualité, pas comme un problème. Quand le recrutement est fait sur-mesure avec validation client, les cas de remplacement sont rares. Mais quand ils arrivent, le processus existe et il fonctionne. Pour comprendre comment se structure le management de ces situations, consultez Manager un développeur à distance : les rituels, les outils et les erreurs qui coûtent six mois de roadmap.

Un remplacement bien exécuté ne vous fait pas perdre du temps. Il vous en fait gagner par rapport au scénario où vous gardez un profil inadapté pendant six mois. Faites le calcul : trois mois avec un dev qui produit à 30 % de la vélocité attendue, c'est 70 % de capacité perdue sur un trimestre. À quoi s'ajoute le temps de votre équipe en review, en corrections, en explications.

Le bon remplacement, c'est deux semaines de transition pour un développeur qui livre à 80 % de sa capacité cible dès le deuxième mois. Le coût de ces deux semaines est absorbé en moins d'un sprint par la différence de vélocité.

C'est aussi un signal fort pour votre équipe interne : vous ne tolérez pas la médiocrité, vous ne sacrifiez pas la qualité pour éviter un inconfort administratif. Vos développeurs internes savent que le renfort offshore est un vrai renfort, pas un poids supplémentaire à porter.

Si vous êtes dans cette situation aujourd'hui, ou si vous voulez éviter de vous y retrouver, la question n'est pas "faut-il externaliser ou pas". La question est "avec quel prestataire, et avec quelles garanties". TARAM recrute votre développeur sur-mesure, le teste sur votre stack, vous le présente avant toute décision, et assume le remplacement si le profil ne convient pas. Un développeur, un client, une infrastructure dédiée.