Qui possède le code source de mon application
En droit français, par défaut, c'est l'auteur du code qui en détient les droits : autrement dit, sans clause écrite, le prestataire qui développe une application reste titulaire des droits sur ce qu'il a écrit. Pour que votre entreprise devienne propriétaire du code source de son application, cette cession doit être prévue noir sur blanc dans le contrat. C'est le point essentiel à retenir, et c'est aussi celui que beaucoup de clients découvrent trop tard. Voici comment fonctionne la propriété code source application, ce qu'il faut exiger par écrit, et comment vérifier qu'on possède réellement son projet. Cet article est une explication générale, pas un conseil juridique formel : pour un cas précis, un avocat reste votre meilleur interlocuteur.
Le principe juridique : le code est une oeuvre protégée
En France, un logiciel, et donc le code source qui le compose, est protégé par le droit d'auteur, au même titre qu'un texte ou une musique. Le Code de la propriété intellectuelle range expressément les logiciels parmi les oeuvres de l'esprit. Concrètement, dès qu'une ligne de code originale est écrite, des droits naissent automatiquement au profit de son auteur, sans formalité, sans dépôt obligatoire.
La conséquence est souvent contre-intuitive. Vous payez une agence pour développer votre application, mais payer une prestation ne vous transfère pas automatiquement les droits d'auteur sur le résultat. C'est la grande différence avec l'achat d'un objet matériel : acheter un livre ne vous rend pas propriétaire du texte. Pour répondre clairement à la question « à qui appartient le code app » : par défaut, à celui qui l'a développé, sauf cession écrite organisée par le contrat.
Le cas particulier du salarié et du freelance
Quand le code est écrit par un salarié dans le cadre de ses fonctions, les droits patrimoniaux sur le logiciel sont, par exception légale, dévolus à l'employeur. Mais cette règle vaut pour la relation employeur/salarié. Entre votre entreprise et une agence prestataire, ou un freelance indépendant, c'est le régime classique qui s'applique : sans clause de cession, les droits restent chez le prestataire. D'où l'importance de bien lire ce que dit le contrat.
Pourquoi une cession explicite est indispensable
La loi exige que la cession des droits code soit écrite et précise. Une formule vague du type « le client devient propriétaire » ne suffit pas toujours. Le texte doit délimiter ce qui est cédé, pour quels usages, pour quelle durée et pour quel territoire. Une cession floue, c'est la porte ouverte aux litiges le jour où vous voudrez faire évoluer l'application avec un autre prestataire, la revendre, ou lever des fonds.
Cette exigence protège tout le monde. Elle vous garantit que vous pourrez exploiter, modifier et faire maintenir votre application librement. Et elle évite la situation classique où une entreprise se rend compte, au moment de changer de prestataire, qu'elle ne peut pas récupérer son propre projet ou qu'on lui en demande le rachat. Anticiper la récupérer code source agence dès la signature du contrat, c'est s'éviter un bras de fer plus tard.
Ce que doit contenir le contrat
Un bon contrat de développement traite la propriété intellectuelle comme un sujet à part entière, pas comme une ligne perdue dans les conditions générales. Voici les éléments qui devraient y figurer.
- La cession des droits patrimoniaux sur le code développé spécifiquement pour vous, avec les droits de reproduction, de modification et d'adaptation.
- Le périmètre exact de la cession : ce qui est cédé (le code sur mesure) et ce qui ne l'est pas (les briques tierces, voir plus bas).
- La livraison du code source commenté et exploitable, pas seulement l'application compilée et mise en ligne.
- L'accès aux dépôts Git où vit le code, avec un transfert ou un partage clair du dépôt.
- Les comptes et identifiants liés au projet : hébergement, nom de domaine, services tiers, ouverts à votre nom.
- Le moment de la cession, idéalement au fil des paiements ou à la livraison, pour éviter le code « otage ».
Si vous hésitez entre une agence locale et une plateforme en ligne pour confier ce travail, cette comparaison entre une agence web locale et une plateforme de mise en relation aborde justement la question des engagements contractuels et de la transmission du code.
Les pièges à connaître
Posséder le code source de votre application ne veut pas dire posséder absolument tout ce qui la fait fonctionner. C'est la nuance la plus mal comprise, et elle mérite qu'on s'y arrête.
Les briques sous licence open source
Une application moderne s'appuie sur des dizaines de composants open source : bibliothèques, frameworks, outils. Vous ne devenez pas propriétaire de ces briques, vous les utilisez sous leur licence (MIT, Apache, GPL, etc.). C'est normal et sain : personne ne réécrit React ou un moteur de base de données à la main. Ce qui compte, c'est que ces licences soient permissives et compatibles avec un usage commercial, ce qu'une agence sérieuse vérifie pour vous.
Les dépendances tierces et les services SaaS
Même logique pour les services externes. Quand votre application stocke ses données dans une base hébergée chez Supabase, encaisse des paiements via Stripe, ou envoie des emails par un service tiers, vous n'êtes pas propriétaire de ces plateformes. Vous en êtes l'utilisateur, via un compte et un abonnement. La distinction clé : le code qui appelle Stripe vous appartient, mais Stripe lui-même reste un service que vous consommez.
Le vrai risque n'est donc pas d'utiliser ces services, c'est que les comptes correspondants soient ouverts au nom de l'agence plutôt qu'au vôtre. Le jour où vous changez de prestataire, vous devez pouvoir reprendre la main sur votre base de données, votre compte de paiement et votre nom de domaine sans dépendre de personne.
Récapitulatif : trois natures de propriété distinctes
| Élément | Statut | Ce que vous obtenez |
|---|---|---|
| Code sur mesure développé pour vous | Cédé au client | Propriété pleine via la cession écrite |
| Briques open source et bibliothèques | Sous licence | Droit d'usage, pas la propriété |
| Services SaaS (base, paiement, emails) | Comptes à votre nom | Contrôle des accès et des données |
Comment vérifier qu'on possède vraiment son projet
Au delà du contrat, quelques vérifications concrètes permettent de savoir si vous êtes réellement maître de votre application. Voici la checklist « êtes-vous vraiment propriétaire ».
- Le dépôt Git vous a été remis ou vous y avez un accès administrateur complet, avec tout l'historique du code.
- Vous pouvez télécharger l'intégralité du code source, et pas seulement consulter l'application en ligne.
- Le contrat mentionne explicitement la cession des droits patrimoniaux sur le code sur mesure.
- Les comptes des services tiers sont à votre nom : hébergement, base de données, paiement, nom de domaine.
- Une documentation technique existe : comment installer, lancer et déployer le projet sans l'agence d'origine.
- Aucune brique captive maison ne vous oblige à rester chez le prestataire pour faire fonctionner l'application.
- Un autre développeur pourrait reprendre le projet demain avec les éléments en votre possession.
Si vous cochez ces points, vous tenez réellement votre projet. Dans le cas contraire, mieux vaut clarifier la situation avant d'aller plus loin, surtout si vous prévoyez de faire évoluer l'application.
La position d'Applyze
Chez Applyze, le principe est simple et il est posé dès le départ : le client est propriétaire du code livré. Vous disposez d'un accès complet aux dépôts Git, le code source vous est remis, et les comptes des services que nous mettons en place (hébergement, base de données, paiement) sont ouverts à votre nom. Nous ne créons aucune dépendance captive qui vous obligerait à rester avec nous.
Cette approche découle d'une conviction : un prestataire doit être choisi pour la qualité de son travail et de son suivi, pas retenu parce qu'il garde votre code en otage. C'est aussi pour cela que nous documentons les projets de façon à ce qu'ils restent reprenables. Cette transparence fait partie de notre valeur ajoutée et de notre manière de travailler sur la durée.
Questions fréquentes
Si je n'ai rien signé, qui possède le code de mon application ?
Sans clause écrite de cession, c'est le prestataire qui a développé le code qui en conserve les droits d'auteur. Payer la prestation ne transfère pas automatiquement la propriété. Il faut donc régulariser une cession écrite pour devenir titulaire des droits patrimoniaux sur le code sur mesure.
Puis-je récupérer mon code source si je change d'agence ?
Oui, si votre contrat prévoit la cession des droits et la remise du code. Demandez l'accès au dépôt Git, le transfert des comptes de services et la documentation technique. Si rien n'a été prévu au départ, la récupération peut nécessiter une négociation, parfois un rachat des droits.
Suis-je propriétaire des briques open source utilisées ?
Non, vous n'en êtes pas propriétaire, vous les utilisez sous leur licence (MIT, Apache, GPL, etc.). C'est le fonctionnement normal du développement moderne. Ce qui compte, c'est que ces licences soient compatibles avec votre usage commercial, ce qu'une agence vérifie en amont du projet.
Et les services comme Supabase ou Stripe, m'appartiennent-ils ?
Non. Vous êtes utilisateur de ces services via un compte et un abonnement, pas leur propriétaire. L'essentiel est que ces comptes soient ouverts à votre nom, afin de garder le contrôle de vos données, de vos paiements et de votre capacité à changer de prestataire.
La cession des droits a-t-elle un coût supplémentaire ?
Cela dépend de chaque prestataire. Certains intègrent la cession dans le prix de la prestation, d'autres la facturent à part. L'important est que le sujet soit clair dès le devis, pour éviter une mauvaise surprise au moment de la livraison ou d'un futur changement d'agence.
Vous avez un doute sur la propriété du code de votre application, ou vous démarrez un projet et souhaitez que ces points soient cadrés dès le départ ? Parlons-en ensemble : nous prenons le temps de clarifier la propriété de votre projet avant même la première ligne de code.