Récupérer le code source de son application : vos droits et la marche à suivre
26/08/2026
Vous avez payé le développement de votre application. Vous en êtes le propriétaire, du moins vous le pensiez. Puis vient le jour où vous demandez le code source à votre prestataire, et la réponse tarde, se fait évasive, ou devient un refus net. Beaucoup de dirigeants découvrent à ce moment précis que payer une prestation de développement ne suffit pas à détenir des droits sur le résultat.
Cet article explique ce que dit réellement le droit français, comment vérifier votre situation en relisant votre contrat, et quelles démarches engager selon le cas. L'objectif est simple : savoir où vous en êtes avant de discuter avec votre prestataire, et éviter les erreurs qui affaiblissent votre position.
Payer ne vaut pas céder les droits
Voici le point qui surprend le plus : en droit français, le fait de commander et de payer un développement ne transfère pas automatiquement les droits d'auteur sur le logiciel produit.
Un logiciel est une œuvre de l'esprit protégée par le droit d'auteur. Celui qui l'écrit en détient les droits patrimoniaux, sauf mécanisme contraire. Le Code de la propriété intellectuelle prévoit bien une dévolution automatique à l'employeur, mais elle vise les logiciels créés par des salariés dans l'exercice de leurs fonctions. Elle ne s'applique pas à un prestataire externe, agence ou freelance, qui reste un tiers indépendant.
Conséquence directe : sans clause de cession écrite dans votre contrat, votre prestataire peut rester titulaire des droits sur le code, même après paiement intégral de la facture. Vous détenez alors un droit d'usage, souvent implicite et mal délimité, pas la propriété.
Le droit va plus loin dans l'exigence. La transmission des droits d'auteur suppose que chaque droit cédé soit mentionné distinctement dans l'acte, avec son domaine d'exploitation délimité. Une formule vague du type « le client est propriétaire des livrables » ne suffit pas toujours à opérer une cession valable. C'est pour cette raison qu'un contrat de développement sérieux consacre un article entier à la propriété intellectuelle, et non une demi-phrase.
Code source et code objet : la distinction qui change tout
Deuxième point de vigilance, distinct du premier. Un contrat peut prévoir une cession de droits sans vous garantir la remise du code source.
Le code source est le texte lisible écrit par les développeurs, celui qu'on modifie. Le code objet, ou code compilé, est la version exécutable par la machine, illisible pour un humain. Disposer du second sans le premier vous permet de faire tourner l'application, mais pas de la faire évoluer ni de la confier à quelqu'un d'autre.
Un contrat peut donc vous rendre titulaire de droits tout en restant silencieux sur la livraison des sources. Dans les faits, vous êtes bloqué. Un contrat complet traite les deux sujets séparément : la cession des droits d'une part, l'obligation de remise du code source et de sa documentation d'autre part, avec un délai et un format.
Relire votre contrat : les 5 points à vérifier
Avant toute démarche, sortez le contrat signé et cherchez ces cinq éléments. Ils déterminent votre marge de manœuvre.
- L'existence d'une clause de cession. Cherchez les mots « cession », « propriété intellectuelle », « droits patrimoniaux ». Si rien de tel n'apparaît, la cession n'a probablement pas eu lieu.
- L'étendue de la cession. Une cession peut être limitée à certains droits, à un territoire ou à une durée. Vérifiez que les droits de reproduction, de modification et d'adaptation sont inclus, car ce sont eux qui autorisent la reprise par un autre prestataire.
- L'obligation de remise du code source. Une clause de cession sans obligation de livraison des sources vous laisse démuni en pratique.
- La clause de réversibilité. Elle organise la restitution de l'ensemble des éléments en fin de contrat : code, accès, données, documentation. C'est la clause la plus utile et la plus souvent absente.
- Le sort des dépendances et briques tierces. Une application repose sur des bibliothèques externes et parfois sur des composants propriétaires du prestataire. Vérifiez si ces derniers sont cédés ou seulement concédés en licence.
Si ces cinq points sont couverts, votre dossier est solide et la discussion sera courte. S'ils sont absents, la suite dépend de votre capacité à négocier.
La marche à suivre selon votre situation
Le contrat prévoit la cession et la remise des sources
Votre position est confortable. Adressez une demande écrite, par courriel puis par lettre recommandée, rappelant l'article du contrat et fixant un délai raisonnable. La plupart des situations se règlent à ce stade, parce que le prestataire sait que le texte lui est défavorable.
Demandez la livraison sous une forme exploitable : un dépôt Git avec son historique plutôt qu'une archive compressée sans contexte. L'historique des modifications a une valeur technique réelle pour celui qui reprendra le projet.
Le contrat est muet ou ambigu
Vous n'êtes pas sans recours, mais la négociation prime. Le prestataire détient un actif, vous détenez la relation commerciale et le règlement des dernières factures. Une cession de droits régularisée par avenant, éventuellement contre paiement, reste souvent moins coûteuse et plus rapide qu'un contentieux.
Évitez deux erreurs fréquentes. La première consiste à cesser tout paiement pour faire pression, ce qui vous met en tort et fragilise votre position. La seconde est d'annoncer votre départ avant d'avoir sécurisé vos accès, ce qui transforme une négociation en rapport de force. Notre guide sur la checklist de réversibilité détaille l'ordre dans lequel procéder.
Le prestataire a disparu ou ne répond plus
Le problème n'est plus juridique mais opérationnel, et l'urgence change tout. La priorité devient la reprise en main de ce qui est encore accessible : noms de domaine, hébergement, comptes tiers. Ce cas particulier est traité dans notre article sur le prestataire qui ne répond plus.
Le séquestre de code source, une sécurité méconnue
Il existe un mécanisme préventif que peu de PME connaissent : le dépôt du code source chez un tiers de confiance, appelé séquestre ou escrow.
Le principe est simple. Le prestataire dépose régulièrement le code chez un organisme indépendant. Le contrat définit les événements qui déclenchent la remise au client : liquidation judiciaire, cessation d'activité, manquement grave, arrêt de la maintenance. Vous n'avez pas accès au code au quotidien, mais vous êtes couvert si le prestataire disparaît.
Cette solution a un coût annuel et suppose que le prestataire l'accepte, ce qui se négocie mieux à la signature qu'en cours de route. Elle prend tout son sens quand votre activité dépend directement de l'application, ou quand vous confiez le développement à une structure petite ou récente.
Ce qu'il faut mettre au contrat la prochaine fois
Que vous récupériez votre code ou non, l'épisode doit servir pour le contrat suivant. Quatre clauses suffisent à écarter la quasi-totalité des situations de blocage.
- Une cession de droits expresse et complète, énumérant les droits cédés, leur territoire et leur durée, incluant reproduction, modification et adaptation.
- Une obligation de remise du code source, avec un délai, un format et l'exigence d'un historique de versions exploitable.
- Une clause de réversibilité organisant la restitution complète en fin de contrat : code, données, accès, documentation, comptes tiers.
- Une clause sur les briques tierces, distinguant ce qui est cédé de ce qui est concédé sous licence, et précisant les conditions de poursuite d'usage.
Ces quatre clauses n'allongent le contrat que de quelques paragraphes. Leur absence peut immobiliser un produit pendant des mois.
Notre position sur le sujet
Chez Bob, le code appartient au client, et cette règle figure au contrat plutôt que dans un argumentaire commercial. Les dépôts sont hébergés sur les comptes du client dès le premier jour lorsqu'il en dispose, et la documentation se construit pendant le projet au lieu d'être promise pour la fin.
Cette position a une raison pratique autant qu'éthique. Un client retenu par la détention de son code est un client qui reste par contrainte, pas par satisfaction. Nous préférons que nos contrats de maintenance applicative se reconduisent parce que le service tient ses engagements. C'est aussi ce qui nous permet de reprendre sereinement des applications développées ailleurs : nous savons ce que c'est que d'hériter d'un projet, et nous ne mettons personne dans la situation que cet article décrit.
Si vous êtes en train de récupérer une application et que vous vous demandez ce qu'elle vaut techniquement, la question suivante est celle de son état réel. C'est l'objet de notre article sur l'audit de code avant reprise.
Questions fréquentes
J'ai payé mon application, ne suis-je pas automatiquement propriétaire du code ?
Non, pas en droit français. Le paiement d'une prestation ne vaut pas cession des droits d'auteur sur le logiciel. Il faut une clause de cession écrite et suffisamment précise. Sans elle, le prestataire peut rester titulaire des droits patrimoniaux malgré le règlement intégral des factures.
Mon prestataire refuse de me livrer le code source, que puis-je faire ?
Commencez par vérifier ce que prévoit le contrat, puis adressez une demande écrite en rappelant la clause applicable. Si le contrat est muet, la négociation d'un avenant de cession est souvent la voie la plus rapide. Un avocat spécialisé en propriété intellectuelle est utile dès que le montant en jeu ou l'enjeu opérationnel est important.
La cession des droits inclut-elle toujours la livraison du code source ?
Non, ce sont deux obligations distinctes. Un contrat peut vous céder des droits sans organiser la remise des sources, ce qui vous laisse propriétaire sur le papier mais bloqué en pratique. Vérifiez que les deux points figurent séparément.
Qu'est-ce qu'un séquestre de code source ?
C'est le dépôt du code chez un tiers de confiance, qui vous le remet si des événements prévus au contrat surviennent, comme la disparition du prestataire ou l'arrêt de la maintenance. C'est une assurance, à négocier de préférence au moment de la signature.
Puis-je faire reprendre mon application par une autre équipe sans avoir les droits ?
C'est risqué. Modifier un logiciel sur lequel vous ne détenez pas les droits d'adaptation vous expose juridiquement, et expose aussi le prestataire qui accepterait la mission. Régularisez la situation contractuelle avant d'engager une reprise.
Combien de temps prend une récupération de code source ?
Quand le contrat est clair, quelques jours à quelques semaines. Quand il est muet et que la relation est dégradée, comptez plusieurs semaines de négociation. C'est la raison pour laquelle il vaut mieux traiter le sujet à la signature qu'au moment du départ.