Propriété du code source et sous-traitance : qui détient les droits sur votre logiciel ?

Payer un prestataire pour écrire votre code ne vous en rend pas propriétaire. En France, comme au Royaume-Uni et aux États-Unis, les droits sur un logiciel développé par un freelance ou une agence restent au prestataire tant qu'un contrat écrit ne vous les cède pas ; seul le logiciel créé par un salarié dans ses fonctions revient de plein droit à l'employeur. Quand vous sous-traitez, il vous faut donc trois choses : une cession de droits écrite et conforme, le code dans un dépôt contrôlé par votre entreprise, et une vérification des licences open source qu'il contient.

Cet article est une information générale, pas un conseil juridique. Les règles varient selon les pays et les contrats : faites relire par un avocat les accords importants pour votre activité.

À qui appartient le code par défaut ?

En France

Un logiciel est protégé par le droit d'auteur dès sa création, sans formalité. L'article L113-9 du Code de la propriété intellectuelle attribue à l'employeur « les droits patrimoniaux sur les logiciels et leur documentation créés par un ou plusieurs employés dans l'exercice de leurs fonctions ou d'après les instructions de leur employeur ». Cette règle ne vaut pas pour un freelance ni pour une agence. Bpifrance Création le résume ainsi : « Le fait de commander un logiciel spécifique auprès d'un prestataire ne fait pas automatiquement du donneur d'ordre le titulaire des droits. » Il faut un contrat de cession.

Et ce contrat obéit à un formalisme strict. Selon l'article L131-3, « la transmission des droits de l'auteur est subordonnée à la condition que chacun des droits cédés fasse l'objet d'une mention distincte dans l'acte de cession et que le domaine d'exploitation des droits cédés soit délimité quant à son étendue et à sa destination, quant au lieu et quant à la durée ». Une clause d'une ligne du type « tous les droits appartiennent au client » risque de ne pas suffire.

Au Royaume-Uni

L'office britannique de la propriété intellectuelle est clair : quand vous commandez une œuvre, le premier titulaire du droit d'auteur est celui qui l'a créée, et non le commanditaire, sauf accord écrit contraire. Pour les salariés, l'employeur est titulaire des œuvres créées dans le cadre de l'emploi.

Aux États-Unis

Le Copyright Office américain réserve la notion de « work made for hire » aux œuvres créées par un salarié dans le cadre de son emploi, ou aux œuvres commandées relevant de neuf catégories limitatives (contribution à une œuvre collective, traduction, compilation…) avec un accord écrit signé des deux parties. Le logiciel n'en fait pas partie : le code d'un prestataire indépendant lui reste acquis tant qu'il ne vous cède pas ses droits par écrit.

Ce que le contrat doit prévoir

1. Une cession, pas une simple licence. Le prestataire vous cède les droits sur tout le code, la documentation et les maquettes créés pour vous. En droit français, énumérez les droits (reproduction, modification, adaptation, traduction, distribution, exploitation commerciale) et précisez territoire, destination et durée.
2. Le moment de la cession. En général au paiement de chaque facture. C'est équitable pour le prestataire ; à vous de payer à temps et de conserver les justificatifs.
3. Les éléments préexistants. Le prestataire réutilise ses bibliothèques, modèles et outils. Vous n'avez pas besoin de les posséder, mais d'une licence permanente et transmissible pour les utiliser dans votre produit.
4. Les sous-traitants. Si le prestataire fait appel à d'autres développeurs, ceux-ci doivent lui avoir cédé leurs droits, sinon la chaîne est rompue.
5. Les composants tiers et open source. Le prestataire en fournit la liste avec leurs licences et confirme leur compatibilité avec votre usage.
6. Les livrables de fin de mission. Code source complet, instructions de build et de déploiement, documentation, et identifiants de chaque compte créé pour vous.
7. Confidentialité et données. Code et données restent confidentiels ; les données personnelles sont encadrées par un contrat de sous-traitance RGPD (voir choisir un prestataire de développement).

Possédez le dépôt, pas seulement les droits

Le contrat vous donne le droit sur le code ; le dépôt vous donne le code lui-même. Créez l'organisation GitHub, GitLab ou Bitbucket au nom de votre entreprise dès le premier jour et invitez-y le prestataire. Si le dépôt est déjà sur son compte, demandez un transfert : sur GitHub, les issues, pull requests, wiki, étoiles et abonnés suivent le dépôt, et les anciens liens sont redirigés automatiquement.

