Développeur offshore : comment choisir le bon profil et le pays adapté ?

Un développeur offshore travaille pour votre entreprise depuis un pays éloigné, en indépendant ou chez un prestataire. Le terme dépend du point de vue du client et ne signifie pas « hors Union européenne » : depuis Paris, la Roumanie relève plutôt du nearshore.

Pour choisir un développeur offshore, suivez un ordre fixe. Cadrez d’abord le besoin, puis vérifiez les compétences et la collaboration sur un essai payé. Comparez enfin les pays qui conviennent à vos horaires et à votre langue de travail, puis à vos contraintes de données.

La nationalité d’une équipe ne dit rien de son niveau ni de son français ; ces deux points se vérifient sur la personne proposée. L’offshore convient mal à un besoin resté flou ou à un projet que personne ne pilote côté client. Écartez-le aussi quand vos contraintes de données l’excluent ou que l’économie attendue reste à démontrer.

Définir le travail avant de chercher un pays

Un projet neuf, une reprise de code existant et une maintenance applicative n’appellent pas le même profil. Le besoin cadré précise les technologies et leurs versions, puis les données manipulées. Il fixe les livrables attendus et leurs délais. Une reprise y ajoute l’état du dépôt et la documentation existante ; une maintenance, le volume de demandes et les délais de correction attendus.

Le document nomme aussi la personne qui arbitre les priorités et accepte le travail livré. Sans elle, chaque question du prestataire reste en attente. Un dirigeant sans compétence technique s’appuie en plus sur un référent technique indépendant des candidats. Ce freelance ou consultant relit le besoin et les devis, puis mène la revue de code.

Une liste de fonctionnalités ne suffit pas comme spécification. Il y manque les règles métier et les cas d’erreur, comme les volumes attendus et les critères d’acceptation. Notre fiche sur les différences entre offshore et nearshore rappelle comment ces termes se définissent depuis le pays du client.

Développeur offshore : freelance, agence ou équipe dédiée ?

Externaliser le développement logiciel suppose de choisir un fournisseur, puis un mode de facturation. Un développeur offshore travaille en freelance ou dans une agence, payé au forfait, au temps passé ou par une capacité réservée chaque mois.

Modes de collaboration avec un développeur offshore

Le forfait suppose une spécification complète ; sans elle, chaque précision devient un avenant. Le temps passé laisse le périmètre évoluer au fil des tickets, et le client paie chaque changement au tarif convenu.

Une équipe dédiée travaille pour vous à plein temps, mais elle reste salariée du prestataire, qui l’encadre. Vous fixez les priorités ; les consignes aux développeurs passent par leur responsable.

Le tarif d’un freelance comprend moins de frais de structure, et tout repose sur une seule personne. Vérifiez ce qui se passe en cas de congé ou de maladie, et qui reprend le code si la mission s’arrête. Une agence peut confier une partie du travail à des freelances. Demandez la liste des intervenants prévus et leur statut avant de signer.

Vérifier le profil et les pratiques de développement

Les logos affichés sur la plaquette d’un prestataire informatique ne disent pas qui, dans l’équipe, a écrit le code. Demandez le nom de la personne affectée à votre projet. Vérifiez ensuite que c’est elle que vous interrogez.

Relire une réalisation comparable avec son auteur

Demandez une référence autorisée, proche de votre projet par la technologie ou le métier, présentée par le développeur qui y a travaillé. Il doit pouvoir expliquer sa contribution personnelle et ce qu’il ferait autrement aujourd’hui.

Un entretien métier montre s’il comprend votre activité. Une revue de code menée par votre référent montre comment il répond aux objections. Pour votre projet, l’expérience sur la version que vous utilisez compte davantage qu’une technologie récente citée sur un CV.

Observer les tests et la capacité de maintenance

Un code maintenable s’accompagne de tests automatisés pertinents, d’une revue entre développeurs et de consignes d’installation qu’un tiers peut suivre. Ces éléments forment la preuve de compétence la plus utile.

