Le dirigeant raccroche, un peu sonné. Son dev offshore, basé à Manille, n'a pas répondu depuis trois jours. Le bouton « Payer » de son site e-commerce renvoie une erreur 500 depuis lundi matin, en pleine campagne newsletter. Le chiffre d'affaires fond à 4 200 €/jour de manque-à-gagner. Il m'appelle parce qu'on s'est croisé à la CCI de Besançon il y a six mois.
Je récupère le projet l'après-midi. Le dev offshore — sérieux, compétent — venait d'être hospitalisé. Personne ne savait. Pas de back-up, pas de team, pas de doc, code source dans son Bitbucket personnel auquel il était le seul à avoir accès.
Cet article n'est pas une attaque contre les développeurs offshore. Beaucoup sont excellents techniquement, et certains sont parmi les meilleurs dans leur spécialité. Mais le calcul « TJM offshore × jours = économie » manque les trois quarts du coût réel. Voici ce qui se cache derrière, et quand le local est objectivement le meilleur choix.
Le calcul que tout le monde fait, et pourquoi il est faux
Le pitch offshore tient en une ligne : « dev senior à 250 €/jour au lieu de 600 € en France ». Sur 60 jours de projet, ça fait 21 000 € au lieu de 36 000 €. 15 000 € d'économie nette. Tout dirigeant en bonne santé serait stupide de refuser, sur le papier.
Le problème, c'est que le coût d'un projet de développement n'est jamais « TJM × jours ». C'est :
- TJM × jours de dev réels
- + Coût de coordination (votre temps, vos équipes, votre PO)
- + Coût de la qualité variable (bugs en prod, refactorings, dette technique)
- + Coût d'opportunité (retards qui décalent un go-to-market)
- + Coût de transmission / fin de mission (récupérer le code, le brief, les comptes)
- + Coût juridique (en cas de litige)
Sur les cinq derniers postes, l'offshore part avec un handicap structurel — pas une fatalité, mais une réalité statistique qu'il faut peser.
Décalage horaire — l'argument le plus sous-estimé
Manille, c'est UTC+8 — 7 heures de décalage avec Paris. Bombay, UTC+5:30 — 4h30. Casablanca, UTC+1, à peine 1h. Tunis, UTC+1 aussi. Buenos Aires, UTC-3.
Un dev à Manille qui travaille de 9h à 18h locale est joignable de 2h à 11h heure française. Concrètement, vous lui envoyez une question à 14h depuis Besançon, il la lit à 7h locale le lendemain, vous répond avant 11h locale (donc avant 4h du matin chez vous). Vous lisez la réponse à 9h. Si la réponse soulève une nouvelle question, vous répondez. Il la lit à 6h locale le surlendemain.
Trois allers-retours = trois jours. Pendant lesquels le projet n'avance pas — il attend la prochaine question, la prochaine réponse. Multiplié par les centaines d'échanges d'un projet web typique, le retard cumulé se chiffre en semaines.
Un dev sur le même fuseau peut faire trois itérations dans la journée. Le projet avance trois fois plus vite, à TJM équivalent une fois ramené à la productivité horaire effective. C'est ce que j'expérimente depuis 14 ans en télétravail français pour des clients européens.
La sémantique métier — l'argument que personne ne facture
Vous expliquez votre métier à votre dev. C'est viticulture biodynamique dans le Jura. Vous parlez de « millésime », « cuvée parcellaire », « SO2 », « bio-cohérence », « biodynamie démétérisée », « millésimes vivants ». Votre dev parisien comprend la moitié, votre dev frontalier de Pontarlier comprend tout, votre dev de Lahore demande des définitions à chaque mot.
Pas parce qu'il est moins compétent. Parce que le vocabulaire métier français se traduit mal et n'a pas d'équivalents directs en anglais business. La traduction prend du temps, et chaque traduction est une opportunité de quiproquo. Vous croyez avoir expliqué « SO2 », il a compris « niveau de soufre » — pas tout à fait pareil.
Multiplié par la conformité réglementaire spécifique (AMF en fintech, ARS en santé, RGPD partout), les CGV françaises type, la TVA française, les bordereaux fournisseurs, l'URSSAF, la facturation Sage/EBP, la sémantique métier d'un dev local est un actif énorme et silencieux. Personne ne le facture, mais il vaut des semaines de coordination économisées.
Le coût juridique — le grand impensé
En cas de litige avec un freelance offshore, vos recours pratiques sont limités. Le tribunal de commerce compétent est celui de Casablanca, Manille ou Buenos Aires. Le contrat est en anglais (au mieux). Les CGV ont été écrites par votre prestataire et n'ont pas été révisées par votre avocat. Le code source est sur GitHub privé dont l'accès dépend de la bonne volonté du dev. Si le projet est mal livré, vous payez un avocat local pour récupérer 12 000 € — ça vaut rarement le coup.
Avec un freelance français, vous avez le tribunal de commerce de votre département (Besançon dans mon cas), des CGV en français standard, une facture TVA classique, un siret vérifiable sur societe.com. Aucun de ces éléments ne vous protège à 100 %, mais ils mettent les barrières d'entrée du litige au bon niveau. La plupart des conflits se règlent à l'amiable — parce que les deux parties savent qu'aller au tribunal serait possible.
Pour les missions sensibles (fintech, santé, données personnelles), c'est même un prérequis. Mon expérience fintech AMF chez Goin Invest depuis 4 ans n'est utilisable côté Suisse romande LSFin/FinSA qu'à condition de garder la traçabilité juridique européenne.
L'argument culturel qu'on n'ose plus dire
Travailler avec quelqu'un dont vous comprenez la culture professionnelle, c'est un facteur de qualité — pas de chauvinisme. Quand votre dev français dit « ça va être tendu pour la semaine prochaine », vous savez que ça veut dire « ça ne sera pas livré la semaine prochaine ». Quand un dev d'Asie du Sud dit la même phrase traduite, vous ne savez pas si c'est « tendu mais ça passera » ou « je ne veux pas vous dire non frontalement, donc je dis tendu ».
Ce n'est pas mieux ou moins bien. C'est différent. Les codes implicites de communication, le rapport à la hiérarchie, la façon de gérer un désaccord, l'expression d'une incertitude — tout ça impacte la qualité de la coordination. Avec un dev culturellement proche, vous économisez un temps considérable de re-interprétation.
Les grandes boîtes de service informatique offshore (TCS, Infosys, Cognizant) ont structuré des couches d'« onshore project manager » justement pour absorber cette friction. C'est efficace, mais ça coûte de l'argent — et ça gomme l'argument prix initial.
Quand l'offshore est le bon choix
Honnêteté oblige : l'offshore est parfois le bon choix. Voici les cas où je le recommande à mes prospects, sans hésiter :
- Mission ultra-cadrée, spécifications écrites détaillées, peu d'itérations attendues. Le décalage horaire devient un avantage : pendant que vous dormez, le code se construit.
- Compétence niche introuvable en local — un expert Solidity, un spécialiste Three.js, un dev embarqué Rust sur ARM. Le marché français est petit, l'offshore vous donne accès à un pool mondial.
- Budget incompatible avec le marché local. Si vous avez 5 000 € pour un projet qui demande 60 jours de dev, l'offshore est la seule option honnête. Mieux vaut un projet abouti à Manille qu'un projet jamais livré à Besançon.
- Maintenance évolutive sur un projet stable — petits ajouts, corrections de bugs, intégrations mineures. Le coût horaire devient déterminant, la coordination est légère.
Quand le local est objectivement supérieur
À l'inverse, je décourage l'offshore dans ces cas — où le surcoût apparent local est massivement compensé sur le total :
- Projet stratégique structurant qui définit votre activité pour 5+ ans. Le coût du mauvais choix dépasse la marge offshore.
- Métier réglementé (santé, finance, juridique, données personnelles). La conformité française et européenne est complexe à porter à distance.
- Itérations fréquentes avec un product owner non-tech. Vous allez avoir besoin de 30 micro-décisions par semaine. Le délai cumulé tue le projet.
- Sémantique métier dense (viticulture, BTP, secteur public, professions libérales spécialisées). Trop de vocabulaire intraduisible.
- Coordination physique régulière nécessaire (visites de chantier, démos terrain, ateliers avec les équipes).
Pour ces cas, un freelance local senior coûtera 30-50 % plus cher au TJM, mais le projet sera livré plus vite, mieux, avec moins de pertes de productivité côté client. Le bilan total est souvent en faveur du local.
Le bon découplage : pas binaire
La vraie réponse en 2026 n'est pas « local OU offshore ». C'est « comment je découpe mon projet pour mettre chaque tâche dans la bonne main ».
Sur un projet e-commerce typique : le design system et l'architecture en local (besoin d'itérations rapides avec le métier), l'intégration des templates en offshore (cadré, peu d'itérations), la maintenance évolutive en offshore (coût horaire critique), les développements stratégiques en local (déploiements sensibles, refonte de logique métier).
Cette stratégie hybride demande un pilote local — quelqu'un qui parle les deux langages, qui peut briefer l'offshore en spécifications précises, qui peut prendre la responsabilité de la livraison globale. C'est un rôle que je joue régulièrement, parce que je suis à la fois dev senior et capable de coordonner une équipe distribuée.
Ce qu'il faut retenir
Le débat « local vs offshore » est mal posé. La bonne question est : « quel est le bon partenaire pour cette mission précise, compte tenu de son enjeu, de sa durée, de sa sensibilité métier et juridique ? »
Pour 70 % des projets de PME française, la réponse est : un freelance senior local ou régional, avec si besoin du renfort offshore sur les tâches cadrées. Pas du chauvinisme — du calcul de coût total de possession sur 5 ans.
Si vous êtes en Bourgogne-Franche-Comté, on peut se rencontrer physiquement. Si vous êtes en Suisse romande, Neuchâtel est à une heure de Besançon. Pour le reste, voir les formats disponibles et la grille tarifaire.