Développement en France ou offshore : comparer le coût apparent et le coût réel

France, nearshore, offshore : le tableau comparatif

On parle de nearshore pour un prestataire dans un pays proche, souvent dans un fuseau horaire voisin (Europe de l'Est, Maghreb), et d'offshore pour un pays éloigné (Asie du Sud, par exemple). Le taux journalier apparent varie fortement d'un pays à l'autre ; le coût total beaucoup moins qu'on ne le croit.

Coût apparent ou coût réel : où passe la différence ?

Le taux journalier n'est qu'un des termes de l'équation. Le coût réel d'un projet externalisé loin additionne des postes qui n'apparaissent pas sur le devis :

• Les spécifications : un prestataire distant ne peut pas deviner ce qui n'est pas écrit. Il faut des documents beaucoup plus détaillés, rédigés par quelqu'un de chez vous ou par un consultant intermédiaire.
• Le pilotage : réunions décalées, relectures, arbitrages. Ce temps de vos équipes est payé, même s'il n'est pas facturé.
• Les allers-retours : une ambiguïté qui se règle en cinq minutes au téléphone prend une journée avec le décalage horaire.
• Les reprises : un écran conforme à la spécification mais inutilisable sur le terrain doit être refait.
• La maintenance : si l'équipe change, chaque évolution commence par une phase de redécouverte du code.

Ces postes pèsent d'autant plus que le logiciel est spécifique. Pour un site vitrine standard, l'écart de taux peut l'emporter. Pour un logiciel métier, c'est rarement le cas.

Pourquoi les spécifications coûtent-elles plus cher à distance ?

Un logiciel métier encode des pratiques qui ne sont écrites nulle part. Exemple : « une intervention urgente passe devant les autres, sauf si le technicien est déjà sur un chantier à moins de trente minutes ». Ce genre de règle émerge en observant le travail réel, en parlant avec le chef d'équipe, en revenant avec une maquette.

Un prestataire proche peut faire ce travail de découverte lui-même pendant le cadrage. À distance, il doit être fait avant, et transmis sous forme de documents. Si le document oublie une exception, le logiciel l'oubliera aussi. C'est une cause de dérive classique quand un logiciel de gestion est développé loin de ceux qui l'utiliseront.

Si vous envisagez malgré tout un prestataire distant, investissez d'abord dans un cadrage réalisé au contact de vos équipes, puis transmettez un dossier complet : profils d'utilisateurs, maquettes validées, règles de gestion avec leurs exceptions, jeux de données d'exemple et liste du hors périmètre. Le guide cahier des charges d'un logiciel métier en donne la structure.

Fuseau, langue et qualité : les frictions du quotidien

Avec quatre ou cinq heures de décalage, la fenêtre de travail commune se réduit à une partie de la journée. Les questions posées le soir trouvent réponse le lendemain, et une anomalie bloquante découverte en production un vendredi après-midi peut attendre.

La langue ajoute une couche. Le vocabulaire d'un métier français (bon de livraison, situation de travaux, avoir, acompte) se traduit mal, et les messages affichés aux utilisateurs doivent être relus. La qualité, elle, dépend du prestataire et non du pays : il existe d'excellentes équipes partout. Mais à distance, vous avez moins de moyens de la vérifier en cours de route, d'où l'importance de versions testables fréquentes et de tests automatisés.

Que dit le RGPD quand les développeurs accèdent aux données depuis l'étranger ?

Dès que des données personnelles (clients, salariés, patients) sont transférées vers un pays situé hors de l'Union européenne, le RGPD impose un cadre. Selon la CNIL, le transfert est possible vers un pays couvert par une décision d'adéquation de la Commission européenne ; à défaut, il faut des garanties appropriées, en pratique les clauses contractuelles types de la Commission ou des règles d'entreprise contraignantes.

Concrètement, si l'équipe distante travaille sur une copie de la base de production ou accède au serveur, ce point doit être traité dans le contrat de sous-traitance prévu par l'article 28 du RGPD. Le plus simple reste de faire travailler les développeurs sur des données anonymisées, c'est-à-dire qui ne permettent plus d'identifier les personnes. Le guide RGPD et logiciel métier détaille ces obligations.

Dans quels cas l'offshore ou le nearshore se justifient-ils ?

• Vous avez une DSI ou un responsable technique capable de rédiger des spécifications exhaustives et de relire le code.
• Le projet est technique et peu dépendant du métier : migration de version, développement d'une API documentée, tests.
• Vous avez besoin d'une capacité importante sur une longue durée, avec une équipe stable et un pilotage interne solide.
• Les données traitées ne sont pas personnelles, ou le cadre de transfert est en place.

Dans quels cas un prestataire en France est-il préférable ?

• Le besoin n'est pas encore entièrement formalisé et doit être découvert avec les utilisateurs.
• Vous n'avez pas de responsable technique pour piloter à distance.
• Le logiciel touche la réglementation française : facturation électronique, export comptable, obligations sectorielles.
• Le logiciel sera maintenu et enrichi pendant des années, avec des échanges réguliers.
• Vous voulez pouvoir rencontrer l'équipe et la faire venir sur le terrain.

Ce que propose YMHB Web

YMHB Web développe depuis la France, avec des bureaux à Lyon et à Dijon : rencontres en personne autour de ces deux villes, échanges à distance ailleurs, toujours dans le même fuseau horaire. Notre argument n'est pas le taux journalier mais le coût total : un cadrage fait chez vous, une version testable en permanence pour vérifier sans attendre, un code documenté qui vous appartient. Si votre projet a les caractéristiques d'un bon projet offshore et que vous avez le pilotage en interne, nous vous le dirons. Pour comparer les profils de prestataires, voir freelance, agence ou ESN.