Propriété intellectuelle : sécuriser la cession du code livré par un freelance hors UE

Introduction

Votre ESN peut perdre la maîtrise juridique d’un code livré si la propriété intellectuelle du freelance hors UE n’est pas correctement chaînée jusqu’au client final.

Le risque n’est pas théorique. Un développeur basé à Dubaï, Bali ou ailleurs hors Union européenne peut produire un code de qualité, respecter le planning et livrer en production. Mais si la cession de droits n’est pas opposable, incomplète ou mal répercutée dans la chaîne contractuelle, l’ESN reste exposée.

Le sujet se joue souvent avant même la mission. Pouvez-vous signer directement avec ce freelance ? Le contrat prévoit-il une cession de droits suffisamment précise ? Les droits sur le code source, la documentation, les correctifs et les livrables intermédiaires sont-ils bien transmis ? Le client final reçoit-il les droits attendus dans son contrat avec l’ESN ?

Pour une ESN, la propriété intellectuelle freelance hors UE doit être traitée comme un sujet de production, de conformité et de responsabilité contractuelle. Pas comme une simple clause standard.

À retenir
Lorsqu’un freelance tech hors UE intervient dans une chaîne ESN → client final, l’enjeu principal est la continuité des droits. Le freelance doit pouvoir céder les droits nécessaires à un fournisseur signable, qui les répercute ensuite proprement à l’ESN, puis au client final selon le périmètre prévu.

Pourquoi la propriété intellectuelle devient sensible avec un freelance hors UE

Avec un freelance français ou une société française, l’ESN dispose généralement de repères contractuels connus : droit français, facturation locale, identification claire du fournisseur, recours plus lisible en cas de litige.

Avec un freelance hors UE, plusieurs frictions apparaissent.

Le freelance peut être résident fiscal réel à l’étranger, avec une entité locale ou un statut indépendant non familier pour l’ESN. Son contrat peut relever d’un droit étranger. Ses factures peuvent être difficiles à intégrer dans les process achats. Le client final peut refuser certains fournisseurs non européens pour des raisons de conformité, de sécurité ou de devoir de vigilance.

La propriété intellectuelle se retrouve alors au cœur du problème.

L’ESN vend une prestation à son client final. Cette prestation peut inclure du code source, des scripts, des interfaces, des pipelines CI/CD, des architectures, des tests automatisés, de la documentation technique ou des correctifs. Si une partie de ces livrables est produite par un freelance hors UE, l’ESN doit pouvoir démontrer qu’elle dispose des droits suffisants pour les livrer, les modifier, les maintenir et les céder ou concéder au client final.

Sans cette continuité, le client final peut contester la conformité de la livraison. L’ESN peut se retrouver entre un client exigeant et un freelance juridiquement difficile à actionner.

Ce que l’ESN doit sécuriser sur le code livré

La propriété intellectuelle ne se résume pas à une phrase du type « le prestataire cède tous ses droits ».

Pour un code livré, plusieurs éléments doivent être vérifiés.

Le périmètre des livrables

Le contrat doit identifier ce qui est concerné par la cession de droits.

Cela peut inclure :

• le code source ;
• le code objet ;
• les scripts de déploiement ;
• les tests unitaires et automatisés ;
• la documentation technique ;
• les schémas d’architecture ;
• les correctifs ;
• les développements spécifiques ;
• les livrables intermédiaires validés ;
• les éléments créés dans le cadre du bon de commande.

Plus le périmètre est flou, plus le risque augmente. Le client final attend souvent une exploitation complète du code livré. L’ESN doit donc éviter un décalage entre ce qu’elle promet au client et ce que le freelance lui transmet réellement.

Les droits transmis

Une cession de droits doit couvrir les usages attendus.

Pour un projet tech, les droits pertinents portent notamment sur la reproduction, la représentation, l’adaptation, la modification, la traduction, l’intégration, la distribution interne ou externe, la maintenance, l’évolution et l’exploitation du code dans les environnements du client final.

L’enjeu est de rester cohérent avec le contrat principal. Si l’ESN s’engage à transférer au client final un droit d’usage étendu, une propriété pleine sur des développements spécifiques ou une licence d’exploitation interne, le contrat en amont avec le fournisseur doit être aligné.

C’est le principe du dos-à-dos contractuel.

La durée, le territoire et les modes d’exploitation

En droit français, une cession de droits doit être suffisamment déterminée. La durée, le territoire et les modes d’exploitation doivent être traités avec soin.

