Propriété du code source : qui possède quoi en 2026 ?

Vous payez les factures, vous validez chaque sprint, le logiciel tourne en production. Et pourtant, en droit français, ce code ne vous appartient toujours pas. La plupart des dirigeants découvrent cette réalité le jour où l’agence coupe l’hébergement ou réclame un solde à cinq chiffres pour « libérer » les sources.

On écrit cet article parce qu’on livre du code toutes les semaines, pas parce qu’on aime le droit d’auteur. Voici, sans langue de bois, qui possède quoi — et les six clauses à verrouiller avant de signer votre prochain contrat de développement.

Propriété du code source : ce que dit vraiment le droit français

Le code source est une œuvre de l’esprit protégée dès sa création, sans dépôt ni formalité, en vertu des articles L.111-1 et L.112-2 du Code de la propriété intellectuelle. Le titulaire initial des droits, c’est le créateur du code — le développeur ou l’agence. Jamais le client par défaut.

C’est le contre-sens qui coûte le plus cher. Payer une prestation ne transfère aucun droit d’auteur. Vous obtenez une licence d’usage implicite dans les limites de ce qui a été convenu, mais l’agence reste titulaire de tout ce qui n’a pas été cédé par écrit : les sources, le droit d’adapter le code, et même le droit de réutiliser ses briques pour un concurrent.

La seule exception, c’est le salariat. L’article L.113-9 du CPI prévoit une dévolution automatique des droits patrimoniaux sur le logiciel à l’employeur. Autrement dit : un développeur en CDI dans votre entreprise vous cède ses droits par défaut. Une agence externe, un freelance ou un ESN, non. La règle s’inverse dès que le prestataire n’est pas votre salarié.

Notre avis de praticien : ne comptez jamais sur le « bon sens » ni sur la bonne foi. Un contrat qui ne dit rien sur la propriété est un contrat qui vous laisse propriétaire de rien. Le silence profite au prestataire.

La cession des droits : un formalisme qui ne pardonne pas

Pour devenir propriétaire, il vous faut une cession écrite des droits patrimoniaux. Et l’article L.131-3 du CPI impose un formalisme redoutable : chaque droit cédé doit être mentionné distinctement, et le domaine d’exploitation délimité quant à son étendue, sa destination, son territoire et sa durée.

Concrètement, une clause valable doit lister nommément :

• les droits cédés (reproduction, représentation, adaptation, traduction, distribution, sous-licence) — tout ce qui n’est pas écrit est réputé non cédé ;
• le caractère exclusif ou non de la cession ;
• le territoire (souvent « le monde entier ») et la durée (souvent « la durée légale des droits »).

La formule magique « tous droits cédés » ? Inopérante. La jurisprudence la sanctionne régulièrement par la nullité de la cession. Un contrat élégant en une ligne peut donc ne rien valoir.

Deux pièges supplémentaires que 9 contrats sur 10 ignorent :

1. Les droits moraux sont incessibles. L’agence pourra toujours revendiquer la paternité de l’œuvre — c’est son droit moral, inaliénable. En pratique, ça ne vous gêne pas : vous conservez le droit d’exploiter, modifier et redistribuer le code.
2. La cession globale des œuvres futures est nulle (article L.131-1). Une clause signée au lancement ne couvre pas automatiquement les développements réalisés six mois plus tard. Solution : prévoir une cession qui s’attache à chaque livraison identifiable (via avenant ou clause de rattachement à chaque sprint livré et facturé).

Dépôt Git : « voir » le code n’est pas le « posséder »

Beaucoup de dirigeants confondent accès et propriété. « Je vois le dépôt GitHub, donc c’est à moi. » Faux. Un prestataire propriétaire de l’organisation Git peut, en 30 secondes, retirer vos accès, verrouiller le compte, et faire du solde des sources un moyen de pression.

Pour éviter ce scénario, votre contrat doit poser trois principes :

• Vous êtes propriétaire de l’organisation Git (GitHub, GitLab, Bitbucket) dès le premier commit. L’agence y travaille en tant qu’invitée, pas en propriétaire.
• La remise du dépôt complet — historique de commits inclus — est une obligation de livraison, pas une faveur de fin de projet.
• Une clause de réversibilité encadre le transfert des sources et de la documentation en cas de rupture, quelle qu’en soit la cause.

En mode SaaS hébergé chez l’agence, le risque grimpe d’un cran : vous ne perdez pas seulement le code, mais aussi vos données de production. La clause de réversibilité doit alors préciser le format d’export des données, le délai de mise à disposition et la durée d’assistance à la migration.

Pour les logiciels stratégiques, ajoutez un contrat d’entiercement (séquestre de code) auprès d’un tiers comme l’APP (Agence pour la Protection des Programmes). Le principe : les sources sont déposées chez le séquestre, qui les libère automatiquement si l’agence devient défaillante (dépôt de bilan, arrêt du service, non-respect du SLA). Bonus : le dépôt donne une date certaine à la création et prouve l’antériorité de vos droits en cas de litige.

Fourchette de coût 2026 : un dépôt APP démarre autour de 300–600 €/an ; un séquestre de code avec convention tripartite se situe généralement entre 1 500 et 4 000 €/an selon la fréquence des dépôts. À réserver aux logiciels dont l’indisponibilité mettrait votre activité à l’arrêt.

Open source : la zone grise qui peut vous faire réécrire tout votre code

Votre logiciel « sur mesure » n’est presque jamais 100 % original. Un projet moderne embarque facilement des centaines de dépendances open source (le simple node_modules d’une application web dépasse souvent 1 000 paquets). Chacune vient avec sa licence — et toutes ne sont pas anodines.

