Ce que vous cédez et ce que vous gardez dans un contrat de développement logiciel

Un logiciel développé par un prestataire ne se résume pas à une question de propriété. Avant de signer, l’organisation doit surtout savoir si elle pourra utiliser, faire évoluer, maintenir et reprendre le logiciel sans dépendance excessive à son fournisseur.

---

Information juridique générale — France et Union européenne — état des références vérifié au 2 septembre 2026.

Avant de signer : tester l’autonomie réelle de l’organisation

La question « à qui appartient le logiciel ? » est trop étroite. Une organisation peut disposer de droits étendus et rester, en pratique, incapable de changer de prestataire, de faire assurer la maintenance par un tiers ou de récupérer ses données dans un format exploitable.

Le contrat se lit donc comme une architecture de dépendances. La lecture consiste à identifier ce qui a été créé pour le projet, ce que le prestataire apporte déjà, ce qui provient de tiers, puis à vérifier les droits et les moyens techniques nécessaires pendant toute la durée de vie du logiciel.

1. Savez-vous exactement ce qui compose le logiciel ?

La première vérification consiste à découper le logiciel en éléments juridiquement et techniquement distincts. Une clause générale de « propriété du logiciel » peut masquer des régimes très différents.

2. Qui détient réellement les droits sur les développements ?

Le paiement du développement ne suffit pas, à lui seul, à déterminer la titularité des droits. Le logiciel est protégé par le droit d’auteur, y compris son matériel de conception préparatoire, et les droits d’exploitation couvrent notamment la reproduction ainsi que l’adaptation et la modification.

Le régime des logiciels créés par des employés prévoit, sous les conditions de l’article L. 113-9 du Code de la propriété intellectuelle, la dévolution à l’employeur des droits patrimoniaux sur le logiciel et sa documentation. Le même article étend cette règle aux agents de l’État, des collectivités publiques et des établissements publics à caractère administratif, ce qui intéresse directement les projets développés en interne dans la sphère publique.

Cette règle ne dispense pas de vérifier la chaîne des droits lorsque le projet fait intervenir des sous-traitants, des développeurs indépendants ou des composants provenant de tiers.

Avant de signer, l’organisation doit donc pouvoir répondre à une question simple : le cocontractant dispose-t-il lui-même des droits qu’il promet de céder ou de concéder ?

3. Les droits prévus correspondent-ils à ce que vous devrez faire demain ?

La bonne clause n’est pas celle qui emploie la formule la plus large ; c’est celle qui couvre les usages réellement nécessaires. Le contrat doit permettre de déterminer si l’organisation pourra exploiter le logiciel, le déployer sur les environnements prévus, le faire évoluer, le corriger, l’interfacer avec d’autres systèmes et, si nécessaire, confier sa maintenance à un autre prestataire.

Tout contrat transmettant des droits d’auteur doit être établi par écrit : depuis le 1er octobre 2016, l’article L. 131-2 du Code de la propriété intellectuelle pose cette exigence sans la réserver à une catégorie de contrats. La règle générale des cessions de droits d’auteur veut en outre que chaque droit cédé fasse l’objet d’une mention distincte et que le domaine d’exploitation soit délimité quant à son étendue, à sa destination, au lieu et à la durée (article L. 131-3).

La conséquence pratique importe davantage que la discussion sur la sanction : ce qui n’a pas été délimité se lit restrictivement. L’organisation se retrouve alors avec moins de droits qu’elle ne croyait en détenir, sans que le contrat ait été remis en cause.

Une licence peut être suffisante lorsque son périmètre répond au besoin ; une cession peut être pertinente lorsque l’autonomie recherchée l’exige. Le choix part du scénario d’usage, non d’une préférence abstraite pour la « propriété ».

4. Aurez-vous réellement accès au code source si vous en avez besoin ?

Un droit juridique de modifier un logiciel ne garantit pas, à lui seul, la possibilité technique de le faire. L’accès au code source se pense avec la documentation, les procédures de compilation et de déploiement, les dépendances, les configurations utiles et les informations nécessaires à la reprise.

Le Code de la propriété intellectuelle réserve certains actes à la personne ayant le droit d’utiliser le logiciel, dans les conditions de l’article L. 122-6-1 : utilisation conforme à la destination, correction des erreurs, copie de sauvegarde, étude du fonctionnement, interopérabilité.

Pour un logiciel critique, le contrat peut aussi organiser un dépôt du code source auprès d’un tiers et définir précisément les événements permettant sa remise. Le dépôt n’a d’utilité que si le code déposé est à jour et réellement exploitable.

5. La réversibilité fonctionnerait-elle si vous changiez de prestataire demain ?

La réversibilité se teste avant la signature, lorsque l’organisation dispose encore d’un pouvoir de négociation. Elle doit permettre à un autre prestataire ou à une équipe interne de reprendre le service sans devoir reconstruire l’ensemble du système.