Lorsque le freelance est hors UE, la tentation est d’utiliser un contrat court, générique ou inspiré d’un modèle anglo-saxon. Cela peut créer une incertitude si le client final impose ensuite une lecture stricte de la cession.

L’ESN doit pouvoir justifier que les droits reçus couvrent ses propres engagements.

Les composants tiers et l’open source

Le code livré peut contenir des bibliothèques open source, des snippets, des composants SaaS, des frameworks ou des éléments générés à partir d’outils tiers.

La question n’est pas seulement de savoir qui a écrit le code. Il faut aussi savoir si le freelance avait le droit d’intégrer chaque composant dans le livrable.

Une clause utile doit imposer une déclaration des composants tiers utilisés, des licences applicables et des éventuelles restrictions. Certaines licences open source peuvent imposer des obligations de redistribution, de mention ou de partage du code modifié. Ces points doivent être visibles avant livraison au client final.

Point de vigilance ESN
Un client final peut accepter l’open source. Il accepte rarement de découvrir après coup une licence incompatible avec son usage prévu. Le sujet doit être cadré dès le bon de commande et suivi pendant la prestation.

Le risque principal : une chaîne de droits rompue

Dans une chaîne de sous-traitance, chaque maillon doit transmettre ce qu’il a réellement reçu.

Le freelance hors UE crée le code. Le fournisseur contractuel de l’ESN doit recevoir les droits nécessaires. L’ESN doit ensuite disposer des droits suffisants pour exécuter son contrat avec le client final. Le client final doit recevoir ce qui lui a été promis.

Si un maillon est faible, toute la chaîne devient contestable.

Le problème apparaît souvent dans trois cas.

Premier cas : l’ESN contractualise directement avec le freelance hors UE, mais le contrat est trop léger. La facture existe, le code est livré, mais la cession de droits est imprécise.

Deuxième cas : le freelance utilise une entité étrangère difficile à valider par les achats. Le client final refuse la sous-traitance ou demande des garanties que l’ESN ne peut pas produire rapidement.

Troisième cas : le contrat avec le client final prévoit une cession large, mais le contrat en amont ne permet qu’un usage limité. L’ESN vend alors plus de droits qu’elle n’en détient.

C’est précisément ce décalage qu’il faut éviter.

Sous-traitance tech : ce que le client final regarde réellement

Le client final ne s’intéresse pas seulement au CV du développeur. Il regarde la conformité de la chaîne.

Dans un contexte ESN, les questions reviennent souvent :

• qui est le fournisseur contractuel de l’ESN ?
• le freelance hors UE intervient-il comme sous-traitant identifié ?
• les livrables sont-ils définis ?
• le code source est-il remis selon les standards attendus ?
• les droits sont-ils transférés selon le contrat principal ?
• les obligations de confidentialité sont-elles opposables ?
• les données du client final sont-elles protégées ?
• les composants tiers sont-ils documentés ?
• le recours en cas de litige est-il lisible ?

La propriété intellectuelle est donc liée à l’acceptabilité fournisseur. Un freelance peut être excellent techniquement, mais non signable par une ESN ou par son client final.

Le rôle de l’ESN est alors de rendre la prestation contractualisable sans créer de zone grise.

Pourquoi un simple contrat freelance ne suffit pas toujours

Un contrat direct avec un freelance hors UE peut fonctionner dans certaines configurations. Mais il doit être cohérent avec les exigences achats, juridiques, fiscales et opérationnelles de l’ESN.

Les difficultés les plus fréquentes concernent :

• l’identification du cocontractant ;
• la loi applicable ;
• la compétence juridictionnelle ;
• la preuve de la cession de droits ;
• la conformité des factures ;
• le traitement TVA ou autoliquidation selon le flux ;
• la sous-traitance déclarée au client final ;
• la confidentialité ;
• la protection du code livré ;
• la responsabilité en cas de réclamation IP.

Sur le plan fiscal, il faut aussi respecter le principe de réalité. Un freelance hors UE doit être réellement résident fiscal hors UE, avec une activité remote réelle, sans présence organisée en France qui créerait une situation artificielle. Une configuration saine repose sur une résidence effective, une autonomie opérationnelle et une absence de structure-coquille. Une entité étrangère fictive ou utilisée pour masquer une activité en France constitue une configuration abusive à écarter.

StelarWork ne vend pas une optimisation fiscale. Lorsqu’un freelance est déjà résident fiscal réel hors UE, StelarWork retire une friction administrative et contractuelle pour l’ESN. La conformité repose sur la réalité de la situation, pas sur un montage.

