Voici une mauvaise surprise que beaucoup de fondateurs découvrent trop tard : avoir payé le développement de son application ne signifie pas en posséder le code. La facture acquittée et la propriété intellectuelle sont deux choses distinctes, et le droit français penche, par défaut, du côté du prestataire. C'est une question juridique, mais c'est surtout un risque business majeur.
En droit français, le code d'une application développée par une agence appartient par défaut à l'agence, pas à vous, même si vous l'avez payé. L'auteur d'une œuvre logicielle en est le titulaire initial des droits (article L131-3 du Code de la propriété intellectuelle). Seule une clause de cession explicite et détaillée dans le contrat vous transfère réellement la propriété.
C'est l'un des verrous de dépendance à une agence que je décris dans l'article CTO freelance ou agence. Ici, on creuse le verrou juridique : qui possède quoi, et comment l'écrire noir sur blanc.
L'auteur par défaut, c'est le prestataire
Le principe est contre-intuitif pour qui n'est pas du métier. Quand une agence développe votre application, ses développeurs en sont les auteurs au sens du droit d'auteur. Payer la prestation vous donne le droit d'utiliser le résultat, mais pas automatiquement celui de le modifier, de le revendre, de le confier à un autre prestataire ou de l'emporter ailleurs.
« J'ai payé 80 000 € de développement. En voulant changer d'agence, j'ai appris que je ne possédais même pas le droit de faire reprendre mon propre code par quelqu'un d'autre. »
L'article L131-3 du Code de la propriété intellectuelle est sans ambiguïté : la transmission des droits d'auteur doit être écrite, et chaque droit cédé doit être mentionné distinctement, avec son domaine d'exploitation délimité. Autrement dit, une cession vague (« l'agence cède les droits ») ne suffit pas. Si le contrat est muet ou imprécis sur ce point, vous n'avez probablement qu'une licence d'utilisation, et le prestataire reste propriétaire de l'actif le plus important de votre entreprise.
Ce n'est pas de la malveillance : c'est le régime par défaut. Mais l'ignorer, c'est construire son entreprise sur un terrain qui ne vous appartient pas.
La clause de cession à exiger
La bonne nouvelle, c'est que tout cela se règle au moment de signer, pour zéro euro de plus, à condition de savoir quoi demander. Une clause de cession de droits correctement rédigée transfère la propriété du code de votre côté. Voici ce qu'elle doit couvrir, et ce que vous devez obtenir à la livraison.
Cession explicite et détaillée
Le contrat doit lister distinctement les droits cédés (reproduction, modification, adaptation, distribution), pour le monde entier et pour toute la durée légale. Une formule vague ne tient pas devant l'article L131-3.
Le code source, pas seulement le binaire
Exigez la livraison du code source complet, pas uniquement de l'application compilée. Sans les sources, vous ne possédez qu'une boîte noire que vous ne pourrez ni reprendre ni faire évoluer ailleurs.
Le dépôt et son historique
Le dépôt Git, son historique complet et les accès doivent être sur un compte que vous possédez, pas sur celui de l'agence. L'historique fait partie de la mémoire du projet.
Le sort des dépendances et briques tierces
Le contrat doit clarifier le statut des bibliothèques open source et des composants tiers utilisés, pour qu'aucune licence cachée ne vienne limiter votre usage plus tard.
Un point souvent oublié : la cession devrait être adossée au paiement, pas l'inverse. Tant que la facture finale n'est pas réglée, certains contrats prévoient que les droits ne sont pas transférés. C'est légitime côté agence, mais vous devez le savoir pour ne pas vous retrouver à exploiter un code qui ne vous appartient pas encore.
Avant de signer avec une agence, vérifiez la présence de trois éléments : une cession de droits explicite et détaillée conforme à l'article L131-3, la livraison du code source complet avec son dépôt, et une clause de réversibilité qui organise le transfert propre vers un autre prestataire le jour venu. L'absence de l'un des trois est un signal d'alerte.
Le lock-in qui se révèle en due diligence
Le pire moment pour découvrir un problème de propriété du code, c'est pendant une levée de fonds. La due diligence technique examine précisément qui possède quoi. Un investisseur sérieux vérifie la chaîne de titularité : si le code de votre produit appartient encore à un prestataire, ou si la cession est juridiquement bancale, c'est un risque qui pèse directement sur la valorisation, quand il ne fait pas capoter le tour.
La propriété du code est un actif, et la due diligence le vérifie
Aux yeux d'un investisseur, votre code n'est pas un coût passé : c'est l'actif central de l'entreprise. Si vous ne pouvez pas prouver que vous en êtes propriétaire de plein droit, l'actif est juridiquement fragile. Un produit dont la PI reste chez l'agence, ou repose sur une cession vague, devient un point de friction en due diligence : on exige une régularisation rétroactive, parfois impossible à obtenir si la relation avec le prestataire s'est tendue. La cession bien écrite dès le départ coûte zéro euro ; sa régularisation sous pression, en pleine levée, peut coûter des semaines et du pouvoir de négociation.
Régulariser après coup est toujours plus difficile. Il faut retrouver le prestataire, renégocier, parfois payer pour obtenir ce qu'on croyait déjà acquis. Si la relation s'est dégradée, vous négociez en position de faiblesse, exactement comme dans le scénario de dépendance que je décris pour les agences.
Ce qu'il faut retenir
Avoir payé ne suffit pas : la propriété du code se gagne par contrat, pas par facture. La question n'est pas « combien j'ai dépensé », mais « qu'est-ce que je possède vraiment, et puis-je le prouver ». Avant de signer une prestation de développement, faites relire la clause de cession, exigez le code source et son dépôt, et organisez la réversibilité dès le départ.
C'est aussi pour ça qu'avoir quelqu'un qui défend votre intérêt au moment de contractualiser change tout. Garder la main sur son produit dès le premier jour est un sujet à part entière, que je traite dans garder le contrôle de son produit quand on délègue le dev.
J'interviens comme CTO fractional pour auditer vos contrats, votre PI et vos accès, et sécuriser la propriété de votre produit avant qu'elle ne devienne un problème. Découvrez l'accompagnement CTO, ou réservons 30 minutes pour faire le point.
Envie d'en discuter ?
Réservez un créneau de 30 minutes pour un premier échange. Je vous aiderai à y voir plus clair sur votre situation.
Prendre rendez-vous