Non, payer le développement d’une application ne vous en rend pas propriétaire. En droit français, les droits d’auteur sur le code naissent chez celui qui l’écrit, et seul un acte de cession écrit, qui liste chaque droit cédé et délimite son domaine d’exploitation, les transfère au client. Le contrat doit donc prévoir explicitement la cession du code spécifique, le sort des briques préexistantes et des composants open source, et une réversibilité concrète : accès, documentation, données et assistance pour changer de prestataire.
Ce sujet paraît juridique ; il est en réalité stratégique. Une application métier devient vite un actif central : elle porte vos processus, vos données, parfois votre avantage concurrentiel. Si vous ne pouvez ni la faire évoluer par quelqu’un d’autre, ni la reprendre, ni la valoriser lors d’une cession d’entreprise, vous dépendez d’un seul prestataire. Voici ce qu’il faut vérifier avant de signer.
Cet article donne des repères pour dialoguer avec votre prestataire et votre conseil. Il ne remplace pas l’avis d’un avocat en propriété intellectuelle sur votre contrat.
Pourquoi le client n’est-il pas propriétaire par défaut ?
Le code source est protégé par le droit d’auteur. Le principe est simple : l’auteur est celui qui crée. Pour un salarié, l’article L113-9 du Code de la propriété intellectuelle (CPI) attribue à l’employeur les droits patrimoniaux sur les programmes développés dans le cadre de ses fonctions. Ce mécanisme automatique ne s’applique pas à une agence, à une ESN ou à un freelance.
Pour un prestataire externe, il faut une cession. Et la loi est exigeante sur sa forme. L’article L131-3 du CPI pose que la transmission des droits est subordonnée à la condition que chacun des droits cédés « fasse l’objet d’une mention distincte dans l’acte de cession » et que leur domaine d’exploitation soit « délimité quant à son étendue et à sa destination, quant au lieu et quant à la durée ».
Conséquence pratique, rappelée par le cabinet SWIM Legal : une clause vague du type « le client est propriétaire de tous les livrables » est fragile, car le juge interprète la cession restrictivement. Ce qui n’est pas expressément cédé reste à l’auteur.
Que doit contenir la clause de cession ?
Une cession de droits d’auteur est l’acte par lequel l’auteur transfère tout ou partie de ses droits patrimoniaux à un tiers. Pour une application sur mesure, elle doit au minimum énumérer :
- les droits cédés, un par un : reproduction, représentation, adaptation et modification, traduction dans d’autres langages, intégration à d’autres outils, mise sur le marché, droit de faire maintenir par un tiers ;
- l’étendue : exclusive pour le code spécifique, afin que le prestataire ne puisse pas revendre votre outil à un concurrent ;
- la destination : usage interne, commercialisation en mode SaaS, distribution à vos clients ou filiales ;
- le lieu : en général le monde entier, surtout si vous avez des sites ou des clients à l’étranger ;
- la durée : la durée légale de protection des droits d’auteur ;
- le moment du transfert : au fil des livraisons ou au paiement de chaque lot, plutôt qu’à la toute fin du projet ;
- les livrables concernés : code source, scripts de déploiement, schémas de base de données, maquettes, documentation.
Ce dernier point mérite attention. Si les maquettes sont réalisées par un designer et le code par une autre équipe, chacun de ces auteurs doit avoir cédé ses droits au prestataire pour que celui-ci puisse vous les céder à son tour. Demandez une garantie contractuelle sur ce point, y compris pour les éventuels sous-traitants.
Code spécifique, briques préexistantes, open source : trois régimes différents
Une application livrée par une agence n’est jamais composée uniquement de code écrit pour vous. On y trouve trois catégories, qu’un contrat solide traite séparément.
| Catégorie | Exemple | Régime recommandé | Point de vigilance |
|---|---|---|---|
| Code spécifique | Vos règles de gestion, vos écrans, vos intégrations | Cession exclusive des droits patrimoniaux | Lister les droits, ne pas se contenter de « tous les livrables » |
| Briques préexistantes du prestataire | Module d’authentification, générateur de documents, socle technique réutilisé | Licence perpétuelle, mondiale, irrévocable, transférable, avec droit de modification | Une licence qui s’éteint en cas de changement de contrôle peut bloquer la vente de votre société |
| Composants open source | Frameworks, bibliothèques, base de données | Licence de l’auteur d’origine | Recenser les licences ; certaines imposent de publier le code qui les intègre |
L’annexe la plus utile du contrat est souvent la plus simple : un inventaire nominatif des briques préexistantes, mis à jour à chaque livraison. Il évite le litige classique où le prestataire revendique un module entier comme « son » savoir-faire au moment où vous voulez changer d’équipe. SWIM Legal recommande d’ailleurs la même pratique, ainsi qu’un recensement des dépendances open source avant signature.
Pour l’open source, le risque n’est pas la propriété mais la conformité. Beaucoup de bibliothèques courantes du développement web sont publiées sous des licences dites permissives, qui autorisent une réutilisation large. Quelques licences dites « à réciprocité » imposent en revanche de redistribuer le code dérivé sous la même licence dans certaines conditions. Un inventaire automatique des dépendances, produit à chaque version, règle la question.
La propriété ne suffit pas : l’accès compte autant
Être titulaire des droits sur un code que vous ne pouvez pas récupérer n’a qu’une valeur théorique. La vraie question opérationnelle est : si votre prestataire disparaît demain, qu’avez-vous entre les mains ?
Exigez dès le démarrage :
- Le dépôt de code au nom de votre entreprise (sur votre organisation GitHub, GitLab ou équivalent), avec le prestataire invité, et non l’inverse.
- Les comptes d’hébergement et de services tiers à votre nom : cloud, base de données, envoi d’e-mails, stockage de fichiers, nom de domaine, certificats.
- Les secrets et identifiants dans un coffre partagé auquel vous avez accès, avec une procédure de rotation au départ du prestataire.
- Une documentation vivante : architecture, installation, déploiement, variables de configuration, procédures de sauvegarde et de restauration.
- Des scripts de déploiement automatisés versionnés avec le code, pour qu’une nouvelle équipe puisse remettre l’application en production sans dépendre de la mémoire de quelqu’un.
C’est la logique que nous appliquons dans nos projets d’applications web : le client possède le dépôt et les environnements dès le premier sprint, et chaque démonstration de sprint s’appuie sur du code déjà dans son espace.
Et le séquestre du code source ?
Le séquestre consiste à déposer le code et sa documentation chez un tiers de confiance, qui les remet au client si certaines conditions sont réunies. En France, l’Agence pour la protection des programmes (APP) propose deux formules : une convention tripartite entre le fournisseur, le client et l’APP, ou une simple clause d’accès dans le contrat bilatéral. L’accès est déclenché par une défaillance du fournisseur, comme une liquidation ou un manquement contractuel, selon les cas prévus.
Le séquestre est pertinent quand le prestataire conserve le code : solution qu’il édite, plateforme SaaS mutualisée, composant critique concédé sous licence. Pour une application sur mesure dont vous détenez le dépôt, il fait double emploi.
Qu’est-ce qu’une réversibilité bien rédigée ?
La réversibilité est la capacité de reprendre en main une application, ses données et son exploitation, soit en interne, soit avec un autre prestataire, sans rupture de service. Une clause sérieuse répond à six questions.
| Question | Ce que le contrat doit préciser |
|---|---|
| Quoi ? | Code, données, documentation, scripts, accès, historique des tickets |
| Sous quelle forme ? | Formats ouverts et documentés pour les données, dépôt complet avec historique pour le code |
| Quand ? | Délai de remise après la demande, période de transition pendant laquelle le service continue |
| Avec quelle aide ? | Nombre de jours d’accompagnement du repreneur, sessions de transfert de connaissances |
| À quelles conditions ? | Prestation incluse ou facturée, et selon quelles modalités |
| Et après ? | Suppression des données chez le sortant, attestation, révocation des accès |
Le dernier point n’est pas qu’une bonne pratique. Lorsque l’application traite des données personnelles, l’article 28 du RGPD impose au sous-traitant, au terme de la prestation et selon le choix du responsable du traitement, de supprimer les données ou de les lui renvoyer.
Ce que le Data Act change pour l’hébergement
Pour la partie hébergement et services cloud, le cadre européen s’est durci. Le règlement sur les données (Data Act) est entré en application le 12 septembre 2025. Son article 25 impose aux fournisseurs de services de traitement de données des clauses de changement de fournisseur : un préavis qui ne peut dépasser deux mois, une période transitoire de 30 jours calendaires en principe, et une période minimale de 30 jours pour récupérer les données. L’article 29 prévoit la suppression totale des frais de changement à compter du 12 janvier 2027.
Ces règles protègent votre hébergement ; elles ne règlent pas la propriété du code de votre application. Les deux sujets se traitent dans des contrats distincts, d’où l’intérêt de garder les comptes d’hébergement à votre nom. Notre article sur l’hébergement des applications métier détaille les options.
Les signaux d’alerte avant de signer
Certains indices doivent vous faire poser des questions, voire renoncer :
- le contrat parle de « licence d’utilisation » pour un développement que vous financez intégralement ;
- la cession n’intervient qu’au paiement du solde final, sans transfert progressif ;
- le prestataire refuse que le dépôt de code soit à votre nom ;
- l’application repose sur un « framework maison » non documenté, exclu de la cession ;
- aucune clause ne décrit la fin de contrat, ou elle renvoie à un devis « le moment venu » ;
- la documentation n’apparaît pas dans la liste des livrables.
Aucun de ces points n’est rédhibitoire isolément. Leur accumulation dessine en revanche une dépendance que vous paierez tôt ou tard. Ce sont aussi de bonnes questions à poser à une agence avant de la choisir, quel que soit le type de contrat, forfait ou régie.
La checklist du contrat de développement
À vérifier, idéalement avec votre avocat, avant la signature :
- Une clause de cession qui énumère chaque droit et délimite étendue, destination, lieu et durée.
- Un transfert des droits au fil des livraisons ou des paiements de lots.
- Une annexe listant les briques préexistantes du prestataire et la licence qui vous est accordée sur elles.
- Un inventaire des composants open source et de leurs licences, livré à chaque version.
- Une garantie d’origine du code et contre les revendications de tiers, y compris des sous-traitants.
- Le dépôt de code, l’hébergement et le nom de domaine au nom du client.
- La documentation technique comme livrable à part entière, avec un niveau de détail défini.
- Une clause de réversibilité qui répond aux six questions ci-dessus.
- Les obligations de suppression ou de restitution des données personnelles en fin de prestation.
- Le cadre de la maintenance après mise en production, qui ne doit pas être un moyen détourné de vous retenir.
Vous pouvez intégrer ces exigences dès votre expression de besoin grâce à notre modèle de cahier des charges. Et si vous voulez savoir comment nous traitons la propriété du code et la réversibilité sur un projet comme le vôtre, écrivez-nous : nous vous montrerons les clauses que nous signons.