Deux référentiels publics aident à formuler ces demandes. Le cadre SSDF du NIST (SP 800-218, version 1.1 de 2022) décrit des pratiques de développement sécurisé à demander à un fournisseur. Il ne classe pas les développeurs et ne garantit pas l’absence de défauts. Sa version 1.2 reste un projet.

L’ASVS de l’OWASP, en version 5.0.0 depuis mai 2025, répartit les exigences de sécurité des applications web en 3 niveaux. Un petit projet en retient une partie, choisie selon son risque, et une personne compétente vérifie les preuves.

Grille de preuves pour évaluer un développeur ou une équipe

Notez chaque critère de 0 à 2 et conservez la pièce qui justifie la note. La note 0 signale une preuve absente ou contradictoire, 1 une preuve partielle, 2 une preuve démontrée sur votre contexte.

Aucun total ne compense un critère éliminatoire fixé à l’avance, comme l’impossibilité de sécuriser les données ou d’obtenir les droits nécessaires. Les pondérations dépendent du projet et se décident avant de recevoir les offres.

Tester la collaboration sur un petit périmètre

L’entretien montre ce qu’un développeur sait expliquer, et l’essai comment il travaille sur votre code et dans vos délais.

Définir un essai rémunéré et représentatif

Un test rémunéré porte sur un petit ticket proche de votre travail réel. Le candidat comprend la demande, pose ses questions si besoin, puis modifie le code concerné dans le dépôt prévu. Il teste ensuite sa modification et la documente avant de remettre le résultat.

Bornez ce ticket à une fonction précise. Chaque candidat retenu reçoit le même ticket et les mêmes critères, pour comparer des résultats équivalents.

Fournissez des données de test, jamais la base de production, et des accès limités au seul périmètre de l’essai. Fixez avant le début la rémunération, la durée, les droits sur le code produit et la règle de décision, sans exiger de produit gratuit.

Un test technique générique, comme un exercice d’algorithmique, ne montre pas comment la personne comprend une demande ni comment elle signale un blocage.

Accepter le résultat sur des critères écrits

Les critères de recette sont écrits avant l’essai. À la fin, le client reçoit :

• le code, livré dans le dépôt convenu ;
• les tests et leur résultat ;
• une démonstration de la fonction livrée ;
• une documentation courte, suffisante pour relancer le projet ;
• un échange sur les choix faits et leurs limites.

Évaluez aussi la manière de signaler un blocage. Un développeur qui pose une question le premier jour évite un retard découvert à la livraison.

La décision de poursuivre suit la règle fixée au départ.

Quel pays choisir pour votre développement ?

Le tableau ci-dessous compare 5 pays de développement offshore pour une entreprise située en France métropolitaine. La mention « hors EEE » désigne un pays extérieur à l’Espace économique européen, qui réunit l’Union européenne, l’Islande, le Liechtenstein et la Norvège. Un lecteur installé hors de France recalcule les écarts horaires depuis son propre fuseau.

Comparer horaires, contraintes de données et organisation

Présélection de 5 destinations pour un client situé en France métropolitaine

Écart = heure locale moins heure de Paris, en hiver puis en été, d’après la base des fuseaux horaires de l’IANA (version 2026e). Grille ExternFlow, sans classement des compétences ni des prix.

Les écarts suivent les règles horaires en vigueur au 21 octobre 2026 et ne disent rien de la disponibilité d’une équipe. Le Maroc a mis fin à l’heure supplémentaire le 20 septembre 2026 et applique désormais l’heure GMT toute l’année. L’écart avec Paris passe donc à 2 h pendant l’heure d’été française. Vérifiez aussi les jours fériés et les astreintes de chaque destination, car un fuseau proche n’assure aucune permanence.