Le bon réflexe : contractualiser la prestation, pas une personne mise à disposition

Pour réduire le risque, l’ESN doit raisonner en prestation.

Le bon document n’est pas seulement une commande de temps. Il doit décrire un périmètre, des livrables, des critères d’acceptation et une responsabilité fournisseur.

Cela permet d’éviter une confusion entre une ressource disponible au quotidien et une prestation structurée. Dans une relation conforme, le fournisseur livre un résultat défini, dans un cadre contractuel clair, avec une chaîne de responsabilité.

Ce point est important pour la propriété intellectuelle. Plus les livrables sont identifiés, plus la cession de droits est maîtrisable.

Un bon de commande doit donc relier :

• le périmètre technique ;
• les livrables attendus ;
• les modalités de validation ;
• les droits cédés ou concédés ;
• les obligations de confidentialité ;
• les règles sur les composants tiers ;
• les engagements de non-violation de droits ;
• les obligations applicables au client final.

Comment StelarWork structure la chaîne entre l’ESN et le freelance hors UE

StelarWork intervient comme fournisseur français contractant en son nom propre avec l’ESN.

L’ESN dispose ainsi d’un cocontractant français, avec une facturation française et un cadre contractuel lisible. StelarWork contractualise ensuite avec le freelance hors UE pour organiser la prestation, le paiement et les obligations de conformité.

L’objectif est de transformer une relation difficile à signer en chaîne fournisseur exploitable par une ESN.

Sur la propriété intellectuelle, cela permet de structurer le transfert des droits en amont et en aval :

• le freelance hors UE cède ou concède à StelarWork les droits nécessaires sur les livrables concernés ;
• StelarWork répercute contractuellement à l’ESN les droits nécessaires à l’exécution du contrat ;
• l’ESN peut ensuite respecter ses engagements envers le client final, selon le périmètre prévu au contrat principal.

Cette logique vise à éviter une rupture de chaîne. Elle ne remplace pas l’analyse contractuelle du client final, mais elle donne à l’ESN un fournisseur français mieux aligné avec ses contraintes achats, conformité et livraison.

Ce que StelarWork apporte à l’ESN
StelarWork n’agit pas comme représentant du freelance. StelarWork contracte en son nom propre avec l’ESN. La relation est construite autour d’une prestation, de livrables et d’un cadre fournisseur, afin de réduire les frictions de contractualisation avec un freelance tech basé hors UE.

Ce que la clause de cession de droits doit couvrir

Une clause IP robuste doit être cohérente avec la prestation réellement commandée.

Elle doit notamment traiter les points suivants.

Les créations concernées

La clause doit viser les créations réalisées dans le cadre de la prestation : code source, modules, scripts, correctifs, documentation, spécifications, configurations, automatisations et autres livrables prévus.

Elle doit distinguer les développements spécifiques des éléments préexistants.

Si le freelance réutilise un framework, un outil interne, une bibliothèque personnelle ou un composant antérieur, ces éléments doivent être identifiés. L’ESN doit savoir si elle reçoit une cession, une licence d’usage ou seulement le droit d’intégrer le composant dans un livrable.

Les droits d’exploitation

La clause doit couvrir les usages nécessaires au projet. Pour un client final, cela inclut souvent le droit d’utiliser, modifier, maintenir, faire évoluer, intégrer et déployer le code livré.

Selon les cas, le client final demandera une cession complète sur les développements spécifiques ou une licence étendue. L’important est d’éviter une contradiction entre le contrat client et le contrat fournisseur.

La garantie d’originalité

Le fournisseur doit s’engager sur le fait que les livrables ne portent pas atteinte aux droits de tiers, sous réserve des composants tiers déclarés.

Cette garantie doit rester réaliste. Elle doit s’accompagner d’une obligation de transparence sur les dépendances, licences et éléments réutilisés.

La documentation des dépendances

Une livraison professionnelle ne se limite pas au dépôt Git. L’ESN doit pouvoir obtenir un inventaire raisonnable des dépendances importantes, des licences open source et des contraintes d’utilisation.

Ce point devient critique si le client final opère dans un secteur régulé, manipule des données sensibles ou impose une politique stricte de sécurité logicielle.

La réversibilité et la maintenance

La propriété intellectuelle doit être liée à l’exploitation dans le temps.