Le danger porte un nom : la contamination copyleft. Une bibliothèque sous licence GPL intégrée dans votre logiciel propriétaire peut vous contraindre à publier l’intégralité de votre code source. Autrement dit : votre logique métier, votre avantage concurrentiel, exposés au public. Découverte tardivement, la contamination vous laisse trois options, toutes douloureuses : renoncer à commercialiser, réécrire les parties infectées, ou négocier une licence commerciale hors de prix.

Voici les licences à connaître avant toute livraison :

Notre position tranchée : MIT, Apache 2.0 et BSD, aucun problème, foncez. GPL et AGPL dans du code propriétaire distribué : interdiction, sauf périmètre isolé et vérifié par un juriste. LGPL : acceptable en liaison dynamique, jamais en copier-coller de code.

Exigez de votre agence une clause imposant : la déclaration de tout composant tiers, le respect de votre politique de licences acceptables, et la garantie de conformité. Un fichier SBOM (Software Bill of Materials) automatisé — généré par des outils comme syft ou license-checker — doit accompagner chaque livraison.

Documentation et livrables : le code seul ne sert à rien

La propriété du code ne se résume pas à un .zip de sources. Un logiciel sans documentation, c’est une voiture sans clé ni manuel : vous la possédez, mais vous ne pouvez ni la conduire ni la faire réparer ailleurs. La protection légale couvre d’ailleurs explicitement le code source, le code objet et la documentation technique.

Ce que vous devez exiger comme livrables contractuels :

• Le dépôt Git complet avec l’historique des commits.
• La documentation d’architecture : schéma applicatif, modèle de base de données, dépendances.
• Le fichier d’inventaire des licences open source (SBOM).
• Les scripts de déploiement et la liste des variables d’environnement (hors secrets de production).
• Un guide de prise en main exploitable par une équipe interne ou un futur prestataire, incluant la procédure de build et de mise en production.

Test simple : demandez à l’agence « combien de temps faut-il à un développeur extérieur pour faire tourner le projet en local à partir des livrables ? ». Si la réponse dépasse une journée, la documentation est insuffisante.

Dans quelle situation êtes-vous vraiment ?

Avant de paniquer ou de signer à l’aveugle, situez-vous dans ce tableau :

Si vous cochez une ligne rouge ou orange, ne laissez pas traîner : chaque semaine qui passe rapproche du moment où le rapport de force basculera contre vous.

Les 6 clauses à verrouiller avant de signer

Voici la check-list à soumettre à votre juriste — ou à l’agence — avant toute signature.

1. Cession des droits patrimoniaux (art. L.131-3) Mentionne explicitement reproduction, représentation, adaptation, traduction, distribution, sous-licence. Territoire et durée précisés. Rattachement à chaque livraison facturée.

2. Propriété de l’organisation Git Vous êtes administrateur de votre dépôt dès le premier commit, jamais en fin de projet.

3. Inventaire open source (SBOM) L’agence déclare chaque composant tiers et sa licence avant livraison, avec garantie de conformité à votre politique de licences.

4. Réversibilité En cas de rupture, l’agence remet sources, données et documentation dans un format exploitable sous un délai précis (30 jours est un standard), avec assistance à la migration.

5. Garantie d’éviction Le cédant garantit être titulaire des droits cédés et prend à sa charge les frais d’une éventuelle action en contrefaçon d’un tiers.

6. Confidentialité et non-réutilisation L’agence ne peut réutiliser vos spécificités fonctionnelles propriétaires pour un concurrent, y compris après la fin du contrat.

Un rappel utile : ces six clauses ne rallongent pas un contrat de dix pages. Une agence sérieuse les propose d’elle-même. Si un prestataire freine sur la propriété du code ou la réversibilité, c’est en soi le signal d’alarme le plus fiable que vous obtiendrez.

Ce que fait Step pour sécuriser la propriété de votre code

Chez Step, la propriété du code n’est pas une option à négocier : c’est le point de départ du cadrage. Quand nous développons un logiciel métier sur mesure, vous êtes propriétaire de l’organisation Git dès le premier jour. La cession des droits patrimoniaux est incluse dans nos contrats standards, rédigée conformément au formalisme du CPI — pas dans un avenant qu’on vous vend plus tard.

En fin de projet, nous remettons systématiquement : le dépôt complet avec historique, la documentation d’architecture, l’inventaire des licences open source (SBOM), et les scripts de déploiement. Objectif assumé : que vous puissiez changer de prestataire ou internaliser la maintenance sans jamais dépendre de nous.

Vous avez un doute sur un contrat existant, ou un logiciel déjà en production dont la propriété est floue ? On peut auditer la situation. Pour le contexte plus large, lisez notre comparatif logiciel sur mesure vs SaaS standard et notre guide pour éviter le vendor lock-in, qui traite d’enjeux directement liés.

Enfin, si vos projets intègrent de l’intelligence artificielle — où la propriété des modèles, des données et des prompts soulève des questions encore plus épineuses — notre pôle conseil IA pour PME intervient en amont pour cadrer le tout. Pour comprendre notre approche et nos engagements, tout est détaillé sur la page agence.

La propriété du code source n’est pas un sujet de juriste. C’est une question de souveraineté sur votre outil de travail. Un logiciel sur lequel vous n’avez aucun droit réel est une dette cachée qui se révèle toujours au pire moment : quand l’agence disparaît, quand le projet doit évoluer, ou quand un concurrent se retrouve avec vos fonctionnalités.

Prenez 30 minutes avant de signer votre prochain contrat de développement. Échangeons gratuitement sur votre projet — on identifie avec vous les clauses à sécuriser et on structure un contrat qui vous protège vraiment.