Sachez ce que signifie un dépôt sans licence : GitHub rappelle qu'en l'absence de licence, le droit d'auteur s'applique par défaut et personne ne peut reproduire, distribuer ni créer d'œuvre dérivée. C'est ce que vous voulez pour un produit privé. Si vous ouvrez un jour une partie du code, choisissez la licence en connaissance de cause.

Bpifrance Création conseille aussi de se ménager une preuve de date et de contenu, par exemple un dépôt auprès de l'Agence pour la protection des programmes (APP) ou une enveloppe e-Soleau de l'INPI. Un historique Git daté, hébergé sur un compte de l'entreprise, y contribue. Aucun de ces dépôts ne crée de droits : ils aident à les prouver.

Licences open source : les points de vigilance

Presque tous les produits reposent sur des paquets open source, et la plupart des licences (MIT, BSD, Apache 2.0) demandent surtout de conserver les mentions de copyright. Les licences dites copyleft demandent plus d'attention. D'après la FAQ de la GPL publiée par la Free Software Foundation :

• Vous pouvez modifier un logiciel sous GPL et l'utiliser en interne sans publier vos changements ; l'obligation de fournir le code source naît lorsque vous le distribuez.
• La GNU Affero GPL (AGPL) va plus loin : si vous faites tourner une version modifiée sur un serveur, les utilisateurs qui y accèdent par le réseau doivent pouvoir en obtenir le code source.
• Si votre programme est lié à une bibliothèque sous GPL (et non LGPL), l'ensemble doit être distribué sous GPL.

Pour un SaaS, examinez de près les composants AGPL ; pour une application mobile ou de bureau que vous distribuez, les composants GPL. Demandez à votre développeur la liste des dépendances et de leurs licences avant chaque version majeure ; les gestionnaires de paquets savent la produire (par exemple composer licenses pour un projet PHP).

La checklist

• Contrat signé avec une cession de droits conforme à l'article L131-3 si le droit français s'applique.
• Licence sur les outils préexistants du prestataire.
• Dépôt, hébergement et comptes au nom de votre entreprise.
• Liste des dépendances et licences, sans GPL ni AGPL inattendue.
• Clause de réversibilité : code source, documentation, identifiants.

Ces points valent quel que soit le modèle ; voir freelance, agence ou abonnement de développement et le plan d'accès de l'intégration d'un développeur à distance.

Questions fréquentes

À qui appartient le code développé par un freelance ?

Par défaut, au freelance. Vous n'en devenez titulaire que par une cession de droits écrite, conforme à l'article L131-3 du Code de la propriété intellectuelle. Le code écrit par un salarié dans ses fonctions revient en revanche à l'employeur (article L113-9).

Une facture payée suffit-elle à transférer les droits sur un logiciel ?

Non. Le paiement rémunère la prestation, mais la cession des droits d'auteur exige un écrit qui mentionne chaque droit cédé et délimite l'étendue, la destination, le lieu et la durée de l'exploitation.

Peut-on utiliser du code sous licence GPL dans un produit commercial ?

Oui, mais si vous distribuez le produit, la GPL impose de fournir le code source sous GPL. L'AGPL étend cette obligation aux logiciels utilisés via le réseau. Vérifiez les licences avant la mise en ligne.

Que récupérer auprès du prestataire en fin de projet ?

Le code source complet dans votre dépôt, la documentation, les instructions de build et de déploiement, les identifiants de chaque compte créé pour vous, et la cession de droits signée.

Sources

1. Works Made for Hire (Circular 30), U.S. Copyright Office, 2024-08
2. Ownership of copyright works, Intellectual Property Office, GOV.UK, 2014-08
3. Code de la propriété intellectuelle – Article L113-9, Légifrance, n.d.
4. Code de la propriété intellectuelle – Article L131-3, Légifrance, n.d.
5. Protection juridique d'un logiciel, Bpifrance Création, 2026-06
6. Frequently Asked Questions about the GNU Licenses, Free Software Foundation (gnu.org), n.d.
7. Licensing a repository, GitHub Docs, n.d.
8. Transferring a repository, GitHub Docs, n.d.