Si le client final doit maintenir le code après la mission, il faut s’assurer que les droits couvrent la modification, la correction, l’adaptation et la reprise par un autre prestataire. Sinon, l’ESN peut livrer un code techniquement fonctionnel mais juridiquement difficile à faire évoluer.

Le rôle du bon de commande dans la preuve des droits

Le bon de commande est souvent sous-estimé.

Il permet de relier une mission, un périmètre, des livrables et une cession de droits. En cas de discussion, il aide à prouver que tel code livré, tel module ou telle documentation entre bien dans le champ de la prestation.

Pour une ESN, chaque bon de commande doit idéalement contenir ou renvoyer vers :

• une description claire de la prestation ;
• les livrables attendus ;
• la période d’exécution ;
• les critères de réception ;
• les obligations de cession de droits ;
• les règles applicables aux composants tiers ;
• les exigences éventuelles du client final ;
• les obligations de confidentialité et de sécurité.

Le contrat-cadre pose les règles. Le bon de commande rattache ces règles à une mission concrète.

Code source : propriété, accès et preuve de livraison

La propriété intellectuelle ne doit pas être confondue avec l’accès technique.

Avoir accès au dépôt Git ne signifie pas nécessairement détenir les droits d’exploitation. À l’inverse, une cession de droits mal accompagnée d’une livraison technique incomplète peut être difficile à valoriser.

L’ESN doit donc traiter les deux sujets.

D’un côté, les droits sur le code livré doivent être transférés selon le contrat. De l’autre, le code source doit être remis dans des conditions permettant son exploitation : dépôt accessible, documentation minimale, historiques utiles, instructions de build, dépendances identifiées, clés et secrets exclus des dépôts, modalités de transfert sécurisées.

Le client final attend souvent une continuité opérationnelle. La chaîne contractuelle doit soutenir cette continuité.

Sous-traitance et client final : aligner les engagements

Dans une mission ESN, le contrat principal avec le client final peut imposer des obligations spécifiques en cas de sous-traitance.

Ces obligations peuvent porter sur :

• l’autorisation préalable du sous-traitant ;
• la localisation du prestataire ;
• la confidentialité ;
• la sécurité informatique ;
• la propriété intellectuelle ;
• le RGPD ;
• la traçabilité des contributions ;
• les audits ;
• les sanctions internationales ;
• la conformité anticorruption ;
• le devoir de vigilance.

Si l’ESN fait intervenir un freelance hors UE sans aligner ces obligations, elle peut créer une non-conformité contractuelle, même si le travail technique est satisfaisant.

La bonne approche consiste à faire descendre les obligations utiles dans la chaîne fournisseur. C’est le dos-à-dos. Les engagements pris envers le client final doivent être répercutés au niveau pertinent, sans promettre plus que ce qui est opérationnellement maîtrisable.

Les erreurs fréquentes à éviter

Utiliser une clause IP générique

Une clause copiée d’un modèle standard peut être insuffisante. La cession de droits doit correspondre au type de livrables, au projet, au client final et aux usages attendus.

Oublier les éléments préexistants

Un freelance peut réutiliser des briques personnelles ou des outils déjà développés. Si ces éléments sont incorporés au code livré sans clarification, l’ESN peut croire détenir plus de droits qu’elle n’en a réellement.

Ne pas documenter l’open source

L’absence d’inventaire des dépendances peut créer un risque à la livraison. Le problème peut apparaître tard, lors d’un audit sécurité ou d’une revue juridique du client final.

Confondre paiement et cession

Le paiement d’une facture ne transfère pas automatiquement tous les droits de propriété intellectuelle. La cession doit être prévue contractuellement.

Ne pas aligner le contrat fournisseur avec le contrat client

C’est l’erreur la plus coûteuse. L’ESN s’engage largement envers le client final, mais ne sécurise pas les mêmes droits auprès du fournisseur qui a produit le code.

Quelle position adopter avant de démarrer la mission

Avant de faire intervenir un freelance tech hors UE, l’ESN doit poser une série de questions simples.

Le freelance est-il contractuellement signable par l’ESN ?
Le client final accepte-t-il cette chaîne de sous-traitance ?
Le périmètre de prestation est-il décrit ?
Les livrables sont-ils identifiés ?
La cession de droits couvre-t-elle le code source et les éléments associés ?
Les composants tiers sont-ils encadrés ?
Les obligations client final sont-elles répercutées ?
La facturation est-elle compatible avec les process achats ?
La résidence et l’activité hors UE reposent-elles sur une réalité vérifiable ?
Le fournisseur contractuel porte-t-il ses engagements en son nom propre ?