Le contrat précise ce qui sera remis, sous quel format, dans quel délai, avec quelle assistance et à quel coût. Ces obligations doivent être cohérentes avec les droits de propriété intellectuelle accordés : une documentation remise sans droit suffisant d’exploitation, ou des droits étendus sans éléments techniques de reprise, ne produisent pas une réversibilité effective.

6. Pouvez-vous récupérer les données dans un format réellement exploitable ?

La sortie du logiciel et la sortie des données sont deux sujets distincts. Le contrat précise quelles données sont restituées, dans quels formats, avec quels délais, quelles modalités de migration et quel sort est réservé aux copies et sauvegardes.

Lorsque le prestataire agit comme sous-traitant au sens du RGPD, le contrat organise également, au terme de la prestation, la suppression ou le renvoi des données à caractère personnel selon le choix du responsable du traitement, ainsi que la destruction des copies existantes, sauf obligation de conservation résultant du droit de l’Union ou du droit national. La réversibilité technique, la maîtrise des données et les droits sur le logiciel s’examinent donc ensemble.

7. Le contrat tient-il encore si le projet change dans trois ans ?

Un contrat de développement logiciel se relit à partir de scénarios de rupture, pas seulement du déroulement nominal du projet. La dépendance apparaît souvent plusieurs années après la livraison, lorsque l’organisation veut changer de prestataire, modifier profondément le logiciel ou remplacer un composant devenu indisponible.

Le contrat se teste donc face à la cessation d’activité du prestataire, à un changement de mainteneur, à une évolution majeure du système, à l’arrêt d’un composant essentiel ou à la fin de la relation contractuelle. Cette lecture transforme la négociation initiale en outil de maîtrise du cycle de vie numérique.

Cas particulier : marchés publics, code source et future mise en concurrence

Dans la commande publique, les droits attachés au logiciel peuvent avoir un effet direct sur la capacité à organiser ultérieurement une maintenance ou une évolution en concurrence.

L’accès au code peut conditionner une future mise en concurrence

Dans l’arrêt Informatikgesellschaft für Software-Entwicklung du 28 mai 2020 (C-796/18), la Cour de justice de l’Union européenne a souligné que le pouvoir adjudicateur qui envisage de passer un marché de maintenance, d’adaptation ou de développement d’un logiciel doit communiquer aux candidats et soumissionnaires potentiels des informations suffisantes pour permettre une concurrence effective sur ce marché dérivé.

Elle invite le juge national à vérifier trois choses : que les pouvoirs adjudicateurs disposent du code source, qu’ils le communiqueraient aux candidats en cas de mise en concurrence, et que l’accès à ce seul code source suffit à garantir un traitement transparent, égal et non discriminatoire.

La décision ne pose pas une obligation générale de remise du code source pour tout marché logiciel. Elle montre en revanche que l’organisation des droits et des accès peut devenir déterminante lorsqu’une mise en concurrence ultérieure est envisagée.

Des droits exclusifs peuvent verrouiller la maintenance, mais pas à n’importe quelle condition

Le Conseil d’État, dans sa décision Département de l’Oise du 2 octobre 2013 (n° 368846), a admis dans les circonstances de l’espèce qu’un droit d’exclusivité couvrant l’exploitation et la maintenance d’un logiciel pouvait rendre indispensable l’attribution du marché à un prestataire déterminé. La décision a été rendue sous l’empire de l’article 35, II, 8° du code des marchés publics, aujourd’hui abrogé.

La disposition équivalente est l’article R. 2122-3 du code de la commande publique, en vigueur depuis le 1er avril 2019, qui permet de passer un marché sans publicité ni mise en concurrence lorsque les prestations ne peuvent être fournies que par un opérateur déterminé, notamment en raison de « l’existence de droits d’exclusivité, notamment de droits de propriété intellectuelle ».

Pour l’acheteur, l’enseignement pratique se situe en amont : les choix de droits opérés lors de l’acquisition ou du développement pèsent durablement sur les conditions de maintenance et sur la possibilité de remettre certaines prestations en concurrence.

La checklist avant signature

Trois erreurs à éviter

• « J’ai payé le développement, donc je possède le logiciel. » Le prix ne suffit pas à déterminer les droits transmis.
• « Une cession de droits me rend autonome. » Sans code source, documentation et conditions de reprise adaptées, l’autonomie peut rester théorique.
• « Nous traiterons la réversibilité à la fin. » C’est précisément au moment de la sortie que le rapport de négociation est souvent le moins favorable.

L’essentiel

Références juridiques

Références vérifiées sur sources primaires le 2 septembre 2026. Elles permettent la relecture du guide ; elles ne remplacent pas l’analyse du contrat et de son contexte.

Ce mini-guide fournit une information juridique générale et ne constitue pas une consultation personnalisée. Chaque contrat s’apprécie au regard de ses stipulations et de son contexte.