BlogConseils · 24 septembre 2026

À qui appartient le code de votre application ?

Payer un développement ne suffit pas toujours à en devenir propriétaire. Droit d'auteur, cession, licences tierces : ce que le contrat doit dire.

Tous les articles Nous écrire

À qui appartient le code de votre application ?

Beaucoup d'entreprises pensent qu'en payant le développement d'une application, elles en deviennent automatiquement propriétaires. En droit français comme en droit belge, ce n'est pas si simple. Un logiciel est protégé par le droit d'auteur, et ce droit appartient d'abord à celui qui l'a créé. Sans clause claire dans le contrat, le client peut se retrouver avec un outil qu'il utilise, mais qu'il ne peut ni modifier librement, ni confier à un autre prestataire. Voici les notions à connaître pour poser les bonnes questions. Cet article donne des repères généraux ; il ne remplace pas l'avis d'un juriste sur votre contrat.

Le logiciel est une œuvre protégée

En France, le Code de la propriété intellectuelle range explicitement les logiciels parmi les œuvres de l'esprit (article L112-2). Au niveau européen, la directive 2009/24/CE harmonise la protection juridique des programmes d'ordinateur, et la Belgique l'a transposée dans son Code de droit économique, au livre XI.

Cette protection couvre le code source et le code exécutable, ainsi que le matériel de conception préparatoire. Elle ne couvre pas les idées ni les fonctionnalités en tant que telles : deux applications peuvent faire la même chose sans que l'une copie l'autre.

Salarié ou prestataire : la différence est décisive

Une forme moulée en plâtre blanc posée à côté du moule ouvert en deux moitiés qui a servi à la couler. — Vous recevez le tirage, mais le moule reste à l'auteur sans cession écrite.

Quand le code est écrit par vos salariés

Le droit prévoit une règle particulière pour les logiciels créés par des salariés dans l'exercice de leurs fonctions : les droits patrimoniaux sont dévolus à l'employeur (article L113-9 du Code de la propriété intellectuelle en France, article 2 de la directive européenne). L'entreprise est donc en principe titulaire du code produit par son équipe interne.

Quand le code est écrit par un prestataire

Cette règle ne s'applique pas à un prestataire extérieur, qu'il s'agisse d'un indépendant ou d'un studio. Les droits restent à l'auteur, sauf s'ils sont cédés par contrat. Et en France, la cession doit être précise : l'article L131-3 du Code de la propriété intellectuelle exige que chaque droit cédé fasse l'objet d'une mention distincte, avec un domaine délimité quant à son étendue, sa destination, son lieu et sa durée. Une phrase vague du type « le client est propriétaire de tout » peut s'avérer insuffisante.

Ce qu'une bonne clause prévoit

Un contrat de développement clair répond au moins à ces questions :

Quels droits sont cédés ? Reproduction, modification, adaptation, distribution, mise à disposition en ligne.

Sur quel périmètre ? Le code propre au projet, la documentation, les maquettes, les schémas de données.

Pour quel territoire et quelle durée ? Souvent le monde entier et la durée légale des droits.

À quel moment ? À la livraison, au paiement complet, ou au fil des étapes.

Que devient ce qui préexistait ? Les briques que le prestataire réutilise d'un projet à l'autre ne sont généralement pas cédées, mais concédées sous licence.

Le code tiers : les licences

Aucune application moderne n'est écrite entièrement à la main. Elle s'appuie sur des dizaines, parfois des centaines de bibliothèques, souvent open source. Ces composants ne vous appartiennent pas : ils restent sous leurs licences respectives, qui fixent ce que vous pouvez en faire.

On distingue en gros deux familles :

Les licences permissives (MIT, Apache 2.0, BSD) autorisent une utilisation très large, y compris commerciale, en demandant surtout de conserver les mentions de copyright.

Les licences à réciprocité, dites copyleft (GPL, AGPL), imposent sous certaines conditions de diffuser sous la même licence le code qui les intègre ou les modifie. L'AGPL étend cette obligation aux logiciels mis à disposition via un réseau.

Un prestataire sérieux tient la liste des composants utilisés et de leurs licences, et vérifie leur compatibilité avec votre usage. Le référentiel SPDX fournit des identifiants standardisés pour décrire ces licences.

Au-delà du droit : pouvoir s'en servir

Être titulaire des droits ne suffit pas si l'on ne peut pas exercer ces droits en pratique. Trois éléments comptent autant que le contrat :

L'accès au code source, dans un dépôt dont vous avez les clés.

Les accès aux services : hébergement, nom de domaine, base de données, comptes des magasins d'applications. Idéalement ouverts au nom de votre entreprise.

La documentation, qui permet à une autre équipe de comprendre, déployer et faire évoluer l'application.

Certaines entreprises recourent aussi au dépôt du code source auprès d'un tiers de confiance, comme l'Agence pour la protection des programmes en France, pour se prémunir contre la disparition d'un éditeur.

Notre position

Chez Hultra Studio, le code propre au projet appartient au client selon les termes du contrat, et les composants tiers restent sous leurs licences. Nous préférons que cette règle soit écrite noir sur blanc dès le départ. Elle rejoint notre conception de l'autonomie après projet : un client doit pouvoir rester avec nous parce qu'il le souhaite, pas parce qu'il ne peut pas faire autrement.

Questions fréquentes

Si je paie le développement, suis-je automatiquement propriétaire du code ?

Pas automatiquement lorsque le développement est confié à un prestataire. Il faut une cession de droits écrite et suffisamment précise.

Puis-je confier mon application à un autre prestataire ?

Oui, si vous disposez des droits nécessaires, du code source, des accès aux services et d'une documentation suffisante.

Les bibliothèques open source posent-elles un risque ?

Elles sont indispensables et généralement sans difficulté. Le risque vient d'une licence mal comprise, par exemple une licence copyleft intégrée dans un produit commercial sans vérification.

Vous voulez faire le point sur la propriété d'une application existante ? Contactez-nous.