Si plusieurs réponses sont incertaines, le risque n’est pas seulement juridique. Il devient commercial. L’ESN peut perdre du temps en validation achats, bloquer une mission ou fragiliser la relation avec son client final.

Ce que StelarWork permet de simplifier

StelarWork vise à rendre exploitable, pour une ESN française, une collaboration avec un freelance tech basé hors UE lorsque le freelance n’est pas directement signable.

Le dispositif permet notamment :

• un fournisseur français pour l’ESN ;
• une facturation compatible avec les standards B2B français ;
• une chaîne contractuelle structurée autour de la prestation ;
• des obligations de propriété intellectuelle répercutées ;
• un cadre de conformité plus lisible ;
• une meilleure articulation entre freelance hors UE, ESN et client final.

StelarWork ne remplace pas les validations internes de l’ESN ni les exigences propres du client final. Le rôle consiste à réduire la friction contractuelle et administrative, tout en structurant la relation dans un cadre fournisseur français.

Disclaimer juridique et fiscal

Cet article fournit une information générale à destination des ESN. Il ne constitue pas un conseil juridique, fiscal ou social personnalisé.

Les règles applicables dépendent notamment du contrat principal, du pays de résidence du freelance, de la nature des livrables, du droit applicable, des exigences du client final et de la réalité opérationnelle de la mission.

Toute situation impliquant un freelance hors UE doit être analysée au regard des faits réels : résidence effective, activité remote réelle, absence de présence organisée en France, absence d’entité artificielle et cohérence de la chaîne contractuelle. En cas d’incertitude, l’ESN doit solliciter ses conseils habituels.

Conclusion

La propriété intellectuelle freelance hors UE est un sujet de chaîne contractuelle.

Pour une ESN, l’objectif n’est pas seulement d’obtenir du code. Il faut pouvoir démontrer que le code livré peut être utilisé, modifié, maintenu et transmis au client final selon les engagements du contrat principal.

La clé réside dans trois éléments : une prestation définie, une cession de droits adaptée et une chaîne fournisseur cohérente.

StelarWork s’insère entre l’ESN et le freelance tech hors UE comme fournisseur français contractant en son nom propre. Cette approche vise à rendre la collaboration plus simple à valider, plus lisible contractuellement et mieux alignée avec les exigences d’un client final.

FAQ

Qui détient la propriété intellectuelle du code produit par un freelance hors UE ?

Par défaut, le fait de payer une prestation ne suffit pas toujours à transférer tous les droits de propriété intellectuelle. Il faut une cession de droits ou une licence clairement prévue au contrat, avec un périmètre adapté aux livrables et aux usages attendus.

Une ESN peut-elle livrer au client final du code produit par un freelance hors UE ?

Oui, si la chaîne contractuelle le permet. L’ESN doit disposer des droits nécessaires sur le code livré et respecter les obligations du contrat principal, notamment en matière de sous-traitance, confidentialité, sécurité, RGPD et propriété intellectuelle.

Que doit prévoir une cession de droits sur du code source ?

Elle doit préciser les livrables concernés, les droits transmis, la durée, le territoire, les modes d’exploitation, les éléments préexistants, les composants tiers et les garanties relatives à l’absence d’atteinte aux droits de tiers.

Le client final doit-il être informé de l’intervention d’un freelance hors UE ?

Cela dépend du contrat entre l’ESN et le client final. Certains contrats imposent une autorisation préalable ou une information en cas de sous-traitance. L’ESN doit vérifier ses engagements avant le démarrage de la mission.

StelarWork représente-t-il le freelance en France ?

Non. StelarWork contracte en son nom propre avec l’ESN. Le cadre repose sur une prestation, des livrables, une facturation française et une chaîne contractuelle structurée.

StelarWork permet-il de défiscaliser la mission ?

Non. StelarWork ne vend pas de défiscalisation. Lorsqu’un freelance est déjà résident fiscal réel hors UE, avec une activité remote réelle et sans présence organisée en France, StelarWork retire une friction administrative et contractuelle pour l’ESN. Une configuration artificielle ou fictive doit être écartée.

Pourquoi passer par StelarWork plutôt que signer directement le freelance ?

Lorsqu’un freelance hors UE est difficile à valider par les achats, la conformité ou le client final, StelarWork permet à l’ESN de travailler avec un fournisseur français, dans un cadre de prestation plus lisible. Cela vise à sécuriser la chaîne contractuelle, la facturation et la transmission des droits sur les livrables.