Au 21 octobre 2026, aucun des 4 pays hors EEE du tableau ne figure dans la liste des pays reconnus adéquats par la Commission européenne. Le travail reste possible. Chaque flux de données personnelles s’analyse alors, puis s’encadre si nécessaire par un outil prévu par le RGPD, comme les clauses contractuelles types.

La Roumanie appartient à l’Union. Choisir une équipe roumaine ne sécurise pas pour autant les accès ouverts ensuite depuis un pays tiers, par un sous-traitant ou un support de nuit.

Un serveur hébergé en France ne suffit pas non plus. Si un prestataire distinct accède à distance aux données depuis un pays tiers, la CNIL traite cet accès comme un transfert. Le risque dépend aussi des données confiées. Avec des données synthétiques et sans accès à la production, il n’a pas la même ampleur qu’une maintenance sur la base clients réelle.

Retenir deux destinations selon votre scénario

Quand le français est indispensable et les échanges fréquents, prospectez des équipes francophones à Madagascar, au Maroc ou en Tunisie. Testez ensuite la langue et la technique au même niveau d’exigence. Aucun pays ne dispense de l’épreuve.

Une exigence de localisation des traitements dans l’EEE oriente vers une offre roumaine, à comparer avec des offres françaises. Contrôlez alors la chaîne de sous-traitance et les accès réels.

L’Inde entre dans la présélection si votre équipe travaille en anglais et accepte un fonctionnement asynchrone. Demandez alors des horaires communs écrits. Une démonstration de passage de relais entre deux journées complète l’épreuve.

Aucune destination ne se choisit sur un tarif moyen. Pour les 3 destinations francophones du tableau, nos fiches des destinations d’externalisation donnent le détail pays par pays.

Comparer le coût complet des offres

Un taux journalier ne se compare ni à un salaire local ni au prix d’un service. Le salaire n’inclut ni les charges ni la marge du prestataire. Le prix d’un service, lui, porte sur un résultat livré.

Coût complet sur une période = cadrage + développement + pilotage interne et externe + contrôle qualité et reprises + outils et infrastructure + maintenance convenue + réversibilité + charges applicables.

Le cadrage se chiffre même quand votre équipe le réalise. Le pilotage interne se compte aussi en heures de vos salariés, pour écrire les tickets et répondre aux questions, puis pour réceptionner le travail. On l’oublie facilement en comparant des devis, alors qu’il dure tout le contrat.

Pour chaque offre, remplissez la formule dans cet ordre :

1. reportez les montants du devis dans les postes qu’il couvre ;
2. ajoutez le coût de vos heures internes de cadrage et de pilotage ;
3. transformez chaque poste resté vide en question écrite au prestataire ;
4. comparez les totaux sur la même période et le même périmètre.

Évitez les doubles comptes quand un forfait inclut déjà les outils ou la maintenance. Séparez aussi les montants certains des provisions pour risque, et vérifiez que les offres visent le même résultat et le même niveau de support.

Le coût de sortie comprend la documentation à jour et le temps de passation avec le prestataire suivant. Les charges applicables dépendent du montage contractuel ; les questions fiscales qu’il soulève dépassent ce guide et se vérifient avec un conseil.

Cet article ne donne aucun tarif par pays : un chiffre national sans source datée ni périmètre homogène ne permet aucune comparaison utile pour votre projet.

Encadrer le code, les accès et les données

Les droits sur le code et le contrôle des accès se règlent avant le premier ticket. Ils décident des conditions de sortie.

Prévoir les droits sur les livrables et dépendances

La remise des fichiers ne rend pas le client titulaire de tous les droits sur le logiciel. Le contrat la distingue du droit d’utiliser et de modifier ce logiciel. La cession des droits sur le code écrit pour vous relève d’une clause distincte, à négocier avant la signature. La propriété du code source se règle par une cession écrite avant la première livraison.

Le contrat liste aussi les licences des composants préexistants ou libres. Faites clarifier par écrit le droit qui régit le contrat et le titulaire des droits sur le code produit. Demandez enfin comment ce code passera à un autre prestataire.

