Le code d’un logiciel sur mesure n’appartient pas automatiquement au client parce qu’il a payé le développement. La réponse dépend du statut de la personne qui l’a écrit et de ce que prévoit le contrat signé. Il faut distinguer la remise d’une copie du code source, le droit de l’utiliser, le droit de le modifier, les éventuelles briques sous licence et les éléments nécessaires à la reprise du projet.
Cet article fournit une information générale. Il ne remplace pas l’analyse d’un contrat par un avocat ou un conseil en propriété industrielle.
Le paiement d’une prestation ne règle pas tout
L’INPI rappelle que les logiciels, notamment leur code source, sont protégés par le droit d’auteur. Les droits d’exploitation couvrent plusieurs actes. L’article L122-6 du Code de la propriété intellectuelle vise notamment la reproduction, l’adaptation ou la modification et la mise sur le marché.
Le premier réflexe ne doit donc pas être de supposer que « le client a payé, donc tout lui appartient ». Il faut lire ce que le contrat prévoit réellement.
Le statut de la personne qui crée le logiciel compte
Le logiciel créé par un salarié
L’article L113-9 prévoit un régime particulier : sauf dispositions statutaires ou stipulations contraires, les droits patrimoniaux sur les logiciels et leur documentation créés par des employés dans l’exercice de leurs fonctions ou d’après les instructions de leur employeur sont dévolus à l’employeur.
Le logiciel créé par un prestataire indépendant
La situation ne doit pas être assimilée automatiquement à celle du salarié. Le contrat doit préciser les droits transmis et les conditions d’utilisation du logiciel. L’article L131-2 prévoit que les contrats transmettant des droits d’auteur doivent être constatés par écrit : sans écrit, le prestataire indépendant reste titulaire de ses droits.
Les droits moraux restent à l’auteur
Même en cas de cession, les droits moraux ne se transmettent pas : l’article L121-1 les déclare perpétuels, inaliénables et imprescriptibles. Pour un logiciel, l’article L121-7 les limite toutefois : sauf clause plus favorable à l’auteur, celui-ci ne peut pas s’opposer à une modification faite par le titulaire du droit d’adaptation, tant qu’elle ne porte pas atteinte à son honneur ou à sa réputation.
Le code d’un logiciel sur mesure et les droits d’exploitation
Recevoir le dépôt de code ne répond pas, à lui seul, à toutes les questions juridiques. À l’inverse, disposer d’un droit d’utilisation ne garantit pas que l’entreprise possède les fichiers, les accès ou la documentation nécessaires pour changer de prestataire.
| Élément | Question à poser |
|---|---|
| Code source | Quels dépôts, versions et scripts sont remis ? |
| Utilisation | Dans quels contextes l’entreprise peut-elle exploiter le logiciel ? |
| Modification | Le client peut-il modifier le logiciel ou confier la maintenance à un tiers ? |
| Distribution | Peut-il fournir, louer ou commercialiser le logiciel, si cela correspond à son projet ? |
| Composants tiers | Quelles licences open source ou commerciales s’appliquent ? |
| Briques génériques | Restent-elles au prestataire et, dans ce cas, quelle licence reçoit le client ? |
Les réponses doivent être cohérentes avec l’usage prévu. Une application interne, un produit revendu et une plateforme proposée par abonnement n’appellent pas nécessairement les mêmes droits.
Les briques génériques doivent être identifiées
Un développeur ne réécrit pas nécessairement chaque composant depuis zéro. Il peut utiliser des bibliothèques tierces, des logiciels open source ou ses propres modules réutilisables.
Demander une cession exclusive de tout le socle peut être impossible ou disproportionné. Une solution contractuelle consiste à distinguer le développement spécifique du client des composants génériques ou tiers, puis à documenter les licences applicables.
Chez ClosiQode, voici comment je travaille. Le code source vous est remis à la livraison. Je ne cède pas mes droits d’auteur par défaut, ni sur le développement spécifique ni sur les briques génériques. Vous recevez une licence d’usage gratuite, non exclusive et sans limite de durée, pour les besoins de votre entreprise : vous pouvez utiliser l’application, la modifier et la faire modifier ou maintenir par un autre prestataire ; vous ne pouvez pas revendre ni redistribuer le logiciel ou ses briques. Si votre projet exige une cession des droits patrimoniaux, par exemple pour revendre le logiciel, elle est possible sur demande et chiffrée à part dans le devis. C’est mon modèle, pas une règle applicable à tous les prestataires : le contrat fait foi, et vous pouvez le faire relire par un avocat avant de signer.
La propriété du code ne garantit pas l’autonomie
Une entreprise peut récupérer un dépôt complet et rester incapable de faire fonctionner son application si les autres éléments manquent.
- Les données sont-elles exportables dans un format exploitable ?
- Les comptes d’hébergement et services tiers sont-ils ouverts au nom du client ?
- Qui possède les identifiants et les moyens de paiement ?
- Les variables de configuration et procédures de déploiement sont-elles documentées ?
- Les sauvegardes peuvent-elles être restaurées ?
- Un autre développeur peut-il installer et reprendre le projet ?
La réversibilité est donc à la fois juridique, technique et opérationnelle.
La matrice de réversibilité à annexer au projet
Cette matrice est un outil de discussion et de vérification. Les droits applicables doivent être rédigés et validés dans le contrat adapté au projet.
| Élément | Ce qui doit être identifié | Test de reprise |
|---|---|---|
| Dépôt de code | Propriétaire du dépôt, branches livrées, historique convenu et composants exclus | Un tiers autorisé peut cloner la version livrée et comprendre sa structure. |
| Droits et licences | Droits accordés sur le spécifique, licence des briques génériques et dépendances tierces | Le client sait qui peut maintenir, modifier, distribuer ou héberger chaque composant. |
| Environnements et comptes | Titulaire, administrateurs, facturation, domaine, hébergement et services externes | Le client peut révoquer un accès et conserver le service après le départ du prestataire. |
| Données et sauvegardes | Format d’export, fréquence, chiffrement, durée et procédure de restauration | Une sauvegarde est restaurée dans un environnement de test documenté. |
| Déploiement et secrets | Variables requises, stockage des secrets, scripts et ordre des opérations | Une personne habilitée peut redéployer sans récupérer un mot de passe personnel du prestataire. |
| Documentation et transfert | Architecture, dépendances, incidents connus et temps de passation | Le nouveau mainteneur peut prendre en charge une correction sans reconstituer tout le projet. |
Le meilleur indicateur d’autonomie n’est pas la présence d’un fichier ZIP. C’est la réussite d’un test de reprise convenu, réalisé avec les accès et documents qui seront effectivement remis.
Quels documents demander à la livraison ?
La liste dépend du projet, mais peut comprendre :
- le dépôt de code et son historique convenu ;
- la procédure d’installation et de déploiement ;
- l’architecture générale et la liste des services externes ;
- l’inventaire des licences et dépendances ;
- les accès administrateur appartenant au client ;
- la procédure de sauvegarde et de restauration ;
- les modalités de maintenance et de fin de collaboration.
Un tiers doit pouvoir comprendre ce qui est livré sans recommencer toute l’enquête depuis zéro.
Les huit questions à poser avant de signer
- Vais-je recevoir le code source et dans quelles conditions ?
- Quels droits d’utilisation, de modification et de distribution sont prévus ?
- Puis-je confier la maintenance à un autre prestataire ?
- Quelles briques génériques ou dépendances tierces sont utilisées ?
- À qui appartiennent les comptes, noms de domaine et environnements ?
- Comment récupérer les données et les sauvegardes ?
- Quelle documentation sera remise et quand ?
- Que prévoit le contrat à la fin de la collaboration ?
Ces réponses doivent figurer dans les documents contractuels ou les livrables, pas uniquement dans une conversation commerciale.
Questions fréquentes
Le client devient-il propriétaire parce qu’il a payé la facture ?
Pas automatiquement. Le paiement et la transmission des droits sont deux questions différentes. Il faut vérifier le statut du créateur et les clauses écrites.
Livrer le code source équivaut-il à céder tous les droits ?
Non. La remise matérielle des fichiers ne décrit pas nécessairement tous les droits d’exploitation. Le contrat doit préciser ce que le client peut faire.
Peut-on utiliser des composants open source dans un logiciel sur mesure ?
Oui, sous réserve de respecter leurs licences. Le prestataire doit pouvoir identifier les dépendances et expliquer les obligations pertinentes pour le projet.
Le client doit-il absolument exiger une cession exclusive ?
Pas dans tous les cas. Le niveau de droits doit correspondre à l’usage et à l’autonomie recherchés. Une licence suffisamment large peut convenir pour certaines briques génériques, tandis que le développement spécifique peut faire l’objet d’un traitement différent.
Quand demander un avis juridique ?
Lorsque les enjeux financiers sont importants, que le logiciel doit être revendu, que plusieurs auteurs interviennent, qu’une exclusivité est recherchée ou que les clauses sont ambiguës. Un professionnel pourra analyser le contrat et le contexte précis.
La bonne relation n’a pas besoin d’enfermement
Être autonome ne signifie pas quitter le prestataire initial. Cela signifie pouvoir rester pour la qualité du service plutôt que par impossibilité technique ou contractuelle de partir.
Clarifier la reprise et les livrables de mon application avec ClosiQode