Aucune formule générale ne garantit que le client possède tout dès le paiement. Selon l’enjeu et les pays, l’avis d’un conseil peut s’imposer ; notre analyse du droit applicable au contrat offshore traite le choix de la loi.

Organiser accès, confidentialité et réversibilité

Le contrôle du dépôt de code est fixé au contrat. Chaque développeur reçoit un compte nominatif. La production reste séparée des environnements de développement et de test.

Les mots de passe et les clés d’accès restent dans un coffre géré par le client, jamais dans le code. Retirez les droits d’une personne le jour où elle quitte le projet.

Le contrat traite la confidentialité et encadre les sous-traitants ultérieurs. Il couvre aussi la correction des anomalies et la maintenance, puis la gestion des changements demandés en cours de route. Il fixe enfin les conditions de reprise par un autre prestataire ou par votre équipe.

Une équipe dédiée qui reçoit ses consignes directement de vous soulève aussi des questions de droit du travail, que ce guide ne traite pas. Un conseil les examine quand le montage le justifie.

Piloter les premières livraisons sans dépendance

Les premières semaines se pilotent par des démonstrations régulières et des critères de recette écrits pour chaque ticket. Une démonstration à chaque fin d’itération, par exemple toutes les 2 semaines, corrige tôt un malentendu. Nommez aussi un interlocuteur de secours chez le prestataire.

Le suivi des anomalies se tient dans un outil de tickets auquel le client accède, ce qui garde l’historique si l’équipe change.

Un prestataire qui détient seul les comptes des outils du projet rallonge la sortie et peut la bloquer. Ouvrez donc à votre nom les comptes des outils suivants :

• le dépôt de code ;
• l’hébergement et le nom de domaine ;
• l’outil de tickets ;
• le coffre des mots de passe et des clés d’accès.

Faites vérifier par une personne extérieure à l’équipe qu’elle peut installer le projet avec la seule documentation. Ce test de reprise documentée révèle les dépendances que personne n’a écrites.

Chaque livraison s’accompagne d’une note de version qui décrit les changements et les points restés ouverts.

Si l’équipe utilise des assistants de codage par IA, précisez les données que ces outils peuvent recevoir et la revue humaine exigée. Le contrat nomme aussi la personne responsable du livrable et les tests attendus.

Notre guide pour préparer la réversibilité de l’externalisation détaille la sortie, du transfert des accès au test du plan de reprise.

Choisir une équipe dont vous avez vérifié le travail

Testez 2 ou 3 prestataires sur le même essai. Préparez un brief identique pour chacun, dans les 2 destinations retenues selon votre scénario, puis notez les résultats avec la grille de preuves.

Si aucune offre n’atteint le niveau fixé, revoyez d’abord le ticket et le cadrage. Élargissez ensuite la recherche à une autre destination compatible avec vos horaires et votre langue de travail. Avant tout engagement long, votre référent valide les points techniques. Un juriste relit les clauses sur les droits et les données quand l’enjeu le justifie.

Sources et références

Cet article s’appuie notamment sur le cadre SSDF du NIST, SP 800-218 version 1.1, publié en février 2022. Sa version 1.2 reste un projet soumis à consultation. Les exigences de sécurité applicative viennent de l’ASVS 5.0.0 de l’OWASP, publié en mai 2025. La page de la CNIL sur les transferts hors de l’Union européenne présente les outils d’encadrement. Son guide sur l’analyse d’impact des transferts traite l’accès à distance. La liste des décisions d’adéquation de la Commission européenne, relue le 21 octobre 2026, ne cite aucun des 4 pays tiers du tableau. Les écarts horaires sont calculés avec la base des fuseaux horaires de l’IANA, version 2026e. Le passage du Maroc à l’heure GMT est décrit dans l’article de TelQuel du 18 septembre 2026.